Re: [Ql-Users] Qliberator problems
On 2 Apr 2013, at 18:32, Wolfgang Lenerz wrote: All, Turbo does the very same thing, in my understanding - just with two different executables - parser_task and codegen_task, and the intermediate file format is not QSAVE, but something different - which is not officially documented. If you use such a file as input for codegen_task, Turbo can very well compile from a file. Interesting - does parser_task actually generate a file? Yes One difference is, of course, that you can qsave a file from any s*basic job, whereas is seems that parser_task seems to need the program to be loaded into job 0. Yes George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 1 Apr 2013, at 16:38, Wolfgang Lenerz wrote: Turbo cannot choose the dataspace which might be needed in a program it is compiling. You can either choose a specific dataspace on compilation or increase it after compilation. From within my (basic or compiled) program? If not, Turbo would be unsuitable for what I'd want to achieve. The TURBO_TK command DATA_AREA can be used in a basic program to set the dataspace. The number following DATA_SPACE is the required amount in kilobytes. Yes. Turbo won't compile a program unless the program resides, tokenised, in the master basic area. Ah OK. Can't it handle Qsaved progs? The program to be compiled must be loaded into ram under Job 0. A Qsaved program would first have to be loaded there before Turbo will compile it. Does QLIB compile directly from a file? George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
The program to be compiled must be loaded into ram under Job 0. A Qsaved program would first have to be loaded there before Turbo will compile it. Does QLIB compile directly from a file? George, QLiberator cannot compile directly from a non-tokenized SuperBASIC program contained in a file (AFAIK). The source program needs to come either from a file in tokenized form (can be produced by QSAVE) or from the master SuperBASIC job in memory. Regards, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Does QLIB compile directly from a file? George, QLiberator cannot compile directly from a non-tokenized SuperBASIC program contained in a file (AFAIK).The source program needs to come either from a file in tokenized form (can be produced by QSAVE) or from the master SuperBASIC job in memory. Regards, Tobias QLiberator creates the initial work file from a loaded, tokenised program, be that a QSAVEd file, or a a workfile generated by a LIBERATE command, e.g. LIBERATE flp1_myprog would create a workfile called flp1_myprog_wrk which could be compiled in a similar way to QSAVEd files. LIBERATE flp1_myprog, (i.e. with a comma after the filename) automates the compilation by first creating the workfile from the program in memory then starting the compiler phase to produce the object file. Apart from automating these processes (and I don't know how difficult that would be) via batch files with commands and suitable pauses to (a) LOAD (b) generate workfile or QSAVEd file, (c) starting compilation phase I don't think it'd be possible to compile direct from an untokenised BASIC program. Might be worth looking at how programs like the Structured SuperBASIC and BASIC Linker work to see if anything can be learned from those, perhaps. Dilwyn ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Tue, 02 Apr 2013 14:22:37 +0200 schreef Dilwyn Jones dil...@evans1511.fsnet.co.uk: Does QLIB compile directly from a file? ... Might be worth looking at how programs like the Structured SuperBASIC and BASIC Linker work to see if anything can be learned from those, perhaps. I write all my SBasic, without line numbers, in QD and test-run from there (SBAS/QD) before I save it as _bsl file. BASIC-Linker loads such a file, adds line numbers and saves that as _bas. Then it creates a _sav file from that and calls Qlib which compiles it. This is all done from the GUI with the help of an ascii _ctrl file where names and options can be set. This can also be used to merge SBasic sections so you an create a library of modules that make up the whole program. BASIC-Linker puts very few restrictions on writing SBasic, the most tricky one is in using DATA RESTORE. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Hi, Might be worth looking at how programs like the Structured SuperBASIC and BASIC Linker work to see if anything can be learned from those, perhaps. I don(t know hox Structuerd Superbasic does it, the Baic linker does the following: It collates and numbers the source files, saving them as a normal basic file. then it calls a parser to parse that file and generate a _sav file. This is done in a function as follows: def fn call_parser_ok% rem this makes the parser command line and calls the parser rem it returns 1 if all ok, else 0 or -1 if parser not found rem if any errors, it prints them out rem if there is an sbasic, it calls sbasic as parser, else the parser file rem rem uses global vars parser_file$, error_string$, sav_file$ ... rem ... parser_cmd$, errfile$, error_message$ rem v. 1.01 local chan%,a$,call_error%,is_sbasic% is_sbasic%=is_thg(sbasic) : rem check: is sbasic there? pe_cls#scr_chan% pe_print#scr_chan%, cr$centr$(info_message$(2),warning_width%) cr$centr$(output_file$,warning_width%) if parser_file$= and not is_sbasic% unst error_string$=error_message$(1) : rem no parser name not dbasic! print_error 0 : rem print this error now return 0 endif call_error%=0 : rem preset no error chan%=topen(parser_cmd$) : rem try to open_over parser cmd file if chan%0 unst error_string$=error_message$(2)cr$parser_cmd$ print_error chan% return 0 endif if is_sbasic% a$='10 Load 'output_file$ : rem command line if we're sbasic else a$=output_file$ \W : rem parser_exe: write file only, (don't compile) endif print#chan%,a$:PRINT#chan%: rem print command to cmd file close#chan% if is_sbasic% chan%=fop_over(errfile$): rem use error file as channel #0 (!) print#chan%,qsave sav_file$ : rem command in channel #0 close#chan%: rem now make sure that the _sav file... delete sav_file$ : rem ...doesn't exist already (else: it's not overwritten!) ew parser_cmd$,errfile$ : rem ew sbasic, passing the 'load file' as... : rem ... parameter string, and the _sav file... : rem ... as channel 0 else if parser_file$ and not ftest(parser_file$) ew parser_file$,parser_cmd$,errfile$ : rem exec parser normally else unst : rem parser not found! error_string$=error_message$(28) print_error 0: rem so complain return -1 endif endif if check_errors%(errfile$) unst: rem there were errors during parser error_string$=error_message$(3) print_error 0 return 0 endif delete parser_cmd$: rem get rid of parser command file return 1 : rem return all ok end def call_parser_ok% : So, if this is running on SMSQ/E, an sbasic job is used (invisibly) as parser (with some jiggery-pokery for the input/output files), else the parser supplied with the basic linker is used. The resulting tokenized sav file is saved and compiled with Qliberator... Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Afternoon all, The following is based on assumptions - always dangerous - but I doubt that I'm far away from reality! I know what I'd rather write. The choices are: * A compiler that misses out the huge part of the process where a source file is tokenised (by the lexer) so all you need to build is a parser and code gen (and library, if required); or * A full on tokeniser/lexer/codegen/library. I'm a lazy git, so I'd take the former and do without the lexer. This is why Turbo can only compile an in-memory source file and why Liberator works from a QSAVEd format. The two are identical, except one is in RAM the other in a file. And the lexing stuff, missing in the compilers, has been done already by SuperBasic. A very very nice way to do things - get the SuperBasic interpreter to tokenise the program so the compiler has much less work to do. Apologies to George if I'm decrying Turbo of course. I'd love to see Turbo being able to compile a QSAVE'd file, I'm not aware of the internals of Turbo, yet, but I can't see too many problems with it? Unless there's much to-ing and fro-ing in the SuperBasic area while compiling? I shall await the corrections that I just know I'm going to get! ;-) Cheers, Norm. -- Norman Dunbar Dunbar IT Consultants Ltd Registered address: Thorpe House 61 Richardshaw Lane Pudsey West Yorkshire United Kingdom LS28 7EL Company Number: 05132767 ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 2 Apr 2013, at 16:18, Norman Dunbar wrote: I'd love to see Turbo being able to compile a QSAVE'd file, I'm not aware of the internals of Turbo, yet, but I can't see too many problems with it? Unless there's much to-ing and fro-ing in the SuperBasic area while compiling? Turbo uses the BASIC name table to find the type of a variable. It therefore needs a name table. This will be set up when the BASIC program is loaded, whether from a SAV or a BAS file. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
From: Wolfgang Lenerz I don(t know hox Structuerd Superbasic does it, the Baic linker does the following: It collates and numbers the source files, saving them as a normal basic file. then it calls a parser to parse that file and generate a _sav file. This reminds me of the SMS2 parser program, which was a standalone program from TT in early times (still working). Is this the same? Cheers...Ralf R. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
All, Turbo does the very same thing, in my understanding - just with two different executables - parser_task and codegen_task, and the intermediate file format is not QSAVE, but something different - which is not officially documented. If you use such a file as input for codegen_task, Turbo can very well compile from a file. Interesting - does parser_task actually generate a file? One difference is, of course, that you can qsave a file from any s*basic job, whereas is seems that parser_task seems to need the program to be loaded into job 0. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
From Ralf Reköndt This reminds me of the SMS2 parser program, which was a standalone program from TT in early times (still working). Is this the same? Maybe. I can't remember. It's quite probable, though. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Am 02.04.2013 um 19:32 schrieb Wolfgang Lenerz: All, Turbo does the very same thing, in my understanding - just with two different executables - parser_task and codegen_task, and the intermediate file format is not QSAVE, but something different - which is not officially documented. If you use such a file as input for codegen_task, Turbo can very well compile from a file. Interesting - does parser_task actually generate a file? One difference is, of course, that you can qsave a file from any s*basic job, whereas is seems that parser_task seems to need the program to be loaded into job 0. Wolfgang Yes, it does - Typically on ram1_, but that can be changed by configuration, as far as I recall. Easily explained by the typical shortage of RAM QLs used to have in the early 90ies ;) And yes, you're right with your second sentence. Turbo gives an invalid job error if you try to compile from a daughter SBASIC. Regards, Tobias ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
From: Wolfgang Lenerz From Ralf Reköndt This reminds me of the SMS2 parser program, which was a standalone program from TT in early times (still working). Is this the same? Maybe. I can't remember. It's quite probable, though. I think, Jochen can bring up a bit light here...(if he want to);-) Cheers...Ralf R. ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 4/2/2013 5:22 AM, Dilwyn Jones wrote: Might be worth looking at how programs like the Structured SuperBASIC Structured SuberBASIC (SSB) does not do any compiling. It is just a pre-processor that that takes a program, written without line numbers and with certain markers, and coverts that to a text file that should be loaded by SuperBasic. There is no syntax checking on the program. I did write some extra programs that allow a user to use an editor like MicroEmacs, and have it fire off SSB and then fire off Qlib or Turbo. MicroEmacs allows the execution of external programs, so the whole SSB and compile process can be done from within MicroEmacs (and it sort of becomes like an IDE). MicroEmacs had syntax highlighting added to it, and it included support for SSB. As for using Qlib and Turbo, I've used both and to me they work very similar. I never knew Qlib could work on a QSAVE file. In fact, I've never dealt with QSAVE. I found Qlib to be easier to use (less strict on what it will compile) where as Turbo is stricter, but IIRC, it compiles faster code. I started moving toward Turbo primarily because it is Open Source and Qlib is still commercial. Tim Swenson ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Mon, 01 Apr 2013 10:34:06 +0200 schreef Wolfgang Lenerz w...@wlenerz.com: Hi all, I have a problem with Qliberator. Consider the following program : 100 DEFine PROCedure increase_result_array 110 LOCal dim1,dim2,temparray$(0,0) 120 dim1=DIMN(result$,1) 130 dim2=DIMN(result$,2) 140 DIM temparray$(dim1,dim2) 150 REMark arrcopy result$,temparray$ 160 DIM result$(dim1+100,dim2) 170 REMark arrcopy temparray$,result$ 180 DIM temparray$(0) 190 END DEFine increase_result_array 200 : 210 DEFine PROCedure p 220 LOCal lp% 230 DIM result$(1,40) 240 FOR lp%=1 TO 90 250 increase_result_array 260 END FOR lp% 270 END DEFine p 280 : 290 p 295 CLS 300 PRINT DIMN(result$,1) 310 kk$=INKEY$(-1) What is does is call the increase_result_array times, each time the result$ array is increased by 100 elements (I've r'mmed out the parts where the old array is copied to tthe new one and back).. The resulting array will have 9001 elements, 40 chars long each. When I run this in S, this Sbasic job occupies about 640 K (240 were already occupied before running the prog, e.g. for the screen etc). OK, seems normal. If I compile execute this, the resulting Qliberated job takes a whopping 32 MB! It seems to me that there is a bug in the variable allocation/deallocation routines. Can anybody confirm this? More importantly, does anybody know a way around this? Wolfgang Oh, and,seeing today's date, I hasten to add that this is no joke... I am not laughing and can confirm your findings. (On QDOS/SGC it ran out of heap space.) ReDIMensioning to zero first doesn't help either. The Qlib manual states that ReDIMensioning is a fast way of clearing all elements to zero. While Jan Jones in her book talks of releasing the old before assigning the new one. This may explain why SuQcess may grow to several MiB's, because a lot of ReDIMming is done there too. As Qlib uses its own name table this must be a Qlib feature. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Oops, sorry for double-posting my question! I am not laughing and can confirm your findings. (On QDOS/SGC it ran out of heap space.) ReDIMensioning to zero first doesn't help either. Darn. The Qlib manual states that ReDIMensioning is a fast way of clearing all elements to zero. Out of curiosity, on what machines did you test (me: SMSQmulator, QPC2)? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Mon, 01 Apr 2013 12:55:53 +0200 schreef Wolfgang Lenerz w...@wlenerz.com: Oops, sorry for double-posting my question! I am not laughing and can confirm your findings. (On QDOS/SGC it ran out of heap space.) ReDIMensioning to zero first doesn't help either. Darn. The Qlib manual states that ReDIMensioning is a fast way of clearing all elements to zero. Out of curiosity, on what machines did you test (me: SMSQmulator, QPC2)? I did my testing under QPC2 (SBasic-380KiB/ Qlib-34MiB). Also QDOS was used on my Aurora/SGC (out of heap). Setting the $$heap directive to 800K doesn't keep it limited either. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Mon, 01 Apr 2013 12:55:53 +0200 schreef Wolfgang Lenerz w...@wlenerz.com: Oops, sorry for double-posting my question! I am not laughing and can confirm your findings. (On QDOS/SGC it ran out of heap space.) ReDIMensioning to zero first doesn't help either. Darn. The Qlib manual states that ReDIMensioning is a fast way of clearing all elements to zero. Out of curiosity, on what machines did you test (me: SMSQmulator, QPC2)? I did my testing under QPC2 (SBasic-380KiB/ Qlib-34MiB). Also QDOS was used on my Aurora/SGC (out of heap). Setting the $$heap directive to 800K doesn't keep it limited either. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
I did my testing under QPC2 (SBasic-380KiB/ Qlib-34MiB). Also QDOS was used on my Aurora/SGC (out of heap). Setting the $$heap directive to 800K doesn't keep it limited either. Yeah, well no it wouldn't. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Mon, 01 Apr 2013 13:18:26 +0200 schreef Wolfgang Lenerz w...@wlenerz.com: I did my testing under QPC2 (SBasic-380KiB/ Qlib-34MiB). Also QDOS was used on my Aurora/SGC (out of heap). Setting the $$heap directive to 800K doesn't keep it limited either. Yeah, well no it wouldn't. Qlib can only claim 512K of heap, confirmed by the STATS. I tweaked your program a bit, disregarding what you tried to do for now. The called Proc returns with a new dimension value and the reDIM is done within the P loop. This behaves differently! After the Inkey$, STATS reports: Data: 524288 0 0 Stack: 800 172 Before clicking STATS, Qpac2's JOBS reports: memory used: 761680 A much more sensible value. Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 1 Apr 2013, at 09:34, Wolfgang Lenerz wrote: I have a problem with Qliberator. Consider the following program : 100 DEFine PROCedure increase_result_array 110 LOCal dim1,dim2,temparray$(0,0) 120 dim1=DIMN(result$,1) 130 dim2=DIMN(result$,2) 140 DIM temparray$(dim1,dim2) 150 REMark arrcopy result$,temparray$ 160 DIM result$(dim1+100,dim2) 170 REMark arrcopy temparray$,result$ 180 DIM temparray$(0) 190 END DEFine increase_result_array 200 : 210 DEFine PROCedure p 220 LOCal lp% 230 DIM result$(1,40) 240 FOR lp%=1 TO 90 250 increase_result_array 260 END FOR lp% 270 END DEFine p 280 : 290 p 295 CLS 300 PRINT DIMN(result$,1) 310 kk$=INKEY$(-1) What is does is call the increase_result_array times, each time the result$ array is increased by 100 elements (I've r'mmed out the parts where the old array is copied to tthe new one and back).. The resulting array will have 9001 elements, 40 chars long each. When I run this in S, this Sbasic job occupies about 640 K (240 were already occupied before running the prog, e.g. for the screen etc). OK, seems normal. If I compile execute this, the resulting Qliberated job takes a whopping 32 MB! It seems to me that there is a bug in the variable allocation/deallocation routines. Can anybody confirm this? More importantly, does anybody know a way around this? 1. Alter the dimensioning of temparray$ from 0,0 (and later 0!!) to 1,1 2. Use TURBO (with a large enough dataspace) George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Le 01/04/2013 14:37, George Gwilt a écrit : 1. Alter the dimensioning of temparray$ from 0,0 (and later 0!!) to 1,1 Interesting - why would this work? temparray is a local var and should not have any existence once the procedure is exited. 2. Use TURBO (with a large enough dataspace) I looked at Turbo some years ago, but AFAICR, it doesn't fit with my workflow : is it possible, from another prog, to call Turbo and have it compile a program that lies, say, on ram1_ (and recover any errors in an error file?) Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Qlib can only claim 512K of heap, confirmed by the STATS. Err, no. The 32 MB are definitely on the heap. I tweaked your program a bit, disregarding what you tried to do for now. The called Proc returns with a new dimension value and the reDIM is done within the P loop. This behaves differently! VERY strange! After the Inkey$, STATS reports: Data: 524288 0 0 Stack: 800 172 WHat about looking at the mem used when the prog is waiting for the inkey (with the QPAC jobs menu?) Before clicking STATS, Qpac2's JOBS reports: memory used: 761680 A much more sensible value. Yes. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 1 Apr 2013, at 14:05, Wolfgang Lenerz wrote: 1. Alter the dimensioning of temparray$ from 0,0 (and later 0!!) to 1,1 Interesting - why would this work? temparray is a local var and should not have any existence once the procedure is exited. Turbo seems not to like zero dimensioning and does not allow a redimensioning of a variable with a number of dimensions differing from that when it was first defined. 2. Use TURBO (with a large enough dataspace) I looked at Turbo some years ago, but AFAICR, it doesn't fit with my workflow : is it possible, from another prog, to call Turbo and have it compile a program that lies, say, on ram1_ (and recover any errors in an error file?) You have to call TURBO from master basic. but you can do this from another program by using COMMAND_LINE to select the master basic and then TYPE_IN to set the command CHARGE which causes the compilation with a report sent to ram1. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Op Mon, 01 Apr 2013 15:08:06 +0200 schreef Wolfgang Lenerz w...@wlenerz.com: Qlib can only claim 512K of heap, confirmed by the STATS. Err, no. The 32 MB are definitely on the heap. What I meant is that the $$heap directive only goes to 512K. Qlib will obviously claim more if needed. I tweaked your program a bit, disregarding what you tried to do for now. The called Proc returns with a new dimension value and the reDIM is done within the P loop. This behaves differently! VERY strange! After the Inkey$, STATS reports: Data: 524288 0 0 Stack: 800 172 WHat about looking at the mem used when the prog is waiting for the inkey (with the QPAC jobs menu?) Before clicking STATS, Qpac2's JOBS reports: memory used: 761680 A much more sensible value. There is no significant difference between before inkey$ or after. (After it's 432 bytes more!) FORGET THE ABOVE RESULT. I tweaked the basic again and could not repeat this result because the original was lost. There must have been a mistake, so I reconstructed it and now come to about 9.15MiB (JOBS). The changes suggested by George result in 12.69MiB, still a lot but less then the original. If we believe that Qlib keeps the old space before allocating new, this explains my first test that claimed 34MiB. Adding all the dim1+100's together comes to 409590, times 42 bytes for each string is 17MiB. Twice that for result$ and temparray$ does explain this 34MiB. But how can we explain the 9.15MiB and 12.69MiB? The last dimmed array (9001,40) is only about 380KiB, so 760KiB if we include temparray$. Could it be that Qlib behaves differently beyond its original boundary of 512KiB? Bob -- The BSJR QL software site at: http://members.upc.nl/b.spelten/ql/ ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
L What I meant is that the $$heap directive only goes to 512K. Qlib will obviously claim more if needed. Ah OK, sorry, didn't get that. FORGET THE ABOVE RESULT. I tweaked the basic again and could not repeat this result because the original was lost. There must have been a mistake, so I reconstructed it and now come to about 9.15MiB (JOBS). Could let us have the source of the reconstructed prog here? The changes suggested by George result in 12.69MiB, still a lot but less then the original. But still ,they shouldn't be necessary. The reason I use 0,0 at first is that you can't have a local variable that you don't identify as an array immediately (by DIMming it) and still use it as an array later. (...) The last dimmed array (9001,40) is only about 380KiB, so 760KiB if we include temparray$. Well, actually, since I dim temparray$ to 0 at the end, it should have gone, too Could it be that Qlib behaves differently beyond its original boundary of 512KiB? I don't know. Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
Turbo seems not to like zero dimensioning and does not allow a redimensioning of a variable with a number of dimensions differing from that when it was first defined. Ah , OK, so K could use LOCAL temparray$(1,1) and re-dim it to (1,1) at the end - no problem. 2. Use TURBO (with a large enough dataspace) Doesn't turbo automatially cliam more heap space when it needs it? The whole purpose of this prog is that when the program starts. I don't know the dimension the array will ultimately need, You have to call TURBO from master basic. but you can do this from another program by using COMMAND_LINE to select the master basic and then TYPE_IN to set the command CHARGE which causes the compilation with a report sent to ram1. Doesn't this mean that the program to be charged will need to be loaded into Job 0, too? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
On 1 Apr 2013, at 15:36, Wolfgang Lenerz wrote: 2. Use TURBO (with a large enough dataspace) Doesn't turbo automatially cliam more heap space when it needs it? The whole purpose of this prog is that when the program starts. I don't know the dimension the array will ultimately need, Turbo cannot choose the dataspace which might be needed in a program it is compiling. You can either choose a specific dataspace on compilation or increase it after compilation. My program adj_ds allows the increase of a program's dataspace and, if has been compiled by Turbo, the stack space too (which sometimes has to be increased). You have to call TURBO from master basic. but you can do this from another program by using COMMAND_LINE to select the master basic and then TYPE_IN to set the command CHARGE which causes the compilation with a report sent to ram1. Doesn't this mean that the program to be charged will need to be loaded into Job 0, too? Yes. Turbo won't compile a program unless the program resides, tokenised, in the master basic area. George ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
Re: [Ql-Users] Qliberator problems
L Turbo cannot choose the dataspace which might be needed in a program it is compiling. You can either choose a specific dataspace on compilation or increase it after compilation. From within my (basic or compiled) program? If not, Turbo would be unsuitable for what I'd want to achieve. Yes. Turbo won't compile a program unless the program resides, tokenised, in the master basic area. Ah OK. Can't it handle Qsaved progs? Wolfgang ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
