| --- Log opened Thu Oct 12 00:00:59 2006 |
| 00:01 | | caps[t-1] [~sam@Nightstar-16870.range81-156.btcentralplus.com] has quit [Quit: Chocolate is our only weakness!] |
| 00:13 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has joined #code |
| 00:37 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Killed (NickServ (GHOST command used by Forj))] |
| 00:37 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 00:38 | | mode/#code [+o Chalcy] by ChanServ |
| 00:40 | | Chalcy is now known as Chalcedon |
| 01:14 | | You're now known as TheWatcher[T-2] |
| 01:17 | | You're now known as TheWatcher[zZzZ] |
| 01:25 | | MSminion [~sysop@Nightstar-6915.hsd1.or.comcast.net] has joined #code |
| 01:28 | < MSminion> | Two functions: foo() and bar(). foo() calls bar() to perform an operation. bar() needs to return some amount of data, but how much data (how many bytes) is not known until bar() runs. Since foo() needs to use the data, the deallocation has to happen in foo() scope at lowest. |
| 01:29 | < MSminion> | By the rule that allocation and deallocation happen in the same scope, then, foo() should be allocating the memory too. But only bar() knwos how much. |
| 01:29 | < MSminion> | Ugly designs that could fix this: |
| 01:29 | < MSminion> | call bar() twice. First return how many bytes |
| 01:30 | < MSminion> | Have bar() allocate and foo() deallocate |
| 01:30 | <@Vornicus> | C, or C++? |
| 01:30 | <@McMartin> | Um, that second one isn't ugly at all, it's hugely traditional. |
| 01:30 | < MSminion> | C++ |
| 01:30 | <@Vornicus> | oh, well, hell. |
| 01:30 | <@McMartin> | It's called a "factory method". |
| 01:30 | <@Vornicus> | bar returns an /object/ |
| 01:30 | <@McMartin> | bar can just kind of, like, be a constructor. |
| 01:30 | < MSminion> | McMartin: It also runs into some really hideous problems. Especially when bar() is in a different lib than foo() and they potentially use different allocators. |
| 01:30 | <@Vornicus> | and the object takes care of the allocation and deallocation. |
| 01:31 | < MSminion> | And it does some ugly pattern breaking if bar() is both a factory and a number crunching algorithm. |
| 01:31 | <@McMartin> | MSminion: Have your destructor be virtual, and delete() should always be right. |
| 01:32 | <@McMartin> | I'm pretty sure that "This method returns a dynamically allocated object that must be delete()d by the caller" is a perfectly valid constraint. |
| 01:32 | < MSminion> | (In the current case, bar() allocates with HeapAlloc() in a private DLL, but I can change this if need be) |
| 01:32 | <@McMartin> | If the destructor for whatever bar returns is not virtual, thus producing allocator problems on destruction, your task is to find the creator of the library and set him on fire. |
| 01:32 | < MSminion> | new/delete are per-instance of CRT, and are NOT guaranteed to cooperate across a dll boundary. |
| 01:33 | <@McMartin> | Then you've divided your DLLs wrong. |
| 01:33 | < MSminion> | heh |
| 01:33 | < MSminion> | If I had time to refactor the whole fscking thing, I'd start over and do it right. I didn't do the DLLs. I'm performing what is called "maintenance programming" on someone else's code. |
| 01:33 | <@McMartin> | Alternatively, have a traditional unmodified new() and delete(), and have the constructor do its HeapAlloc thing, and your destructor do the HeapDealloc thing. |
| 01:34 | <@McMartin> | Unless CRT doesn't guarantee destructor calls, in which case go to your boss and ask to migrate from pretend C++ to real C++. |
| 01:35 | < MSminion> | Nah. It's the same compiler. The problem with new/delete (and to a lesser extent, with HeapAlloc/HeapFree) is not that they're implemented differently, but rather that they may be operating on separate heaps. |
| 01:35 | | Reiver is now known as ReivWork |
| 01:36 | <@McMartin> | MSminion: That wasn't what I meant. |
| 01:37 | <@McMartin> | I meant that all calls to HeapAlloc/HeapFree would be inside one DLL |
| 01:37 | < MSminion> | Ahh. |
| 01:37 | | * MSminion ponders |
| 01:37 | <@McMartin> | And if you can't delete() what is new()ed in a separate DLL, your C++ implementation is Fucking Broken. |
| 01:37 | <@McMartin> | And won't link, for instance, SDL. |
| 01:37 | < MSminion> | Current implementation is that bar()'s data is simply bare bytes. I'd have to wrap it in an object of some sort. But that shouldn't be a problem. Just added complexity. |
| 01:38 | <@Vornicus> | ...and apparently hope to god that your regression tests work. |
| 01:38 | <@McMartin> | All Problems Can Be Solved With An Additional Layer Of Indirection. |
| 01:38 | < MSminion> | If you new() raw bytes in one DLL, and then you delete() those bytes in another, and both DLLs are statically linked to the CRT, then indeed you get separate heaps, and it doesn't work. |
| 01:38 | < MSminion> | Vorn: regression what? |
| 01:39 | <@McMartin> | Uh, wouldn't that be "new[]" and "delete[]"? |
| 01:39 | <@Vornicus> | oh, yeah, you're the one working on new shit. |
| 01:39 | <@McMartin> | AFAIK you can only "new" objects. |
| 01:40 | < MSminion> | Could also be new()/delete(). Same thing if you new SOME_LARGE_STRUCT in DLL X and then delete() it in DLL Y |
| 01:40 | <@McMartin> | ... again, assuming that your destructors are virtual, that had better work. |
| 01:40 | <@McMartin> | And nonvirtual destructors are Always An Error. |
| 01:40 | < MSminion> | http://windowssdk.msdn.microsoft.com/en-us/library/ms713497.aspx <-- SOME_LARGE_STRUCT |
| 01:41 | <@ToxicFrog> | McM: I think "<primitive> * foo = new <primitive>" will also work, but it's been ages. |
| 01:41 | < MSminion> | McMartin: You seem to assume that the struct has a destructor at all. |
| 01:41 | <@McMartin> | According to the standards, they most certainly do. |
| 01:41 | <@McMartin> | Structs == classes; the only difference is that in a struct stuff is public by default. |
| 01:41 | < MSminion> | I could wrap my WAVEFORMATEX, but I most certainly can't virtualize its destructor. |
| 01:42 | <@McMartin> | Wrap it. |
| 01:42 | <@McMartin> | And set whoever wrote that on fire for not defining the destructor as virtual. |
| 01:42 | < MSminion> | |
| 01:42 | < MSminion> | It's a C struct. |
| 01:42 | <@McMartin> | Yes. |
| 01:42 | < MSminion> | Set your torches on Kernighan and Ritchie. |
| 01:42 | <@McMartin> | When a C++ compiler deals with it it's supposed to do it right. |
| 01:42 | <@McMartin> | C++ is not "C with shit tacked on" |
| 01:42 | <@McMartin> | It's just that most C happens to be grammatical C++. |
| 01:43 | <@McMartin> | So, yes. The solution is to wrap it in a class to force the system to do the right thing with it. |
| 01:44 | <@McMartin> | If it were a C struct, I'm pretty sure that malloc() and free() would have to work appropriately as well |
| 01:44 | < MSminion> | I dunno. Not sure which standards you're talking about... I just knwo that if I declare a struct (or a class with no methods), then the MS compiler produces no vtable. No vtable means there will be no virtual destructor. |
| 01:45 | < MSminion> | malloc() and free() will also not work correctly across a DLL boundary, for the same reasons. You malloc() on one heap with one instance of the CRT, then try to free() from a different heap, and the other instance of the CRT is going to look at you funny then explode. |
| 01:45 | <@McMartin> | That sounds like MS's fault to me. |
| 01:46 | <@McMartin> | free() should be able to ask the struct "Hey, where the Hell were you allocated?" and go from theme. |
| 01:46 | < MSminion> | |
| 01:46 | <@McMartin> | That said. |
| 01:46 | < MSminion> | Yeah, and when you write that compiler, let me knwo. I'll look into getting you a job. |
| 01:46 | <@ToxicFrog> | glibc certainly doesn't behave like that. |
| 01:46 | <@ToxicFrog> | Well, glibc/g++. |
| 01:46 | <@McMartin> | TF: Like what he says, or like what I say? |
| 01:46 | <@ToxicFrog> | Or whatever the hell the C++ equivalent of glibc is... |
| 01:46 | <@McMartin> | glibc++. |
| 01:47 | <@ToxicFrog> | McM: it behaves like you say it should behave, and not like msdev does behave. |
| 01:47 | <@ToxicFrog> | In that you can allocate stuff inside one SO and free it in another and it works just fine. |
| 01:47 | <@McMartin> | TF: Good. Because this is the fundament concept behind object ownership. |
| 01:47 | <@McMartin> | In any event, MSminion. |
| 01:47 | <@ToxicFrog> | That said, I'm not sure I've tried this with a struct, but I can't see any reason why it wouldn't work. |
| 01:47 | <@McMartin> | I don't need to be hired to do this because it's already been done, but in the meantime... |
| 01:48 | < MSminion> | TF: That has to assume that both .so's are linked dynamically to the same instance of glibc++. In a VMM system, there is no way that one instance can even knwo about another. |
| 01:48 | <@McMartin> | MSminion: Uh... if they don't know about one another's structs, how can they even return it? |
| 01:48 | < MSminion> | For all the other instance knwos, I'm trying to deallocate from the code segment. Or from uninitialized memory. There is no communication between different heaps. |
| 01:48 | <@McMartin> | If the heaps aren't mutually accessible you're going to have to do an "ask length, copy out result" operation, and pray no pointers are involved. |
| 01:49 | <@McMartin> | Then how can you read it? |
| 01:49 | < MSminion> | It's memory. |
| 01:49 | <@McMartin> | Uh, yeah. |
| 01:49 | <@McMartin> | For all it knows, as you said, it's reading unallocated memory, hi2u GPV/SIGSEGV, right? |
| 01:49 | < MSminion> | I'm talking about instances of a CRT allocator. My client code knwos about the struct. The CRT generally doesn't. |
| 01:50 | <@McMartin> | In any case. |
| 01:50 | <@McMartin> | Add to the DLL containing bar() a new routine that deallocates an object of this type. |
| 01:50 | < MSminion> | free() doesn't even have any type info. All it has is a void*, and has to consult its internal structures to even get a length. |
| 01:50 | <@McMartin> | Yes. This is traditionally "the four-byte value immediately behind it". |
| 01:51 | <@McMartin> | That said, yes, if you have a complete failure of coordination, then this would be a problem. |
| 01:51 | <@McMartin> | But I then have to ask what the fuck you're doing passing pointers around. |
| 01:52 | < MSminion> | Trying to communicate with an audio driver, FWIW. |
| 01:53 | <@McMartin> | Since that's roughly equivalent to writing raw pointer data out to a file, and then reading it back in next week on a rerun of the program/. |
| 01:53 | <@McMartin> | It actually will usually work! |
| 01:54 | <@McMartin> | But yeah. If you must segregate these things, Fix Your API so that there's three functions: "Allocate a struct of this type", "Do the work that needs doing", and "Deallocate a struct of this type" |
| 01:54 | <@McMartin> | And have the second call the first. |
| 01:55 | <@McMartin> | And then your other DLL had damned well better be able to deallocate in that technique |
| 01:55 | | You're now known as TheWatcher |
| 01:55 | <@McMartin> | Because, if nothing else, I've seen SDL_image do this. |
| 01:55 | <@McMartin> | On MSVC6. |
| 01:55 | | Vornicus [~vorn@Admin.Nightstar.Net] has quit [Quit: ] |
| 01:58 | | The-Librarian-Away is now known as The-Librarian |
| 01:59 | < Janus> | ... um, what exactly is a .DLL? |
| 02:00 | <@McMartin> | Dynamically Linked Library. |
| 02:00 | <@McMartin> | It is a piece of code that a bunch of programs need, typically |
| 02:00 | <@McMartin> | So the computer only keeps one of them on disk, and when programs start up, they load up that copy and hook it up to their code at run time. |
| 02:00 | <@McMartin> | This has lots of advantages, when done right |
| 02:01 | <@McMartin> | Such as, for instance, letting you upgrade all your programs at once by fixing the library that they all use in one place. |
| 02:01 | <@McMartin> | It also has lots of disadvantages, particularly when you have two programs that want mutually incompatible versions of the same library. |
| 02:01 | | Thaqui [~Thaqui@Nightstar-8486.adsl.xtra.co.nz] has quit [Ping Timeout] |
| 02:02 | < Janus> | I see... I thought it was just some sort of OS dealie. |
| 02:02 | <@McMartin> | DLL is a Windows term. Other OSes have different names. |
| 02:02 | <@McMartin> | SO or .so is the only other one you'll see, though ("Shared Object") |
| 02:04 | <@McMartin> | (You deal with the disadvantages either by giving each app its own copies of the DLLs, keeping a history of all versions of the DLL and demanding apps specify the version they want, or by designing your DLLs such that all future versions will still let old apps run.) |
| 02:04 | < Janus> | Could you write a .DLL using C++? I'd guess there'd be a lot of restrictions on what you could or couldn't do, depending on what was needed from it. |
| 02:04 | <@McMartin> | You can write one in pretty much any language. |
| 02:05 | <@McMartin> | Though Java, Python, the .NET framework, and probably a goodly number of others do dynamic linking everywhere as part of the language spec. |
| 02:06 | <@McMartin> | The general problem with C++ is that you usually talk to a .DLL using C-style names, so you have to wrap the function call declarations with extern "C" { ... }. |
| 02:06 | <@McMartin> | That's not generally a problem, as you might imagine. |
| 02:07 | <@McMartin> | The only bit where it gets even slightly tricky is if you want the same header files to work in both C and C++. |
| 02:08 | < Janus> | Headers are where classes are usually defined, and C doesn't support classes, right? |
| 02:09 | <@ToxicFrog> | Headers are where classes are declared, as well as functions, extern variables, important constants and the like. |
| 02:09 | <@ToxicFrog> | The class is actually defined in the associated .c++ file. |
| 02:10 | < Janus> | Oh, right! I was, simply checking to see if anyone would catch that... |
| 02:10 | <@ToxicFrog> | And yes. You can write DLLs in almost anything. They're especially easy in C and C++, tho. |
| 02:11 | | Thaqui [~Thaqui@Nightstar-8486.adsl.xtra.co.nz] has joined #code |
| 02:12 | | * ToxicFrog idly stabs himself in the face before he modifies luafreeze to generate SOs, because McM has already done that. |
| 02:12 | < Janus> | I couldn't really imagine why I would need to make one for, but I suppose it's only a matter of time before a reason presents itself. |
| 02:12 | <@McMartin> | Using a DLL that exports C++ classes from C is kind of a pain. |
| 02:13 | <@ToxicFrog> | The most obvious reason is "because you're writing a library that you want other people to be able to use rather than an app in its own right" |
| 02:13 | <@ToxicFrog> | However, it also has uses when making an entire program. |
| 02:13 | <@McMartin> | VControl can be made into an .so, but you generally don't want to bother, because it's small and pretty integral. |
| 02:13 | <@McMartin> | For whole-programs-based-on-dlls, the only serious app I can see for it offhand is plugins. |
| 02:15 | < Janus> | Perhaps updates as well, though it'd be hard to predict where an update would be needed, and justify not updating it on the spot before releasing it. |
| 02:15 | <@McMartin> | Well, the question is twofold |
| 02:15 | <@McMartin> | There's "When do I write something as a DLL" |
| 02:15 | <@McMartin> | And then there's "When do I use other people's DLLs" |
| 02:16 | <@McMartin> | The latter is generally "all the time", especially if you're using SDL or DirectX or whatever. |
| 02:16 | <@ToxicFrog> | McM: alternately, you're writing a whole bunch of related programs that share code, and decide to split that into an SO rather than statically linking them all with their own copies. |
| 02:17 | <@McMartin> | Ah. True. |
| 02:17 | <@McMartin> | All the work I've done like that has all been in Java, which, as I noted, does this invisibly as part of its basic semantics |
| 02:17 | <@ToxicFrog> | Indeed. |
| 02:17 | | * McMartin still needs to do ClassLoader jackassery as an option for using his research prototype. |
| 02:18 | <@McMartin> | Since right now it takes one Java app and turns it into another one. |
| 02:18 | | MSminion [~sysop@Nightstar-6915.hsd1.or.comcast.net] has left #code [] |
| 02:18 | <@McMartin> | It would be Fairly Awesome to have it transform the first into the second on the fly at link time. |
| 02:22 | <@McMartin> | Also, in the code I wrote today: |
| 02:22 | <@McMartin> | /* TODO: There has *got* to be a better way of doing this. I can feel pieces of my soul dying. */ |
| 02:37 | < Janus> | May I ask a ... design concept, (no) ... implimentational-- (no) ... well, I'm not quite sure what catagory to give it, it's about movement interpolation, and the fact it bogards about 50% of the runtime. |
| 02:38 | <@ToxicFrog> | "movement interpolation"? |
| 02:38 | <@ToxicFrog> | (and it's 'bogarts', I believe) |
| 02:40 | < Janus> | (really? I suppose I'm just thinking of my science teacher...) The height grayscale image that's checked to determine where the final destination of a move between frames goes. If something's too high, or impassible, it halts... or rather, sends them back a certain distance. |
| 02:41 | <@ToxicFrog> | This would be the clipping code, I think. |
| 02:41 | < Janus> | The problem is that it has to step a few hundred times per object moving, for every frame, or less the interpolation fail, and walls become lousy at their job. |
| 02:41 | <@ToxicFrog> | ...I know there's a better way to do that. |
| 02:41 | <@ToxicFrog> | Several better ways depending on how your engine works, in fact. |
| 02:41 | < Janus> | http://rafb.net/paste/results/7l1qCS20.html It's Cluehammer worthy. |
| 02:42 | <@ToxicFrog> | (and what constraints you can rely on() |
| 02:42 | <@McMartin> | "Draw everything then only blit the part of your backbuffer you want rendered" is typically easiest |
| 02:42 | <@ToxicFrog> | McM: this appears to be physics, not rendering. |
| 02:42 | <@McMartin> | Arbitrary polygonal scissoring is typically harder, but even then, blitting from a backbuffer is probably the best you'll get. |
| 02:42 | <@McMartin> | Ah |
| 02:42 | <@McMartin> | In any case |
| 02:42 | <@McMartin> | dinner time |
| 02:43 | <@ToxicFrog> | Something moves, it needs to make sure that the move didn't take it through a wall or similar. |
| 02:43 | <@McMartin> | Mmm. Some kind of octree (or quadtree for 2D) is probably the standard algo |
| 02:44 | <@ToxicFrog> | How does that work? |
| 02:45 | < Janus> | Yeah. It should probably step on a pixel to pixel basis, but I was feeling lazy and gave it a /very/ inaccurate (not to mention ineffective), system of simply moving the magnitude a wee bit, checking left/right/up/down, and continuing it's merry way if it checks out. |
| 02:45 | < Janus> | The problem is that if it moves to a pixel diagonal to it... |
| 02:45 | <@ToxicFrog> | Hang on. |
| 02:45 | <@ToxicFrog> | So, you can't just check to see if the move ends inside a wall? |
| 02:46 | <@ToxicFrog> | Because it's possible for objects to move fast enough that they can pass entirely through a wall in one frame? |
| 02:47 | | Chalcedon is now known as ChalcyCooking |
| 02:47 | < Janus> | Well, actually, if that were the case, I believe the height checking accuracy would be comprimised. (Just think of a 'wall' as being an infinitly high chunk of terrain, or that's at least how the function sees it.) |
| 02:48 | <@ToxicFrog> | ...so, this is 2d with heightmaps? |
| 02:48 | < Janus> | Yeah. |
| 02:48 | <@ToxicFrog> | And you need to make sure, not only that you can't clip through walls, but also that you can't move up steep slopes? |
| 02:49 | < Janus> | Yes. they're not too different from eachother, so poping into one function seems more effective. |
| 02:51 | < Janus> | Right now, with the current one I showed ya, it's exceedingly accurate, but if there's about 20 characters moving at once, the framerate plummets to the 10 to 20 FPS range. |
| 02:53 | < Janus> | Of course, if I have it step at larger intervals, the function speeds up, but the accuracy becomes largely faulty. It's the difference between "0.02" and "0.1". |
| 02:53 | <@ToxicFrog> | Hmm. Depending on what kind of assurances you have about your terrain, you might be able to get away with checking /\y//\x |
| 02:54 | | * Vornicus-Latens plays Quake. |
| 02:54 | < Vornicus-Latens> | They kinda screwed up the water transformation, it should be volumetric. |
| 02:54 | <@ToxicFrog> | Say, if you don't want them to be able to walk up a more than 45ยบ incline, if y/x > 1, then you do the trace to see where the move actually stops. |
| 02:55 | <@ToxicFrog> | Otherwise, it's...sub, sub, div, cmp, a few pointer dereferences, not very many instructions per move per frame. |
| 02:55 | <@ToxicFrog> | However, this breaks if it's possible for them to move fast enough to go through such areas. |
| 02:57 | < Janus> | How about... it checks it's speed, and if it's fast enough for a break to become possible, it uses the slower method instead? |
| 02:57 | <@ToxicFrog> | That could work. |
| 02:57 | <@ToxicFrog> | You'll probably want to consult with McM when he gets back, though. |
| 02:57 | <@ToxicFrog> | I know little about plain collision detection and very little about this sort of clipping. |
| 02:58 | < Janus> | The only problem I can see, besides physic inconsistancy, would be the fact that the slower method becomes even /slower/ if the distance traveled over time is great. |
| 02:58 | <@ToxicFrog> | Yes. |
| 02:58 | <@ToxicFrog> | What kind of game is this again? |
| 02:59 | < Janus> | A RPG. |
| 02:59 | <@ToxicFrog> | I mean, if it's a newtonian-physics space sim, yes, this is a potential problem, but if it's an RPG it's pretty easy to clamp the top speed of the characters at less than the resolution of the clipping routines. |
| 03:00 | | * Janus tries too hard. |
| 03:02 | <@ToxicFrog> | (if it's tile-based it's almost too easy, but this isn't from what I can tell) |
| 03:02 | < Janus> | Speed is a higher priority than accuracy, so I guess a few missing precision points may go unaccounted for. (No tiles here, they give me car sickness.) |
| 03:03 | < Janus> | Here's what it looks like so far, just so you know: http://img.photobucket.com/albums/v492/tai_ragnarok/Cerulean0007.jpg |
| 03:04 | <@ToxicFrog> | Anyways. The algorithm I sketched out above will prevent them from moving more than a certain distance up per unit distance horizontally. This won't work if they manage to step right through a wall in a single frame, but it will stop them from moving through walls they can't step through in a single frame and from ascending too-high slopes. |
| 03:04 | <@ToxicFrog> | It also automagically handles stairs. |
| 03:04 | <@ToxicFrog> | I have no idea, however, if this is the right way to do it. |
| 03:05 | < Janus> | It's good resource practice to avoid thin walls and wacky grades in 2D anyway. |
| 03:06 | < Vornicus-Latens> | (Quake, at least the version I'm playing,has a bit of a problem with the interfacebetween air and water - underwater walls kinda drift, but they drift at a constant rate no matter how much water is above it. so the walls at the interface split in two, and you can see the clear buffer) |
| 03:10 | < Janus> | No such thing as a pretty buffer, which is why 3D games usually have something like a sky-box surrounding a stage. |
| 03:12 | <@ToxicFrog> | ...no, not usually. |
| 03:12 | <@ToxicFrog> | The skybox is an illusion. If it surrounds the entire level you are heiniously misuing the level design tools. |
| 03:12 | <@ToxicFrog> | (unless you're working in Source, in which case the 'skybox' is actually real world geometry) |
| 03:14 | < Janus> | That's the kind I was refering to. I'm not sure if all games would need one though, besides the one's where I've actually noticed the enclosure. |
| 03:16 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has quit [Quit: bathitime~!] |
| 03:21 | < Vornicus-Latens> | there's generally a clear color. |
| 03:21 | < Vornicus-Latens> | though some games don't have that either |
| 03:22 | < Vornicus-Latens> | (cf. pre-aleph one Marathon) |
| 03:24 | <@ToxicFrog> | Vorn: from what I've seen, generally you either have a reserved texture that the engine replaces with the skybox textures in game, or (a la HL2) it actually makes it a portal into a sky zone. Presumably there are some games where you must physically surround your level with sky-textured brushes, but that's...icky. |
| 03:28 | < Vornicus-Latens> | Marathon uses the former... but untextured walls get wiggy. |
| 03:28 | < Vornicus-Latens> | it doesn't clear and it doesn't cover with sky. |
| 03:33 | | You're now known as TheWatcher[T-2] |
| 03:36 | | Vornicus-Latens is now known as Vornicus |
| 03:37 | | Vornicus is now known as NSGuest-388 |
| 03:37 | | You're now known as TheWatcher[zZzZ] |
| 03:37 | | NSGuest-388 is now known as Vornicus |
| 03:39 | <@ToxicFrog> | Yeah. Same thing happens in Half-Life. |
| 03:39 | <@ToxicFrog> | (and other Quakeoids, I believe) |
| 03:40 | | Mahal is now known as MahalOUt |
| 03:40 | | MahalOUt is now known as MahalOut |
| 03:46 | | ChalcyCooking is now known as Chalcedon |
| 04:02 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 04:02 | | mode/#code [+o Chalcy] by ChanServ |
| 04:03 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 04:03 | | Chalcy is now known as Chalcedon |
| 04:13 | | * McMartin reads backscroll |
| 04:14 | <@McMartin> | Octree/Quadtree is for checking collisions between large number of objects that can move freely. It won't help for this height-map stuff. |
| 04:14 | <@McMartin> | ... It might almost be easier to model what you're doing with, like, a gravity model |
| 04:14 | <@McMartin> | "I can supply this much force; past a certain point gravity will pull me down faster than I can shove myself up" |
| 04:20 | | * McMartin eyes his I7 code |
| 04:20 | <@McMartin> | Man, I must have been tired or in some other unusual mental space when writing this. |
| 04:21 | <@McMartin> | Not only do we have the Table of Badass One-Liners, we also have "[unseemly gloat]" as an evaluatable expression. |
| 04:37 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 04:37 | | mode/#code [+o Chalcy] by ChanServ |
| 04:38 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 04:39 | | Chalc [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 04:41 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 04:42 | <@McMartin> | Whee! |
| 04:42 | | * McMartin gets door mapping to work right. |
| 04:42 | <@McMartin> | http://www.stanford.edu/~mcmartin/if/mapz0r.png |
| 04:44 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 04:44 | | mode/#code [+o Chalcy] by ChanServ |
| 04:45 | | Chalc [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 05:17 | | ReivWork is now known as Reiver |
| 05:40 | | MahalOut is now known as Mahal |
| 05:48 | | Mahal [~Mahal@Nightstar-11770.worldnet.co.nz] has quit [Quit: It's hard to be mad at someone who misses you while you're asleep. ] |
| 05:48 | | Chalcy is now known as Chalcedon |
| 05:54 | | Mahal [~Mahal@Nightstar-11770.worldnet.co.nz] has joined #Code |
| 05:54 | | mode/#code [+o Mahal] by ChanServ |
| 06:03 | | Thaqui is now known as ThaquiWork |
| 06:08 | | Chalcedon is now known as ChalcyGettingSpoiled |
| 06:11 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 06:11 | | mode/#code [+o Chalcedon] by ChanServ |
| 06:11 | | ChalcyGettingSpoiled [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 06:23 | | jerith [~jerith@IRCop.Nightstar.Net] has quit [Ping Timeout] |
| 06:24 | | jerith [~jerith@IRCop.Nightstar.Net] has joined #code |
| 06:25 | | mode/#code [+o jerith] by ChanServ |
| 06:25 | | Vornicus is now known as Vornicus-Latens |
| 06:50 | | Chalcedon is now known as ChalcySpoiled |
| 07:16 | | ChalcySpoiled is now known as Chalcedon |
| 07:18 | | Chalcedon is now known as ChalcySpoiled |
| 07:22 | | The-Librarian is now known as The-Librarian-Away |
| 08:28 | | ChalcySpoiled is now known as ChalcyPhone |
| 08:31 | | Reiver is now known as ReivStudy |
| 08:38 | | ChalcyPhone is now known as Chalcedon |
| 09:24 | | Chalcedon is now known as ChalcyZzz |
| 09:34 | | You're now known as TheWatcher[wr0k] |
| 11:18 | | ThaquiWork is now known as Thaqui |
| 12:41 | | ReivStudy is now known as ReivZzz |
| 12:52 | | ChalcyZzz [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 13:08 | | Mahal is now known as MahalZzz |
| 14:15 | | Thaqui is now known as ThaquiSleep |
| 15:07 | | Sex_capable [Ogres@212.160.180.ns-21448] has joined #Code |
| 15:09 | | Sex_capable [Ogres@212.160.180.ns-21448] has quit [Quit: ] |
| 15:13 | <@ToxicFrog> | Hmm. |
| 15:13 | <@ToxicFrog> | I find myself pondering writing my own implementation of regexec(). |
| 15:25 | <@ToxicFrog> | An obvious optimization for my current algorithm is to anchor each regex at the start of the line, but this falls down badly as soon as there's a lexical construct that really does need to be at the start of the line. |
| 15:33 | <@ToxicFrog> | argh |
| 15:33 | | * ToxicFrog foams at the brain |
| 16:32 | | You're now known as TheWatcher |
| 16:50 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has quit [Ping Timeout] |
| 17:01 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has joined #code |
| 17:05 | | Vornicus [~vorn@Nightstar-18307.slkc.qwest.net] has joined #code |
| 17:05 | | mode/#code [+o Vornicus] by ChanServ |
| 17:27 | | You're now known as TheWatcher[afk] |
| 17:52 | <@ToxicFrog> | Whee, pointerfun. |
| 17:52 | <@ToxicFrog> | *current = new Regex; |
| 17:52 | <@ToxicFrog> | (*current)->next = NULL; |
| 17:52 | <@ToxicFrog> | tail = *current; |
| 17:52 | <@ToxicFrog> | current = &((*current)->next); |
| 17:52 | | * Vornicus /flees screaming/ |
| 17:53 | <@ToxicFrog> | Sweet. |
| 17:55 | <@ToxicFrog> | "lua_tointeger not declared in this scope" wtf |
| 17:55 | | The-Librarian-Away is now known as The-Librarian |
| 17:56 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 17:56 | | mode/#code [+o Chalcedon] by ChanServ |
| 17:58 | <@Vornicus> | heh |
| 18:00 | | * ToxicFrog cranks up static_cast<> |
| 18:00 | <@ToxicFrog> | And it builds! |
| 18:02 | <@ToxicFrog> | ...hmm. That shouldn't've happened. |
| 18:03 | <@ToxicFrog> | To my side, reinterpret_cast<>! |
| 18:04 | < The-Librarian> | guh |
| 18:04 | <@ToxicFrog> | Chill, it's debugging code. |
| 18:05 | < The-Librarian> | right now, my problem is that I need a javascript call to render the contents of a template into a textarea... which isn't that difficult |
| 18:05 | < The-Librarian> | the difficulty lies in the fact that the template relies on information from the model |
| 18:05 | < The-Librarian> | and I really don't want to retrieve the model from the database just for that little call |
| 18:06 | < The-Librarian> | but there doesn't seem to be a way to pass the model through javascript and back to ruby |
| 18:06 | < The-Librarian> | *shrug* |
| 18:06 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 18:06 | | mode/#code [+o Chalcy] by ChanServ |
| 18:08 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 18:15 | <@ToxicFrog> | Ok, that totally wasn't meant to happen. |
| 18:16 | <@jerith> | Lies! It was preordained from the time of Creation! |
| 18:16 | < The-Librarian> | ook? |
| 18:16 | <@ToxicFrog> | I added some debugging code which is causing glibc to freak out - "detected double-free() or corruption" |
| 18:17 | <@jerith> | Is ToxicFrog doing Three Star Programming? |
| 18:17 | | * Vornicus ponders that C, by default, is already two-star programming. |
| 18:17 | <@ToxicFrog> | ...dude, what was that? |
| 18:18 | <@Vornicus> | ?? |
| 18:18 | <@ToxicFrog> | ...in free() from libc.so |
| 18:18 | <@ToxicFrog> | ...int fclose() from libc.so |
| 18:18 | <@ToxicFrog> | ...in DebugRegexList()] |
| 18:18 | <@jerith> | http://c2.com/cgi/wiki?ThreeStarProgrammer |
| 18:18 | <@ToxicFrog> | How did I break fclose()? |
| 18:18 | <@jerith> | With a hammer? |
| 18:19 | | * ToxicFrog idly fiddles it so that it's not constantly opening and closing it while in a tight loop |
| 18:20 | <@jerith> | Perhaps by closing a file that was already closed? |
| 18:20 | <@jerith> | Or one that was already being closed? |
| 18:20 | <@ToxicFrog> | Not possible, but I suppose it could have closed a file it failed to open |
| 18:20 | <@jerith> | Hmm... |
| 18:21 | <@ToxicFrog> | Hmm. Ok, that fixed it, but now it's segfaulting when it passes head->name to fprintf. |
| 18:23 | <@ToxicFrog> | Oh, no it isn't! |
| 18:23 | <@ToxicFrog> | It's calling DebugRegexList(head->subpatterns, 4). |
| 18:23 | <@ToxicFrog> | Which it shouldn't be doing. |
| 18:25 | | Chalcy is now known as Chalcedon |
| 18:27 | <@Vornicus> | gnar. |
| 18:33 | | * The-Librarian gnaws on Vornicus |
| 18:33 | <@ToxicFrog> | ....... |
| 18:34 | <@ToxicFrog> | Ok, apparently NULL is not actually false. |
| 18:34 | <@ToxicFrog> | Or 0. |
| 18:34 | <@ToxicFrog> | Since it's showing up as 0x080D00DC. |
| 18:34 | | * jerith giggles. |
| 18:34 | <@ToxicFrog> | Either that or this structure isn't being properly initialized. |
| 18:35 | <@jerith> | You shouldn't really assume that NULL is zero or false unless it's defined as such in the spec. |
| 18:35 | <@ToxicFrog> | Correct me if I'm wrong, but doesn't spec /say/ that NULL is always false and always equal to zero even if, under the hood, it's not really zero? |
| 18:35 | <@ToxicFrog> | And I know it's zero on this architecture anyways! |
| 18:36 | <@ToxicFrog> | So, I'm guessing the constructor isn't getting called for some reason. |
| 18:37 | <@jerith> | It may say that NULL is always false. It most certainly does /not/ say that (int) NULL is always zero. |
| 18:37 | <@jerith> | Although it usually is. |
| 18:37 | <@ToxicFrog> | Not (int)NULL. |
| 18:38 | <@ToxicFrog> | I mean, given type * foo = NULL, (foo == 0) even if ((unsigned int)foo != 0) |
| 18:38 | <@ToxicFrog> | Anyways, I'm not relying on that. |
| 18:40 | <@ToxicFrog> | Oh, that would be why! |
| 18:41 | <@ToxicFrog> | Lua uses 1-indexed arrays! Right, forgot that. |
| 18:41 | <@Vornicus> | heh |
| 18:41 | <@ToxicFrog> | And head is uninitialized rather than NULL. |
| 18:41 | <@ToxicFrog> | There we go. |
| 18:42 | | You're now known as TheWatcher |
| 18:42 | | * jerith applies an aging Jedi master to the problem. |
| 18:43 | <@ToxicFrog> | Victoly! |
| 18:43 | <@ToxicFrog> | Now I just need to get it so that it actually applies the regexes to the source text and colorizes them. |
| 18:43 | | * jerith arranges the procession through the streets. |
| 18:43 | <@jerith> | Are you building an editor? |
| 18:43 | <@ToxicFrog> | Which in turn requires access to the source text on a line-by-line basis, which probably means copying it one byte at a time into a buffer! |
| 18:44 | <@ToxicFrog> | shoot me now |
| 18:44 | <@ToxicFrog> | jerith: I'm writing a lexer for SciTE that will, if it works, fix that editor's most gaping flaw. |
| 18:44 | | * jerith warms up the BH-209i. |
| 18:44 | <@jerith> | Ah. |
| 18:44 | <@Vornicus> | copy a chunk at a time - say, 64 character, then backscan when you see a newline. |
| 18:44 | <@ToxicFrog> | Vornicus: I cannot. |
| 18:44 | <@Vornicus> | bah |
| 18:44 | <@ToxicFrog> | I can only see one character at a time. |
| 18:44 | <@Vornicus> | ow |
| 18:45 | <@jerith> | Does it only expose getbyte()? |
| 18:45 | <@ToxicFrog> | Otherwise, I'd just use GetEndOfLine() to calculate line length and then either access it directly (I'm only reading, after all) or memcpy() it. |
| 18:45 | <@ToxicFrog> | jerith: in effect, yes. |
| 18:45 | <@ToxicFrog> | Specifically, the fact that adding support for a new language, or modifying support for an existing language, requires you to write a lexer for it in C++ and then recompile it. |
| 18:46 | <@ToxicFrog> | I'm adding a lexer that, given a language L, will load a set of regexes describing that language from L.regex and use those to colorize the text. |
| 18:47 | <@ToxicFrog> | (well, $(regex.config-path)/L.regex) |
| 18:47 | <@ToxicFrog> | This is why I am contemplating writing my own implementation of regexec(). |
| 18:47 | <@ToxicFrog> | Because the question POSIX regexec() answers is "where is the first match of this regex in this string" |
| 18:47 | <@jerith> | Hmm... |
| 18:48 | <@ToxicFrog> | Whereas the question I'm asking is "what regex does the start of this string match" |
| 18:48 | <@ToxicFrog> | And at present, I'm just iterating over the list of regexes calling regexec() on each one until I find one that matches the start of the string. |
| 18:48 | <@jerith> | Perhaps you actually want to supply parsing rules rather than regexen? |
| 18:48 | <@ToxicFrog> | Which is slow, although I haven't actually tested it to see how slow. It may actually be acceptably performant. |
| 18:49 | <@ToxicFrog> | jerith: lexing, not parsing. |
| 18:49 | <@ToxicFrog> | And regexes are lexing rules. |
| 18:49 | <@jerith> | Ah. |
| 18:49 | <@Vornicus> | why don't you just prepend ^ to the regex? that way it will /only/ match the start of the string |
| 18:49 | <@Vornicus> | that way you'll get a match, or no match |
| 18:50 | <@ToxicFrog> | Vornicus: because what if someone's trying to describe a language where something has to be at the start of the line? |
| 18:50 | <@Vornicus> | ...true that |
| 18:50 | <@ToxicFrog> | Although I have some ideas in that direction. |
| 18:51 | | aoanla [~sam@Nightstar-16652.range81-156.btcentralplus.com] has joined #code |
| 18:51 | <@ToxicFrog> | (give them a seperate flag AtStartOfLine. Forbid use of ^, or remove it (and set that flag) before calling regcomp(). When iterating over the regexes, if regex->AtStartOfLine and linestart!=stringstart, skip that regex.) |
| 18:51 | | aoanla is now known as caps[hereish] |
| 18:52 | < The-Librarian> | ToxicFrog: I saw SciTE up there, what are you fixing? |
| 18:52 | < The-Librarian> | and are you fixing SciTE or building a new system using Scintilla as the base? |
| 18:52 | <@Vornicus> | apparently in order to add languages you need to recompile. |
| 18:52 | <@jerith> | Why not rip the syntax highlighting engine out of vim? |
| 18:52 | | * jerith hides. |
| 18:53 | <@ToxicFrog> | The-Librarian: <ToxicFrog> Specifically, the fact that adding support for a new language, or modifying support for an existing language, requires you to write a lexer for it in C++ and then recompile it. |
| 18:53 | <@ToxicFrog> | <ToxicFrog> I'm adding a lexer that, given a language L, will load a set of regexes describing that language from L.regex and use those to colorize the text. |
| 18:53 | | * The-Librarian beats jerith to a bloody pulp |
| 18:53 | < The-Librarian> | oh that sucks |
| 18:53 | < The-Librarian> | and yeah, that would be a good help, I think |
| 18:53 | <@ToxicFrog> | Technically this lexer is part of Scintilla, not part of SciTE, so it'll work in other libscintilla-based stuff if you have Lua 5.x handy to link it with. |
| 18:53 | <@ToxicFrog> | (it uses Lua as a parser for its config files and as a hash table implementation) |
| 18:53 | < The-Librarian> | I like the way scintilla does syntax hilighting |
| 18:54 | < The-Librarian> | it's got the best ruby syntax thingy I've found yet |
| 18:54 | <@ToxicFrog> | Yeah. And folding, calltips, shell integration... |
| 18:54 | < The-Librarian> | not counting vim because I don't and won't use vim |
| 18:54 | <@ToxicFrog> | It has a lot of stuff NEdit lacks, but it's so much less flexible. |
| 18:54 | <@ToxicFrog> | I actually considered simply porting NEdit's syntax hilighting/language description engine into a Scintilla lexer module. |
| 18:54 | <@ToxicFrog> | Then I read the source. |
| 18:54 | <@ToxicFrog> | There is no god. |
| 18:55 | < caps[hereish]> | There is a god; he just hates you. |
| 18:55 | <@Vornicus> | *snrk* |
| 18:55 | <@ToxicFrog> | (also - yes, this will support folding; you can tell it to increment or decrement the fold level when it hits a certain regex. No idea how calltip support works. The Scintilla documentation is...lacking.) |
| 18:55 | <@ToxicFrog> | And now, class! |
| 18:56 | <@jerith> | The reason I suggested vim is simply that it has the biggest library of syntax rules anywhere. |
| 18:57 | < The-Librarian> | OK, first off, what exactly is calltip? |
| 18:57 | <@Vornicus> | SciTE's folding for Ruby is not great; Eclipse's is better, because it folds the end in there too |
| 18:57 | < The-Librarian> | hmm |
| 18:58 | <@Vornicus> | But Eclipse is also too aggressive |
| 18:58 | < The-Librarian> | the main problem I have with scintilla's highlighter thing is that it has these little dotted lines showing indent levels and tying bits of code together, which is really nice |
| 18:58 | < The-Librarian> | but those lines break if there's any whitespace lines in there |
| 18:58 | < The-Librarian> | eclipse is also slow as a goddamn overburdened snail |
| 18:58 | < The-Librarian> | and more memoryhoggy than firefox and photoshop put together |
| 18:59 | <@Vornicus> | if you stop typing for one second, it reparses, and if you aren't done writing your method or whatever, it goes blooie. |
| 18:59 | <@ToxicFrog> | Calltip is where, when you're writing a function call, it looks up the arguments for the function and gives you a little popup below the cursor telling you what they are. |
| 18:59 | < The-Librarian> | ToxicFrog: oh god, I so want those. |
| 19:00 | < The-Librarian> | they don't work in komodo |
| 19:00 | < The-Librarian> | and komodo uses scintilla |
| 19:00 | < The-Librarian> | they didn't work in scite either |
| 19:00 | <@ToxicFrog> | So if you write, say, fprintf(, it'll pop up a little box saying (FILE *, const char *, ...) or whatever. |
| 19:00 | <@Vornicus> | Ruby - and other dynamically-typed languages - are /very/ hard to do calltips for. |
| 19:00 | <@ToxicFrog> | Vornicus: yeah, but you can at least do argument names. |
| 19:00 | < The-Librarian> | if scite had a (decent) file browser that'd snap to it, I'd probably use it. I don't really need all the overhead of komodo |
| 19:00 | <@Vornicus> | TF: even that is hard. |
| 19:01 | <@ToxicFrog> | Anyways. AFAIK, SciTE only does it with predefined .API files. |
| 19:01 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 19:01 | | mode/#code [+o Chalcy] by ChanServ |
| 19:01 | < The-Librarian> | hmm |
| 19:01 | <@ToxicFrog> | It can't look at code you wrote and guess the calltips from that the way a language-specific IDE can. |
| 19:01 | <@Vornicus> | You need to be able to guarantee the class of the object you're calling the method on, and if you can't, you don't know /anything/ about the arguments. |
| 19:01 | < The-Librarian> | interesting |
| 19:01 | <@Vornicus> | ah |
| 19:01 | <@Vornicus> | well, that, okay. |
| 19:01 | < The-Librarian> | well I don't mind if it doesn't calltip my own code |
| 19:01 | < The-Librarian> | I mean, if I start typing a function that I wrote... I don't care if it doesn't calltip that |
| 19:02 | < The-Librarian> | I want the stuff from the language itself to get calltipped though. |
| 19:02 | <@ToxicFrog> | Librarian: look under scintilla.sourceforge.net/SciTEExtras.html |
| 19:02 | < The-Librarian> | and I'd freakin love it if someone would come out with one that'd calltip Rails |
| 19:02 | | Chalcedon [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 19:02 | < The-Librarian> | komodo's supposed to have "Code Intelligence" but I've never seen it do a goddamn thing |
| 19:02 | <@ToxicFrog> | There doesn't appear to be one for Rails yet, but they're pretty easy (albeit tedious, if you can't autogenerate them |
| 19:02 | <@ToxicFrog> | ) to write. |
| 19:03 | < The-Librarian> | nothing there on ruby or rails |
| 19:03 | <@jerith> | To do intellisense (or whatever you want to call it) properly, your editor needs to be very tightly coupled to the language. |
| 19:03 | < The-Librarian> | although I wonder what that filerx thing is |
| 19:03 | < The-Librarian> | jerith: yeah, and nobody's built a good Rails IDE yet |
| 19:03 | <@jerith> | Which means writing new language modules for it becomes a *lot* more difficult. |
| 19:04 | < The-Librarian> | there's Komodo, which falls short in a few places... |
| 19:04 | <@ToxicFrog> | jerith: yeah. Which is why SciTE just uses predefined lists of function signatures. |
| 19:04 | < The-Librarian> | vim, bleccch! |
| 19:04 | <@jerith> | The-Librarian: I'm sure there's a reasonable emacs mode for it... *ducks* |
| 19:05 | < The-Librarian> | eclipse with various ruby packages, still not tied very well to ruby/rails |
| 19:05 | < The-Librarian> | jerith: I've actually been contemplating that |
| 19:05 | < The-Librarian> | I used to be a huge emacs fan |
| 19:05 | < The-Librarian> | haven't used it in over a decade though |
| 19:05 | <@ToxicFrog> | Librarian: anyways, just check out the .api files on that page. |
| 19:05 | <@ToxicFrog> | You should be able to generate one for Rails pretty easily. It's a simple format. |
| 19:05 | | * jerith ponders a Ruby-based IDE that uses introspection and such. |
| 19:05 | <@jerith> | The-Librarian: Ah, that explains the vimbashing... |
| 19:06 | < The-Librarian> | vim has always always been actively uncomfortable for me to use |
| 19:06 | < The-Librarian> | I'm constantly typing in command mode, or issuing commands in insert mode... and that's just a start |
| 19:06 | < The-Librarian> | it just feels like a whole bunch of little kludges built on top of one great big kludge. |
| 19:07 | < The-Librarian> | oh, I can use it, I use it all the time |
| 19:07 | < The-Librarian> | but it's not comfortable for me to use for anything but quick edits on the server |
| 19:07 | | * Vornicus avoids both vi and emacs. |
| 19:07 | <@ToxicFrog> | I use nano for my quick edits, personally. |
| 19:07 | <@Vornicus> | indeed |
| 19:08 | < The-Librarian> | hmm |
| 19:08 | <@ToxicFrog> | And avoid both emacs and vi in favour of NEdit. |
| 19:08 | <@ToxicFrog> | Or, if I can get this working, SciTE. |
| 19:08 | < The-Librarian> | RadRails: Eclipse-based. |
| 19:08 | <@ToxicFrog> | And now I really must depart for Class! |
| 19:08 | <@jerith> | Is NEdit GUI? |
| 19:08 | <@ToxicFrog> | (seriously, TL, just write the API file) |
| 19:08 | <@jerith> | Cheers TF -- enjoy! |
| 19:08 | <@Vornicus> | Eclipse is a /very/ powerful tool. it just happens to be build for projects with half a million lines of code. |
| 19:08 | < The-Librarian> | ArachnoRuby: Eclipse based too, I think |
| 19:09 | < The-Librarian> | RoRED: Not ready for primetime, AT ALL |
| 19:09 | <@ToxicFrog> | jerith: yes. X11/Motif based. Limited shell integration, syntax hilighting based on extended regular expressions with some custom modifications. |
| 19:09 | < The-Librarian> | Komodo: Okay, but the file management is HORRIBLE |
| 19:09 | < The-Librarian> | Vornicus: that's because it's built for Java |
| 19:09 | | * The-Librarian dives headfirst into the bunker! |
| 19:09 | < The-Librarian> | and j2ee whatever the hell that is |
| 19:09 | < The-Librarian> | I've just heard the term thrown around a lot |
| 19:09 | | * Vornicus has written C++ and Java in it. |
| 19:10 | <@Vornicus> | Ruby is not really designed to go half a million lines of code. |
| 19:10 | < The-Librarian> | no |
| 19:10 | < The-Librarian> | if you have ten thousand loc, that's an absolutely freakin huge application |
| 19:10 | < The-Librarian> | if you have ten thousand loc in Rails, then there's something seriously wrong with you |
| 19:12 | <@Vornicus> | 10kloc is a lot of code, but it's really not that hard to hit. |
| 19:12 | < The-Librarian> | hmm |
| 19:12 | < The-Librarian> | RIDE-ME looks intriguing |
| 19:12 | < The-Librarian> | Rails IDE - Minus Eclipse |
| 19:13 | < The-Librarian> | it's a windows-only thing designed from the ground up to be a streamlined Rails dev environment |
| 19:13 | < The-Librarian> | programmed in .NET |
| 19:13 | < The-Librarian> | whatever the hell that means. |
| 19:13 | <@jerith> | Usually C#. |
| 19:13 | < The-Librarian> | .NET is still in the "unidentified buzzword" category in my brain |
| 19:14 | <@jerith> | It's an overhyped runtime environment. |
| 19:14 | < The-Librarian> | and C# is somewhere between "unidentified buzzword" and "I heard that was *awful*" |
| 19:14 | <@Vornicus> | .NET consists several technologies designed to increase interoperability. |
| 19:14 | <@Vornicus> | in particular, the COmmon Language RUntime, which allows you to write things in different languages and have them work together seamlessly. |
| 19:16 | <@Vornicus> | I have 400loc in Euclid for just 20 methods. Mind, this includes documentation and unit tests. |
| 19:16 | < The-Librarian> | colru? |
| 19:16 | <@Vornicus> | CLR |
| 19:16 | < The-Librarian> | ah okay, shift hangup |
| 19:16 | <@Vornicus> | I can't hit shift today. |
| 19:16 | < The-Librarian> | heh |
| 19:17 | < The-Librarian> | okay, I now know all I need to know about .NET |
| 19:17 | <@Vornicus> | It's a rather shiny piece of tech. I don't know how well it actually works though |
| 19:17 | < The-Librarian> | if i can't do it in Rails, then I don't need to be doing it. |
| 19:17 | < The-Librarian> | although I'd still like to make an open source version of PersonalBrain |
| 19:18 | < The-Librarian> | http://www.thebrain.com/ |
| 19:18 | < The-Librarian> | and on that note, bbiaf |
| 19:20 | <@jerith> | Hometime. I may be back in about 45 minutes. |
| 19:41 | | Chalcy is now known as Chalcedon |
| 20:05 | | Janus [~Cerulean@Nightstar-10302.columbus.res.rr.com] has joined #Code |
| 20:06 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has quit [Ping Timeout] |
| 20:18 | | The-Librarian is now known as The-Librarian-Away |
| 20:18 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has joined #code |
| 21:06 | | You're now known as TheWatcher[T-2] |
| 21:09 | | You're now known as TheWatcher[zZzZ] |
| 21:23 | | MahalZzz is now known as Mahal |
| 22:01 | <@Vornicus> | SHe blinded me... with library science! |
| 22:01 | <@ToxicFrog> | SCIENCE! |
| 22:02 | <@ToxicFrog> | (libSCIENCE!.so?) |
| 22:02 | <@Vornicus> | not that kind of library |
| 22:02 | <@ToxicFrog> | ...I must now totally find an excuse to write a libSCIENCE! |
| 22:03 | <@Vornicus> | scientific computing. Writ large. |
| 22:04 | <@ToxicFrog> | (and embed this somewhere in the binary: http://imgs.xkcd.com/comics/science.jpg ) |
| 22:06 | | ReivZzz is now known as Reiver |
| 22:35 | | The-Librarian-Away is now known as The-Librarian |
| 22:36 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has quit [Ping Timeout] |
| 22:48 | | EvilDarkLord [althalas@Nightstar-17046.a80-186-184-83.elisa-laajakaista.fi] has joined #code |
| 22:52 | | Reiver is now known as ReivClass |
| 23:25 | | Janus is now known as Jan[dinnerino] |
| 23:39 | | Chalcedon is now known as ChalcyUni |
| 23:43 | | The-Librarian is now known as The-Librarian-Away |
| 23:54 | <@Pi> | <The-Librarian> if you have ten thousand loc, that's an absolutely freakin huge application |
| 23:54 | | * Pi boggles |
| 23:55 | <@Pi> | So what do I have, when I work on an app with 120 million loc? |
| 23:56 | <@Vornicus> | WIndows. |
| 23:57 | | caps[hereish] is now known as caps[t-2] |
| 23:57 | <@Vornicus> | Personally, I could easily get to 10kloc by the end of next week if it were the only thing I did. |
| 23:57 | | Chalcy [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has joined #code |
| 23:57 | | mode/#code [+o Chalcy] by ChanServ |
| 23:58 | | ChalcyUni [~Chalceon@Nightstar-869.bitstream.orcon.net.nz] has quit [Ping Timeout] |
| 23:59 | <@Pi> | Yeah. |
| 23:59 | <@Vornicus> | in Ruby, even. |
| 23:59 | <@Vornicus> | C++ I could get to 10kloc by the end of /this/ week. |
| 23:59 | <@Pi> | Note that Windows has about 6000 developers, and is mostly C++. It doesn't really fit any part of librarian's concept of an app. |
| 23:59 | < caps[t-2]> | 10kloc doesn't seem /that/ huge to me, no. |
| --- Log closed Fri Oct 13 00:00:04 2006 |