| --- Log opened Wed Oct 05 00:00:44 2011 |
| 00:04 | | You're now known as TheWatcher[T-2] |
| 00:06 | <@ToxicFrog> | Heee |
| 00:07 | | You're now known as TheWatcher[zZzZ] |
| 00:08 | | * McMartin checks the Book of Madness |
| 00:08 | < McMartin> | Ah, yes, it is in fact in here as a suggested thing to do. |
| 00:09 | < McMartin> | However, it's right next to the "Of course, Javascript functions don't have a curry method, but we can fix that" |
| 00:12 | < McMartin> | This is also the same book that claims that some of the most terribly brain-dead aspects of JavaScript are that + is overloaded to work on both numbers and strings, and that there exist reserved words in the language. |
| 00:13 | < Vornicus> | I actually pulled something like that |
| 00:13 | < Vornicus> | By accident |
| 00:13 | < Vornicus> | Without knowing I could. |
| 00:14 | < Vornicus> | In an introductory js class. During a test. At which point I exclaimed "wait that worked?" |
| 00:14 | < McMartin> | Hee |
| 00:14 | < McMartin> | With a handful of gotchas, most of which if I'm being honest have to do with it being multiparadigm and are not lolJS, JS has pretty much ideal lexical scope semantics. |
| 00:15 | < McMartin> | Which you can do All The Horrible Scheme Things. |
| 00:17 | < RichardBarrell> | You can't macro. |
| 00:17 | < RichardBarrell> | Correction, you *shouldn't* macro because you're going to commit a syntax error by mistake when you start concatenating strings and throwing them into eval(). |
| 00:17 | < McMartin> | And you can't c/cc |
| 00:18 | < McMartin> | What I should be saying there is "you can do all the standard nasty tricks that lexical scope and first-class functions let you do." |
| 00:18 | < RichardBarrell> | Mmmmyeah. You can CPS manually but it's just ugly. |
| 00:18 | <@ToxicFrog> | I thought JS used Python scope? |
| 00:19 | | * RichardBarrell sings a small hymn in praise of Control.Monad.Cont. |
| 00:19 | < McMartin> | With a few asides of "oh, btw, everything's passed by reference" and some possibly surprising interactions with the object model. |
| 00:19 | < McMartin> | TF: Maybe once, but as of JS 1.4 it's been full ML style. |
| 00:19 | < McMartin> | Fully assignable upvalues. |
| 00:19 | < RichardBarrell> | No, JS's scoping rules are mostly stolen from Scheme (thank goodness). Real upvalues were in the language from day one. |
| 00:20 | < RichardBarrell> | The one oddity about scoping that JS has is that { and } don't introduce new scopes like they do in C. Instead, functions and only functions introduce new scopes. |
| 00:21 | < McMartin> | Yeah, lack of block scope and lack of a primitive for "create an object with this other object as its prototype" are the two most obvious flaws in the language, imo |
| 00:21 | < McMartin> | Of course, the latter is fixable with a three-line function |
| 00:21 | < RichardBarrell> | The former is understandable despite being really ugly. |
| 00:22 | < McMartin> | The latter seems to be because they were ashamed of not using class systems. |
| 00:22 | < RichardBarrell> | Just a stupid hack in the language semantics in order to get the really crummy, maybe not even bytecoded interpreter to run a little faster by forgoing the need to create data structures to keep track of variable scopes for every single block. |
| 00:22 | <@ToxicFrog> | RichardBarrell: so the distinction is that Python hoists variable declarations to the start of the function, but neither of them let you create new scopes without creating fnuctions? |
| 00:23 | < RichardBarrell> | JS hoists variable declarations to the start of the function, and requires an explicit 'var' statement to introduce locals. |
| 00:24 | < McMartin> | TF: Python once only had a "local scope" and a "global scope", and didn't have lexical scoping at all |
| 00:24 | < McMartin> | It eventually replaced it with read-only full lexical scoping, but upvalues are unassignable |
| 00:24 | < RichardBarrell> | Python has done various extremely stupid things over the years. |
| 00:24 | < RichardBarrell> | GvR is, as a benevolent dictator, slightly overrated. |
| 00:25 | < McMartin> | Well, making upvalues unassignable fits in with the Python model of "there's only one way to do it, and it works" |
| 00:25 | < RichardBarrell> | Extremely stupid things with scopes, anyway. |
| 00:25 | < McMartin> | If you want assignable "upvalues", use object fields. |
| 00:25 | < RichardBarrell> | Yes, I'm just talking about the bit where it *ever* lacked lexical scoping at all. |
| 00:26 | < RichardBarrell> | and the explicit "global" keyword, because otherwise any attempt to assign to a global will instead *shadow* it by mistake. |
| 00:26 | < McMartin> | I consider that a reasonable design decision, if you allow globals at all. |
| 00:27 | < McMartin> | In the absence of local declarations, you do not want a change in an imported module to change the behavior of your functions. |
| 00:29 | < RichardBarrell> | I prefer the "local identifiers are introduced either as function parameters or with a declaration" rule. |
| 00:30 | < RichardBarrell> | For starters it means that you can't get idiocy like NameError exceptions at run-time instead of compile-time. |
| 00:30 | < RichardBarrell> | JavaScript's "it's a global variable by default! yay!" isn't the most helpful thing in the world either. |
| 00:31 | < McMartin> | I don't think anyone seriously claims JS is a good language~ |
| 00:32 | < RichardBarrell> | At one point I almost found myself believing Crockford's assertion that JS *contains* a good language. |
| 00:33 | < McMartin> | Crockford's book on this is the aforementioned "Book of Madness" |
| 00:33 | < McMartin> | Crockford is entirely on crack. |
| 00:33 | < RichardBarrell> | ...yes. |
| 00:33 | < RichardBarrell> | Out of curiosity, why are you doing fun things that Crockford recommends like using closures to hide variables? :) |
| 00:33 | < McMartin> | Like, his idea of terrible language features include things like "the continue statement exists" and "the language has reserved words in it" |
| 00:34 | < McMartin> | Well, no, he recommends adding methods to the Object and Function prototypes so that you make the language look more like Self~ |
| 00:35 | < RichardBarrell> | Oh yes that, I forgot about that. |
| 00:35 | < McMartin> | While making the language look more like Self is laudable, I question the wisdom of sticking those functions in Object.prototype or Function.prototype. |
| 00:35 | < RichardBarrell> | Does he actually say those things? He has never attempted to assert those either of those statements by putting them into JSLint rules. |
| 00:35 | < McMartin> | Well, all the sample code in the book treats Object.create as a primitive |
| 00:36 | < McMartin> | (It's not; he defines it in Chapter 3 and then pretends it's a primitive forever after) |
| 00:36 | < RichardBarrell> | Completely with you there. Messing with the prototype of any built-in type is an instant trip to fuck-you town, population: fuck you. |
| 00:36 | < McMartin> | The behavior of "this" in functions that are not method calls makes *his life harder* but if I put my language-theorist hat on I cannot make a coherent argument that that JS way is wrong |
| 00:36 | < McMartin> | Just inconvenient for Mr. Crockford. |
| 00:37 | < Vornicus> | RichardBarrell: welcome to the reason a lot of us cannot stand Ruby. |
| 00:37 | < RichardBarrell> | It pisses me off in JavaScript more because it breaks for .. in loops. |
| 00:38 | < Vornicus> | Where that is in fact the recommended way to do it for some unknown reason. |
| 00:38 | < RichardBarrell> | And yes, I know, Object.prototype.hasOwnProperty, but that completely ruins the *terseness* of for .. in and drives me up the wall. |
| 00:38 | < McMartin> | Happily, the lexical scope thing does defeat that~ |
| 00:40 | < Vornicus> | I haven't done stuff with for...in and hasOwnProperty. What's, um. what's it, uh...? |
| 00:40 | < McMartin> | hasOwnProperty is "did you define this, or get it from the prototype" |
| 00:40 | | * Vornicus has apparently lost his train of thought very badly. |
| 00:45 | | kwsn [kwsn@Nightstar-635d16fc.org] has quit [Ping timeout: 121 seconds] |
| 00:46 | < RichardBarrell> | Vornicus: var o = { a:1, b:"cheese", c:null }; for (name in o) { console.log(name); } /* will print out "a" "b" and "c" on the console in a completely undefined order */ |
| 00:46 | < RichardBarrell> | Vornicus: Object.prototype.d = "ham"; var o = { a:1, b:"cheese", c:null }; for (name in o) { console.log(name); } /* will print out "a" "b" "c" and also "d" in an undefined order */ |
| 00:48 | < RichardBarrell> | The for (x in y) loop iterates over the object y and assigns each of its keys to the variable x. It runs up y's prototype chain too though, and all prototype chains eventually end in Object. |
| 00:48 | < McMartin> | Ordinarily, running up the prototype chain would be what you want, ofc, because this is how inheritance works. |
| 00:49 | < RichardBarrell> | So if someone dicks with Object.prototype, you lose a pleasingly concise way to iterate over a bunch of strings in who-cares-what-order. (You can still check hasOwnProperty, but it isn't concise any more.) |
| 00:50 | < RichardBarrell> | Also for (x in y) works for Arrays, assigning x to each of the valid indices. Or it would, except that some ambulatory phallus added something to Object.prototype and now you've lost the most concise way of iterating an array, too. |
| 00:52 | < McMartin> | This is, broadly speaking, why Aspect-Oriented Software Development is a terrible idea outside of a tiny number of places where it is the only sane way to do it. |
| 00:54 | | kwsn [kwsn@Nightstar-635d16fc.org] has joined #code |
| 00:54 | < RichardBarrell> | Having never touched real Aspect-Oriented in anger, I'll defer to your judgement for now. |
| 00:55 | | * Vornicus still hasn't figured out the difference between Aspect-Oriented and a spectacularly complex inheritance graph. |
| 00:56 | < McMartin> | RichardBarrell: The ability to assign to other people's prototypes, elsewhere in the code, is sufficient to *be* aspect-orientation. |
| 00:56 | < McMartin> | Vornicus: AOSD tends to include some concept of "COME FROM". |
| 00:57 | < Vornicus> | oh hooray. |
| 00:57 | < RichardBarrell> | McMartin: okay. I can't say I've ever used that feature because I kind of violently hate it. I have to ask, is this distinct from having the ability to monkey-patch? |
| 01:04 | < McMartin> | I'm unfamiliar with the term "monkey-patch" |
| 01:04 | < McMartin> | (The killer app for this capability, incidentally, is "instead of doing thing X, log debugging info to a file and then do thing X") |
| 01:04 | < McMartin> | (Which lets you put spectacularly intrusive instrumentation in and then rip it out without actually editing your real source base) |
| 01:05 | < RichardBarrell> | Replacing methods at runtime, again from any arbitrary piece of code. |
| 01:06 | < McMartin> | Ah, OK |
| 01:06 | < McMartin> | It's distinct, generally, because it happens at compile-time instead. |
| 01:06 | < RichardBarrell> | On classes, specifically. |
| 01:06 | < McMartin> | Languages that aren't compiled would see no difference. |
| 01:07 | < RichardBarrell> | You usually resort to it in order to fix some kind of idiocy in an upstream library that you can't patch. |
| 01:08 | < Vornicus> | (in RUby, the problem is compounded by the fact that there isn't f'rinstance an __radd__ method) |
| 01:14 | <@ToxicFrog> | Yeah, I don't think the "at runtime" part is necessary for it to be monkeypatching; it's more "after the class is defined and supposed to be immutable" |
| 01:16 | < McMartin> | Now I have to ask: How is this different from shimming via LD_PRELOAD? |
| 01:16 | < McMartin> | Also, yay |
| 01:16 | | * McMartin is back down to one problem. |
| 01:17 | <@ToxicFrog> | Because it's "modifying parts of an existing class, which you may not have the source for" rather than "replacing it wholesale with your own implementation" |
| 01:17 | <@ToxicFrog> | If you could, say, use LD_PRELOAD to replace iostream::operator<< individually, I'd consider that a monkeypatch. |
| 01:18 | <@ToxicFrog> | (part of the implications here is that you don't need the source for the old class, and other code that depends on the old class will be affected by your changes to it) |
| 01:18 | < McMartin> | (If you know the C++ ABI and mangling technique, you can in fact totally do this) |
| 01:18 | < RichardBarrell> | You could mmap() around a bit and replace your process's view of iostream::operator<< with a bit of violence. |
| 01:18 | < McMartin> | (LD_PRELOAD lets you overwrite individual exported symbols) |
| 01:18 | <@ToxicFrog> | (well then) |
| 01:19 | <@ToxicFrog> | (that said, there's also a strong implication that you're doing this using entirely in-language features, like editing prototypes) |
| 01:19 | < McMartin> | (Yeah, I know) |
| 01:19 | < McMartin> | (And on Mac{h} you need to use compiler pragmas alongside it to make it work) |
| 01:20 | < McMartin> | ObjC does have that though, as does TADS 3. |
| 01:21 | < McMartin> | Basically, any OO language that lets you split up the definition of a class, and allows either duck typing or some kind of referential transparency that means adding methods in half your libraries won't break the ABI, kind of gets that power for free. |
| 01:22 | < McMartin> | ObjC also gives us the absolutely awesome and horrifying "poseAsClass:" class method, in Object, that surreptitiously replaces that other class's constructor with yours. |
| 01:23 | <@ToxicFrog> | o.O |
| 01:23 | < McMartin> | For roughly the same reason as one would use LD_PRELOAD. |
| 01:24 | < McMartin> | "I'd like to replace NSButton with my own Button class that does other stuff, and then delegates to NSButton if and when appropriate" |
| 01:24 | < McMartin> | (ObjC has duck typing though) |
| 01:29 | < RichardBarrell> | LD_PRELOAD is for debugging and epic security failures. |
| 01:29 | < RichardBarrell> | Not all that many other sane uses. |
| 01:29 | < McMartin> | s/LD_PRELOAD/AOSD/ |
| 01:41 | | kwsn [kwsn@Nightstar-635d16fc.org] has quit [Ping timeout: 121 seconds] |
| 01:42 | | kwsn [kwsn@Nightstar-635d16fc.org] has joined #code |
| 01:56 | < McMartin> | . |
| 01:57 | < McMartin> | "Ubuntu One is now available on Windows" |
| 01:57 | < McMartin> | Well, uh, OK? |
| 02:12 | <@ToxicFrog> | McMartin: it's basically Dropbox except with 5GB instead of 2GB as storage and it doesn't support as many platforms. |
| 02:37 | | gruber [lenin@Nightstar-202a5047.priv.bahnhof.se] has joined #code |
| 02:38 | | gnolam [lenin@Nightstar-202a5047.priv.bahnhof.se] has quit [Ping timeout: 121 seconds] |
| 02:45 | | gruber is now known as gnolam |
| 02:48 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:16 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 03:35 | | gnolam [lenin@Nightstar-202a5047.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 03:54 | | [ka]killer [John@Nightstar-74bd0be9.dyn.optonline.net] has quit [[NS] Quit: <Orochi> fuck <Orochi> now I'm pregnant] |
| 04:14 | | Phox is now known as Fantastic_Phox |
| 05:17 | | kwsn [kwsn@Nightstar-635d16fc.org] has quit [Ping timeout: 121 seconds] |
| 05:27 | | kwsn [kwsn@Nightstar-635d16fc.org] has joined #code |
| 06:40 | | Derakon is now known as Derakon[AFK] |
| 07:41 | | You're now known as TheWatcher |
| 08:11 | | Janus [NSwebIRC@Nightstar-b1ac186a.res.rr.com] has joined #code |
| 09:07 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has joined #code |
| 09:15 | | Kindamoody is now known as Kindamoody|out |
| 10:42 | | AnnoDomini [annodomini@FFB3F3.4C5BE8.2014E2.DC0864] has joined #code |
| 11:13 | | Janus [NSwebIRC@Nightstar-b1ac186a.res.rr.com] has quit [[NS] Quit: zzzzzz] |
| 11:16 | | Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has quit [Client exited] |
| 12:23 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code |
| 12:28 | | Reiver [orthianz@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 12:36 | | Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code |
| 12:46 | | gnolam [lenin@Nightstar-202a5047.priv.bahnhof.se] has joined #code |
| 12:51 | | kwsn [kwsn@Nightstar-635d16fc.org] has quit [[NS] Quit: later all] |
| 14:14 | | AnnoDomini [annodomini@FFB3F3.4C5BE8.2014E2.DC0864] has quit [[NS] Quit: Goin' home. I am being very kind to that place, calling it home.] |
| 14:39 | | kwsn [kwsn@Nightstar-635d16fc.org] has joined #code |
| 15:04 | | Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has quit [Ping timeout: 121 seconds] |
| 15:09 | | Reiver [orthianz@3CF3A5.E1CD01.C6689C.33956A] has joined #code |
| 15:56 | < gnolam> | Hmm |
| 16:20 | | Kindamoody|out is now known as Kindamoody |
| 17:38 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has quit [Ping timeout: 121 seconds] |
| 18:05 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has joined #code |
| 18:18 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [[NS] Quit: If the world didn't suck, we'd all fall off.] |
| 18:21 | | Derakon [chriswei@Nightstar-f68d7eb4.ca.comcast.net] has joined #code |
| 18:21 | < Derakon> | Bah, can't work on this project right now because the computer with Visual Studio installed on it is also the microscope computer and a biologist is using it to collect data. |
| 18:22 | < Derakon> | (I can't remember offhand why the free version of VS didn't work for my build-against-Python projects but it really didn't...) |
| 18:22 | < Derakon> | (And we certainly aren't going to pay for a second copy of the program) |
| 18:30 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has quit [Ping timeout: 121 seconds] |
| 18:39 | < Derakon> | "Disk space requirements: C: 552MB and D:197MB. Total download size: 92MB." That's some impressive compression they're applying there. |
| 18:39 | < Tamber> | ...impressive. |
| 18:40 | < Alek> | whatcha wanna bet it's an installer that'll be downloading more, silently, to fill in the gaps? |
| 18:41 | < Alek> | like 3rd-party libraries and stuff? |
| 18:45 | < Derakon> | This is the installer itself saying how much space it'll use, and, presumably, how much stuff it'll be downloading. |
| 18:45 | < Derakon> | Which I could see being a nice feature for people who have capped internet connections. |
| 18:57 | < jerith> | Like me. |
| 19:12 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has joined #code |
| 19:37 | | Kindamoody is now known as Kindamoody[zZz] |
| 19:42 | | AnnoDomini [annodomini@60F158.737D66.CA1918.CC7562] has joined #code |
| 19:44 | | Vash [Vash@Nightstar-f03c5637.sd.cox.net] has quit [[NS] Quit: I <3Lovecraft<3 Vorn!] |
| 20:44 | | AnnoDomini [annodomini@60F158.737D66.CA1918.CC7562] has quit [[NS] Quit: I must flee. Battery low.] |
| 20:49 | | Rhamphoryncus [rhamph@Nightstar-14eb6405.abhsia.telus.net] has joined #code |
| 20:53 | | * Derakon blarghs at SWIG and numpy. |
| 20:54 | < kwsn> | SWIG? |
| 20:54 | < Derakon> | Possibly the most irritating aspect of this particular problem is that I know Sebastian solved it already, but I can't bring myself to figure out how his solution worked (and besides it's probably a decade out of date). |
| 20:54 | < Derakon> | SWIG's a system for getting two languages to talk to each other. |
| 20:54 | < Derakon> | In this case, so my Python code can talk to a C++ API. |
| 20:54 | < kwsn> | ah |
| 21:05 | < RichardBarrell> | Derakon: might I suggest boost::python or ctypes? |
| 21:06 | < RichardBarrell> | I don't know much about boost::python, but I suggest ctypes just because using the CPython API on PyPy is known to be rather slow. |
| 21:08 | < RichardBarrell> | Er that might not actually still be true. |
| 21:12 | < Derakon> | I have only limited experience with ctypes...but I have the rest of the C++ API working with SWIG already, and I'd rather not throw that work away to start over with a new approach just for a couple of functions. |
| 21:13 | < RichardBarrell> | Fair enough. I was piping up on the off-chance that you were *just* getting started. |
| 21:15 | | * Derakon nods. |
| 21:21 | < RichardBarrell> | Yay, I have a silly fold-in-half bluetoothh keyboard. |
| 21:24 | | * Tamber folds RB's keyboard into an airplane. |
| 21:41 | | Attilla [Some.Dude@Nightstar-f29f718d.cable.virginmedia.com] has joined #code |
| 21:54 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 22:00 | < celticminstrel> | There's just two things I'm missing about exporting to BMP; one is how to get the correct bit depth for the BMP header, and the other is how to get the xy coordinates for glReadPixels. |
| 22:01 | < gnolam> | How to assign glReadPixels() x,y coordinates or how to convert the read data into pixels? |
| 22:03 | < celticminstrel> | I suppose what I need is either how to get the xy coordinates of the GLUT window, or evidence that it's reading relative to the window (and thus I pass 0,0). |
| 22:03 | < celticminstrel> | I don't think I need to convert the read data if I pass GL_BGR? |
| 22:03 | < celticminstrel> | Maybe I'm wrong, I dunno. |
| 22:05 | < celticminstrel> | Anyway, I don't know what xy coordinates to pass to glReadPixels. |
| 22:05 | < celticminstrel> | Nor what bit depth the resulting data will be in. |
| 22:10 | < gnolam> | You pass 0,0, assuming you want to capture the entire screen. The coordinates are in buffer pixel coordinates. |
| 22:10 | < celticminstrel> | I only want the GLUT window. |
| 22:10 | < gnolam> | Err |
| 22:10 | < celticminstrel> | Actually, I'm also going to need the screen to be redrawn before reading the pixels. |
| 22:10 | < gnolam> | How do you mean? |
| 22:11 | < celticminstrel> | So for coordinates I suppose there must be GLUT functions to get them... |
| 22:11 | < celticminstrel> | How do I mean which? |
| 22:11 | < gnolam> | "I only want the GLUT window" |
| 22:11 | < gnolam> | Do you want to capture the entire window, with decorations, or what? |
| 22:11 | < celticminstrel> | Just the contents. |
| 22:12 | | Derakon [chriswei@Nightstar-f68d7eb4.ca.comcast.net] has quit [[NS] Quit: Lost terminal] |
| 22:13 | < gnolam> | ... in other words, you do just want a copy of the framebuffer. |
| 22:13 | < gnolam> | In which case, it's a straight glReadPixels() copy from 0,0 to whatever width and height you have. |
| 22:14 | < celticminstrel> | You said "entire screen" so I assumed you meant entire screen. :P |
| 22:14 | < gnolam> | Ah. My bad. Should've said "buffer". |
| 22:15 | < gnolam> | (I tend to use "screen" to refer to "everything the game renders". Even in windowed mode.) |
| 22:15 | < celticminstrel> | I'm currently setting the bit depth in the bmp header to 16. Not sure if that's right, but I'm going to go finish off SVG output now. |
| 22:16 | < gnolam> | (I am not alone in this.) |
| 22:16 | < gnolam> | 16 bit BMPs are rather... uncommon. |
| 22:17 | < celticminstrel> | I assume it has to be set to match what glReadPixels produces. |
| 22:17 | < gnolam> | The ones that are universally supported are the classic BMPs: 8 and 24 bit. |
| 22:18 | < gnolam> | Why are you in 16 bit then? :) |
| 22:19 | < celticminstrel> | I was just guessing. :P |
| 22:20 | < celticminstrel> | Huh, does Eclipse not support #pragma mark? |
| 22:21 | < celticminstrel> | Unless I'm just looking at the wrong view. Eclipse is pretty confusing really. |
| 22:21 | < McMartin> | Eclipse is the editor, not the compiler. |
| 22:22 | < McMartin> | Are you using gcc here? |
| 22:22 | | * TheWatcher stab microsoft and its fucking .NET framework |
| 22:22 | < celticminstrel> | I know, but #pragma mark is targeted at the editor, not the compiler. |
| 22:22 | < McMartin> | I think of #pragma as being more an MSVC thing, though I know it's technically part of the standard |
| 22:22 | < McMartin> | Oh, I get it |
| 22:22 | < McMartin> | Sorry |
| 22:22 | < McMartin> | I read that wrong |
| 22:22 | < McMartin> | No idae |
| 22:22 | < McMartin> | TW: ? |
| 22:23 | < TheWatcher> | Oh, I think I have about 5 or 6 different versions installed now |
| 22:23 | < celticminstrel> | I guess #pragma mark takes advantage of the fact that the compiler is supposed to ignore unrecognized pragmas. |
| 22:23 | < McMartin> | cm: Yeah, probably |
| 22:23 | < McMartin> | TheWatcher: The Solution to DLL Hell (tm) |
| 22:23 | < TheWatcher> | Yeah, that, yey 9_9 |
| 22:24 | < RichardBarrell> | C compilers aren't actually supposed to ignore unrecognised pragmas. The C spec says that unrecognised pragmas produce undefined behaviour of the compiler itself. |
| 22:24 | < Namegduf> | So they're supposed to recognise them, then do something undefined. |
| 22:24 | < RichardBarrell> | gcc used to take advantage and take the piss by running NetHack when you fed it an unknown pragma. |
| 22:24 | < Tamber> | haha |
| 22:24 | < celticminstrel> | I think C++ compilers are supposed to ignore them... and I can't imagine a C compiler doing anything different. |
| 22:24 | < Namegduf> | That undefined thing could be ignoring them, but the recognition step and decision is important. |
| 22:24 | < celticminstrel> | Heh. |
| 22:25 | < McMartin> | RichardBarrell: This is another reason the old gcc steering committee cannot be trusted |
| 22:25 | < celticminstrel> | How can you recognize an unrecognized pragma? :P |
| 22:25 | < celticminstrel> | (Did gcc actually do that?) |
| 22:25 | < Tamber> | Easy. Your compiler starts playing nethack. |
| 22:25 | < McMartin> | You recognize that it *is* a pragma, and then that you don't know it. |
| 22:25 | < celticminstrel> | Ah. |
| 22:25 | < celticminstrel> | Well that's easy. :P |
| 22:25 | < McMartin> | Basically, even if you support no pragmas, supporting #pragma is required. |
| 22:26 | < RichardBarrell> | Maybe not. You could just ignore all #pragmas, and that'd be legal. |
| 22:26 | < RichardBarrell> | ("undefined" allows "nothing bad happens" even though it does not imply it) |
| 22:26 | < McMartin> | Well, right, but #pargma should signal an error. |
| 22:26 | < McMartin> | IIRC. |
| 22:26 | < McMartin> | "An error is signalled" is different. |
| 22:26 | < McMartin> | Pretty sure undefined strongly implies nothing bad happens. |
| 22:26 | < Tamber> | #pragma rocks_fall |
| 22:27 | < McMartin> | Because otherwise "it is an error to" do it. |
| 22:27 | < gnolam> | GCC ignores the #pragma three times, then a cock crows. |
| 22:27 | < McMartin> | But yes, old!gcc had a bit of a snit about How Dare You Be Compatible With Compiler That Aren't Us, That Means You Hate Freedom |
| 22:27 | < Namegduf> | McMartin: That is not my understanding of "undefined behaviour" |
| 22:27 | < RichardBarrell> | We're talking undefined behaviour, as in daemons are allowed to fly out of your nose. |
| 22:28 | < McMartin> | RichardBarrell: Yes, and it's a really bad idea to have that for #pragma |
| 22:28 | < Tamber> | Rather bad on the sinuses, too. |
| 22:28 | < celticminstrel> | XD |
| 22:29 | < RichardBarrell> | McMartin: I'm failing to communicate. If someone writes "#pragma foo" and you don't understand what "#pragma foo" means, you may do absolutely anything or nothing in response to this. |
| 22:29 | < McMartin> | Right, and if so, I'm saying that's an obvious flaw in the standard. |
| 22:29 | < RichardBarrell> | ("you" being the compiler itself in this case, not the compiled program) |
| 22:29 | < Tamber> | "...ohgod, I have lpd stuck in my nostril!" |
| 22:29 | < McMartin> | Pragma is specifically "special instructions to people who aren't you". |
| 22:30 | < McMartin> | So unknown pragmas in a sane standard would be mandatorily ignored. |
| 22:30 | < celticminstrel> | Isn't it more like "special instructions to people who may or may not be you"? |
| 22:30 | < Tamber> | You expect any of this to be sane? |
| 22:30 | < McMartin> | Yes, actually, given how fucking long it took them to get a standard out the door. |
| 22:30 | < RichardBarrell> | Arguably. I would have moved in favour of requiring the compiler enact physical harm upon the programmer in the case of seeing an unrecognised pragma. |
| 22:30 | < Tamber> | The raisins aren't just hysterical, they're off finding axes... |
| 22:30 | < McMartin> | RichardBarrell: Is this because you hate compatibility, or because you love #ifdef thickets? |
| 22:30 | < celticminstrel> | You know, some of this logic would be easier if I had guaranteed that x1 and y1 are the top left of the rectangle. |
| 22:31 | < RichardBarrell> | McMartin: the latter. People who want to send instructions to specific compilers darn well oughta write #ifdef thickets. |
| 22:32 | | * McMartin tends to feel the makefile is a better place for that. Shrug. |
| 22:32 | < celticminstrel> | How would that work? |
| 22:32 | < RichardBarrell> | Or a generated header or something, sure. |
| 22:32 | < RichardBarrell> | celticminstrel: command-line switches. |
| 22:32 | < celticminstrel> | A generated header, sure, but in the makefile? |
| 22:33 | < McMartin> | Makefile modifies the include paths. |
| 22:33 | < RichardBarrell> | and in cases of viciously platform-specific stuff, picks between foo_win32.c and foo_unix.c |
| 22:33 | < celticminstrel> | So, you'd have a folder of win32 versions and a folder of mac versions and the makefile essentially picks between them? |
| 22:34 | < McMartin> | That's the way I like to set things up if I can get away with it, yeah. |
| 22:34 | < McMartin> | In particular, have an interface layer of viciously platform-specific stuff, that then serves as a compatibility layer everyone else hits. |
| 22:34 | < celticminstrel> | Makes sense... I dunno though, I might prefer the #ifdef thickets. |
| 22:34 | < RichardBarrell> | Yes. You do try to isolate the platform-specific stuff down to a small number of modules with clean, common interfaces, so it's not like you want to have a *large* directory there. |
| 22:35 | < celticminstrel> | Although if they were truly thickets, I can see that method being better. |
| 22:50 | <@ToxicFrog> | Seconding the "do seperate files, pick at compile time" approach. |
| 23:07 | < gnolam> | "separate". |
| 23:08 | < gnolam> | (Pet peeve) |
| 23:08 | < celticminstrel> | Okay, so I should probably set bit depth to 24? |
| 23:10 | < gnolam> | For the BMP, yes. |
| 23:11 | < celticminstrel> | And glReadPixels will get the data in that format? |
| 23:12 | < gnolam> | glReadPixels will get the data in whatever format you specify. |
| 23:12 | < celticminstrel> | I specified GL_BGR |
| 23:15 | < gnolam> | Specifically, this is how glReadPixels() works: |
| 23:15 | < gnolam> | "f RGBA color components are stored in the color buffers, they are read from the color buffer selected by glReadBuffer. Each color component is converted to floating point such that zero intensity maps to 0.0 and full intensity maps to 1.0. |
| 23:15 | < gnolam> | [...] Unneeded data is then discarded. [...] Finally, the indices or components are converted to the proper format, as specified by type." |
| 23:15 | < gnolam> | *If |
| 23:20 | <@ToxicFrog> | gnolam: for some reason "separate" feels like a verb to me, and "seperate" like an adjective. |
| 23:20 | <@ToxicFrog> | Like centre and center. |
| 23:21 | <@ToxicFrog> | (the former is an organization, the latter a location) |
| 23:22 | < celticminstrel> | The former is British/French spelling, the latter is American spelling. |
| 23:40 | <@ToxicFrog> | Yes, I know that strictly speaking they're regional spellings of the same word. |
| 23:40 | <@ToxicFrog> | But the way they connote for me is different. |
| 23:40 | <@ToxicFrog> | It's "the center of a circle" but "the Centre for Disease Control" |
| 23:41 | < celticminstrel> | Blarg this is annoying. |
| 23:41 | < celticminstrel> | Every time I do anything with the coordinates I have to min/max them to make sure they're top-right and bottom-left. |
| 23:42 | < celticminstrel> | Uh, top-left and bottom-right. |
| 23:42 | < jerith> | celticminstrel: Why not just do that on the edges? |
| 23:43 | < celticminstrel> | What? |
| 23:43 | < jerith> | When you first get coordinates, adjust them to be top-left/bottom-right. |
| 23:44 | < celticminstrel> | Yeah, that's what I should have done. |
| 23:44 | < jerith> | After that, assume that's what they are. |
| 23:44 | < celticminstrel> | But for some reason I didn't. |
| 23:44 | < jerith> | Refactor tractor! |
| 23:44 | < celticminstrel> | I suppose changing that wouldn't actually hurt since I'm currently min/maxing at use anyway. |
| --- Log closed Thu Oct 06 00:00:07 2011 |