Re: [Ql-Users] Function type error

[Per Witte via Ql-Users]

I couldnt resist wading in here. Regarding Michael's original question the
Mint% routine should answer.Try this:

100 :
110 a = 330.7: b = 440.7
120 PRINT #0, Min_Int%(a, b), Mint%(a, b)
130 PAUSE -1
140 STOP
150 :
160 DEFine FuNction Min_Int%(x%,i)
170  IF x% < i : RETurn x% : ELSE : RETurn i
180 END DEFine
190 :
200 DEFine FuNction Mint%(x%, i)
210 LOCal a%
220 IF x% < b: a% = x%: ELSE : a% = i
230 RETurn a%
240 END DEFine Mint%
250 :

Dilwyn's solution is somewhat different in that a% = INT(a) <> a% = a, as
can be verified by running the routine below:

100 CLS: FOR i = 4 TO 5.1 STEP .1: PRINT Flint(i)! i
110 DEFine FuNction Flint(a%)
120 LOCal x%
130 x% = a%
140 IF INT(a%) = x%: RETurn 1
150 RETurn 0
160 END DEFine Flint
170 :

(But replacing the line 100 above with the line below, wheres the logic in
this:
100 CLS: FOR i% = 4 TO 5.1 STEP .1: PRINT Flint(i%)! i%
? Probably the result of hitting a RIRO design paradigm?)

Per

On 10 August 2017 at 18:22, Dilwyn Jones via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> The fact that the function name ends in % doesn't seem to make it an
> integer function (although the QL user guide says that "the type of data
> returned by the function is indicated by the type appended to the function
> identifier") any more than  parameter names have no type until they are
> set, so parameter x% could be float or integer, depending on what it is
> made when parameters are passed.
>
> As a workaround, add INT in line 160
>
> 160 IF INT(x%) < i : RETurn INT(x%) : ELSE return INT(i)
>
> Dilwyn
>
> -Original Message- From: Michael Bulford via Ql-Users
> Sent: Thursday, August 10, 2017 5:54 PM
> To: ql-users@lists.q-v-d.com ; ql-users-requ...@lists.q-v-d.com
> Subject: [Ql-Users] Function type error
>
>
> Hi all,
> I've no idea whether this has been mentioned before, but consider this …
> 100 :110 PRINT #0, Min_Int%(330.7, 440.7)120 PAUSE -1130 STOP140 :150
> DEFine FuNction Min_Int%(x%,i)160  IF x% < i : RETurn x% : ELSE : RETurn
> i170  END DEFine The correct result should be 331, sincethis is an integer
> function.On QPC2, SBASIC gives the result as 330.7QLiberator likewise also
> gives 330.7 Can anything be done? Michael
>
> ___
> QL-Users Mailing List
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> ___
> QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

George, the question is relevant if you write programs intended for other
people: You cant be sure THEY will load Turbo. However, IMHO, any serious
Tinkerer should load Turbo as a matter of course.

Per

On 18 August 2017 at 16:54, gdgqler--- via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> > On 17 Aug 2017, at 13:54, Lee Privett via Ql-Users <
> ql-users@lists.q-v-d.com> wr
>
> > I feel there must be a way to test for TURBO toolkit, any ideas?
>
> In my BOOT I load the TURBO toolkit. So why should I test for it?
> If I don’t load it in my BOOT it just is not loaded.
>
> George
> ___
> QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Your approach is commendable as an option for those who dont load a Turbo
toolkit by default, but for the rest of us it doesnt do much good.
Presumably, the REM version is based on the generic version which is
somewhat less optimal under SMSQ/E? And Turbo-compiled tasks will use the
incorporated keywords rather than those loaded into the machine at boot?
Thus the high-end user will end up with 7k of belt-and-braces bloat running
at less than optimal speed. I guess in the scheme of things its not going
to make much real difference, but I thought it was worth pointing out that
my comment was not just a thoughtless blurt.
Per

On 19 August 2017 at 09:13, George Gwilt via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> > On 18 Aug 2017, at 17:38, Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> >
> > George, the question is relevant if you write programs intended for other
> > people: You cant be sure THEY will load Turbo. However, IMHO, any serious
> > Tinkerer should load Turbo as a matter of course.
>
> I would usually expect to compile any programs before releasing them to
> the general public. In that case TURBO_TK_REM would have been added.
>
> George
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Hi Michael, I dont know why it doesnt work for you. I just clicked on the
link now and it works for me. Try copying the link and pasting it in your
browser. The article is about searching for specific keywords in
SuperBASIC, SBASIC and compiled BASIC without the use of an external
toolkit.
Per

PS Apologies if Im top-posting or bottom-posting or whatever one objects
to. Im not at home, with my normal email client, and am at the mercy of
whatever my browser-based email client thinks appropriate. (HELL is stupid
programs that THINK they are clever (or rather those who made them))

On 19 August 2017 at 12:17, Michael Bulford via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On Thu, 17 Aug 2017 21:08:31, Per Witte  wrote:
>
> > Thats a nice solution. Not sufficient for all manner of keywords,
> though. A
> > more general solution for checking for relevant toolkits in boot
> programs,
> > without having to load a toolkit to do so can be found in this
> article:
> > http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)
>
> Hi Per, I cannot get the above link to work.  It says not found.
>
>
>
> On Thu, 17 Aug 2017, 16:54:32, Duncan   wrote:
>
> Hi Lee, If booting from a Win drive  on the first instance of needing
> to load the Turbo toolkit check for the existence of a file on the boot
> device called "TTKLoaded", or similar. If the file does not exist create it
> and load TurboTK. If the file is found to exist do not load the
> toolkit. At the end of the session tidy up the boot device by deleting
> this file. Not elegant but practical.
>
>
> Hi Duncan,
>
> But what if during the session the QL crashes?  The TTKLoaded file will
> remain on the Win drive, and the next time the QL session is started, it
> won't work properly.  A nice idea though.  Another way of doing this is to
> use environment variables, which I use myself.  The details are here:
> http://www.dilwyn.me.uk/tk/env.zip
>
>
> Michael
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] Stupid AND

