| 05:29.30 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 05:29.30 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 06:26.06 | *** join/#riftuidev hughball (hughball@d66-222-251-47.abhsia.telus.net) |
| 06:27.00 | hughball | good evening - anyone around for what should be a simple question? |
| 06:27.07 | hughball | for someone who knows what they're doing, that is |
| 06:27.15 | hughball | "simple" |
| 06:27.19 | hughball | ha |
| 06:28.02 | hughball | I'm trying to split my addon into separate files so it's easier to maintain. |
| 06:28.56 | hughball | I've declaring a variable file with the code "local G = ...; G.tableName = {}" (pretend that ; are line breaks) |
| 06:30.02 | hughball | in my other file, I've got "local G = ...; dump(G.tableName);" and the output is nil |
| 06:31.33 | hughball | in my .toc, I've got my variable file above the other in the "RunOnStartup" table. |
| 06:36.44 | hughball | hmm |
| 06:37.12 | hughball | any hints as to why that property would be nil when i've defined it as a new (but empty) table in the variables file? |
| 07:02.03 | hughball | also, at the top of the variables file, i'm doing a "G = G or {}" to instantiate the shared table |
| 07:02.18 | hughball | thanks in advance - time for sleep for this guy |
| 09:03.26 | ZorbaTHut | hugh, "local" values are local - each file ends up with its own independent G |
| 09:03.42 | ZorbaTHut | you'd want to make a non-local variable, named something more distinctive so you don't clobber other people's variables |
| 09:15.18 | *** join/#riftuidev NuSuey (uid3556@gateway/web/irccloud.com/x-teatmakqabzwbnxb) |
| 09:16.50 | *** join/#riftuidev hughball (hughball@d66-222-251-47.abhsia.telus.net) |
| 11:39.14 | *** join/#riftuidev Naifu (515c640d@gateway/web/cgi-irc/kiwiirc.com/ip.81.92.100.13) |
| 12:23.20 | Ivnedar | ... is the addon reference isn't it? |
| 12:23.30 | Ivnedar | addon table, addondata table |
| 12:27.02 | ZorbaTHut | hmm, y'know what, you're right. but I think the addondata table is the only one that's guaranteed shared? the other might be regenerated per-file |
| 12:27.10 | ZorbaTHut | (obviously it's been a long time since I looked at that :V) |
| 12:28.07 | Ivnedar | I can see I was trying things when I set mine up. The main file does a local a = Inspect.Addon.Detail("addonname"); local addondata = a.data |
| 12:28.16 | Ivnedar | then next file does local addon, addondata = ... |
| 12:28.32 | Ivnedar | changing addondata in the second file affects the one in the first |
| 12:28.40 | Ivnedar | haven't tried doing anything with the first one |
| 12:29.39 | Ivnedar | is the file's code evaluated as if it was inside a big function that passes in a series of args, which is why ... reference gets those values |
| 12:32.42 | ZorbaTHut | "as if" is a bit of an understatement - when lua parses a chunk of text like that it literally parses it as a function |
| 12:32.50 | Ivnedar | ah yeah, that'd make sense. If the addon reference is created new each file, then hughball's .tableName wouldn't persist |
| 12:32.51 | ZorbaTHut | and yes, that means files can return things :) |
| 12:32.55 | Ivnedar | :) |
| 12:33.24 | Ivnedar | does the return value of a file go anywhere? |
| 12:33.27 | ZorbaTHut | it's a reasonably clever bit of behavior. they already have the concept of functions, why not just define files as functions? |
| 12:33.42 | ZorbaTHut | I know we don't make productive use of it. depending on how paranoid I was, returning a value from a file may be an error |
| 12:34.04 | Ivnedar | changes all his files to finish with return "Hi Zorba!" |
| 12:35.31 | *** join/#riftuidev Imhothar (~Imhothar@ppp-93-104-180-108.dynamic.mnet-online.de) |
| 12:36.10 | ZorbaTHut | I'm *pretty* sure that's valid ;) |
| 12:36.29 | Ivnedar | will find out when my client finishes patching :D |
| 12:47.14 | Ivnedar | hee hee, assert failed |
| 12:47.22 | Ivnedar | looks like you assert that nothing's returned |
| 12:47.50 | Ivnedar | Error: Unknown: assertion failed! |
| 12:48.03 | Ivnedar | addon works fine otherwise |
| 12:49.31 | ZorbaTHut | yep, looks like I do :) |
| 12:49.43 | ZorbaTHut | guess that should be a better assert message, but it's not like anyone really does that, so |
| 12:50.07 | ZorbaTHut | I'm one of the most assert-happy programmers I know - I want to ensure it does *exactly* what I'm expecting |
| 12:50.16 | ZorbaTHut | (and then, if it doesn't do that, I want it to recover as well as it can) |
| 12:51.02 | *** join/#riftuidev Naifu (515c640d@gateway/web/cgi-irc/kiwiirc.com/ip.81.92.100.13) |
| 12:51.55 | Naifu | the second one is share through all files of one addon afik |
| 12:53.03 | Naifu | i do the following in all my files: local addonInfo, privateVars = ... |
| 12:53.40 | Naifu | privateVars is shared and addonInfo includes all kind of stuff including info from the toc file for example addon.toc.version or something like that |
| 13:11.28 | Naifu | funny there are still 'heroes of telara' images in the assets :D |
| 13:11.45 | Naifu | wonder what the 'heroes of trion' images were for |
| 13:34.43 | Imhothar | ZorbaTHut I guess you're not just using good old assert() |
| 13:36.21 | ZorbaTHut | naifu, Channel 1 -> Heroes of Trion -> Heroes of Telara -> Rift: Planes of Telara -> Rift |
| 13:36.34 | ZorbaTHut | this game had, shall we say, an interesting history |
| 13:37.18 | ZorbaTHut | imhothar, yep - the vast majority of the game uses an assert function that pops up a modal dialog which allows asserts to be skipped, either one time or for that execution of the game |
| 13:37.31 | ZorbaTHut | it also provides a stack trace for QA to paste into bug reports |
| 13:37.54 | ZorbaTHut | and while we can just use a normal assert message, we can also override the message to include whatever details we want |
| 13:38.13 | ZorbaTHut | (I had to modify the function last month to properly deal with messages more than half a dozen lines long, I have a massive thirty-line debug dump happening on some messages now) |
| 13:39.24 | ZorbaTHut | they're disabled on release clients; on release servers, they log to a database, and we get daily reports of asserts. recoverable asserts are a great system and I have no idea why they're not industry-standard by now. |
| 13:40.26 | Imhothar | well that sounds less like a traditional assert but more like a general error handling mechanic |
| 13:41.19 | ZorbaTHut | it's a little difference because there is no concept of an "expected assert". any assert that triggers is considered a bug |
| 13:41.29 | ZorbaTHut | (that's why the whole modal-dialog thing) |
| 13:42.17 | ZorbaTHut | whereas I think "error handling" is generally expected to deal with errors properly - our asserts are more along the lines of "we're boned, but if you want to continue anyway, pres butan and we'll try" |
| 13:42.31 | Imhothar | aye, but in my books if an assert gets triggered, you don't really know if the program is even in a state from which it can safely recover |
| 13:42.39 | ZorbaTHut | yeah, and that's our system too |
| 13:43.21 | ZorbaTHut | although we're defensive enough that *generally* it can, and any crash fix is usually accompanied with "and here's how we prevent it from crashing if this same error somehow occurs again" |
| 13:43.45 | ZorbaTHut | I was actually rather proud of this - I checked in a massive change to shader choice about a month ago, and I've been dealing with probably 1-2 *dozen* new asserts every week |
| 13:43.55 | ZorbaTHut | and not one of them has caused a crash yet |
| 13:44.18 | Torhal | "pres butan" FTW |
| 13:47.58 | hughball | awesome, thanks for the response. is there any reason why i shouldnt pollute addondata and go with globals instead? |
| 13:48.53 | Imhothar | because it takes extra effort to break other addons' private table than it takes to break their globals |
| 13:48.56 | Torhal | Using globals means you're playing in the same sandbox as several someone elses. |
| 13:49.30 | Torhal | If you make a global var named "spoons" and someone else does as well, the behavior is dependent upon which was defined last. |
| 13:49.50 | hughball | certainly. |
| 13:49.53 | Torhal | Plus it's less efficient lookup-wise than using local data. |
| 13:50.49 | hughball | ah, theres a solid reason. |
| 13:51.19 | hughball | because what im doing is totally intense.... right. |
| 13:51.24 | Imhothar | to be honest, the name clashing thing is a much more solid (and important) reason |
| 13:51.31 | ZorbaTHut | imho the performance hit is overstated :V the name clashing is much more important |
| 13:51.51 | ZorbaTHut | when I was working on QH I accidentally used a global that someone else was using and it caused both our addons to completely break |
| 13:54.40 | hughball | yeah, i realize thats the more important item. i just dont run a whole lot of addons and my cruft likely wont be released ;) |
| 13:55.50 | Torhal | I just tend to stay away from it as a dirty aberration from experience in C, C++, C# |
| 13:56.17 | Imhothar | ZorbaTHut one thing I'm starting to do more in my code is to use simple wrapper types with descriptive names. e.g. taking NotNull<X> as argument. It doesn't do any null checking itself but has an explicit constructor, so if anyone has to pass a pointer to the function they see at the call site that there is a contract there they have to adhere to. plus there us zero overhead in a release build |
| 13:56.39 | ZorbaTHut | huh, that's not a bad idea |
| 13:57.35 | ZorbaTHut | there was a great Bungie talk at GDC about how they handle thread synchronization. every task has a list of "permissions", and each global resource request goes through a global resource manager. in debug mode the resource manager does extensive tests to ensure not only that there will be no thread-safety errors, but that there *can* be no thread-safety errors |
| 13:57.55 | ZorbaTHut | in release mode all of that goes away and the resource manager doesn't do any validation whatsoever, but since everything's been tested, everything Just Works |
| 13:58.58 | Imhothar | and it helps with APIs where there are two args with the same type next to each other. instead of calling foo(1, 2) it has to be called with foo(Index(1), Value(2)) |
| 13:59.36 | Imhothar | yeah, heard a similar talk last year at GDC EU about Kill Zone |
| 14:00.19 | ZorbaTHut | some version of unrealscript had it set up so that "index to specific array" was a type - you couldn't use integers as array indices, and there was no generic "array index" type |
| 14:00.30 | Imhothar | where in release builds Ptr<X> is a smart pointer but in release it's just a typedef to X* |
| 14:00.52 | ZorbaTHut | huh, that's clever |
| 14:01.14 | Imhothar | jup, lots of zero-overhead abstractions you can do in C++ that would cost you something in other environments |
| 14:01.37 | ZorbaTHut | for all that c++ is a nightmare of a language, there's a lot of stuff you can do in it that simply is not possible in any other language |
| 14:01.49 | Imhothar | gotta be one reason why I like it so much |
| 14:01.56 | ZorbaTHut | the preprocessor is both the best and worst thing ever invented :V |
| 14:02.07 | Imhothar | amen to that |
| 14:02.17 | ZorbaTHut | have you seen Rust? it's nowhere near production-ready but it's the only language I've seen that threatens to oust C++ in terms of capabilities |
| 14:02.31 | Imhothar | though I tend to not need it anymore with C++11/14. lots of stuff that can be done at language level now |
| 14:02.59 | ZorbaTHut | oh man, rift 3.3 is exciting in that regards |
| 14:03.04 | ZorbaTHut | we just changed to visual studio 2013 :3 |
| 14:03.09 | Imhothar | yay |
| 14:03.13 | Naifu | ZorbaTHut is there a performance difference in using different file formats for textures? DDS vs PNG vs TGA vs JPG ? |
| 14:03.25 | ZorbaTHut | we're not using any of its features yet, but we will be soon |
| 14:03.56 | ZorbaTHut | naifu, DDS is the best-performing all around, and if you want to jump through the hoops to use it, and care about performance enough, it's recommended |
| 14:04.01 | Imhothar | auto, lambdas and rvalue refs are such a game changer |
| 14:04.11 | ZorbaTHut | outside that, load time is going to be the only difference |
| 14:04.16 | Naifu | no problem the source file is dds so that's easy :) |
| 14:04.25 | ZorbaTHut | imhothar, yeah, I so want to use lambdas |
| 14:04.30 | ZorbaTHut | and then there's little things like "override" |
| 14:04.34 | Imhothar | aye |
| 14:04.38 | ZorbaTHut | and nullptr |
| 14:04.53 | Imhothar | devirtualization is finally a thing now |
| 14:04.57 | ZorbaTHut | I checked in my first nullptr a few days back! it felt good :3 |
| 14:05.20 | ZorbaTHut | haven't heard of that, what's devirtualization? |
| 14:05.42 | Imhothar | it's when the compiler can replace a virtual call with a plain call, or even inline it |
| 14:05.56 | ZorbaTHut | oh nice |
| 14:06.02 | ZorbaTHut | I imagine that's pretty restrictive though |
| 14:06.02 | Imhothar | because it can prove the target object is always the same |
| 14:06.08 | Imhothar | it is |
| 14:06.13 | ZorbaTHut | given that the entire point of virtual function calls is that you can't always tell |
| 14:07.01 | Imhothar | wher it works best is: have a base class with an abstract method, derive from it and make the class or function final, then if you cast fr m Base* to Derived* (with an assert on dynamic_cast or something in debug) then there is only one possibly call |
| 14:07.32 | Imhothar | and I know that at least clang will devirtualize these calls |
| 14:07.34 | ZorbaTHut | ahhh, I get it. yeah, that's neat |
| 14:07.52 | ZorbaTHut | didn't consider final as a possible optimization before, clever |
| 14:08.33 | Imhothar | oh, and welcome to "I can return vector by value now, yay"-land :) |
| 14:09.27 | ZorbaTHut | I'll admit that one scares me a little :V |
| 14:09.36 | Imhothar | NRVO is now pretty much more or less mandated by the standard |
| 14:09.37 | ZorbaTHut | one problem is that we don't use STL containers so I'm going to have to add move semantics to our containers |
| 14:09.47 | Imhothar | you have to |
| 14:09.55 | Imhothar | that's like the first thing you should do |
| 14:10.13 | ZorbaTHut | yeah, and that means a *lot* of research to make sure I'm doing it right |
| 14:10.19 | ZorbaTHut | even stuff like operator= has gotchas |
| 14:10.33 | Imhothar | you can even use std::move_if_noexcept to decide whether the move constructor is noexcept or you should properly do a copy instead to be safe |
| 14:10.44 | ZorbaTHut | that's not a concern, we have exceptions disabled anyway |
| 14:11.00 | Imhothar | ugh |
| 14:11.13 | Imhothar | well ok, Rift si still 32 bit |
| 14:11.47 | ZorbaTHut | I don't mind that one myself, I think exceptions are generally bad news |
| 14:11.48 | Imhothar | but the performance argument is pretty much moot with 64bit |
| 14:12.13 | Imhothar | I prefer an exception to an if(foo() == success) cascade any day |
| 14:12.28 | ZorbaTHut | I'd actually prefer the latter, myself - there's just way too many ways to subtly screw up exception handling |
| 14:12.42 | ZorbaTHut | at least the cascade is explicit |
| 14:12.50 | Imhothar | not if you're using RAII they way it is intended |
| 14:12.59 | ZorbaTHut | (although I generally go with a chain of if (foo() == failure) { return; }) |
| 14:13.12 | Imhothar | and measurements show the if-cascade can be a significant slowdown |
| 14:13.13 | ZorbaTHut | as nice of an idea as that is, it's really hard to apply RAII perfectly in all cases |
| 14:14.00 | Imhothar | I just prefer to focus on the success path and let the compiler do the cleanup until somebody in the call chain decides how to handle the error |
| 14:14.44 | Imhothar | do you know Alexandrescu's ScopeGuard11? |
| 14:15.58 | Imhothar | it's pretty neat, works almost like a finally in any block you want |
| 14:16.56 | ZorbaTHut | oh, clever - I figure that works beautifully with lambdas? |
| 14:17.00 | hughball | that does sound neat - im silently listening while makin bacon |
| 14:17.04 | Imhothar | it's based on a lambda |
| 14:17.32 | ZorbaTHut | yeah, I still haven't actually *used* lambdas. I imagine there's lots of neat uses for them I haven't yet noticed |
| 14:17.40 | Imhothar | we have a macro that's used like: FINALLY { do something }; and it always gets run when the scope exits |
| 14:18.28 | Imhothar | so in my code reviews, if I see a try/catch that does nothing but free some resource and re-throw that is something I immediately reject and request that resource to be put in a RAII class |
| 14:18.36 | hughball | does that just save you writing the try block every time or is there something more? |
| 14:18.57 | Imhothar | it has nothing to do with try blocks |
| 14:19.11 | Imhothar | it creates a local object where the destructor calls the lambda |
| 14:20.21 | Naifu | ZorbaThut I found out why the warfront maps show up ... they come from the dialog where you can sign up for warfronts |
| 14:20.30 | ZorbaTHut | naifu, ahhh, that makes sense |
| 14:20.47 | ZorbaTHut | yeah it would not surprise me if maps in general are hidden |
| 14:20.57 | Naifu | :( |
| 14:21.08 | Imhothar | so what the macro does is more like "ScopeGuard<F> someUniqueVariableName{} + [&]" followed by the lambda body |
| 14:21.12 | Naifu | yeah I'm compiling the map files as we speak ... |
| 14:24.25 | hughball | thats interesting. id never heard of raii until this morning... would this have any other applications? |
| 14:24.48 | hughball | forgive my ignorance heh, im a c# dev |
| 14:25.01 | Imhothar | it's one of the pillars of C++ and one reason it's awesome |
| 14:25.06 | ZorbaTHut | RAII is pretty much an artifact of C++'s strong destructor semantics |
| 14:25.09 | ZorbaTHut | and yeah it's absolutely awesome |
| 14:25.30 | ZorbaTHut | I *think* C# has a makeshift version - it's the "using" statement |
| 14:25.39 | Imhothar | yeah |
| 14:25.40 | hughball | c++ was the lang i learned on and was shifted to # |
| 14:25.57 | hughball | gotcha |
| 14:26.07 | ZorbaTHut | but it's a lot more limited in C#. C++ basically allows for superpowerful general using's all over the place |
| 14:26.40 | Imhothar | every block has its own implicit using and for every variable in that scope the desatructor is called when its exited |
| 14:27.16 | Imhothar | works in a function, in a class, heck even in the global scope around main() |
| 14:27.46 | hughball | ive always been told that c++for the fast stuff. wow yeah,thats control. |
| 14:28.11 | Imhothar | that's amyth. C++ doesn't automatically give you performance, it gives you control over performance |
| 14:28.19 | ZorbaTHut | C++ has a level of control over execution and behavior that very few modern languages can match. the downside is that you don't really have the option of *avoiding* that kind of control |
| 14:28.38 | ZorbaTHut | but honestly, dealing with object lifetimes in C++ is nowhere near the problem it used to be |
| 14:28.44 | hughball | thats exaclty right. i remember pointers very fondly... |
| 14:30.17 | hughball | the shift from c++ to c# was an easy transition - everything was basically done for me. i imagine going backnwould be an eye opener |
| 14:30.18 | Imhothar | you always had the option of smart points, with (boost|std)::shared_ptr being your go-to reference counted garbage collector as in any managed language. The thing with C++ is: it's up to you if you use it. In Java/C# you have to |
| 14:30.39 | ZorbaTHut | imhothar, in fairness, while refcounting is easy in C++, full GC isn't |
| 14:30.52 | Imhothar | not with raw pointers, no |
| 14:31.19 | Imhothar | and it doesn't solve retain cycles, but it does its job where it's needed |
| 14:31.28 | ZorbaTHut | yeah, it's the cycles that present the problem |
| 14:31.57 | ZorbaTHut | there are ways of implementing a full GC in C++ but they tend to be painful. UE4, for example, has a massive structure markup layer that does the job |
| 14:32.08 | Imhothar | .NET can handle cycles because it's not *just* ref counted, but e.g. Java and Objective-C have the cycle problem, too |
| 14:32.23 | ZorbaTHut | does java actually not handle cycles? that's sort of disturbing |
| 14:32.25 | ZorbaTHut | even lua handles cycles |
| 14:32.37 | Imhothar | and the .NET GC knows the object layout |
| 14:33.11 | Imhothar | I'm not 100% certain on Java, but the Objective-C runtime has the problem, with the old GC and now with ARC |
| 14:33.28 | ZorbaTHut | yeesh |
| 14:33.34 | ZorbaTHut | I'll happily use both GC'ed and non-GC'ed languages |
| 14:33.38 | ZorbaTHut | but if it's GC'ed I expect it to work properly |
| 14:34.25 | Imhothar | well with ARC every raw object pointer is implicitly a shared_ptr, so it has the same problems and you have to use weak pointers to break cycles |
| 14:34.57 | ZorbaTHut | that's horrible |
| 14:35.23 | Imhothar | a GC just wasn't feasible on a mobile device in 2008 |
| 14:35.42 | ZorbaTHut | still, you'd think it would have been fixed by now |
| 14:35.53 | ZorbaTHut | it's not like zombie orphan cycles are something anyone wants |
| 14:37.06 | Imhothar | well, there is no GC, so no runtime detection. the compiler can't see through your retain cycles |
| 14:37.37 | Imhothar | well clang does warn if it can detect cycles directly |
| 14:37.53 | Imhothar | they didn't even try to fix this with Swift as it uses the same runtime |
| 14:38.15 | hughball | thanks for the variable tips earlier guys - im off to feed the kids. its been good listening. |
| 14:39.18 | ZorbaTHut | cya hugh :) |
| 14:41.43 | Imhothar | any reason you didn't wait for VS15 to get it C++14 feature complete? |
| 14:42.24 | ZorbaTHut | (1) porting to vs15 is now going to be relatively trivial, (2) there are several people on the team who have been burned by brand-new MS compilers, (3) we'd have to wait longer |
| 14:42.46 | ZorbaTHut | the tough part was actually updating our project files - microsoft changed to the msbuild system, with an entire new project file layout, for msvc2010 |
| 14:42.50 | ZorbaTHut | and we were on msvc2008 |
| 14:43.29 | ZorbaTHut | I'd expect we head to vs15 six months or so after its release, though |
| 14:43.46 | Imhothar | hmm right |
| 14:44.04 | Imhothar | I'm pretty excited about the whole Android support deal in VS15 |
| 14:44.16 | ZorbaTHut | hadn't heard about that, nice |
| 14:44.19 | Imhothar | Android Studio and NDK are such a pain |
| 14:44.27 | ZorbaTHut | MS has really changed lately |
| 14:44.31 | ZorbaTHut | interesting times |
| 14:44.44 | Imhothar | so they now include the clang/llvm toolchain for Android in addition to MSVC |
| 14:44.58 | ZorbaTHut | I wonder if they're planning to just change over to clang/llvm entirely someday |
| 14:46.30 | Imhothar | I doubt it, they'd have to port C++/CLI and CX to clang |
| 14:47.16 | Imhothar | you can even debug on android with VS |
| 14:47.57 | Imhothar | which is amazing considering neither Eclipse nor Android Sutdio can reliably debug native code on android |
| 14:48.52 | Imhothar | and they do plan on supporting iOS in some way, which is difficult considering all the restrictions Apple is putting on it |
| 14:49.14 | Imhothar | interesting times to do crossplatform development |
| 14:50.32 | ZorbaTHut | wouldn't entirely surprise me if they were aiming for a slow changeover - maintain the existing compiler but stop developing it, switch over to clang/llvm for new stuff |
| 14:50.49 | ZorbaTHut | but we'll see |
| 14:51.40 | Imhothar | having another compiler in the mix is good for all of us |
| 14:52.39 | ZorbaTHut | agreed. especially a BSD-licensed compiler |
| 14:52.46 | Imhothar | aye |
| 14:53.05 | Imhothar | gcc already improved a lot of its error messages because of clang |
| 14:54.04 | ZorbaTHut | I've started to think that software, in general, progresses from proprietary -> copyleft -> bsd/mit |
| 14:54.26 | Imhothar | copyleft is meh |
| 14:54.39 | Imhothar | a nice idea but doesn't work very well in practice |
| 14:54.42 | ZorbaTHut | I think it's a very important step in getting away from proprietary |
| 14:54.46 | ZorbaTHut | but long-term, doomed |
| 15:36.30 | NuSuey | Midori and I are now BFFs |
| 15:36.49 | NuSuey | damn, wrong channel >.< |
| 15:37.38 | NuSuey | (still .. midori browser > chrome .. that chrome sure steals a LOT of memory) |
| 15:56.47 | ZorbaTHut | I will admit my solution up until now has been "buy more RAM" |
| 15:56.51 | ZorbaTHut | but I tend to be a RAM hog anyway |
| 15:59.34 | Naifu | does a computer actually work with anything less than 16gb? hehehehe |
| 15:59.35 | Imhothar | Skype is using double the RAM of Chrome right now, and it has 5 paused youtube tabs and a twitch stream open. plus other random tabs |
| 16:00.28 | Imhothar | oh wait no, that's just the "app" |
| 16:00.44 | Imhothar | ah yes, this now looks more realistic |
| 16:01.13 | Imhothar | forgot chrome actually has multiple processes |
| 16:01.41 | Naifu | skype should work with low memory I'd think. It's integrated in a number of oldish tv sets |
| 16:07.33 | ZorbaTHut | it's also worth noting that chrome's memory use is misleading |
| 16:07.57 | ZorbaTHut | no OS on the planet does a good job of reporting the memory use of shared libraries, and Chrome, with a ton of processes with a ton of shared libraries, makes extensive use of this |
| 16:08.34 | ZorbaTHut | (in fairness this is partially because it's unclear how such a situation should be reported) |
| 16:10.25 | Naifu | at work we need to work with all kinds of browsers despite IE not sticking to ANY standards they are all about the same IMHO |
| 16:48.06 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 17:12.25 | Repo | nkcartographer: naifu * r18 (3 files in 1 directory): some waypoint related bug fixes |
| 19:55.53 | *** join/#riftuidev borbra (~quassel@grm-s-128-39-202-53.uia.no) |
| 21:17.50 | *** join/#riftuidev hughball (hughball@d66-222-251-47.abhsia.telus.net) |