00:00:00 --- log: started forth/13.08.04
00:15:20 --- join: ncv (~quassel@79.114.112.168) joined #forth
00:15:20 --- quit: ncv (Changing host)
00:15:20 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth
00:54:45 --- quit: ncv (Ping timeout: 240 seconds)
01:33:43 --- join: epicmonkey (~epicmonke@188.134.41.114) joined #forth
02:00:16 --- quit: epicmonkey (Ping timeout: 264 seconds)
02:21:21 --- join: goingretro (~kbmaniac@host109-155-40-193.range109-155.btcentralplus.com) joined #forth
02:31:43 --- quit: kludge` (Ping timeout: 264 seconds)
02:37:33 --- join: kludge` (~comet@unaffiliated/espiral) joined #forth
03:18:44 --- join: true-grue (~quassel@95-28-205-254.broadband.corbina.ru) joined #forth
03:18:50 --- quit: c00kiemon5ter (Ping timeout: 264 seconds)
03:19:45 --- join: c00kiemon5ter (~c00kiemon@foss-aueb/coder/c00kiemon5ter) joined #forth
03:49:11 --- join: epicmonkey (~epicmonke@188.134.41.114) joined #forth
04:20:34 --- join: ncv (~quassel@79.114.112.168) joined #forth
04:20:34 --- quit: ncv (Changing host)
04:20:34 --- join: ncv (~quassel@unaffiliated/neceve) joined #forth
06:48:35 --- quit: epicmonkey (Ping timeout: 276 seconds)
07:19:30 --- quit: overdamped (Quit: leaving)
07:44:33 --- join: Nisstyre (~yours@oftn/member/Nisstyre) joined #forth
08:00:46 --- join: epicmonkey (~epicmonke@host-224-58.dataart.net) joined #forth
09:10:24 --- quit: epicmonkey (Read error: Operation timed out)
09:12:50 --- join: Kumul (~nmz@adsl-64-237-237-200.prtc.net) joined #forth
09:21:14 <Vuokko> how this is done right? : xorwith> ( d "name" -- ) create , does> xor ; It needs literal lit or something. I'm using gforth.
09:23:17 <tangentstorm> hmm
09:23:39 <koisoke> : xorwith> create , does> @ xor ;
09:23:55 <koisoke> if i understand what you are trying to do
09:24:34 <koisoke> er sorry one second
09:26:04 <Vuokko> I want to say 25 xorwith> xor25 and it always xors with 25
09:26:54 <koisoke> then as above.
09:30:16 <Vuokko> how that can work? if comma takes item from stack and puts it in the newly created  definition, what what fetch fetches when executed?
09:30:28 <tangentstorm> reading http://www.taygeta.com/forth/dpans6.htm#6.1.1250 does not really explain what DOES> does.
09:32:18 <koisoke> comma takes from the stack and puts the value at HERE and advances HERE
09:34:47 <koisoke> default behavior of a CREATEd word is to put the pointer to the start of its data on the stack
09:35:25 <koisoke> and does> appends to that behavior
09:36:22 <tangentstorm> hrm
09:37:08 <tangentstorm> so create happens when xorwith> is called.
09:38:23 <tangentstorm> create reads the name and creates a new entry.
09:39:15 <tangentstorm> so when you say   25 xorwith> xor25    it creates a new entry called xor25, then the comma writes the 25
09:39:29 <tangentstorm> as if you'd typed   : xor25 25 
09:40:38 <C-Keen> are you explaining how does works or are you figuring it out for yourself aloud?
09:40:49 <tangentstorm> back at compile time, the address of xor25 is on the stack.
09:40:52 <tangentstorm> the latter
09:40:54 <tangentstorm> i'm asking :)
09:41:10 <tangentstorm> or at least stating what i think in hopes someone will confirm or deny :)
09:41:36 <C-Keen> comma puts whaterver's on the stack in the parameter field, does> modifies the code field
09:41:42 <Vuokko> so far I believe tangentstorm is right. atleast it seems reasonable
09:42:54 <koisoke> create parses a name and creates a word with that name that returns the HERE after the word is created. , takes a word from the stack, writes it at HERE and advances HERE
09:42:56 <C-Keen> mpe's ProgramForth has an explanation of it, so does Starting Forth
09:43:03 <C-Keen> (page 313)
09:43:23 <koisoke> does> appends code to the definition of the word you made with create
09:43:24 <tangentstorm> does> must do somthing that pushes the adddress of the data field onto the stack then, so that the @ can read from it.
09:44:20 <tangentstorm> oh i see.
09:44:23 <koisoke> tangentsotrm: create by itself does that
09:44:45 <tangentstorm> got it.
09:45:04 <tangentstorm> DOES> is modifying xorwith> , not xor25
09:46:23 <tangentstorm> no...
09:47:52 <koisoke> no. look at that dpans page again.
09:53:14 <tangentstorm> i've re-read it a few times. i think i need to draw it out. :)
09:53:32 <Vuokko> please share that diagram with us
09:54:40 <tangentstorm> it's saying: Run-time: ( -- ) ( R: nest-sys1 -- )
09:55:10 <tangentstorm> this behavior is appended to xorwith>
09:56:14 <tangentstorm> which means that when you say   xorwith> it's going to run the code but it won't return to the OK prompt like it normally would.
09:56:55 <tangentstorm> step 2 at compile time is Initiation: ( i*x -- i*x a-addr ) ( R:  -- nest-sys2 )
09:57:01 <koisoke> it's like:
09:57:16 <koisoke> : foo does> @ 2 * . ;
09:57:16 <koisoke> create bar 42 ,
09:57:17 <koisoke> bar .s
09:57:17 <koisoke> foo
09:57:19 <koisoke> bar
09:57:21 <koisoke> er
09:57:24 <koisoke> mispaste
09:57:28 <koisoke> : foo does> @ 2 * . ;  ok ok
09:57:28 <koisoke> create bar 42 ,  ok ok
09:57:28 <koisoke> bar .s <1> 139943570015136  ok
09:57:28 <koisoke> foo  ok
09:57:31 <koisoke> bar 84  ok
09:57:33 <koisoke> @ . 42  ok
09:58:36 <koisoke> create  bar 42 , by itself creates a word with a pointer to a data field whose first word is 42, then i run foo, which appends @ 2 * . to that definition, so when i call bar again it has that behavior
09:58:59 <tangentstorm> yeah
09:59:01 <tangentstorm> i'm with you
10:00:52 <koisoke> does> isn't modifying foo, it's modifying the most recent definition (which must have come from create) when foo executes
10:06:15 <tangentstorm> it is modifying foo though
10:06:24 <koisoke> how
10:06:39 <tangentstorm> let's use an example
10:07:17 <tangentstorm> well the xor one works
10:08:09 <tangentstorm> modifying is a loaded word. it's appending something to the definition.
10:09:00 <koisoke> it's not appending anything to the definition of xorwith>
10:09:08 <tangentstorm> it has to
10:09:13 <koisoke> why
10:09:42 <tangentstorm> because otherwise you could just remove it from the definition of xorwith>  and it would work the same.
10:10:18 <Vuokko> does> adds the words after it to the newly defined word 
10:10:54 <koisoke> tangentstorm: it's part of the definition of xorwith> but it doesn't append anything to xorwith> after it is defined
10:11:01 <tangentstorm> it must
10:11:06 <Vuokko> why?
10:11:36 <tangentstorm> here's the definition that koisoke made:   : xorwith> create , does> @ xor ;
10:11:53 <tangentstorm> where is the "@ xor ;" stored?
10:12:04 <tangentstorm> surely it's stored in the definition of xorwith>
10:12:10 <Vuokko> yes.
10:12:22 <tangentstorm> so then why  doesn't it execute immediately?
10:12:33 <tangentstorm> because does> added something to make it not execute immediately.
10:13:23 <tangentstorm> like
10:14:10 <tangentstorm> you type   xorwith>   and at runtime it's going to run "create , " ... but then the next thing it runs is not "does>"
10:14:20 <koisoke> it has compilation semantics that are not the default ones, but that is not the same as appending something to a definition
10:16:39 <koisoke> actually it wouldn't even have to, because does> could be implemented as a word which stores a pointer in the most recent definition and then returns from the word
10:17:46 <koisoke> i don't think gforth does it that way, but one could. and then the stuff after does> would be compiled into the word definition like anything else, it just wouldn't get executed because the word would return before that
10:18:27 <tangentstorm> but how does it know what pointer to compile?
10:18:48 <tangentstorm> it still has to store the appropriate pointer in the definition of xorwith>
10:18:59 <tangentstorm> the pointer is to the code immediately following it.
10:19:16 <tangentstorm> so you definie xor25
10:19:22 --- join: _spt_ (~steven@host-92-12-216-57.as43234.net) joined #forth
10:19:22 --- quit: _spt_ (Changing host)
10:19:22 --- join: _spt_ (~steven@unaffiliated/-spt-/x-5624824) joined #forth
10:19:30 <koisoke> it could look at the program counter (but again, i'm not sure gforth does it that way)
10:19:59 <tangentstorm> ok fair enough.
10:20:23 <tangentstorm> so at the very least then it compiles a call to "do-runtime-does>" stuff and appends that to xorwith>
10:20:35 <tangentstorm> "do-runtime-does>-stuff"
10:22:24 <tangentstorm> i'm just saying something has to be laid down in the compiler to prevent '@ xor ;' from running immediately.
10:23:12 <tangentstorm> it could very well just put that code somewhere else but the simplest thing would be to just append something to the current definition
10:23:47 <koisoke> again. having compilation semantics that are different than the usual ones is not the same as appending to an existing definition, but again one would not need to do anything special for the compilation (though i think gforth does)
10:24:10 <tangentstorm> i don't understand why not.
10:24:24 <tangentstorm> can you give me an example?
10:24:31 <koisoke> of what?
10:25:23 <tangentstorm> of how you could implement DOES> without appending code to the current definition.
10:25:29 <koisoke> not executing stuff that comes after a word with no special behavior on compilation? sure:
10:28:10 <Vuokko> does> could have runtime semantics to append newest word jump to its own payload address and exit and compilation semantics to just compile other words after itself to the definition
10:32:03 <tangentstorm> Vuokko: you mean DOES> would modify the entry for DOES> to do something else at runtime? 
10:32:19 <tangentstorm> that's plausible.
10:32:21 <koisoke> as vuokko said (having trouble coming up with an example that works in gforth, since i do not normally use it)
10:33:26 <tangentstorm> Okay, it could then just be compiled normally.
10:33:57 <tangentstorm> It would have to create a new entry for DOES> though.
10:34:05 <tangentstorm> otherwise you could only use it once.
10:34:37 <koisoke> new entry?
10:35:09 <tangentstorm> if i understand what Vuokko is saying, DOES> modifies its own dictionary entry to do something at runtime.
10:35:26 <tangentstorm> i mean he's saying it could do that hypothetically.
10:35:39 <tangentstorm> and then it would not have to append code to the current definition.
10:35:48 <tangentstorm> it would just be compiled normally.
10:36:01 <tangentstorm> did i understand you correctly, Vuokko ?
10:36:03 <C-Keen> that's not what happens
10:36:30 <koisoke> no. the only entry it modifies is the latest one you CREATEd and are appending to
10:36:33 <tangentstorm> yes of course it's not what happens. what happens is it appends code to the definition, like it says in the spec :) but we're being hypothetical.
10:37:13 <tangentstorm> koisoke: how does it know the right way to modify the new word though?
10:38:05 * tangentstorm goes and looks up the actual definition in gforth.
10:38:07 <koisoke> because it knows the internals of the forth implemention and how to find the newest word in the dictionary
10:38:25 <tangentstorm> yeah, finding the new word is easy.
10:38:30 <tangentstorm> what does it do with the new word?
10:39:07 <koisoke> it puts writes in a jump to the stuff that comes after does>
10:41:51 <koisoke> so if it knows how to read the program counter and find the newest word, and what the internals of the word are, there is no need for any special compilation magic for does>
10:43:08 <tangentstorm> ok, i think i see it now.
10:43:25 <koisoke> actually it wouldn't need the program counter if it is being called like any other word and not inlined
10:43:40 <koisoke> since the value on the top of the return stack would point to the stuff it appends to the new word
10:44:03 <koisoke> and the value under that is the value does> should return to when it is done
10:44:17 <tangentstorm> : does> r> 1+ , ;
10:45:45 <koisoke> : does> r> (find where to put it) ! ; or something like that
10:47:55 <tangentstorm> oh because the thing you're CREATE-ing might not be code.
10:48:45 <koisoke> ?!
10:49:01 <tangentstorm> you might CREATE an array or whatever.
10:49:16 <tangentstorm> the definition might contain data rather than code.
10:49:34 <tangentstorm> if it contains code then my definition of does would work fine.
10:49:37 <koisoke> no.
10:51:04 <tangentstorm> not sure i need the 1+
10:52:12 <tangentstorm> yeah, that's wrong.     : does> r> , ;    would work for code, at least in retro. (although you'd write it    : does> pop , ;
10:53:26 <tangentstorm> your version solves the general case though.
10:55:27 <koisoke> you don't but that is not what is wrong with it. create by itself creates a word whose semantics are defined by create. create foo by itselfwill create a complete word and  , after that cannot possibly append code
10:56:18 <tangentstorm> doesn't , append to the last definition?
10:56:24 <tangentstorm> (it does in retro)
10:56:35 <koisoke> , appends data at HERE
10:56:40 <tangentstorm> sure
10:57:00 <tangentstorm> which will be pointing to the last part of the last definition.
10:57:12 <tangentstorm> the last cell of the last definition
10:57:29 <koisoke> right, but the last definition is already a complete definition that does something and returns, so your code will be unreachable
10:57:36 <tangentstorm> again, that's how the dictionary is laid out in retro. it depends on your dictionary format.
10:57:44 <tangentstorm> no it's not.
10:57:47 <Vuokko> what went wrong in my comments? : xorwith> ( d "name" -- ) create ( d addr ) , ( d  does> wants addr ) does> @ xor ; 
10:58:32 <Vuokko> I believe we're on the same problem now
10:58:33 <tangentstorm> nothing has told it to compile a return instruction yet, koisoke 
10:59:00 <koisoke> i last played with retro in 2001 or something like that, but that does not sound right at all, unless you are still compiling
10:59:09 <koisoke> tangentstorm: create compiles a return instruction
10:59:38 <tangentstorm> huh
10:59:45 <tangentstorm> it doesn't in retro. weird.
11:00:09 <koisoke> so if you just say create foo foo it will just start executing garbage on the heap?
11:00:17 <tangentstorm> sure
11:00:30 <tangentstorm> hrm
11:00:36 <tangentstorm> it does not.
11:01:02 <koisoke> it returns a pointer, yes?
11:02:58 <tangentstorm> aaaaaaaexit
11:03:33 <tangentstorm> sorry
11:03:38 <tangentstorm> no i was right. 
11:04:27 <tangentstorm> CREATE just creates a dictionary entry, but i think by default it's marked as data so it just returns its address.
11:04:55 <koisoke> i hope one would be forgiven for thinking you were talking about an ans compliant forth when you refered to dpans
11:05:19 <tangentstorm> but if you type   create foo see foo  in retro it'll count from HERE to 1000000000 or whatever the size of your ram is, showing nops.
11:05:39 <koisoke> hang on, fetching retro
11:05:56 <tangentstorm> retro doesn't has create but not DOES>
11:05:58 <tangentstorm> er
11:06:02 <tangentstorm> man i suck today.
11:06:09 <tangentstorm> retro has create but it doesn't have does>
11:06:34 <tangentstorm> so i've never used it and i was looking at the ansi stuff to see how real forth does it. :)
11:06:57 <koisoke> does retro have something like see
11:07:08 <tangentstorm> yeah
11:07:18 <koisoke> ?
11:07:19 <tangentstorm> like i said   create foo see foo    but be ready to kill that process.
11:07:47 <koisoke> it doesn't seem to be defined
11:09:00 <tangentstorm> i have it in my image. let me see where i got it.
11:11:11 <tangentstorm> it's in library/help.rx but something is screwy in the latest version i have and i'm unable to import it.
11:11:51 <tangentstorm> hrm. just my working copy
11:11:59 <tangentstorm> needs help' with help' should get you "see"
11:12:00 <koisoke> does retro actually tag things as data vs code? seems highly unusual for a forth
11:12:08 <tangentstorm> but it's buggy. :(
11:12:14 <tangentstorm> it has a "class" concept.
11:12:31 <tangentstorm> argh.. sorry.. i have to go though.
11:12:33 <tangentstorm> bbl
11:12:47 <tangentstorm> (i think autopsy.rx has a better implementation of see)
11:29:15 --- quit: sirdancealo2 (Ping timeout: 240 seconds)
12:41:16 --- join: tommytom3 (~tommytom@joole.fr) joined #forth
12:42:38 <tommytom3> Hello, I couldn't find how to display the content of the dictionnary
12:42:43 <C-Keen> words
12:43:14 <tommytom3> And with definitions ?
12:43:24 <tommytom3> Uncompiled ? maybe
12:43:38 <C-Keen> see 
12:44:15 <tommytom3> Awesome, thank you
12:45:57 <C-Keen> np :)
13:02:22 --- join: sirdancealo2 (~sirdancea@98.82.broadband5.iol.cz) joined #forth
13:13:15 --- quit: sirdancealo2 (Ping timeout: 240 seconds)
13:38:40 --- quit: true-grue (Read error: Connection reset by peer)
13:51:40 --- join: epicmonkey (~epicmonke@188.134.41.114) joined #forth
14:07:06 --- join: sirdancealot (~sirdancea@98.82.broadband5.iol.cz) joined #forth
15:09:43 --- quit: ncv (Remote host closed the connection)
15:13:17 --- quit: epicmonkey (Ping timeout: 245 seconds)
15:20:57 --- quit: dys (Ping timeout: 264 seconds)
15:24:21 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth
15:33:33 --- quit: dys (Ping timeout: 264 seconds)
15:36:41 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth
15:40:12 --- quit: dys (Remote host closed the connection)
16:12:13 --- quit: _spt_ (Quit: bye)
16:31:11 --- join: Nisstyre-laptop (~yours@oftn/member/Nisstyre) joined #forth
17:45:50 --- quit: Eth|cal (Ping timeout: 264 seconds)
17:53:07 --- join: Eth|cal (~sam@ppp59-167-172-238.static.internode.on.net) joined #forth
18:08:51 --- quit: Eth|cal (Quit: Leaving)
18:14:21 --- join: Eth|cal (~sam@ppp59-167-172-238.static.internode.on.net) joined #forth
18:14:32 --- quit: Eth|cal (Read error: Connection reset by peer)
18:14:55 --- join: Eth|cal (~sam@ppp59-167-172-238.static.internode.on.net) joined #forth
18:22:01 --- quit: sirdancealot (Read error: No route to host)
18:23:11 --- quit: Nisstyre (Quit: Leaving)
18:47:14 --- quit: Kumul (Ping timeout: 256 seconds)
18:51:07 --- join: karswell` (~user@31.1.125.91.dyn.plus.net) joined #forth
18:52:07 --- quit: karswell (Ping timeout: 264 seconds)
19:25:39 --- join: Kumul (~nmz@adsl-64-237-237-200.prtc.net) joined #forth
19:27:33 --- nick: Nisstyre-laptop -> Nisstyre
20:38:41 --- quit: tangentstorm (Quit: WeeChat 0.3.2)
20:56:30 --- join: true-grue (~quassel@95-24-23-156.broadband.corbina.ru) joined #forth
21:00:00 --- quit: Nisstyre (Quit: Leaving)
21:04:43 --- quit: djinni (Ping timeout: 264 seconds)
21:18:08 --- join: djinni (~djinni@li125-242.members.linode.com) joined #forth
21:20:09 --- join: Bahman (~Bahman@2.146.63.173) joined #forth
21:29:32 --- quit: djinni (Ping timeout: 245 seconds)
21:37:39 --- join: djinni (~djinni@li125-242.members.linode.com) joined #forth
22:20:56 --- quit: Kumul (Quit: Divided by 0)
23:24:21 --- join: Bahman1 (~Bahman@2.146.236.114) joined #forth
23:26:05 --- quit: Bahman (Ping timeout: 264 seconds)
23:33:52 --- join: dys (~user@2a01:1e8:e100:8296:21a:4dff:fe4e:273a) joined #forth
23:59:59 --- log: ended forth/13.08.04