[Per Witte via Ql-Users]

Yes, its dumb, but the problem has been there since the day day dot. So
suck it up and work around :)

Per

On 19 September 2017 at 21:55, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On 19/09/2017 21:32, Dave Park via Ql-Users wrote:
>
>> Your BASIC interpreter fits in 48K. With room to spare.
>>
>
> And?
>
> (pun intended)
>
> Wolfgang
>
>> On Tue, Sep 19, 2017 at 2:27 PM, Wolfgang Lenerz via Ql-Users <
>> ql-users@lists.q-v-d.com> wrote:
>>
>> Hi all,
>>>
>>> Just a rant about the SBasic AND operator.
>>>
>>> Suppose this:
>>>
>>> 10 a=0
>>> 20 b=10
>>> 30 if (a<>0 AND b/a=5)
>>> 40   do_something
>>> 50 end if
>>>
>>> Run it and what happens?
>>>
>>> You get an "overflow" error at line 30.
>>> You get this error because it is trying to evaluate the second condition
>>> (b/a) and failing as a=0 and you can't divide by 0.
>>>
>>> BUT WHY IS IT TRYING TO EVALUATE THE SECOND CONDITION IN THE FIRST PLACE?
>>>
>>> The first condition (a<>0) is NOT met and so, in any other programming
>>> language I use, the second condition isn't even tested, as the result
>>> will
>>> be "false" anyway because of this.
>>>
>>> Apparently though, Sbasic still also tests the second condition.
>>>
>>> G.
>>>
>>> Wolfgang
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> QL-Users Mailing List
>>>
>>>
>>
>>
>>
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] Qbase

[Per Witte via Ql-Users]

Lots of different programs use Qmenu, so there should be no need to link it
in. Its best loaded at boot time.

Per

On 19 September 2017 at 21:15, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> the problem is that these parameters are likely to vary from version to
> version, as they are offsets into the file...
>
> Your best bet is probably to adapt your program to the latest version.
>
>
> Wolfgang
>
>
>> A question about QBase and QMenu.
>>
>> The menu  extensions are used fairly extensively in QBase. However, the
>> program was originally written in 1998 with whatever version of QMenu was
>> current then, and it doesn't seem to work properly with the later version
>> (version 7.66) which is distributed with QPC.
>>
>> I also have a version 5.06, which appears to work much better with QBase,
>> and I thought it might be a good idea to link it into QBase with
>> Q-Liberator and avoid problems for people using later versions.
>>
>> The other possibility is to update the QBase code, but for this I would
>> need a manual, which seems to be unavailable (is it really still
>> commercial?). I did purchase a copy of QMenu in the 1990s, but I can't
>> find
>> the manual, which I assume is buried somewhere in my attic.
>>
>> So, does anyone know the correct parameters for linking menu_rext into a
>> Q_Liberator compiled program?
>>
>> Thanks,
>>
>> D.
>>
>> On Fri, Sep 15, 2017 at 7:42 AM, Daniel Baum  wrote:
>>
>> Hi all,
>>>
>>> In my previous posting I forgot to mention another new feature: The
>>> tabular view no longer attempts to load the whole file at once. It can
>>> now
>>> be paged up and down using the left and right arrow buttons. This way you
>>> can load large files without hitting any memory limitations.
>>>
>>> The page size and the scroll size are both parameters that eventually I
>>> intend to put in a Config block to the user can alter them.
>>>
>>> Thanks to Bob Spelten for pointing out the need for this.
>>>
>>> Rgds,
>>>
>>> Daniel
>>>
>>> On Thu, Sep 14, 2017 at 9:40 PM, Daniel Baum  wrote:
>>>
>>> Hi all,

 Here is the new version of QBase.

 Changes:

 - Loads in 512x256 resolution, and is resizable.
 - May be called with a command-line parameter, e.g. ex
 flp1_Qbase_obj;'flp1_data_dbs'
 - Lots of refactoring. The eagle-eyed among you may notice that it's a
 lot smaller than it was.

 Tested on QPC2 with SMSQ/E 3.31, Q-Emulator with SMSQ/E 3.31

 Unlike the previous version, this one also works on Q-Emulator with
 Minerva. I couldn't get it to work on a JS ROM. It reported "Channel not
 open", and I've no idea why.

 Is it important to anyone to run QBase on original QL hardware? Testing
 with Q_Emulator and Minerva at "QL speed" it appears to be extremely
 slow,
 especially when switching to tabular mode. I could try to get it to run
 a
 bit faster if anyone is interested. I hadn't remembered just how much
 faster QPC is than a real QL until I started using Q-Emulator.

 Download the new QBase here:
 https://www.dropbox.com/s/4s3fm0rm84mxfn7/QBase.zip?dl=0

 Currently I have numbered this version 0.99. It will become version 1.0
 one it's been tested and bugfixed

 Finally, I'd like to give an honourable mention to MasterBasic by Ergon
 Development (Davide Santachiara). It made 80s-style program editing
 bearable (almost...). The more massive refactoring was done with
 Notepad++
 on Windows.

 Regards to all,

 D.


 On Mon, Sep 11, 2017 at 9:29 PM, Darren Branagh via Ql-Users <
 ql-users@lists.q-v-d.com> wrote:

 Hi Daniel,
