Just to see how Turbo developed I tried to compile EasyPtr's AppMan
with it. I'd like to tell some of my quest in case anybody else wants
to try it, too.
First of all I'd like to note that whatever feature I thought "it
would be cool if Turbo could do this" Turbo could already do, one just
has to read the documentation.
It's for example very convenient that all compiler settings can be
specified in the BASIC program itself. It pissed me off to no end that
I couldn't specify the "No winds" option, or the job name in
Qliberator on a per-program basis. With Turbo it's all there:
100 TURBO_objfil 'ram1_appman' <- name of resulting EXE file
110 TURBO_taskn 'APPMan4' <- job name
120 TURBO_diags 2
130 TURBO_windo 0 <- "No winds"
140 TURBO_objdat 32 <- Dataspace size
150 TURBO_buffersz 64
160 REMark %%win1_easy_app_appman_cde,4,82
170 REMark %%win1_easy_app_fapp_cde,0,4
180 REMark %%win1_easy_app_mkapp_cde,0,10
190 REMark %%win1_easy_app_qcfx001_cde,0,10
200 IF NOT(COMPILED) THEN
210 LRESPR win1_easy_app_appman_cde
220 LRESPR win1_easy_app_fapp_cde
230 LRESPR win1_easy_app_mkapp_cde
240 LRESPR win1_easy_app_qcfx001_cde
250 END IF
The REMark lines will be quite familiar to QLiberator users and they
work exactly the same as $$asmb.
With the settings all in the basic file a simple "charge ," command
will automatically compile and create the resulting EXE file.
Another feature that I missed for example in Qliberator was support
for hexadecimal values using the $ notation. I thought "I should
probably ask George to include support for them". Once again, after
browsing the changes files I saw that Turbo already supports them...
After that AppMan did already start, but when trying to access the
Files menu the line
1760 MITEM#wdef1,-9,,appnum$
gave an error "not found". Changing it to
1760 MITEM#wdef1,-9,0,appnum$
helped, so not much of a problem, but I've told George about it
and he has fixed it in 4e21.
After this the files menu opened up, I could select something, the
"file select" menu opened up, it loaded the appendix and then booom,
another problem. Turned out some variable values were really messed
up. To make a very long story short: the application did simply run
out of stack space on the "file select" call and subsequently
overwrote some variables of the program. If you do compile programs
for EasyPtr, make sure to crank up the stack by configuring
"codegen_task" to a higher value (using MenuConfig). 1024 should be
pretty safe, but 2048 can't do any harm either.
In any case, Turbo was working correctly, tough a higher default value
might be in order.
After THAT I could load an appendix and... Sysmon went mad about a
memory corruption. God, those are hard to track down! To make an
equally long story short, Appman simply had a bug that corrupted the
heap! Why it didn't show up in SBasic or in the Qliberated version I
don't know, probably chance, but once again Turbo was just fine.
After that there was a problem with the MINPUT function of EasyPtr. It
has to do with the way Turbo handles strings (only fixed dimensioned
strings which EasyPtr didn't accept) but I could easily make the
EasyPtr Basic extension compatible, so that's fine then, too. Please
note that this EasyPtr version has not yet been released but might be
acquired if you really need it.
And that really was all of it, Appman works now as fine with Turbo as
it did with Qlib, so I think it's really time for you to check out
Turbo, too. ;-)
This was all some weeks ago, today I did a quick check of the array
slicing and it seemed to work perfectly well, too! Well done.
One more thing, I tried to compile a very large EasyPtr program with
Turbo and got hundreds of errors. The reason being that the same
variable names sometimes had different definitions, like
100 DIM a$(10,10): REMark a$ two dimensional
110 Test
120 :
130 DEFine PROCedure Test
140 LOCal a$: REMark a$ is one-dimensional
150 a$="xyz"
160 PRINT a$
170 END DEFine
This will be honoured by Turbo with the error
**** ERROR at 100: Ambiguous declaration of name.
and some errors
**** ERROR at 150: Ambiguous name used.
The reason is simple, consider the extended version of this program
100 DIM a$(10,10)
110 Test
120 Test2
130 :
140 DEFine PROCedure Test
150 LOCal a$
160 a$="xyz"
170 PRINT a$
180 Test2
190 END DEFine
200 :
210 DEFine PROCedure Test2
220 PRINT a$
230 END DEFine
I guess Turbo cannot know what code to produce for Test2. When called
from line 120, a$ is two-dimensional, when called from Test, a$ is
one- dimensional. SBasic handles this at runtime, but from a software
engineer point of view I actually prefer the way Turbo works, because
it can prevent bugs in the code. The downside is that some code
probably needs to be rewritten, but usually it's sufficient to just
rename some variables, so should not be that big a deal.
I hope this description might help some people get a start with Turbo,
I personally am not a big Basic programmer myself but it looks to me
as though Turbo gets ready for prime time.
Marcel
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
