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

Quote:

---

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

"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."

Oh, I did misunderstand what you were having trouble with...

Code:

---

hg --config http_proxy.host=server,user=mats,passwd=password push

---

(It's something like that.)

What I've done is setup a simple forwarding utility to cooperate with `hg' executable and a few associated scripts that setup environment variables that define how the forwarding utility operates.

In other words, at home:

Code:

---

> hg-loader
> hg pull blahblahblah

---

at work:

Code:

---

> hg-loader --config work
> hg pull blahblahblah

---

Then again... I don't like remembering things. Your mileage may vary.

Soma

O_o

Okay...

At some point, you completely broke the parser. I think I fixed a couple of bugs, but I found dozens more. It is, more or less, completely stuffed. (At the very least "REIGN.MBI" and "PITMAN.MBI" load and seem to run correctly. Of course, infinitely many others do not. For example, load "DFOREST1.MBI" and "DFOREST2.MBI".)

I'm not exactly sure why, but you two have reintroduced some old bugs. (For one, you dropped my console size implementation in favor of a different one which fails under various circumstances.) I fixed the problem related to the startup code, but it is poor bandage.

I fixed one of the oldest bugs related to handling a carriage return. See several posts back where I posted/linked a description and a snapshot of the problem in action.

I uploaded a new image built from MSVC. (It requires the MSVC2K3 runtime DLL.)

I accidentally loaded the old source which was naturally stripped of trailing blanks so the push has fake updates to the old source.

Soma

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

"I have been testing with Pitman, which works just fine on my machine."

Oh no it doesn't. I did say "load and seem to run correctly". Look back through the thread to see the issue I'm talking about.

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

Not really... or not exclusively... it certainly didn't work as it should have. (I fixed several bugs with that and broke several others. I knew this, but my change seemed a net win.) I've updated the relevant bit to correct only the most obvious problem. (It is still broken in other areas. Or at least manifests from there...) I don't really understand why it exists. As for the other point of interest, I don't think it broke anything, but I've explicitly noted it with "(ZSV)" in the latest update so you know where/why I made the change.

"I'm going to completely delete the deprecated files in my next submission."

I did that just now. Actually, I did it several times. I kept getting a bad clone. (It seems to work now.) Still, several pointless commits. (One very pointless commit.)


Soma

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.

"This thread seems to have become a project discussion a long time ago."

Yep.

I was hoping that the host (BitBucket) would have a forum or something so we wouldn't have to use this thread at all.

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

Are we talking the "Projects and Job Recruitment" board? That's probably a good idea.

O_o

Now that you've brought it up, I kind of wonder why laserlight didn't move it.

Soma

Quote:

---

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

"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."

We just don't have the right primitives in place for that. Don't get me wrong, it would be better than nothing, but really, the "program" needs to communicate its state to the interpreter, and the interpreter needs to be able to communicate its state to... something at a higher level. And to be Bill, because of the inconsistency in the documentation and the original assembler I don't see how we can produce an automated testing tool. We need a real specification to work towards.

Soma

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