| 00:01.33 | Ivnedar | I apparently use 1TBS |
| 00:01.51 | Ivnedar | But, I can switch without realising if I'm working on an existing code base and that uses a different style |
| 00:02.13 | Ivnedar | so I apparently go with whatever style is apparent in an existing code base, or default to 1TBS |
| 00:04.52 | seebs | Yeah. |
| 00:05.03 | seebs | My least favorite thing about moai, by far, is that they do: |
| 00:05.08 | seebs | function ( argument, argument ) |
| 00:05.14 | seebs | and the extra spaces drive me nuts. |
| 00:06.12 | Ivnedar | check out the whole code base, run a regex over all the files to strip out the extra spaces, check it all back in with a commit message of "FIXT" |
| 00:07.22 | Ivnedar | I have seen that style used before, but does it have a name? |
| 00:09.24 | seebs | I don't know. |
| 00:09.50 | seebs | I do recall being utterly mystified when I first read a coding standard at $dayjob, but then it turned out that because I'm in the Linux group, we got a dispensation to "conform to community standards" so we're KNF. |
| 00:41.42 | ZorbaTHut | one slightly annoying thing about trion is that every major project has its own coding standard which is almost, but not entirely, compatible with all the others |
| 00:42.00 | ZorbaTHut | although I think Trove finally said "screw it, we're just going to use Rift's standard" |
| 01:53.51 | seebs | That's sort of scary. |
| 01:54.12 | seebs | I have overall ended up with a very positive impression of the Rift team, and an at most mildly-positive impression of Trion Itself. |
| 01:54.20 | seebs | Although the latter has changed radically since Hartsman came back. |
| 01:54.46 | seebs | *sigh* |
| 01:55.16 | seebs | So Windows has this thing it can do sometimes, I don't know how, where an app ends up with a UAC prompt, but for some reason the prompt window ends up behind all other windows and is not actually displayed. And everything seems really weird until I happen to look at the task bar and notice the icon. |
| 01:55.28 | ZorbaTHut | Trion's had an interesting history. For what it's worth, the rest of the company has been pretty thoroughly brought into the culture of the Rift team, so with luck your impression of Trion as a whole will improve. |
| 01:56.37 | ZorbaTHut | Windows has a really complicated chunk of logic regarding when programs are able to claim focus. It's possible a program is popping up a UAC prompt but isn't being allowed to take focus, so it just hangs out in the taskbar until you notice it |
| 01:59.38 | seebs | I've never figured out the rules, but it may have to do with having another app in front; like, the UAC window can only become frontmost if that app is in front. |
| 02:00.15 | seebs | What I've gathered from things I've seen said and things I've inferred is that Trion corporate had a pretty short-term profit-seeking view, and Hartsman has strongly preferred longer-term strategies. |
| 02:00.48 | seebs | At least from my point of view, the *kinds* of changes that show up in Rift's patches these days include a lot of things which I think make no sense at all unless there's a fairly long-term expectation involved. |
| 02:01.08 | ZorbaTHut | yep, that's part of it. if I recall correctly, you can also bring a window to the front if you're a child process of the app in front and the app hasn't been removed from the front since the child process was spawned |
| 02:01.10 | seebs | Lots of short-term hiccups, long-term improved stability. |
| 02:01.30 | ZorbaTHut | I vaguely recall some 5-second time limits as well |
| 02:01.32 | seebs | Ah-hah! I bet that's it. What tends to happen is I run a bunch of launchers at once to get games updated, and then one or two of them UAC and fail. |
| 02:01.43 | ZorbaTHut | ah, yup, that'd do it |
| 02:01.54 | ZorbaTHut | I ran across that when I was writing a crash handler for my projects - I'd spawn the crash handler, then quit |
| 02:02.00 | seebs | I still hate that so many games UAC prompt for updates even when not installed such that they should need it. |
| 02:02.09 | ZorbaTHut | and this didn't work because the parent app would have quit before the crash handler was ready to pop open a window |
| 02:02.12 | seebs | Rift is one of the few games that has never once annoyed me with that. |
| 02:02.22 | ZorbaTHut | so I added a five-second delay between "spawn crash handler" and "quit" :V ah, workarounds |
| 02:02.28 | seebs | Heh. |
| 02:02.57 | ZorbaTHut | yeah, I think we haven't really solved permissions yet |
| 02:03.15 | ZorbaTHut | Unix-style permissions, which is sort of what Windows UAC derives from, makes the assumption that only administrators will install new programs |
| 02:03.21 | ZorbaTHut | but that's just totally invalid with how people use their computers |
| 02:04.10 | ZorbaTHut | people need to be able to install and update new programs of their own without hitting UAC, but simultaneously, you don't want one person's bad choice in program to hit other users on the system. which, right now, it does |
| 02:04.43 | ZorbaTHut | that permission schema basically puts the security gate in a position that is completely counterproductive and pointless for an end-user computer :P |
| 02:04.50 | seebs | My practical solution: I make a directory c:\games, which is owned by the user games, and then that user installs everything in that folder, and I say "no" to any UAC prompts by default. Works for almost everything. |
| 02:05.07 | seebs | My favorite was the ncsoft launcher, which spawned a subprocess to do the UAC prompt. |
| 02:05.20 | seebs | I replaced it with an "int main() { return 0; }" executable, and everything was fine. |
| 02:05.55 | seebs | FF14 prompts and actually *checks* that you accepted the prompt, and if you don't it won't run. DDO and Rift don't prompt unless they actually need to. |
| 02:06.00 | ZorbaTHut | and the entire system is honestly silly on single-user computers because it carefully protects parts of the computer we don't care about - the OS - while leaving everything we do care about, namely, data, completely vulnerable |
| 02:06.33 | seebs | Uh-huh. |
| 02:06.51 | seebs | I've been doing a bunch of secure linux stuff lately, and it's sort of terrifying realizing just how much no clue what's going on is often involved. |
| 02:06.58 | seebs | Also reading security code makes me nervous. |
| 02:07.26 | ZorbaTHut | yeah security code is frightening stuff |
| 02:07.34 | seebs | I was looking at a utility that sets a special kind of password (not a regular system password), and the password entry routine is a single routine that does a for() across an enum of states until it reaches a specified maximum state. |
| 02:07.57 | seebs | Because then it can have you enter the password twice if it's asking for a new one, and just once if it's only trying to read your entry to compare with an existing one, see. |
| 02:08.21 | seebs | Also, the routine that reads the password stashes the hashed password (and then zeroes out the memory that held the unhashed one, yay), and then prints a message saying the password has been saved. |
| 02:08.30 | seebs | Note: This routine does not in fact save or write anything. |
| 02:08.50 | seebs | An entirely different routine calls this one, and then if it reports success, the other routine actually does the write. This is almost certainly very stupid. |
| 02:09.09 | ZorbaTHut | wacky |
| 02:10.40 | seebs | I actually sometimes read this code and conclude that it can't possibly be an accident that it's this bad, it has to be an intentional subversion. |
| 02:10.49 | seebs | Like, even if it's correct, it's intended to be hard to be sure. |
| 02:11.29 | seebs | Oh, hey. |
| 02:11.43 | seebs | Do you want to hear the INSANE story of the bug I spent over a day on recently, which ended up requring something like three lines of code to fix? |
| 02:12.03 | ZorbaTHut | absolutely :D (that's the exact opposite of what I've been doing on Defiance!) |
| 02:12.11 | seebs | Okay, so. |
| 02:12.30 | seebs | I maintain something called pseudo, which works on Linux and OS X, and probably FreeBSD with some patches, which provides emulated-root-access. |
| 02:12.44 | seebs | We do build system, and we have a hard requirement that you must be able to assemble a root filesystem without root access. |
| 02:13.30 | seebs | pseudo's basic design is: You use LD_PRELOAD to cause the pseudo library to be loaded *before* libc. All library calls which involve filesystem access in relevant ways end up being intercepted by the library. It then talks to a server which maintains a database of "real" filesystem modes. |
| 02:13.50 | seebs | So you if you do "chown bob file", the server ends up with a record that the uid on that file is <some other uid>, but no actual chown() call is made. |
| 02:14.15 | seebs | And for chmod(), it's similar, except we do make the chmod() call, but ignore the results in case you made a call that would fail. But we record the values you provided. |
| 02:14.34 | seebs | So. We had a thing happen. The thing was that a particular directory in each package's build directory was ending up with unpredictable modes. |
| 02:14.41 | seebs | The mode might be any of 777, 775, 755, or 700. |
| 02:14.49 | ZorbaTHut | *nod* basically storing your own mirrored copy-on-write view of the filesystem? |
| 02:14.49 | seebs | And this was... not expected. |
| 02:15.11 | seebs | Yeah. Except it only keeps uid, gid, permission and type bits, and these days extended attributes. |
| 02:15.30 | seebs | So, I started looking to try to figure out the mode, and eventually I got a nice simple reproducer for *part* of it. |
| 02:15.45 | seebs | Make a tar archive containing a 777 directory. Untar it, get 777. Untar it under pseudo, get 700. |
| 02:15.48 | seebs | Well. |
| 02:15.53 | seebs | GNU tar has some interesting design choices. |
| 02:16.19 | seebs | First, it handles permissions differently when it's running as root. Specifically, if you're running as root, directories get restored 0700, and then changed later. |
| 02:16.35 | seebs | The change of the mode ends up involving fchmodat(), which is one of the *at() family of syscalls. |
| 02:17.14 | seebs | *at() calls take two extra arguments; a file descriptor for a directory to perform relative to, and a flag which is either 0 or AT_NOFOLLOW_SYMLINK. |
| 02:17.21 | seebs | I am betting you can guess what that flag does. |
| 02:17.45 | seebs | Well, GNU tar has a fascinating comment, observing that on Linux, AT_NOFOLLOW_SYMLINK is not supported for fchmodat(). Which is true. |
| 02:18.12 | seebs | So what GNU tar does is pass AT_NOFOLLOW_SYMLINK in unconditionally no matter what, and if fchmodat() fails and errno is ENOTSUP, then it tries again without the flag if that's appropriate. |
| 02:18.31 | seebs | And when pseudo intercepts the fchmodat() call, it just naively passes the arguments along, then *ignores* any failure mode and claims to have succeeded. |
| 02:18.50 | ZorbaTHut | hah. ouch. |
| 02:19.08 | seebs | Which means that it consistently disregards any mode set by this particular mode-changing routine. But this routine only gets invoked if you are extracting a directory and are root, and I think possibly only if the directory has particular bits set in its mode. |
| 02:19.57 | seebs | So, the solution is, have pseudo check for that error, and indicate it. And also set a static flag and just error out immediately if we get later calls with that flag set, because otherwise we could be doing two IPC messages to the server for each chmod from GNU tar, because they insist on retrying *every single time* just in case. |
| 02:20.32 | seebs | I mean, what happens if the user upgrades to a new kernel which supports a new filesystem type which supports that flag, and the filesystem gets mounted on a mount point in the directory tree you're extracting? You'd want to try the flag again just in case! |
| 02:20.50 | seebs | So, I fix that, and that fixes the 0700. The directory is now consistently coming out with any of 0777, 0755, or 0775. |
| 02:21.21 | ZorbaTHut | I imagine there's a bunch of really hairy nastiness involved in trying to emulate root privileges |
| 02:21.32 | seebs | It turns out, this directory exists to contain other directories, and that the order of operations can change which part of the process is involved when this directory gets created. |
| 02:21.39 | seebs | (Yes, yes there is.) |
| 02:22.07 | seebs | So in one common case, what happens is that you want to create directories for each of a bunch of sub-packages, so the code iterates through making those directories and copying the appropriate files into them. |
| 02:22.15 | seebs | Unfortunately, it does this and *then* creates the parent directory. |
| 02:22.45 | seebs | When copying the files, it is running with umask 0, because it is trying to preserve the modes of the things it's copying, so it's going to do a lot of mkdir() calls where it wants to preserve the exact mode of an existing directory. |
| 02:23.01 | seebs | Which means that when it creates the first subdirectory, the parent directory gets created. With umask 0. And no specified mode. Which defaults to 777. |
| 02:23.22 | seebs | So adding a default to one of the utility functions used to create a directory and any parent directories it may have solves that. |
| 02:24.00 | seebs | The 0755 and 0775 are caused by other paths that allow you to reach similar code which creates that directory, but is running with a different umask for whatever reason. In particular, umask 002 is used when creating the "shared state" archives because those are intended to be shareable. |
| 02:24.25 | seebs | So, after ~8-10 hours of study, I ended up with a two-line change in a Python script, changing (path) to (path, mode = 0755) and (path) to (path, mode). |
| 02:24.33 | seebs | And with about five lines of changes in pseudo. |
| 02:26.16 | ZorbaTHut | I'm never sure if it's disappointing or not when I fix a complicated issue with a tiny number of lines of code |
| 02:26.47 | seebs | In this case, I was pretty happy with it. |
| 02:27.55 | ZorbaTHut | I think my favorite bugfix ever is when I was working on Google Calculator. There was a function intended to parse complex numbers, so that 4+3i would be packaged up sensibly and efficiently |
| 02:28.27 | ZorbaTHut | but the problem is if you wrote, say, 2*4+3i, the complex number parser would run before the actual arithmetic, so it would treat it as 2*(4+3i) |
| 02:28.47 | ZorbaTHut | the funny part was that Google Calculator had "i" as a constant, and it was perfectly able to understand things like "3i" on its own without an added parse step |
| 02:28.57 | ZorbaTHut | so I just deleted the complex number parser and all references to it. |
| 02:29.07 | ZorbaTHut | Zero lines of code added, zero lines of code modified, 44 lines of code removed, bug fixed. |
| 02:31.37 | seebs | That's beautiful. |
| 03:57.34 | Ivnedar | oh man, big argument about style here today |
| 03:57.37 | Ivnedar | totally staying out of that one |
| 03:58.13 | Ivnedar | old school c/unix guy vs new gen puppet guy |
| 03:58.23 | Ivnedar | new guy's teaching old school guy how to do puppet stuff |
| 05:17.15 | ZorbaTHut | puppet? |
| 05:17.36 | Ivnedar | http://puppetlabs.com/ |
| 05:17.39 | Ivnedar | systems automation stuff |
| 05:17.41 | Ivnedar | config management |
| 05:18.11 | ZorbaTHut | huh, neat |
| 06:19.12 | *** join/#riftuidev NuSuey (uid3556@gateway/web/irccloud.com/x-hqotvxsokdtqiwqn) |
| 07:25.55 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 08:18.46 | *** join/#riftuidev Imhothar (~Adium@p5DCD764C.dip0.t-ipconnect.de) |
| 08:22.04 | *** join/#riftuidev Imhothar1 (~Adium@p5DCD764C.dip0.t-ipconnect.de) |
| 09:38.58 | Ivnedar | oh wow, Volt looks awesome |
| 09:39.23 | Ivnedar | new lockbox mount |
| 09:47.03 | ZorbaTHut | dang, that does look pretty sweet |
| 09:47.07 | ZorbaTHut | I wonder how the hair-color sync thing works |
| 09:57.08 | Ivnedar | oh man, electric hair! |
| 09:57.35 | Imhothar1 | this guy really trusts his architect http://bilderparade.langweiledich.net/CCXCIV/LangweileDich.net_Bilderparade_CCXCIV_37.jpg |
| 10:51.51 | *** join/#riftuidev Wildtide (0fe3b94b@gateway/web/freenode/ip.15.227.185.75) |
| 11:27.44 | Wildtide | argh, just done it... used "--" in c#. it's happening again :/ |
| 14:22.55 | *** join/#riftuidev Noshei (~quassel@c-24-9-171-99.hsd1.co.comcast.net) |
| 14:49.21 | ZorbaTHut | writing the addon system was fun in that way - I was often writing C++, Lua, and Actionscript simultaneously |
| 14:49.35 | ZorbaTHut | made it a bit tricky to remember syntax |
| 14:56.01 | Wildtide | lol, i can imagine that was fun... at least i'm ony working on one or the other at a time :) |
| 15:30.46 | *** join/#riftuidev Imhothar (~Adium@p4FC544EA.dip0.t-ipconnect.de) |
| 16:50.13 | *** join/#riftuidev seebs (~seebs@home.seebs.net) |
| 16:50.14 | *** mode/#riftuidev [+o seebs] by ChanServ |
| 16:56.11 | *** join/#riftuidev Imhothar (~Imhothar@ppp-93-104-161-239.dynamic.mnet-online.de) |
| 17:23.55 | *** join/#riftuidev Wildtide (~quassel@host86-139-189-190.range86-139.btcentralplus.com) |
| 17:40.09 | Wildtide | hmm... what would stop an addon appearing in the list in RIFT? |
| 17:40.23 | Imhothar | errors in the toc |
| 17:40.45 | Wildtide | i'll check through it... it's the latest Gadgets repo |
| 17:41.34 | Wildtide | ahhh... i'm missing LibSimpleWidgets, as it's included by the Curse packager |
| 17:41.48 | Wildtide | so missing dependency. that'd do it i suspect |
| 17:42.36 | Wildtide | yep, it's appeared now |
| 17:44.04 | Wildtide | oh dear... many many errors. i think maybe i'd better start from the downloadable zip, and work out what's not in the repo |
| 17:46.11 | Wildtide | my RIFT experience isn't enhanced by the giant spinning moon in the middle of my screen, think maybe i should turn off my sandpit addon :) |
| 17:58.29 | Wildtide | ouch... ZorbaTHut - that addon i sent you is eating 40% cpu (20% processing, 20% rendering) on my machine. it calls SetShape once per frame, which i know is a bad thing to do, but it still seems a little high for what it's doing |
| 20:04.24 | *** join/#riftuidev purl (~purl@rikers.org) |
| 20:04.24 | *** topic/#riftuidev is http://pastebin.com for code snippets || PIL: http://www.lua.org/pil || Rift AddOn Policy: http://t.co/7xXd4LL || AddOn Wiki: wiki.riftui.com/ || this channel is logged, via purl || Happy Pi day! |
| 20:40.41 | *** join/#riftuidev Wildtide_ (~quassel@host86-161-68-105.range86-161.btcentralplus.com) |
