Just a quick note that strictly, Adrian didn't say yes to RPM - I think
they had forgotten that utility but he said he would dig out all of his
old disks and see what software and sources (when he returns to New
Zealand in the next few days) and see what he can access.
OK - if the opportunity ar
Good news The sources are also available?
As yet, no, we do not have the sources. But it will be great if Ian Stewart
or Adrian Soundy can find those too.
I do have a printed manual for QLOAD/QREF but not had time to OCR the 4
pages yet. Will do that as soon as I get time.
The manuals fo
Certainly they're the most recent versions I have, I *think* that's what was
uploaded (I hope!) - it was all done in such a hurry!!!
Dilwyn
-Original Message-
From: RWAP Software via Ql-Users
Sent: Tuesday, June 13, 2017 6:52 PM
To: ql-us...@q-v-d.com
Subject: Re:
Just a quick note that strictly, Adrian didn't say yes to RPM - I think
they had forgotten that utility but he said he would dig out all of his
old disks and see what software and sources (when he returns to New
Zealand in the next few days) and see what he can access.
I have v1.9 of QLOAD and
Good news The sources are also available?
Il 13 giu 2017 19:46, "Dilwyn Jones via Ql-Users"
ha scritto:
> Rich Mellor has been able to secure permission for the Liberation Software
> range of compilers and utilities to be released as freeware.
>
> So I have made available copies of the versi
Dilwyn Jones via Ql-Users wrote:
> Rich Mellor has been able to secure permission for the Liberation Software
> range of compilers and utilities to be released as freeware.
Wow, Rich, that is pretty cool news. Good work!
Cheers, Marcel
___
QL-Users Mai
Rich Mellor has been able to secure permission for the Liberation Software
range of compilers and utilities to be released as freeware.
So I have made available copies of the version 1 compiler and manual
(formerly known as Budget QLiberator) and version 3.36 compiler and manual
on a new QLibe
On 8 Dec 2016, at 15:02, Derek Stewart wrote:
But what I mean is, if a SBASIC procedure is written, it can be compiled
with Qliberator and LRESPRed into the Interpreter list.
E.g. from Qliberator Manual
10 $$external
20 Def Proc Square(x)
30 print x*x
40 End Def Square
When this is compi
> On 8 Dec 2016, at 15:02, Derek Stewart wrote:
>
>
> But what I mean is, if a SBASIC procedure is written, it can be compiled with
> Qliberator and LRESPRed into the Interpreter list.
>
> E.g. from Qliberator Manual
>
> 10 $$external
> 20 Def Proc Square(x)
> 30 print x*x
> 40 End Def Squ
> On 8 Dec 2016, at 15:02, Derek Stewart wrote:
>
> But what I mean is, if a SBASIC procedure is written, it can be compiled with
> Qliberator and LRESPRed into the Interpreter list.
>
> E.g. from Qliberator Manual
>
> 10 $$external
> 20 Def Proc Square(x)
> 30 print x*x
> 40 End Def Square
On 08/12/16 14:43, George Gwilt wrote:
On 8 Dec 2016, at 14:09, Derek Stewart wrote:
I was reading my old Qliberator manual which I had forgotten about the
$$external function to allow S*Basic procedures and Functions to be compiled to
that added to the S*BASIC to extend the commands.
Can
> On 8 Dec 2016, at 14:09, Derek Stewart wrote:
>
> I was reading my old Qliberator manual which I had forgotten about the
> $$external function to allow S*Basic procedures and Functions to be compiled
> to that added to the S*BASIC to extend the commands.
>
> Can this be done in Turbo, or ca
Hi,
I was reading my old Qliberator manual which I had forgotten about the
$$external function to allow S*Basic procedures and Functions to be
compiled to that added to the S*BASIC to extend the commands.
Can this be done in Turbo, or can Turbo be altered to do this.
Regards,
Derek
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
In message <69be217bfb43484290de0b6d6f988...@d3hkh9x94>, Dilwyn Jones
writes
->>I'd been tinkering with a VERY fiddly program which behaved a
bit
differently and gave lots of errors when compiled compared to when it
was runnng interpreted, so it needed multiple compilations to test
and f
->>I'd been tinkering with a VERY fiddly program which behaved a
bit
differently and gave lots of errors when compiled compared to when
it was runnng interpreted, so it needed multiple compilations to
test and fix a whole host of compiling problems and I was never sure
after using SBASIC
In message <9fe217ce3e574bcd962d82ee7a634...@d3hkh9x94>, Dilwyn Jones
writes
Hi Dilywn,
In my 'boot' file, I use:
DISP_COLOUR 3,800,600 REM Set High Colour Mode 32 - 16 bit
Before - LRESPR 'Qlib_run'
(Which is needed by some programmes like FileInfo2)
I don't know if that is relevant to
Morning Dilwyn,
On 28/10/10 20:32, Dilwyn Jones wrote:
> ... and I was never sure after using
> SBASIC if I'd killed the QLiberator job or just buried it under the
> BASIC windows.
Did you try using the JOBS command from TK2? ;-)
Cheers,
Norman.
--
Norman Dunbar
Dunbar IT Consultants Ltd
Reg
Hi Dilywn,
In my 'boot' file, I use:
DISP_COLOUR 3,800,600 REM Set High Colour Mode 32 - 16 bit
Before - LRESPR 'Qlib_run'
(Which is needed by some programmes like FileInfo2)
I don't know if that is relevant to what you are trying to achieve
... ?
Malcolm Cadman
Not quite, though that's
In message <000901cb76be$50246f60$6402a...@baerchen>, Ralf Reköndt
writes
Gerhard Plavec wrote:
Ralf Reköndt wrote:
Dilwyn Jones wrote:
This is probably something you cannot do as the limits for moving
the front screen is probably hard coded in the original SuperBASIC
unfortunately.
--
Ric
Gerhard Plavec wrote:
Ralf Reköndt wrote:
Dilwyn Jones wrote:
This is probably something you cannot do as the limits for moving
the front screen is probably hard coded in the original SuperBASIC
unfortunately.
--
Rich Mellor
RWAP Services
Thanks - I was afraid that might be the case.
The n
Ralf Reko"ndt schrieb:
Dilwyn Jones wrote:
This is probably something you cannot do as the limits for moving
the front screen is probably hard coded in the original SuperBASIC
unfortunately.
--
Rich Mellor
RWAP Services
Thanks - I was afraid that might be the case.
The nearest I came to bein
Dilwyn Jones wrote:
This is probably something you cannot do as the limits for moving
the front screen is probably hard coded in the original SuperBASIC
unfortunately.
--
Rich Mellor
RWAP Services
Thanks - I was afraid that might be the case.
The nearest I came to being able to fix this was t
On 27/10/2010 13:04, Dilwyn Jones wrote:
On 27/10/2010 12:40, Dilwyn Jones wrote:
Anyone know how to get QLiberator to move outside the top left
512x256 pixel part of the screen on a high-res display?
The Move icon will float around the whole of the 1024x768 for
example, but the QLiberator w
On 27/10/2010 13:04, Dilwyn Jones wrote:
On 27/10/2010 12:40, Dilwyn Jones wrote:
Anyone know how to get QLiberator to move outside the top left
512x256 pixel part of the screen on a high-res display?
The Move icon will float around the whole of the 1024x768 for
example, but the QLiberator wi
On 27/10/2010 12:40, Dilwyn Jones wrote:
Anyone know how to get QLiberator to move outside the top left
512x256 pixel part of the screen on a high-res display?
The Move icon will float around the whole of the 1024x768 for
example, but the QLiberator window stays firmly within 512x256. At
firs
On 27/10/2010 12:40, Dilwyn Jones wrote:
Anyone know how to get QLiberator to move outside the top left 512x256
pixel part of the screen on a high-res display?
The Move icon will float around the whole of the 1024x768 for example,
but the QLiberator window stays firmly within 512x256. At first
Anyone know how to get QLiberator to move outside the top left 512x256
pixel part of the screen on a high-res display?
The Move icon will float around the whole of the 1024x768 for example,
but the QLiberator window stays firmly within 512x256. At first I
thought it might be down to the basic
60 matches
Mail list logo