>
> Have you released any of your updates yet?
>
> Just wondering if they can be tested.
>
> Darren Branagh
>
> Sent from My Android Phone.
>
> On 10 Sep 2017 23:18, "Bob Spelten via Ql-Users" <
> ql-users@lists.q-v-d.com>
> wrote:
>
> Op Sun, 10 Sep 2017 20:19:22 +0200 schreef Daniel Baum via Ql-Users <
>> ql-users@lists.q-v-d.com>:
>>
>> One more thing:
>>
>>>
>>> I should add that limiting the number of displayed records to 1000
>>>
>> works
>
>> fine, so I could fix the problem by using a paging arrangement.
>>>
>>> The test _dbs has 3111 records by 6 fields making 18666 menu items.
>>>
>> That is well within the limit of items (<32K) WMAN2 can handle in the
>>
> AW.
>
>> Records times Fields must be less.
>> But there is also a limit in S*Basic of 65K for indexing second and
>>
> third
>
>> dimensions, in this case Fields x Field_length (including length
>> word).
>> As you used Fields as the first dimension instead, 2nd (Records: 3111)
>> times 3rd (length: 20 +2) would be just too much.
>> As records will in most cases be the highest number, making it the

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Thats a nice solution. Not sufficient for all manner of keywords, though. A
more general solution for checking for relevant toolkits in boot programs,
without having to load a toolkit to do so can be found in this article:
http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)

Per

On 17 August 2017 at 13:54, Lee Privett via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> I have also been able to get this method to work with TURBO ptr extensions
> as well by using the following
>
> 220 IF ACR<>0 THEN
> 230  PRINT "Done":STOP
> 240 ELSE
> 250  LRESPR win2_tptr_ext
> 260 END IF
>
>
> Lee
>
> Lee
>
>
>
>
> On Thu, Aug 17, 2017 at 12:22 PM, Lee Privett 
> wrote:
>
> > Thanks for all the suggestions guys,
> >
> > 220 IF TK_VER$<>"" THEN
> > 230  PRINT "Done":STOP
> > 240 ELSE
> > 250  LRESPR win8_turbo_sms_code
> > 260 END IF
> >
> > this works exactly how I wanted it to, so  to Tobias.
> >
> > Many thanks to you all
> >
> > Lee
> >
> >
> >
> >
> >
> >
> >
> >
> > Lee
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 11:47 AM, Tobias Fröschle via Ql-Users <
> > ql-users@lists.q-v-d.com> wrote:
> >
> >> Lee,
> >>
> >> in case your question is really only Turbo Toolkit specific, you can
> very
> >> well do away with a much simpler solution than WHEN ERRor clauses:
> >>
> >> 1000 IF TK_VER$ <> ""
> >> 1010   REM do whatever you want to do when Turbo Toolkit is loaded
> >> 1020 ELSE
> >> 1030  REM Do whatever you want to do if it is not loaded
> >> 1030 END IF
> >>
> >> This relies on the fact that the interpreter will interpret TK_VER$ as a
> >> FUNCTION returning a string in case the toolkit is loaded, and an unset
> >> string variable in case it is not. And unset string variables are by
> >> convention "empty".
> >>
> >> Tobias
> >>
> >>
> >> > Am 17.08.2017 um 12:37 schrieb Lee Privett via Ql-Users <
> >> ql-users@lists.q-v-d.com>:
> >> >
> >> > Perhaps I should clarify this a little further.
> >> >
> >> > Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the
> >> same
> >> > boot, I will always do this or use QPC2, I am not really looking for a
> >> BBQL
> >> > solution as it is development for other things.
> >> >
> >> > Where this
> >> >
> >> > [code]IF VER$<>"HBA" THEN
> >> >   LRESPR "WIN8_SMSQ_QEM"
> >> > END IF[/code]
> >> >
> >> > loads SMSQ and fails the second time around (as designed, so all good)
> >> as
> >> > the same boot loads again, I then load (still in the same boot) the
> >> > TURBO_SMS_CODE appropriate for SMSQ based system.
> >> >
> >> > This is all fine, however, I am developing the boot for different
> setups
> >> > and change them a lot depending on what project I decide to work on.
> >> >
> >> > This means re-running the boot several times in the one session to
> test
> >> > what I am trying to do and I don't want to keep using up space
> re-LRESPR
> >> > the TURBO toolkit.
> >> > Using another toolkit to test for the existence of a keyword in the
> >> TURBO
> >> > toolkit would then mean using another method to test for that
> additional
> >> > Toolkit, a catch 22.
> >> >
> >> > So I may try the WHEN_ERR method as soon as I find the documentation
> on
> >> it.
> >> >
> >> > Lee
> >> >
> >> >
> >> >
> >> >
> >> > Lee
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
> >> > ql-users@lists.q-v-d.com> wrote:
> >> >
> >> >> Hi Tobias,
> >> >>
> >> >> The WHEN solution is great, but on some version of QODS, the WHEN
> ERRor
> >> >> did not work.
> >> >>
> >> >> There are some people still using AH,JM, roms which may have problems
> >> with
> >> >> WHEN ERRor
> >> >>
> >> >> --
> >> >> Regards,
> >> >>
> >> >> Derek
> >> >>
> >> >>
> >> >> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
> >> >>
> >> >>> After I sent this, I realised a bit of explanation might be in
> order,
> >> as
> >> >>> WHEN ERRor is not so well-known:
> >> >>>
> >> >>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
> >> >>> program execution, it doesn't do anything with the commands inside
> the
> >> >>> clause but remembering "I should do this in case an error occurs".
> >> So, line
> >> >>> 1020 is not executed if no error occurs in line 1050. But in case
> >> there is
> >> >>> an error (the interpreter choking on the MANIFEST statement it
> >> doesn't know
> >> >>> when TT is not loaded), line 1020 is executed, telling us TT is not
> >> loaded.
> >> >>>
> >> >>> After 1020 was executed, the program is continued at the point
> /after/
> >> >>> the error occurred.
> >> >>>
> >> >>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
> >> >>> processing back to "normal".
> >> >>>
> >> >>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050
> was
> >> >>> executed without a problem, and set to 0 in case there was an error.
> >> >>> Because we have made sure line 1050 is the only line that can be
> >> executed
> >> >>> while error processing is active, we clearly know the 

