Update on the new release

[The Beez]

Hi 4tH-ers!

You haven't heard from me lately, but I've been working hard for you. A few libraries are updated, giving you some optimizations or even some new possibilities, I've added a few more "design patterns", even one that allows you to mimic multiple inheritance on 4tH (twin pattern) and the manual has been fully updated - even added some articles that should have been added last release. We're close to 600 pages (!) now - more than any Forth compiler I know of.

Even more, I've been planning some new extensions to 4tH, so this one is really the last in the 3.62.x series. So, everything is in place, I've just got to find the time to prepare all the packages. Like I've said before, this one isn't a milestone release, but a step forward anyway.

What will v3.63.0 bring you?

- */ will become a second class citizen. It will still compile, but to a set of 4 tokens;
- I' will be restored again and R'@ will become a first class citizen and gets its own token;
- R"@ will be introduced. Yes, you can use "j", but it's dirty. Well, no more;
- I've got (untested) code for +TO. No, it won't be a first class citizen, but it will be optimizing, so if you add a literal expression it won't take any more opcodes than an equivalent +! expression.

Keeping you posted,

Hans Bezemer  

[The Beez]

Hi 4tH-ers!

This must be the most frustrating release in ages. Usually, changes are pretty localized, so testing them is a breeze. The LINT patches are everywhere, which makes testing very hard I bumped into a "bug" last Saturday when the Turbo C compilant was unable to write files anymore. Given the size of 4tH's elaborate I/O system I was able to tear my hair out. I rolled back the entire VM and it disappeared. After some hacking I was able to pinpoint the problem to a byte sized table that maps outrageous I/O modes to sane options, e.g. INPUT APPEND + is mapped to "rb". This is the code:

-
-  static const char Mapping [] =
-         "\x0\x0\x1\x2\x3\x0\x3\x4\x5\x5\x6\x5\x6\x5\x6\x5";
+                                       /* don't "const" this! */
+  static char Mapping [] = "\x0\x0\x1\x2\x3\x0\x3\x4\x5\x5\x6\x5\x6\x5\x6\x5";
   int x;

After that, it worked as expected again. But that's not it. You wonder what you could have missed. Sure, I have a test script for the VM, but that doesn't cover EVERYTHING - and certainly not something I can't even begin to understand. Why should making the string immutable trigger this kind of behavior? I might have to punch out assembler code to find out, since I can't find anything in the Turbo C manual that can explain this.

Hans Bezemer