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
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 "charge"d 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
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 "charge"d 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
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
Op Mon, 01 Apr 2013 15:08:06 +0200 schreef Wolfgang Lenerz : 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
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
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
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
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
Op Mon, 01 Apr 2013 13:18:26 +0200 schreef Wolfgang Lenerz : 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
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 12:55:53 +0200 schreef Wolfgang Lenerz : 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 : 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
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
[Ql-Users] Qliberator problems
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 procedure 90 times. Each time the result$ array is increased by 100 elements (I've REMmed out the parts where the old array is copied to a new one and back). The resulting array will have 9001 elements, 40 chars long each. When I run this in Sbasic, 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 occupies 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... ___ 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 : 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
[Ql-Users] Qliberator problems
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... ___ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
