00:00:00 --- log: started forth/01.11.26 00:58:35 --- join: aaronl (aaronl@vitelus.com) joined #forth 01:28:50 * aaronl is away: sleep 05:49:23 --- join: Fare (fare@samaris.tunes.org) joined #forth 09:32:43 hihi 09:41:51 --- quit: MrReach () 09:47:01 --- join: MrReach (~mrreach@209.181.43.190) joined #forth 10:09:45 lolo 10:09:55 how are you? 10:10:01 still not 10:10:24 huh? 10:10:44 you died and this is your ghost typing? 10:11:04 or I'm still not fully alive 10:11:17 ah! 11:17:29 --- join: Speuler (akhandel@preiselbeere.icafe.spacenet.de) joined #forth 11:17:42 g'day 12:47:37 greetings. 12:48:35 --- mode: ChanServ set mode: +oo aaronl Fare 12:48:35 --- mode: ChanServ set mode: +oo Speuler MrReach 12:59:03 good day 2 u 12:59:12 how goes? 12:59:27 i survived 12:59:59 i found asm source for raw keyboard input, which i have sent to you 13:00:18 that's probably not quite what i was looking for but may be useful too 13:00:47 oh! 13:00:56 allows to trap non-ascii keys 13:01:06 like shift, control etc 13:01:11 so you are "gastlogin" ... I was wondering who that was. 13:01:40 right.. i mailed it with the browser from guest login 13:01:53 yep, as far as keyboard input goes, that's about as primitive as you get 13:01:59 have two x sessions running 13:02:26 if anything else fails, single-char keyboard input could be done with that too 13:02:35 but more tediously 13:02:49 yes, have to use own lookup tables 13:03:02 lookup and translation, rather 13:03:14 independant of os keytable setup too 13:03:21 oh? 13:03:22 which is bad 13:03:27 that hadnt occured to me 13:04:11 i haven't found example source for callback single-char input yet 13:04:17 heh, can do some neat stuff, though ... like tapping left-ALT raises a menu ... and tapping right-ALT raises a different menu 13:04:40 yes. for some keys, non-ascii, it may be useful 13:04:49 Speuler: you mean where a specified address is called when a character is ready?? 13:04:57 yes 13:05:14 into the fifo with it 13:05:29 you won't find it, but I believe that signal(2) can be used for asynchronous notification of keyboard event 13:06:01 i know too little about linux os interfacing to be able to do that w/o example source or lots of trying out 13:06:27 also, I think signal is a sys_call 13:06:46 no idea yet how to hook up the app 13:06:46 yes, signal is awkward with the stacks, IIRC 13:07:04 lemme check ... 13:07:09 which forth you using? 13:07:13 toyforth? 13:07:25 meant for it 13:07:34 asm 13:08:05 i've put compare in yesterday 13:08:17 and here, comma and the like 13:08:38 getting to the point of requiring word 13:08:46 and key 13:08:51 syscall proto is ... *signal(int signum, void (*handler)(int)) 13:09:20 looking higher-level to find event numbers 13:09:26 name> 13:09:37 (which is just @) 13:10:21 found a nice alternative to "deadbeef" 13:10:32 dec0ded 13:10:52 $feed $babe $dead $beef :) 13:11:10 heh 13:11:30 in caps it looks very natural: DEC0DED 13:12:08 asked my psion to come up with anagrams of aaabbbcccdddeeefff000 13:12:29 http://quaff.port5.com/man/signal.2.html 13:14:56 syscall #67 might be more useful to you (sigaction) ... 13:15:01 http://quaff.port5.com/man/sigaction.2.html 13:17:43 implementing signal handlers allow for some *REALLY* powerful methodologies 13:18:05 like asynchronous notification when a child process terminates 13:18:19 i guess we need signals 13:18:26 no, but we want them 13:18:35 not NEED ... but vastly improves versatility 13:18:50 another one you're gonna want is SELECT 13:19:43 which allows to block on up to 1024 filedescriptors until they have input available, are ready for output, or have an exception 13:22:07 heh, have you considered building an event-driven forth? 13:22:49 no, but reacting to external events could be event-driven 13:24:11 i ry to keep any fanciness for until the kernel runs 13:24:12 are yoiu familiar with how widows does it? 13:24:18 indeed 13:24:19 not at all 13:24:32 ok, shen you write your app ... 13:24:53 windows is a big mystery to me 13:25:01 you do any initialization you need, tell windows what routine to call when something happens, then exit 13:25:06 will probably stay that way 13:25:35 when something happens, like a keypress, mousepress or move, timer expire, etc ... 13:25:51 windows calls that routine with a "message" describing the event 13:26:28 your program then reacts to that message in whatever fasion it wants, then returns to the system 13:27:17 that is a bit of simplification, actually, but you get the idea 13:28:26 so building an app amounts to writing routines to handle various events ... all others are simply ignored 13:29:03 not ignored, actually, but passed on to the default windows handler, which often ignores them 13:32:32 oh, btw, catching SIGSEGV will stop your interpreter from crashing with coredump when it writes to the wrong memory address 13:33:27 useful 13:33:51 yes, I _really_ appreciated that in gforth 13:34:18 i'll probably continue with catch + throw when i get into coding again 13:34:34 good 13:34:47 no os to interfere with this :) 13:34:57 I like catch/throw ... makes everything *SO* much simpler 13:35:21 btw, it looks like the signal handler uses the current data and return stacks 13:35:34 bad 13:35:37 so one needs to be DAMN careful to leave them intact 13:36:11 however, one *COULD* save the d/r stacks in a struct, then use d/r stacks allocated earlier 13:36:35 well, as long as the handler is clean, nothing should be wrong with it 13:36:41 that way, if a user installs a bogus handler, it won't mangle the system 13:36:53 hehe -- continuations 13:36:54 i didn't swap stack pointers to get access to return stack 13:37:12 no, that's not what I'm saying ... 13:37:32 when toyforth starts, it sets up data and return stacks 13:38:00 I'm saying it should ALSO set up seperate, smallish data/return stacks for the sig handler 13:38:45 when the sighandler is invoked, is saves the current stack state, switches to the alternate stacks already allocated, and then does whatever it needs to do 13:38:49 sometimes you see xchg ebp, esp pop reg xchg ebp, esp to get the top of return stack in that case, the handler, being asynchronous , would use the one or the other stack 13:39:40 do you understand what I'm saying about the seperate stacks? 13:39:54 call back stack probably must be nestable 13:40:02 yes, i did 13:40:09 ok 13:40:44 I can be nestable, but not required, because you can specify that the kernel hold all furthor signals until this one is finished processing 13:40:55 It can be nestable, rather 13:43:33 hmmmm ... it might be eaiser to allocate stacks when the handler is called, and free them afterwords 13:43:48 sounds like a recipe for memory leaks, though 13:43:53 was thinking of that 13:44:24 if the handler borks, the system prob wouldn't crash, but mem wouldn't be freed either 13:45:18 btw, why would you use such primitive keyboard input in the default system? 13:50:00 the raw mode you mean ? 13:50:07 yes 13:50:23 it is the closest thing i found yet to single-char input :) 13:50:24 or were you just looking for a way to do asynchronous? 13:50:45 anything without a return at the end 13:50:48 oh, in that example prog you sent me ... 13:51:02 was a demonstration of how to turn off line buffering 13:51:07 that's all you need to do 13:51:18 i really don't want to poll 13:51:28 ah 13:51:43 the kernel will queu for you 13:51:51 i noticed :) 13:51:59 (kernels are good for that @:^) 13:52:07 with good reason 13:52:39 that way, KEY or EKEY need only check when needed ... no event-driven input 13:52:51 haven't got a floppy handy to take the file with me ... 13:53:37 you'd prob want to set sigaction for POLL_IN , btw 13:53:50 if you wanted to watch for keyboard events 13:54:20 let me know if you want to know how SELECT C-macros work 13:54:35 I dove into it last year, took almost a week to figure out 13:54:54 what is select good for if we use callback anyway ? 13:55:19 because ... 13:55:52 SELECT is a way for non event-driven progs to wait on more than one descriptor 13:56:38 ooh, i think i see. instead of many callbacks, per descriptor, you use just one ? 13:56:48 sort of 13:57:02 there is no callback, it's all handled by the kernel 13:57:14 the SELECT call blocks until something is ready 13:57:23 but i don't want the kernel to block my calling process 13:57:26 (or until specified timeout) 13:57:44 sometimes you do, and sometimes you don't 13:58:01 instead i want to continue whatever i do, and have the callback inform me that data in a decriptor is available 13:58:19 a websever, for example, SHOULD block when it's done processing and is waiting for a new connection 13:58:24 with select, in any descriptor 13:58:56 there is an option for a non-blocking SELECT call 13:59:13 IIRC, it's done be setting the timeout to 0 milliseconds 13:59:40 it will ALWAYS return immediately, with an array of bits telling which descriptors are ready 14:00:14 I *THINK* 14:00:18 * MrReach goes to check 14:01:31 timeout is an upper bound on the amount of time elapsed 14:01:31 before select returns. It may be zero, causing select to 14:01:31 return immediately. If timeout is NULL (no timeout), 14:01:31 select can block indefinitely. 14:02:09 hmmm ... I always thought that NULL == 0 14:02:26 --- join: XeF4 (~xef4@dsl-VI-53.kotikaista.weppi.fi) joined #forth 14:02:37 greetings, XeF4 14:02:49 greetings, all 14:03:04 greetings, XeF4 14:03:21 from the country of the linux kernel 14:03:27 brb, making coffee 14:03:32 --- nick: MrReach -> MrCoffee 14:04:23 --- nick: Speuler -> PhoodPhrancy 14:05:10 $dec0de $food 14:06:34 --- nick: PhoodPhrancy -> PhoodPhrenzy 14:13:07 --- nick: MrCoffee -> MrReach 14:13:35 what I _would_ like to know is how to receive mouse input in console mode 14:13:55 * PhoodPhrenzy is still known as PhoodPhrenzy 14:14:16 I think it would be kinda neat to left-click the mouse and then pick a vitual terminal our of a popup 14:14:26 heh, ok, enjoy 14:18:08 --- nick: PhoodPhrenzy -> BeerBelly 14:18:54 brain blood drain will occur shortly 14:20:05 "just a beer belly, beer belly, get these mutts away from me. You know I really don't find this stuff amusing no more." ... You Can Call Me Al 14:21:14 do you expect toyForth to ever provide an XWin interface? 14:22:41 i was considering frame buffer support for the start 14:23:04 --- nick: BeerBelly -> BloodDrain 14:23:08 isn't that internal to the xwin system, though? 14:23:26 there is an xserver which runs on the fbdev 14:23:59 what is "fbdev" ... is that in /dev ? 14:24:04 yes 14:24:11 hmmm 14:24:30 when support is compiled into kernel, it starts in graphics mode 14:25:05 also consoles run graphic 14:25:24 writing to fbdev writes to graphics page 14:25:25 --- join: aum (~aum@210-86-61-152.jetstart.xtra.co.nz) joined #forth 14:25:45 yes, I had assumed that 14:25:50 (the last part, anyway 14:25:52 so you can cp /dev/fbdev file for a screen shot 14:25:54 greets, aum 14:25:59 hi MrReach 14:26:15 * aum has been madly coding for the last week or so 14:26:37 I'm getting kinda pissed off ... there is STILL no "LoadLibrary" and "GetProcAddress" system calls 14:26:48 aum: whatcha workin' on? 14:26:48 I've been working on a new forth distro with GUI, sockets, crypto etc 14:27:04 oh? really? what threading model? 14:27:13 compiled with what? 14:27:15 hear hear 14:27:23 I've just released my first forth-based app - an encrypted person-person chat prog called PSST 14:27:31 http://netforth.sf.net/psst 14:27:48 I started with FICL, but have been doing serious hacking on it 14:28:17 FICL appealed to me because of ease of creating turnkeys, and ease of Forth <-> C calls 14:28:26 * MrReach nods. 14:29:02 I've just now integrated a platform-independent GUI library called FLTK 14:29:55 heh, bit I know what .DLL it needs @:^> 14:30:23 as for threading model - i must admit i'm still inexperienced with forth - i'm not across all the threading models - FICL seems to write a word pointer into each cell during word defs - what threading model is that? 14:30:35 MrReach: PSST needs no DLLs 14:30:49 no, I meant about FLTK 14:30:59 FLTK needs no DLLs 14:31:10 I've built my copy of FLTK to do strictly static link 14:31:10 the name implies an interface to the tcl/Tk library 14:31:17 no 14:31:18 ah! ok 14:31:25 FLTK == Fast Light Tool Kit 14:31:35 it's like a poor man's GTK++ 14:31:38 gotta do some work ... i' ll be back from the other box 14:31:45 ok 14:31:46 but brain-dead easy to learn and program with 14:31:54 and produces very small binaries 14:32:05 * MrReach nods. 14:32:10 http://fltk.org 14:32:56 --- quit: BloodDrain (Remote closed the connection) 14:34:51 MrReach - what are the different threading models? 14:35:13 hmmm 14:35:32 the most conventional are direct threaded and indirect threaded 14:35:50 what is the difference between those? 14:36:41 in direct threaded, the first cell contains the address of a machine code routine that interprets the remaining tokens in the definition 14:37:12 and indirect threaded? 14:37:18 in indirect threaded, the def is always assumed to be a colon def, so there's no initial address 14:37:40 for example ... : test w1 w2 w3 ; 14:37:43 ok - netForth is derived from FICL, which seems to be direct-threaded 14:38:17 pros and cons of [in]direct threading? 14:39:11 would looke like CODE test db END-CODE 14:39:33 or like CODE test dd END-CODE 14:39:41 sorry, make that "dd" in the first part 14:40:17 speedwisethe winner depends entirely on the processor and the care with coding inner interpreter 14:40:21 i'm still pretty naive about forth internals 14:40:47 on some systems, direct is faster, on others indirect 14:41:03 i'm not very 'pure' on things - i have one foot in forth, and one in C/C++ 14:41:26 direct is a bit easier to get into machine code primatives 14:42:07 because the first token just points at the machine code for the prim, instead of at docolon 14:42:49 other threading models are subroutine threaded code (STC) and token threaded code (TTC) 14:43:18 well, i sure have some reading to do 14:43:30 subroutine consists of machine code CALL or JSR instructions instead of interpreted tokens 14:43:53 it is generally slower, believe it or not 14:44:14 because forth tends to be deeply nested, and the instruction alignment tends to get mangled 14:44:29 well, the FICL inner interpreter treats each cell as a function pointer, and calls its contents 14:44:42 but it allows for copying the called def into the current def, and then optimising 14:44:57 there's a statement like (*ip)(pVM); 14:44:58 aum: that would be direct threaded, then 14:45:01 in the inner interp 14:45:24 the called routine then places its return address on the return stack? 14:45:59 now, with token threaded forth ... 14:46:18 i think there's a run-time word for executing nested words 14:46:32 the tokens stored are actually an offset into a table of machine code addresses that get called 14:47:00 this is EXACTLY the way most Java virtual machines are implemented (w/o all the type checking of params) 14:47:19 that seems to offer location-independence 14:47:26 it does 14:47:50 the FICL inner interpreter is (.. please excuse flood) ... 14:47:55 the same word is always at the same offset in the table, regardless of platform or where the actual machine code is 14:48:05 Hofstadter suggests playing Rachmaninoff's 18's variation on a theme by Paganini in reverse 14:48:14 --- join: aum`` (~aum@210-86-60-227.jetstart.xtra.co.nz) joined #forth 14:48:16 beg parden? 14:48:22 sorry - i got disconnected? 14:48:27 ok 14:48:33 don't flood as much 14:48:44 3-4 lines at a time 14:48:48 does this channel kick people for flooding? 14:48:54 the servers might 14:48:59 clog don't care 14:49:10 and I'll deop someone if they kick yu 14:49:14 shit - i only pasted 5 lines 14:49:43 --- quit: aum (Ping timeout: 181 seconds) 14:49:55 --- nick: aum`` -> aum 14:50:07 try again 14:50:20 for (;;) 14:50:26 { 14:50:33 FICL_WORD *tempFW = *(pVM)->ip++; 14:50:38 (pVM)->runningWord = tempFW; 14:50:44 (pVM)->runningWord = tempFW; 14:50:44 tempFW->code(pVM); 14:50:55 } 14:51:03 (ignore repeated line) 14:51:14 blarg! where's the homepage for the language you're using? 14:51:28 it's C 14:51:48 oh?? 14:52:09 why didn't you go with one of the conventional C forth interpreters, then? 14:52:23 various reasons 14:52:35 1) gForth requires Cygwin environment 14:52:49 * aum doesn't like mandating cygwin 14:52:56 yes, gforth is bad coice for learning about basic interpreters 14:53:04 I would suggest TILE 14:53:14 well, i'm using FICL, and it works 14:53:24 FICL the language? 14:53:27 I've put weeks of coding effort into extending it 14:53:37 where is it's homepage? 14:53:39 FICL is an ANS-compliant FORTH distro, 14:53:44 ok 14:53:44 http://ficl.sf.net 14:53:44 aum: it is ix86 only and uses GPLed primitives with a macro-expanding compiler(evil), but have you looked at bigforth? 14:53:57 i can't read German 14:54:27 if i cover windows and x86-based linux, i'm happy 14:55:03 homepage for TILE? 14:55:17 * aum doesn't seem to remember TILE from forth.org compilers list 14:55:29 goodness, it was written in the 70s/80s, not sure there's a homepage 14:55:38 brb 14:55:56 aum: and pfe or pforth? 14:55:59 another advantage of FICL - easy to provide turnkeys that are truly standalone 14:56:24 most forths require a 'forth environment' to be installed on target system 14:56:51 after much pain with Java, I want to get away from that kind of thing 14:57:00 you can make turnkeys with bigforth 14:57:24 Most of the bigForth doco is in German 14:57:43 most of the ANS forth draft applies to bigforth 14:58:07 well, I've evolved FICL into a new distro called netForth 14:58:17 the FFI I figured out in 5min under ix86 Linux by looking at the examples 14:58:29 so far, added a coupla hundred new words to it 14:58:46 FFI ? 14:59:04 foreign function interface 14:59:06 does bigForth do sockets? 14:59:45 does bigForth only compile into the turnkey the code that's actually needed? 15:00:28 actually I haven't looked, but not that caught my attention 15:01:18 not automagically, but bigforth only fills ~64KB anyway 15:01:30 well, at this stage, I can't feel any overwhelming reason to switch to another Forth 15:01:36 XeF4: you aren't Bernd Paysen, are you? 15:01:47 Mr: no 15:02:11 if I were, I would know if bigforth supported sockets without looking :-) 15:02:32 aum: bigforth has an interface to system libs, so it can do anything the host system can do 15:03:14 bigforth as a very nice compiler, peephole optimised machine code 15:03:46 unfortunately, I was put off by the german documentation, also, and by the widget editor 15:03:56 which is incomprehensible to me 15:04:02 same here 15:04:19 I've implemented my GUI words in script 15:04:34 I notice that the author has started a seperate project to document bigforth at sourceforge 15:04:37 sample gui prog - http://netforth.sf.net/psst/screen.html 15:05:26 also, bigforth is NOT stable on Winblows, my principle dev platform 15:05:43 yeh - i noticed that gui was flaky, for one thing 15:05:58 FICL is rock solid on *doze and *nix 15:06:08 but I think bigforth could be a HELLA good system, if it were pruned, modularized, and documented properly 15:06:23 well, that's why I'm working hard on netForth 15:06:35 I use comment markups for auto doco generation 15:06:50 you got a C prog to cross compile well on both windoze and linux? 15:06:51 Minos (the GUI) is flaky everywhere. 15:07:27 example netForth app source code - http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/netforth/netForth/apps/psst/psst.fr?rev=HEAD&content-type=text/plain 15:07:29 aum: I've been thinking of writing an auto-doc for win32forth and gforth 15:08:07 sample autodoc output from netForth - http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/netforth/netForth/words.html?rev=HEAD&content-type=text/html 15:09:33 well ... that's ALMOST forth ... looks damn good, though 15:10:54 well, it uses a lot of words i've added 15:11:19 how are .EXEs written? 15:11:27 what compilers did you use? 15:11:39 I 15:11:46 I've adapted the FICL forth compiler 15:11:52 it converts forth to c 15:12:24 basically, it converts a forth file into one huge C string, and adds a tiny c func which executes that string 15:12:47 do there's an edit->compile->debug loop? 15:12:55 I plan to add compression, so that when compiled into C, the forth command isn't plain ASCII 15:13:16 MrReach: i only compile the forth code when nearing a release 15:13:32 while hacking/testing, I load the forth code interactively 15:13:34 oh, it interprets, otherwise? 15:13:41 it's up to user 15:13:50 interesting setup 15:14:10 so it LIKE a seperate image file, but contained in a C string ? 15:14:16 i've also got a primitive which causes the interpreter to log all stdio 15:14:45 so one can hack interactively, then edit the log file into a source file 15:15:17 well, it's pretty mindless - forth source code is simply converted into a C string - compiled at program startup time 15:15:19 --- join: Speuler (~root@tangerine.icafe.spacenet.de) joined #forth 15:15:23 hi 15:15:38 ok, so I start the system, define some words, and then SAVE-SYSTEM (or whatever) ... what gets written? 15:15:49 there's no 'save-system' 15:16:03 wb, Speuler 15:16:14 if i suspect i'm going to produce something useful, i turn on session logging 15:16:36 ok, i think I get it 15:17:07 pretty slick 15:17:55 and you've gotten i/o to work on both Windows and Linux? 15:20:55 back 15:21:14 i/o works ok on 'doze and 'nix 15:22:22 later, i'm hoping to create an IDE for netForth - with word/class browser, gui designer etc 15:22:36 * MrReach nods. 15:22:56 presently, it uses console which is good and bad 15:23:16 what happend to Xe? 15:23:56 brb, will talk about this some more ... interesting concept 15:24:03 k 15:24:20 * aum wants to extend it to running on Windows CE PDAs 15:26:16 SO DO I!!! 15:26:26 which one you got? 15:26:54 I'm shopping around at the moment - will probably choose Casio Cassiopeia or Compaq iPac 15:27:12 HP is not too popular with users 15:27:32 and Micro$oft provide complete dev kit, with emulator, for WinCE for free ! 15:27:50 yes, I've got it 15:28:00 is it any good? 15:28:24 and, what PDA are you using? 15:28:45 HP Jornada 525 w/ 128mb of flash 15:28:56 do you like the jornada? 15:29:04 kinda absurd, but it has as much mem as my desktop 15:29:07 yes, very much 15:29:15 i've seen complaints about dust getting under screen 15:29:28 oh? was unaware of that 15:29:38 is the 12-bit color any good? 15:29:46 I've only had mine for a month, so wouldn't know 15:30:01 8 bit color, and it's outstanding ... that's why I chose this one 15:30:20 you bought it second-hand? 15:30:27 no 15:30:43 bought it new, what makes you think that? 15:30:50 i don't wanna buy new - prices here in NZ are hideous 15:31:28 sorry - no offense intended - i assumed 525 was earlier model 15:31:53 I can imagine, I bought this one clearance, and it was still pretty expensive ($200 USD) 15:32:07 it is, recently stopped manufacturing it 15:32:30 well, jornada 548 here is $1300 new, the 568 is $1500 15:32:32 otherwise, I can START paying at $500 USD 15:32:42 arg! 15:32:49