2024-12-20 01:42:42 You don't remember how they got there? 2024-12-20 10:10:50 GreaseMonkey: Yeah never know what the kernel will look like 2024-12-20 10:11:01 What's easy on one arch isn't on another, or also what's standard in one forth might not be standard in another 2024-12-20 10:13:16 zelgomer: And if you have exceptions then ABORT is -1 THROW 2024-12-20 10:13:29 And an uncaught exception basically clears data and return stack 2024-12-20 10:14:15 I do actually like exceptions although R> DROP et al is cleaner 2024-12-20 11:23:41 is there a simpler way to do something similar to C's switch() than nested if's? 2024-12-20 11:34:12 There's the ANS Forth CASE .. OF .. ENDOF .. ENDCASE 2024-12-20 11:35:09 e.g. : WHITESPACE? ( c -- flag ) CASE BL OF TRUE ENDOF 10 OF TRUE ENDOF DROP FALSE ENDCASE ; 2024-12-20 11:36:06 The OF compares top two stack items, and skips to after ENDOF and leaves the lower item on stack if they're not same 2024-12-20 11:36:22 And ENDOF obviously skips to after ENDCASE 2024-12-20 11:36:31 ENDCASE just does nothing I think 2024-12-20 11:36:53 At compile-time it's used to link the jumps, rather, but at runtime it's a no-op 2024-12-20 11:37:31 Likewise I think CASE is a no-op at runtime, at compile-time it prepares the stack for processing OF/ENDOF/ENDCASE 2024-12-20 11:39:55 Oh apparently ENDCASE drops one item 2024-12-20 11:39:59 at runtime 2024-12-20 11:40:22 So I guess instead of DROP FALSE I need FALSE SWAP 2024-12-20 11:40:52 I find that unsatisfactory honestly, but I admit in the simple case you want to 'do nothing' on 'default' then that would be shorter 2024-12-20 12:00:09 ok so I guess in Forth-79 there's no other way 2024-12-20 12:12:30 pgimeno: R> DROP EXIT and BEGIN WHILE WHILE WHILE ... REPEAT ... THEN THEN are two things you could try 2024-12-20 12:13:45 Roughly what sort of code needs refactoring? 2024-12-20 12:14:41 I am porting a BASIC program for the ZX81 to the Jupiter ACE, it uses something like IF K$="1" THEN... IF K$="2" THEN... 2024-12-20 12:15:34 if translated literally, it would just be non-nested IF's 2024-12-20 12:16:05 Are the codes all within a contiguous range? 2024-12-20 12:16:07 I just wanted to know if there was something more general that I could also use in future 2024-12-20 12:16:43 yes, in this case they are, but I'd really prefer if there's no ASCII value tricks (jump table or the like) 2024-12-20 12:17:41 there's another case where it's a choice between "L", "R" and "T" 2024-12-20 12:17:43 I think especially as the original is all IF .. THEN .. IF .. THEN .. I would probably stick to that in Forth too, initially 2024-12-20 12:18:52 That's how I tend to port code, first manage to translate it literally and have it run, and then worry about making it idiomatic 2024-12-20 12:19:56 I like the R> DROP EXIT idea if it does what I think, I assume it does an "early return from word", is that so? I don't understand how the return stack changes and I don't even fully understand EXIT 2024-12-20 12:20:23 Assuming nothing else is on return stack, it returns from an inner word to the outer word 2024-12-20 12:20:41 So it's a good way to get a string of calls to all 'go' to one place when they're done 2024-12-20 12:21:51 so I guess one way is to define a word e.g. : CHOICE IF EXIT THEN IF EXIT THEN ... ; 2024-12-20 12:23:11 : WORD1 COND1? IF R> DROP EXIT THEN ; ... : ALL WORD1 WORD2 WORD3 ; : TOP ALL COMMON-END ; 2024-12-20 12:23:28 In the above COMMON-END is executed straight after calling EXIT in WORD1 2024-12-20 12:23:59 ah I see 2024-12-20 12:24:30 That CHOICE suggestion is another way to go, yeah 2024-12-20 12:25:07 I think CHOICE as you defined it makes more sense here, but the R> DROP EXIT suggestion is more flexible than that one example I gave 2024-12-20 12:25:34 It's better to think of R> DROP EXIT as being a bit like a longjmp, so there's more ways to use/abuse that technique 2024-12-20 12:25:58 It's quite helpful where e.g. 'exceptions' would usually be helpful, in parsing etc, where an 'early exit' is necessary 2024-12-20 12:26:24 I understand, thank you very much 2024-12-20 12:26:31 No problem 2024-12-20 14:18:16 I think I'd like to support PREBLOCK to asynchronously load a block 2024-12-20 14:18:47 I.e. you use n PREBLOCK to async read block n into a buffer, if it's not already loaded 2024-12-20 14:19:00 And then a later n BLOCK will wait until it's actually loaded, if not already 2024-12-20 14:19:23 Maybe n BUFFER will cancel a load in progress 2024-12-20 14:20:13 The nice thing about this is you can define PREBLOCK as DROP on systems that don't support async I/O 2024-12-20 14:21:26 This could potentially speed up I/O significantly in some cases, mostly baremetal or if the access pattern appears random to the OS/controller 2024-12-20 14:22:48 And obviously using PREBLOCK can invalidate buffers 2024-12-20 14:22:57 at the time of calling 2024-12-20 14:54:19 what are you going to do in the meantime? 2024-12-20 15:06:43 I'm alternating between writing pieces of a forth system and designing a forth OS 2024-12-20 15:06:57 And keeping as much of the 'OS' able to run under a host as possible 2024-12-20 15:11:01 no i mean between n PREBLOCK and n BLOCK what would you do in the meantime to take advantage of it? 2024-12-20 15:11:37 Work on a different block 2024-12-20 15:13:00 "work" means parsing? 2024-12-20 15:13:13 Or anything 2024-12-20 15:13:19 It saves time if I load a block in advance of when I need the data to actually be ready in RAM 2024-12-20 15:14:19 As long as I know in advance of when I need it which block I will need 2024-12-20 15:14:42 Quite often this is true, e.g. when sorting data 2024-12-20 15:15:06 i see 2024-12-20 15:16:11 sounds cool 2024-12-20 15:17:07 And I can write for this already, and define : PREBLOCK DROP ; in the meantime 2024-12-20 15:21:06 right 2024-12-20 19:24:32 veltas: what is your forth system written in? c? 2024-12-20 19:37:56 also veltas it is published? 2024-12-20 19:38:20 can we see your code and steal it to sell it and get rich? 2024-12-20 19:38:34 and can you please do my laundry 2024-12-20 19:39:21 my non forth is written in perl xd 2024-12-20 19:39:32 but has nothing to do with forth :/ 2024-12-20 23:01:51 I'm curious: would this work in all standard forths for breaking out of a function from within a (not nested) DO LOOP? : EXITDO R> DROP R> DROP R> DROP ; 2024-12-20 23:03:41 e.g. : STUFF 100 0 DO INKEY IF EXITDO THEN DELAY LOOP ; would that do an exit from STUFF if a key is pressed? 2024-12-20 23:36:43 no, the standard doesn't specify how many items are in a do-sys 2024-12-20 23:37:05 oh ok 2024-12-20 23:37:27 neither dpANS 94 nor the Forth 2012 standard, I believe 2024-12-20 23:37:35 not sure about Forth-83 and Forth-79 2024-12-20 23:40:00 in other news, my port of Mazogs is now complete, it just needs me to add some delays here and there because now it's way too fast :) 2024-12-20 23:41:26 congratulations! 2024-12-20 23:41:29 https://codeberg.org/pgimeno/Mazogs/src/branch/jupiter_ace 2024-12-20 23:44:15 thanks! 2024-12-20 23:47:07 I'm sure there will be quite a lot to criticize in it, because I've learned Forth just to write this, so it's my first Forth program ever 2024-12-20 23:57:51 I'm not really in a great place to criticize other people's Forth ;) 2024-12-20 23:59:03 depends on whether they have coordinates for your bunker? 2024-12-20 23:59:35 I mean it presupposes that I know Forth well enough to make well-founded criticisms