| --- Log opened Fri Sep 18 00:00:03 2009 |
| 00:00 | < Derakon[work]> | I.e. right rotation, minor translational of fset. |
| 00:00 | < Derakon[work]> | Er, offset. |
| 00:00 | <@Vornicus> | Okay. |
| 00:01 | < Derakon[work]> | The generated triangle image wasn't perfect though. |
| 00:01 | <@Vornicus> | "wasn't perfect"? How so? |
| 00:01 | < Derakon[work]> | http://derakon.dyndns.org/~chriswei/temp2/triangles.png |
| 00:01 | < Derakon[work]> | (You may need to clear your cache) |
| 00:02 | < Derakon[work]> | Red: image 1. Green: image 2. Blue: image 2 transformed. |
| 00:02 | < Derakon[work]> | But this may be due to non-perfectly-congruent triangles. |
| 00:02 | <@Vornicus> | What the crap, these numbers should be perfect. |
| 00:03 | <@Vornicus> | Or near to it. |
| 00:03 | <@Vornicus> | Can we try a more dramatic change? |
| 00:03 | | AnnoDomini [farkoff@Nightstar-f6416c3d.adsl.tpnet.pl] has quit [[NS] Quit: (...) By this point, the astute reader has picked up that Nethack isn't a "game" as much as an extremely prolonged and extremely elaborate form of masochism. Ask any serious player.] |
| 00:03 | < Derakon[work]> | Okay, aside from completely failing test #3 (which is probably due to a bug in my validity-of-transformation code or something), the rest all show minor translational offsets. |
| 00:03 | < Derakon[work]> | Sure, what did you have in mind? |
| 00:04 | <@Vornicus> | No, no. |
| 00:04 | < Derakon[work]> | Oh, more dramatic image. |
| 00:04 | <@Vornicus> | Yes |
| 00:04 | < Derakon[work]> | I have a few that have 180? flips. |
| 00:04 | <@Vornicus> | Something closer to 90 would be better. |
| 00:05 | < Derakon[work]> | Nothing like that, no. The images are generally close to aligned already; we aren't just aiming the camera any old way, after all. |
| 00:05 | <@Vornicus> | All right. |
| 00:06 | < Derakon[work]> | This any help? http://derakon.dyndns.org/~chriswei/temp2/triangles2.png |
| 00:06 | <@Vornicus> | Yes. wtf. |
| 00:09 | < Derakon[work]> | I wonder if I have some bug in transformPoint. Mixing up which coefficients are applied to X vs. Y, kinda thing. |
| 00:11 | < Derakon[work]> | Okay, that's better. I switched from (y, x) to (x, y) in a few places and it's tighter. Still not perfect, but tighter. |
| 00:14 | | * Derakon[work] runs his test files, gets beaut results except for that one file, which is junk. |
| 00:14 | < Derakon[work]> | I think we may want to say "Take a better bead image" for that situation. |
| 00:14 | < Derakon[work]> | That does happen sometimes. |
| 00:15 | < Derakon[work]> | Only issue now is that the transformation matrix I'm getting includes some invalid transforms. Specifically, it includes shear, which we don't actually get from these cameras. |
| 00:19 | | You're now known as TheWatcher[T-2] |
| 00:22 | | You're now known as TheWatcher[zZzZ] |
| 00:31 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 00:47 | < KazWork> | gah. Dynamic C's library mechanism is so darn quirky... |
| 00:48 | < McMartin> | Dynamic... C? |
| 00:49 | < KazWork> | Made for some 8-bit sbc's. |
| 00:49 | < KazWork> | http://www.rabbit.com/products/dc/index.shtml |
| 00:50 | < KazWork> | it has .lib files with header and code intermixed, and some boilerplate stuff, but as it compiles it grabs only the bits that it needs from each library. not sure how much of the boilerplate is required to make it function properly. |
| 00:51 | | * KazWork is trying to build his own libraries... :( |
| 00:51 | < KazWork> | or rather, modules. so I can unittest them in this weird compiler. |
| 00:54 | < KazWork> | trying to modularize the web stuff is especially hard with this. |
| 00:54 | < KazWork> | so many tricks done with #defines... |
| 00:55 | < KazWork> | the comments appear to be required and significant... heh |
| 01:01 | < KazWork> | cool, that seemed to work... |
| 01:03 | < KazWork> | anything starting with /*** is significant to their preprocessor, so I've put those in my template. :) |
| 01:05 | < gnolam> | Argh. Class naming angst. |
| 01:06 | < gnolam> | The class mostly provides a thin wrapper over SDL, so "SDLWrapper" would be the obvious choice... but it also has to init some other stuff (mainly: GLEW). |
| 01:07 | < McMartin> | "GraphicsEngine" |
| 01:07 | < McMartin> | Or just "Graphics"~ |
| 01:07 | < McMartin> | Or if you're also doing event handling etc, maybe "UI" |
| 01:07 | < gnolam> | Ah! I thought about something like that as well. But it also gets to handle sound playback. :) |
| 01:08 | < gnolam> | (And timing, etc. Everything that would otherwise require a non-portable API call.) |
| 01:08 | < McMartin> | "CompatLayer" |
| 01:09 | < gnolam> | Hmm. Good enough. Thanks! |
| 01:11 | < gnolam> | Now, to Singleton or not to Singleton, that is the question... |
| 01:20 | | Finale [c0cb88fe@Nightstar-14e5d099.mibbit.com] has quit [[NS] Quit: lata] |
| 01:28 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Client closed the connection] |
| 02:00 | | * McMartin reboots like a dozen times so as to test his new bugfixes. |
| 02:26 | | GeekSoldier [Rob@Nightstar-e86e3e0d.ip.cablemo.net] has joined #code |
| 02:44 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 02:54 | | Attilla [The.Attilla@FBC920.642D35.FA4C32.0AF6BA] has quit [[NS] Quit: ] |
| 03:01 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 03:39 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has quit [Client closed the connection] |
| 03:48 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 03:50 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 03:50 | | mode/#code [+o Vornicus] by Reiver |
| 05:01 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 05:12 | | Derakon[AFK] is now known as Derakon |
| 06:13 | | Derakon is now known as Derakon[AFK] |
| 06:41 | | Moon [mahi.way80@3CF3A5.86AC73.A27C0D.1673AF] has joined #code |
| 06:41 | < Moon> | hi reveithia |
| 06:44 | | Moon [mahi.way80@3CF3A5.86AC73.A27C0D.1673AF] has quit [[NS] Quit: ] |
| 07:33 | | AnnoDomini [farkoff@Nightstar-f6416c3d.adsl.tpnet.pl] has joined #code |
| 07:33 | | mode/#code [+o AnnoDomini] by Reiver |
| 08:52 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 08:53 | | AnnoDomini [farkoff@Nightstar-f6416c3d.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 08:59 | | AnnoDomini [farkoff@Nightstar-11878314.adsl.tpnet.pl] has joined #code |
| 08:59 | | mode/#code [+o AnnoDomini] by Reiver |
| 08:59 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Client exited] |
| 09:42 | | You're now known as TheWatcher |
| 10:24 | | Attilla [The.Attilla@FBC920.642D35.FA4C32.0AF6BA] has joined #code |
| 10:24 | | mode/#code [+o Attilla] by Reiver |
| 11:25 | | AbuDhabi [farkoff@Nightstar-11878314.adsl.tpnet.pl] has joined #code |
| 11:25 | | AnnoDomini [farkoff@Nightstar-11878314.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 11:44 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Client closed the connection] |
| 12:45 | | AbuDhabi [farkoff@Nightstar-11878314.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 12:51 | | AnnoDomini [farkoff@Nightstar-907fdb59.adsl.tpnet.pl] has joined #code |
| 12:51 | | mode/#code [+o AnnoDomini] by Reiver |
| 13:31 | | AnnoDomini [farkoff@Nightstar-907fdb59.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 13:32 | | AnnoDomini [farkoff@Nightstar-907fdb59.adsl.tpnet.pl] has joined #code |
| 13:32 | | mode/#code [+o AnnoDomini] by Reiver |
| 13:57 | | * gnolam WTFs at OpenGL. |
| 13:57 | < TheWatcher> | ? |
| 14:01 | < gnolam> | It appears to have something against me using GL_RGB instead of GL_RGBA in a call to glTexImage2D(). |
| 14:02 | | AnnoDomini [farkoff@Nightstar-907fdb59.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 14:03 | | * gnolam blarghs, uses the extra byte. |
| 14:07 | | AnnoDomini [farkoff@Nightstar-d9946fa8.adsl.tpnet.pl] has joined #code |
| 14:07 | | mode/#code [+o AnnoDomini] by Reiver |
| 14:08 | | AnnoDomini [farkoff@Nightstar-d9946fa8.adsl.tpnet.pl] has quit [[NS] Quit: Some people find sanity a little confining.] |
| 14:13 | | AnnoDomini [farkoff@Nightstar-d9946fa8.adsl.tpnet.pl] has joined #code |
| 14:13 | | mode/#code [+o AnnoDomini] by Reiver |
| 14:18 | < gnolam> | Mmm, magenta/yellow checkerboard skybox... |
| 14:19 | | * gnolam is testing the "resource not found" behavior of his resource manager. |
| 14:25 | < gnolam> | I'm tempted to use "Damn the torpedoes, full speed ahead!" as the log message whenever it creates an error texture in response to a non-existent resource. |
| 14:32 | | SmithKurosaki [Smith@Nightstar-82ad4434.dsl.teksavvy.com] has quit [Connection closed] |
| 14:40 | | SmithKurosaki [Smith@Nightstar-82ad4434.dsl.teksavvy.com] has joined #code |
| 14:41 | | SmithKurosaki [Smith@Nightstar-82ad4434.dsl.teksavvy.com] has quit [[NS] Quit: Leaving] |
| 14:48 | | AnnoDomini [farkoff@Nightstar-d9946fa8.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 14:49 | | AnnoDomini [farkoff@Nightstar-d9946fa8.adsl.tpnet.pl] has joined #code |
| 14:49 | | mode/#code [+o AnnoDomini] by Reiver |
| 15:06 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 15:06 | | mode/#code [+o ToxicFrog] by Reiver |
| 15:24 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has joined #code |
| 15:25 | | SmithKurosaki [Smith@Nightstar-82ad4434.dsl.teksavvy.com] has joined #code |
| 15:26 | | Reivthia [Orthianz@Nightstar-41e7b4f2.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 16:07 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 16:07 | | mode/#code [+o Syloqs-AFH] by Reiver |
| 16:13 | | Derakon[code] [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 16:43 | | * Derakon[code] reflects on the Gaussian elimination approach Vorn suggested yesterday. |
| 16:43 | < Derakon[code]> | The problem here is that certain transformations are not allowed as they shouldn't be happening in the actual images. |
| 16:43 | < Derakon[code]> | Those being shear and non-square scaling. |
| 16:49 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has quit [Client closed the connection] |
| 16:52 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has joined #code |
| 16:56 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has joined #code |
| 17:00 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 17:02 | <@Vornicus> | hmng. |
| 17:03 | <@Vornicus> | You can just, you know, reject shear and non-square ones - though I'd do that with an epsilon. |
| 17:04 | < Derakon[code]> | To do that I need to be able to extract the transformation parameters from the matrix so I can examine them. But AFAICT they get entangled to the degree that this isn't possible. |
| 17:04 | < Derakon[code]> | E.g. if there were only square scaling, then I could get the rotation by comparing the ratio of [0][0] and [1][1]...but there isn't, necessarily. |
| 17:08 | < Derakon[code]> | (This brings up a secondary issue, that the expected output from this progarm is in fact a set of individual transformation parameters, not a transformation matrix...but that may be fungible) |
| 17:08 | < Derakon[code]> | (I haven't looked at how the parameters are used yet) |
| 17:14 | < gnolam> | http://www.telltalegames.com/playlikeapirate |
| 17:22 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has quit [Client closed the connection] |
| 17:25 | | * Derakon[code] heads off to poke at the microscope some. |
| 17:37 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has joined #code |
| 17:56 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has quit [Client closed the connection] |
| 18:01 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 18:04 | | Syloqs-AFH [Syloq@NetworkAdministrator.Nightstar.Net] has joined #code |
| 18:04 | | mode/#code [+o Syloqs-AFH] by Reiver |
| 18:10 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has joined #code |
| 18:15 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Ping timeout: 121 seconds] |
| 18:15 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 18:16 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has quit [Client closed the connection] |
| 18:21 | | Netsplit *.net <-> *.split quits: KazWork, @Vornicus, @Attilla, SmithKurosaki, dmlandrum |
| 18:21 | | Netsplit over, joins: dmlandrum, @Attilla, KazWork, @Vornicus, SmithKurosaki |
| 18:24 | | Orthia [Orthianz@Nightstar-1f2c6569.xnet.co.nz] has joined #code |
| 18:26 | | Finale [c0cb88fe@Nightstar-14e5d099.mibbit.com] has joined #code |
| 19:01 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has quit [Client closed the connection] |
| 19:08 | | crem [moo@Nightstar-8ca3eea7.adsl.mgts.by] has joined #code |
| 20:11 | | * gnolam ...s. |
| 20:12 | < gnolam> | Got a spam e-mail from one of those sites that basically hijack people's accounts to send mails to everyone on their contact list... from a friend who used to work in infosec. |
| 20:39 | | * TheWatcher /point, /laugh |
| 20:40 | | * Finale /pointer /redirect /shiftyeye |
| 20:42 | | You're now known as TheWatcher[afk] |
| 20:49 | | Derakon[code] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [Operation timed out] |
| 21:14 | | Finale is now known as Nathia |
| 21:34 | | Derakon [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 21:34 | | mode/#code [+o Derakon] by Reiver |
| 21:34 | | Derakon is now known as Derakon[work] |
| 21:34 | <@Derakon[work]> | Thanks, Reiv. |
| 21:34 | | mode/#code [+o Derakon[AFK]] by Derakon[work] |
| 21:39 | | * Derakon[work] mutters at this bug. |
| 21:40 | <@Derakon[work]> | The microscope program is crashing when it runs this line: |
| 21:40 | <@Derakon[work]> | X.f_mrc_hdr.Num = wx.GetApp().getNX(), wx.GetApp().getNY(), nZ*nTimes*nw |
| 21:40 | <@AnnoDomini> | Can you narrow that down further? |
| 21:40 | <@Derakon[work]> | From logging, it looks like trying to calculate the multiplication is crashing...except I can log all three inputs without trouble. |
| 21:40 | <@Derakon[work]> | Their values, in this case, being 0, 1, and 1. |
| 21:41 | <@Derakon[work]> | If I try to log their product, though, *boom* |
| 21:43 | <@AnnoDomini> | Have you tried the product of two of them? |
| 21:43 | <@Derakon[work]> | No, I haven't. |
| 21:44 | <@Derakon[work]> | But I did try casting them to ints and storing those values back in the variables...no good. |
| 21:50 | | * McMartin finds his first totally egregious bug in Vista. |
| 21:50 | <@ToxicFrog> | ? |
| 21:51 | < McMartin> | If UAC is disabled, you are non-admin, and you pick something as "run as administrator", you don't. |
| 21:52 | <@Derakon[work]> | It silently refuses to run? |
| 21:52 | < McMartin> | No, it runs it, but as non-administrator. |
| 21:52 | < Nathia> | lol |
| 21:52 | <@Derakon[work]> | Oh. |
| 21:52 | <@Derakon[work]> | No warning or anything, eh? |
| 21:52 | < McMartin> | If you wanted warnings for anything, you'd have UAC on~ |
| 21:52 | <@Derakon[work]> | Heh. |
| 21:52 | < Namegduf> | s/anything/everything/ |
| 21:53 | < McMartin> | It's either gotten better since launch or I just don't use my system in such a way that I have to sudo every third command. |
| 21:54 | < Namegduf> | It got better since early RCs. |
| 21:54 | < Namegduf> | Where it was really bad. |
| 21:54 | < McMartin> | I have to wonder how much of that is people learning to use the security model right, actually. |
| 21:54 | < McMartin> | I've been doing development for Win32 at work for some time, and this is the first "Vista Problem" we've had that is clearly Vista's fault and not our own for being lax about authentication tokens and such |
| 21:55 | < McMartin> | (In Windows 7, this actually works *exactly* like sudo, and "Administrator Group" isn't a set of people with root privileges, but is instead a group of people with sudo privileges. |
| 21:55 | < Namegduf> | To be honest, I think any security model based on making special-cased folders (Program Files) and such isn't particularly strong. |
| 21:55 | < Namegduf> | Or robust. |
| 21:55 | < Namegduf> | It might be fine overall, I guess. |
| 21:55 | < McMartin> | I'm talking about the authentication tokens and such, which is pretty close to OSX and *I think* SELinux. |
| 21:56 | < McMartin> | The "this thing here is magic and accounts XYZ can't mess with it" sounds more like the XP model that Vista was trying to break. |
| 21:57 | < Namegduf> | Vista's the one that introduced "Program Files" as a magic location. |
| 21:57 | <@Derakon[work]> | Wasn't that in an attempt to prevent XP-style apps from just putting their files any old place? |
| 21:57 | <@Derakon[work]> | Without actually breaking those apps? |
| 21:57 | < McMartin> | Magic, or just owned by someone highly privileged? |
| 21:58 | < McMartin> | I mean, /usr/bin is a magic location, after all. |
| 21:58 | < Namegduf> | "magic"; programs installed outside of there can write to their own directories, programs in it cannot. |
| 21:58 | < Namegduf> | And no, /usr/bin isn't. |
| 21:58 | < Namegduf> | You can adjust PATH and put it somewhere entirely different. |
| 21:58 | | * Derakon[work] heads back to bang on the microscope software some more. |
| 21:58 | < Namegduf> | GoboLinux does it. |
| 21:59 | < Namegduf> | (/System/Links/Executables) |
| 21:59 | < McMartin> | There's an env var for Program Files as well; it's how NSIS gets its default install location. |
| 21:59 | < McMartin> | That said, if you're a random user, programs installed to /usr/bin generally can't write there, while ones installed to ~/bin write to ~/bin. |
| 21:59 | < Namegduf> | There's still no reason that env var should have special-cased security stuff. |
| 22:00 | < McMartin> | The behavior you describe is however still expressible using standard ACL rulse. |
| 22:00 | < McMartin> | *rules |
| 22:00 | < Namegduf> | Except you can't change it. |
| 22:00 | < Namegduf> | You can't give programs the ability to write to their own directories. |
| 22:01 | < McMartin> | Programs don't write things; users do. |
| 22:01 | | * Namegduf headdesks. |
| 22:01 | < Namegduf> | If it is an ACL. |
| 22:01 | < Namegduf> | It is an unalterable ACL. |
| 22:01 | < McMartin> | I'm actually kind of serious; I haven't heard of this and if there's a doc on it somewhere I'd like to see it~ |
| 22:01 | < Namegduf> | This... would also count as special casing of the directory. |
| 22:02 | <@ToxicFrog> | Namegduf: but root can write to program files, no? |
| 22:02 | < McMartin> | TF: Side note: "Administrator" is the *second* highest access level in the Windows system. |
| 22:02 | < Namegduf> | ToxicFrog: What root? |
| 22:02 | < Nathia> | what's first? |
| 22:02 | < Namegduf> | System? Maybe. |
| 22:02 | < McMartin> | "SYSTEM". |
| 22:02 | < McMartin> | Yeah. |
| 22:02 | < Nathia> | pft. |
| 22:02 | <@ToxicFrog> | root-equivalent, then. |
| 22:02 | < McMartin> | SYSTEM is broken as Hell in XP, and Vista/W7 fix that so that it's worthier of the name. |
| 22:02 | < Nathia> | but you can't log in as system. |
| 22:02 | <@ToxicFrog> | If so, I'm not sure how this is different from "normal users can write to ~/ but not to /usr" |
| 22:02 | < Nathia> | all you can do is ask system to run something. |
| 22:03 | <@ToxicFrog> | ...actually, wait, yes I am |
| 22:03 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [Operation timed out] |
| 22:03 | < McMartin> | This is, I think, "wheel can't sudo a command to change permissions on /usr/bin" |
| 22:03 | <@ToxicFrog> | Aah. |
| 22:04 | < Namegduf> | A mixture of that, and "You can't change it on a per-directory basis. |
| 22:04 | < Namegduf> | You can't for /usr/bin either, but that would be because it doesn't *have* subdirectories. |
| 22:04 | < McMartin> | That I'm not convinced of, but I think it might require writing a custom Windows service. |
| 22:04 | < Namegduf> | Ew. |
| 22:05 | <@ToxicFrog> | I think part of the issue here is that in *nix, programs conventionally put their stuff in $HOME, whereas in windows, they put it in `dirname $0` |
| 22:05 | < McMartin> | TF: Which changed in XP, to %APPDATA%. |
| 22:05 | <@ToxicFrog> | McMartin: which relatively few programs actually use~ |
| 22:05 | < Namegduf> | s/changed/was supposed to change/ |
| 22:05 | < McMartin> | Which is by default on XP C:\Documents and Settings\$Username\Application Data |
| 22:06 | < McMartin> | And changed to Vista to the much superior C:\Users\$Username\AppData |
| 22:06 | < Namegduf> | Even if it was only a default setup, the results of the setup is that programs installed in Program Files get special rules compared to those outside of it. |
| 22:06 | < Namegduf> | Yeah, Vista's setup there is better. |
| 22:06 | <@ToxicFrog> | In particular, no pre-XP program does, and a highly unscientific survey of my game collection indicates that a minority of post-XP programs do. |
| 22:06 | < McMartin> | This is true enough, though I'm doing my part for the crusade~ |
| 22:07 | < McMartin> | There's also a weird interaction between %APPDATA% and %LOCALAPPDATA% and I'm not super clear on the difference. |
| 22:07 | | * McMartin doesn't Get roaming profiles. |
| 22:07 | < McMartin> | TF: Hilariously, pre-XP programs *can* use %APPDATA% but it ends up inside of C:\WINDOWS |
| 22:08 | < Namegduf> | So... anything that relies on the program being uneditable fails if the program's path is changed to install outside of Program Files. |
| 22:08 | <@ToxicFrog> | ahahahaha |
| 22:08 | < McMartin> | (In a subdir, but still, wtc) |
| 22:08 | < McMartin> | Actually, that may be only Win9x. |
| 22:08 | <@ToxicFrog> | Namegduf: I would say the bigger problem is the converse; anything that relies on `dirname $0` being writable (ie, most things) breaks if you install it to the default location. |
| 22:08 | < Namegduf> | ToxicFrog: That's practically the bigger issue, yeah. |
| 22:09 | < McMartin> | I agree with TF; the former is only important for security guarantees. |
| 22:09 | < Namegduf> | It breaks 'nice' things like program automatic updating. |
| 22:09 | < Namegduf> | McMartin: I'd say breaking security guarantees is a pretty big flaw in a security model. |
| 22:09 | <@ToxicFrog> | And like save files and program configuration... |
| 22:09 | < McMartin> | Autoupdate I know for a fact is doable, because we do, and it works on Vista and W7. |
| 22:09 | < Namegduf> | Save files and configuration *can* go in APPDATA. |
| 22:09 | <@ToxicFrog> | Namegduf: yes, but my point is that in most programs they don't. |
| 22:09 | < Namegduf> | AUtomatic updates *can't* if they need to write to Progam Files unless they have a service. |
| 22:10 | < Namegduf> | ToxicFrog: I know; my point is that even for programs doing the 'right thing', it causes issues. |
| 22:10 | <@ToxicFrog> | For updates, isn't the answer just to sudo the updater? |
| 22:10 | < Namegduf> | Yeah; annoying as hell for background updates, though. |
| 22:11 | < Nathia> | know what I hate? when the updater is also the installer and the launcher. |
| 22:11 | < Namegduf> | Since they're no longer entirely possible; you have to download the update, then request permission to install it. |
| 22:11 | < Nathia> | and even more so when it actually launches you to a website and THEN you can launch from there. |
| 22:11 | <@ToxicFrog> | Frankly I don't want things updating themselves behind my back anyways~ |
| 22:11 | < Namegduf> | (This would cause Chrome, for example, issues, if it actually lived in Program Files, which AFAIK it doesn't) |
| 22:11 | < Namegduf> | ToxicFrog: I got an interesting view on that from the Chromium people, actually. |
| 22:11 | < Namegduf> | ToxicFrog: Their goal is to make sure outdated versions *don't* exist and not to allow people to put in website hacks for them. |
| 22:12 | < Namegduf> | ToxicFrog: They said something about not deliberately exposing any easy version number in one place, for example. |
| 22:12 | < Namegduf> | (I don't remember the details) |
| 22:12 | <@ToxicFrog> | Ummmmm |
| 22:12 | < McMartin> | 14:10 <@ToxicFrog> For updates, isn't the answer just to sudo the updater? |
| 22:12 | < McMartin> | Yes, more or less. |
| 22:13 | <@ToxicFrog> | As far as not letting old versions exist goes: the fuck? |
| 22:13 | < McMartin> | That said, our updater has the various manifest options that say "I need to run privileged" |
| 22:13 | < Namegduf> | ToxicFrog: They want to avoid the need for web developers to support older versions than the newest and most bugfixed, I assume. |
| 22:13 | <@ToxicFrog> | This works only as long as each release works on/for a [super]set of what the previous one did. |
| 22:13 | < McMartin> | Windows has a wacky half-setuid bit, where it runs as another user but you have to auth as that user to run it. |
| 22:14 | < Namegduf> | That's true. |
| 22:14 | < McMartin> | s/user/group/g |
| 22:14 | <@ToxicFrog> | I've had my fill of projects where some release drops support for something useful, or is just broken in some manner, and the official response is "suck it up" or in some cases "well, maybe you can get the old installer from archive.org" |
| 22:14 | < McMartin> | NSIS sets that up more or less by default, and as such, maybe that's why it can write to Program Files without difficulty? |
| 22:14 | < Namegduf> | Ah, that thing. |
| 22:14 | <@ToxicFrog> | Most recently grub. |
| 22:14 | < McMartin> | Fucking grub |
| 22:15 | < McMartin> | They aren't even supporting their current release |
| 22:15 | < Nathia> | ... |
| 22:15 | <@ToxicFrog> | "hey, let's only support grub2 even though it's still in alpha and doesn't fucking boot on any computer I own" |
| 22:15 | < Namegduf> | Eurgh, yeah. |
| 22:15 | <@ToxicFrog> | "and everything except ubuntu9 is still using grub-legacy" |
| 22:15 | < Namegduf> | GRUB are annoying. |
| 22:15 | < Namegduf> | Er... the project, I mean. |
| 22:15 | <@ToxicFrog> | And this is why I'm using syslinux for my USB stick` |
| 22:15 | | You're now known as TheWatcher |
| 22:15 | < McMartin> | Namegduf: Anyway, before we got sidetracked |
| 22:16 | <@ToxicFrog> | (which still doesn't boot on my laptop, but appears to work on everything else) |
| 22:16 | < McMartin> | Do you know if there's a "feature name" for this Program Files thing? I haven't actually gotten stung by it yet and I'm now kind of concerned |
| 22:17 | < Namegduf> | McMartin: I don't think so; it looks like you can theoretically alter the ACL, so it's only "broken" for anything relying on it for any actual security by default. |
| 22:17 | < McMartin> | Yeah, thinking about it more, every installer ever can write to Program Files without difficulty~ |
| 22:17 | < McMartin> | So it can't be that strong a security setup |
| 22:17 | < Namegduf> | Right; they sudo. |
| 22:18 | < Namegduf> | (Or, rather, they do the equivalent) |
| 22:18 | < McMartin> | Yeah |
| 22:18 | < McMartin> | I don't really have an issue with that, tbh, but yeah, they need the split between (equivalents of) /usr/bin, /usr/share, and ~ |
| 22:18 | < Namegduf> | The annoyance is that you need to sudo to write to any folder there, including ones you created/installed, but this isn't true elsewhere. |
| 22:18 | < Namegduf> | Yeah, that'd be helpful. |
| 22:19 | | * McMartin blinks as he remembers something |
| 22:19 | < Namegduf> | Programs in *nix that have their own subdirectory in /usr/bin (for some BIZARRE reason) could write to it. |
| 22:19 | < McMartin> | ... I think Vista *does* have a /usr/share equivalent. |
| 22:19 | < McMartin> | God knows if anyone actually uses it. |
| 22:19 | < McMartin> | I think there's a C:\AppData though |
| 22:19 | < Namegduf> | Weird. |
| 22:19 | < Namegduf> | Interestingly, GoboLinux has a "Program Files" directory, with no such special rules. |
| 22:19 | | * McMartin goes to hunt up a Vista machine. |
| 22:19 | < Namegduf> | /Programs/ |
| 22:20 | < McMartin> | That sounds a lot like OS X's /Applications |
| 22:20 | < Namegduf> | Everything installs into there, with /Programs/ProgName/Version/bin and similar subdirectories. |
| 22:20 | < McMartin> | Which is world-writable, but most subdirs are not |
| 22:20 | < Namegduf> | Other way around for Gobo. |
| 22:20 | | * TheWatcher blinks |
| 22:21 | < Namegduf> | /Programs/ is root-writable-only, as is the default state for most everything, but programs that have writable subdirectories work fine. |
| 22:21 | < Namegduf> | /Programs/ProgName/Version/var (might or might not be called that) is the obvious example. |
| 22:21 | < McMartin> | Any user can drag a program into /Applications to install it globally in OS X. |
| 22:21 | < Namegduf> | That is odd. |
| 22:21 | < McMartin> | I think. Maybe it's only group-writable by wheel (read: every power user) |
| 22:22 | < Namegduf> | I guess it's not a harmful thing as described. |
| 22:22 | < McMartin> | I'm pretty sure that substitution attacks can't be done against protected subdirs. |
| 22:22 | < Namegduf> | I mean, all they're technically doing is making something readable and executable by other users as well as themselves. |
| 22:23 | < Namegduf> | But... yeah, seems pointless to put special ACL rules on that directory when it's not guaranteed things will be there or not. |
| 22:23 | < Namegduf> | Doesn't really provide any useful security guarantees. |
| 22:24 | < Namegduf> | It's undoubtably an *improvement*, but the previous state was *terrible*. |
| 22:28 | < McMartin> | Pretty much. |
| 22:28 | < McMartin> | Though actually, an installer can protect any directory it wants, I think, so if they were aware of it they could make it better. |
| 22:28 | < Namegduf> | Hmm, that's true. |
| 22:28 | < McMartin> | (Really, though, if you want security, I believe the official approach is actually "use code signing") |
| 22:32 | < McMartin> | But yeah, this aside, every other problem we've had with Vista has been "oh. People figuring uot how to actually do stuff in the new model and actually doing it is probably 80% of why W7 is sucking way less than Vista" |
| 22:39 | < gnolam> | I wouldn't mind Vista if it only had a working goddamned explorer. |
| 22:53 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #code |
| 22:53 | < Derakon[work]> | This is really feeling like a memory corruption bug. >.< |
| 22:54 | < Derakon[work]> | The code is filling in data fields in a class instance. Just straight assignments. |
| 22:54 | < Derakon[work]> | If I copy out the line that's crashing, a line later on will crash instead, with the two having nothing in common except that they're assigning to a field in the class instance. |
| 22:54 | <@AnnoDomini> | Put DEADBEEF in memory. |
| 22:54 | < Derakon[work]> | This is Python. |
| 22:55 | < Derakon[work]> | It's not supposed to be able to get corrupt memory. |
| 22:55 | <@AnnoDomini> | It's ALL Python? |
| 22:55 | < gnolam> | Type incompatibility? |
| 22:56 | < Derakon[work]> | This particular version is Python wrapped by a C++ container program, but another version that's pure Python reportedly has the same bug. |
| 22:56 | < TheWatcher> | Retrograde mercury~ |
| 22:56 | < Derakon[work]> | I haven't gotten the other version running yet (it's rather out of date in many ways) to check that, mind. |
| 22:57 | < TheWatcher> | I'm no python person, so this may be a dumb question, but there's no way to run it in a debugger and stick watches on the relevant bits? |
| 22:57 | < Derakon[work]> | Gnolam: if it were something that Python could catch, it'd be getting caught. |
| 22:57 | < Derakon[work]> | TW: there may be a Python debugger; I don't know of one personally. |
| 22:58 | < Derakon[work]> | There'd probably be issues with the C++ wrapper program though. |
| 22:58 | < Derakon[work]> | More importantly, the code doesn't crash every time. I can pretty consistently get it to crash after a few dozen loops. |
| 22:58 | < Derakon[work]> | But it's variable. Sometimes it makes it all the way through an experiment. Sometimes it crashes on the first go. |
| 22:59 | < TheWatcher> | ugh |
| 23:04 | < Derakon[work]> | Oh, question -- is there a Python pretty-printer that treats class instances as dicts? I.e. lets me print out the contents of a class without needing it to have a __str__ or __repr__ implementation? |
| 23:11 | <@Vornicus> | I think .__dict__ will do that. |
| 23:14 | < Derakon[work]> | Ahh, yes, that does work. Danke. |
| 23:16 | | * jerith wrote epic hax in Python today. |
| 23:16 | < TheWatcher> | Oh? |
| 23:16 | < Derakon[work]> | Do tell. |
| 23:17 | | * gnolam assembles the bards. |
| 23:17 | < TheWatcher> | pft |
| 23:17 | | Namegduf [namegduf@37647E.DB45F1.609B34.8CB351] has quit [Client closed the connection] |
| 23:17 | < McMartin> | (In passing; I went to a vista machine and opened up the ACL lists for Program Files; it's got all kinds of restrictions, and there's some kind of weird bypasser for detected installers, too.) |
| 23:17 | < McMartin> | (So now I don't know wtf) |
| 23:17 | <@jerith> | return globals()[record_type+'Record'](domain_name, api=None, rr=rr, **record_data) |
| 23:18 | < Derakon[work]> | :( |
| 23:18 | < TheWatcher> | ~o/Bravely rode Sir jerith, rode forth from Camelot/o~ ¬¬ |
| 23:18 | <@jerith> | That's a refactoring I chased my tail on for ages. |
| 23:18 | <@jerith> | I really wanted to write this code as a matrix. |
| 23:19 | <@jerith> | N operations on M kinds of record. |
| 23:19 | < Derakon[work]> | If I read that properly, you have a bunch of functions that are named "fooRecord", "barRecord", etc., and you want to call the appropriate one given "foo", "bar", etc. |
| 23:19 | <@jerith> | Each cell needs to be different. |
| 23:19 | <@jerith> | Derakon[work]: Correct. |
| 23:19 | < Derakon[work]> | Why couldn't you use a dictionary for this? |
| 23:20 | < Derakon[work]> | recordTypeToFunctionMap = {"foo" : fooRecord, "bar" : barRecord} |
| 23:20 | < Derakon[work]> | Then do recordTypeToFunctionMap[record_type](args) |
| 23:20 | <@jerith> | Because then I'd need Yet Another Dict. |
| 23:20 | < Derakon[work]> | Better than invoking globals(), IMO. |
| 23:21 | <@jerith> | This replaces a nested dict full of lambdas. |
| 23:21 | < Derakon[work]> | Well, that sounds like an improvement, yes. |
| 23:22 | < Derakon[work]> | I'd still rather avoid invoking globals() if possible. |
| 23:22 | <@jerith> | I already need to declare FooRecord twice. Doing it a third time would push the code past my DRY threshold. |
| 23:22 | <@jerith> | This is a pretty limited usage. |
| 23:22 | < Derakon[work]> | Twice? |
| 23:23 | < Derakon[work]> | Where's the second declaration you have to do? |
| 23:24 | <@jerith> | The first is the class. The second is where I hook it up to the backend. |
| 23:24 | <@jerith> | Well, backer-end. This is already pretty backend stuff. |
| 23:24 | < Derakon[work]> | Heh. |
| 23:26 | < Derakon[work]> | ...from a discussion on the amount of data being generated by a telescope array (1 exabyte per day): "Or to put it into numbers that the RIAA can understand: 1.5707309 * 10^9 music CDs every single day. At 15 pieces of music per CD and $80,000/song that's $1.88 * 10^15 dollars/day flowing through that network. That's 632 times larger than the US federal budget for 2008." |
| 23:26 | < Derakon[work]> | "No wonder the music industry is in trouble!" |
| 23:27 | <@jerith> | And from the third-party library this wraps: |
| 23:27 | <@jerith> | classname = element.tag |
| 23:27 | <@jerith> | # Define a new class. |
| 23:27 | <@jerith> | cls = classobj(classname, (object,), {} ) |
| 23:27 | <@jerith> | obj = cls() |
| 23:27 | < Derakon[work]> | You're instantiating classes based on XML tags? |
| 23:27 | <@jerith> | They are. |
| 23:27 | < Derakon[work]> | Well, so long as they're making certain that only valid classnames are picked... |
| 23:28 | <@jerith> | Turning a chunk of XML directly into an object. |
| 23:28 | <@jerith> | I came pretty close to vomiting when I read that. |
| 23:28 | < Derakon[work]> | Heh. |
| 23:29 | < Derakon[work]> | Oh, wait, I hadn't read what classobj does. |
| 23:29 | < Derakon[work]> | So I assumed it was "Look up the class that has the given name, and instantiate one for me". This is not that. |
| 23:30 | <@jerith> | No. |
| 23:30 | <@jerith> | This is "invent a new class that descends from object". |
| 23:31 | < Derakon[work]> | Right. |
| 23:32 | <@jerith> | Please note that some operations return a list of mixed objects. |
| 23:32 | < Rhamphoryncus> | why isn't it type? |
| 23:32 | | Namegduf [namegduf@37647E.DB45F1.609B34.8CB351] has joined #code |
| 23:32 | < Rhamphoryncus> | calling type rather than classobj that is |
| 23:33 | < Derakon[work]> | Oh, Rhamphoryncus, you're back. |
| 23:33 | < Rhamphoryncus> | I'm always back. Except when you need me |
| 23:33 | <@jerith> | Rhamphoryncus: I've been trying not to think about it that deeply. |
| 23:33 | < Derakon[work]> | Care to read the backscroll a bit? The microscope is finally available for me to work on, so I was able to poke at that random crash a bit. |
| 23:33 | < Derakon[work]> | And it really looks like memory corruption. :( |
| 23:34 | < Derakon[work]> | One thing I'm wondering is if maybe the fact that we're running Python 2.4 here has something to do with it. Unfortunately I'm not certain what the ramifications of upgrading Python would be... |
| 23:34 | < Rhamphoryncus> | Derakon[work]: pure python version has the same bug? |
| 23:34 | < Derakon[work]> | It is claimed to, yes. |
| 23:34 | < Rhamphoryncus> | Is it using threading? |
| 23:34 | < Derakon[work]> | I have not yet tried to get it to run on the microscope machine. |
| 23:34 | < Derakon[work]> | I think so. |
| 23:35 | < Rhamphoryncus> | Is the main thread exiting before all the child threads have finished and exited? |
| 23:35 | < Derakon[work]> | I can't see how, since it's crashing in the middle of a long-running process. |
| 23:35 | <@jerith> | Anyways, the sanest way I can figure out what kind of object I'm looking at is to inspect the classname and munge it into something suitable. |
| 23:36 | < Rhamphoryncus> | If all the work is done in the child threads... or if the main thread gets an exception.. |
| 23:36 | < Rhamphoryncus> | although an exception would probably get printed before the crash |
| 23:36 | < Rhamphoryncus> | libraries in use? |
| 23:37 | < Derakon[work]> | For the area where the code's crashing, just numpy. |
| 23:37 | <@jerith> | G'night all. |
| 23:37 | < Derakon[work]> | Night, Jerith. |
| 23:37 | < Rhamphoryncus> | Any libraries loaded |
| 23:37 | < Derakon[work]> | Tons. |
| 23:37 | < Rhamphoryncus> | all candidates :/ |
| 23:37 | < Derakon[work]> | Howso? |
| 23:38 | < Rhamphoryncus> | It's quite possible for one of them to leave things corrupted, which only gets tripped by python later |
| 23:38 | < Rhamphoryncus> | A double free for instance |
| 23:38 | < Derakon[work]> | Hrmph... |
| 23:39 | < Rhamphoryncus> | How reproducible is the crash? |
| 23:39 | < Derakon[work]> | I can consistently get it to crash within 10 minutes or so of starting the process. |
| 23:39 | < Derakon[work]> | But it could happen anytime within that 10 minutes. |
| 23:39 | | * Rhamphoryncus nods |
| 23:40 | < Rhamphoryncus> | Same places? |
| 23:40 | < Derakon[work]> | Yes. The location is consistent. |
| 23:40 | < Derakon[work]> | If I comment out the line that crashes, then it crashes a couple of lines later. |
| 23:40 | < Derakon[work]> | I have a try/catch block around the crashing line, but it doesn't catch anything. |
| 23:40 | < Rhamphoryncus> | Any you can put on pastebin? |
| 23:40 | < Derakon[work]> | That line, incidentally, being: |
| 23:40 | < Derakon[work]> | X.f_mrc_hdr.Num = wx.GetApp().getNX(), wx.GetApp().getNY(), nZ*nTimes*nw |
| 23:41 | < Rhamphoryncus> | ah, wx >.> |
| 23:41 | < Derakon[work]> | And I've tried replacing all the values there with values calculated ahead of time and stored in variables. |
| 23:42 | < Rhamphoryncus> | I think you need to strip down your test case |
| 23:42 | < Derakon[work]> | Basically turning the line into "X.f_mrc_hdr.Num = nx, ny, nZ*nTimes*nw" |
| 23:42 | < Derakon[work]> | ...you're kidding, right? |
| 23:42 | < Rhamphoryncus> | I wish :( |
| 23:42 | < Derakon[work]> | This is a tangled mess of code. It's 20k lines long. |
| 23:42 | < Derakon[work]> | It's completely unseparatable. |
| 23:42 | < Rhamphoryncus> | malloc debuggers are other options.. there's a simple one built into glibc |
| 23:42 | < Derakon[work]> | What it needs is a year or so with a hacksaw and some carpenter's glue. |
| 23:43 | < Derakon[work]> | Unfortunately I don't have that kind of mandate. |
| 23:43 | < Rhamphoryncus> | Another possibility to check for and guard against bugs in the use of malloc, realloc and free is to set the environment variable MALLOC_CHECK_. When MALLOC_CHECK_ is set, a special (less efficient) implementation is used which is designed to be tolerant against simple errors, such as double calls of free with the same argument, or overruns of a single byte (off-by-one bugs). Not all such errors can be protected against, however, a |
| 23:43 | < Rhamphoryncus> | nd memory leaks can result. If MALLOC_CHECK_ is set to 0, any detected heap corruption is silently ignored; if set to 1, a diagnostic is printed on stderr; if set to 2, abort is called immediately. This can be useful because otherwise a crash may happen much later, and the true cause for the problem is then very hard to track down. |
| 23:43 | < Rhamphoryncus> | so set it to 2 and run in gdb |
| 23:44 | < Derakon[work]> | This is also running in Windows, I note, and getting gdb running on it may be tricky. |
| 23:44 | < Rhamphoryncus> | I should warn you that some programs seem to interact with debuggers badly |
| 23:44 | < Derakon[work]> | But thanks for that environment variable. I hope it's helpful. |
| 23:45 | < Rhamphoryncus> | doh |
| 23:45 | < Derakon[work]> | Yeah. :( |
| 23:45 | < Derakon[work]> | We needed some hardware drivers, IIRC. |
| 23:45 | < Rhamphoryncus> | visual studio? Does it have an option somewhere for a debugging malloc? |
| 23:45 | < TheWatcher> | Cywgin an option?~ |
| 23:46 | < TheWatcher> | *cygwin |
| 23:46 | < Derakon[work]> | Visual Studio actually pops up automatically when the crash happens and asks if we want to debug. |
| 23:46 | < Derakon[work]> | You get dumped into the middle of some assembly code with a useless stack trace. |
| 23:46 | < Derakon[work]> | TW: that would be the way to go for installing gdb, yes. |
| 23:46 | < McMartin> | WinDbg >>>>> Visual Studio. |
| 23:46 | < Rhamphoryncus> | That'll get you the debugger, but not a debug malloc |
| 23:46 | < Rhamphoryncus> | http://msdn.microsoft.com/en-us/library/974tc9t1(VS.80).aspx |
| 23:46 | < Derakon[work]> | I'm very leery of making major changes to that system, though, because if it breaks, then a) the microscope can't be used, and b) I have no idea how to fix it. |
| 23:47 | < Rhamphoryncus> | are you running with debugging on, optimization of f? |
| 23:47 | < Derakon[work]> | I haven't the foggiest. |
| 23:47 | < McMartin> | Also, even without those, was this built with Visual Studio on the C++ end? |
| 23:48 | < McMartin> | Because if so, you need the .pdb files to get any useful stack traces. |
| 23:48 | < Derakon[work]> | I think so, McM. |
| 23:48 | < McMartin> | On the plus side, .pdbs seem to work way better in release mode than gcc's release mode. |
| 23:48 | < Derakon[work]> | That's another issue I have with this project: the C++ code hasn't been built in years. |
| 23:49 | < Rhamphoryncus> | ... right. There's no way in hell you're going to debug in the presence of that code |
| 23:51 | < Rhamphoryncus> | any of those libraries old versions that have updates available? |
| 23:51 | < Derakon[work]> | Probably! |
| 23:51 | < Derakon[work]> | So just blindly upgrading things and hoping they continue to function is one option. |
| 23:51 | < Derakon[work]> | Apparently there's some problem with use of generator functions that's preventing us from upgrading Python itself, though. |
| 23:52 | < Rhamphoryncus> | what? |
| 23:52 | < Derakon[work]> | I don't know. |
| 23:52 | < Derakon[work]> | That was the claimed reason; I haven't yet investigated further. |
| 23:53 | < Rhamphoryncus> | The only obvious reason is they're using the yield keyword as something else |
| 23:54 | < Rhamphoryncus> | Less obvious would be some obscure (or even buggy) behaviour that changed/fixed |
| 23:54 | <@Vornicus> | I broke forward compat on Schlockian by using "False" before it was defined. |
| 23:55 | | * Derakon[work] does a quick grep, determines that one prominent use is "yield None" to allow a function to pick up where it left off. |
| 23:56 | < Rhamphoryncus> | Vornicus: I think that was a motivator for the current use of __future__ imports. Although assigning to False is only now becoming a syntax error |
| --- Log closed Sat Sep 19 00:00:18 2009 |