Re: [Ql-Users] EasyPTR vs Button Frame :-)

[Per Witte via Ql-Users]

Yes, but not with Wman. You have to devise your own.
Per

On 4 September 2017 at 20:20, Giorgio Garabello via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hello to all.
> Has anyone ever tried to insert an EasyPTR menu inside the Button Frame?
> Is it possible?
>
> Greetings
> Giorgio
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] EasyPTR vs Button Frame :-)

[Per Witte via Ql-Users]

PS You will probably also need some kind of toolkit to reserve and release
a slot in the Button Frame. If you dont have one and dont feel like writing
your own, you may use mine. Its just over 300b of code.
Per

On 4 September 2017 at 23:02, Per Witte  wrote:

> Yes, but not with Wman. You have to devise your own.
> Per
>
> On 4 September 2017 at 20:20, Giorgio Garabello via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
>
>> Hello to all.
>> Has anyone ever tried to insert an EasyPTR menu inside the Button Frame?
>> Is it possible?
>>
>> Greetings
>> Giorgio
>> ___
>> QL-Users Mailing List
>>
>>
>>
>
___
QL-Users Mailing List

Re: [Ql-Users] Strange channel bugs?

[Per Witte via Ql-Users]

Is this the sort of issue you mean?

100 CLS
110 FOR i = 0 TO 4
120  FOR j = 0 TO 4
130   AT i * 2, j * 6: PRINT i; ','; j;
140  END FOR
150 END FOR
160 :
170 PRINT
180 PAUSE

RUNs fine under SMSQ/E, displays only the first line if compiled as a Qlib
job (but no errors or warnings are given - either at compile time or when
executing). Turbo, even under SMSQ/E, kicks up a fuss at parse time, and if
you load it in SuperBASIC under Qdos or Minerva lines 140 and 150 show up
as MISTake's. So its normally a good idea to try out problematic code in
different environments. It doesnt necessarily have to work 100% before
certain mistakes reveal themselves.

Just my penny's worth..

Per

On 12 November 2017 at 13:54, Bob Spelten via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Op Tue, 12 Sep 2017 18:47:35 +0200 schreef Bob Spelten :
>
> What's happening?
>>
>> I have successfully compiled a new version of my program.
>> That's to say, there were no errors reported by BasicLinker or Qlibeator.
>> But when the _obj is executed nothing seems to happen, no menu to act on.
>> It's there in the JOBS list but no channels were opened for it.
>> When I then kill this job it has the effect that the QD with the
>> programs  _bas can no longer produce lists of my Procs and FNs from the
>> C-F6 to C-F8 buttons or keys.
>>
>> (...)
>>
>> It's been 2 month since I reported this problem.
> After many attempts to locate the problem Wolfgang Lenerz finally found
> the culprit.
> It was one missing index variable on an END FOR line.
>
> "Unnamed NEXT, EXIT and END statements" is a feature of SMSQ/E.
> Normally I am no fan of this as it can make the program more difficult to
> read, especially when start and end of the loop are far apart.
> This one (actually two) had escaped my proof reading.
>
> Now it turned out Q_Liberator also cannot deal with it and can, as was the
> case here, corrupt SMSQ/E in a sneaky way without a Sysmon alarm.
> So be warned, don't use this "feature" with Qlib!
>
>
> Bob
>
> --
> The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/;
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] Theme file format

[Per Witte via Ql-Users]

Sorry, that was supposed to be:

header
dc.b "THB",57;  not "THM",57
data
dc.w $200
dc.w $FFC0
etc..

On 13 November 2017 at 17:59, Per Witte  wrote:

