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