I'm still a bit worried about the code size when using gcc to build the code. I was looking at uSTL, which may work better. Not sure if it supports "map" tho, or if it compiles for Windows!
On the project front, I have now implemented the basics to allow long variable names - it allocates space for variables as needed, not based on "there are only 26 variables". It still doesn't actually allow long names as such, but it's just a question of adding a little bit of extra code.
--
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.
And I've now submitted changes to support long variables. It appears to work fine - as usual, I used pitman as the test-code, and that loads and runs correctly.
Note that some variable names will need a keyword to make them work:
will produce an error when trying to run.Code:10 fork = 10
will work.Code:10 let fork = 10 20 print fork
I had to change a bit of the parsing code, and fix a the compiler::expect function to use match, because the old token_scanner::get_token() function was not able to provide tokens like "X11" or "A2B" - it stopped on any transition from alpha to non-alpha or vice versa. I think the new get_token is actually a bit easier to read and understand, as I could remove a couple of variables too - but it's got a lot more return statements now!
I think this is a good improvement. ]
Edit: I just pushed a new version number, as the format of the new files is different from old ones.
Unfortunately, the current code allows OLD pre-compiled files to be loaded and attempted to run, which falls over, so we probably need to change the version checking in some way that means that we can detect the "oldest version that works" - or perhaps simply say "the version number pre-compiled binaries will have to match" - any thoughts?
Next two things I will do:
1. Optional use of uSTL instead of STL - should produce radically smaller executable - not sure how much right now, but I'd be disappointed if it's more than half it's current size.
2. ANSI escape codes in consolestdio.
--
Mats
Last edited by matsp; 05-27-2009 at 12:21 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.
Looking good so far. Is a final release coming soon?
Paul
"Is a final release coming soon?"
This is software development. There is no final release; there is only the last release.
"Optional use of uSTL instead [...] half it's current size."
This is a spectacularly bad idea. The uSTL is not a replacement for the STL, copatble with the STL, or even an alias for the STL.
Instead you may as well use `std::vector<???>' for all storage requirements--replacing every other container--, pun `std::vector<??? *>' as `std::vector<void *>', and use the C IO routines directly. At least then you retain some level of portability and isolation, and the source will not give the allusion of being what it isn't.
Soma
Whilst it may be that uSTL isn't a plug-in replacement for STL, it is certainly capable of doing pretty close to everything that our current code is doing in STL - I'm still working through the code to make uSTL compile properly (I only just switched the computer on for the first time a little bit ago, so I haven't done ANYTHING on it today). I certainly think it's a better solution than the solution you are suggesting. Particularly since using uSTL means very few changes to the ACTUAL code, whilst your suggestion implies a lot of changes. And it's selectable, so anyone who wants to use STL can still do so [assuming recompile, of course].
I agree on the "final release". I think we are actually looking pretty good at the moment, and I would have no problem with the current version being used more widely.
--
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.
"it is certainly capable of doing pretty close to everything that our current code is doing in STL"
NO. IT. IS. NOT.
A `std::vector<std:air<x, y>>' masquerading as a `std::map<x, y>' is not even in the same universe as what we need.
"I certainly think it's a better solution than the solution you are suggesting."
O_o
That wasn't a suggestion; that was sarcasm.
*shrug*
If you want to waste time adding that as option solely because the resulting binary is a little large go for it.
Soma
Well, my wasted time has achieved this (I've just submitted the code itself, however, I will have to add all the USTL code to the local repo first - it's currently in a different directory).
Now for the results:
1. The compiled code is 183KB, instead of 549KB.
2. The speed of execution (simple benchmark) is approx 5x faster than Visual Studio [1], but about the same as gcc with stl.
[1] This is probably because of some feature we can switch off with a #define - I just haven't figured out what (because I've spent 0 time on that).
--
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'd say that's a significant improvement.
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 have now posted the USTL code inside the Minibasic project.
Note that you still have to build the USTL by itself. I'm going to fix that...
--
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, thanks.
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; }
And I've now ACTUALLY added the ustl code - it already had a .hg directory [becuase I used the hg git extension to pull in the code], and I had to recreate it by moving it to a fresh emtpy directory. All done now [I think - at least it said added 134 files, and the repo is about 200KB larger].
--
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.
For some reason I get an error on -fvisibility-inlines-hidden and -Wno-overflow. I couldn't find the latter in my gcc docs (is it a new-ish option?), and the former, well maybe it just got left out of the mingw port of 3.4.2?
EDIT:
Oh, wait a minute. I don't see the switches in the makefile...what the heck? I'll post back as soon as I figure it out.
Last edited by Sebastiani; 06-14-2009 at 06:00 AM.
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; }
Oh, I see. It's in the USTL makefile. I guess I can just delete those entries from my copy of the makefile (possible side-effects?).
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; }
The flags are in config.mk - I haven't bothered to fix the warnings occurring in uSTL.
It may be easies to remove flags that cause the offending code.
--
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.
Fixed those, but now I get compilation errors from utuple.h on lines #293 & #294 (ambiguous template specialization).
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; }