> > Theme file format
> > I had a look at Theme file format on QL forum. Some
> > comments and questions:
> >
> > Rethorical question: Is it worthwhile to create a new
> > format to save some space (a few bytes, I suppose)
> > when we have (QPC2, SMSQmulator)  128MB at our disposal?
> Despite computers getting ever faster and bigger, the likes of
> Windoze still seem slow at times, and just as soon run out of space -
> as they always did.. That may partly be down to BLOAT and lazyness.
>
> In the case of the "QL", software might be expected to run on a wide
> variety of platforms, some fast and big, some slow and tight. IMHO,
> efficiency is rarely a bad thing unless achieving it is considerably
> more costly that what it is likely to save.
>
> I dont know where the current theme file format originated, but a few
> programs use that. It is sometimes (usually?) given the extension
> _thm. It is a pure text file that looks like this:
>
> $200
> $FFC0
> .. etc altogether 57 lines
>
> To load a palette (theme) youd use something like:
> ..
> FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
>  INPUT#ch; it$
>  POKE_W addr + ofs, HEX(it$(2 to))
>
> Whats not to improve? ;)
>
> I propose to use a binary format (see below) and use LBYTES instead.
> This cuts space and time, and would allow a number of such files to
> be concatenated. But instead of LBYTESing any kind of rubbish, I
> suggested we make a header that would give a strong indication, if
> not absolute certainty, that we were loading the right kind of file.
>
> A number of file formats on the QL scene dont have headers, and this
> sometimes causes confusion not to mention frustration and the
> potential for inelegant crashes unless preventive steps are taken by
> each and every program using them. The _scn extension, for example
> means widely different things..
>
> > Not all palette files have 57 entries.
> Well, thats the current tally, as given by the Wman2 function
> SP_GETCOUNT. If that were to change, a file header might help to
> identify that fact quickly.
>
> > In fact, a complete palette should have 58 entries.
> > The original author forgot to reserve a slot for the
> > border of the error window. Doesn’t a new format imply
> > a rewrite of existing programs?
> No.
>
> > Will Qspread, QD, Files,... comply?
> I dont think any of them load external palettes. If they do, they
> will no doubt happily continue to use whatever standard theyre
> using now.
>
> > Afraid of having 57 entries filled with wrong data?
> Not afraid, as loading the wrong data will not crash the program,
> only display strange colours. POKEing or LBYTESing more data than
> ALCHPed would be seriously problematic.
>
> > Why not create a new type of file? I would suggest type
> > 84 (T for theme).
> File types are sadly not much supported in QL land. Defining a new file
> type could cause problems - for existing file managment programs, for
> example.
>
> > Just my two cents.
> Glad for your interest so this matter can be finalised.
>
> The current suggestion is for theme files to have an additional
> format to the existing one. It will be dead easy to convert theme
> files between "standards", so programmers can choose to support the
> new standard (if it becomes one) - or not. The reason Im bringing this up
> is
> to try to prevent a third and a fourth "standard" to emerge (unnecessary
> creating confusion and nonsense), by engaging anyone who has an
> opinion to "speak now or be forever silent" (as they say at the wedding
> ceremony in the C of E.) As mentioned, the file will be binary, but I
> describe it here in assembler for clarity:
>
> header
> dc.b "THM",57
> data
> dc.w $200
> dc.w $FFC0
> etc..
>
> Other suggestions have been made. This is V3.0, currently my
> preferred option, but Im open to improvements, including a header-less
> binary, considered earlier on.
>
> Per
>
> On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
>
>> Hi,
>>
>> Theme file format
>> I had a look at Theme file format on QL forum.
>> Some comments and questions:
>>
>> Rethorical question: Is it worthwhile to create a new format to save some
>> space (a few bytes, I suppose) when we have (QPC2, SMSQmulator)  128MB at
>> our disposal?
>> Not all palette files have 57 entries.
>> In fact, a complete palette should have 58 entries. The original author
>> forgot to reserve a slot for the border of the error window.
>> Doesn’t a new format imply a rewrite of existing programs?
>> Will Qspread, QD, Files,... comply?
>> Afraid of having 57 entries filled with wrong data? Why not create a new
>> type of file? I would suggest type 84 (T for theme).
>> Just my two cents.
>>
>> Have a nice day.
>>
>> François Van Emelen
>>
>>
>>
>> 

Re: [Ql-Users] Theme file format

[Per Witte via Ql-Users]

> Theme file format
> I had a look at Theme file format on QL forum. Some
> comments and questions:
>
> Rethorical question: Is it worthwhile to create a new
> format to save some space (a few bytes, I suppose)
> when we have (QPC2, SMSQmulator)  128MB at our disposal?
Despite computers getting ever faster and bigger, the likes of
Windoze still seem slow at times, and just as soon run out of space -
as they always did.. That may partly be down to BLOAT and lazyness.

In the case of the "QL", software might be expected to run on a wide
variety of platforms, some fast and big, some slow and tight. IMHO,
efficiency is rarely a bad thing unless achieving it is considerably
more costly that what it is likely to save.

I dont know where the current theme file format originated, but a few
programs use that. It is sometimes (usually?) given the extension
_thm. It is a pure text file that looks like this:

$200
$FFC0
.. etc altogether 57 lines

To load a palette (theme) youd use something like:
..
FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
 INPUT#ch; it$
 POKE_W addr + ofs, HEX(it$(2 to))

Whats not to improve? ;)

I propose to use a binary format (see below) and use LBYTES instead.
This cuts space and time, and would allow a number of such files to
be concatenated. But instead of LBYTESing any kind of rubbish, I
suggested we make a header that would give a strong indication, if
not absolute certainty, that we were loading the right kind of file.

