Fri Oct 2 20:19:21 2009
[dgd]
Sorressean@Falcon: will that require that the other routers be linked to me?
Fri Oct 2 20:19:39 2009
[dgd]
Aidil@Way of the Force: then, you'll have to be trusted by all other participating routers. the inter router network is not an open network.
Fri Oct 2 20:21:21 2009
[dgd]
Aidil@Way of the Force: but, overal *i4 and *wpr are both pretty stable and run on hosted servers, not from some home dsl connection.
Fri Oct 2 20:22:31 2009
[dgd]
Sorressean@Falcon nods. I was planning on running off a stable server. probably the one that this is running off of, actually, just thought it might be of assistance, and it sounded like a fun project. :p
Fri Oct 2 20:24:02 2009
[dgd]
Sorressean@Falcon: I'm going to have to learn the i3 protocol anyway soonish.
Fri Oct 2 20:24:44 2009
[dgd]
Aidil@Way of the Force: not to mention, the spec is out of date and somewhat ambigious :)
Fri Oct 2 20:25:15 2009
[dgd]
Aidil@Way of the Force: the spec + looking at some commonly used clients.
Fri Oct 2 20:26:49 2009
[dgd]
Aidil@Way of the Force: heh. if I ever get through my current list of things I want to add to gurbalib, I might consider porting my router implementation to it.
Fri Oct 2 20:27:34 2009
[dgd]
Sorressean@Falcon: lucky for me I don't have to do the router bit. just the client-side work. and yeah.
Fri Oct 2 20:28:46 2009
[dgd]
Aidil@Way of the Force: before that happens, there should be a preliminary i3 v4 spec and i3 over json instead of mudmode support.
Fri Oct 2 20:30:01 2009
[dgd]
Sorressean@Falcon: I want to work on getting channels and tells working, then work on the higher stuff. Implamenting that in c++ should be fun. :(
Fri Oct 2 20:31:13 2009
[dgd]
Kalinash@Fire and Ice: it's not bad... "mud" mode sockets are just length prefixed strings of save_variable() output
Fri Oct 2 20:31:19 2009
[dgd]
Kalinash@Fire and Ice: I think I implemented the parser for that in a day or two
Fri Oct 2 20:31:55 2009
[dgd]
Aidil@Way of the Force: for implementing i3 in c++ i3 over json might be easier tho since there already exist parsers for that.
Fri Oct 2 20:34:59 2009
[dgd]
Aidil@Way of the Force: btw, gurbalib parses and generates mudmode in lpc. You'll need some parser generator, but could use that as a starting point for implementing the same in c++
Fri Oct 2 20:35:40 2009
[dgd]
Kalinash@Fire and Ice: or i could give you a bunch of C code that's specific to the Pike codebase :)
Fri Oct 2 20:36:56 2009
[dgd]
Kalinash@Fire and Ice: i've been tinkering with building a driver using it as the embedded language
Fri Oct 2 20:37:18 2009
[dgd]
Sorressean@Falcon: I want to put in some sorta backend like lua or something for mscripting
Tue Oct 6 23:04:49 2009
[dgd]
Sorressean@Falcon: when I'm not using it I guess. to be fair, I could probably get used to it, but... not for what I wanted.
Tue Oct 6 23:06:26 2009
[dgd]
Sorressean@Falcon: I was looking for some docs on compiler design. I have an idea for a script language I want to play with, and one of the links I found used pascal.
Tue Oct 6 23:11:19 2009
[dgd]
Sorressean@Falcon: heh. it probably wouldn't be that bad, but learning compiler design and theory and combining that with learning pascal would be rough
Wed Oct 7 00:44:42 2009
[dgd]
Silenus@Dead Souls Dev: consider compilers principles techniques and tools
Wed Oct 7 04:12:52 2009
[dgd]
Sorressean@Falcon: yeah. I'd like that book, I haven't found an accessible version of it though.
Wed Oct 7 13:54:17 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 352 to svn://wotf.org/gurbalib : Merged dgd 1.3.8 from vendor branch
Wed Oct 7 22:03:37 2009
[dgd]
Aidil@GurbaDev2: nice shortcut for returning multiple values and directly assigning them without needing some temp array.
Wed Oct 7 22:03:59 2009
[dgd]
Aidil@GurbaDev2: tho, the temp array is there still, but never exists as a variable.
Wed Oct 7 22:04:10 2009
[dgd]
Kalinash@Fire and Ice: functions that return more than one value? bollocks I say!
Wed Oct 7 22:12:55 2009
[dgd]
Subversion@Way of the Force: Aidil committed revision 46 to svn://wotf.org/dgd-devel-net : Imported dgd 1.3.8 from vendor branch
Mon Oct 12 09:12:34 2009
[dgd]
Subversion@Way of the Force: Aidil committed revision 47 to svn://wotf.org/dgd-devel-net : Imported 1.3.9 from vendor branch
Mon Oct 12 09:13:22 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 353 to svn://wotf.org/gurbalib : Imported dgd 1.3.9 from vendor branch
Sun Oct 25 14:49:38 2009
[dgd]
Thingol@Middle-earth: I was wondering, is there a way to retrieve the datatype of a function, other than using a call_other on it?
Sun Oct 25 15:14:28 2009
[dgd]
Kalinash@Fire and Ice: you mean you want to find out the prototype of the function?
Sun Oct 25 15:16:02 2009
[dgd]
Thingol@Middle-earth: The same as when using typeof() on a variable. I noticed status(ob) doesn't support it.
Sun Oct 25 15:17:20 2009
[dgd]
Kalinash@Fire and Ice: i don't think you can... you need to use a mixed variable to hold the return value and then use typeof() on that
Sun Oct 25 15:18:42 2009
[dgd]
Thingol@Middle-earth: I'm affraid that won't do for what I had in mind. I'd like to make a function that will return the datatype of whatever the function calling it would have returned.
Sun Oct 25 15:20:15 2009
[dgd]
Kalinash@Fire and Ice: yeah, it's an efun in fluffos/mudos... didn't think dgd had that
Sun Oct 25 15:21:38 2009
[dgd]
Kalinash@Fire and Ice: but i still don't see why you need to know the return type of a function you didn't call...
Sun Oct 25 15:21:46 2009
[dgd]
Thingol@Middle-earth: I can already do that for int funcs of course, but I'd like it to work for any datatype function. Right now I have to use a macro for voids, that's really messy.
Sun Oct 25 15:22:26 2009
[dgd]
Thingol@Middle-earth: DGD will give a compile error when trying to return a function from a void function.
Sun Oct 25 15:23:37 2009
[dgd]
Kalinash@Fire and Ice: well, notify_fail() just sets the action failure string so users see something other than "What?"
Sun Oct 25 15:24:39 2009
[dgd]
Thingol@Middle-earth: Indeed, but I need return notify_fail() to work as well.
Sun Oct 25 15:24:41 2009
[dgd]
Kalinash@Fire and Ice: but it sounds like you're trying to do some type of reflection that the driver doesn't support
Sun Oct 25 15:25:31 2009
[dgd]
Thingol@Middle-earth: It seems so, I guess I can put it on DGD mailing list. Perhaps Dworkin feels like adding it to status()
Sun Oct 25 15:25:37 2009
[dgd]
Kalinash@Fire and Ice: well, if you're using it in a function that has no return, then you don't use it that way :)
Sun Oct 25 15:26:59 2009
[dgd]
Kalinash@Fire and Ice: to have anything between 'return' and ';' in a function with no return type is gramatically incorrect
Sun Oct 25 15:27:51 2009
[dgd]
Kalinash@Fire and Ice: since void isn't a type, even if you have 'void notify_fail(string)' you can''t 'return notify_fail();'
Sun Oct 25 16:37:37 2009
[dgd]
Silenus@Dead Souls Dev: i think the answer I got from Dworkin was implement it in LPC
Sun Oct 25 16:39:08 2009
[dgd]
Silenus@Dead Souls Dev: but honestly it requires you write a preprocessor to extract the information from lpc code
Wed Oct 28 17:32:07 2009
[dgd]
Silenus@Dead Souls Dev: he was on briefly on wotf but was quite idle so i didnt send him a tell this was about a week ago.
Sun Nov 15 22:25:43 2009
[dgd]
Marajin@AndroDGD-Upd: Adjust for wind.. compensate for curvature of the earth..
Mon Nov 16 03:30:37 2009
[dgd]
Sorressean@Falcon: Aidil: I found a quick bug. when loading races, for some odd reason /obj/races just inherits /std/races/race_name, I just fixed race_d to point to the /std/races dir and removed the extra inheritance.
Go to the top | Channel Index
