Sun Aug 30 22:25:19 2009
[imud_code]
Quixadhal@Bloodlines: if you set a = 4 and b = 5, a && b is true, but a == b is not.
Sun Aug 30 22:28:24 2009
[imud_code]
Silenus@Dead Souls Dev: hmm i wonder if i get this stuff working if C++ code would be welcome in fluffos :P
Sun Aug 30 22:32:17 2009
[imud_code]
Wodan@Discworld: but for some reason it doesn't work on solaris when you do that :(
Sun Aug 30 22:32:37 2009
[imud_code]
Wodan@Discworld: or at least it didn't when i first made it compile, haven't tried in a while
Sun Aug 30 22:34:39 2009
[imud_code]
Silenus@Dead Souls Dev: just rewriting one module in C++ to optimize it not sure if I will do more
Sun Aug 30 22:34:54 2009
[imud_code]
Silenus@Dead Souls Dev: i could do it in C but it would take longer for sure.
Sun Aug 30 22:37:36 2009
[imud_code]
Silenus@Dead Souls Dev: a question of course is other than the standard C++ library would it be ok to use something like boost?
Sun Aug 30 22:38:31 2009
[imud_code]
Wodan@Discworld: boost is rather big, not sure that's a reasonable requirement
Sun Aug 30 22:44:48 2009
[imud_code]
Ideysus@ShadowMUDii: Wait, is the official fluffos going to depend on C++?
Sun Aug 30 22:47:09 2009
[imud_code]
Wodan@Discworld: C++ is just a bit more comfortable to write in :)
Sun Aug 30 22:47:22 2009
[imud_code]
Ideysus@ShadowMUDii: Are you going to strip all the legacy support for other systems out then?
Sun Aug 30 22:48:00 2009
[imud_code]
Ideysus@ShadowMUDii: I thought it supported a load of old unixes
Sun Aug 30 22:48:07 2009
[imud_code]
Wodan@Discworld: i don't think we support anything without a c++ compiler
Sun Aug 30 22:48:45 2009
[imud_code]
Wodan@Discworld: oh, no, i stripped out some of the stupidly old stuff, nobody is going to run fluffos on a vax :)
Sun Aug 30 22:50:29 2009
[imud_code]
Woom@Discworld: Oh, so *that's* why that didn't work last time I tried.
Sun Aug 30 22:51:09 2009
[imud_code]
Aidil@Way of the Force: hey, I have a vax.. I was planning to see if DS runs on it sometime.. :)
Sun Aug 30 22:52:50 2009
[imud_code]
Aidil@Way of the Force: well, if I actually can be bothered to get it out of storage I'll get to see :)
Sun Aug 30 22:52:59 2009
[imud_code]
Wodan@Discworld: i haven't tried, but i would expect it to work :)
Sun Aug 30 22:53:27 2009
[imud_code]
Wodan@Discworld: but then, i expected 64 bit sparc to work as well, so who knows
Sun Aug 30 22:54:08 2009
[imud_code]
Raudhrskal@Dead Souls Dev: VAX is 32bit, so endian-problems shouldn't matter here...
Sun Aug 30 22:54:56 2009
[imud_code]
Aidil@Way of the Force: well, can still have endian problems on 32bit.. but those should have been sorted out somewhere over the last decade or 2 :)
Sun Aug 30 22:54:57 2009
[imud_code]
Raudhrskal@Dead Souls Dev: (For those who just tuned in: Yes, what I said makes a bit of sense - this is FLuffOS after all.)
Sun Aug 30 22:55:55 2009
[imud_code]
Aidil@Way of the Force: anyway.. enjoy. I shall enjoy some sleep.
Sun Aug 30 22:56:23 2009
[imud_code]
Raudhrskal@Dead Souls Dev: i mean - somebody who doesn't know the situation would say "wth? what bits have to endianness?"
Sun Aug 30 22:58:38 2009
[imud_code]
Ideysus@ShadowMUDii: Out of interest, what is getting added with the C++ support?
Sun Aug 30 22:59:15 2009
[imud_code]
Raudhrskal@Dead Souls Dev: It's more like "Sil can't write C", I suppose...
Sun Aug 30 22:59:38 2009
[imud_code]
Ideysus@ShadowMUDii: Thats understandable. I can't read C++. :-)
Sun Aug 30 23:00:31 2009
[imud_code]
Wodan@Discworld: oh, could make the svalue_t a proper class and do some things automatically and clean up the source :)
Sun Aug 30 23:00:55 2009
[imud_code]
Wodan@Discworld: could even put the whole runtime type handling in C++ hands that way perhaps
Sun Aug 30 23:01:44 2009
[imud_code]
Silenus@Dead Souls Dev: i am just too lazy to have to implement all my own data structures :P
Sun Aug 30 23:02:19 2009
[imud_code]
Wodan@Discworld: but the thing that made me consider it first time was regular expressions in boost, C regular expressions seem to come in several incompatible packages
Sun Aug 30 23:03:09 2009
[imud_code]
Wodan@Discworld: most of them much changed versions of the code fluffos regexps are based on
Sun Aug 30 23:04:11 2009
[imud_code]
Wodan@Discworld: fluffos has the great-granddad of all them regexp libs in it :)
Sun Aug 30 23:05:36 2009
[imud_code]
Silenus@Dead Souls Dev: i might try hacking some JIT system into fluffos "maybe" but not sure if anyone would want to use it
Sun Aug 30 23:08:05 2009
[imud_code]
Silenus@Dead Souls Dev: but i have alot of the stuff mapped out for the driver thing i was workign on
Sun Aug 30 23:11:41 2009
[imud_code]
Silenus@Dead Souls Dev: all objects refs in fluffos are handles now?
Sun Aug 30 23:12:58 2009
[imud_code]
Silenus@Dead Souls Dev: hmm nm not sure what this comment means
Sun Aug 30 23:15:34 2009
[imud_code]
Wodan@Discworld: oh, a jit is always welcome, even if i'm not aware of any lpc mud being cpu limited :)
Sun Aug 30 23:16:52 2009
[imud_code]
Wodan@Discworld: but it being optional would be important if it needs all of llvm :)
Sun Aug 30 23:18:46 2009
[imud_code]
Ninja@Dead Souls Dev: don't ya just hate it when a function saves a handle, but releases the object reference?
Sun Aug 30 23:19:31 2009
[imud_code]
Silenus@Dead Souls Dev: not sure it's worth the effort since muds tend to be more i/o bound
Sun Aug 30 23:24:51 2009
[imud_code]
Qwer@Archipelago: lost legends was CPU bound at one point in its history
Sun Aug 30 23:25:52 2009
[imud_code]
Wodan@Discworld: discworld has been, but I fixed those driver scaling problems :)
Sun Aug 30 23:27:36 2009
[imud_code]
Qwer@Archipelago: i think the scaling problems were more in the domain code than anywhere else!
Sun Aug 30 23:27:39 2009
[imud_code]
Ninja@Dead Souls Dev: k, wot's the diff between 'object ref' and 'handle' in flouffos?
Sun Aug 30 23:28:47 2009
[imud_code]
Wodan@Discworld: the only handles in fluffos that i can think of are for databases and call_out()s, so not sure what the question is!
Sun Aug 30 23:29:34 2009
[imud_code]
Ninja@Dead Souls Dev: I'm not sure either...prolly misunderstand an earlier comment.
Sun Aug 30 23:29:49 2009
[imud_code]
Silenus@Dead Souls Dev: heh i just didnt understand some comment i was reading
Sun Aug 30 23:30:07 2009
[imud_code]
Silenus@Dead Souls Dev: most things in fluffos appear to be *object_t
Sun Aug 30 23:30:34 2009
[imud_code]
Silenus@Dead Souls Dev: in some cases you get stuff like **object_t and ***object_t
Sun Aug 30 23:30:37 2009
[imud_code]
Ninja@Dead Souls Dev: sleepy, brain shutting down, trying to understand things I shouldn't try to understand.
Sun Aug 30 23:31:50 2009
[imud_code]
Ninja@Dead Souls Dev: is **xxx a pointer to a pointer, or does "**" itself have special meaning and is itself a single "token"
Sun Aug 30 23:35:43 2009
[imud_code]
Silenus@Dead Souls Dev: i am just curious why in some cases you have 1 and in others something else
Sun Aug 30 23:39:43 2009
[imud_code]
Wodan@Discworld: so with *** is a pointer to a pointer to a pointer
Sun Aug 30 23:39:52 2009
[imud_code]
Wodan@Discworld: so i suspect there aren't that many of those :)
Sun Aug 30 23:47:16 2009
[imud_code]
Ninja@Dead Souls Dev: somewhere, there's a &&&xxx that's lonely.
Mon Aug 31 04:32:33 2009
[imud_code]
Quixadhal@Bloodlines: It may be helpful to know that a->b is just syntactic sugar for lazy folks who don't like (*a).b
Mon Aug 31 04:33:08 2009
[imud_code]
Cratylus@Dead Souls Dev: i am just so sick of three comparison operators when you just need 1
Mon Aug 31 04:33:55 2009
[imud_code]
Tricky@Rock the Halo: We should just program everything using NAND logic.
Mon Aug 31 04:34:00 2009
[imud_code]
Quixadhal@Bloodlines: The good old days when BEQ was enough, and BNE or BPL were handy.
Mon Aug 31 04:36:31 2009
[imud_code]
Cratylus@Dead Souls Dev: i need someone to explain step by step how to make a function
Mon Aug 31 04:36:56 2009
[imud_code]
Cratylus@Dead Souls Dev: im sorry, i've been away and am catching up on some backlog
Mon Aug 31 04:37:10 2009
[imud_code]
Cratylus@Dead Souls Dev: and this channel has seen some amazing stuff while i was away
Mon Aug 31 04:38:09 2009
[imud_code]
Quixadhal@Bloodlines: First, you push all the registers onto the stack, then you load your pass-by-value parameters into data registers and your pass-by-address values into address registers, push your return address onto the stack and JMP for joy!
Mon Aug 31 04:39:01 2009
[imud_code]
Quixadhal@Bloodlines: Oh sure, you can pass them via the stack too... but that's slow.
Mon Aug 31 04:39:34 2009
[imud_code]
Quixadhal@Bloodlines: That's only for African coconuts. European coconuts have a different API.
Mon Aug 31 04:44:38 2009
[imud_code]
Quixadhal@Bloodlines: Luckily for the monkeys, the coconuts aren't very demanding.
Mon Aug 31 04:57:36 2009
[imud_code]
Silenus@Dead Souls Dev: i had a hard time trying to explain how to write a function to Enigma
Mon Aug 31 04:57:54 2009
[imud_code]
Silenus@Dead Souls Dev: i think maybe he might be best served by reading an introd programming book
Mon Aug 31 05:21:19 2009
[imud_code]
Quixadhal@Bloodlines: There seem to be several newcomers who are highly resistant to the whole "book" idea. Apparently they're just full of "jargon" and stuff.
Mon Aug 31 05:23:49 2009
[imud_code]
Tsarenzi@Sremassande: But they're so hard to understand. Like programming. And it would really be easier if they could just -know- what to do.
Mon Aug 31 05:24:43 2009
[imud_code]
Tricky@Rock the Halo: Yeah! LPC should be able to code itself by now!
Mon Aug 31 05:26:24 2009
[imud_code]
Tsarenzi@Sremassande: You'd think! Of course, I'm just doing this for the fun of coding anyway, not for the end result. But I guess that's less common.
Mon Aug 31 05:31:32 2009
[imud_code]
Quixadhal@Bloodlines: FUN??? Oh, my no. That's not allowed. You should be wearing a suit, sitting in a cubicle, coding a mudlib whose requirements will change every week until it gets scrapped 6 months from now, and having to beg to warm your ramen noodles in the microwave. *grin*
Mon Aug 31 05:32:30 2009
[imud_code]
Tsarenzi@Sremassande: I know, I know. Naughty me. But no one wants to give me a job, so in the meantime, I'll be defiant and enjoy myself :P
Mon Aug 31 05:34:40 2009
[imud_code]
Quixadhal@Bloodlines: Speaking of which... I think I need to go nuke a small city in Fallout 3. I can imagine it's filled with all the people who wouldn't give me interviews. *grin*
Mon Aug 31 05:35:10 2009
[imud_code]
Tsarenzi@Sremassande: You go have fun with that! Splode a few for me too?
Mon Aug 31 05:36:02 2009
[imud_code]
Quixadhal@Bloodlines: Sure, always happy to make a few extra civilian casualties. :)
Mon Aug 31 05:36:18 2009
[imud_code]
Shak@Rock the Halo: Tsarenzi@Sremassande, Thou hast all the social graces of a yeasty spur-galled boar-pig
Mon Aug 31 18:14:52 2009
[imud_code]
Silenus@Dead Souls Dev: anyone know what these large 400k-200k block allocations that fluffos does at startup are?
Mon Aug 31 18:18:59 2009
[imud_code]
Ninja@Dead Souls Dev: if fluffos does it's own memory allocation, then perhaps it's grabbing a big chunk of raw memory for future use?
Mon Aug 31 18:19:16 2009
[imud_code]
Ninja@Dead Souls Dev: instead of grabbing bits of heap as it goes along.
Mon Aug 31 18:20:24 2009
[imud_code]
Silenus@Dead Souls Dev: i speculate that is what it is doing too
Mon Aug 31 18:21:08 2009
[imud_code]
Ninja@Dead Souls Dev: LPC will be *mature* when we can ALL say...
Mon Aug 31 18:24:56 2009
[imud_code]
Silenus@Dead Souls Dev: just trying to figure out something w.r.t to the allocation patterns
Mon Aug 31 21:18:08 2009
[imud_code]
Silenus@Dead Souls Dev: oh i think someone might have mentioned him at some point.
Mon Aug 31 23:21:26 2009
[imud_code]
Ninja@Dead Souls Dev: nothing like logging onto a new mud, bragging that I'm XXX from YYY mud, the toughest player there!
Mon Aug 31 23:22:12 2009
[imud_code]
Ninja@Dead Souls Dev: so, I just tell people that I'm Cratylus of Borg.
Wed Sep 2 16:07:10 2009
[imud_code]
Corrik@Lost Realms: Who is considered the official maintainer of FluffOS, currently?
Thu Sep 3 03:36:54 2009
[imud_code]
Corrik@Lost Realms: Anyone interested in support to save/restore objects from MySQL?
Thu Sep 3 06:18:54 2009
[imud_code]
Corrik@Lost Realms: Does anyone have a source for a complete documentation of FluffOS 2.7? Or am I retarded to think that such a thing even exists?
Thu Sep 3 06:20:08 2009
[imud_code]
Newt@ShadowMUDii Dev: I think maybe changelog is as close as you'll get...I could be mistaken...and hope I am.
Thu Sep 3 06:21:26 2009
[imud_code]
Newt@ShadowMUDii Dev: It's not like there was complete docs for mudos. But, yes, still sad.
Thu Sep 3 06:57:57 2009
[imud_code]
Quixadhal@Bloodlines: I'm afraid the only complete docs are all those .c files, as is typical with most open-source projects. :(
Thu Sep 3 15:57:08 2009
[imud_code]
Corrik@Lost Realms: Anyone else having memory issues with FluffOS 2.7?
Fri Sep 4 20:21:00 2009
[imud_code]
Corrik@Lost Realms: Has anyone successfully implemented A* on MudOS that'd be willing to share some insight?
Fri Sep 4 20:23:04 2009
[imud_code]
Mecha@UOSSMUD: You'd probably generally do better by indexing the rooms beforehand with a crawler of some sort.
Fri Sep 4 20:23:27 2009
[imud_code]
Wodan@Discworld: it's always been nearly instant on dw, the only reason i moved it to external c++ is that people kept suggesting it was the reason for any lag we had (even though it wasn't!)
Fri Sep 4 20:23:31 2009
[imud_code]
Ideysus@ShadowMUDii: You could probably spread processing over heartbeats though. I've got a daemon that spiders over the entire mudlib. Each time eval_cost() gets low it returns until next heartbeat. Thats probably intensive than A* (which wouldn't need to cover every room)
Fri Sep 4 20:24:15 2009
[imud_code]
Wodan@Discworld: so unless you did something stupid or have a mud that's much bigger than dw, i wouldn't expect eval problems :)
Fri Sep 4 20:24:27 2009
[imud_code]
Mecha@UOSSMUD: Mmm. Whenever we've built that kind of thing, it generally evals out within some number of rooms of distance.
Fri Sep 4 20:24:45 2009
[imud_code]
Mecha@UOSSMUD: Like, I think the last time someone tried it, it was 14.
Fri Sep 4 20:25:18 2009
[imud_code]
Mecha@UOSSMUD: Or maybe loading rooms really just sucks that bad.
Fri Sep 4 20:25:30 2009
[imud_code]
Corrik@Lost Realms: Well, the current system I've made uses pre-indexed rooms
Fri Sep 4 20:25:44 2009
[imud_code]
Wodan@Discworld: oh.. well, if you need to load the rooms i suspect it will get slow
Fri Sep 4 20:26:01 2009
[imud_code]
Corrik@Lost Realms: I've got an array of arrays, each sub-array is a street
Fri Sep 4 20:26:03 2009
[imud_code]
Mecha@UOSSMUD: Right. If you have some sort of index, or just read the file without loadin git, I'm sure you could get it to work fine.
Fri Sep 4 20:27:30 2009
[imud_code]
Corrik@Lost Realms: I'm just really having trouble wrapping my head around how A* works, I guess.
Fri Sep 4 20:27:33 2009
[imud_code]
Mecha@UOSSMUD: It's not intense on its own, it's the damn IO, or loading the room, or loading the monsters in the room, or...
Fri Sep 4 20:28:54 2009
[imud_code]
Mecha@UOSSMUD: Honestly, I'd probably try to cheat and search from both ends.
Fri Sep 4 20:29:12 2009
[imud_code]
Mecha@UOSSMUD: Your entire MUD is 'known' to you. Use it to your advantage.
Fri Sep 4 20:29:15 2009
[imud_code]
Wodan@Discworld: that said, my first implementation did load the rooms, but after 30 minutes of loading lag, they were all loaded anyway, so it was ok after that :)
Fri Sep 4 20:29:58 2009
[imud_code]
Mecha@UOSSMUD can't really rely on any rooms being loaded. We're reasonably aggressive about cleanup.
Fri Sep 4 20:30:45 2009
[imud_code]
Corrik@Lost Realms: Well, I've got an index of all the rooms in my mud already anyways... just figured A* would be a good way to go about parsing the info i have.
Fri Sep 4 20:31:25 2009
[imud_code]
Mecha@UOSSMUD: Well, I guess the real question is 'what's your heuristic?'
Fri Sep 4 20:31:41 2009
[imud_code]
Mecha@UOSSMUD: How do you know that you're getting closer in any way?
Fri Sep 4 20:32:25 2009
[imud_code]
Mecha@UOSSMUD: That's why I think bidirectional: when two breadth-first searches intersect, you're done.
Fri Sep 4 20:47:45 2009
[imud_code]
Nilrin@Rebirth: Isn't there A* pathfinding posted on the boards some place?
Fri Sep 4 20:49:17 2009
[imud_code]
Silenus@Dead_Souls_silenus: yeah i think tricky and chaos each posted one
Fri Sep 4 20:50:02 2009
[imud_code]
Nilrin@Rebirth: I used one to make path finding NPCs. You might be able to use it for your indexing Corrik.
Fri Sep 4 20:54:30 2009
[imud_code]
Silenus@Dead_Souls_silenus: i think the basic idea of A* is pretty simple but implementing it efficiently requires you use some sort of heap data structure i am sure tricky could tell you more about it (or chaos)
Fri Sep 4 21:21:04 2009
[imud_code]
Quixadhal@Bloodlines: Just write a map daemon that keeps connected graphs of all the rooms (registered as they are loaded), and a tracking daemon that maps npcs and players to what room they're in (updated as they move). If the map/npc data persists, you just need to force every room to load once. :)
Fri Sep 4 21:22:11 2009
[imud_code]
Quixadhal@Bloodlines: If the source and target are not on the same connected graph, you can't get there (without maaaagjicks, or admin powers). :)
Fri Sep 4 21:23:09 2009
[imud_code]
Silenus@Dead_Souls_silenus: yeah make sure the map daemon gets updated as exits get added and removed though
Fri Sep 4 21:23:35 2009
[imud_code]
Quixadhal@Bloodlines: If you have terrain or other stuff that modifies your movement costs, you'll want those as weights on your nodes as they register, so your lowest cost algorithm gives you the cheapest (not always shortest) path.
Fri Sep 4 21:24:07 2009
[imud_code]
Silenus@Dead_Souls_silenus: i think A* can quite easily account for that
Fri Sep 4 21:25:36 2009
[imud_code]
Silenus@Dead_Souls_silenus: i think in general you weight the edges though not the nodes.
Sat Sep 5 02:11:47 2009
[imud_code]
Tricky@Rock the Halo: A* links on lpmuds.net -- http://lpmuds.net/forum/index.php?topic=393.0 and also http://lpmuds.net/forum/index.php?topic=372.0
Sat Sep 5 02:15:26 2009
[imud_code]
Tricky@Rock the Halo: As noted in my post see -- http://www.policyalmanac.org/games/aStarTutorial.htm
Tue Sep 8 06:26:38 2009
[imud_code]
Corrik@Lost Realms: I've written a handler that passes all of it's data on a callback function, but a new item im building requires that i'll need a blocking call to the handler... any ideas other than re-writing the handler to do blocking calls?
Tue Sep 8 18:54:39 2009
[imud_code]
Cratylus@Dead Souls Dev: so i was pokin around in fluffos to see if i could find that legendary option to make the parser default to the first object
Tue Sep 8 19:49:16 2009
[imud_code]
Cratylus@Dead Souls Dev: it cant be this easy. i musta missed something
Tue Sep 8 19:49:53 2009
[imud_code]
Cratylus@Dead Souls Dev: but rummaging around this http://dead-souls.net/code/libs/lima-1.0b5/lib/help/wizard/design_decisions/default_to_first_object
Tue Sep 8 19:54:26 2009
[imud_code]
Ideysus@ShadowMUDii: Discworlds's approach is to give you an option to toggle unambiguous parsing.
Tue Sep 8 19:56:08 2009
[imud_code]
Aransus@Pyloros: choice wins. i understand the motivation and explanation behind lima's decision. it just seems like one of those deals that makes high-level sense but is really annoying in practice.
Tue Sep 8 19:56:44 2009
[imud_code]
Raudhrskal@Dead Souls Dev: "We know better what's good for you."
Tue Sep 8 19:56:49 2009
[imud_code]
Ideysus@ShadowMUDii: I like the concept, I'm just colossally lazy. 'a ' is, like, two whole characters.
Tue Sep 8 19:56:52 2009
[imud_code]
Cratylus@Dead Souls Dev: and while i respect beeks towering achievements in blah yadda
Tue Sep 8 19:57:02 2009
[imud_code]
Cratylus@Dead Souls Dev: i refuse to believe he did that out of love for players
Tue Sep 8 19:58:14 2009
[imud_code]
Ideysus@ShadowMUDii: Hey, at least its better than enforced natural language. 'stab the first orc with my sword' :-)
Tue Sep 8 19:58:17 2009
[imud_code]
Cratylus@Dead Souls Dev: unfortunately i'm not leet enough to do it such that the player has option
Tue Sep 8 19:58:37 2009
[imud_code]
Cratylus@Dead Souls Dev: im just gonna allow for default first object
Tue Sep 8 19:59:07 2009
[imud_code]
Cratylus@Dead Souls Dev: is fast and works, just has that one thing
Tue Sep 8 19:59:09 2009
[imud_code]
Silenus@Dead Souls Dev: i figure you might not have the time either.
Tue Sep 8 19:59:11 2009
[imud_code]
Ideysus@ShadowMUDii: I'm working on a command parser right now. I don't think I'm going to even bother with unambiguous parsing.
Tue Sep 8 19:59:34 2009
[imud_code]
Cratylus@Dead Souls Dev: i was actually doing this ridiculous thing
Tue Sep 8 19:59:49 2009
[imud_code]
Cratylus@Dead Souls Dev: where the lib caught ERR_AMBIG and retried with modified stuff
Tue Sep 8 20:00:10 2009
[imud_code]
Silenus@Dead Souls Dev: it's just the zork mud parsing I am not sure if it's good for non zork muds.
Tue Sep 8 20:00:17 2009
[imud_code]
Cratylus@Dead Souls Dev: which is completely ludicrous, but i didnt want to ditch the compiled parser, and im not smart enough to grok the C conveniently
Tue Sep 8 20:00:28 2009
[imud_code]
Cratylus@Dead Souls Dev: but it looks like maybe i found what i needed
Tue Sep 8 20:00:59 2009
[imud_code]
Silenus@Dead Souls Dev: I can sort of get it now but I suspect I would have to comb through it to really understand it.
Tue Sep 8 20:01:23 2009
[imud_code]
Silenus@Dead Souls Dev: i think it contains alot of optimization stuff though
Tue Sep 8 20:01:24 2009
[imud_code]
Cratylus@Dead Souls Dev: what bothers me about the parser isnt necessarily the impenetrability
Tue Sep 8 20:01:39 2009
[imud_code]
Cratylus@Dead Souls Dev: it's that i get the impression it's INTENTIONALLY impenetrable
Tue Sep 8 20:01:43 2009
[imud_code]
Silenus@Dead Souls Dev: once you pull that stuff out it might be not so difficult to grasp
Tue Sep 8 20:01:51 2009
[imud_code]
Cratylus@Dead Souls Dev: so that, for example, beek's design decision is not trivial to reverse
Tue Sep 8 20:02:13 2009
[imud_code]
Silenus@Dead Souls Dev: i dunno about that though I can see where you are coming from
Tue Sep 8 20:02:51 2009
[imud_code]
Silenus@Dead Souls Dev: i think Beek (again speculation) was trying to write highly optimal code
Tue Sep 8 20:03:16 2009
[imud_code]
Silenus@Dead Souls Dev: so he added alot of stuff which complicates the parser i.e. the bitsets and so on.
Tue Sep 8 20:03:18 2009
[imud_code]
Cratylus@Dead Souls Dev: there's a subtle malevolence to some lima/mudos
Tue Sep 8 20:04:04 2009
[imud_code]
Silenus@Dead Souls Dev: perhaps you could see it that way and I dont like all parts of lima.
Tue Sep 8 20:04:11 2009
[imud_code]
Cratylus@Dead Souls Dev: all righty, now to test and see if this parser is doing what i think it's doing
Tue Sep 8 20:04:30 2009
[imud_code]
Silenus@Dead Souls Dev: but alot of the core design stuff was pretty good IMHO but all my own opinion of course :P
Tue Sep 8 20:05:12 2009
[imud_code]
Quixadhal@Bloodlines: There's no reason to think it won't worJNREIUH&#^$.NO CARRIER
Tue Sep 8 20:06:13 2009
[imud_code]
Aidil@Way of the Force throws in some comments about modern dsl/cable modems not giving that message..
Tue Sep 8 20:07:01 2009
[imud_code]
Aidil@Way of the Force: but.. whats the prob with a parser in LPC :)
Tue Sep 8 20:07:21 2009
[imud_code]
Silenus@Dead Souls Dev: well Beeks C parser was originally in LPC
Tue Sep 8 20:07:42 2009
[imud_code]
Aidil@Way of the Force: discworld does it iirc, and I'm sure about quite a few others.
Tue Sep 8 20:07:46 2009
[imud_code]
Silenus@Dead Souls Dev: unfortunately we no longer have that code.
Tue Sep 8 20:09:11 2009
[imud_code]
Cratylus@Dead Souls Dev: the speed arguments started failing the laug test when machine clock speeds went over 66mhz
Tue Sep 8 20:09:50 2009
[imud_code]
Aidil@Way of the Force: on mid 90s hardware, parsing player input in lpc on a large mud was mostly a non issue already, so.. I sortof wonder why the mud/fluffos parser needs to be heavily optimized.. I tend to agree with Crat on there probably being another reason for obfusication there :)
Tue Sep 8 20:10:39 2009
[imud_code]
Silenus@Dead Souls Dev: no idea Aidil but Beek was complaining about speed on Zork mud
Tue Sep 8 20:11:17 2009
[imud_code]
Silenus@Dead Souls Dev: but does require some effort to understand
Tue Sep 8 20:11:35 2009
[imud_code]
Aidil@Way of the Force: the parser it functionally tries to mimic ran on sub megahertz machines.
Tue Sep 8 20:12:01 2009
[imud_code]
Silenus@Dead Souls Dev: i sometimes suspect he did perhaps overdo the optimizations a bit just because he could :P (as an exercise maybe).
Tue Sep 8 20:12:41 2009
[imud_code]
Silenus@Dead Souls Dev: *nod* I have no idea all I can do is pass on what I remember being said.
Tue Sep 8 20:13:06 2009
[imud_code]
Quixadhal@Bloodlines: "Go east, then grab the rusty sword from the small corpse, then go north three rooms and kill the big ugly troll with the rusty sword using offensive stance and loot the corpse of everything but hard candy." You don't want to parse that??? :)
Tue Sep 8 20:13:16 2009
[imud_code]
Aidil@Way of the Force: it reminds me a bit of this compile lpc to c and dynamically link it to the driver.
Tue Sep 8 20:13:49 2009
[imud_code]
Aidil@Way of the Force: but at the time, it was the only way to make mudos keep up with the amylaar drivers of the time performance wise.
Tue Sep 8 20:14:06 2009
[imud_code]
Aidil@Way of the Force: which simply means there was a more structural issue, and this is a way to work around it.
Tue Sep 8 20:14:33 2009
[imud_code]
Quixadhal@Bloodlines: I think a lot of those optimization attempts were not just for limited hardware, but not forseeing the idea that an average joe would be able to have their own server.
Tue Sep 8 20:15:13 2009
[imud_code]
Aidil@Way of the Force: probably better vm, faster bytecode interpreter etc :) but thats just a guess.
Tue Sep 8 20:15:26 2009
[imud_code]
Silenus@Dead Souls Dev: well I always wonder how much you gain from going from LPC->C
Tue Sep 8 20:16:07 2009
[imud_code]
Aidil@Way of the Force: hard to say because it depends on the lpc dialect and on the actual code :)
Tue Sep 8 20:16:40 2009
[imud_code]
Aidil@Way of the Force: but, typically, on dgd the gain is an approx 5x increase :)
Tue Sep 8 20:17:17 2009
[imud_code]
Silenus@Dead Souls Dev: i guess it might depend on how you handle some of the function calls.
Tue Sep 8 20:17:44 2009
[imud_code]
Silenus@Dead Souls Dev: bc my attempt to JIT LPC looked horribly messy
Tue Sep 8 20:18:30 2009
[imud_code]
Aidil@Way of the Force: with real world lpc dialects, there is no way to safely disable much of the runtime checks.
Tue Sep 8 20:18:32 2009
[imud_code]
Silenus@Dead Souls Dev: I probably will have to look at Dworkin's code and see what exactly the LPC->C stuff is doing.
Tue Sep 8 20:18:58 2009
[imud_code]
Quixadhal@Bloodlines: There was also the percieved value of an lpc->C conversion allowing one to distribute binaries.
Tue Sep 8 20:19:38 2009
[imud_code]
Silenus@Dead Souls Dev: well given fluffos's design you dont really have binary compatibility.
Tue Sep 8 20:19:44 2009
[imud_code]
Aidil@Way of the Force: just being able to save the bytecode would do for that tho (which iirc mudos could as well at least for some time)
Tue Sep 8 20:20:21 2009
[imud_code]
Raudhrskal@Dead Souls Dev: yes, but mudos' opcodes->op mapping varies by recompile.
Tue Sep 8 20:20:31 2009
[imud_code]
Silenus@Dead Souls Dev: i mean for byte codes oops misread that quix.
Tue Sep 8 20:20:42 2009
[imud_code]
Aidil@Way of the Force: same on dgd at least for some of them :)
Tue Sep 8 20:21:03 2009
[imud_code]
Quixadhal@Bloodlines: I'm just thinking, if (for example) you didn't know an object lived at /daemons/ansi_d.c and that were compiled to C and linked into the driver, you wouldn't know you could override it.
Tue Sep 8 20:21:19 2009
[imud_code]
Aidil@Way of the Force: so a save includes some kind of symbol table that is used to remap those on load.
Tue Sep 8 20:21:57 2009
[imud_code]
Aidil@Way of the Force: objects() will very likely still tell you.
Tue Sep 8 20:22:21 2009
[imud_code]
Aidil@Way of the Force: and if it is callable at all, find_object() can tell you it exists.
Tue Sep 8 20:22:50 2009
[imud_code]
Quixadhal@Bloodlines: Sure, but security through obscurity never works for people who know how things work... it DOES work for the average joe who just wants to setup and run a mud.
Tue Sep 8 20:23:23 2009
[imud_code]
Quixadhal@Bloodlines: and that would be the target audience for someone handing them a compiled driver + mudlib.
Tue Sep 8 20:23:59 2009
[imud_code]
Raudhrskal@Dead Souls Dev: and that way you'd cut them down to diku level.
Tue Sep 8 20:24:04 2009
[imud_code]
Aidil@Way of the Force: but what would be the point of that? (and btw, you can create that exact situation right now with dgd if you want, but at the expense of being able to use things like gurbalib's warmboot)
Tue Sep 8 20:24:31 2009
[imud_code]
Quixadhal@Bloodlines: Not saying it's a GOOD thing, just that it's one perceived value of lpc->C compilation.
Tue Sep 8 20:25:09 2009
[imud_code]
Aidil@Way of the Force: but to me it seems totally contrary the ideas behind an lpmud :)
Tue Sep 8 20:25:38 2009
[imud_code]
Aidil@Way of the Force: people have been talking about distributing a dgd mudlib as statedump..
Tue Sep 8 20:25:47 2009
[imud_code]
Silenus@Dead Souls Dev: the whole mixed call_other returning mixed situation makes LPC extremely difficult to compile properly
Tue Sep 8 20:26:18 2009
[imud_code]
Aidil@Way of the Force: have seen that talk for a decade now, but, it is so impractical once someone starts actually running it, and having questions or bugs, that I still have to see the first serious try :)
Tue Sep 8 20:26:34 2009
[imud_code]
Aidil@Way of the Force: maybe so, but it has been done Silenus :)
Tue Sep 8 20:26:48 2009
[imud_code]
Silenus@Dead Souls Dev: yeah but the speed up is somewhat more limited
Tue Sep 8 20:26:57 2009
[imud_code]
Aidil@Way of the Force: and, that thing you complain about, is exactly part of what makes it such a nice language for the actual users of it.
Tue Sep 8 20:27:04 2009
[imud_code]
Quixadhal@Bloodlines: I guess you could. lpc->C would leave you the objects without source. A statedump would do the same, but be unrecoverable if you dest'd the wrong thing (other than restoring a backup dump file).
Tue Sep 8 20:27:25 2009
[imud_code]
Silenus@Dead Souls Dev: perhaps Aidil. I dont really see a need for call_other() being the way it is.
Tue Sep 8 20:27:28 2009
[imud_code]
Aidil@Way of the Force: well, you can make things undestructable quite easily.
Tue Sep 8 20:28:14 2009
[imud_code]
Aidil@Way of the Force: maybe you don't, I don't see a need for the complexity of the alternatives :)
Tue Sep 8 20:28:30 2009
[imud_code]
Silenus@Dead Souls Dev: I dont find the alternatives more complex :P
Tue Sep 8 20:28:33 2009
[imud_code]
Aidil@Way of the Force: a deserialize function that can really return any possible type is mixed.
Tue Sep 8 20:28:54 2009
[imud_code]
Aidil@Way of the Force: and anything you want to do to change that involves somehow ending up with more code and work for the programmer.
Tue Sep 8 20:29:34 2009
[imud_code]
Quixadhal@Bloodlines: Actually... it doesnt' have to be. You could specify the type you expect to get back and throw an exception/error on a mismatch.
Tue Sep 8 20:29:41 2009
[imud_code]
Aidil@Way of the Force: but writing a compiler is a one time job.
Tue Sep 8 20:29:55 2009
[imud_code]
Silenus@Dead Souls Dev: actually it's more complex for a compiler writer
Tue Sep 8 20:30:03 2009
[imud_code]
Aidil@Way of the Force: when dealing with network data you have never seen before, there is absolutely no way you can do that, Quix.
Tue Sep 8 20:30:18 2009
[imud_code]
Quixadhal@Bloodlines: I'd prefer that to mixed, myself. If I know I want an "object foo", and I get something else, that's an error.
Tue Sep 8 20:30:44 2009
[imud_code]
Aidil@Way of the Force: yes, but you really can't know in quite a common case that I just mentioned.
Tue Sep 8 20:30:57 2009
[imud_code]
Aidil@Way of the Force: think real world, not ideal predictable world.
Tue Sep 8 20:30:59 2009
[imud_code]
Silenus@Dead Souls Dev: especially given how prevalent imposing static typing using virtual function pointers is nowadays (java,C++) etc.
Tue Sep 8 20:31:18 2009
[imud_code]
Aidil@Way of the Force: yes, and as a developer, I hate both those languages :)
Tue Sep 8 20:31:22 2009
[imud_code]
Silenus@Dead Souls Dev: alot of developers might actually find mix more foreign
Tue Sep 8 20:31:51 2009
[imud_code]
Quixadhal@Bloodlines: At the point you're doing call_other(), you're in code. If you don't know what to expect, how do you expect to deal with it anyways? Most network libraries treat data as string chunks until parsed into a context.
Tue Sep 8 20:33:06 2009
[imud_code]
Aidil@Way of the Force: because you don't. just put some more thought in it, Quixadhal, you can't know beforehand what data is encoded in say a JSON or mudmode network packet until after you decoded it, which is the exact point that your call_other is going to return the data.
Tue Sep 8 20:33:24 2009
[imud_code]
Aidil@Way of the Force: there is absolutely no way to know beforehand without parsing the message twice.
Tue Sep 8 20:34:16 2009
[imud_code]
Aidil@Way of the Force: there may be ways for the code doing the call_other to predict it in certain cases, but not in a generic way.
Tue Sep 8 20:36:51 2009
[imud_code]
Quixadhal@Bloodlines: Put it another way... what are you doing the call_other() for? If you're expecting an object of a given type, it better BE data the can populate such an object, or it's an error. If you don't know, then you're expecting a parser to deal with it and make some sense out of it. At some point, you have to use what you got back.
Tue Sep 8 20:37:40 2009
[imud_code]
Raudhrskal@Dead Souls Dev: Actually, LPC's call_other is not entore unlike Samlltalk's message passing.
Tue Sep 8 20:37:55 2009
[imud_code]
Aidil@Way of the Force: yes, and that parser just so happens to be a different object, which you call with a string argument (containing the message), and will return whatever sillyness happens to be encoded in it.
Tue Sep 8 20:38:05 2009
[imud_code]
Aidil@Way of the Force: which you will only know when it has been returned.
Tue Sep 8 20:38:07 2009
[imud_code]
Quixadhal@Bloodlines: If I just say "go get some random object" and it plops it in my lap... now what? If I don't know the type AND I don't have a common API, what good is it?
Tue Sep 8 20:38:18 2009
[imud_code]
Raudhrskal@Dead Souls Dev: you send to an object, (you don't know what it is) a message to do something. It can do anything with the message, including ignoring it.
Tue Sep 8 20:38:58 2009
[imud_code]
Silenus@Dead Souls Dev: but i think even it is more constrained than
Tue Sep 8 20:39:28 2009
[imud_code]
Silenus@Dead Souls Dev: i.e. i think you can impose static style optimizations on smalltalk code
Tue Sep 8 20:39:29 2009
[imud_code]
Aidil@Way of the Force: Sorry, Quix, that makes no sense whatsoever in the context of lpc and mixed.
Tue Sep 8 20:39:38 2009
[imud_code]
Aidil@Way of the Force: because you can quite tell what type it is once you got it.
Tue Sep 8 20:39:44 2009
[imud_code]
Raudhrskal@Dead Souls Dev: it's all "I have an object, I ask it to do a thing. It either does it, or doesn't."
Tue Sep 8 20:40:01 2009
[imud_code]
Silenus@Dead Souls Dev: yep but I think you can to some extent infer the type of object
Tue Sep 8 20:40:26 2009
[imud_code]
Raudhrskal@Dead Souls Dev: btw, Sil, sorry that i have to say that to you, but F**K OPTIMIZATIONS!
Tue Sep 8 20:40:29 2009
[imud_code]
Silenus@Dead Souls Dev: i think this is not possible in LPC given that call_other can point to anything.
Tue Sep 8 20:40:47 2009
[imud_code]
Silenus@Dead Souls Dev: which poses problems from an optimizer :P
Tue Sep 8 20:41:19 2009
[imud_code]
Raudhrskal@Dead Souls Dev: Well, if you'd get a version of LPC where everything's an object and there are no primitive types...
Tue Sep 8 20:41:34 2009
[imud_code]
Aidil@Way of the Force: and even if it is not a lot, it is an irrelevant question.
Tue Sep 8 20:41:42 2009
[imud_code]
Silenus@Dead Souls Dev: and LPC isnt really statically typed it just sort of pretends to be :P
Tue Sep 8 20:41:47 2009
[imud_code]
Aidil@Way of the Force: how important is its use, that would be the relevant question.
Tue Sep 8 20:41:49 2009
[imud_code]
Raudhrskal@Dead Souls Dev: it's even more similar to the message model.
Tue Sep 8 20:42:04 2009
[imud_code]
Silenus@Dead Souls Dev: to me i think i could design a library in say java
Tue Sep 8 20:42:17 2009
[imud_code]
Silenus@Dead Souls Dev: which does similar things to an LPC library and I wouldnt have call other
Tue Sep 8 20:42:43 2009
[imud_code]
Silenus@Dead Souls Dev: and I disagree on the optimization thing... but it really depends on what you want to do with the platform
Tue Sep 8 20:42:59 2009
[imud_code]
Aidil@Way of the Force: I rather want the prototype alike structure of lpc and alike.
Tue Sep 8 20:43:22 2009
[imud_code]
Aidil@Way of the Force: optimizing is something you do when you have your functionality 100% ok.
Tue Sep 8 20:43:33 2009
[imud_code]
Aidil@Way of the Force: you first do it well, and then if possibly also fast.
Tue Sep 8 20:43:47 2009
[imud_code]
Quixadhal@Bloodlines: Ok, let's say I ask for an instance of a monster (/std/monster.c), and call_other instead funbles around and ends up giving me a player (/std/player.c). Yes, I know the type of the object. However, unless I know that the player and monster types have some overlapping API's, what do I do with it? I'd rather be able to cast the call_other so that a type mismatch is an error, rather than the error happening when I try to use what I got back later on.
Tue Sep 8 20:44:01 2009
[imud_code]
Aidil@Way of the Force: Quic, for that you don't need mixed no,.
Tue Sep 8 20:44:16 2009
[imud_code]
Aidil@Way of the Force: but could you PLEASE put some thought into the json example I gave you?
Tue Sep 8 20:44:22 2009
[imud_code]
Silenus@Dead Souls Dev: i dont think that's true for language design tho
Tue Sep 8 20:44:37 2009
[imud_code]
Silenus@Dead Souls Dev: you either make some choice which cannot be optimized (if you think it's important)
Tue Sep 8 20:44:48 2009
[imud_code]
Aidil@Way of the Force: I'm not sayin you always need it, in fact, often you don't. But, there are things where you DO need it.
Tue Sep 8 20:45:02 2009
[imud_code]
Raudhrskal@Dead Souls Dev: You don't want to know the type of the object.
Tue Sep 8 20:45:15 2009
[imud_code]
Raudhrskal@Dead Souls Dev: You call ob->func(). It returns undefined, or not.
Tue Sep 8 20:45:17 2009
[imud_code]
Silenus@Dead Souls Dev: are saddled a priori with something which cannot be made particularly fast.
Tue Sep 8 20:45:19 2009
[imud_code]
Aidil@Way of the Force: and if you want to provide a counter argument, please respond to the case where it is needed, and explain why it is not.
Tue Sep 8 20:46:03 2009
[imud_code]
Silenus@Dead Souls Dev: the socalled classical OO model (i.e. with static checks unlike smalltalk/self) to me is a compromise.
Tue Sep 8 20:46:43 2009
[imud_code]
Silenus@Dead Souls Dev: it's something which can be made reasonably fast and then a whole body of work developed around how to write code for it.
Tue Sep 8 20:47:42 2009
[imud_code]
Aidil@Way of the Force: and with regards to the random things being returned, if you assign the return of a call_other to some typed variable, you get a nice error if the return is of the wrong type.
Tue Sep 8 20:47:44 2009
[imud_code]
Raudhrskal@Dead Souls Dev: Actually, now that I think about it, call_other is a bit liky ruby's duck typing. The difference is that ruby would error out on calling a non-existing method, so you do a precall has_method? check. In LPC you call_other, then check if it returned non-undefined value (or in other words, acknowledged the message).
Tue Sep 8 20:47:52 2009
[imud_code]
Aidil@Way of the Force: so, mixed in no way stands in the way of what you want.
Tue Sep 8 20:48:29 2009
[imud_code]
Aidil@Way of the Force: the 'issue' here is that that happens during runtime, not compile time.. whereas the later would be much better performance wise.
Tue Sep 8 20:50:51 2009
[imud_code]
Aidil@Way of the Force: and less flexible, and causing the need for extra code that serves no function other then satisfy the compiler :P
Tue Sep 8 20:51:35 2009
[imud_code]
Silenus@Dead Souls Dev: well depends on how you feel about type annotations :P
Tue Sep 8 20:52:19 2009
[imud_code]
Aidil@Way of the Force: Sil, just like Quix, please accept for a fact that there are things that by design must return values of which you cannot know the type until after you produced the value.
Tue Sep 8 20:52:31 2009
[imud_code]
Raudhrskal@Dead Souls Dev dreams, "If only FluffOS would keep line numbers in the bytecode structure and print them in runtime errors..."
Tue Sep 8 20:52:46 2009
[imud_code]
Aidil@Way of the Force: you will have to write code to do that while satisfying the type checking.
Tue Sep 8 20:53:55 2009
[imud_code]
Silenus@Dead Souls Dev: the more I wonder about whether you can just impose interfaces on certain entities to get some speed up in certain cases. in general of course you are right given LPC's model it's impossible.
Tue Sep 8 20:53:59 2009
[imud_code]
Quixadhal@Bloodlines: That would be useful if mixed worked more like C's void, which is specifically a way to pass blocks of memory around that MUST be nailed down to a static type before they can be used as anything else.
Tue Sep 8 20:54:40 2009
[imud_code]
Silenus@Dead Souls Dev: problem being you cannot pin down the interface since LPC recompiles can change them arbitrarily.
Tue Sep 8 20:54:58 2009
[imud_code]
Silenus@Dead Souls Dev: unless you recompile all the users of said code
Tue Sep 8 20:55:19 2009
[imud_code]
Aidil@Way of the Force: in a different world (ie, entirely different language design) you can likely do without, but not in the 'world' we are talking about here.
Tue Sep 8 20:56:03 2009
[imud_code]
Silenus@Dead Souls Dev: it does give benefits tho assuming you are willing to do that sort of recompile because at the very least you can figure out what type of object you are working with.
Tue Sep 8 20:56:26 2009
[imud_code]
Aidil@Way of the Force: Quix, it is useful, and if you want to know why, check the code in /daemons/serialize on gurbalib, and try to write them in LPC without mixed.
Tue Sep 8 20:56:59 2009
[imud_code]
Aidil@Way of the Force: What other objections then performance are there against doing that on runtime where needed?
Tue Sep 8 20:57:46 2009
[imud_code]
Silenus@Dead Souls Dev: but it might not be too big an issue for some ppl.
Tue Sep 8 20:57:49 2009
[imud_code]
Aidil@Way of the Force: one more hour spent on writing a compiler that will save every user of it a minute of time every so often is well spent.
Tue Sep 8 20:58:10 2009
[imud_code]
Aidil@Way of the Force: because user minutes multiply, the time spent on writing the compiler is spent once.
Tue Sep 8 20:58:38 2009
[imud_code]
Aidil@Way of the Force: so, 'it makes it easier to write the compiler' generally is not a good argument.. :)
Tue Sep 8 20:58:41 2009
[imud_code]
Silenus@Dead Souls Dev: like alot of ppl object to using languages like lisp/smalltalk because to make sure the type discipline is correct
Tue Sep 8 20:59:01 2009
[imud_code]
Silenus@Dead Souls Dev: actually it's harder to implement a good v table than doing a call other :P
Tue Sep 8 20:59:57 2009
[imud_code]
Silenus@Dead Souls Dev: you need to well check every path with type checking code.
Tue Sep 8 21:00:16 2009
[imud_code]
Aidil@Way of the Force: btw, recompiling all users of an interface.. you do not know which users exist until they are actually making the call :)
Tue Sep 8 21:01:47 2009
[imud_code]
Silenus@Dead Souls Dev: but if you have a module x it does call some object which has it's type checked in
Tue Sep 8 21:02:04 2009
[imud_code]
Silenus@Dead Souls Dev: at the call site as something conforming to some interface.
Tue Sep 8 21:02:35 2009
[imud_code]
Silenus@Dead Souls Dev: so if you separate the interface from the implementation you can determine certain things.
Tue Sep 8 21:03:11 2009
[imud_code]
Ideysus@ShadowMUDii: Okay, does the sparc solaris installer actually let you switch to a virtual terminal or somehow suspend the installer so I can use a shell?
Tue Sep 8 21:03:34 2009
[imud_code]
Ideysus@ShadowMUDii: Also, I demand a gold star from Cratylus for installing sparc solaris.
Tue Sep 8 21:03:54 2009
[imud_code]
Aidil@Way of the Force: oh, and Sil, if you want to, you can enforce that in DGD's lpc dialect as it is today.
Tue Sep 8 21:04:20 2009
[imud_code]
Aidil@Way of the Force: have to declare your objects as 'object "type" name'
Tue Sep 8 21:04:52 2009
[imud_code]
Silenus@Dead Souls Dev: it's just if you are doing it from scratch... you might as well jet the type tags as well.
Tue Sep 8 21:05:05 2009
[imud_code]
Aidil@Way of the Force: that tells you which interfaces might be used by some piece of code.
Tue Sep 8 21:05:16 2009
[imud_code]
Aidil@Way of the Force: not the reverse, which pieces of code use which interface.
Tue Sep 8 21:05:56 2009
[imud_code]
Silenus@Dead Souls Dev: well you wont know which pieces of code use xxx interface until you compile the code assuming you arent doing call_other(var string stuff)
Tue Sep 8 21:06:54 2009
[imud_code]
Wodan@Discworld: ah, lpc->c, i remember it well, it took longer to compile the converted ftp deamon than it took to compile the driver :)
Tue Sep 8 21:07:14 2009
[imud_code]
Wodan@Discworld: which made the compile and dynamically load things option rather useless
Tue Sep 8 21:07:30 2009
[imud_code]
Silenus@Dead Souls Dev: it just seems a bit strange to have both type tags and a language design that doesnt need them :P
Tue Sep 8 21:07:58 2009
[imud_code]
Silenus@Dead Souls Dev: and of course the code (bytecode size) drops dramatically
Go to the top | Channel Index
