Busy day, I need to get my hair cut (whats left of it) and my workout afterwards (#peloton , join me).
That done I'm back at WideBight 3.0, porting (or rather rewriting) it to net.core - and it's what I'll be doing for the next year it seems (there's a LOT of code in WideBight 2.7, like A LOT ... not counting the shitload of css and js and views).

BUT maybe I sneak in an hour of #Genesis64 dev ... just for the fun.

Today in #Genesis64 dev:
finished the PRINT tokenizer (or rather code splitter).

In order to keep things "simple" G64 splits code into parts, so:

PRINT SIN(1)*2;"xyz"

is split into (PRINT's already tokenized):
"sin(1)*2"
";"
"xyz"

and then these are fed into the tokenizer again and the results are attached to the PRINT token...

And so I tried Bing's AI search ...
the first reply I got (a #C64 based question of course) return a "wrong" result when it spat out #basic code that contained ELSE
in an IF / THEN.

It quickly added that extensions (like Simon's basic) do have ELSE as a command (so does #Genesis64, btw).

Alas, beyond that ... I'm not sure I have any use for it - most of the things I search for either is a one-hit info (say a movie) or needs more research (because I also need to understand the underlying concepts and a summarising it doesn't help)

Today in #Genesis64 dev:
I'm going to have a stab a tokenizing PRINT (not the command itself, but what it prints). It's a bastard command if you look at the multiple ways it chains ("," or ";" for instance) or modifies output ("," or ";" again) and it's unfortunately tied to the #C64 screen's behaviour (think SPC, TAB, ",", etc).
Not to mention what a simple space can do or numbers...
#basic

Today in #Genesis64 dev:
a quick look at "tokens" (or what the parser spits out when we're not looking) ...
Consider this simple piece of #C64 #BASIC code:

a=sin(b*3.1415)

When I feed that into the parser the result is a list of "tokens" ordered by "importance":

Tokens: Array(5) [ {…}, {…}, {…}, … ]
0: Object { Name: "a", Id: -1, Type: 10, Values: [...] }
1: Object { Name: "b", Id: -1, Type: 10, Values: [...] }
2: Object { Name: "*", Id: 68, Type: 3, Values: [...] }
3: Object { Name: "sin", Id: 52, Type: 3, Values: [...] }
4: Object { Name: "let", Id: 16, Type: 2, Values: [...] }

(note that "Name" is only in there for debugging)

Let's take a closer look at the 2nd token's ("*") Values list:
0: Object { Name: "b", Id: -1, Type: 10, … }
1: Object { Id: -1, Type: 8, Order: 100, Num: 3.1415 }

Entry 0 links to entry 0 of the token list and entry 2 is a primitive (i.e. number) and doesn't need to be linked.

Easy, isn't it?

Today in #Genesis64 dev:
Fixed yesterday's moronic bug and also fixed the function parsing.
Tomorrow's dev time will be dedicated to make
A$="x" + B$
work and add compile time checks for that.
#c64 #basic

So at the end of the day, I have to admit that my #Genesis64 plans for today completely .... failed.

I noticed something strange while working on DEF FN's test code:
10 DEF FN X1(YY) = SIN(YY * 3) + 2

The quick fix was to move operators up in the parser priority but NOT realize the real problem.

Let's just say that I didn't sleep last night (for fuck knows what reason) and that didn't help to see the obvious.
Well, that was time well wasted. 😒

I'm doing a git push now and get home, then dinner one or two episodes of Magnum, and hopefully some sleep.
... and then fix the mess I created today: tomorrow.

Today in #Genesis64 dev:
Fixing DEF FN. The parser can handle it quite well as it is, the only thing messing it up is the parameter variable.
Per definition, it can use the name of a present variable and not change its value. BUT variables used in FN are global.
#C64 #BASIC

The drawback of "not playing by the rules" while writing #Genesis64's #BASIC parser is that sometimes things get fucked up.

Like DIM.

I forgot that you can use DIM with "dynamic" values:
b=10 + c: DIM a(b), DIM B$(c)

This breaks the idea of saving some time by initializing the whole array at compile time.

Well. Back to the drawing board on this.

If someone tells you that you could parse #C64 #BASIC with a just few regular expressions, I allow you to call that someone a liar.

I should know, it's how #Genesis64 started and I proved myself very, very wrong.

I still use a lot of regular expressions, though.

Today in #Genesis64 dev:
FOR / TO / STEP and IF / THEN
Like DATA they need some attention, luckily not as much as PRINT.
#C64 #BASIC #Parser

Today in #Genesis64 dev:
working on DATA.
As simple as it may seem, the #C64 #BASIC has some specials up the sleeve for it.
You can store literals without enclosing it in " and you can read numbers into string vars. You can even do things like:

10 data print, sin(1)

Also, leading spaces are ignored while trailing ones are kept.

Joy.

Today in #Genesis64 dev:
The parser now deals with arrays and does compile-time testing (type, dimensions - if possible).

Like #C64 #BASIC arrays get DIM'ed to 11 elements per dimension when they are used without DIM.

Technically the parser is now feature complete, I just need to test and/or update the "parser definition" for each command.

There are some commands that need special attention (IF/THEN, DATA, PRINT, and DEF FN).
Let's start easy with DATA.

In Germany, we have "Rosenmontag" and where I live it still means something - and of course, I loathe everything about it. I'm not even trying to get to the office.
So home office it is, with a pot of tea, listening to "???" (another German thing) and working on #Genesis64, making final fixes to arrays.

Every now and then the stars align and I'm able to celebrate a perfect Saturday morning: a #retromovie and #coding.
The movie in question is Blake Edwards' "The Great Race" (1965).
Staring Jack Lemmon, Tony Curtis and Natalie Wood. Oh and Peter Falk.
Working on #Genesis64's parser, adding compare operators (=, <, > ... plus != (which is not part of the #c64 #basic, but oh-so-helpful))

Quick #Genesis64 update: the new parser has about 70% less code than the last one, typecheck data is in without hardcoding them into the parser, the language can easily be expanded and it's fast.
And best of all: it doesn't look even remotely how a parser should look code wise (judging from all the books I've read about parser design).
But it works. So far.
#c64 #basic

More type-checking fixes for #Genesis64 's parser. Most type errors should be caught before even running the piece of code (actually I *think* all type errors).

First few takes are shot and we have a break, so I have 2 hours to work on #Genesis64 .
Operators are in and working, btw, and it's about to move type checking to its own function.
#c64 #basic

I have a few minutes before I head to the studio to shoot some training videos (no, I'm not infront of the camera, I make sure the virtual unreal 5 studio is behaving).
Time enough to fix the operator parser in #Genesis64.

So far the new parser works pretty well. I had some hickups with signs:
a=2*-b or a=2--b, but that's for tomorows session.
#Genesis64 #C64 #BASIC