00:00:00 --- log: started forth/04.10.31 00:15:46 damnit. the ansi reference is down 00:15:54 can anyone tell me the rules on DOES> 00:16:03 can it only be used within a coldef? 00:16:12 that would make my next job a LOT easier ;) 00:16:19 the ansi ref is hosted at many locations 00:16:32 all mine seem to point towards one, the taygeta site 00:16:42 there 00:16:45 er 00:16:49 just google for dpans 00:16:55 true 00:16:59 but you could just as well tell me ;) 00:17:15 heh. look at googles theme :p 00:17:19 i believe that does> can be used from outside a colondef. you just end the doescode with a ; 00:17:28 oh so you do end with ; 00:17:29 cute 00:17:32 thats all i need really 00:17:32 :) 00:17:38 at least in gforth 00:17:44 i don't know what TEH ANS says 00:17:55 well i dont really care for ans specifically 00:18:03 just need a generalized idea of how 00:18:04 okies 00:18:16 ans or fig or whtever 00:19:55 nice. ans doesnt even show an example :\ 00:22:39 fig seems to do the same 00:22:45 i mean, in their example 00:22:50 : ... ... DOES> ... ; 00:23:09 guess i'll just go with the flow ;) 00:23:14 :) 00:26:04 I have a question about direct threading forths. I want to have words like find/' and execute. - 00:26:14 ok.. 00:26:24 and the problem is? 00:26:47 Right now my operators for my VM are written in asm, and I have .global opname .global opsize 00:27:22 The problem is I'm not sure how to go about adding a next to all words, so that when I do find followed by execute the return stack is filled properly by the call from execute. 00:28:09 I was thinking I could just have the code for next after each operator, but it would be after the opsize. Does that make sense? 00:29:14 not to me, but i'm not really an asm coder i'm afriad 00:29:24 Also, I'm wondering about how to implement the equivalent of r> when my code is generally inlined, and only when I do something like 'wordname find execute should it use r> to save the address for next. 00:29:42 if you find a word with tick or find, you get the XT, or cfa, or whatever you call it, of that word 00:30:03 if you pass that onto your CALL or EXECUTE word, it should do so... 00:30:57 yah, I'm just wondering about how to manage the return stack so that I can return properly and still have the direct threading work properly. 00:31:49 --- join: Serg[GPRS]_ (~z@193.201.231.126) joined #forth 00:32:00 I could use the idea of call label; label: to get the PC (as someone here told me ages ago), but I wonder if there's a better way. 00:32:04 the call word should take care of that 00:32:24 ok 00:32:34 lets see 00:33:07 the call word should pop his return address (from calling CALL) from the return stack, and push the TOS to there, then simply ret 00:33:20 the tos is the result by tick/find (the xt/cfa of the word) 00:34:17 so pop return stack, push tos to return stack, ret 00:37:02 hmm, so say I have : incr 1 + . 1 'incr find execute 00:37:50 thats not proper in any way :\ 00:37:54 err should be: : incr 1 + . 'incr find execute 00:38:02 My forth uses . instead of ; 00:38:06 oh 00:38:07 ok 00:38:14 and ' is a quote word, like in Lisp 00:38:22 or quote syntax rather 00:38:24 shorthand 00:38:25 denotations, aaaaaaaaah make it stop! 00:38:36 yeah i know what you mean 00:38:38 heh 00:38:50 worked with ciforth for a while, used denotations as well 00:39:13 ok, but in that case the example is proper... whats the problem? 00:40:02 find should o a lookup on the word, and return the address of the machine code for the word right? 00:40:33 i think so yes 00:41:05 although i'm not sure what its input is (of FIND specificly). but i guess thats implementation dependent (seeing how you use . for ; ;)) 00:41:57 i havent got a find in my forth (yet), because i use ' and (') for that 00:42:17 Then execute I guess would do something like moving the addr for the word into %eax and then call %eax right? And hopefully the next appended to all words would do ret ? 00:42:50 that i just dont know for sure. i know how the CALL word should work 00:42:56 like i said above 00:43:14 but i'm not quite sure whether (your) forth will pick up when simply calling the xt 00:46:53 Thanks for your help. :) 00:46:56 sure 00:48:32 Sonarman> is create an immediate? 00:48:38 no 00:48:44 i mean, if its supposed to be working with : create bla does> ; 00:48:52 hmm 00:50:25 oh wait 00:50:27 nvm 01:11:36 Robert> ehm. i think this is bad... 01:11:36 Block allocation table size: 1 01:11:36 Kernel size: 13 01:11:36 Core language sources size: -31 01:11:36 OK. 01:12:32 yep. its bad :( 01:17:50 but the question is... is it fixable? :) 01:30:38 --- part: Sonarman left #forth 01:33:25 --- join: Sonarman (~matt@adsl-67-113-235-102.dsl.snfc21.pacbell.net) joined #forth 01:33:40 --- quit: Sonarman (Client Quit) 01:33:54 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 01:37:00 hi I440r 01:37:03 hi 01:37:07 how's w/ isforth ? 01:37:28 well im waiting for my laptop to come back from being fixed so i can complete some edits i was doing 01:37:37 im like " <-- that close to THREE releases 01:37:56 isforth x86 linux, isforth ppc linux, isforth x86 fbsd 01:38:10 heh, nice ! 01:38:32 * Serg[GPRS]_ thinks of migrating to BSD coz of Linux versions split 01:38:46 trouble is i cant do devel on my desktop pc, im just tooooooo used to doing it on my laptop 01:40:22 hehe 01:40:35 * Serg[GPRS]_ is split between home and work desktops 01:40:46 i now rent a room, so see my home one rarely 01:42:28 * Serg[GPRS]_ is test-driving Photoshop CS 01:48:10 --- join: Raystm2 (Rastm2@ACAAC45C.ipt.aol.com) joined #forth 01:51:38 I440r: did u ever think of making 'do your forth' kit ? 01:52:10 ? 01:58:53 some text explainig overall idea, + some sources, so one can make basic decisions for himself 01:59:32 for example, i would make ultra-minimal forth - only the words needed for compiler, all other - into loadable extensions 01:10:00 not sure if i could do that 01:10:09 hehe ;) 01:10:43 i seen some, butt for x86 segmented mode - real suxx 01:16:39 :) 01:16:43 i prefer real mode 01:17:05 i think pmopde is a huge KLUDGE fix of a stupid design flaw 01:17:10 i.e. segmented memory 01:18:46 i would prefer flat memory CPU ;)) 01:18:49 what is pmopde 01:20:05 protected mode 01:20:39 oh 01:20:46 i kinda like segmented memory 01:29:35 I440r: would you prefer to yell A.OUT? before testing something? 01:30:35 The unix creators originally ran unix on a PDP without an MMU, so they would clobber each other during testing. So, they would yell A.OUT? to warn others to save. 01:31:10 Thats a funny story. 01:32:10 The entire story is here: http://cm.bell-labs.com/cm/cs/who/dmr/odd.html 01:35:30 ? 01:35:39 Hey 1440r: have you Had a chance to talk to TheBlueWizard lately. seems he's been asking for you when I've been on. but we both have missed you :) 01:36:28 err no not talked to him in about a week 01:36:33 ill keep an eye out for hiom 01:37:17 --- quit: Serg[GPRS]_ (Read error: 104 (Connection reset by peer)) 01:38:50 your welcome :) now I can tell him that I finally "saw" you :) 01:39:03 heh 01:39:35 How's the chat then 01:40:08 mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm- 01:40:56 OOPTS SORRY HEHE 01:41:15 was cleaning my kbd by inverting and shaking it 01:41:22 grr capslock too lol 01:42:06 hehe 02:59:49 Robert alive yet? :) 03:57:18 Yep 03:57:24 Sleep is good! 03:57:55 robert! 03:57:59 fix plz :( 03:58:36 Hm? 03:58:40 Oh 03:58:56 Any idea how THAT happend? 03:59:42 ehm. because of something you did? 03:59:47 Pffft 03:59:59 I mean, what did you do before this happend? 04:00:09 If you only modified core.f, what is the new size of it? 04:00:11 ehm. add code? 04:00:16 its now 34k 04:00:24 obviously a turnpoint from 32k to > 04:00:32 Hehe. 04:00:44 I'll make a quick check before I take my shower 04:01:25 btw, did you recompile this with another compiler? 04:01:53 (other than good old 32-bit gcc) 04:02:04 eh 04:02:07 i dont know 04:02:13 i'm using a batchfile i created a longlong time ago 04:02:26 mkdist kuf.bin boot.bin kernel.bin core.f 04:02:33 --- join: saon (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 04:02:33 thats yours 04:02:35 mkdist 04:03:16 Is that for Linux? 04:03:34 Didn't I compile this in a 16-bit Borland compiler? 04:04:25 Then it should be easy. Just replace all relevant ints with long ints. 04:05:05 i have nooooo idea. 04:05:15 its for windows 04:05:16 dos 04:05:17 w/e 04:05:26 OK, you have any 32-bit Windows C compiler? 04:06:19 eh 04:06:25 visual c 04:07:06 OK, try that then. Or do the changes I suggested and recompile with av 16-bit compiler. 04:07:20 OR, if you're _really_ lazy, wait until I got breakfast and a shower and I'll fix this. 04:10:21 * Raystm2 is eaves-droping and want's Robert to fix ne breakfast too :) 04:10:21 hello Robert and qFox :) 04:11:03 Hehe, morning, and brb :) 04:11:08 ok 05:00:46 --- quit: Raystm2 ("User pushed the X - because it's Xtra, baby") 05:09:45 --- join: crc_ (crc@165-pool1.ras11.nynyc-t.alerondial.net) joined #forth 05:10:13 --- nick: crc_ -> crc 05:12:23 Hi crc 05:12:30 Robert! ;) 05:12:33 FOX! 05:12:40 Did you fix it? 05:12:46 incapable 05:13:06 You lazy... 05:13:20 weak i am. 05:13:22 OK, OK, I'll do it. 05:13:32 yay :d 05:13:40 * Robert pets qFox with an axe. 05:13:50 i luuuuuvs teh axe 05:18:42 Hmm... 05:19:05 I think the boot loader might freak out on 64kB, so make sure you don't get there. ;) 05:20:12 :| 05:22:06 Hi Robert 05:23:42 qFox: robos.org/f/mkdist.exe 05:25:57 yay 05:25:57 :D 05:26:25 Tell me if it works 05:27:19 yep seems to be working. at least no negative counter... 05:27:30 might have fucked the disk though (last time) 05:27:43 Hehe 05:28:02 hm it formats. good 05:28:02 As in physically (no, not THAT physically) fucked your floppy, or just the disk image? 05:28:20 well, at some point, when i dont format, the disk will be unuseable 05:28:24 wont be able to format 05:28:26 or anything 05:28:33 but if i format in time, it'll be fine 05:28:45 Heh 05:28:59 "World's Scariest Ghosts caught on Tape" my god what a big pile of bullshit 05:29:09 its not even amusing :\ 05:29:51 Haha 05:30:01 Don't tell me you're watching that 05:30:12 hm. still the same behaviour (taking a long time to write) 05:30:32 having my doubts whether it will work, but gonna have to test on a "Fresh" disk before i can tell for sure :) 05:30:44 i WAS wathcing it, but after 10 minutes or so nothing changed so i stopped 05:30:46 You mean writing the disk image or writing it to the floppy? 05:30:56 flop 05:31:05 it works though 05:31:08 as in, it boots 05:31:11 Hrm, I can't see how a flawed mkdist would fuck up that part 05:31:12 Oh, cool 05:32:14 before it would write the image in a few seconds 05:32:19 now it takes 20 or 30 05:32:48 Odd. 05:32:53 yeh 05:32:53 Probably some bug remaining. 05:32:57 i guess 05:33:04 OK, OK, I'll recompile it with lcc 05:33:09 One minute.. 05:33:42 its not a BIG deal. it boots, thats what counts 05:34:08 Well, it feels like that program will start overwriting system memory any second 05:34:24 :p 05:34:49 it does appear as if he's writing a full floppy or something 05:35:10 ohwell. lets see whether my variable create does> and constant words function (as if, in one try, psh) 05:36:10 figures :) 05:40:55 Download the file again. 05:41:13 yessir 05:41:40 And this time it will WORK. 05:41:43 :D 05:41:47 yessir 05:41:50 Otherwise YOUR head will be rolling on the floor. 05:41:55 yessir 05:42:08 Another dimension of "ROFL" 05:44:46 my poor head :( 05:44:56 i'm sorry mr robert sir. same. 05:45:16 Grrrr 05:45:19 * Robert checks 05:45:40 btw, do you get the right sizeof()s? 05:45:50 you mean indication of source size? 05:46:02 oh wait 05:46:12 D:\download\forth\f\f-040714\f\bin>mkdist kuf.bin boot.bin kernel.bin core.f 05:46:12 sizeof(bootblock) = 1028, sizeof(mainblock) = 1024 05:46:12 Can not read 1kB from boot loader file. 05:46:13 Well, struct sizes 05:46:16 Hah 05:46:19 That's bad. :P 05:46:29 That's with the newest version? 05:46:34 indeed. he didnt do squat 05:46:42 i guess. hold on let me try a new disk 05:46:56 Hehe 05:47:02 I think I might have forgot rebuilding the lcc makefile 05:47:15 thats a bad thing, right? 05:47:15 ;) 05:47:38 either he wrote that VERY fast 05:47:39 or... 05:47:45 he's not writing anything. 05:47:51 the latter is the case 05:48:04 Ooops 05:48:12 I forgot to make it 32-bit again 05:49:08 OK, try again. 05:49:52 seemed to be fine 05:49:58 but still VERY short on writing so... 05:50:17 nope. not writing 05:50:28 but hold on, maybe its something else 05:50:31 fucked disk or /we 05:50:49 Wait a minute, is it mkdist or rawrite that takes longer now? 05:50:55 --- quit: crc ("Time for bed... Goodnight!") 05:51:01 rawwrite 05:51:18 Ah 05:51:20 but only after you supplied that new mkdist 05:51:26 Well, that isn't my fault. :P 05:51:29 Bleh 05:51:34 Sure the disk image didn't grow? 05:51:35 its not? 05:51:45 ehm i'm only modifying the source 05:51:49 core.f 05:51:52 nothing else 05:51:52 very sure 05:52:11 Yeah, but I mean the size of the finished disk image 05:52:11 Block allocation table size: 1 05:52:11 Kernel size: 13 05:52:11 Core language sources size: 33 05:52:13 What is it now? 05:52:29 huh 05:52:32 how the fuck 05:52:34 Just create a new, empty one. 05:52:37 the thing is 64mb??? 05:52:44 I think the buggy program made a HUGE disk image 05:52:45 well, 63.9mb 05:52:56 And now you're still working with it 05:52:57 perhaps 05:53:04 just any file is fine right? 05:53:08 any contents i mean 05:53:17 Yeah. Or no contents. :) 05:53:32 An empty file is probably the best 05:54:03 ok... 05:54:10 didnt seem to work 05:54:24 will try fresh disk 05:55:35 i think its not writing anything atm... 05:55:42 kuf.bin is now 50k 05:55:54 Sounds reasonable 05:56:27 rawwrite does access the disk (hear the sound) but very shortly and the disk is not bootable 05:56:39 Hrm. 05:56:56 hah 05:56:59 hold on ;) 05:57:24 fucking write protection 05:57:28 :p 05:57:42 --- quit: clog (^C) 05:57:42 --- log: stopped forth/04.10.31 05:57:50 --- log: started forth/04.10.31 05:57:50 --- join: clog (nef@bespin.org) joined #forth 05:57:50 --- topic: 'http://www.orangetide.com/forth/ -- Links about FORTH. I, for one, accept our new ianp overlord' 05:57:50 --- topic: set by slava on [Sun Oct 24 13:17:17 2004] 05:57:50 --- names: list (clog saon I440r qFox warpzero madwork__ imaginator Robert Stepan swsch_ oxygene Hyrax madgarden hefner jim fca I440r_ cmeme mur ASau @ChanServ @Herkamire skylan onetom @ianp) 05:57:59 i'd say perfect, but i'm sure i'll hit that 64k barier some time ;) 05:58:05 thanks alot 05:58:29 :D 05:58:40 I hope you do that _after_ G is released ;) 05:58:52 :D 05:59:17 yeah i think so. i wont add another 32k of source any time soon :p 05:59:24 whats the limit based on btw? 06:02:31 The 64kB one? 06:02:41 yewah 06:02:51 Well.. one segment is 64kB 06:02:58 I'll check the F boot loader 06:03:07 ah right 06:03:38 Yeah, 64kB will be a problem. But that could be fixed. 06:03:49 You know, you're not really supposed to put everything in core.f 06:04:06 You should let core.f load kuf.f or whatever. 06:04:16 i dont even HAVE a filesystem yet 06:04:30 Well, F "kind of" has one. 06:04:38 But you're probably right in not trying to use it 06:04:39 ehm. no. it doesnt ;) 06:04:44 Hehehe 06:05:03 i ripped out anything i didnt absolutely need, from core.f 06:05:11 with all due respect 06:05:12 :) 06:05:28 Ah, good boy. 06:05:36 I smell a healthy Forth spirit 06:05:56 you're taking up 2.6k in my source :p 06:08:36 yay 06:08:41 my create word seems to work :d 06:08:50 Congratulations ;)( 06:08:55 Tell me when does> works 06:09:25 thats the next in line to test, but that already put something on the stack when compiling (teh word itself) so its bugged :p 06:10:21 yep. at least the create word now works as i intended it to work :p 06:11:10 and maybe the does> word is good now as well as it depended on the create word (it wasnt returning to interpretation mode before) 06:12:12 pity :p 06:14:58 Hehe 06:15:55 * Robert makes some fixes in the new G boot loader. 06:16:04 Remember - it never had any size limits. NEVER. 06:16:09 :) 06:18:32 256kB block size limit should be enough, right? 06:18:39 i hope so 06:18:40 :) 06:19:08 If you ever need mor than that I'll personally rape you, murder you, and spray "bloatware supporter" on your grave. 06:20:34 thanks. 06:22:04 hm 06:22:11 i thought up this great construction for doeS> 06:22:23 except. its not really working. it ends up in an endless loop :( 06:22:28 or something that causes a hang 06:22:32 Heh :/ 06:28:09 hm. well the thought wasnt very bad, it just didnt work quite as i thought in practice 06:28:21 i just used : to create an empty word 06:28:42 then in that word i compiled the DFA as a literal (field that contains a pointer to the data) 06:28:59 once the coldef was done i backcompiled here to the dfa 06:29:07 this is how my create word works 06:29:16 (still does, functions correct) 06:29:27 does> however, is independent 06:30:14 so i added one extra empty cell at the end of the word for create 06:31:04 now i let does> read the last defined word from LATEST, fetch the dfa, and go one cell back. there it compiles a jump to here. it is asumed that does> is executed after the allotting of data 06:31:18 (although i think this shouldnt be a problem either way) 06:31:28 well 06:31:30 whatever 06:31:47 anyways. the problem is that i would need an additional ; to close the word 06:31:57 due to internal constructions 06:32:21 Hehe, the magic of does> :) 06:32:28 or else kuF would not know where the end of the word is 06:32:51 so now i'm thinking that create should simply copy its compiled list of stuff 06:32:55 or something... 06:33:34 but that will result in a very strange and complicated (looking) construction ;) 06:36:16 --- join: qF0x (C00K13S@82-169-140-229-mx.xdsl.tiscali.nl) joined #forth 06:37:52 --- quit: qFox (Read error: 104 (Connection reset by peer)) 06:41:13 --- nick: qF0x -> qFox 06:45:02 Did it crash your computer THAT bad? ;) 07:02:01 no it didnt crash this morning 07:02:14 it crashes once a day, almost always at the first bootup 07:02:40 Heh 07:02:54 it really does though 07:02:57 very odd 07:03:05 but its been doing that for over a year now 07:03:07 so whatever 07:05:11 :D 07:05:14 * Robert pets Windows 07:05:26 Hrm, I'm thinking about switching from NASM to FASM. 07:08:30 why would nasm have a problem with labels? I'm trying to create an elf-format object file to be linked with some C libs, and just potting a label in there causes it to segfault just before where the label is 07:09:01 brb 07:10:35 Heh. 07:12:51 --- quit: saon (Read error: 238 (Connection timed out)) 07:13:06 the same code too... put a label in, code dies. remove label, code runs. 07:13:27 Heh 07:13:35 (sorry, I'm getting repetative) 07:13:51 or repetetive 07:14:22 what platform do you run nasm/fasm on? 07:15:34 and we even tried creating with and without labels, and stripping each resulting executable... result was two identical files 07:16:59 I've been using NASM, so far. On DOS (16-bit), Windows (32-bit) and Linux. 07:17:34 on linux, do you -f elf? 07:20:12 Usually I'm using it to generate raw binaries, but sometimes I'm using ELF 07:20:40 can you run raw binaries in linux? 07:21:11 or, taken from another pov, what do you use raw binaries for? 07:21:45 Forth. :) 07:21:58 Using it for (among other things) my Forth system. 07:22:07 Which qFox has been struggling with for a while now. 07:33:46 hm? 07:34:22 struggle being the correct word there ;) 07:34:46 Hehe, exactly. 07:35:49 right 07:35:50