A number of file formats on the QL scene dont have headers, and this
sometimes causes confusion not to mention frustration and the
potential for inelegant crashes unless preventive steps are taken by
each and every program using them. The _scn extension, for example
means widely different things..

> Not all palette files have 57 entries.
Well, thats the current tally, as given by the Wman2 function
SP_GETCOUNT. If that were to change, a file header might help to
identify that fact quickly.

> In fact, a complete palette should have 58 entries.
> The original author forgot to reserve a slot for the
> border of the error window. Doesn’t a new format imply
> a rewrite of existing programs?
No.

> Will Qspread, QD, Files,... comply?
I dont think any of them load external palettes. If they do, they
will no doubt happily continue to use whatever standard theyre
using now.

> Afraid of having 57 entries filled with wrong data?
Not afraid, as loading the wrong data will not crash the program,
only display strange colours. POKEing or LBYTESing more data than
ALCHPed would be seriously problematic.

> Why not create a new type of file? I would suggest type
> 84 (T for theme).
File types are sadly not much supported in QL land. Defining a new file
type could cause problems - for existing file managment programs, for
example.

> Just my two cents.
Glad for your interest so this matter can be finalised.

The current suggestion is for theme files to have an additional
format to the existing one. It will be dead easy to convert theme
files between "standards", so programmers can choose to support the
new standard (if it becomes one) - or not. The reason Im bringing this up
is
to try to prevent a third and a fourth "standard" to emerge (unnecessary
creating confusion and nonsense), by engaging anyone who has an
opinion to "speak now or be forever silent" (as they say at the wedding
ceremony in the C of E.) As mentioned, the file will be binary, but I
describe it here in assembler for clarity:

header
dc.b "THM",57
data
dc.w $200
dc.w $FFC0
etc..

Other suggestions have been made. This is V3.0, currently my
preferred option, but Im open to improvements, including a header-less
binary, considered earlier on.

Per

On 13 November 2017 at 15:50, François Van Emelen via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> Theme file format
> I had a look at Theme file format on QL forum.
> Some comments and questions:
>
> Rethorical question: Is it worthwhile to create a new format to save some
> space (a few bytes, I suppose) when we have (QPC2, SMSQmulator)  128MB at
> our disposal?
> Not all palette files have 57 entries.
> In fact, a complete palette should have 58 entries. The original author
> forgot to reserve a slot for the border of the error window.
> Doesn’t a new format imply a rewrite of existing programs?
> Will Qspread, QD, Files,... comply?
> Afraid of having 57 entries filled with wrong data? Why not create a new
> type of file? I would suggest type 84 (T for theme).
> Just my two cents.
>
> Have a nice day.
>
> François Van Emelen
>
>
>
> ___
> QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Fwd: Re: Theme file format

[Per Witte via Ql-Users]

As mentioned, the suggested binary standard would be in addition to the
established text standard as used by QCoCo. Its easy enough to convert
files back and forth between these formats. So pundits and punters are free
to choose. A possible advantage with having a header, such as "THB9" (where
9 = chr$(57)) would be so that when one VIEWs a file with the _thb
extension one can easily see what kind of file it is, However, a headerless
file would be the simplest, as one could then just:

thl = FLEN(\themefile$)
tha = ALCHP(thl)
LBYTES themefile$, tha
SP_JOBOWNPAL -1, tha

Should a standard palette at some point contain 58 or 102 entries, it would
still load alright and, presumably Wman would know what to do with it. If
one were to load an old, 57 entry theme file by mistake, the program
wouldnt crash or anything, just display some weird colours.

> <> why not have a standard
> theme file that can be edited with MenuConfig. One could probably have
> the "SCLx" extension, which would give you enough options to play
withedit
> (SCL0-9, SCLA-Z, SCLa-z). Of course, parsing that would be even more
> difficult.

To me it would make more sense to use Config to select one of a number of
predefined themes, rather than use it to edit the themes themselves, which
is a design, rather than a configuration problem. We've got the excellent
QCoCo for that.

Per



