00:00:00 --- log: started forth/04.01.05 00:10:38 --- join: schihei (~schihei@pD9548821.dip.t-dialin.net) joined #forth 00:21:23 --- join: ayrnieu (~julian@206.61.132.131) joined #forth 00:21:57 slava - what did you call that language, again? 00:26:20 : cons here >r , , r> ; : .cons ." ( " 2@ swap 0 .r ." . " 0 .r ." )" ; 00:27:29 wtf!? 00:27:40 oh 00:27:41 nevermind 00:27:42 ^__^ 00:27:52 Those smileys are annoying 00:27:59 er, what initially bothered you ? 00:28:03 Robert: sorry on 2 accounts. 00:28:12 ayrnieu: here >r ... r> 00:28:15 but then I realized 00:28:17 ^__^ 00:28:28 arke - realized what? What did you think those did? 00:29:16 Well, I know what they do, I just thought "Hey, why not put the here at the end by itself?" before i realized it does that on purpose in order to get the right address, not the address 2 cells later 00:32:25 : cons , , here 2 cells - ; 00:32:40 : cons , , here [ 2 cells ]L - ; 00:46:19 ^__^ 01:01:07 --- nick: arke -> not_arke 01:02:14 --- nick: not_arke -> not 01:02:29 --- nick: not -> Wang 01:03:05 --- nick: Wang -> arke 01:52:04 --- join: chrisrw (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 01:55:43 --- quit: rO| ("maintenancemaintenance") 02:00:44 --- quit: chrisrw (Nick collision from services.) 02:01:16 --- join: chrisrw (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 02:01:24 --- quit: chrisrw (Nick collision from services.) 02:22:51 --- quit: arke (Read error: 104 (Connection reset by peer)) 02:25:29 --- join: arke (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 02:51:37 --- join: chrisrw (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 02:51:57 --- quit: chrisrw (Client Quit) 02:52:38 * arke is away: I'm busy 03:57:12 --- join: jbj (~jbj@rdu26-59-021.nc.rr.com) joined #forth 05:18:48 --- quit: hovil ("Leaving") 05:38:07 --- quit: I440r ("going to work, brb") 05:41:40 --- join: qFox (C00K13S@cp12172-a.roose1.nb.home.nl) joined #forth 06:29:25 --- join: I440r (~mark4@saturn.vcsd.com) joined #forth 06:30:32 --- mode: ChanServ set +o I440r 06:30:53 --- mode: I440r set -o I440r 06:37:39 --- quit: fridge ("Client exiting") 06:56:36 --- join: aktnot (ident@233.80-202-65.nextgentel.com) joined #forth 07:09:13 --- join: aktnot_ (ident@233.80-202-65.nextgentel.com) joined #forth 07:12:43 --- quit: aktnot (Read error: 60 (Operation timed out)) 07:15:25 --- quit: TreyB (sterling.freenode.net irc.freenode.net) 07:15:25 --- quit: chandler (sterling.freenode.net irc.freenode.net) 07:16:01 --- join: chandler (~darmok@64-145-60-36.client.dsl.net) joined #forth 07:27:54 --- join: aktnot (ident@233.80-202-65.nextgentel.com) joined #forth 07:43:35 --- quit: aktnot_ (Read error: 110 (Connection timed out)) 07:49:52 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 07:53:39 --- join: aktnot_ (ident@233.80-202-65.nextgentel.com) joined #forth 07:54:03 --- part: aktnot_ left #forth 07:58:25 --- quit: aktnot (Read error: 60 (Operation timed out)) 08:07:02 --- quit: arke (Read error: 110 (Connection timed out)) 08:34:30 --- quit: I440r ("brb - maybe :)") 08:48:38 --- join: Herkamire (~jason@h000094d30ba2.ne.client2.attbi.com) joined #forth 08:59:45 --- join: I440r (~mark4@saturn.vcsd.com) joined #forth 09:14:45 --- join: TreyB (~trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 09:19:01 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 09:19:01 --- mode: ChanServ set +o kc5tja 09:19:48 * kc5tja is happy to report that I am slowly making headway with FS/Forth's interpreter. 09:20:02 Though I haven't written a single line of code yet, I'm settling in on a particular implementation. 09:20:23 The whole interpreter looks like it'll fit on no more than 3 screens of source code. 09:21:02 Though, to be fair, this doesn't include the primitives that I need to define for it so it'll compile. So I'm wagering on four screens total. 09:45:16 --- join: jbj_ (~jbj@rdu26-59-021.nc.rr.com) joined #forth 09:46:18 --- quit: Robert ("leaving") 09:48:05 kc5tja: you're writing FS/Forth in forth? 09:48:14 Yes 09:48:34 --- join: Robert (~snofs@c-7e5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 09:48:38 nice. So what forth are you using? 09:48:49 Currently using gforth to implement the cross-compiler for FS/Forth. 09:49:19 Though this cross-compiler, I now realize, is too complex for what it does. I could have done things much simpler, to gain the same benefits. 09:49:32 But even so, it works, and I'm not about to go changing it now. Especially since it's a use-once type of thing. 09:49:43 yup 09:49:46 The cross-compiler for FS/Forth in FS/Forth will be much simpler. 09:50:38 Some of my observations on my cross-compiler can be found at http://www.falvotech.com/cgi/fsforth 09:57:40 :( 09:57:49 * kc5tja might have to change the name of his FS/Forth product. 09:58:03 Doing a web search for FS/Forth yields several links to a company called FS-Forth, Gmbh. 10:00:42 Gotta go. Time for work. 10:00:47 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 10:02:26 --- quit: jbj (Read error: 110 (Connection timed out)) 10:37:27 --- quit: jbj_ (Read error: 60 (Operation timed out)) 11:06:19 --- quit: schihei (Client Quit) 11:32:41 sigh, it disturbs me that my interest in Forth has respawned so swiftly and completely. 11:35:11 ayrnieu: not sure what to think of that 11:37:52 Herka - I adored Forth for about a year, and then wrecked my interest trying to write a program in IsForth that needed lots of dynamic features and such when IsForth didn't even have ALLOCATE and I had to write my own networking library wrapping wrapping linux syscalls (searching through headers, trying to figure out how to nicely resolve domain names, etc). I haven't touched Forth for about a year, focusing instead of functional and lispy languages like Ha 11:39:08 Herka - then yesterday slava talked about his Forth/Joy-like language and posted a URL to a little webserver written in it. 11:40:43 ayrnieu: I see. I imagine trying to do high level programming with a still low level language would be quite frustrating 11:40:51 I think slava's think is really cool 11:43:40 Herka - well, Forth needn't lack so many high-level features. I've already mostly designed a cute IRC connect-four bot with multitasking and controlled run-time update, so I can hack and extend and debug the bot without taking it down or even stopping a game in process. 11:44:10 ayrnieu: in forth? 11:44:37 Herka - designed, yes. I know how I'll do it, but I've only thought about it since this morning before school =) 11:45:15 ayrnieu: :) 11:46:42 Herka - the bot uses all deferred words, and at certain points checks a variable to see if it should change those deferred words to new code (and also invoke a word to transform its state, maybe) -- and the bot runs in its own task, emitting text on the top half of a terminal (using an enter-thread/exit-thread extension to the multitasker to change the terminal scrolling region) while a normal interactive Forth works on the lower half. 11:47:13 Herka - so I hack a bit, hack a bit, point some deferred words at new code that I've figured out and then set a variable -- and the bot moves over to the new code when it notices. 11:48:04 not really my sort of thing. why all this deferels and not restarting the game? 11:48:31 Plenty of time to remove the multitasking and the deferredness if I ever decide that I've gotten the bot working the way I like it, after this nice development environment. 11:49:29 Herka - faster development this way -- I basically write a 'development' bot and then keep editing its source in an editor whilst also checking interactively with the bot and updating it to immediately test features and fix bugs. 11:50:03 Herka - and I think the ability to say 'woops, that shouldn't happen -- wait a sec... OK. Carry on =)' during a game has much coolness to it. 11:50:19 ayrnieu: ok, that does sound usefull now that I think about it more. I was making a bot and I kept having to disconnect it to change something. 11:52:09 Herka - something I learned in Erlang =) You can program *must faster* when you can hack a server from 'wow, it accepts connections!' to 'hey, I just added some cute colorization to this bit of output' without ever stopping the server. 11:53:27 Herka - it also makes for easier programming, because you can build the program feature-by-feature, immediately testing the results. Forth compiles fast enough that you can do this with stop/restart, but the overhead of connecting back to the server, forcing people to restart their interactions with the server, etc, slow you down. 11:54:05 ayrnieu: sounds good 11:54:10 but, anyway, I'll start working on my bot a little later today. 11:55:12 I'm considering an architecture for my new forth system where there is no compiling (except for optomization) and the forth engine and editor run off the same source, so editor changes instantly take effect 11:57:21 Herkamire - how would that differ from compiling to ALLOCATEd storage with implicitly deferred words? 11:58:33 Herka - and presumably you'd need to allow atomic edits, too, or else you couldn't ever edit the interpreter from within the editor =) 11:59:06 ayrnieu: the important difference that I'm looking for a solution for, is with my system, all changes happen instantly, so this would make it difficult or impossible to make serious changes to something that is running (like the forth core) because you often need to change more than one thing before it's in a working state again 11:59:22 ayrnieu: exactly the problem 12:02:03 Herka - what if you had nested systems? So when you load the editor the editor runs in the 'super' system, with a new system spawned that reflects its code. If that system breaks during an edit, no worries -- the 'super' system will just immediately restart it... and then you can run an editor in the newly altered system, or throw the changes away and close the editor, reverting to the original system -- or save the new system as an image, or migrate to th 12:03:09 ayrnieu: that's probably what I'll do 12:03:56 at first I was thinking of having two copies of the "kernel/editor" parts. but I don't want to have two categories of code, some of which you have to sync and some that is instant-change 12:04:07 so I think I'll probably have to have two copies of the source. 12:04:16 not sure if that is going to introduce complications 12:04:36 Herka - I suppose that you'd still have problems with, e.g, terminal-controlling code or networking code or such -- if you integrate a task-manager into your system, you could have define 'stop-on-edit' tasks, maybe, so the new system will spawn with most of its critical tasks stopped. 12:04:37 the whole point of this was to reduce complexity, so if it get's complicated the whole thing is out 12:07:17 Herkamire - well, if the entire system runs on source and you have nested systems, it makes sense that you copy the source when you edit it for a nested system -- but why limit yourself to only two systems at a time? You couldn't test edit-new-system code without migrating it with that limitation. 12:09:10 geepers. I hadn't really thought about multitasking 12:09:35 it could be very bad to update the source while a task is in the middle of executing it 12:10:55 yeah, hence the way I've designed my IRC bot, with atomic updates on 'its terms' -- it decides when to check for new updates. 12:14:39 I'm planning on using cooperative multitasking, so I don't think this will be a problem. and if I'm really going to change the flow control of a program drastically enough I can't change some of is't code when it's waiting in the event loop, then I'll probably want to stop the program first anyway. 12:19:26 hmmmm. maybe I'll use a more traditional compiling aproach 12:26:53 * warpzero is away: Let's get a party goin', let's get a part goin', let's get a party goin', party hard, party hard: irc.wsyntax.com 12:27:44 * warpzero is back (gone 00:00:09) 12:45:59 --- quit: tathi ("leaving") 12:59:46 --- quit: Robert ("Away, practicing being silent.") 13:44:21 --- join: Robert (~snofs@c-7e5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 14:55:31 --- join: jbj (~jbj@rdu26-59-021.nc.rr.com) joined #forth 14:56:01 Hi 14:58:42 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 15:01:05 --- quit: I440r ("brb - going home") 15:28:44 --- join: I440r (~mark4@12-160.lctv-a5.cablelynx.com) joined #forth 15:30:59 --- join: tathi_ (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 15:31:07 --- quit: tathi (Nick collision from services.) 15:31:13 --- nick: tathi_ -> tathi 15:31:36 I hate X 15:35:26 --- quit: qFox ("if at first you dont succeed, quit again") 15:48:28 --- join: arke (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 16:44:44 --- join: tathi_ (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 16:45:00 --- quit: tathi (Nick collision from services.) 16:45:02 --- nick: tathi_ -> tathi 16:57:27 --- nick: jbj -> jbj_tampa 17:10:58 --- join: TheBlueWizard (TheBlueWiz@207.111.96.23) joined #forth 17:10:58 --- mode: ChanServ set +o TheBlueWizard 17:11:07 hiya all 17:11:23 hi TheBlueWizard :) 17:12:40 hiya Herkamire 17:16:50 it's a shame compter interfaces generally haven't improved sinse the Amiga 17:17:45 yeah...a shame indeed 17:20:00 hiya 17:20:25 hiya arke 17:22:20 ^__^ 17:22:33 dammit, need to switch windowmanagers... 17:22:53 * arke is away: brb 17:23:10 --- quit: arke (Read error: 104 (Connection reset by peer)) 17:23:48 --- join: arke (~chris@wbar8.lax1-4-11-099-104.dsl-verizon.net) joined #forth 17:24:41 gotta go...bye all 17:24:55 --- part: TheBlueWizard left #forth 17:25:03 bye,,, 17:25:06 I'm back. 17:33:02 --- quit: tathi ("leaving") 18:27:48 hi all 18:29:41 slava - howdy. Welcome back. 18:30:02 slava - what did you call your language, again? And where do you have it? 18:30:31 its called "lsd", just a temporary name :) 18:30:36 you want a copy? 18:30:39 i can upload the latest. 18:31:11 ooh, ooh, can I play? 18:31:45 http://slava.kicks-ass.org/slava/LSD.jar 18:32:06 my machine's port 80 is still apache -- it supports > 1 connection :) some stuff is served from :8888 which is an httpd written in that language. 18:32:08 slava - thankee =) 18:32:55 whats LSD like? 18:32:56 very nice. is this dynamically typed or untyped? 18:33:05 chandler, dynamically typed 18:33:24 very very nice 18:33:30 arke - it a bit like Joy -- with lists of words and combinators. 18:33:31 chandler, unlike forth, only 1 set of +, -, *, / that supports a 'number tower' with integers, floats, bignums, and ratios 18:33:40 ayrnieu, yes, the names of the combinators are in fact taken from joy. 18:33:45 slava: hrm? 18:33:49 ayrnieu, the implementation is different. joy does not expose the return stack with >r/r> 18:33:51 this looks like scheme to me too 18:33:54 also, it looks. 18:34:02 chandler, its postfix syntax! 18:34:02 arke - people describe 'Joy' as 'Forth's functional cousin' 18:34:12 I took a look at joy ... its ugly 18:34:18 compared to forth? 18:34:33 Forth is as ugly as you make it. 18:34:33 arke - lsd looked non-ugly enough to me to re-spark my interest in Forth =) 18:34:34 ^_^ 18:34:40 ^___^ 18:34:59 slava: c'mon, you have call/cc 18:35:14 chandler, yes 18:36:02 slava: do you have a web page for LSD? 18:36:18 slava - do you have a specification of LSD? 18:36:38 neither 18:37:02 ayrnieu, docs don't exist. this hasn't been released yet, only mentioned it on irc. i will make an SF project for it soon. 18:37:27 slava - OK. 18:37:33 ugh, sf is evil! 18:37:41 sf is evil, but it works.. 18:37:42 chandler, where else would i host it? 18:37:51 dunno. aren't you a jedit person? 18:38:09 jedit is hosted at sourceforge 18:38:14 oh 18:38:28 don't let the domain name fool you :) 18:39:12 joy is ugly, but potentially fun. 18:39:19 I'm considering writing a joy dialect. 18:39:28 how do you use its callcc? 18:39:32 It would be more forthish in its approach. 18:39:49 I've never found Joy all that interesting, really. I like Forth, I like many functional programming languages, I don't really like joy. 18:39:50 I've gotten call/cc explained to me 1`232154145145153125876 times, and I still don't get it ^__^ 18:40:28 arke: basically it copies and heap-allocates the return stack as a procedure which when called replaces the return stack with what was originally copied 18:40:47 [1 2 3 4] [dup *] map <--- this is still okay, but... 18:40:53 arke - it copies the data and the return stacks and returns an xt that connects them to the current data/return stacks. 18:40:54 .................. 18:41:10 can you write me a forth words that does that? :) 18:41:11 ayrnieu, i'm not a real fan of joy's tailrec/binrec/linrec/genrec 18:41:46 ayrnieu, that explains continuations pretty well. 18:42:00 ayrnieu, but an efficient implementation (which mine is not) would try to minimise copying. 18:42:47 arke - so, say : foo ( a -- xt -- b -- a+b ) call/cc + ; 1 FOO ( xt ) 2 over execute . ( 3 ) 4 swap execute ( 5 ) 18:43:27 ayrnieu, in my language it is different 18:43:31 ayrnieu, here is an example: 18:43:35 !?!? 18:43:44 : hello [ @mycc ] callcc + . ; 18:43:50 slava - and hopefully much better =) I just made that up for pedagogical purposes. 18:43:56 then you invoke: hello 18:44:04 and now the continuation is in $mycc 18:44:09 could you give me a forth word for call/cc? 18:44:11 as in, 18:44:12 so you can do 2 2 $mycc call 18:44:15 : call/cc .... ; 18:44:15 and it prints 4 18:44:19 fill in teh ... ^__^ 18:44:41 arke - exercise for the reader! 18:45:04 : callcc ([ code ] --) 18:45:07 datastack$ callstack$ [ [ ] continue ] cons cons 18:45:07 swap call ; 18:45:11 but that's my language ;) 18:45:15 very nice 18:45:30 it uses another definition 'continue' which is a bit of a mess, i won't paste it here 18:45:46 you can look at it though: slava.kicks-ass.org:8888/lsd/continuations.lsd 18:46:41 you need to document this 18:46:47 this language is cool 18:46:47 i will 18:47:11 the http server will be a dynamic 'javadoc' system that will view code and documentation side by side 18:47:18 javadoc-style 18:47:31 (also doxygen, etc are the c++ equivalents) 18:48:01 i've sort of begun but it only shows the code right now: http://slava.kicks-ass.org:8888/dictionary.lhtml 18:48:07 this is a server-side script 18:49:31 a forther should look at the definitoins of 'dup', 'swap', '2dup', etc. 18:50:05 uh. you write code as a comment? :-) 18:50:19 for stack words 18:50:43 very cute 18:50:47 a lot of words are bindings to java library functions, like + for instance. but all the control structures are in the language itself 18:50:52 look at each or map 18:50:53 any hope of actually compiling this language? 18:51:14 the stack words can be compiled easily, also words that use java reflection only. 18:51:19 other stuff is trickier 18:54:28 : callcc ([ code ] --) 18:54:28 datastack$ callstack$ [ [ ] continue ] cons cons 18:54:28 swap call ; 18:54:45 yes 18:54:46 what do obviously, [ and ] have differnet meanings here. 18:54:50 what are they? 18:54:56 same meanining always. 18:55:01 [ ... ] is a linked list literal. 18:55:06 (...) is comment 18:55:39 oh 18:55:39 ok 18:55:47 note that [ ] is a null pointer as well as an empty list 18:55:55 using cons cells, is my guess... 18:55:57 [ foo , bar ] is a 'cons cell' 18:56:08 and [ 1 , [ 2 , [ ] ] ] is [ 1 2 ] 18:56:15 [ ] can also be written f 18:56:24 anything that is not f is true for purposes of flow control 18:56:49 so datastack$ callstack$ [ [ ] continue ] cons cons creates [ datastack$ [ callstack$ [ [ ] continue ] ] ] 18:57:09 and what is continue again? 18:57:20 no, it creates [ [ ] continue ] 18:57:34 where is what datastack$ evaluates to 18:57:47 continue is another word, look it up in the dictoinary 18:58:07 note that the code in [ ... ] is not evaluated immediately, it is just part of a list that is on the stack. 18:58:31 this list is the 'xt' that is returned by callcc 18:58:50 when executed, it restores the call stack and datastack to what they were, using 'continue' 19:02:20 * slava looks at httpd logs. ayrnieu is looking at each word in turn :) the source is nicer to look at than the dictionary.lhtml; it has comments and a better layout. 19:03:41 hrm.. 19:03:49 I don't get it ^__^ 19:04:09 slava - well, 'wget' does more looking than me, right now =) The last time I thought that I could casually go back to your site, you'd taken your nifty httpd code down. 19:04:18 or the server. One of those. 19:05:18 wget probably takes enough of its sweet time that it looks a human, though, given the way my connection thrashes right now. 19:05:39 ayrnieu, all the source is in the LSD.jar file whose url i posted, except a few server side scripts for the httpd. 19:05:54 slava - ah, OK. 19:06:05 slava - still waiting for blackdown to download =) 19:06:08 the httpd is slow too :) 19:06:24 ayrnieu, it compiles with gcj, with some changes. 19:06:50 ayrnieu, mainly that lsd uses a few jdk 1.4 features (not many, nothing graphical) 19:12:17 ~<< 2dup 19:12:17 a b ~~~ a b a b >>~ <-- might I add that this is neat as hell? 19:15:38 sorry i killed the httpd 19:15:47 ayrnieu, i closed the xterm it was in by accident :) 19:15:54 ^____________________________________________________________________________________________________________^ 19:15:56 slava - oh, why? 19:16:01 its back up 19:16:29 slava - does the 'see?' documentation exist in the LSD.jar ? 19:16:41 ayrnieu, yes. "foo" see in the interpreter 19:16:47 ayrnieu, the lsd jar also has the source code. 19:16:56 nifty. 19:17:17 i just remembered that examples.lsd hard-codes the port number and path for the httpd. if you want to run it, you can edit this file first, then eval examples/httpd 19:17:39 default doc root is /home/slava/ExampleHTTPD/ which will not exist for you 19:18:03 ayrnieu, in case youre wondering why this exists, its scripting in a game. 19:18:17 ayrnieu, game uses java opengl bindings for graphics, its coming along pretty well. 19:20:49 slava - well, OK. 19:43:14 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 19:43:14 --- mode: ChanServ set +o kc5tja 19:56:21 slava: [ and ] have a different meaning in forth. 19:57:55 hiyahiyahiya kc5tja 19:58:32 umm 19:58:33 Hi 19:58:34 I guess. 19:58:55 It's nice to know that I am bathed in such joyous happiness. :) 19:59:52 Oh yeah! 20:00:05 everytime you come to this room, celebration breaks out. 20:09:32 yay 20:13:08 yayayaayyayyyyyy 20:13:11 clap clap clap clap 20:13:38 oh, hey, kc5 has returned. 20:14:04 hehe :) 20:14:47 * arke is implementing a 6-register cache optimization routine for pygmy. 20:14:56 er, not 6 20:15:05 EAX, ECX, EDX, EDI 20:15:06 4 20:15:08 $_$ 20:15:30 * kc5tja nods 20:15:41 * kc5tja is still designing FS/Forth's command-line and block interpreter. 20:16:08 Though, block support isn't something I particularly look forward to implementing. 20:16:18 I always hated implementing blocks in a new Forth. 20:16:24 ^__^ 20:17:30 i never understood blocks. 20:17:37 unless you're very limited in memory. 20:17:39 A part of me says, "Screw blocks, just stick with files, since Linux already has a perfectly good filesystem interface you can rely on." 20:18:11 slava: I find blocks are vastly superior to files for coding. I can keep things all nice and neat and organized. 20:18:21 but having to refer to them by numbers? 20:18:25 I can also comment my code in a cleaner way. 20:18:31 What's wrong with that? 20:18:33 with shadow blocks? 20:18:36 slava: Yep. 20:18:47 well i prefer having a file named strings.lsd than block 37 or whatever... 20:19:04 I have a word called INDEX that prints the top line of each block in a range you give it. 20:19:12 It's as good as filenames. 20:19:27 are the words in all blocks available at all times? 20:19:31 or do you have to say "load block 12" 20:19:38 You have to load them. 20:19:59 Blocks, of course, can cause other blocks to be loaded too. 20:20:51 it seems a bit iffy to me... just like having hard-coded magic numbers in code, instead of using constants. 20:21:07 You can use constants in Forth too. 20:21:15 Nothing prevents you from saying something like, 37 constant Strings 20:21:18 Strings load 20:21:21 i guess 20:21:36 how are they stored? just a bunch of 1k files with numeric names? 20:21:44 I have my gforth set up that way currently, where I have many user commands mapped to things like "2 load" or "15 load", etc. 20:22:07 Usually, a single, contiguous file, where each 1024 byte chunk represents one block. 20:23:42 you know, this has given me an interesting idea. 20:23:56 PygmyForth was a bit more sophisticated than this. It mapped ranges of blocks to individual files (e.g., blocks 1000-1999 could be in one file, while 15000-15099 could be in another, etc) 20:24:34 What's that? 20:25:14 kc5tja, well, have all blocks stored in one file, and load/save them on the fly with a pseudo-virtual memory system, and store compiled code in blocks too; each block of code will have a shadow block with comments, and a compile output block. 20:25:35 when you modify a word definitoin in a block it is reloaded immediately 20:26:35 Blocks are more or less already kinda sorta done that way. 20:26:49 i guess i reinvented the wheel :) 20:26:54 They already implement a virtual memory-like behavior, in that blocks are treated exactly as caches in a larger virtual address space. 20:27:08 what i'd like is have the block numbers not visible really. all done with names 20:27:09 Well, changing source doesn't cause the binary code to be changed right away. 20:27:26 But it's not that hard to come so close as to make it worthless to even try. :) 20:27:52 Well, having names requires having a file system, and that's additional complexity that I can do without. 20:28:13 it will be a very simple, flat namespace for names. 20:28:20 i think i can manage it. 20:28:33 Where are you going to store the names? 20:28:39 And how are you going to search them quickly? 20:28:51 Will a name reference one block or a whole range? 20:28:52 etc. 20:29:07 These are all issues that I don't have to deal with when working with blocks at the moment. 20:29:46 in fact i've thought of extending my langauge to store everything in a full fledged object database. not very forthish eh :) 20:30:31 slava: I'm not sure I'd agree that it's not Forthish. It's just not minimalistic, that's all. But if it suits your purposes, then there is no reason not to shoot for it. 20:30:49 Jeff Fox's AHA system more or less stores his source code in a database format, though it sits on top of blocks as its underlying persistence engine. 20:31:33 i will start with a block approach. 20:31:50 i have a lot of ideas for language <-> db integration, and i want to experiment with them over time. 20:32:23 the main priority of the language right now though is just using it in my game, and extending it to suit this. its serving that purpose well. 20:33:08 The way I see it, solve the problem you have right now. 20:33:26 Don't try to find the General Solution, because the General Problem doesn't exist. 20:33:29 indeed. 20:33:33 right now files is working well. 20:33:54 Yep, and this is why I've been kinda hedging back and forth on the issue of blocks for FS/Forth for Linux. 20:33:58 http://www.falvotech.com/cgi/fsforth 20:34:02 i guess blocks are easy to implement, so... 20:34:02 oops 20:34:07 Yep. 20:34:21 They are very easy to implement. But the cache management strategies can be complex sometimes. 20:34:39 This is why Chuck Moore redefined BLOCK to be 1024 * in ColorForth. He uses RAM instead of disk storage to maintain blocks. :) 20:35:08 i like this: Fortunately, nearly all FS/Forth primitives can be expanded to one or two CPU instructions. Relatively few things expand to three. None, so far, expand to four or more. 20:35:11 ! 20:35:40 gforth has some pretty big assembly definitions in the kernel. 20:36:06 It's also not a native-code producing compiler wither. :) 20:36:08 either even 20:36:26 the newest version of gforth has moved from ITC (but with an optional -itc compiler, apparently) to native compiled, right? 20:36:56 The code my Forth produces is not optimal; but it's a heck of a lot faster than either PygmyForth or gforth. 20:37:19 ayrnieu: No. Where'd you get that idea from? GForth has always been either DTC or ITC. Never has, nor will be, native code producing. 20:37:26 You might be thinking of BigForth. 20:38:02 i must go now. 20:38:05 good talking to you all. 20:38:19 later slava. :) 20:38:29 kc5 - I remember it building ITC on intel machines as some optimization, but nowadays it builds something else with an extra -itc build. Perhaps this evidences some portable redundancy. 20:39:03 No, it uses direct threaded code by default, unless you use -itc, which causes it to build using indirect threaded code. 20:39:37 But even DTC requires an inner interpreter. Native code and subroutine threaded code both discards the concept of an inner interpreter, choosing to let the CPU itself directly execute the Forth code. 20:39:38 kc5 - oh, I wonder why it changed. 20:39:45 Efficiency. 20:40:04 kc5 - before it said that it chose ITC over DTC on x86 for efficiency reasons =) 20:40:07 Modern CPUs have branch target buffers and reasonably excellent branch prediction logic, so ITC is no longer faster than DTC anymore. 20:40:16 That was then. This is now. 20:40:42 Before, REP MOVSW was faster than an explicit loop. Now-a-days, REP MOVSW will kill performance faster than a direct hit from an ICBM. 20:40:48 does my P2M qualify as a 'modern CPU' in this estimation? 20:41:20 ayrnieu: Is your CPU an Intel-clone? 20:41:30 If not, then it doesn't matter whether it's 'modern' or not in this context. 20:41:47 When I said 'modern CPUs,' I was talking within the context of x86-architecture CPUs, which I had assumed you were too. 20:42:58 er, then gforth must've made quite a mistake in previous versions with its explicit 'oh, you've a pentium? I'll use ITC' -- but OK. 20:47:28 Different Pentiums have different rules for optimizing. 20:47:51 The latest series of Pentiums (P3s and P4s) all have 2-cycle branch overheads. 20:48:01 **IF** the target address is correctly predicted. :) 20:48:06 You just said that it didn't matter what machine I had, given its 'modern CPU' status. ah--and nifty. 20:48:22 * kc5tja discovered through my own experiments that there's a monsterous 30 to 60 cycle penalty if it is NOT correctly predicted. 20:48:33 No, that's NOT what I said. 20:48:36 Listen to what I'm saying. 20:48:55 In the context of Intel CPUs, a "Modern CPU" has rather decent branching performance. 20:49:11 I had assumed, considering your previous discussions, that you were talking about Intel-class CPUs. 20:49:22 Oooooohhhh.....wait! 20:49:23 wait! 20:49:24 wait! 20:49:31 P2M -- Pentium II series CPU? 20:49:37 Mobile, yes. 20:49:40 Wow, I rarely see a P2 listed as a P2M. 20:49:43 Sorry, that was my fault. 20:49:50 I think a P2 has the same rules as a P1. 20:49:55 The P3 has the new branching implementation. 20:50:13 I'm not sure about the P2M, though, since it's a later die version than the original P2. 20:50:32 I would say build both kinds, and benchmark to see which is faster. :) 20:50:39 I wonder how well P3/P4 prediction works on typical Forth code =) 20:50:50 Pretty good, all things considered. 20:51:09 Since decisions are generally avoided in Forth code, it's true that most branches are statically known at instruction fetch time. 20:51:38 Frankly, I find pipeline interlocks to be a much bigger problem in Forth code than branching overhead. 20:51:46 Man, I feel totally stupid now. 20:51:50 I can't believe I didn't see that before. 20:51:51 :/ 21:11:30 kc5 - see what before? 21:12:30 I thought your `P2M' was a custom CPU design you were working on for some reason. It seems like everyone else here in the channel has one. :) 21:12:50 ah. OK. 21:13:01 And with me not recognizign it as the Pentium II-M, I feel kinda stupid for not seeing it sooner. 21:15:39 Sorry for confusing you -- I should've taken pause on your 'If not, then it' assertion. 21:15:54 Instead of misreading it =) 21:16:21 Man, that was a whole comedy of errors then, I guess. :D 21:17:16 Definitely a conspiracy! 21:17:24 Heh 21:17:45 Well, all I know is that FS/Forth ought to run about 3.5 to close to 10x faster than the direct threaded systems I've used in the past. 21:18:16 This is despite the fact that it does not perform a lick of dataflow optimization at all. 21:18:32 All optimizations that it performs are peephole optimizations. 21:21:44 Well, in the brief period that I had the site open, it seems that people really like FTS/Forth as the leading alternative to FS/Forth. 21:26:26 What site do you mean? And how does FTS/Forth differ from FS/Forth 21:26:43 http://www.falvotech.com/cgi/fsforth/FsForthNameChangeProposal 21:35:42 ah, OK. 21:38:11 --- join: imaginator (~gps@166.70.196.201) joined #forth 21:38:41 * kc5tja needs to decide whether to make IF consume its argument or not. 21:39:14 If IF consumes its argument, it has the advantage of being closer to the Ideal Stack Machine. 21:39:38 But if IF doesn't consume its argument, then it'll be more closer to x86, and would expand to one instruction. 21:39:44 Hmmm....so many tradeoffs. 21:40:05 * kc5tja decides in favor of MachineForth, since everything else so far is MachineForth-based too. 21:41:16 yay. 21:41:50 It's funny -- since starting the FS/Forth product line in the mid-80s, they've been progressively going closer and closer to MachineForth. 21:42:03 This version just plain goes all out, and the next version I have planned goes even farther. 21:42:54 FTS/MF86 is my current name for that project, and while it has an effectively infinite return stack (ESP register as usual), it only implements a 6-deep data stack (the data "stack" exists purely in CPU registers). 21:44:16 * kc5tja is also planning on exploring Color Forth in the future too. 21:44:39 --- quit: scope (sterling.freenode.net irc.freenode.net) 21:44:39 --- quit: ayrnieu (sterling.freenode.net irc.freenode.net) 21:44:39 --- quit: skylan (sterling.freenode.net irc.freenode.net) 21:44:46 But MF86 and my ColorForth will be written in FTS/Forth. 21:44:56 cool 21:45:34 --- join: ayrnieu (~julian@206.61.132.131) joined #forth 21:45:34 --- join: scope (junk@njd.paradise.net.nz) joined #forth 21:45:34 --- join: skylan (~sjh@vickesh01-4902.tbaytel.net) joined #forth 21:46:19 Man, I have so many applications I want to write in Forth it's not funny. 21:46:41 And for the first time, I'll have a Forth environment powerful enough to interact with its environment, so things will actually work. 21:48:33 I suppose one can make Chuck Moore's ColorForth do the things I want too, but it's lack of general purpose byte addressing and full character set limits it for my needs. 21:48:59 Otherwise, I really like ColorForth. :) 21:49:12 In fact, it was ColorForth that inspired me to resurrect my FS/Forth line in the first place. 21:49:44 Herkamire: re: wiki -- I can see your edit in PikiSandBox. 21:50:05 Not sure if that means anything to you or not. 21:52:01 kc5tja: no, I put that in with firebird :) 21:52:04 back. 21:52:07 ^___^ 21:52:13 Herkamire: Ahh. :) 21:52:16 6 deep data stack using registers only, eh? 21:52:30 I wanna write my own wiki 21:52:30 neat, neat, neat. 21:52:40 in forth ^__^ 21:52:41 but I can't think of a good reason 21:52:54 kc5tja: so you're gonna be using compile time register optimization? 21:56:57 arke: Not as such; I'm going to use the CPU registers as a circular stack. 21:57:04 Herka - say "I'd like to have a wiki -- but what wiki should I use? Hey, I know, I'll just write a simple one." =) 21:57:11 Basically, the CPU registers is all you'll have in MF86. 21:57:51 A Wiki engine is one of my higher priorities for FS/Forth too. I intend on using it to thoroughly renovate my own website, and to engineer a website for my roommates. 21:58:33 I'd also like to replace PIKI with my Forth Wiki Engine too. 21:58:35 FTS/Wiki. :D 21:58:40 I like the sound of that. 21:58:50 kc5tja: that might be hard to implement, as you need to keep an index, and then choose the correct registers based on the index. 21:58:57 kc5tja: :D 21:59:02 arke: I've done this type of thing before. 21:59:08 It's not intensely hard to do. 21:59:14 How do you do it then? 21:59:25 Maintain a "register to stack" mapping inside the compiler. 21:59:36 Words like SWAP and DROP and whatnot do not emit code; they only affect the mapping. 21:59:45 Yes, but you won't always know the location at compile time, right? :) 22:00:19 At basic-block boundaries (e.g., where you'd stick a label in NASM, for example), you would "canonicalize" the registers, so that they line up to compiler's expectations. 22:01:13 !? 22:01:57 In other words, at every control flow join or branch, you need to make sure the top of stack is in EAX, the next in EBX, etc. 22:02:06 You may have to generate a few XCHG instructions to get the registers right. 22:04:39 uum 22:04:54 it seems to me like you need to make an align call every procedure call.... 22:05:10 :( 22:05:17 But I sleep. 22:05:21 * arke is away: zZzZ 22:07:09 Nope. 22:07:15 Only when registers are known to have been modified. 22:12:34 --- join: Serg (~z@212.34.52.140) joined #forth 22:13:00 hi 22:13:17 kc5tja: any good IRC or other forum on homebrew radio ? 22:14:46 I'm not familiar with any. 22:14:51 The closest I can think of is #electronics 22:14:52 ;(( 22:15:02 But it's not restricted to just radio, afaik. 22:17:36 is it common to sell old military equipment to hams ? 22:17:45 in USA ;)) 22:18:21 here many men work on heavy tubed backpack rigs ;)) 22:20:34 Yes, if you can find a surplus electronics shop, there are usually a few pieces of gear from discarded military units there. 22:25:34 --- quit: scope (sterling.freenode.net irc.freenode.net) 22:25:34 --- quit: skylan (sterling.freenode.net irc.freenode.net) 22:25:35 --- quit: ayrnieu (sterling.freenode.net irc.freenode.net) 22:26:15 --- join: skylan (~sjh@vickesh01-4902.tbaytel.net) joined #forth 22:27:22 --- join: scope (~junk@njd.paradise.net.nz) joined #forth 22:28:51 bbiab 22:30:45 --- join: ayrnieu (~julian@206.61.132.131) joined #forth 22:33:10 do you know about Losev cristadyne ? 22:38:38 jar apparently needs 7 OS-level threads to unpack a 'jar' archive. How interesting. 22:39:07 actually extracting a file or listing a filename would further impress me. 22:40:44 ayrnieu: heh, my multi-thread news client has only one OS thread (in Perl ;)) 22:40:59 it sucks as fast as WGET on slow phone modem 22:41:16 3k of code ;)) 22:43:02 3-5 kB/sec, vs. 300 byte/sec one-thread 22:46:28 I don't understand the comparison you just made, sorry. 22:47:41 simple: i ask server for article, packet travels to server 22:47:58 then article travels back to me 22:48:13 so during the ping time, line is not used, time wasted 22:48:22 ok ? 22:50:49 so i can do other things in that time , like asking for other article in other thread ;)) 22:51:00 That you spawn a thread for each article download, sure. What does "3-5 kB/sec vs. 300 byte/sec one-thread" mean? What other news client do you compare your news client with? 22:51:35 my old one-thread vs. my new multi-thread 22:51:53 ah. nifty =) 22:53:33 actually, no threads but just an array of 'connection' objects and a loop ;)) 22:54:20 actually, 1st version was written for leased line, paid for traffic 22:54:45 so i minimized traffic by asking only required headers via XHDR 22:55:22 so one message took FOUR pings (Date,From,Subj,body), but on hi-speed it was of zero concern 22:55:42 but then i tried it on modem, it was skid slow 22:56:42 the first optimization was asking bunches of 100 Dates,Froms etc. in one XHDR, so 1,01 pings for message - 1-1.2 kB/sec on modem 22:57:49 next i paralellized BODY download - so it got maximum fast 22:58:08 --- join: hovil (~hovil@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth 23:03:23 who of meb here uses NEWS ? 23:03:34 err, of men here 23:09:00 I access usenet -- but why do you only want to ask males? 23:11:44 ;)) historycally, man = human being generally 23:12:00 at least, in RU, but i think in ENG too 23:13:36 Your usage definitely implies 'male' rather than 'human', but OK =) 23:16:20 back for now. 23:16:36 re, kc5tja 23:17:01 so, did you ever heard of Losev crystadyne ? 23:17:17 No. 23:18:11 But it sounds like a regenerative receiver design, based on its name alone. 23:18:33 Maybe I can offer a regenerative receiver as a kit for my kit business idea... 23:18:38 it's negative resistance in galena or zincyte xtal detector, so semiconductor RF amp in 1924, makeable in even medieval or ancient, or post-nuke 'industrial' conditions 23:19:15 Russia in 1924 was close to the latter ;(( 23:19:36 so u right about regeneration ;)) 23:20:35 no wolfram wire or vacuum suckers ;)) 23:22:26 kc5tja: i may scan for you some diagrams from Polyakov, IMHO the world's best 'open source' radio engineer 23:22:53 kc5tja: do you need ? 23:23:20 Sorry, I was googling for Losev's crystadyne. 23:23:24 Sure. 23:23:49 ok, remind me if i forget 23:24:08 I'm rarely up this late, unfortunately. 23:24:13 Especially now that I work regular hours. 23:24:22 (and soon, I will be going back to school for the spring semester) 23:24:43 u may mail me: 23:25:05 snaga ( 'ear' sign ) inbox dot RU 23:28:09 Cool. 23:30:59 --- join: bwb (~nate@ip68-4-123-127.oc.oc.cox.net) joined #forth 23:32:58 * hovil arghs 23:33:08 sysadminning is not for me 23:35:17 its a lesson in frustration 23:41:30 bwb: http://www.falvotech.com/cgi/fsforth 23:41:41 hmm 23:41:41 And with that, I'm going to go to bed. 23:41:49 heh, I'll look at it, night 23:41:54 Night 23:42:01 falvo tech :) 23:42:19 bwb: Umm...you did know that my business name was Falvo Technical Solutions, yes? 23:42:23 I do remember telling you. :) 23:42:26 Anyway, 'night. 23:42:31 kc5tja: hmmm no, don't 23:42:32 night 23:42:42 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 23:59:59 --- log: ended forth/04.01.05