00:00:00 --- log: started forth/03.06.09 00:03:16 --- join: serg (Serg_Pengu@212.34.52.142) joined #forth 00:03:37 damn. power fell while cd-burning ;((( 00:13:33 --- join: segr_ghost (Serg_Pengu@212.34.52.142) joined #forth 00:13:55 hope it won't hang this time ;((( 00:14:42 --- quit: XeF4_ () 00:19:31 --- quit: Serg_Penguin (Killed (NickServ (Nickname Enforcement))) 00:20:21 --- quit: sifbot (Read error: 110 (Connection timed out)) 00:21:00 --- nick: segr_ghost -> Serg_Penguin 00:21:27 oooops 00:21:43 IRC really needs better mechanism to handle ghosts... 00:32:57 --- quit: serg (Read error: 110 (Connection timed out)) 01:00:36 z 01:03:14 --- quit: fridge (Read error: 104 (Connection reset by peer)) 01:03:16 --- join: fridge (~matt@dsl-203-33-160-107.NSW.netspace.net.au) joined #forth 01:08:25 yoh yoh 01:35:03 did one on NET ever attempted to design an _open_ , RFC'ed net paging protocol ? 01:48:54 Privet! 01:54:37 hi ! 01:54:43 * Serg_Penguin screws w/ MS VBA 01:54:48 it's a bogus ! 01:55:13 function dies of null argument, and i can't see call stack to trace the trubble !!! 01:55:24 Hehe. 01:55:29 Poor Serg :) 01:55:43 grep help 4 'call stack' - zero effect 01:56:27 and worse, it's syntax allows func call w/o parens !! 01:56:50 so if i chomped off string end somethere, it won't complain :(( 01:59:20 stupid, write-only language 02:36:56 z 02:37:03 i beaten it ! 03:28:32 --- join: mur (murr@baana-62-165-185-171.phnet.fi) joined #forth 03:33:49 hi 03:38:32 privet serjuska 03:56:17 --- join: tathi (~josh@pcp02123722pcs.milfrd01.pa.comcast.net) joined #forth 04:41:57 --- quit: a7r (Read error: 104 (Connection reset by peer)) 06:55:54 --- join: sifbot (~sifforth@h00a0c5e17756.ne.client2.attbi.com) joined #forth 06:55:54 Type sifbot: (or /msg sifbot to play in private) 07:02:29 --- join: futhin (futhin@dial-149.ocis.net) joined #forth 07:14:42 anyone awake 07:16:24 * Serg_Penguin is one-eye awake 07:19:48 * mur is tired but still awake 07:20:00 i think i can manage :) 07:21:30 you guys could get an account with an online stock broker and do some day trading at this time ;) 07:21:45 * futhin is following the market :P 07:22:37 buy large quantities of some idiot stock and it will raise and everyone just stare and wonder :) 07:23:44 nah, no idiocy 07:23:57 whole stock markets is idiocy :/ 07:24:29 mur: what is greed? is it greed when a person works hard and develops a product and markets that product and sells many products? 07:24:45 you're very anti-capitalistic.. 07:25:00 what you don't realize is that capitalism is the _only_ moral system :P 07:25:02 ugh afaik i didn't said anything related to that 07:25:16 but you must admit that a lot of money does not equal to hard work 07:25:17 yeah you did, yesterday your quit message said something about greed 07:25:24 eh?! 07:25:33 hard work that produces lots of money is fine.. 07:25:37 it was funny proverb 07:25:54 but hard work != lot of money 07:25:59 gtg bbl 07:26:59 market trading is NOT work 07:27:12 it's a casino 4 stupid greedy outsiders 07:27:18 heh 07:27:28 no, the market actually plays a key role in the economy 07:27:40 once i read wasted Financial Times 07:27:51 it's full of the word INSIDER 07:28:20 i mean playing on exchange rates or prices oscillations 07:29:04 here this ("FOREX") is advertised as agressively as fraud pyramids at 90-s 07:30:20 there are a lot of suckers, people who jumped in without learning how its done, so they get burned. does that make the market evil? 07:32:58 evil is doing something that is not good for society (many people) 07:33:12 no 07:33:23 evil is coercing someone 07:33:30 coercing ? 07:33:45 evil is stealing money from a man (the government stealing money from a man) 07:33:54 coercion = force 07:37:14 --- quit: futhin ("Leaving") 07:39:28 back 08:16:37 --- join: hovil (~matt@CommSecureAustPtyLtd.sb1.optus.net.au) joined #forth 08:45:29 --- quit: Serg_Penguin () 09:18:46 --- join: XeF4_ (Vatteluttu@12-245-108-157.client.attbi.com) joined #forth 09:26:23 --- join: PoppaVic (~pfv@s71.waters.gtlakes.com) joined #forth 09:35:23 --- quit: XeF4 (Read error: 110 (Connection timed out)) 09:38:57 --- part: PoppaVic left #forth 10:14:35 --- quit: tathi (""(reasons, bah!)"") 10:37:07 --- join: XeF4 (~XeF4@in-vitro228.gprs.suomen2g.fi) joined #forth 10:53:30 --- join: a7r (~a7r@206.72.82.135) joined #forth 11:19:54 'lo 11:21:00 Hi a7r 11:21:29 --- quit: XeF4 ("en koskaan osta kirvestä. enkä koskaan viinaa juo") 11:21:37 sup Robert? 11:34:47 Not doing much. :) 11:35:15 --- quit: mur (Read error: 60 (Operation timed out)) 11:44:36 --- join: mur (murr@baana-62-165-185-171.phnet.fi) joined #forth 12:22:09 --- nick: hovil -> matt___ 12:25:03 --- nick: matt___ -> hovil 12:25:12 --- nick: hovil -> matt___ 12:26:18 --- nick: matt___ -> hovil 12:37:07 --- quit: a7r (Read error: 110 (Connection timed out)) 12:39:47 --- join: a7r (~a7r@206.72.82.135) joined #forth 13:18:13 --- join: wossname (wossname@HSE-QuebecCity-ppp81002.qc.sympatico.ca) joined #forth 14:43:38 --- quit: wossname ("^__- addict") 14:46:58 --- quit: a7r (Read error: 110 (Connection timed out)) 15:05:05 --- quit: hovil ("http://lice.codehack.com") 15:52:05 --- quit: mur ("MURR!") 16:47:19 --- join: a7r (~a7r@206.72.82.135) joined #forth 16:49:23 Hi a7r. 17:25:24 --- quit: fridge ("http://lice.codehack.com") 17:37:05 --- quit: paxl (asimov.freenode.net irc.freenode.net) 17:37:05 --- quit: cleverdra (asimov.freenode.net irc.freenode.net) 17:37:05 --- quit: ianni (asimov.freenode.net irc.freenode.net) 17:37:06 --- quit: ChanServ (asimov.freenode.net irc.freenode.net) 17:37:06 --- quit: TreyB (asimov.freenode.net irc.freenode.net) 17:37:06 --- quit: Fractal (asimov.freenode.net irc.freenode.net) 17:37:06 --- quit: a7r (asimov.freenode.net irc.freenode.net) 17:37:45 --- join: ChanServ (ChanServ@services.) joined #forth 17:37:45 --- join: a7r (~a7r@206.72.82.135) joined #forth 17:37:45 --- join: Fractal (kter@i.either.got.mad.cow.from.alberta.beef.or.strongLSD.com) joined #forth 17:37:45 --- join: ianni (ian@inpuj.net) joined #forth 17:37:45 --- join: paxl (paxl@modemcable110.168-130-66.que.mc.videotron.ca) joined #forth 17:37:45 --- join: cleverdra (nailuj@ACC6186F.ipt.aol.com) joined #forth 17:37:45 --- join: TreyB (~Trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 17:37:45 --- mode: asimov.freenode.net set +o ChanServ 17:45:39 --- quit: a7r (Read error: 113 (No route to host)) 18:45:58 --- join: XeF4 (~XeF4@62.78.121.228) joined #forth 18:55:49 --- join: Calm (~Calm@24.65.137.230) joined #forth 18:58:26 Hi 18:58:44 Hello. 19:08:42 --- quit: Calm () 19:33:18 --- quit: XeF4 ("pois") 19:44:04 --- nick: TreyB -> Trey 19:44:09 --- nick: Trey -> TreyB 20:59:38 --- quit: Fractal (Read error: 104 (Connection reset by peer)) 21:11:28 --- join: Fractal (tetkvel@i.either.got.mad.cow.from.alberta.beef.or.strongLSD.com) joined #forth 22:19:24 --- join: Serg_Penguin (Serg_Pengu@212.34.52.142) joined #forth 22:20:06 hi 22:27:40 --- join: kc5tja (~kc5tja@ip68-8-206-137.sd.sd.cox.net) joined #forth 22:27:41 --- mode: ChanServ set +o kc5tja 22:28:48 re 22:29:06 --- quit: Fractal (Read error: 104 (Connection reset by peer)) 22:30:14 * kc5tja just spent pretty much all day at a potential software development customer's site, only to be sent e-mail just a few minutes ago that, "We don't think we can afford to pay professional software development individuals, complete with process and all." Huh?! Why the bloody hell did you call me then?! 22:30:23 * kc5tja shakes his head. "Morons." 22:31:51 hi 22:34:12 --- join: Fractal (dkhmp@i.either.got.mad.cow.from.alberta.beef.or.strongLSD.com) joined #forth 22:36:09 Serg_Penguin: I got FS/Forth's compiler implemented. Time permitting this week, I'll be working on its ability to load source code from block storage. 22:37:50 cool ! 22:38:04 i definitely will try 22:38:11 Since it's running on top of DOS, why not use the (technically superior to blocks) DOS filesystem? 22:39:01 --- join: fridge (~matt@dsl-203-33-160-107.NSW.netspace.net.au) joined #forth 22:39:14 Fractal: Because "superior" is relative. 22:39:35 For one, with files, each line of source code is variable length. 22:39:54 This means that the end of the buffer may contain incomplete lines; the parser has to be able to handle this condition. 22:39:58 This is not trivial code. 22:40:15 Second, blocks permit easy switching to shadow blocks for documentation purposes. 22:40:49 Third, blocks are faster -- faster to use, faster to cache, and faster to write software for. 22:41:02 kc5tja : No, not necessarily. You could simply allocate 1024 byte DOS files. For a tiny bit of overhead you can take advantage of relocatability and such 22:41:20 Relocatability of what? 22:42:02 Besides, 1024-byte DOS files will severely fragment my harddrive, as my cluster size is 4096 bytes. 22:42:06 Well, of the files... Hardcoding block numbers into forth code is generally a bad idea 22:42:31 . . . 22:42:36 Fractal: blocks are not HDD sectors, but block file a top of DOS ! 22:42:49 * cleverdra carefully re-reads that, to make sure that he isn't actually reading Fractal as suggesting that kc5 use 1024 DOS files instead of blocks so that somebody, somewhere, will be spared the effort of doing something that will need to be done anyway, SFAHCT. 22:43:01 Serg_Penguin : Exactly. That's what I'm suggesting 22:43:18 Well . . . yes. 22:43:21 That's what I am doing. 22:43:32 A single file contains a multitude of blocks. 22:44:02 Well that's the same idea 22:44:21 Goodness, I would never access the harddrive directly while running under DOS. :) 22:44:23 That's suicide. :) 22:45:03 Although, the bare implementation of FS/Forth will access its boot-up volume as directly as possible. 22:45:06 --- join: a7r (~a7r@206.72.82.135) joined #forth 22:45:07 brb -- more business stuff. 22:45:16 A much better solution. Relocatability, despite what the vocal chuck moorish minority says, is a good thing. Not to mention being able to interact with the files from the underlying OS... 22:45:30 hola 22:47:00 Fractal - I get the feeling that you're really talking to yourself. 22:47:53 cleverdra : That sometimes happens when you don't listen... 22:48:21 * Serg_Penguin would run something w/ direct access only on a scratch monkey HDD, and unplug the main one first 22:49:31 Serg_Penguin : Agreed... Accessing the floppy drive directly would probably be OK... Depending on what kc5's plans are for his forth... 22:49:53 back 22:50:14 Fractal: I still, truely, honestly, 100% do not know what you mean by relocatability. 22:50:53 As far as my plans for FS/Forth, well, that depends on context. 22:51:00 I have several plans for it. 22:51:14 On the one hand, I will be implementing a version of it to run under the Linux environment. 22:51:29 On the other hand, I will be implementing yet another version of it to run without any host operating system at all. 22:52:00 The bare-hardware FS/Forth will hopefully replace Linux as my desktop OS of choice. 22:52:37 kc5tja : Well, OK... Like have you ever read legacy forth code in, for instance, byte magazine and such? They generally gave a long listing of screens of forth code with block numbers hardcoded in. This makes forth's potential for reusable words very difficult to achieve... Similar to relocatable machine code, really. Imagine if assemblers were only capable of directly linking your ASM code into an executable. 22:52:49 I'm sick of fidgeting with Linux's seemingly infinite and patently incoherent configuration files, inadequate dependency management between large and often way overkill applications and servers, etc. 22:53:02 Not to say that it wasn't possible to write screens of forth that were relocatable, it could be if you didn't hardcode offsets and such... 22:54:29 * kc5tja rarely hardcodes offsets in his screens. 22:54:57 I arrange my source code in a tree structure -- an application consists of one root-level block, which LOADs sub-blocks as required. 22:55:46 The only exception to this is when the whole application, plus dependencies listed in the LOADs, fit on one block. 22:56:04 Which is going to be pretty rare for any reasonable sized application. 22:56:45 Even in Chuck's code, you'll often see the main block prefixed with a set of LOAD statements, followed by some relatively high-level code. 22:57:04 Yes, that's a sensible way of coding. :) 22:57:32 However, I understand your concern a lot better now. I've often thought of this problem. For example, when translating the FS/Forth target compiler to FS/Forth itself, it will have to be block-moved, and all the LOADs renumbered. But since all LOADs appear in one block, it is not that much of an issue. 22:58:20 What threading mechanism are you using? 22:58:34 would i make standalone Forth, i'll make filesystem first ;) 22:58:38 Er, to change the subject... :) 22:58:44 Where blocks do become inadequate is when downloading information from the network whose size is unknown ahead of time. I will be implementing micro-filesystems for those cases (or, if running hosted, use the host OS's file services natively). 22:59:34 Fractal: I'm using subroutine threading; the compiler is non-optimizing, though, so it's producing some really lack-luster code right now. 22:59:46 But it works and is correct, which is my priority. 22:59:56 16-bit x86 is not conducive to native code production. :) 23:00:17 But I'm having fun with it all the same. 23:00:27 32-bit versions of FS/Forth will produce substantially more optimized code. 23:01:39 Yeah, optimizing forth code is one of the few areas of forth research that is still active... Very interesting field although I haven't looked into it much... 23:02:03 Well, I was just going to do the obvious, peephole optimization techniques. 23:02:08 I'll bet the postscript community could offer the forth community a lot in this regard 23:02:13 I'm not looking for uber-fast code, just "rational" code. :) 23:02:44 Right.. Like making dup compile a push instruction if you're in compile mode? 23:03:19 If you choose to use the ESP register to point to the (second) top of data stack, yes. 23:03:29 Which is something I've been considering for the 32-bit environment, actually. 23:03:36 Using EBP to point to the return stack. 23:03:47 Well, yeah, or whatever the equivalent machine code for your implementation is 23:04:04 The only thing is, colon definitions will need prolog/epilog code to >R and R> as necessary. 23:04:37 I think I read once that the data stack is accessed slightly more often than the return stack - not to mention the great simplification of most code words... 23:04:48 Yeah, tell me about it. 23:05:00 I made the mistake of letting SP point to the return stack in my DOS Forth. 23:05:10 As a result, all my data stack manipulations are framed by XCHG BP,SP instructions. 23:05:16 :) 23:05:35 So you see a lot of XCHG BP,SP; XCHG BP,SP pairs in the generated code (just one example of how dumb my current compiler is). 23:06:02 Actually, I wrote a forth for the z80 for my TI calculator and switched my mind to this about half way through... 23:07:17 --- quit: Serg_Penguin (Read error: 104 (Connection reset by peer)) 23:07:22 But, even if I do not use ESP to refer to the data stack, I can still break instructions down, at the cost of code space requirements, without losing any speed. 23:07:23 So I notice on your site you're planning on implementing FORGET soon 23:07:43 After I implement the ability to load source from blocks, yes. 23:07:50 Isn't that trivial in your implementation? Just a matter of modifying the dictionary pointer? 23:08:05 Or are you going to be using a different FORGET? 23:08:08 My idea is to off-load as much as humanly possible into block source (including FORGET implementation). 23:08:24 Well, my implementation is different, but the premise is the same. 23:08:55 I'll actually be using the word EMPTY to actually empty the dictionary to the last REMEMBERed point. FORGET forgets about the last REMEMBER point, restoring the one previous. 23:09:04 But I'm still kind of waffling on this. 23:09:19 --- join: Serg_Penguin (Serg_Pengu@212.34.52.142) joined #forth 23:09:25 Oh, oh I see what you're saying 23:09:28 I want a system that is natural and easy to use, because I'll be swapping overlays in and out of the dictionary quite often. 23:09:47 * Serg_Penguin is sick of power hits 23:09:58 Serg_Penguin: :( 23:10:01 Generally how I do this is have FORGET defined like, for instance, : forget find dict-pointer ! ; 23:10:32 So to do what you're talking about you'd do like, : marker ; some stuff here... forget marker 23:10:51 That won't work because you also need to update your vocabulary pointers (e.g., the word just before the forgotten word becomes the new "last defined word", etc). 23:11:04 I support two dictionaries, so that becomes an issue for me. 23:11:09 I have to walk the lists. 23:11:35 The 32-bit version of FS/Forth will use parallel arrays instead of linked lists to store dictionary linkage information, so it'll actually be quite a bit easier to do. 23:11:52 I don't use parallel arrays in the DOS version because of memory constraints. 23:11:57 Parallel arrays? 23:12:08 I can illustrate in C: 23:12:25 void *cfa[ MAX_DICT_SIZE ]; 23:12:34 char *nfa[ MAX_DICT_SIZE ]; 23:12:40 void *pfa[ MAX_DICT_SIZE ]; 23:12:50 int nameLengths[ MAX_DICT_SIZE ]; 23:12:55 Oh, gotcha... 23:13:26 ColorForth is astonishingly limited in this regard. 23:13:49 It supports only 128 compiler words in addition to what comes "standard" in the kernel, and 512 normal words. 23:14:38 The use of arrays in this manner should also be substantially faster to search too, because the data locality can reduce cache thrashing. 23:15:55 Yeah, I hadn't thought of that... It might... 23:16:13 My current dictionary system is based on Pygmy Forth's system, which is dog slow. 23:16:25 It compiles the whopping 6K of FS/Forth in, oh, around 15 seconds. 23:16:26 :( 23:16:49 Of course I almost always count dictionary search time as negligible since it is only signifigant during compilation... 23:17:07 Hmmmm 23:17:16 That is pretty poor :( 23:17:30 Well, as I indicated earlier, FS/Forth is designed to run lots and lots and lots of *tiny* applications. Switching applications literally causes the new application to be recompiled when you switch to it. 23:18:25 Er... why not just keep them compiled in memory? 23:18:26 I'm kicking around the idea of writing a web server in FS/Forth for use in some proprietary hardware solutions I'd like to sell my customers. 23:18:50 Fractal: One, very important, reason is you lose Forth's interactivity advantages. 23:19:04 When I make a change to a program, it ought to be as instantaneous a change as possible. 23:19:26 If I have to manually "FORGET" the application I'm using to reload it, then the interaction is greatly diminished. 23:19:46 Another reason is it significantly reduces the need for implementing memory management words like ALLOCATE and FREE. 23:20:16 By using the dictionary to store intermediate data via , and C, , the next time an application is loaded, that memory is automatically freed. 23:20:36 My usage scenario was going to be this: 23:21:15 for those applications that are always running (servers, e-mail client, network drivers, etc), they're loaded in a group, which remains resident until explicitly unloaded. 23:21:39 However, the user interfaces for these tools are written as small, well-factored applications that get "swapped out" when no longer needed. 23:22:12 Interestingly enough, there are only a few applications that will ever be running in the background. Most applications are really user-interface front-ends to data sitting on disk. 23:22:50 Applications are structured very differently in a typical Forth environment. 23:22:59 Consider a hypothetical web client. 23:23:10 To run it, the user just types WEB at the OK prompt. 23:23:37 This brings up the browser, which displays exactly what was being viewed the last time the user quit. 23:24:05 It can do this because block storage approximates orthogonal persistence to a very high degree of fidelity (even though it isn't orthogonal by any means). 23:24:23 The user hits, say, CTRL-G to go to a new URL. 23:24:51 nah, let's give this user a VI-like interface. The user hits 'g'. 23:25:08 The web program is EMPTied by the block responsible for handling the CTRL-G, and the new user interface is displayed, asking the user for the URL. 23:25:46 When the URL is entered, yet another block is loaded, which is responsible for actually acquiring the relavent content. 23:26:37 When that's done, the web server's overlay manager will reload its user interface code, which will render the display with the newly fetched content. 23:26:50 I see... Compilation really will be %100 performance critical with this system... 23:27:07 Yes. 23:27:41 It also eliminates the need (to a large extent) for supporting VOCABULARY and friends. 23:27:58 If your code is constantly being swapped in and out on an as-needed basis, there's little chance for name clashes. 23:28:40 To me it sounds like a signifigant performance penalty to pay for the questionable benefit of interactivity, but of course I haven't seen this working so I'm in no position to judge... 23:29:11 * kc5tja has had the chance to use XcolorForth (the ColorForth ported to X11), and its performance in switching between applications is mind-blowing. 23:29:17 Yeah, I'm not a big fan of forth vocabularies... I think they were a cheap hack to achieve proper namespacing 23:29:19 I never see the harddrive light blink. 23:29:41 The "multitasking" forth implementations were much better 23:29:55 Of course, ColorForth reads in its entire memory image and blocks all come from RAM, but I digress. 23:30:01 Where each task maintains a completely separate dictionary and stack pair 23:30:11 It sounds as if kc5 is describing a multitasking Forth. 23:30:14 (but shares the reentrant system dictionary) 23:30:36 Yes, it's multitasking. But, I was expecting to share the dictionary. 23:31:02 However, FS/Forth *does* support multiple word-lists; it's just that only FORTH and COMPILER have significance to the interpreter and compiler. 23:31:37 So I can create multiple "vocabularies" if I want. I just have to manage them explicitly. 23:32:27 Yes, well vocabularies can be trivially implemented on any ANS forth system... That's probably why they're so popular... 23:32:40 My Forth isn't an ANS system. 23:32:47 Has never been. Nor will it ever be. 23:32:49 why not just write yet another UNIX in Forth ? 23:32:59 traditional m/tasking... 23:33:12 Serg_Penguin: I do have plans to write my own exokernel in Forth, which will in turn, let me finish my Dolphin project. 23:33:24 and let the apps be written in whatever author wants, even C 23:35:04 Well, now that I've so thoroughly turned people off from using FS/Forth, . . . :) 23:35:13 Probably because there's no need for one... We already have decent implementations of unix kernels in C along with quality C compilers... 23:36:02 kc5tja : Why the hostility towards putting the ANS name on your compiler? 23:36:20 ANS is a *very* permissible standard - odds are your system is already near ANS compliance 23:37:01 Because ANS puts an excessive burden on me as a systems implementor. 23:37:24 For example, I do not support WORD or PARSE. 23:37:43 I replaced WORD with ParseWord, which is simpler to use, and more robust. 23:38:14 PARSE's behavior is easily added outside the kernel. 23:38:18 WORD can be emulated. 23:38:23 If your forth system is flexible and (at least slightly) resembles conventional forth APIs, it should be trivial to create WORD and PARSE wrappers 23:38:54 >IN isn't supported. 23:38:59 Nor can it be emulated. 23:39:00 Well ANS doesn't mandate that WORD and PARSE (or anything for that matter) exist inside the kernel, whatever that may be 23:39:46 No, but it does mandate that they somehow do exist. 23:40:03 I can come close to ANS compatibility, but anything that manipulates >IN is wholesale incompatible with FS/Forth. 23:40:29 SOURCE-ID can't be emulated either -- not without hacking the FS/Forth kernel itself. 23:41:03 SOURCE-ID isn't required by ANS 23:41:19 I sometimes see it in ANS Forth source code though. 23:41:34 >IN *is* required by the Forth environment, though, IIRC. 23:41:54 Well you might see it in ANS code that uses the CORE-EXT wordset 23:42:09 So it's conceivable that one can create a proper subset of ANS for FS/Forth; but it can't become 100% compatible without changing the kernel itself. 23:42:21 And I highly doubt that >IN couldn't be implemented 23:42:27 I'm absolutely positive. 23:42:31 >IN is defined as a VARIABLE. 23:42:36 Or a word which returns an address to one. 23:42:44 Yes... 23:42:46 It contains a zero-based offset into the current input buffer. 23:42:59 My parser uses actual addresses, not offsets into buffers. 23:43:09 * cleverdra puzzles at 'zero-based offset'. 23:44:03 Fractal: So, if you wanted to port code which uses >IN to FS/Forth, you'd have to create a compatibility layer which handles the offset problem. 23:44:05 For example: 23:44:16 : >IN@ ParseAddress @ ParseBuffer @ - ; 23:44:26 : >IN! ParseBuffer @ + ParseAddress ! ; 23:44:28 or some such. 23:45:31 Well, OK, it IS possible to emulate >IN. 23:45:40 You need to enable paging, and set up a page fault handler to do it though. :) 23:46:12 Set the address that >IN returns to a read-only page, so that any write will let the environment detect a write to it, and adjust ParseAddress accordingly. 23:46:23 kc5tja : >IN is essentially used to enable an application to know (and modify - with limitations) what is currently being parsed afaik 23:46:57 Fractal: Yes. But that doesn't change anything. It still cannot be emulated without the assistance of the CPU's MMU. 23:47:35 I'm not familiar with your forth implementation, but I would imagine as long as you parse words in a sequential manner that such a general specification could fairly easily be applied to your forth 23:47:59 Well, I already said . . . 23:48:14 My Forth does not use offsets into buffers -- it uses honest-to-goodness real addresses. 23:48:26 ParseAddress is a variable that contains the actual address of the next character in the input stream. 23:48:36 It does not contain an offset into the buffer. 23:48:59 ParseBuffer points to the beginning of the buffer, and ParseLimit contains the address of the last byte, plus one. 23:49:01 So when your forth accepts a line of input into memory, how does it know where to put it? 23:49:08 I tell it. 23:49:17 CREATE inputBuffer 85 ALLOT 23:49:23 . . . 23:49:42 CREATE TIB 3 CELLS ALLOT 23:49:45 . . . 23:49:53 So, in fact, your ParseAddress returns an address pointing inside inputBuffer ? 23:49:57 inputBuffer 0 85 TIB Buffer! 23:50:02 Yes 23:50:50 So why can't you define >IN as something like : >IN ParseAddress inputBuffer - ; 23:50:50 ? 23:51:18 Because ParseAddress is a variable. Executing it returns the address of ParseAddress. You must then @ to get the address it's pointing to. 23:51:42 Excuse me: : >IN ParseAddress @ inputBuffer - ; 23:51:52 Still, even so, >IN is defined to return an address of a variable which contains the offset in the current input buffer. 23:52:17 >IN, according to your definition above, returns NOT the address of a variable containing the offset, but rather the offset itself. 23:53:51 Well you get my drift, don't you? It could be: variable someHiddenVar : >IN ParseAddress @ inputBuffer - someHiddenVar ! someHiddenVar ; 23:54:13 OK, but now you have code which changes the contents of >IN. 23:54:25 How does it get communicated back to ParseAddress? 23:54:46 You pretty much have to redefine ! to constantly check the current value of >IN. 23:55:59 I'm not saying it's impossible to port between ANS and non-ANS systems. I do that all the time; I've *never* had any problems porting GForth code to PygmyForth and vice-versa. 23:56:08 But why can't ParseAddress depend on someHiddenVar ? 23:56:10 (Pygmy is a dialect of cmForth, quite patently NOT ANS). 23:56:28 Because it's already defined in the dictionary, long before >IN ever gets defined. 23:56:37 (and, by extension, someHiddenVar) 23:57:06 Like I said, to support >IN, you have to change the kernel of FS/Forth. 23:57:14 Er... Well why can't you make a someHiddenVar when you define ParseAddress and have >IN use that instead? 23:57:23 Well, OK, I see what you mean I suppose 23:59:51 Hardly a signifigant change, though 23:59:51 Surely you're not anti ANS because of one simple word that doesn't fit into your forth's design at the moment... ? 23:59:59 --- log: ended forth/03.06.09