Dave Westbury writes:
> Now that rings a bell. In early coding days I wrote some array handling
SBASIC
> commands (which, given a channel, filled arrays directly from a MIDI data
dump).
> They worked well under SMSQ but failed when I qliberated the program. I
just put
> it down to different data structures in Qlib'd programs, perhaps it
wasn't.
Probably not. Arrays are treated identically to the parser in Qlib :) (Not
so in Turbo :( So array handling keywords that work correctly under
S*Basic should also work with Qlib. You can skip most of the a6-rel stuff
once you know youre working inside a Qlib job, which speeds things up a
bit. And so it seems you partially can from SBAS.
<>
> O/T Qliberator
> I wonder what the status of Qlib sources are, wasn't it going to be
updated to
> deal with SMSQ some time ago? Although SBASIC is as quick as compiled, you
can't
I cant say Ive hit too many limitations using Qlib with SMSQ/E. The first
time I tried to compile something more substantial written for SBAS, I got
lots of compile, runtime, and whats worse: "phantom" errors (not a source
code logic problem, no obvious clues to whats going on) which almost made
me give up trying. But after tidying a few lable-less EXITs, un-initialised
variables, and obvious things like that it went surprisingly well. Avoiding
that
kind of SBAS "luxury", is no problem to me. You cant compile hex and
binary literals, and there are a few quirky incompatibilities, such as
PRINT ("abc")(2)
which are neither understood, nor flagged by Qlib. (As a matter of fact
theres a bug in SMSQ/E, so this is not always handled properly there either,
try
a$='abc': PRINT ('x'&a$)(4)
)
Lable-less loop controls, apart from the opening clause REPeat, are not
flagged at compile-time,
though they generate a run-time error in simple programs. (But may lead to
"phantom" errors in larger/more complex ones??)
> circulate EasyPtr extensions separately to your programs. Writing a new
program
> using TPTR and Turbo would be OK but I wouldn't like to completely rewrite
my
> old EasyPtr programs to use it :-(
If the location and format of Turbo arrays were known, and the parser could
be told to shut up about array parameters passed to m/c procedures, then
extention toolkits could test for Turbo and take the appropriate action.
Unless the header or storage format are very different, even patching some
non supported toolkits might be possible. Just a thought.
Per
