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
>> d
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
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
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
>> do
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
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
Am 01.04.2013 um 17:38 schrieb Wolfgang Lenerz:
> 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?
>
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"
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
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 b
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
Hi,
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.
Ok, so each time I'd increse an array, i'd have to increasethe data_area
at runtime?
The program to be compiled must be loaded into
Op Tue, 02 Apr 2013 14:22:37 +0200 schreef Dilwyn Jones
:
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
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.
>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 fil
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?
>
>
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.
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
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 larg
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 reco
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 pr
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 dim
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 differen
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 lo
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,
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
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://
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 ReDIMensio
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 ReDIMensio
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
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 resu
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$(d
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
33 matches
Mail list logo