Thread: Converting MINI-BASIC in MASM over to C++?

I have fixed the "INPUT" command that I had broken. The fix is not yet submitted, as I fixed it on the way into work, and still haven't figured out how to make mercurial work through the proxy/firewall here at work.

As to why it was broken: when I refactored the compiler component, I changed the behaviour by reading the token. I fixed it by checking for "mode" earlier in the compiler, and not use the "compile_line" function (which also allows a whole lot of other things to be done that would be incorrect, in my view - I'm even tempted to change the behaviour to match the original minibasic implementation, rather than going through the complex compiler / interpreter chain - after all, the original only accepts numeric input).

--
Mats

"The fix is not yet submitted, as I [...] here at work."

If your company allows, mostly unrestricted, HTTP/HTTPS and you have a decent "always on" connection you can setup a private tunnel through your home computer.

You've done a good bit of shuffling. I'll take a look and see if I notice any outstanding bugs later if you want.

Soma

Originally Posted by phantomotap

"The fix is not yet submitted, as I [...] here at work."

If your company allows, mostly unrestricted, HTTP/HTTPS and you have a decent "always on" connection you can setup a private tunnel through your home computer.

You've done a good bit of shuffling. I'll take a look and see if I notice any outstanding bugs later if you want.

Soma

I do have "always on" when it comes to networking at home. But the work is on my work-laptop at the moment, which when I take it to work won't be able to access HTTP without a proxy. I'm sure there is a way to set mercurial to use a proxy, but I'd have to toggle it back and forth, aside from figuring out how it's done.

I'd appreciate a code-review/debug session, if you have the time. I'm going to push up the latest bits of code. I was trying to benchmark a bit vs. original minibasic. I'm surprised that we're not that much faster (but original minibasic is a bit hard to time - have to use stop-clock).

--
Mats

Doh! Running a program that does 1000000 loops in DEBUG mode is about the same speed as the original. With Release, it's about 3x faster in C++.

That's not because C++ in itself is faster, but because the C++ code works differently.

I'm going to post the executable with optimization. (g++ -O2).

--
Mats

Huh? I have been testing with Pitman, which works just fine on my machine. But I did notice the window resize was a bit borked. But certainly not completely broken. I will have a look at your changes, tho'.

I found at least one bug: Your change for "get_symbol" to just return token broke this:

Code:

5 A = 0
10 FOR I = 1 TO 10: A = A + I: NEXT : PRINT A
20 STOP

I think we really NEED to start looking at some automated testing (not because you broke it this time - I'm just as guilty of breaking stuff - one of my compiler changes broke INPUT for example). I'll look into making a module of the console that uses iostream so that we can produce output to a file, and compare it with an expected result. Probably not today tho.

I'm going to completely delete the deprecated (or depreciated ) files in my next submission. I don't think we want them any more - and if we do, we can always pull them back out of the archive.

--
Mats

This thread seems to have become a project discussion a long time ago. Does anyone think otherwise?

If nobody disagrees, I'll move it to the appropriate forum.

Originally Posted by CornedBee

This thread seems to have become a project discussion a long time ago. Does anyone think otherwise?

If nobody disagrees, I'll move it to the appropriate forum.

No problem to me.

I should have pushed my change to the get_symbol() - which is identical to your in all but the exact detail of how you check if it's a @.

I also started on a "consolestdiol.cpp" which can be used interchangably with "console.cpp" - it obviously doesn't do all the stuff that the full console does, but it would allow a set of automated tests for checking the language and functionality.

It will of course not check problems caused by console differences...

--
Mats

Well, I'm going to submit it anway - it's not going to hurt.

We probably should also cover cursor movement through metadata (or perhaps ANSI sequences?) so that we can "see" if something goes wrong with cursor positions.

And whilst we may not be able to test for some "standard", we should certainly be able to test for consistency in our own implementation - at least to the extent of spotting when something has gone wrong, rather than someone else discovering it several days later.

--
Mats

I agree with you completely. I'm just saying it would be nice if we had hooks in place to "watch" the compiler/interpreter and a real specification of the targeted dialect. That "something" is definitely better than our current "nothing".

Regarding the markup issue, instead of a simple ASCII input file and looking at the result after the fact--from a file dumped via your `stdioconsole'--why not markup everything? You--or we--could then add a few more lines--say in your `stdioconsole' or an object derived from it--to record a sample run of the program. I think this would be far superior to trying to craft the input files manually using ANSI escape sequences, but it does mean some extra work.

Soma

My plan was to capture the output from the test-code. Then when we change the code, it should match - or you have to explain why the new output is "better" (and reissue a new "template result").

Input would come from an input template. [Again, we probably can't simulate editing and such, but at least we will know if the input keyword is broken, and we can run multiple tests in a single "script" (batch file or so)].

It's pretty basic, probably because I believe in simple solutions, and I may not have thought it through very much.

--
Mats