[02:54:28] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[02:54:29] --> Kirben2 has joined #pentagram
[05:24:29] --- Kirben2 is now known as Kirben
[06:09:11] --- Darke|zzZ is now known as Darke
[09:27:43] --> Kirben2 has joined #pentagram
[09:27:44] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[09:30:31] --> Kirben has joined #pentagram
[09:30:32] <-- Kirben2 has left IRC (Read error: 104 (Connection reset by peer))
[10:19:12] <-- Kirben has left IRC (Read error: 110 (Connection timed out))
[11:23:26] --> Colourless has joined #Pentagram
[11:23:26] --- ChanServ gives channel operator status to Colourless
[11:28:25] --> Kirben has joined #pentagram
[11:28:25] --- ChanServ gives channel operator status to Kirben
[12:39:16] <Darke> Surreal Thought For The Night: Adding IEEE floating point support to usecode.
[13:01:05] <Colourless> hmm, is there are real point? if you can come up with a reason to do so, it would be a fairly logical extension to the language
[13:03:18] * Darke hides!
[13:03:29] <Colourless> i can see you
[13:03:37] * Darke would rather not. Really. *Grin*
[13:03:51] <Colourless> it would make the compiler just a 'tad' more complex :-)
[13:04:58] <Colourless> you'd need to have things like if (left_node.type == UCTYPE_FLOAT && right_node.type != UCTYPE_FLOAT) and a whole lot of other similar garbage all over the place
[13:05:33] <Darke> Eh? We've already got bytes/words/dwords/strings/lists/slists, of which there are about three copies of 'identical' opcodes for them how much more complex could it make it? *grin*
[13:06:02] <Colourless> well implementing it in the interpreter would be trivial. we'd just need to think of the required opcodes
[13:06:44] * Darke would probably add a ddword type first to see how complex it might be. *Grin*
[13:07:14] <Colourless> i think a ddword/qword/int64 would be excessive
[13:07:37] <Darke> Awwwwwww.
[13:07:54] <Colourless> for floats all you'd 'really' need is +-*/ int_to_float and float_to_int
[13:08:46] <Colourless> now, i'm trying to think, is there anything else that you'd want with floats
[13:09:15] <Colourless> and of course what precision do you want single 32bit and/or double 64bit :-)
[13:10:11] <Darke> 32bit of course, 64bit "would be excessive". *innocentlook*
[13:10:19] <Colourless> indeed :-)
[13:11:48] <Colourless> now then, do you want flists and do you want to be able to add floats to strings :-)
[13:11:56] <Darke> Isn't there are word->string opcode? Or am I thinking of one of the intrinsics.
[13:12:27] <Colourless> word->string would be an opcode as far as I know
[13:13:05] * Darke just can't find it however.
[13:13:33] <Darke> Ahh. 'concat'.
[13:14:30] <Darke> General form of use is `push string; push word; concat;`.
[13:15:40] <Darke> Hmm... actually, I may be confuzzled.
[13:16:16] <Colourless> 0A78: 0F calli 02 B9 00 (numToStr(ushort))
[13:16:32] * Darke was looking at the remorse disassembly for that, not the brightest thing to do. *Grin*
[13:16:41] <Darke> 'concat' just concats strings.
[13:16:50] <Colourless> :-)
[13:16:57] * Darke thought it might have been an intrinsic. *grin*
[13:17:49] <Colourless> also is strToNum(char*) too
[13:22:04] * Darke gives remorse usecode class 2590 (0A1E ITEM), function ITEM::ordinal25: the award for having the stupidist number of internal variables (all in total 23) for about a 100 lines of code.
[13:22:59] <Darke> ITEM::ordinal26: comes a close second with 22, over the same number of LOC. *Grin*
[13:25:06] <Darke> NPCDEATH::ordinal20: (class 2588) has one more variable, but it's over 800ish LOC, so it's excused. *Grin*
[13:25:17] <Darke> OTOP, an 800 LOC function is scary in it's own right...
[13:25:39] <Colourless> hmm, i guess that a number of those vars must be in an array or something
[13:27:10] <Darke> destX/destY/destZ/vel/currentP/x/y/z/w/h/counter/minor/r/q/oabs/v/ovel/c/axis/ztarg/zcur/dif Mostly ints, two bytes and a structure.
[13:47:03] --> Kirben2 has joined #pentagram
[13:47:04] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[13:49:01] * Darke considers that at some point he wants to make the language a 'proper' high level language, (not just something that looks like C *grin*), with things like 'WorldPoint' (comprising of an x, y and z attribute) datatypes, and types more complex. Sure they can be replicated by structs (once we implement them), but what's the point of having a domain specific, high level language if we don't target it to the domain? *grin*
[13:49:21] --- Kirben2 is now known as Kirben
[13:52:00] <Darke> Of course at the usecode level, it'd still look like bytes/words/dwords/... though.
[13:52:18] <Colourless> well, it's just the compiler which has to do the work
[13:52:27] <Darke> Yup.
[13:55:12] * Darke considers sleep. Finds it good. And wanders off. Night!
[13:55:28] <Colourless> cya
[13:55:43] --- Darke is now known as Darke|zzZ
[14:54:46] --- ChanServ removes channel operator status from Darke|zzZ
[16:58:45] <-- Colourless has left IRC ("casts invisibility")
[17:12:40] <-- Kirben has left IRC (Read error: 54 (Connection reset by peer))
[17:49:43] --> wjp has joined #pentagram
[17:49:43] --- ChanServ gives channel operator status to wjp
[21:07:41] <-- wjp has left IRC (Killed (NickServ (Ghost: firstname.lastname@example.org)))
[21:08:05] --> wjp has joined #pentagram
[21:08:05] --- ChanServ gives channel operator status to wjp
[22:56:32] <-- wjp has left IRC (Remote closed the connection)
[23:57:18] --> Kirben has joined #pentagram
[23:57:18] --- ChanServ gives channel operator status to Kirben