On 14 November 2017 at 13:01, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> Hi,
>
> >> Theme file format...
> >> Rethorical question: Is it worthwhile to create a new
> >> format to save some space (a few bytes, I suppose)
> >> when we have (QPC2, SMSQmulator)  128MB at our disposal?
>
> It's the typical chicken-and-egg problem - if you don't have any
> standard, nobody is (ever) going to use it. If you create a standard
> now, nobody is currently using it (exept perhaps some in-house
> productions) - but somebody **might** in the future.
> You will not be worse off with the latter, but maybe better.
>
>
>
> > Despite computers getting ever faster and bigger, the likes of
> > Windoze still seem slow at times, and just as soon run out of space -
> > as they always did.. That may partly be down to BLOAT and lazyness.
>
> Or to legibility. I'd personally prefer a text file - because it is text
> and you can alter it with a simple text editor which is generally faster
> than using spmething like wined to edit the bianry file directly.
> Granted, you can also totally muck it up by merrily editing the file
> beyong all recognition, but -to me- that would be a small price to pay.
>
>
> > In the case of the "QL", software might be expected to run on a wide
> > variety of platforms, some fast and big, some slow and tight. IMHO,
> > efficiency is rarely a bad thing unless achieving it is considerably
> > more costly that what it is likely to save.
>
> True. On the other hand, a program would normally only do that when
> starting up and the time taken to parse the palette file, compared to
> the time taken to start up, would probably not be very important.
>
> > To load a palette (theme) youd use something like:
> > ..
> > FOR ofs = 0 to SP_GETCOUNT - 2 STEP 2
> >  INPUT#ch; it$
> >  POKE_W addr + ofs, HEX(it$(2 to))
> >
> > Whats not to improve? ;)
> >
>
> Actually, I would prefer:
> 00 : $200
> 01 : $ff00
>
> etc
>
> Thay way, I'd know right away what to edit.
>
> > I propose to use a binary format (see below) and use LBYTES instead.
>
> The debate of plain text config files (large, take a while to process)
> vs binary files (unreadable to us normal humans) isn't new...
>
> > This cuts space and time, and would allow a number of such files to
> > be concatenated.
>
> You could also concatenate text files.
>
> > But instead of LBYTESing any kind of rubbish, I
> > suggested we make a header that would give a strong indication, if
> > not absolute certainty, that we were loading the right kind of file.
>
> Oh, if you want something standard, a header is definitely needed. A
> program could perfectly well only use the first 30 or so of the colours
> and have a theme file only for those. One would need to know honw many
> colurs are un that aplette file. I do notice that your proposal seems to
> have the number of colours (after the "THM")?
>
> >> In fact, a complete palette should have 58 entries.
> >> The original author forgot to reserve a slot for the
> >> border of the error window. Doesn’t a new format imply
> >> a rewrite of existing programs?
>
> Not unless they want to use the new format. As I said above, if they
> don't use it, you're not worse off than now.
>
> >
> >> Why not create a new type of file? I would suggest type
> >> 84 (T for theme).
> > File types are sadly not much supported in QL land. Defining a new file
> > type could cause problems - for existing file managment programs, for
> > example.
>
> A certin number of prowess progs have a different filetype if I'm not
> mistaken. The problem here is that, apart from maybe being a 

Re: [Ql-Users] SMSQmulator 2.25

[Per Witte via Ql-Users]

Great!

Im particularly pleased that many of the differences in behaviour between
SMSQmulator and QPC2 have been ironed out! That means that programmers dont
have to write separate versions, or include fiddly workarounds, in their
programs. They run identically on both platforms. Amazingly, this also
includes some lower-level stuff, such as accessing many host platform
facilities - at least where they both run under Windoze. Am I right in
thinking that ound has also improved?

The great thing about SMSQmulator is that we now have an SMSQ/E platform
that will run on just about any host that supports Java - both now and in
the foreseeable future. Many people, me included, didnt see the point, when
Wolfgang first suggested the idea, back in 2010, in Vienna. But he has
proved his point! This is now a very usable, stable, and mature product.

Thanks Wolfgang! Im sure having fun!

Per

On 5 November 2017 at 10:37, Wolf via Ql-Users 
wrote:

> Hi all,
>
> I just released SMSQmulator 2.25
>
> Have fun.
>
> Wolfgang
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] EXT_PROC

[Per Witte via Ql-Users]

Thanks Dilwyn. It seems Jon S is already on the case of appending it.

Per

On 9 November 2017 at 20:19, Dilwyn Jones via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> I've OCRed Chapter 15 from my copy of the manual and placed it as PDF and
> Word DOC file at http://www.dilwyn.me.uk/qlib/index.html
>
> Would be delighted if it could be added to the manual already on that page.
>
> Note that it was done in a hurry and I've only hurriedly gone through the
> OCRed file so there are probably dozens of misstakkes in it.
>
> Dilwyn
>
> -Original Message- From: SMSQE
> Sent: Thursday, November 09, 2017 1:28 PM
> To: ql-us...@q-v-d.com
> Cc: 'Dilwyn Jones'
> Subject: RE: [Ql-Users] EXT_PROC
>
>
> My version of QLIB didn't come with such a supplement for some reason, so
> it
> won't be in the manual I created. If I can get the supplement, I'll update
> the manual.
>
> Jon
>
> -Original Message-
> From: Ql-Users [mailto:ql-users-boun...@lists.q-v-d.com] On Behalf Of
> Dilwyn
> Jones via Ql-Users
> Sent: 09 November 2017 01:01
> To: ql-us...@q-v-d.com
> Cc: Dilwyn Jones 
> Subject: Re: [Ql-Users] EXT_PROC
>
> Chapter 15!?
>>
> An 8 page supplement entitled "Release 3.3 Enhancements"
>
> Headings (to give you an idea what it covers):
>
> Introduction
> Notes For Minerva Users
> SuperBASIC Changes With Minerva
> WHEN Handling
> WHEN ERROR
> Entering WHEN ERROR
> Exiting WHEN ERROR
> Turning Off WHEN ERROR
> WHEN ERROR and Q_ERR
> WHEN ERROR in compiled programs
> WHEN ERROR and Externals
> WHEN variable
> Stopping WHEN Processing
> WHEN variable in compiled programs
> Trace Options
> Error Console
> Free Running Procedures
> QLIB_SYS
> New Error Messages
>
> If anyone has time to OCR this I'll gladly post it on my QLib page - I'm
> afraid I don't know if the information has been integrated into the v3.36
> manual on my site or not.
>
> Dilwyn
>
> ___
> QL-Users Mailing List
>
>
> ---
> This email has been checked for viruses by AVG.
> http://www.avg.com
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] EXT_PROC

[Per Witte via Ql-Users]

Thanks Giorgio!

