00:00:00 --- log: started forth/01.10.04 01:12:04 --- quit: Speuler (Ping timeout for Speuler[c38038.upc-c.chello.nl]) 02:14:52 --- join: Speuler (l@c38038.upc-c.chello.nl) joined #forth 02:24:03 --- join: swapdrop (swapdrop@c38038.upc-c.chello.nl) joined #forth 02:25:00 Bongo wants to be opped 02:26:00 Bongo wants to be opped 02:27:00 Bongo wants to be opped 02:27:43 --- quit: Fare (Ping timeout for Fare[samaris.tunes.org]) 02:27:43 Bongo wants to be opped 02:28:00 Bongo wants to be opped 02:29:00 Bongo wants to be opped 02:29:19 --- join: Fare (Fare.LISPM@samaris.tunes.org) joined #forth 02:31:56 --- quit: Speuler (Ping timeout for Speuler[c38038.upc-c.chello.nl]) 02:32:06 --- quit: swapdrop (Ping timeout for swapdrop[c38038.upc-c.chello.nl]) 02:34:20 --- join: Speuler (l@c38038.upc-c.chello.nl) joined #forth 06:55:00 --- nick: Speuler -> GrubPecker 07:25:12 --- join: edrx (edrx@copacabana-ttyS24.inx.com.br) joined #forth 07:25:36 hi GrubPecker 07:25:59 are you trying to add a Forth to Grub, by any chance? :) 07:43:14 --- quit: edrx ([x]chat) 10:45:58 --- quit: cqx (zelazny.openprojects.net farmer.openprojects.net) 10:46:18 --- join: cqx (cqx@m206-182.dsl.tsoft.com) joined #forth 11:25:21 --- join: edrx (edrx@200.240.18.101) joined #forth 11:25:47 --- quit: edrx ([x]chat) 11:54:10 --- nick: GrubPecker -> Speuler 14:36:16 --- join: MrReach (mrreach@209.181.43.190) joined #forth 14:36:19 --- join: futhin (thin@24.66.209.114) joined #forth 14:36:25 hiya, futhin 14:36:28 heya 14:36:45 hey guys, some REALLLY ugly ugly ugly code of mine 14:36:49 : filid dup create fileid ; 14:36:49 : openfile s" d:\essentials\inwork\forth\work\code\eggdrop\eggdrop.log" r/o open-file abort" open-file failed" filid ; 14:36:49 : makefilebuffer 14:36:49 file-size throw drop dup constant filesize 14:36:52 4 + allocate throw dup constant addr 14:36:53 filesize fileid read-file throw ; 14:36:55 : filetomem openfile makefilebuffer ; 14:36:56 what system are you running? What are you trying to accomplish, and what is your question? 14:36:57 : main filetomem testloop ; 14:37:22 i'm using win32forth.. my main problem is opening a file and putting it into memory 14:37:30 the way that i'm doing it is a bit ugly.. 14:37:54 for some reason, it wouldn't let me use "CREATE" it kept complaining about "invalid NAME" even though i was using a name.. 14:39:11 ugh 14:39:13 um 14:39:16 what is the word "filid" supposed to do? 14:39:29 i was hacking it up 14:39:35 let me redo the code a little bit 14:39:42 I would suggest ... 14:40:03 it was complaining about stuff.. so filid was a hack.. to try to get around the complaint 14:40:12 : slurp ( a-str u-cnt -- a-contents ) 14:40:36 : makefilebuffer file-size throw drop 4+ allocate throw ; 14:40:36 : openfile s" d:\essentials\inwork\forth\work\code\eggdrop\eggdrop.log" r/o open-file abort" open-file failed" filid ; 14:40:36 : filetomem openfile makefilebuffer ; 14:40:53 give slurp the address of a filename, and it returns a pointer to the contents of that file (not forget to FREE it later) 14:41:08 i'm trying to put the file into memory.. 14:41:18 i tried to do something like... 14:41:21 yes, I understand that 14:41:33 er 14:41:37 somebody told me to do it like this: 14:41:38 : makefilebuffer file-size throw drop 4+ allocate throw create , @ does> ; 14:42:16 if need a word in the dict for the pointer 14:42:31 personally, I'd use slurp and stuff the resulting address in a VALUE 14:43:03 heh, the funny part is that I'm quite sure Win32Forth has a word that does exactly what you need 14:43:18 mrreach: i want to run my code on linux later.. 14:43:25 so i want to keep it portable or ansi 14:44:29 mrreach: in win32forth, "allocate throw create somenameofmine" doesn't work.. why? :( 14:44:29 nope, apparently it isn't 14:44:46 did you put a size of the stack? 14:44:54 eh? 14:45:03 "allocate" needs a size 14:45:22 yeah, the filesize is on there 14:45:28 i'm just showing a snippet 14:45:32 of the makefilebuffer.. 14:45:35 word 14:45:43 4000 allocate throw create somenameofmine ok. 14:45:43 . -1013144 ok 14:45:54 works great on my win32 14:46:33 see somenameofmine 14:46:33 247740 VARIABLE SOMENAMEOFMINE Value = 0 ok 14:47:13 it works fine in the interpreter.. but when it's inside the word it doesn't work 14:47:23 : makefilebuffer file-size throw drop 4+ allocate throw create somenameofmine ; 14:47:47 and how are you using "makefilebuffer"? 14:48:22 don't forget that CREATE will parse the input stream at runtime, not at compile time 14:48:31 look, i just put this into win32forth 14:48:32 : makefilebuffer file-size throw drop 4 + allocate throw create somenameofmine ; 14:48:32 Error: somenameofmine is undefined 14:48:34 there's you're error 14:48:47 hmm 14:48:49 heh 14:49:03 what does "create , does>" do? 14:49:09 when makefilebuffer is executed, it calls CREATE which ten parse a name from input stream 14:49:17 hmm 14:49:19 what do i do then? 14:49:23 ok, DOES> 14:49:24 if i can't use create? 14:49:39 why not use slurp type construct? 14:51:11 why get fancy? 14:51:27 is there some functionality that you need that I'm missing? 14:53:09 hmm 14:53:27 i just need to be able to put the address of the begining of the file in memory onto stack 14:55:10 what does slurp do? 14:56:02 given a filename 14:56:13 it returns the address of the entire file in memory 14:56:22 just a sec, writing the def now 14:58:15 somebody on here gave me this. : makefilebuffer file-size throw drop 4+ allocate throw create , @ does> ; so i'm wondering what "create , @ does>" is and if it's supposed to work? 14:58:53 it backwards 14:59:08 more like "create , does> @" 14:59:37 ermm ... I just realized ... 14:59:56 slurp also needs to return the SIZE of the data read from the file 15:00:11 so instead of what I typed above, it would be ... 15:00:31 : slurp ( a-str u-cnt -- a-contents u-len ) 15:02:04 what does create , does> @ do ? :) 15:03:05 ok 15:03:17 CREATE adds a new word to the dictionary 15:03:37 normally, when that word is executed it returns an address in data space 15:04:02 in this def, it takes whatever is TOS and commas it into that space 15:04:21 and then changes the behavior of the resulting word 15:04:38 such that instead of returning the address of whatever was comma'd 15:04:51 it actually returns the value that was TOS 15:05:08 I'm sure sure I was a clear as I might be 15:05:15 not sure, rather 15:07:54 --- join: qless (qless@clgr000977.hs.telusplanet.net) joined #forth 15:08:14 --- quit: Speuler (Read error to Speuler[c38038.upc-c.chello.nl]: EOF from client) 15:09:20 hello? 15:09:34 want to see an ANS definition of slurp? 15:09:44 go for it 15:10:01 \ read an entire file into memory, return address 15:10:01 : slurp ( a-str u-len -- a-data ) 15:10:01 R/O BIN OPEN-FILE THROW ( fid ) 15:10:13 DUP FILE-SIZE THROW DROP ( fid size ) 15:10:13 \ WARNING: will break if larger than 32 gigs in size 15:10:13 DUP ALLOCATE THROW ( fid size adr ) 15:10:22 DUP >R ROT DUP >R ( size adr fid R: adr fid ) 15:10:23 >R SWAP R> ( adr size fid R: adr fid ) 15:10:23 READ-FILE THROW ( bufsize R: adr fid ) 15:10:30 R> CLOSE-FILE THROW ( bufsize R: adr ) 15:10:30 R> SWAP ( adr size ) ; 15:10:42 ( WARNING: untested code ) 15:11:01 hmmm 15:11:12 OOOPS! 15:11:27 initial stack comment is wrong, should be ... 15:11:37 : slurp ( a-str u-len -- a-data u-len ) 15:12:11 nifty 15:12:46 guess what I call the word that writes out all the data after it has been processed? 15:13:17 alldata>? 15:13:34 SPEW 15:13:41 :-) 15:13:47 orthagonal to SLURP 15:14:08 kinda like gozinta and comezatta in unix? 15:14:29 have no idea what those words mean @:^> 15:14:38 > < 15:15:00 ah! yes, quite similar 15:15:17 cool 15:15:21 --- join: Speuler (l@c38038.upc-c.chello.nl) joined #forth 15:15:36 so many people spend a lot of time fussing with parsing a file line-by-line to save memory 15:16:05 any type of recent OS can read any of the disk files and hold in memory 15:16:20 my keyboard just run out of battery :( 15:16:20 so just slurp the thing and quit worrying about it 15:16:25 HAHA! 15:16:54 well, I can imagine that a huge database could exceed memory and swap 15:17:01 hey, got a diff question 15:17:07 greetings, Speuler 15:17:10 shoot 15:17:38 is there some sort of loop running in the background of forth.. like i thought i heard there was some kind of loop involving the interpreter and NEXT or something 15:17:44 or maybe NEST? 15:17:56 round robin tasker ? 15:18:00 not in the interpreter, no, not really 15:18:22 mrreach: no.. the interpreter is _part_ of a loop i think.. 15:18:29 QUIT usually has a loop that includes REFILL and INTERPRET 15:18:45 INTERPRET is not ANS, note 15:19:25 in Win32Forth, there *IS* a background loop, and it handles messages from the user interface 15:19:31 mouse clicks and whatnot 15:20:17 futhin: the loop you're thinking of is NOT a background loop, rather it is a containing loop ... understand the difference? 15:20:32 umm.. i wanted to code a MUD in forth.. and i thought there was some loop in forth, so i could modify interpret so that it acts more like a mud interface.. 15:20:53 that would be good 15:21:18 IMO, better would be to write a new loop, possibly based on the source of the current interpreter 15:21:24 is there any loop in forth that i can take advantage of? 15:21:46 hmm 15:21:58 i need to be able to handle multiple users.. 15:22:19 you would want to be very VERY careful that MUD users an not access the entire dictionary 15:22:35 can not access 15:22:36 that's what the modified interpreter would be for :) 15:22:50 or maybe i can create a new vocab and only allow access to that vocab? 15:23:10 in the source of the MUD, create a vocabulary specifically for the MUD users 15:23:25 those are the ONLY words they are allowed to access 15:23:39 yeah.. ok 15:23:44 also, I would suggest ... 15:24:02 spawning a thread to handle each user, for stack protection 15:24:11 hmmm 15:24:24 it's only a matter of time before a user causes a stack underflow 15:24:37 and you wouldn't want that to crash the entire system 15:24:40 the modified interpreter would discard any numbers the users type in.. only words in the mud vocabulary are accessed 15:25:03 well, they'll undoubtedly need to enter numbers sooner or later 15:25:30 and letting them have the compiler allows them great versatility in writing macros 15:25:44 is this a text mud or graphical one? 15:25:57 eh? they shouldn't need to enter any numbers.. hmm.. 15:26:21 text mud.. maybe i'll make it graphical later on (shouldn't be too hard to upgrade the text one into a graphical one ;) 15:26:47 erm ... might want to give some thought as to structure, then 15:27:07 i'll worry about the text mud first.. the graphical is a lot more complex :) 15:27:11 and i'm still a newbie forth coder 15:27:27 you should _probably_ parse out commands manually, if it's a text interface 15:27:38 what do you mean? 15:27:45 otherwise, the users will get confused by RPN notation 15:28:01 imagine IRC client working like ... 15:28:05 oh yeah.. i'll do some BNF thingie 15:28:08 or whatever 15:28:08 "some text" say 15:28:18 like the CREATE..DOES> would do the trick right? 15:28:23 or "farts" action 15:28:36 do the trick for what? parsing? 15:28:50 hmmmm ... 15:29:31 show me a couple of examples of what a MUD user might type, please 15:30:12 they might type: " hi 15:30:21 or they might type: help stats 15:32:11 ok, do you think that most of what the user does will be talking? 15:32:33 or do you think there will be large amounts of commands interspersed witht he text? 15:33:19 eh.. well there's going to be a bunch of other commands that they are going to be using 15:33:32 probably a fair amount of commands that need parameters 15:33:41 yes, but mostly talking? 15:33:43 so i need something thats non-RPN i suppose 15:33:49 the reason I ask ... 15:34:04 is that you might want to give it an IRC like interface 15:34:22 where whatever is typed goes as saying something 15:34:30 unless prefixed by a command character 15:34:32 hmm.. naw.. it's not that much talking 15:34:51 there's going to be lots of commands 15:34:56 like for killing other players, et 15:34:58 etc 15:35:02 buying food 15:35:06 eating the food 15:35:11 dealing with equipment 15:35:14 mIRC has lots of commands, too, but 98% of all my typing is to the channel 15:35:22 yeah 15:35:35 but the mud is more of a rpg 15:35:38 ok, I see how you're setting up 15:35:39 not a talker mud 15:36:03 in that case, REFILL ... PARSE ... SEARCH-WORDLIST 15:36:17 don't even mess with a vocabulary 15:36:44 and don't even let them at the interpreter loop 15:36:46 eh?! 15:36:57 hmm 15:37:10 create a wordlist 15:37:15 i want to let some trusted people to log onto the mud online and do some coding.. 15:37:19 add to it all the things a user can do 15:37:47 when a user types a command, parse it from the input stream 15:37:54 search the wordlist 15:38:02 if found, execute the definition for it 15:38:29 otherwise send back, "Huh? If you can't type, maybe you shouldn't be MUDing." 15:38:42 hmm.. what about parameters? 15:38:57 like if a user types: help stats 15:39:12 like if a user types: help eat 15:40:08 : help parse s" stats" compare if help_stats else send_help_help then ; 15:40:43 "eat bananas" 15:41:26 parse is a word that i have to define right? :) 15:41:42 : eat parse 2dup isfood? if get-calories add-calories else type ." is not something you eat, you moron." then ; 15:41:49 no, it's ANS 15:42:11 for finding tokens in the input stream 15:42:36 let's sort of back up a bit.. 15:43:04 sure 15:44:31 this is something i said to somebody earlier 15:44:33 well the classic forth implementation apparently has some simplistic loop running in the background that's basically "interpreter-compiler-etc-etc-other-forth-stuff" so all i have to do is modify the interpreter or replace it with a "mud interface" that basically only accepts commands (already compiled words). then i just throw in some tcp/ip stuff into that loop and viola, we have a mud. we can immediately start coding look, north, south, etc 15:44:49 WORD would prob be better 15:45:21 yes, if you want reverse polish 15:45:42 heh 15:45:42 yeah 15:45:55 you would be writing something very like the forth interpreter 15:46:05 but there's lots of stuff you want to cut out 15:47:35 hm 15:48:30 what's the word for spawning new threads? 15:48:49 also, your users will appreciate prefix notation much more than postfix 15:49:12 in Win32Forth? 15:49:49 use the windows call directly, use the forth word Callback: to build the top-level definition 15:50:09 i think it would be best to run my mud in linux/openbsd 15:50:15 and watch your ass regarding shared memory areas 15:50:22 yes, it would 15:50:30 ok 15:51:00 if you don't give users access to the interepter, there's no need for seperate threads 15:51:08 ah ok 15:51:43 in fact, one of your commands could totally crash and reboot the system w/o the user knowing 15:51:45 so how do i deal with multiple people? how do they type the stuff and get the text? 15:52:27 ok, you should be using an event driven paradigm 15:52:38 which can be simulated with KEY? 15:53:36 loop through all open network sockets, if keystroke is available, add it to buffer for that user, if it is a CR, invoke the command parser 15:53:59 hmmm ... no, wrong ... 15:54:05 you know so much :P 15:54:33 loop through all open network sockets, if keystroke is available, fetch it, if it is not a CR add it to buffer for that user, otherwise invoke the command parser 15:54:51 i'm going to have to reread the log to make sure i get everything.. bah :) 15:55:51 in both unix and windows there are ways to wait on many many file descriptors to become ready for reading or writing 15:56:02 but using those methods is a real pain with Forth 15:56:18 eh?! 15:56:25 you will HAVE to when your system starts to get busy 15:56:27 what do i need to wait on file descriptors for? 15:56:44 because you don't want to waste time polling all of them 15:57:12 polling what? 15:57:16 polling files? 15:57:22 simply tell the OS "start me up again when some arrives on one of these 500 sockets" 15:57:52 sockets and files look almost identical on both windows and unix 15:58:08 hmm 15:58:43 they ARE identical on BSD ... because it was designed specifically with that in mind 15:59:22 sockets have somewhat different control functions, though 16:00:04 incidently, that will make it incredibly easy to both test and benchmark your MUD 16:00:31 because it takes little effort to make a disk file look like a user on a socket 16:01:28 do you expect this MUD to run on many machines? or just yours? 16:01:57 gah.. we're kinda going a bit fast, i'm having trouble visualising the structure of the mud in forth.. i suppose i've got a loop somewhere and blahblahblah :) 16:02:07 heh 16:02:14 i'm not quite sure where to start :) 16:02:41 the MUD running on many machines in a distributed manner?? 16:02:56 could i put that functionality in later? or would it be better sooner? 16:03:07 i was mostly thinking of one machine 16:03:41 no, I meant ... 16:04:02 several MUDs using your software, unaware of each other 16:04:46 ah.. i haven't really decided that yet.. i probably would make my code opensource and let other people hack it up.. it would help get more people interested in forth too i hope :) 16:05:04 yes, it would me 16:05:28 but I'm much more interested in a user-built graphical virtual reality 16:06:09 how many, at the most, could you envision logging onto your system at once? 16:06:32 say, 5 years from now? 16:07:09 well, it'd be really cool if about 200 to 500 people were logged on at any one time :) 16:07:19 i'd like that.. a nice big mud 16:07:24 good for variety :) 16:07:35 ok, Linux will handle that, Winblows PROBABLY will 16:07:47 heh 16:07:53 well i'm doing it for linux though 16:08:09 when I owned TerraComm ... we did a little research 16:08:12 although i might want it to run on windows too.. create two versions or something 16:08:41 Linux was immeasurably fast in handling sockets, but was limited in the kernel to 1,000 sockets per process 16:09:24 we never got to find out how many sockets windows could handle, because the machine completely stalled at 125 sockets 16:09:40 heheh 16:09:57 when you say socket, you mean port connection? 16:10:01 I sould repeat that test with TCL ... it would be quick and simple now 16:10:01 i only need one port 16:10:22 yes, but each user telneting in get its own socket connection 16:10:40 hmm.. windows only handles 125??? weird 16:11:05 when the connection is made, the OS assigns a (pseudo random) port number to the local end 16:11:50 port numbers range from 1-65535 ... and the lowest 1024 are usually reserved 16:12:22 so a MACHINE can only handle roughly 60,000 simultaneous connects (theoretically) 16:12:42 that is a limitation imposed by IPV4 16:14:08 there may have been an inaccurate test on the windows machine ... we were explaining to our chef coder why windows was forbidden from running server tasks at Terracomm 16:14:18 chief coder 16:14:27 chef coder sounds cooler ;P 16:14:28 he was a windows guy 16:14:52 we had lots of windows machines for workstations, but one server, and it was Linux 16:15:23 no other machine was allowed to hand out data, EVER 16:15:39 any machine would retrieve data, though 16:16:22 yeah 16:16:58 anyway, he couldn't get windows to handle lots of incoming sockets, no matter how he tried 16:17:20 i'm also interested in a user-built graphical virtual reality kind of system.. or something graphical anyways 16:17:31 so the case was made for linux, and we had to go hire a unix coder 16:17:36 i have some ideas, but first i gotta implement a text mud 16:17:45 no you don't 16:17:59 in fact, you'd be shooting yourself in the foot 16:18:14 i'd start from scratch on the graphical one 16:18:23 different animal altogether 16:18:24 i just need to become a better forth programmer first 16:18:30 ah! ok 16:18:37 that makes good sense 16:18:53 not really though.. i could implement ansi graphics and change the room descriptions into weird maps :) 16:19:17 that assumes the terminal uses ansi 16:19:36 yeah well, everyone is gonna hafta use ansi if they wanted to connect to that graphical mud :) 16:19:39 not a safe assumption, as many people still use the old-fashioned telnet for MUDing 16:19:51 not ANSI 16:19:59 use a rendering engine 16:20:14 and a specific MUD protocol 16:20:20 the old fashioned telnet supports ansi i think? there's color..? 16:20:41 not the ones that come out of the box on my Unices 16:20:51 the fancy ones do 16:21:02 and all my windows ones do, of course 16:21:30 I would suggest investigating OpenGL for a rendering engine 16:21:39 use a rendering engine? you creating a client for the users?? 16:22:05 yes, a user-bult VR environment 16:22:05 er 16:22:11 you mean creating a client for the users 16:22:18 yes, I do 16:22:32 the server would simply be a data-shuffling device 16:22:32 but then i'd have to worry about creating the client for linux and windows..? 16:22:54 you *CAN* with OpenGL ... it run on both platforms 16:23:08 opengl in forth? 16:23:27 it would be simple library calls, like any other 16:23:31 hmm, ok 16:25:18 there are a couple of more challenging issues, though 16:25:40 one is changing to a completely event driven paradigm 16:25:59 the other would be incorporating an object-orientation system of some type 16:26:50 especially in the server 16:28:01 oh! btw ... I wouldn't let ANYONE write forth code on the public server ... not even yourself or other opers 16:28:20 a virtual reality thingie would be pretty complex.. much easier to go with a simple graphical mud :) 16:28:36 mrreach: are you talking about the text-mud or what? 16:28:36 I don't consider ANSI to be graphical 16:28:46 yeah, ansi would be a hack :P 16:28:56 in the above warning, I mean both a text and graph MUD 16:29:09 hmm, i want to code on the mud online.. 16:29:19 it's too easy to bring the server process to its knees by accident 16:29:19 i would have to put in safety stuff :) 16:29:38 do so would unceremoniously dump all the users 16:30:06 quite a few muds let ppl code online on it.. 16:30:34 let the opers telnet to a development system running parallel to the public one 16:30:50 naw.. 16:31:04 then copy the files into the public directory and restart the public system when code is tested 16:31:41 the muds that I saw were NOT written in Forth, even though they had a forth scripting language 16:31:53 was that DikuMUD? I don't remember now 16:31:59 tinymuck is the only one i know of with a forth scripting lang 16:32:09 tinymuck! that's it 16:32:29 it shouldn't matter if the mud is in forth.. i should be able to do something to make it reasonably safe to code online on it 16:32:36 if you crashed your interpreter, it didn't bring the whole system down 16:33:19 ANY language that allows real-time change to running code is prone to crashing 16:33:30 TCL is bad for that 16:33:51 erm ... incidently ... in favor of Forth 16:34:15 there would be two layers though.. there'd be the bottom layer of forth code, which i wouldn't touch.. and then there would be the commands and stuff that the users use 16:34:20 in theory ... it should be possible to restart the server gracefully w/o the user ever knowing it had happened 16:35:49 in coding the text-mud i don't have any idea where to start... 16:36:09 heh, with accepting socket connections 16:36:15 ok 16:36:29 you might want to write out sample sessions with a text editor 16:37:27 do yoiu have a linux machine handy? 16:37:27 do i put that stuff in the loop that checks every socket? 16:37:55 yes, to start 16:37:57 yeah i have linux on a partition 16:38:05 set up the listener socket 16:38:29 cehck the listener one each time through the loop for new connections 16:38:53 if new connection, setup a user databuffer for line storage 16:40:15 be sure to use allocated memory for everything that isn't actually compiled source code 16:40:33 what words do i use to deal with sockets :) 16:41:15 that way, when you restart, you can write all the data out to disk, delete the vocab holding the server, reload the new source files, reload the user data, and resume operations 16:41:52 which platform? 16:42:26 * MrReach searches the Win32Source for socket commands. 16:42:36