One thing I noticed was that the scrolling function has a most annoying flicker (LOAD and LIST PITMAN to see a good example of this). If you remove the call to clear(), it looks much better, but of course leaves artifacts on the screen. Any ideas for how we can improve this?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
OK, that was easier than I thought it would be. I also modified the input history mechanism so that consecutive repeats are eliminated. I'll go ahead and push the most recent snapshot.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Go ahead - sounds good.
I'm not getting very far on the "long" variables - but as a side-effect, I think we will be able to do:
1. multiple arrays using "dim A(100)"
2. different type values - e.g. floating point and strings as well as integers.
The latter in particular will be a bit more work, but I think it's not too difficult.
--
Mats
Last edited by matsp; 04-23-2009 at 05:50 PM.
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
Not that I'm totally against the idea of supporting those features, but I just think that it almost makes it a new language. Besides that, it would require a fundamentally different approach to the way we are doing things now - not a complete rewrite or anything, but definitely a major reworking. Having said all that, if you still really want to do it (and perhaps we could get some input from Paul or others that use the language) I'm willing to help out where needed. Let's just make sure that this version is 100% complete before we start adding features, though.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Well, I've made some improvements to the console, and fixed a bug in the ends_with function. All in all, everythings looking pretty good. I've tested the dozen or so programs that Paul gave us and all of them run without a hitch, though it would be nice to have some more to test with. I'll see if I can find some more on the net. I haven't been able to push the update yet - I think the server is down at the moment.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I've changed a few things, but I forgot to test a few changes so you'll find one update corrects an alteration that broke many programs. The interpreter is not doing exactly what I thought it did, but it is working now.
Sebastian:
Do you care to change the compiler to emit multiple "PRINT" instructions for strings containing newlines? It would allow a few improvements to the `put' functions which should give us a speed boost.
Say compiling:
as if it were:Code:10 PRINT "TESTING!\nTESTING!"
I'm trying to patch the interface, but I didn't get very far. Almost nothing has changed...Code:10 PRINT "TESTING!":PRINT '\n':PRINT "TESTING!"
I added a few lines to support 'F5' and 'F6'.
I added a few simple changes to `void console::get(string& buffer)' to support an edit mode. (It probably doesn't work with very long lines.)
I changed the queue feature to use 'F5' and 'F6'. I tried a few long lines with the arrows and it didn't work, but I'm not exactly sure what the circumstances were. (Traditional long lines for consoles are solely navigated in edit mode or using only the left and right arrow keys, but I didn't want to remove that code.)
I'm also stripping the line number from the queue. (It makes edit mode nicer.)
I've also changed a few variables that have no business being static.
Soma
Note: I was playing around with the defaults and left the console defaults different than they should have been. I'm trying to get the "Dark Forrest" programs Paul posted to display correctly. They should be restored but constitute such a small change I didn't want to change it until I had something else to add.
Well this is frustrating. I can't pull or push anything - all I get is "abort: error: Operation timed out". The wierd thing is that I can view the web-pages from that site - I just can't get mercurial to communicate with it.
Soma - I'll take a look at the changes as soon as I can pull them.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Strange. When I explicitly specify the site, the pull works. I'll just do that for now until I've found out whats wrong with my configuration.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
You could always create a new local repository. Rename your current directory, and do hg clone again. You can then copy any modified files [use diff or some such to compare the files].
Once you are satisfied the new repo is fine, just delete the old one. I used to do that with Xen when I was working on an older version with lots of changes, and wanted to get the latest version - usually I'd have a load of merge problems if I just splatted the new version on top, so I'd have two repo's for a while, and then just delete the old one.
You can even have two local repos of the same thing active at the same time - just make sure you keep both in sync so as to not create a branch that you didn't want.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
OK, there are a few things I have an issue with. First of all, I don't think it's a good idea to strip line numbers from the input history. If the user wants to reuse the input, the record should be available in its entirety. If they decide to change the line number they can simply use the navigation keys. Besides that, I don't think the console should know anything about minibasic. You could still emulate editing without breaking the encapsualtion. Second, why aren't lines entered in edit mode being stored in the history? Input is input. Finally, the static variables will improve performance. Do we really need to reallocate a 80 X 25 buffer every time we scroll the window? It doesn't have to be static, mind you - for all I care it could be a member of the console class. But for efficiency reasons, I think we should avoid unnecessary allocations whenever possible.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
One more thing: can we use some other combination of keys for navigation, or perhaps provide a command to set it? On my keyboard, F5 and F6 aren't very accessible.
I've push a merged update. I left Soma's console code as is for now, but I really do think it should be more isolated from the minibasic class.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
Please excuse the insane number of pushes - I mistakenly thought that commits overwrite eachother until a push is made. Is there a way to rollback all commits made before a single push?
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
I think you can do "hg revert -r xxx" and then "hg commit", I believe. If that doesn't work, you can use "hg export -r xxx > diff.txt" and then use "patch -r < diff.txt" to "undo" the change.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I strongly disagree. If a user needs to apply a recent entry to a particular line they can, as you said, use the navigation keys, but I can make a relevant change and add the appropriate line number with "home" faster than I can hit "insert" or "backspace". Also, stripping the line number means changes based solely on the line number don't pollute the queue.First of all, I don't think it's a good idea to strip line numbers from the input history.
This I strongly agree with, but that has nothing to do with stripping line numbers. I could have added the change without breaking into the `console' class, but all of the classes are strongly tied together and to the idea that they are singletons I didn't really see a point. We have a lot of work to do in this area.Besides that, I don't think the console should know anything about minibasic.
Avoiding the allocation is one thing, but marking a container as static isn't going to help the performance. And, you weren't necessarily avoiding the allocation/destruction, but you may have been. (It depends on the implementation.) If that is what you were trying to avoid, you need to avoid `resize'.Finally, the static variables [...] allocations whenever possible.
Type a long line in "COMMAND.COM", "CMD.EXE", the BASH shell, and most other terminals and terminal based line editors. The up and down arrow keys almost never move between different layers of the same input line. I'd say clone part of the implementation for `UP' and `DOWN' into `LEFT' and `RIGHT', swap `UP' with `FUNCTION_05', and swap `DOWN' with `FUNCTION_06'.One more thing: can we use some other combination of keys for navigation, or perhaps provide a command to set it?
"I left Soma's console code as is for now, but I really do think it should be more isolated from the minibasic class."
I completely agree. The problem is, we just don't have an organized list of all the primitives we need to cleanly separate the various classes.
1): The compiler has no business using the same global state as the editor.
2): The line editor has no business being an aspect of the virtual machine.
3): The queue feature should be rewritten as a feature of the class not as an implementation of the input.
4): Virtually everything pretends to have knowledge of everything else because everything uses the idea that various bits are currently implicit singletons.
This is just a short list off the top of my head that will take several days to sort properly.
I hate to throw your own words back at you, but let's get this one working before we start a rewrite. ^_^
I wouldn't worry about it. I think you'd probably just wind up with another head or another commit when you push it to the central repository. (You could easily revert back to commit two and still have the current source in your local repository.)Is there a way to rollback all commits made before a single push?
Soma
>> I strongly disagree. If a user needs to apply a recent entry to a particular line they can, as you said, use the navigation keys, but I can make a relevant change and add the appropriate line number with "home" faster than I can hit "insert" or "backspace". Also, stripping the line number means changes based solely on the line number don't pollute the queue.
Consider a direct edit (line number followed by code). The user edits the line and runs the program, but there was some sort of error in the code, and it takes several attempts to correct. Using my method, they can simply navigate backward and correct the line without having to retype the line number over and over.
>> This I strongly agree with, but that has nothing to do with stripping line numbers. I could have added the change without breaking into the `console' class, but all of the classes are strongly tied together
That's not true. Neither the console nor token_scanner classes know anything about minibasic class, and could even be reused in other, unrelated programs - the only classes that are actually tied together are minibasic and minibasic::interpreter (which makes sense, anyway).
>> Avoiding the allocation is one thing, but marking a container as static isn't going to help the performance. And, you weren't necessarily avoiding the allocation/destruction, but you may have been. (It depends on the implementation.) If that is what you were trying to avoid, you need to avoid `resize'.
No, resize only reallocates if the new size is larger than the internal buffer. Like I said, they could very well be class members - they just don't need to be reallocated every time the function executes.
>> Type a long line in "COMMAND.COM", "CMD.EXE", the BASH shell, and most other terminals and terminal based line editors. The up and down arrow keys almost never move between different layers of the same input line. I'd say clone part of the implementation for `UP' and `DOWN' into `LEFT' and `RIGHT', swap `UP' with `FUNCTION_05', and swap `DOWN' with `FUNCTION_06'.
Yes, but I think that emulating the behavior of today's text editors is more appropriate. Having HOME, END, UP, DOWN, LEFT, and RIGHT work the way they do now is very user friendly, and I would argue that most users would prefer it that way. I think a better candidate for history navigation might be the PAGE_UP and PAGE_DOWN keys, personally.
>> The compiler has no business using the same global state as the editor.
As I pointed out earlier, the compiler knows nothing about minibasic.
>> The line editor has no business being an aspect of the virtual machine.
The virtual machine (interpreter) does need to have some access to the minibasic class, since the latter contains state information and other things used by the former. In fact, the only reason I implemented them separately is because the INPUT command needs an interpreter to do it's work.
>> The queue feature should be rewritten as a feature of the class not as an implementation of the input.
I disagree. Being part of the console class preserves encapsulation, and as I said earlier, the class could even be used in an unrelated program and make use of the input history feature.
>> Virtually everything pretends to have knowledge of everything else because everything uses the idea that various bits are currently implicit singletons.
Only minibasic and minibasic::interpreter access singletons, and don't so much "pretend" to know about anything so much as they *use* these objects (they could have just as well have been instantiated as members). I mean, you could simply declare an instance of the console class within minibasic and the only thing it would change would be instead of typing console::instance() you'd use global_console, or whatever. The point is, there is no unnecessary intermingling here, whatsoever.
Code:#include <cmath> #include <complex> bool euler_flip(bool value) { return std::pow ( std::complex<float>(std::exp(1.0)), std::complex<float>(0, 1) * std::complex<float>(std::atan(1.0) *(1 << (value + 2))) ).real() < 0; }