It turns out that Dilwyn has a very nice, up-to-date version on his site,
at http://www.dilwyn.me.uk/qlib/index.html.

Earlier this year I looked around for one, but found only various poor
scans of (as I discovered today) older versions. Dilwyn's seems to be the
last word on Q-Liberator manuals - for now! (Lets hope that will soon
change - when the next version of Qlib arrives...)

Per

On 8 November 2017 at 23:07, Giorgio Garabello via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Me!
> take me 10 minutes to send you some photos
>
> Giorgio Garabello
>
> 2017-11-08 21:05 GMT+01:00 Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com>
> :
>
> > I was just made aware of a number of features in Q-Lberator that I havent
> > seen documented anywhere: EXT_PROC, EXT_FN, GLOBAL, and possibly others.
> I
> > believe I have a general idea of what theyre about, but should like to
> see
> > some documentation. Ive been told there is a chapter 14 in some manuals?
> > The two pdf manuals I found online, one of them claiming to be of V3.36,
> > dont mention these keywords, and my printed one is altogether of an older
> > vintage.
> >
> > Anyone?
> >
> > Per
> > ___
> > QL-Users Mailing List
> >
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] EXT_PROC

[Per Witte via Ql-Users]

Chapter 15!?

On 9 November 2017 at 00:03, Bob Spelten via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Op Wed, 08 Nov 2017 21:05:55 +0100 schreef Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com>:
>
> I was just made aware of a number of features in Q-Lberator that I havent
>> seen documented anywhere: EXT_PROC, EXT_FN, GLOBAL, and possibly others. I
>> believe I have a general idea of what theyre about, but should like to see
>> some documentation. Ive been told there is a chapter 14 in some manuals?
>> The two pdf manuals I found online, one of them claiming to be of V3.36,
>> dont mention these keywords, and my printed one is altogether of an older
>> vintage.
>>
>> Anyone?
>>
>> A version of the manual is at Dilwyn's download site.
> < http://www.dilwyn.me.uk/qlib/Q_Liberator%203.36%20manual.pdf >
>
> I just did a quick check of the .pdf against my original 3.36 printed
> manual and everything including chapter 14 is there.
> However chapter 15 (Release 3.3 Enhancements) from my copy is missing from
> the .pdf.
> I'll try to scan this asap.
>
> Bob
>
>
>
>
> --
> The BSJR QL software site at: "http://members.upc.nl/b.spelten/ql/;
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

[Ql-Users] EXT_PROC

[Per Witte via Ql-Users]

I was just made aware of a number of features in Q-Lberator that I havent
seen documented anywhere: EXT_PROC, EXT_FN, GLOBAL, and possibly others. I
believe I have a general idea of what theyre about, but should like to see
some documentation. Ive been told there is a chapter 14 in some manuals?
The two pdf manuals I found online, one of them claiming to be of V3.36,
dont mention these keywords, and my printed one is altogether of an older
vintage.

Anyone?

Per
___
QL-Users Mailing List

Re: [Ql-Users] sBASIC overloading...

[Per Witte via Ql-Users]

Im not familiar with C++ overloading, but S*BASIC allows some "parametric
polymorphism", viz:

dim x%(2): for i% = 0 to 2: x%(i%) = 9 - i%
Test 'abc', 2.99, x%
:
def proc Test(a, b%, c)
print a\ b% \ c, \
enddef Test
:
Result:
abc
2.99
9  8  7

The SBASIC compiler performs a number of additional passes to SuperBASIC's
parser, to end up with a much purer "executable". The compiled program is
not machine code, of course, it consists of fixed length tokens that still
need to be "interpreted". But all useless baggage has been eliminated from
the program flow, expressions teased into simple RPN steps, and locations
resolved to absolute addresses. So no, the size of the program or distance
to procedures does not effect the speed of execution.


On 20 June 2018 at 22:35, Dave Park via Ql-Users 
wrote:

> Hi all,
>
> How hard would it be to extend sBASIC functions to support C++ style
> overloading?
>
> Separately, does the sBASIC in SMSQ or Minerva still scan for
> procedures/functions from the beginning of the program, so earlier FN/PROCs
> have a speed advantage over later ones like in JM/JS?
>
>
> --
> Dave Park
> d...@sinclairql.com
> ___
> QL-Users Mailing List
>
>
___
QL-Users Mailing List

Re: [Ql-Users] QD 2018

[Per Witte via Ql-Users]

Thank you, Marcel - !

On Sun, 16 Sep 2018 at 00:55, Marcel Kilgus via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> I have just updated QD 2018 to version B.05:
>
> ; B.05  Implemented per-extension editor-usage (configurable) (MK)
> ;   Fixed BASIC usage for DEFine FuNction (MK)
> ;   Fixed colours in replacement confirmation dialog (MK)
> ;   Fixed DO on resize to keep the x window size (MK)
> ;   Bottom right corner stays where it is on normal resize (MK)
> ;   Allow CTRL+Z (mark current line) in read-only mode (MK)
>
> As previously with the tab settings the editor-usage can now be
> configured per extension, so you can say all "_bas" (or "_bsl" ;) )
> files automatically invoke the "BASIC" editor usage, for example.
>
> The rest is the stuff we've already talked about here.
>
> https://www.kilgus.net/smsqe/qd/
>
> Cheers, Marcel
>
> ___
> QL-Users Mailing List
>
>
___
QL-Users Mailing List