00:00:00 --- log: started forth/03.03.24 01:52:13 --- join: Soap` (~flop@202-0-42-22.cable.paradise.net.nz) joined #forth 02:28:08 --- quit: fridge (""Wife who put husband in doghouse soon find him in cat house."") 02:55:43 --- join: fridge (meldrum@zipperii.zip.com.au) joined #forth 03:41:47 hmmm 03:41:58 must remember to keep an original of colorforth around 03:47:03 --- quit: skylan (Read error: 104 (Connection reset by peer)) 03:47:53 --- join: skylan (sjh@207.164.213.111) joined #forth 03:54:05 --- join: deluxe (~deluxe@pD9E4E969.dip.t-dialin.net) joined #forth 03:54:57 salut 03:57:37 hey 03:57:59 :-) 04:02:48 --- join: deluxe_ (~deluxe@pD950F5C2.dip.t-dialin.net) joined #forth 04:11:17 --- quit: deluxe (Read error: 60 (Operation timed out)) 04:23:39 fridge: what color4th editor r u talkin about? 04:24:53 I was dicking about with a version of chucks colorforth that had been patched to work with newer systems 04:25:29 accidently overwrote important blocks with my stupid test code 04:25:44 :( 04:26:10 aha 04:26:27 flux is a much more cleaner feeling. try that 1 04:26:30 so glad I found those updated patched versions though 04:26:38 never thought I'd be able to run it 04:26:39 heh 04:27:34 I've crashed the system about 8 times tonight 04:30:06 thats not much ;) 04:30:18 --- nick: deluxe_ -> deluxe 04:31:42 --- join: gilbertdeb (~knoppix@fl-nked-ubr2-c3a-29.dad.adelphia.net) joined #forth 04:32:53 hey gilbert 04:33:49 Hi 04:34:31 did your system crash? ;-) 04:34:48 gilbertknx: did your system crash? ;-) 04:34:52 hehehe 04:35:00 I changed something to sarge 04:35:08 and did apt-get upgrade 04:35:10 and now ... 04:35:14 LOL 04:35:15 I am back in knoppix 04:35:25 rofl 04:35:33 brave guy... 04:35:38 --- quit: Robert ("brb") 04:35:40 yeah. 04:35:48 I just want my old stuff back. 04:36:01 I had such good bookmarks too! 04:36:06 --- quit: Soap` (Read error: 104 (Connection reset by peer)) 04:36:21 deluxe: do you run debian? 04:36:45 atm on 2k, but yes 04:36:54 woody 04:36:59 it is a problem with lilo. 04:37:23 what was updated 04:37:28 everything. 04:37:40 :) 04:37:41 and I distinctly remember asking apt-get not to mess with lilo 04:38:34 at the boot prompt it doesn't seem to take my arguments. 04:39:26 any suggestions? 04:39:30 so lilo was updated from version ? to version ? 04:39:40 woody to sarge. 04:39:48 but I didn't run lilowhatever. 04:40:11 at first lilo changelog? 04:40:29 version x to y 04:40:43 changelog? 04:41:02 lilo version didn't change? 04:41:59 I am not sure at all., 04:42:14 I wasn't paying attention to the apt-get upgrade/update process. 04:42:30 I didn't even look until I rebooted and saw the Li 04:42:45 it only showed that half thing to tell me I had done something bad. 04:43:16 updating lilo(if changed) should run lilo scripted 04:43:33 yes it wanted to. 04:43:39 that I remember. but I told it 'no'. 04:43:47 now I need to somehow boot back in and do that. 04:44:03 of course, lilo must be installed to mbr or part-br 04:44:49 for now I just want to boot into the system and then correct the error. 04:45:31 maybe you could changeroot from knx to run lilo 04:45:46 but i'm not sure 04:45:51 better to 04:46:42 take debian bootfloppies to boot into your new system and then run lilo 04:47:29 if you got debian cd's it's even easier 04:47:58 I lost it. 04:48:26 what? 04:48:38 I lost the cd and I didn't make boot floppies :D 04:48:45 np 04:48:45 also I never backup. 04:49:03 tztz 04:49:16 ;-) 04:49:21 in english? 04:49:37 :-) 04:49:47 --- quit: skylan (Read error: 104 (Connection reset by peer)) 04:50:26 brb 04:50:28 --- quit: gilbertdeb ("Client Exiting") 04:50:33 --- join: skylan (sjh@207.164.213.110) joined #forth 04:51:30 --- join: Robert (~snofs@h138n2fls31o965.telia.com) joined #forth 05:51:43 --- join: XeF4_ (~xef4@guanine208.gprs.suomen2g.fi) joined #forth 06:03:32 --- join: krish (KRISHNAKUM@61.1.220.231) joined #forth 06:03:51 anybody here using isforth ? 06:06:56 I do. 06:16:07 Robert: today, I added a word that calls a simple C function that simply returns 1 on the stack. 06:17:02 what happens is: the word works fine in the "raw" kernel.com - but segfaults when invoked in the "extended" isforth executable 06:17:09 any ideas ? 06:24:36 any ideas ? 06:25:11 --- quit: krish ("Client Exiting") 06:39:20 --- quit: XeF4_ (Remote closed the connection) 06:39:59 --- join: gilbertdeb (~gilbert@fl-nked-ubr2-c3a-29.dad.adelphia.net) joined #forth 06:44:06 --- part: gilbertdeb left #forth 07:00:53 --- join: Speuler (~Speuler@mnch-d9ba43e5.pool.mediaWays.net) joined #forth 07:01:45 --- join: gilberdeb (~gilbert@fl-nked-ubr2-c3a-29.dad.adelphia.net) joined #forth 08:13:45 --- join: flyfly (~marekb@ip164.ktvprerov.cz) joined #forth 08:17:41 --- join: I440r (~mark4@1Cust10.tnt2.bloomington.in.da.uu.net) joined #forth 08:48:39 --- quit: I440r (Read error: 113 (No route to host)) 09:03:41 --- quit: fridge (Read error: 60 (Operation timed out)) 09:42:40 --- part: gilberdeb left #forth 10:12:44 --- join: I440r (~mark4@1Cust5.tnt3.bloomington.in.da.uu.net) joined #forth 10:18:36 --- join: krish (KRISHNAKUM@61.1.220.206) joined #forth 10:18:43 hi! 10:19:23 hi 10:19:43 I440r: I've been trying to reach you 10:19:47 whatz ur email id ? 10:20:06 ill privmsg it to you 10:20:26 ok. 10:20:51 i have a prob. 10:21:24 whats the problem ? 10:21:27 i tried adding a word that calls a dummy C function which returns 1 on the stack. 10:21:59 i built the kernel.com and when the word was invoked from kernel.com it worked fine. 10:22:13 but not from an extension ? 10:22:22 however, when invoked in the "extended" isforth , it segfaults. 10:22:27 why is that ? 10:22:43 i saved/restored the forth env. 10:22:57 in fact I did pusha and popa 10:23:27 ok. show me the code :) 10:23:47 oops. its on the linux partition 10:23:50 anyway: 10:23:57 heh 10:24:06 just a moment 10:24:09 well email it to me sometime and ill see if i can see why it doesnt work 10:24:23 so its simple. 10:24:28 s/so/no 10:25:37 :) 10:25:41 which register is the forth ip ? 10:25:45 esi 10:25:48 esi ? 10:25:58 and rsp ? 10:26:01 ebx is top of stack too 10:26:03 ebp 10:26:57 1 min 10:27:12 k 10:28:27 the asm code is: 10:28:32 extern c_dummy 10:28:33 forth_ip dd 0 10:28:33 forth_rsp dd 0 10:28:33 code 'dummy',c_dummy 10:28:33 mov [forth_ip], esi 10:28:33 mov [forth_rsp], ebp 10:28:34 call c_dummy 10:28:36 mov ebx,eax 10:28:38 mov esi,[forth_ip] 10:28:40 mov ebp,[forth_rsp] 10:28:42 10:28:44 next 10:28:48 the c code is this: 10:28:50 int c_dummy(){ 10:28:52 return 1; 10:28:54 } 10:29:54 "dummy emit" in kernel.com correctly prints 1. but under isforth, it segfaults. 10:30:25 ok.. who compiles c_dummy ? 10:30:27 since nasm does not support debugging I'm clueless as to what/where the prob. might be 10:30:39 gcc -c c_dummy.c 10:30:52 and how are you linking that to isforth ? 10:30:53 and I link c_dummy.o to produce kernel.com 10:30:59 ok 10:31:04 let me try 10:31:05 static linking only. 10:31:13 brb 10:31:33 one of the messages that I got was something like "eip invalid ..." 10:31:51 so I wrapped the call c_dummy with pusha and popa 10:31:59 but even then it crashed 10:32:12 hang on - im trying it :) 10:32:43 okok 10:33:41 where did you put the code'dummy_c' word ? 10:34:31 in a seperate file. i think c_dummy.1 10:34:42 and included it in isforth.asm 10:34:54 ok 10:35:04 just copied ur policy 10:35:09 how do you compile the c file without a main ? 10:35:25 gcc -c c_dummy.c 10:35:43 and use the c_dummy.o to link with the forth kernel 10:36:13 using what command to link it ? 10:36:16 exactly 10:36:37 nevermind i got it 10:36:39 hang on 10:37:05 just add c_dummy.o to the makefile 10:37:26 @ld -o kernel.com ..... c_dummy.o 10:38:20 yea thats that i did hhe 10:41:38 ok first of all the c function is called c_dummy and so is the forth word - that might cause problems with nasm and the linker :/ 10:42:53 no. the forth word is called dummy 10:43:02 code 'dummy', c_dummy 10:43:07 yes 10:43:10 the label on "dummy" is c_dummy 10:43:29 so as far as nasm is concerned its called c_dummy 10:43:40 but then how it works on the raw executable ? 10:43:41 macro 'name', label 10:43:46 code 'foo', foo 10:43:48 but then how it works on the raw executable ? 10:44:00 what you have wont heh. 10:44:55 i cant get it to build :/ 10:45:56 ok;. rename the c function 10:46:13 it wont build because nasm doesnt know what that external is 10:46:25 how do you mark a label as external in nasm ? 10:46:55 no no where do you think the clash is ? 10:47:13 code 'dummy', dummy 10:47:13 mov [forth_ip], esi 10:47:13 mov [forth_rsp], ebp 10:47:13 call c_dummy 10:47:13 mov ebx,eax 10:47:14 mov esi,[forth_ip] 10:47:16 mov ebp,[forth_rsp] 10:47:20 next 10:47:26 nasm barfs on the "call c_dummy" 10:47:36 it doesnt know what that is. it cant. it doesnt exist till LINK time 10:47:42 how do i mark that as an external in nasm ? 10:48:12 nevermind i got it 10:48:13 "extern c_dummy" 10:48:16 iirc 10:48:17 Hehe, OK 10:48:32 rename the c function 10:49:49 ok i got it working in the kernel 10:49:56 let me see in the extended forth 10:51:26 hrm i SORTA got it working :/ 10:51:27 but not right. 10:51:57 your right. it works in the kernel but not in the extension. ill have to investigate thi 10:52:00 this 10:52:50 what happens during extension ? 10:53:28 i know what happens 10:53:32 lol 10:53:54 even tho c_dummy is linked to kernel.com it has NO knowledge of its existance 10:54:11 when you run the kernel and execute the forth dummy word it works 10:54:12 but 10:54:32 when you extend the kernel overwrites the linked c code with the code IT compiles 10:54:47 how is that possible ? 10:54:48 guaranteed to crash 10:55:25 you mean the code segment is over written ? 10:55:37 if you study the macros in macros.1 and the way they are used you will see that forth keeps track of where things are 10:55:51 krish everything in isforth is +rwx! 10:56:06 you HAVE to be able to write to code space. or variables wont work 10:56:17 this is a direct threaded forth. NOT indirect 10:56:56 anyway, the c code should not be thrashed ! 10:57:02 lol 10:57:40 nasm has NO knowledge of that c code 10:57:42 how about allocating a piece of memory to hold the code defns during extension ? 10:58:00 as far as the kernel knows code space ended where nasm wrote the last byte of code 10:58:21 ok. suppose I replace that C code with code written in asm in the same body as the code 'dummy' c_dummy' 10:58:24 will it work ? 10:58:55 yes. if nasm assembles it. it wont work if you assembled it external to the kernel build and then LINK it to the kernel 10:59:50 why ? 11:00:28 then the whole C linkage issue is infeasible. 11:00:32 because NASM is keeping track of where it finishes writing code. when the kernel runs it knows where its "list" space starts and ends and where its "head" space starts and ends 11:00:50 link something onto the end of list space and forth doesnt know anytihng about it 11:00:56 it will happilly overwrite it :) 11:01:05 you cant link 11:01:52 instead of using the code segment, is it possible to use a seperate chunk of memory to hold the forth defns ? 11:02:24 i specifically wanted code and data in the same pages 11:02:31 here is how a variable is constructed 11:02:35 some_var: 11:02:38 call dovariable 11:02:41 dd 0 11:02:52 the return address of the CALL is the body address of the variable 11:03:00 so its all +rwx 11:03:02 also 11:03:13 create creates a new word which is ALWAYS a variable 11:03:22 : constant create , ;uses doconstant ; 11:03:34 the ;uses patches the "call dovariable" to be a "doconstant" 11:04:12 hmmm 11:04:38 what about dynamic loading ? 11:04:58 meaning linking into .a files ? 11:05:05 not possible yet. its on the todo list 11:05:11 but its not a high priority yet 11:05:14 no runtime linking 11:05:21 yes. thats what i mean 11:05:33 dynamic linking to .so files etc 11:05:53 I actually wrote the asm code to interface with shared libs. 11:06:13 using the libdl library. 11:06:40 I has a rude awakening when linking the kernel. 11:06:46 there are issues with calling c functions from forth. c is totally fscked in the head if you ask me :/ 11:06:56 buries its own parameters under the return address 11:07:06 but it is possible - and planned for isforth 11:07:43 the dependency goes like this: libdl->libc->libm->libgcc - horrible. 11:07:59 ugh 11:08:14 thats what im striving to avoid, interdependancies between this that and the other 11:08:27 and 28469824 levels of indirection just to do some SIMPLE thing 11:08:50 burying the return address is not C's fault. - call and ret do that 11:09:14 interfacing to C is pretty simple. 11:09:17 no. its c's fault 11:09:24 it doesnt happen in forth 11:09:34 once I know how to open shared libs and get access to the symbols in the lib. 11:09:37 the designers of c had their head up their ass :/ 11:10:18 its not just C - just about every language (excepting forth) uses this mechanism 11:10:26 exactly 11:10:44 where is the return stack allocated ? 11:11:11 actually, i just changed the way that is done. i added code to isforth.asm to allocate a grows down buffer for the return stack 11:11:29 i might have to change this back tho because i think grows down memory mappings are a 2.4ism 11:11:40 and i dont want to restrict isforth to a 2.4.x kernel 11:11:43 and in the source, I found some comments on recursion which is unfair. 11:11:59 anything you can do WITH recursion you can do better without 11:12:03 recursion is the single most beautiful thing in comp.sci 11:12:20 ive never seen a single USEFUL thing done with recursion that could not be done smaller, faster and better without recursion 11:12:35 i would disagree. but you do see that i added the ability so that YOU can use it :) 11:12:50 have you tried a non recursive alpha-beta search ? 11:12:57 yes actually 11:13:06 doing an itterative tree search is simple 11:13:18 simple ? 11:13:21 yes 11:13:22 simple 11:13:28 maybe in forth - but certainly not in C 11:13:43 just keep a fifo of open nodes. any time you expand a node you remove it from the list and add its children to the list 11:13:49 --- part: flyfly left #forth 11:13:51 in ANY language 11:13:55 yes. 11:14:47 how long have you been coding forth btw ? - its good to see someone new in here who knows the language :) 11:15:14 3 days. 11:15:27 not yet coding though ... 11:15:32 you have been coding forth for 3 days ? 11:15:37 you code assembler and c ? 11:16:02 a bit of asm. but C/C++/ 11:16:12 btw look at the src/bench/fib.f file 11:16:13 and other languages. ... 11:16:22 too see a classic example of recursion verses itteration 11:16:45 the recursive fib function recurses on itself one hundred and thirteen MILLION times to calculate the 40th fib 11:16:52 it takes 6 minutes for it to do so 11:17:07 the itterative method calculates the 40th fib 90 MILLION times in 7 seconds 11:17:16 or something like that 11:17:24 actually i'm more interested in a real example - where the state to be saved is larger 11:17:42 you mean in say... an n^2-1 puzzle solver? 11:18:11 ive been working on one but its been on hold for a long time, i just wrote a memory manager for isforth and im going to fold the use of that into the code 11:18:20 alpha-beta perhaps ... 11:18:30 the proram will solve the 3x3, 4x4,5x5 and 6x6 puzzles 11:18:41 i have also long wanted to code a checkers game 11:19:13 i found a fantastic engine written by Bill Spitzak in the FLTK examples directory 11:19:23 that program is unbeatable. 11:19:27 a chekers game ? 11:19:33 you got a url ? 11:19:55 www.fltk.org - its a gui toolkit and the checkers program is a sample 11:19:58 fltk.sf.net 11:20:24 i would be interested in the checkers engine not the gtk stuff (for now :) 11:20:32 i want to have my own forth x toolkit eventually 11:21:05 ok. here we go: 11:21:48 cool :) 11:21:55 got it ? 11:22:28 yea 11:22:30 cool 11:22:35 ill check that out :) 11:23:05 and forthify it if possible 11:24:12 yea 11:24:22 it looks like an interesting project :) 11:24:45 i tried porting ian osgoods fcp to isforth but it keeps segfaulting, i need to fix that sometime too 11:25:16 does it use recursion ? 11:25:19 fcp 11:25:39 yes 11:26:01 thats not whats crashing it tho 11:26:11 :-) 11:27:45 fcp is a chess program converted from a c program for compilation with ans forth compilers 11:28:02 i am more opposed to ans forth than i am to c 11:28:12 and I did some work on tscp as well. 11:28:13 or possibly equally opposed 11:28:24 tscp is the code its based on 11:28:37 added a lot of positional evaluation stuff 11:28:50 unfortunately lost the work :-( 11:28:54 damn 11:29:02 i hate it when that happens :/ 11:29:19 redo it dood, you will be happier with the new code that you were with the stuff you loost 11:29:22 lost 11:29:29 the second time you code something its always better 11:30:02 actually i would prefer to write a new engine with bitboards etc. 11:30:14 tscp uses array based representation 11:30:22 crafty f.e uses bitboards 11:30:37 how good is bit twiddling support in forth ? 11:32:52 you have "and" "or" "xor" "not 11:32:54 " 11:32:55 etc 11:33:01 fast ? 11:33:16 you also have << (shift left) >> (shift right) and u>> (unsigned shift right) 11:33:18 not slow :) 11:33:27 code 'and', andd 11:33:30 pop eax 11:33:33 and ebx, eax 11:33:33 next 11:34:27 the nice thing in forth is you can return multiple values ... 11:34:36 yes. 11:34:43 you can return ANY number 11:34:48 limited only by stack space 11:35:06 just curious: 11:35:09 tho... anyone who pases 2856279 parameters or gets 298659782 values back is realy dumb heh 11:35:17 well.. if they do it alot they are 11:35:29 time to upgrade ... 11:35:30 if they have some very clever code that does it once then maybe they are realy clever :) 11:35:38 upgrade what? 11:35:46 to a wider architecture 11:35:54 heh i like x86 11:35:55 just curious: 11:36:08 how do you ppl start writing a forth word ? 11:36:21 : xyzzy ..... ; 11:36:30 you now have a word called xyzzy :) 11:36:33 come on ... 11:36:38 i know that. 11:36:40 give me an example 11:36:45 i know you know, i was being funny 11:36:49 a forth word to do what 11:36:59 the stack arrangement, etc 11:37:11 do you plan the entire word at one shot 11:37:12 ? 11:37:25 since locals are not available/recommended 11:37:33 ok. sometimes. sometimes it takes me 2 or 3 tries to decide on what words i actually need 11:37:42 you start with the overall problem 11:37:44 clever stack manipulation is required. 11:37:58 and decide what words might simplify the problem 11:38:08 when i read code, i actually found reading from right to left a bit easier ... 11:38:11 then you think what parameters would those words need and what would they return 11:38:24 read the comments then the code? 11:38:25 that works 11:38:37 if the author bothered to add comments 11:39:00 take a line - proceed from right to left ... 11:39:03 might be easier for you to follow a program if you start at the BOTTOM of the source file too 11:40:00 working on it ... 11:40:16 1 more thing: 11:41:07 when I run and quit isforth, the terminal starts to act weird - only a reset sets things right 11:41:28 erm that shouldnt happen 11:41:48 isforth has to mess with the terminal settings but it puts it all back when it quits 11:41:53 it happens everytime 11:41:58 what distro are you running and what terminal? 11:42:06 what kernel versionb ? 11:42:22 btw, i use framebuffer console @ 1024x768,16bpp 11:42:42 me too - but 800x600 11:42:45 Mandrake 8, 2.4.14 11:42:50 i use that sometimes. 11:43:03 hmm. in what way does it mess up ? 11:43:06 since I prefer to write code on the console, i use a large console. 11:43:20 screen not refreshed properly. 11:43:21