Why not have the parser flag where extra stuff exists?
Mon Jun 22, 2020 4:57am
Basically make you a map. "IGNORING STATEMENT AT LINE 239." You then look at line 239 and it will tell you what sub it's in and where and you can add it back in.
Ok, so you might have to add a "page id" variable or something and have a long IF..ELSE IF chain (Um... QB had something like SELECT CASE for this, didn't it?) that only makes the secrets and stuff available from that page.
Wry: Plate-inum edition. Now with no stack errors!
the Qbasic stack error. For some reason I always thought it was it's own stack error and the config.sys stack was for something else. Learn something new every day!
The variable would be for which screen to go to. I took that as have a global string that held the sub name of what to call next.
Why not have the parser flag where extra stuff exists?- Puckdropper,Mon Jun 22 2020 4:57am
Might be easier to just manually take note where the secrets are and add them into the generated source code afterwards instead of having the parser do it. There aren't too many actually. The biggest thing is the invalid selection text but even then a good chunk of them are "YOU MAMA".
Wry HTML... more
If you think you'll rerun the parser many times, then it's worth adding the logic to add in those special cases.
I love the snow on Wry HTML. :-) It snowed today here but wasn't pretty and was just a rain snow mix. :-(
The amount of effort that went in to parse a single Qbasic BAS file into different output writers was silly but a fun thing to work on.
Creating the data files for Wry COBOL by hand would have been much less effort and probably quicker but zero fun. (Honestly, I probably would have never finishe... more
e they're fun." Some president misquoted somewhere.
Wait, so you can use a buggy QBASIC source as input to your parser to write a not very buggy QBASIC program? That's like Donald Knuth levels of computer science there!
Get on a regular release cycle where your parser fixes some bugs, adds a few new ones and you update every 2-4 weeks.
Just like every Android app out there, even the ones that should be technically finished! (How many updates does a sliding tile game need?)
Should have a release at the end of every 2 week sprint.
Thankfully at my job being a 20+ year old server side system we're not tied to that. They tried getting us to follow the agile flow to the "T" when it was first introduced to the company. We all had to go to a two day training session which... more