| --- Log opened Wed Jul 03 00:00:18 2013 |
| 00:01 | | You're now known as TheWatcher[zZzZ] |
| 00:05 | | Typh|offline [Typherix@Nightstar-7dc8031d.mi.comcast.net] has quit [Ping timeout: 121 seconds] |
| 00:05 | | Derakon[AFK] is now known as Derakon |
| 00:05 | | Typh|offline [Typherix@Nightstar-7dc8031d.mi.comcast.net] has joined #code |
| 00:28 | | Derakon is now known as Derakon[AFK] |
| 01:04 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 01:10 | | Turaiel[Offline] is now known as Turaiel |
| 01:19 | | Derakon[AFK] is now known as Derakon |
| 01:28 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.] |
| 01:31 | | RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code |
| 01:53 | | Vorntastic [Vorn@Nightstar-79f10640.sub-70-211-3.myvzw.com] has joined #code |
| 01:59 | <&Derakon> | Hmph, that whole "only strings can be keys in JSON" thing is biting me again. |
| 01:59 | <&Derakon> | This time because I have objects whose IDs are position tuples. |
| 01:59 | < Vorntastic> | ...yep. |
| 02:05 | < Vorntastic> | What the heck kind of object has a position tuple. |
| 02:06 | <&Derakon> | A Cell in the map; a simple container that holds all the entities at that location. |
| 02:06 | < [R]> | One written by someone who doesn't understand multi-dimensional arrays. |
| 02:06 | <&Derakon> | Fortunately it turns out that I never actually reference the Cell's ID directly, so the fact that it has a position is in fact irrelevant. |
| 02:07 | <&McMartin> | [R]: I will admit to using a map of tuples to represent random-access sparse arrays |
| 02:39 | < [R]> | TIL: you can shebang .jar files |
| 02:39 | <@celticminstrel> | ...how does that work. |
| 02:39 | < [R]> | .jar files are .zip files. |
| 02:40 | < [R]> | .zip files have footers. |
| 02:40 | < [R]> | Which is why you can have self-extracting .zip files. |
| 02:40 | <@celticminstrel> | Footers? Not headers? |
| 02:41 | < [R]> | Right |
| 02:41 | <&McMartin> | And it's a footer of variable length and the magic identifier number is at the start of it |
| 02:41 | | * McMartin rages inhumanly |
| 02:41 | < [R]> | O.o |
| 02:41 | < [R]> | lolwat |
| 02:41 | < [R]> | That's horrible |
| 02:41 | <&ToxicFrog> | celticminstrel: specifically, the central directory is at the end of the file; you can append a zipfile to anything and it remains a valid zip file. |
| 02:41 | <&McMartin> | I wrote a .zip decoder a month or two back. |
| 02:41 | <&McMartin> | Pretty minimalist but did what I needed |
| 02:42 | <&McMartin> | I'm taking the C++ out of it over the next couple days, I think. |
| 02:42 | <&McMartin> | So I can have a super-minimalist libphysfs. |
| 02:42 | <&McMartin> | But seriously |
| 02:42 | <&McMartin> | The magic number should have been at the end, Mr. Katz. |
| 02:42 | <&McMartin> | Or at least a fixed distance therefrom. |
| 02:43 | <@celticminstrel> | ...ah, good to know. |
| 02:43 | <@Namegduf> | Implication: You can shebang .zip files |
| 02:43 | <&McMartin> | Yup |
| 02:43 | <&McMartin> | That said |
| 02:43 | <@Namegduf> | And make Linux "self-extracting" zip files which don't contain executable code. |
| 02:43 | <@Namegduf> | I do not, however, advocate this. |
| 02:43 | <&McMartin> | You'll have to do work to make it happen, because the zip entries have offsets from the start of the file, so you'll need to update the links therein. |
| 02:44 | < [R]> | Not every distro unzips the same way though |
| 02:44 | <&McMartin> | Isn't unzip part of the base utils by now? |
| 02:44 | < [R]> | Some have `unzip`, some make you use `p7z` some saner ones name it `7z` instead, and a few very rare ones have a `zip` command that also unzips. |
| 02:44 | <@Namegduf> | No. It's often available, but like rar files .zip is actually fairly unusual in Linux stuff |
| 02:44 | < [R]> | f |
| 02:45 | <@Namegduf> | unzip is pretty standard; I doubt the ones with 7-zip often *only* have 7-zip. |
| 02:45 | <&McMartin> | 7z is a different beast, yeah |
| 02:45 | <@Namegduf> | I think zip and unzip come in the same package, usually, and zip normally has a parameter to "become" unzip |
| 02:46 | <@Namegduf> | Some other stuff in Linux is like that |
| 02:46 | <&McMartin> | Yeah |
| 02:46 | <&McMartin> | VirtualBox -_- |
| 02:46 | <@Namegduf> | unwhatever OR whatever --undo-or-something |
| 02:47 | <@Namegduf> | Yeah, bzip2 with a parameter, OR bunzip2 |
| 02:47 | <@Namegduf> | Those two are quite common because bz2 is |
| 02:47 | < [R]> | zip and unzip are entirely seperate packages on every distro that I've used with em. |
| 02:47 | <@Namegduf> | Hmm, they are now. Maybe I misremembered that. |
| 02:48 | < [R]> | Oh, Slackware has the info-zip version for both |
| 02:48 | < [R]> | Hmm |
| 02:49 | | Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code |
| 02:58 | | * Derakon eyes deserialization. |
| 02:58 | <&Derakon> | On the one hand, recreating game objects tends to require that they have a copy of the GameMap handy, since they interact with it while being created. |
| 02:59 | <&Derakon> | On the other hand, I want the GameMap to itself be one of the objects that the deserializer recreates. |
| 02:59 | <&Derakon> | This seems unlikely to work out... |
| 02:59 | | Courage [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 02:59 | < [R]> | Can you dummy load the GameMap, then fill it as you get data from the deserialization? |
| 03:00 | <&Derakon> | That's actually how all of the other objects work. |
| 03:00 | <&Derakon> | They have to provide two functions: one creates a "blank" object -- bare-bones and empty as possible, the other fills in the data a fter. |
| 03:00 | <&Derakon> | Er, after. |
| 03:01 | <&Derakon> | The difficulty being that I have to have a GameMap lying around before any of the "create bare-bones object" functions get called, as it's the only input to those functions. |
| 03:02 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 03:05 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 03:05 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 03:05 | | Vorntastic [Vorn@Nightstar-79f10640.sub-70-211-3.myvzw.com] has quit [[NS] Quit: Bye] |
| 03:44 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 03:45 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 03:45 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 04:14 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:15 | | Kindamoody[zZz] is now known as Kindamoody |
| 04:41 | | Karono is now known as Karono[afk] |
| 04:44 | | Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Connection reset by peer] |
| 04:45 | | Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code |
| 04:49 | | Karono[afk] [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Ping timeout: 121 seconds] |
| 05:08 | | ktemkin[awol] is now known as ktemkin |
| 05:13 | | Karono [Karono@10AAA2.FD2B33.6E253B.F190AF] has joined #code |
| 05:13 | | Derakon is now known as Derakon[AFK] |
| 05:44 | | Turaiel is now known as Turaiel[Offline] |
| 05:44 | | Turaiel[Offline] is now known as Turaiel |
| 06:13 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [Ping timeout: 121 seconds] |
| 06:14 | | ErikMesoy|sleep is now known as ErikMesoy |
| 07:14 | | celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 07:14 | | Turaiel is now known as Turaiel[Offline] |
| 07:47 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has quit [Ping timeout: 121 seconds] |
| 07:50 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has joined #code |
| 07:53 | | Orthia [orthianz@3CF3A5.E1CD01.B089B9.1E14D1] has joined #code |
| 07:53 | | mode/#code [+o Orthia] by ChanServ |
| 08:23 | | Kindamoody is now known as Kindamoody|out |
| 08:25 | | * Vornicus should really, you know, Write Some Code. |
| 08:53 | < AverageJoe> | nah |
| 08:53 | < AverageJoe> | f that |
| 09:09 | | You're now known as TheWatcher |
| 09:24 | | Karono is now known as Karono[afk] |
| 09:27 | | ktemkin is now known as ktemkin[awol] |
| 09:51 | | AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving] |
| 09:51 | | Karono[afk] is now known as Karono |
| 09:54 | <&McMartin> | f() that |
| 09:56 | <~Vornicus> | clearly, f(that) |
| 10:03 | < Syka> | that.f() |
| 10:17 | < ErikMesoy> | f().that() |
| 10:17 | < Karono> | f->that(); |
| 10:31 | | * TheWatcher eyes you all |
| 10:34 | < Syka> | TheWatcher.eyes(that) |
| 10:40 | <@TheWatcher> | Tsk, no. `my $channel = Irssi::active_win -> {active}; foreach my $nick ($channel -> nicks()) { $self -> eye($nick); }` |
| 10:42 | <@TheWatcher> | Wait, no. I'm not really an Irssi bot. |
| 10:47 | | * TheWatcher sighs at these students |
| 10:47 | < Karono> | enraged teacher stories? I can never get enough of those |
| 10:47 | <@TheWatcher> | What do they have against checking the return values from functions? |
| 10:51 | <&McMartin> | Call-with-cthulhu-invocation! |
| 10:51 | | * McMartin ponders the questionable virtues of writing a JSON parser in Scheme on pen-and-paper during his flight tomorrow. |
| 10:52 | <@TheWatcher> | For extra marks*: write it in Enochian. |
| 10:53 | <@TheWatcher> | * or possibly extra shoggoths, either way. |
| 10:53 | <&McMartin> | I'm translating this C++ to C right now |
| 10:53 | <&McMartin> | Speaking of checking return values |
| 10:53 | <&McMartin> | I tell you what, I'm missing exceptions damned hard |
| 10:53 | < Reiver> | ... why would you do that McM |
| 10:53 | <&McMartin> | I want a DLL that can be linked against by others |
| 10:54 | <&McMartin> | C++ is kind of utter shit at this, even if everything you *intentionally* export is C-linker compatible |
| 10:54 | <&McMartin> | And even when you stay within C++, exceptions and DLLs don't mix without a serious chunk of Being Incredibly Fragile. |
| 10:55 | <&McMartin> | I started design on the next few levels of abstraction while playing with FFI tests and just decided the C++ game wasn't worth the candle |
| 10:55 | <&McMartin> | So I've got two source files to de-libstdc++. |
| 10:55 | <@TheWatcher> | Last night I disovered that the NewDark has been compiled with exceptions disabled. This explains some crashes I've caused >.> |
| 10:55 | <@TheWatcher> | -the |
| 10:56 | <&McMartin> | Since the only things I was making serious use of were std::list and std::map, and I've got C replacements for those now, I'm good to go. |
| 10:56 | <&McMartin> | TheWatcher: Yeah |
| 10:56 | <&McMartin> | Basically, if your DLL or .so was written including C++, stuff that links against you has to use not only the same compiler that you did, but the same *compiler options* |
| 10:56 | | Karono [Karono@10AAA2.FD2B33.6E253B.F190AF] has quit [Client closed the connection] |
| 10:57 | <&McMartin> | Whereas if I write it in C my library can be loaded by anything capable of making system calls. |
| 10:57 | | Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code |
| 10:57 | | * McMartin blinks |
| 10:57 | <&McMartin> | I'd hesitate to ask anyone else, but you'd know and also not put this fact to terrible use |
| 10:57 | <&McMartin> | How's Perl's C-import interface? |
| 10:59 | <@TheWatcher> | A shitton of standard perl modules are implemented in C |
| 10:59 | <&McMartin> | Yeah. That doesn't quite answer my question though >_> |
| 11:00 | <&McMartin> | Python and Scheme both basically have a module that lets you say "here is a shared binary name, and here is a C function prototype" and get back "here is a callable Python/Scheme object, go nuts" |
| 11:01 | <@TheWatcher> | Pretty much the same |
| 11:01 | <@TheWatcher> | perl has XS |
| 11:01 | <@TheWatcher> | You write an XS file for the library, compile it, and you get some gubbings you can basically just 'use Whatever' in your perl code, and talk to the library |
| 11:02 | <@Tarinaky> | iirc in Python you have to do unintuitive stuff to make the function's arguments work. |
| 11:02 | <@TheWatcher> | the XS file deals with mapping how the c library routines are used, and the types they take/return, and the stuff the perl code sees |
| 11:02 | <@Tarinaky> | Well, I say unintuitive. |
| 11:03 | <&McMartin> | There's always going to be a certain level of bullshit regarding how storage works |
| 11:03 | <&McMartin> | Which is why Monocle is designed to never pass anything more structurally complex than an intptr_t >_> |
| 11:05 | <@TheWatcher> | (I wasn't /entirely/ joking when I said that I could write perl bindings for Monocle. As long as it's not doing anything exotic, it should actually be easy to do. Whether it's something that /should/ be done is another matter) |
| 11:08 | <&McMartin> | (Yeah, once I get something worth making the bindings for I'm going to use it as a vehicle to explore FFIs) |
| 11:08 | <&McMartin> | (My 'I actually need this to work' is basically restricted to Python and Mono, though, and I know I've got those covered~) |
| 11:09 | | Karono [Karono@Nightstar-03f66622.optusnet.com.au] has quit [Client closed the connection] |
| 11:09 | | Karono [Karono@Nightstar-03f66622.optusnet.com.au] has joined #code |
| 11:20 | | Syloq [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Ping timeout: 121 seconds] |
| 11:21 | | Syloq [Syloq@B4EC54.59F324.016BDA.8CB0A3] has joined #code |
| 11:21 | | mode/#code [+o Syloq] by ChanServ |
| 11:32 | | Karono is now known as Karono[afk] |
| 11:37 | < RichyB> | McMartin: "never pass anything more structurally complex than an intptr_t" <3 |
| 11:37 | < RichyB> | Also makes Haskell bindings trivial... |
| 11:37 | < RichyB> | Also makes Javascript bindings (!) trivial... |
| 11:38 | < RichyB> | (There's a library called "js-ctypes" available to some Mozilla things.) |
| 11:39 | <&McMartin> | The Haskell bindings, sadly, aren't entirely trivial because they'll be Monadic As All Fuck |
| 11:39 | <&McMartin> | You'd want to shelter some of that away |
| 11:40 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Client closed the connection] |
| 11:46 | < RichyB> | Meh. Unless Monocle actually does significant amounts of stuff which is really pure computation, that's not an issue. |
| 11:46 | < RichyB> | "My entirely-IO-oriented library is stuck entirely in the IO monad!" is neither an antipattern nor a problem. |
| 11:48 | < RichyB> | There are some things that you'd want to do, like write lenses ("lenses" in Haskell are reified getter/setter pairs) for lots of attribute so that you can have nice syntax like "foo $= 2" instead of "setFoo 2" just to be idiomatic. |
| 11:48 | <&McMartin> | Hmm |
| 11:49 | <&McMartin> | So, there's an event loop. That's going to be highly monadic |
| 11:49 | <&McMartin> | One could imagine lenses |
| 11:49 | <&McMartin> | But one builds a collection of objects in Monocle and then lets them loose |
| 11:49 | <&McMartin> | It seems like that should be organizable as a non-monadic mapping function. |
| 11:49 | < RichyB> | It's actually really common in Haskell to have multi-level bindings to C libraries, where there's one package which just has the raw "foreign import ccall ..." statements in it, and another one which turns it into idiomatic Haskell. |
| 11:49 | <&McMartin> | Yeah |
| 11:50 | <&McMartin> | And there's a really obvious place to do that, for the update routines, which seem like they could reasonably be pure-functional |
| 11:50 | <&McMartin> | And then the rendering ones, which obviously would not |
| 11:50 | <&McMartin> | If you did it with lenses, then perhaps even the update routines would be monadic, dunno |
| 11:52 | < RichyB> | Oh, I might have misused the term "lens" because AIUI there are purely-functional equivalents to the concept I just named. |
| 11:52 | < RichyB> | getter/setter pairs are what I was talking about. |
| 11:52 | <&McMartin> | I still haven't thought those layers through fully |
| 11:53 | < RichyB> | Whoops yeah, I meant statevars. |
| 11:53 | <&McMartin> | But it is nearly 4AM, and I have an airplane trip tomorrow, so, z |
| 11:53 | < RichyB> | http://hackage.haskell.org/packages/archive/OpenGL/latest/doc/html/Graphics-Rend ering-OpenGL-GL-StateVar.html |
| 11:53 | < RichyB> | Sleep well, McM. |
| 11:56 | | Karono[afk] is now known as Karono |
| 11:58 | | * TheWatcher ughs, apparently needs more tea, just had terrible problems stopping himself spelling implementatatatation |
| 12:01 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 12:08 | < Reiver> | ... So, uh, at what point did OpenGL become Sufficiently Awesome to be a viable replacement for ActiveX on large-scale games? |
| 12:08 | <~Vornicus> | Um |
| 12:08 | <~Vornicus> | I presume you mean DirectX |
| 12:08 | <~Vornicus> | but the Quake engine has always been opengl. |
| 12:09 | < Syka> | Reiver: since... forever? |
| 12:09 | < Reiver> | DirectX, yeah. |
| 12:10 | < Syka> | Reiver: opengl has always been on par with directx - microsoft just don't want you to know that |
| 12:10 | < Reiver> | Syka: Hardly. |
| 12:10 | < Karono> | Also, the whole thing about DirectX being more than just Direct3D and such |
| 12:10 | <@TheWatcher> | Yeah |
| 12:10 | < Syka> | Reiver: no, it more or less has |
| 12:10 | < Reiver> | Technically, it was capable of doing everything ActiveX did, but it was a hell of a lot more finicky to work right. |
| 12:10 | <@TheWatcher> | OpenGL is arguably as good as or better than Direct3D |
| 12:10 | < Syka> | ...activeX? |
| 12:11 | < Reiver> | Fuuuck, my brain is miswired. Sigh. |
| 12:11 | | * Karono snerks at ActiveX again |
| 12:11 | <@TheWatcher> | But DirectX includes a lot more than just Direct3D |
| 12:11 | < Reiver> | DirectX. |
| 12:11 | < Syka> | yeah, opengl is on par/better than direct3d |
| 12:11 | < Reiver> | Assume any refeence to ActiveX for the next hour or so is in fact DirectX, I'm just tired~ |
| 12:11 | < Syka> | as far as sound systems, that's directsound, but I don't think anyone ever uses that directly |
| 12:12 | < Syka> | they wrap it in openal or some other thing by RAD Game Tools |
| 12:12 | < Reiver> | To put another way: OK, OpenGL could technically match Direct3D; but for a very long time game companies developed on DirectX because it was simply faster/easier on their end to get stuff shiny and performing right. |
| 12:13 | <@TheWatcher> | Well, more that with DirectX you get a bunch of things (like DirectInput) along for the ride |
| 12:13 | < Syka> | Reiver: bzzt |
| 12:14 | < Syka> | Reiver: one of the greatest graphics engines in history - iDTech - is OpenGL |
| 12:14 | < Reiver> | But as of late, it seems almost everyone and their dog will cheerfully use OpenGL - fss, Planetary Annihilation skipped DirectX entirely in favor of OpenGL to streamline development. I feel like I missed an inflection point in there somewhere, and I'm wondering when and what it was. |
| 12:14 | < Syka> | the reason they used DirectX was that it was better on *Windows* |
| 12:14 | <@TheWatcher> | The downside was that using it tied you to windows, yeah |
| 12:14 | < Syka> | OpenGL was sort of shafted by the driver developers and Microsoft |
| 12:14 | <@TheWatcher> | Reiver: the word you're looking for is "portability" |
| 12:15 | < Reiver> | ... oho? |
| 12:15 | < Syka> | Reiver: opengl has critical mass now |
| 12:15 | < Reiver> | So OpenGL became king when people decided Mac/Linux were worthy? |
| 12:15 | < Syka> | Android, iOS, Mac OSX, Linux, and even Windows |
| 12:15 | | * Reiver muses. |
| 12:15 | < Syka> | Reiver: DirectX also stagnated |
| 12:15 | < Syka> | DX9 was released in what, 2003 |
| 12:16 | < Reiver> | Syka: Yeah, I know it does. I'm wondering when and why and how it hit that point; it seems very much a chicken-and-egg scenario and I'm trying to find the egg. |
| 12:16 | < Syka> | DX10 was released with Vista, but nothing really supported it until DX11 in 7 |
| 12:16 | < Syka> | Reiver: oh yes, also |
| 12:17 | < Syka> | Reiver: PS3 is OpenGL, too |
| 12:17 | < Syka> | so Unreal supported it |
| 12:17 | < Reiver> | Even then, an awful lot of Unreal games ran on DX for an awful long time |
| 12:18 | < Syka> | that's because DirectX was better performing |
| 12:18 | < Syka> | see: MS shafting OpenGL |
| 12:18 | < Reiver> | Right, that's my point. |
| 12:19 | < Syka> | also, it's not like OpenGL was never used |
| 12:19 | < Reiver> | Be it via MS deliberately shafting or not, OpenGL simply had a hard time competing with DX for Serious Developers On Big Projects for a long time |
| 12:19 | <@Tamber> | Reiver, Serious Developers On Big Windows Projects. |
| 12:19 | < Reiver> | I mean yeah, there's always exceptions, but the general trend was DX All The Way. |
| 12:19 | < Syka> | ...are you calling Doom Fucking 3 a non-Big Project |
| 12:19 | < Syka> | let me say that again |
| 12:20 | < Syka> | IDTECH WAS OPENGL |
| 12:20 | < Syka> | *iDTech* |
| 12:20 | < Reiver> | Syka: And IDTech is a rather long time ago, and failed to revolutionise the industry standards. :p |
| 12:20 | <@Tamber> | Hey, Syka; get down off the impotent raeg horse. "Had a hard time" != "Never, ever, ever used" |
| 12:20 | < Syka> | Reiver: ... |
| 12:20 | | * TheWatcher blinks at Reiver |
| 12:20 | < Syka> | you're kidding, right |
| 12:20 | <@TheWatcher> | um |
| 12:20 | | * Karono just, um, walks away or something |
| 12:21 | | * Karono doesn't even know |
| 12:21 | | * Reiver patpat TW, will stop that. Merely found Syka's exuberance a little too tempting. Moves on. |
| 12:21 | <@TheWatcher> | Uh-huh |
| 12:21 | < Syka> | I will beat you with Quake 2's legacy until you come out speaking Strogg |
| 12:21 | <@Tamber> | Don't poke the rageburd. |
| 12:22 | | * Tamber hides the jabby-stick. |
| 12:22 | < Reiver> | Tamber: But I has a stick and everything~ |
| 12:22 | | * Azash gives everyone soothing pats |
| 12:22 | <@Azash> | What are we melting down about? |
| 12:22 | <@Tamber> | Everything. |
| 12:22 | <@Tamber> | (So, y'know, the usual~) |
| 12:22 | <@Azash> | Excellent |
| 12:22 | <@Azash> | Then I can melt down about this auto parts store's incredibly bad new webstore |
| 12:23 | <@Azash> | Actually I'm just going to implode |
| 12:23 | <@Tamber> | Azash, really want a meltdown? Have you seen what netcraft have done with their site? |
| 12:23 | < Syka> | right |
| 12:23 | < Reiver> | OK, so. Unless IDTech actually /was/ the inflection point (Which I doubt, given Unreal+DX's dominance in the market for a great many years, unless a crapload of things have been using the engine and I've just missed it somehow) |
| 12:23 | <@Tamber> | (I know, I'm late to notice again; but holy shit, it's bad.) |
| 12:23 | <@Azash> | Tamber: A couple of points |
| 12:23 | <@Azash> | First, their CS reps are entirely blocked from viewing orders by customer name |
| 12:24 | <@Azash> | Also as a friendly launch bunch, all prepaid orders are charged in advance then automatically mailed as COD |
| 12:24 | <@Tamber> | ... |
| 12:24 | <@Azash> | s/bunch/bug/ |
| 12:24 | < Syka> | Reiver: BTW |
| 12:24 | < Syka> | Reiver: the world's biggest game series uses iDtech |
| 12:25 | < Reiver> | As noted, sure, DX ruled supreme on Windows Projects. But there's a chicken and the egg thing there - did stuff shift to OpenGL because portability became desirable, or did portability become desirable becuse OpenGL was good enough that you'd use it in preferece, and portability came as part of the package? |
| 12:25 | < Reiver> | Syka: Call of Duty? |
| 12:26 | < Syka> | Reiver: yep |
| 12:26 | < Syka> | well it uses bits of idtech |
| 12:26 | < Syka> | they split like 10 years ago |
| 12:26 | < Syka> | (idtech is a technical base) |
| 12:27 | < Reiver> | Hum. Does it run OpenGL? |
| 12:27 | < Syka> | yes |
| 12:27 | < Syka> | CoD's primary platforms are the Xbox and PS3 |
| 12:27 | < Syka> | the latter requires they do |
| 12:27 | <@TheWatcher> | Reiver: because portability became desirable, mainly. There have always been users of opengl, and pretty much all of them either were explicitly multiplatform or written with an eye to be. |
| 12:28 | <@TheWatcher> | If you were a windows-only developer, working on a project you never expected to be ported to anything else, you'd use Direct3D simply because it was there, it worked, and you got the rest of DirectX along with it (especially DirectInput). |
| 12:29 | <@Tamber> | Reiver, I suspect it was the former. OpenGL was -- and correct me if I'm wrong -- The Standard for anything other than Windows projects; so if you were doing, say, 3D rendering crud on a UNIX, chances are you'd be using OpenGL. (...which is, really, what it was *for*) But if you tried to use the same code on Windows, it'd probably hurt (Either out of lack of proper [...] |
| 12:29 | <@Tamber> | [...] hardware acceleration (Which is the biggest one. OpenGL was written assuming hardware accel. Direct3D was written assuming there wasn't any, but used it if there was.), lack of optimisation, or deliberate meddling. Pick whichever you favour~) |
| 12:29 | < Reiver> | TheWatcher: Aha, sweet, OK |
| 12:29 | < Reiver> | TheWatcher: So what brought about the Portability Revolution? |
| 12:29 | | * Tamber also nods and hammers "Not Fucking With the Ecosystem" into the list of stuff. :D |
| 12:29 | < Reiver> | Is this 'when Macs started showing up on Steam' timeframe, or...? |
| 12:29 | <@TheWatcher> | Consoles |
| 12:29 | < Syka> | Tamber: yes, opengl was The Standard |
| 12:30 | < Syka> | since OpenGL was originally made by Silicon Graphics, IIRC |
| 12:30 | <@Tamber> | Yup |
| 12:30 | < Syka> | and then handed over to the Khronos Group |
| 12:30 | < Reiver> | ... can't be, DX ruled for most of the XBox/XBox360 era, didn't it? |
| 12:30 | <@Tamber> | Reiver, that's the exception, surely~? |
| 12:30 | < Reiver> | Then the 360 started getting, uh, crusty. |
| 12:30 | < Syka> | Reiver: everything serious used OpenGL |
| 12:30 | <@Tamber> | (...and you really think Microsoft would give in to a competitor's standard on a flagship product? :p) |
| 12:31 | < Syka> | eg. your movie effects and shit |
| 12:31 | < Reiver> | Syka: Oh, I know that much, yes. But that wasn't gaming. |
| 12:32 | <@TheWatcher> | Reiver: I suspect that it's honestly more complicated than a single thing. The fact that the PS3 used OpenGL would have been part of it, expansition in mac and linux gaming would be another |
| 12:32 | < Syka> | well, Half Life, which pretty much invented the Good Story FPS, used a hacked together idtech 2 |
| 12:32 | <@Tamber> | (Plus, if it used roughly the same software ecosystem as the PC, then *in theory* you could get your games to work on both with minimal skullfuckery. Or at least only a *small* forest of #ifdefs =) |
| 12:32 | < Reiver> | I more mean that for a long time on windows PCs, 'install a game' had 'and also update your DX' were nearly synonyms |
| 12:32 | < Syka> | Source still has bits of idtech 1 in there~ |
| 12:32 | < Syka> | Reiver: that's because directx is stupid |
| 12:32 | <@TheWatcher> | Syka: LIES!~ |
| 12:32 | < Syka> | and you built agianst point releases |
| 12:32 | <@TheWatcher> | (at least, that's what Valve'd like to think...) |
| 12:33 | < Syka> | TheWatcher: huh? |
| 12:33 | < Syka> | no, gaben says that directly |
| 12:33 | < Reiver> | Syka: Yes, that's nice. I'm not picking sides here, just tracking historics. |
| 12:33 | < Syka> | he says there's still bits of Quake in there :P |
| 12:33 | < Syka> | not a lot, but there's still a few Hard Problems that iDtech fixed |
| 12:33 | <@TheWatcher> | Syka: Huh, really? Last I heard they were vehemntly denying it, 'about time they admitted it though |
| 12:33 | < Reiver> | And then, in the past few years, you... don't. |
| 12:33 | < Syka> | because early Carmack was a fucking genius |
| 12:33 | <@Tamber> | Reiver, that was the most annoying thing about that. DX and other various runtimes, anyway. "Look, it's a standard runtime so you don't have to install a shittonne of runtime support crap with every game!" *has to install slightly different versions of the runtime support crap with every game* |
| 12:34 | | * Tamber glares at the VC runtimes. |
| 12:34 | < Syka> | TheWatcher: "Source distantly originates from the GoldSrc engine, itself a heavily modified version of John D. Carmack's Quake engine, as is explained by Valve employee Erik Johnson on the Valve Developer Community" |
| 12:34 | < Reiver> | And then the Big Boy Games including things like PlanetaryAnnihilation (WHich granted, is a mid-scale project, but by a Serious Team), go, nearly literally, "...DirectX? Why the heck would we use that? OpenGL ftw" |
| 12:34 | < Reiver> | And I go "... whoa, when did /that/ wind shift?" |
| 12:35 | < Syka> | "John Carmack commented on his blog in 2004 that "there are still bits of early Quake code in Half-Life 2"" |
| 12:35 | < Syka> | Reiver: uh |
| 12:35 | < Syka> | I don't think Planetary Annihilation counts as a Big Serious Game |
| 12:35 | <@Tamber> | Everything's all built on the crumbling, hastily-propped up remains of everything that went before it. |
| 12:35 | < Reiver> | Syka: No, but it is being built by people who tend to lean heavily on Big Serious Tools to get shit produced. |
| 12:36 | < Syka> | Reiver: most people just use an engine |
| 12:36 | < Syka> | they license Unreal, hack their shit on top, and release the game |
| 12:36 | < Reiver> | Right. |
| 12:36 | < Syka> | nowadays, they license Unity |
| 12:36 | < Reiver> | And somewhere in there, everyone stopped using DX as part of the engine stack. |
| 12:37 | < Syka> | well, no |
| 12:37 | < Syka> | they don't CARE about the engine stack |
| 12:37 | < Reiver> | Once apon a time, *not* using DX would have been noteworthy. |
| 12:37 | < Syka> | that's why they licensed it |
| 12:37 | <@Tamber> | I believe that, if you go and license one of the big engines, it's relatively* painless** to change out whether you're using D3D or OpenGL. |
| 12:37 | < Syka> | Tamber: it depends |
| 12:37 | < Syka> | I think with Unreal it is |
| 12:37 | < Reiver> | I was wondering mostly at what point this shift happened. |
| 12:37 | < Syka> | since you write your stuff in Unreal-specific stuff |
| 12:38 | <@Tamber> | * "compared to swallowing ground glass and scorpions" ** will only make you scream for months, after that, your brain is too numb to care any more. |
| 12:38 | < Syka> | Reiver: it's just always happened |
| 12:38 | < Syka> | openGL has always been *there*, because it's on the PS3 |
| 12:38 | | * Reiver sighs. |
| 12:38 | < Reiver> | Yes, yes, I know. |
| 12:38 | < Syka> | people just did the right thing |
| 12:38 | < Syka> | and had the engine take care of the GL |
| 12:38 | < Syka> | swappable back ends |
| 12:39 | < Syka> | if you had that, it doesn't *matter* what GL you're using |
| 12:39 | < Reiver> | Realise your arguement is coming across as Q: "Hey, when did people start actively prefering OpenGL to DirectX" A: "OpenGL was always awesome and was used the whole time" |
| 12:40 | < Syka> | your question is like "when did people start actively preferring AMD64 to i386" |
| 12:41 | | * Tamber sighs, drops a lot of very heavy SGI boxes (from the department of redundancy department) on the conversation. |
| 12:41 | < Syka> | AMD64 support was pretty much always there, people just flicked GCC to use it |
| 12:41 | < Reiver> | ... |
| 12:41 | < Syka> | (always as in 'since amd64 chips existed') |
| 12:41 | < Syka> | the analogy doesnt quite work |
| 12:41 | < Syka> | since technically OpenGL came first |
| 12:42 | <@Tamber> | ...the worst thing is, it's better than your usual analogies. |
| 12:42 | | * Reiver wanders off. |
| 12:42 | < Syka> | Reiver: OpenGL was always there, and always being used - it's just that nowadays, people go 'WHOO OPENGL' rather than putting it as a bullet point in the engine specs |
| 12:43 | < Syka> | because what people did was write an engine, and the engine would have pluggable backends for the different renderers, for targeting different platforms |
| 12:43 | < Syka> | people are going 'whoo opengl' for the /portability PR/ even though /loads of engines already did it/ |
| 12:44 | < Syka> | it's like advertising that the particular model of desktop you have has USB3 built in, even though that's standard in Ivy Bridge chipsets |
| 13:05 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 13:05 | | mode/#code [+o himi] by ChanServ |
| 13:30 | | * ToxicFrog upreads |
| 13:32 | <&ToxicFrog> | Reiver: yes, for something like 2003-2010, DX-only games on PC were extremely common; at this time DX9/10/11 had pulled ahead of OGL feature-wise and mac/linux weren't seen as viable gaming platforms, so unless you were doing a PC+PS3 game - itself rare - a lot of developers went to DX. |
| 13:32 | <&ToxicFrog> | This also coincided with ATI and nV OGL support being shit, although it's hard to say what the cause/effect is there. |
| 13:32 | < Reiver> | Right. |
| 13:33 | <&ToxicFrog> | These days, OGL has caught up a lot and portability across PC platforms is seen as a bigger concern, and the driver situation has improved. |
| 13:33 | <&ToxicFrog> | Result: a resurgence in games using dual OGL/DX or pure OGL rendering stacks. |
| 13:34 | <&ToxicFrog> | I note that the 360 does not support OGL, and there are way more PC/360 games than PC/PS3 because porting between those two is so much easier; all of those games use DX. |
| 13:34 | < Reiver> | Interesting. Did anything drive this catchup, or was it more tht DX stagnated? |
| 13:35 | <@gnolam> | Correction: "pulled ahead of OGL feature-wise" "pulled ahead of /core/ OGL feature-wise". |
| 13:35 | <&ToxicFrog> | Granted. |
| 13:35 | <@gnolam> | OpenGL will always let you have accesss to the latest and greatest inventions. It's just that you'll have to write separate code paths for different vendors. |
| 13:36 | <&ToxicFrog> | Reiver: OGL 2.0 and 3.0 came out introducing a bunch of new stuff, Valve leaned on GPU manufacturers to unfuck their drivers, increasing numbers of indie developers building stuff for minimum budget and maximum portability. |
| 13:37 | <&ToxicFrog> | Wolfire Games has some interesting stuff on the OGL/DX wars; as recently as three years ago they were getting reactions of shock and dismay from both other developers and video card manufacturers when they said they used OGL for all their games. |
| 13:38 | < Reiver> | Yes, that was much the status of OpenGL for a while as I understood it, Syka's protelisations aside~ |
| 13:38 | < Reiver> | (Who are Wolfire games?) |
| 13:40 | <&ToxicFrog> | (Lugaru, Receiver, Overgrowth) |
| 13:40 | < Syka> | the guys behind humble indie bundle |
| 13:40 | < Syka> | iirc |
| 13:40 | < Syka> | i think humble bundle was originally a wolfire thing |
| 13:40 | <&ToxicFrog> | The first one was, then they spun up a separate company to manage them |
| 13:42 | < Reiver> | Right. |
| 13:54 | <&ToxicFrog> | Aah, this is the artcile I was thinking of: http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX |
| 14:20 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 14:27 | | celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has joined #code |
| 14:27 | | mode/#code [+o celticminstrel] by ChanServ |
| 14:45 | | * TheWatcher ...s |
| 14:45 | <@TheWatcher> | Why had I never run into mintty before? |
| 14:55 | <@Azash> | https://github.com/blog/1547-release-your-software |
| 14:58 | <&ToxicFrog> | Sweeeeeeeeeeeeeeeeeeeeeeeeet |
| 15:18 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code |
| 15:20 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 15:21 | | celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 15:21 | | celticminstrel [celticminst@Nightstar-8403057e.dsl.bell.ca] has joined #code |
| 15:21 | | mode/#code [+o celticminstrel] by ChanServ |
| 15:49 | < [R]> | http://xiennith.com/wtf.txt |
| 15:49 | < [R]> | (JS) |
| 15:51 | <@TheWatcher> | That appears to missing important bits |
| 15:51 | <@TheWatcher> | like the definition of a |
| 15:52 | < [R]> | Done |
| 15:52 | < [R]> | Updated rather |
| 15:54 | < [R]> | a = new Array(5) |
| 15:54 | <@TheWatcher> | Interestingly, it behaves differently for me in opera |
| 15:55 | | VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 15:55 | <@TheWatcher> | http://pastebin.starforge.co.uk/572 |
| 15:56 | <@TheWatcher> | actually, no, I think opera is just hiding the empty array |
| 15:56 | <@TheWatcher> | so it behaves the same |
| 15:56 | | * TheWatcher shrug |
| 15:56 | <@TheWatcher> | Javascript. |
| 15:57 | <@TheWatcher> | Oh, wait, here we go |
| 15:57 | <@TheWatcher> | "callback is invoked only for indexes of the array which have assigned values; it is not invoked for indexes which have been deleted or which have never been assigned values." |
| 15:58 | < [R]> | Lovely |
| 15:58 | < [R]> | Guess I can't one-line this. |
| 15:58 | | VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds] |
| 15:58 | < [R]> | All I wanted was an array with size X filled with values Y D: |
| 16:03 | <@Azash> | What language? |
| 16:04 | <@Azash> | Oh JS |
| 16:09 | < [R]> | Oh well, I've got it working now :) |
| 16:09 | | * Azash wonders if any language has arrays that can do a binary operation over every element |
| 16:10 | < [R]> | Uhh? |
| 16:10 | < [R]> | Pretty much all of the ones that have arrays and binary operators can? |
| 16:10 | < [R]> | Unless you meant with sugar. |
| 16:10 | <@Azash> | I mean like |
| 16:10 | <@Azash> | array2 = array XOR integer |
| 16:10 | <@Azash> | For example |
| 16:11 | <@Azash> | If this is a common feature I will have the sads |
| 16:12 | < [R]> | a.map(function(n) { return n ^ 4 }) // close as JS gets. But seeing as binops are rarely called I don't see why that should be a first-class thing. |
| 16:13 | <@Azash> | It's more a thought that popped up |
| 16:13 | < ErikMesoy> | Azash: numpy |
| 16:13 | <@Azash> | Python, hissss |
| 16:14 | < ErikMesoy> | "Numpy" is a very silly-sounding name. |
| 16:14 | <@Azash> | Nincompyp |
| 16:14 | <&ToxicFrog> | Azash: a lot of languages let you implement something like that using operator overloads. APL has that as a builtin. |
| 16:15 | <&ToxicFrog> | Generally you'd just use map, though. |
| 16:15 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 16:15 | | mode/#code [+o Alek] by ChanServ |
| 16:15 | <@Azash> | Right |
| 16:54 | | Kindamoody|out is now known as Kindamoody |
| 17:08 | <@iospace> | ... i have two 24 inch monitors at work... and i still feel like i need another one Dx |
| 17:10 | < Syka> | hey iospace |
| 17:10 | < Syka> | iospace: https://dl.dropboxusercontent.com/u/14290114/IMG_20130110_183110.jpg |
| 17:10 | < Syka> | :3 |
| 17:12 | <@iospace> | Syka: are you doing low level development at work with a 4 data sheets open right now? ^_^ |
| 17:13 | < Syka> | iospace: no, I am doing high level development in my home office with no pants on |
| 17:13 | | * iospace golf claps |
| 17:13 | < Syka> | :3 |
| 17:14 | <@iospace> | i'm working on an i7 BIOS right now, specifically an SMBus driver for a FPGA attached to the board |
| 17:15 | | * iospace shrugs |
| 17:21 | | Kindamoody is now known as Kindamoody|out |
| 17:33 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 17:33 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 17:36 | | Derakon[AFK] [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 17:41 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 17:42 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 17:42 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 18:32 | | AnnoDomini [abudhabi@Nightstar-cc35cb3c.adsl.inetia.pl] has quit [Ping timeout: 121 seconds] |
| 18:35 | | abudhabi [abudhabi@Nightstar-c53de59e.adsl.inetia.pl] has joined #code |
| 18:36 | | abudhabi is now known as AnnoDomini |
| 18:44 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [Ping timeout: 121 seconds] |
| 19:22 | <&ToxicFrog> | Oh what is this nonsense |
| 19:22 | <&ToxicFrog> | They're planning a power outage this weekend |
| 19:22 | <&ToxicFrog> | I don't want to have to restart all my terminals! |
| 19:26 | | Karono [Karono@Nightstar-03f66622.optusnet.com.au] has quit [[NS] Quit: ] |
| 19:35 | | ktemkin[awol] is now known as ktemkin[work] |
| 19:49 | | * McMartin eyes this code. |
| 19:50 | <&McMartin> | I have to choose between a function hundreds of lines long, but with like three levels of indentation max, or a dozen-odd functions with kind of arbitrary arguments, none of which are exported and all of which are called exactly once. |
| 19:50 | <&McMartin> | These are *both* bad code smells. |
| 19:53 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 19:53 | | mode/#code [+o Alek] by ChanServ |
| 19:54 | <@froztbyte> | haha |
| 19:54 | <@froztbyte> | fun times |
| 19:56 | <&McMartin> | I think I'm going to go for the former; one of the reasons all these functions are called exactly once in the first place is that I'm trying to not cache anything and also present an incredibly simple interface. |
| 19:57 | <&McMartin> | Oh, hm |
| 19:57 | <&McMartin> | I could have the refactored functions have the interface "you pass it a file pointer and it returns success or failure. If it returned success, then the file pointer has been fseek()ed to {semantically important thing}" |
| 19:57 | <&McMartin> | ... I'm honestly not sure if that's better or worse |
| 20:06 | | Kindamoody|out is now known as Kindamoody |
| 20:11 | < ktemkin[work]> | Wrap the file pointer in an object, and have it maintain state? |
| 20:11 | <&McMartin> | (a) this is C, (b) that's kinda what FILE * is already |
| 20:12 | < ktemkin[work]> | b) Right, but the state is meaningful in terms of the position in the file, not in terms of your semantic tokens. |
| 20:13 | < ktemkin[work]> | a) Okay, I assumed C++, and that would make the pattern I had in mind just as ugly as the above. |
| 20:13 | <&McMartin> | Right, the reason all of these look about the same is because none of this state leaves the translation unit |
| 20:16 | <&McMartin> | (This is a thin wrapper around zlib to index into a zip file and pull out and re-inflate data into a buffer) |
| 20:16 | <&McMartin> | (So the "state" is generally "I found the indexing information for (X)") |
| 20:16 | <@iospace> | and... that's a bug knocked down |
| 20:16 | <&McMartin> | (So the API could be "seek file pointer X to (Y)") |
| 20:22 | < ktemkin[work]> | (I /should/ have assumed C, given your return scheme above; that only makes sense if you lack exception handling.) |
| 20:25 | < ktemkin[work]> | Of the options you've said above, the single long function gives you the least ability to test. |
| 20:30 | | Kindamoody is now known as Kindamoody|out |
| 20:32 | <&McMartin> | Kiiinda |
| 20:32 | <&McMartin> | These steps don't exist in a vaccuum |
| 20:32 | <&McMartin> | You can't test 3 unless you have already done the work for step 2 |
| 20:33 | <&McMartin> | You can thus take a set of unit tests for steps 1-5 and turn them into an equivalent set of systemic tests |
| 20:34 | < ktemkin[work]> | If you're testing based on a known piece of reference data, shouldn't your seek offsets be constants? |
| 20:35 | < ktemkin[work]> | You'd be able to test the individual pieces by manually seeking to the location of the appropriate data, and then calling the UUT. |
| 20:36 | < ktemkin[work]> | (Unless you have other side effects that are more difficult to recreate.) |
| 20:36 | <&McMartin> | I'm finding a file in a .zip archive. |
| 20:36 | <&McMartin> | So the other part of this is "this really isn't *that large a problem* beyond step 1; it's basically "read from offset, seek to that location" |
| 20:37 | <&McMartin> | Step 1 is the one that I threw a lot of insane corner cases at but it's also fundamentally unsolvable because the spec is broken~ |
| 20:37 | <&McMartin> | ZIP has a footer instead of a header, to make self-extractors work. |
| 20:37 | <&McMartin> | This footer is (a) variable length, (b) has its magic number at the *beginning* of this footer, which means that you have to do a backwards scan, and (c) includes a comment field at the end that may contain arbitrary data |
| 20:38 | <&McMartin> | I am adding in the unstated requirement "ZIPfile comments are not permitted to contain the ZIP footer magic number" |
| 20:38 | < RichyB> | (*) |
| 20:38 | < RichyB> | ZIP's use of a footer instead of a header also allows you to start streaming huge ZIP files to tape without necessarily having read all of your input yet. |
| 20:39 | <&McMartin> | That initial scan is really the only part that isn't "trust libc to do its job" or "trust zlib to do its job" |
| 20:39 | <&McMartin> | RichyB: There's also tape-archive-like inter-file quasiheaders |
| 20:39 | < RichyB> | Yes. |
| 20:39 | <&McMartin> | This also makes disk-spanning work semi-well. |
| 20:39 | < RichyB> | Importantly, nothing has a "length" field except the footer. |
| 20:39 | <&McMartin> | But only semi-well. |
| 20:40 | < RichyB> | Remembering that PKZIP was designed in the days of rollicking-slow floppy disk drives... |
| 20:40 | <&McMartin> | Since I'm not writing a ZIP file *verifier* I'm using the footer exclusively. |
| 20:40 | <&McMartin> | * |
| 20:41 | <&McMartin> | (The footer includes link to a central directory structure that is traditionally kept at the end of the file but it can actually be anywhere) |
| 20:41 | < RichyB> | You can actually stream files-to-be-archived in at one end, stream output-to-tape at the other end, and have to keep only enough storage in the middle to store the current DEFLATE compressor state and the dictionary of filenames and lengths. <3 |
| 20:41 | <&McMartin> | Yup |
| 20:41 | <&McMartin> | ZIP is an almost entirely sensible format. |
| 20:42 | <&McMartin> | The one thing it did disastrously wrong is not put the magic number and and link to the real data as a 12-byte fixed-length footer. |
| 20:42 | | Kindamoody|out is now known as Kindamoody |
| 20:47 | <&McMartin> | Anyway, this means that the three basic components to test, at the end of the day, are "can you find the central directory", "can you find a file *in* the central directory", and "did you configure zlib properly to re-inflate things right" |
| 20:48 | <&McMartin> | I am unconvinced that one gains anything by manually seeking to the start of the central directory to test the "find a file in the central directory" portion. It seems much more sensible to me to first sort out finding the central directory and then relying on that as infrastructure for the second test. |
| 20:52 | <&McMartin> | I guess you gain the ability to test the "find start of central directory" part without moving on to the rest, but those are smoke tests. |
| 20:53 | <&McMartin> | Those happened when I sketched out the original implementation of this in C++. The part I'm doing now is more "refactoring it so I don't rely on exceptions" |
| 20:53 | <&McMartin> | Since that was the only C++ feature this part really used, except for some std::vectors of fixed size within a function call. |
| 20:55 | < ktemkin[work]> | I don't think the argument for orthogonal unit tests is only based on the idea that a failing dependency prevents you from testing dependent functions. |
| 20:57 | < ktemkin[work]> | In general, the isolation between them assures you that your dependent functions don't "rely on" side effects generated by the dependencies. |
| 20:57 | < ktemkin[work]> | In your case, what you're doing is simple enough that you're likely aware of all of the side effects, so you may not /really/ gain anything by making your tests orthogonal. |
| 20:57 | <&McMartin> | More sharply, I'm deciding on how to functionally decompose this in the first place. |
| 20:58 | <&McMartin> | By the standard you propose, this really *should* all be one function, because they're all inextricably bound. |
| 20:58 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: bbl] |
| 20:58 | <&McMartin> | Except for "OK, deflated data begins here", but that's a boundary between not only functions but modules, and I'm trusting zlib here =P |
| 21:01 | < ktemkin[work]> | (Of course, I don't think that pointing out a benefit of any particular course of action is the same thing as advocating that course of action.) |
| 21:02 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 21:02 | | mode/#code [+o Alek] by ChanServ |
| 21:04 | <&McMartin> | Yeah |
| 21:04 | <@Alek> | Nope |
| 21:04 | <&McMartin> | SHORYUKEN |
| 21:06 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: brb] |
| 21:10 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 21:10 | | mode/#code [+o Alek] by ChanServ |
| 21:12 | | Kindamoody is now known as Kindamoody[zZz] |
| 21:13 | | Turaiel[Offline] is now known as Turaiel |
| 21:23 | | Derakon_ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 21:23 | | * Derakon_ eyes his serializer. Uh oh. |
| 21:23 | < Derakon_> | "RuntimeError: Attempted to serialize unrecognized object type <type 'cython_function_or_method'>" |
| 21:37 | < Derakon_> | (That is, while my serializer seems to work fine for pure-Python method and object references, it has no clue what to do about Cython methods). |
| 21:44 | < Derakon_> | Oh hm, this only happens for lambdas within Cythonized code, apparently. |
| 21:44 | < Derakon_> | And I can't serialize lambdas anyway. |
| 22:03 | | Courage [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 22:03 | | mode/#code [+o Courage] by ChanServ |
| 22:05 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 22:21 | | Derakon__ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 22:21 | | Derakon__ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [[NS] Quit: leaving] |
| 22:22 | | Turaiel is now known as Turaiel[Offline] |
| 22:23 | | Derakon_ [chriswei@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:24 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:25 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 22:25 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 22:37 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 22:38 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 22:38 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 22:49 | <@Tarinaky> | I'm having difficulty working out how to set the 'target' for OpenGL calls in PyGlet. |
| 22:49 | <@Tarinaky> | Say if I want to rasterise something offscreen to disk and write it out as a bitmap? |
| 22:57 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has quit [Operation timed out] |
| 22:57 | | Derakon [Derakon@Nightstar-a3b183ae.ca.comcast.net] has joined #code |
| 22:57 | | mode/#code [+ao Derakon Derakon] by ChanServ |
| 23:03 | <@Tarinaky> | Oh sod it. I don't need to do this anyway :/ |
| 23:07 | | gnolam_ [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has joined #code |
| 23:07 | | gnolam is now known as NSGuest7027 |
| 23:07 | | gnolam_ is now known as gnolam |
| 23:07 | | mode/#code [+o gnolam] by ChanServ |
| 23:09 | | ErikMesoy is now known as ErikMesoy|sleep |
| 23:11 | | NSGuest7027 [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has quit [Ping timeout: 121 seconds] |
| --- Log closed Thu Jul 04 00:00:32 2013 |