Q L H A C K E R ' S J O U R N A L
===========================================
Supporting All QL Programmers
===========================================
#31 June 1999
The QL Hacker's Journal (QHJ) is published by Tim
Swenson as a service to the QL Community. The QHJ is
freely distributable. Past issues are available on disk,
via e-mail, or via the Anon-FTP server, garbo.uwasa.fi.
The QHJ is always on the look out for article submissions.
QL Hacker's Journal
c/o Tim Swenson
2455 Medallion Dr.
Union City, CA 94587
swensont@geocities.com swensont@mail.sns.com
http://www.geocities.com/SiliconValley/Pines/5865/index.html
EDITORS' FORUMN
This issue is far later that I would like. Planning for the
West Coast Sinclair Show (for which this issue is being
prepared) took a fair amount of time. I've also been
fiddling around the house getting it ready for guests coming
to the show. I've also been distracted by some projects
from work. I'm looking foward to running Linux on my Q40
and doing some "Professional" stuff with it.
Well, after about a year, the Qliberator Source Book project
has reached a point that I have enough material to release.
Since Qliberator was only a small part of the main document,
I changed the title to the SuperBasic Source Book. The
focus was on Qliberator, Programming Toolkits, and
Programming Tools. There is no sections on the SuperBasic
langauge itself. The emphasis was on what is necessary to
produce compiled professional code. I plan to add more
information to the Source Book as I find the time. A number
of sections came from the QHJ, but were expanded with more
information. The whole document (along with many others)
can be found on my web page:
www.geocites.com/SiliconValley/Pines/5865/
Last issue covered two different languages, Perl and AWK.
This started me thinking about other languages that are
available on the QL and who, if any, uses them. A number of
people have ported different languages to the QL, from the
then popular XLISP, to the now popular Perl. Each language
has it's own features and reasons for being. What I want to
know is, who uses these languages? Has anybody done
anything useful with these languages? Do you have a
favorite language that you like to program in? If you use a
language on the QL other than Assembly, C, SuperBasic, or
Perl (we just touched it), let me know. Tell me what
language you use, what you use it for, how it suits your
needs, and provide an example of a usefull tool you've
created with the language.
STRUCTURED SUPERBASIC 2.6.1
One project keeping me away from working on the QHJ was
updating Structured SuperBasic. I've made a few minor
changes to it that allows it to much more usefull. I've
also added a new utility that makes it SSB production
easier.
The two changes are:
1 - Added a second command line argument of Starting Line
Number. This was made so that SSB would be used with the
Unix utility 'make'. Make, which comes with the C68
distribution, is a tool designed to only compile those
sections of code that have changed. With SSB, if you have a
program comprised of 5 program files, and you only change 1
one them, you have to run SSB on the whole lot (if you've
used #include statememts). Using 'make', you leave out the
#include statements and let make run the SSB filter for you.
If you have only changed 1 file, the only that file is
converted from _SSB to _BAS, then all of the _BAS files are
added together into one file (using 'cat', another Unix
utility).
I'm not saying that we all should be using 'make', but I
wanted the ability to use it built into SSB.
2 - When using the command line, if SSB fails with an error,
the _BAS file is deleted. This was need for the SSBGO, the
utility mentioned below.
3 - Better error reporting.
The new utility is SSBGO. SSBGO automates running SSB and
Qliberator. SSBGO was designed to be used with MicroEmacs.
From MicroEmacs, I would saved a file, then use the
execute-program command. I would enter:
ssbgo flp1_file &
(the & is to EXEC it and not EXEC_W it)
SSBGO will then run SSB on 'flp1_file_ssb' (_ssb is the
default extension). Once it has file_bas, it then load
file_bas in to SuperBasic, SAVEs the file to a temporary
file, checks it for the keyword MISTake and exists if one
exists. If not, it executes the LIBERATE command, which is
the command line interface to Qliberator. Qliberator then
fires up, compiles the program, and finishes. So I have
gone from having SSB source to a compiled program in just a
few minutes, with only one command. SSBGO can be use with
other editors, you just need to CTRL-C out of the editor,
EXEC SSBGO, and let it run.
SSB261_ZIP is available on my web page.
FILECONFIG
Another program that I have been working on is FileConfig.
The short explanation is that FileConfig is an automated
version of BasConfig, by O. Fink (and modified by Norman
Dunbar and Dilwyn Jones). With BasConfig, you can't edit an
existing Config Block, only create a new one. With
FileConfig, you store the definition of a Config Block in a
text file. If you need to edit a Config Block, edit the
definition file, run FileConfig, and you have a new Config
Block.
FileConfig is designed for programmers and has very minimal
error checking. It does not verify the data put into the
Config Blocks, which means that you could attempt to put the
character A into a Byte item. If you attempt this, the
results will be "undefined", which is a nice way of saying,
"you are on your own."
FileConfig is available on my web site.
MICROEMACS MACROS
Thierry Godefroy has ported over the latest version of
MicroEmacs 4.00 to the QL. He has added Pointer Environment
support for MicroEmacs, including menu items for all the
commands. This has made MicroEmacs much more appealing and
much easier to use. Just before this port, I had been
playing with a little with configuring MicroEmacs and
tinkering with macros. I have tried using macros in the
past, but I had not quite figured out how to use them. With
all the commands now available from pulldown menus, it is
very easy to execute a macro from a file.
Now that I know how to execute macros from a file, the next
thing was to figure out what would be usefull to write as a
macro.
I've looked over some macros that I found on the MicroEmacs
web page. These macros helped create HTML files. These
macros would query the user for any information it needed
when creating HTML constructs. This means that an
application could be written in macros, querying the user
for certain data, and generate an end product. Given the
maths funcions built into MicroEmacs, one could write short
little calculating programs, just like we did, years ago, on
the ZX81.
The macro I wrote to show how this works is a simple
mail-merge like application. The user creates a document,
with fields marked out where they want information to go.
Here is a short example:
@fname@ @lname@
@street@
@city@
Hello @fname@,
How are you today? How is your wife @wife@?
Signed,
Here there are fields marked for first name, last name,
street, city, and wifes' name. Since this is a text editor,
I used an at sign (@) at the beginning and end of each field
to make it distinct from the rest of the test.
The macro will first query the user for the information and
then it will go through the text file, replacing the marked
fields with the user provided data. A macro like this can
be usefull if you are writing a Christmas letter that you to
make a little more personal, but still save time in writing.
The macro is faster than editing the document yourself, or
even running the same search-and-replace queries.
The command
set %variable @"String"
tells MicroEmacs to query the user for input, showing
"String" on the command line, and store the data in the
variable %variable. Without the at sign (@), the string
"String" would be stored in %variable.
;This macro will query the user for some items
; and then replace them with marked fields in the
; text file.
goto-line 1
set %fname @"First Name : "
set %lname @"Last Name : "
set %addr @"Street Address : "
set %city @"City : "
set %wife @"Wife's First Name : "
write-message "Replacing Text ..."
replace-string "@fname@" %fname
; Need to goto to the beginning of the
; file because the search starts from
; where the cursor is to the end of file.
beginning-of-file
replace-string "@lname@" %lname
beginning-of-file
replace-string "@street@" %addr
beginning-of-file
replace-string "@city@" %city
beginning-of-file
replace-string "@wife@" %wife
beginning-of-file
write-message "Done ..."
When Thierry introduced spell checking with MicroEmacs 4.00,
it only allowed spell checking of a single word, already
marked. I thought it would be a good idea to write a macro
that would talk through a file and spell check them all.
Thierry has since mentioned that he is looking to expand the
spell checking capability to be more user friendly. But,
still the idea of writing a macro to walk through a file,
word by word, seemed like a good challenge. Below is the
macro.
store-procedure get-word
set $kill ""
!force next-word
set-mark
!force end-of-word
copy-region
set %word $kill
; write-message &cat "The Word is : " %word
!endm
end-of-file
set %end $curline
beginning-of-file
!while &less $curline %end
get-word
write-message &cat "Word is : " %word
!endwhile
PROGRAM INTERNATIONALIZATION
About 10 years ago I attended some vendor training on how to
program and extend their particular office automation suite.
One of the things that I took away from the training was how
they designed their system to adapt to many languages.
Recently the method came to mind. As I was thinking about
the possibilities of using this method in my own programs, I
pondered over it's limitations and what other methods might
be used.
After some thought I have considered three different
approaches to allowing a program to support multiple
languages:
- Text File
One file per language
- All languages stored in executable
- One executable per langauge
Before covering the different approaches, the main thing
that each approach hinges on is the storage of all output
messages in an array. Instead of having a line like this:
PRINT #3,"File Not Found"
You would have something like this:
PRINT #3,messay_array$(35)
Since the output messages are not hard coded, the array can
be changed to suit the lanuage. For every possible output
message you would have to put an entry in the array.
Granted this will make reading and maintaining the source
code more difficult, but it does make supporting different
languages so easy.
Now the difference in each appraoch is how to store the
different arrays for each language. Each method has some
pluses and minuses and each have to taken into consideration
for each programs needs.
The first method mentioned, Text File, is the method that I
learned in the training class. The developers created a
text file, in each language, of all of the possible
messages. Each file would be given a different name. The
program would expect a certain file name. The current
language would be renamed to that file name. When the
program was executed, the program would read the file and
load messages from the file into the array.
The problem with this method is the overhead of reading in
the file. If you have a program that may be exected many
times in a single session, the speed of the program will
suffer from reading in the language file each time. If you
are writing an application that once executed will run for a
while, such as a word processor or spreadsheet.
One advantage of having that messages in a text file is that
new languages can be added to the program, with no change to
the executable.
One way of getting around the overhead of reading in a text
file is to store all of the messages of all the langauges in
the executable and have a command line option or environment
variable determine which langauge is choosen. With
SuperBasic the different messages would be stored in DATA
statements. When the determination of which langauge is
made, the program would read select which DATA statements to
read into the array.
There are two disadvantages to this approach. First, the
space needed for each langauges may add signficantly to the
size of the executable. Secondly, if a new language is
needed to be added, then the program has to be recompiled.
Another approach is to create the program the same way as
the previous approach, but use conditional compilation to
create an executable for each language. This will cut down
on the amount of space needed for the message data, but it
does mean that a different executable would have to be
distributed for each langauge. If you included each
language executable on the distribution media, then this
approach may work.
Given the wide distribution of QL users and the many
different languages, having a localized version of an
application may make an application more accepted in the
community. The difficult part will be in translating the
messages into different languages. If the Text File
approach is used, then users could translate the messages
and distribute the new language file to other users. I
believe something like this has been done with various
dictionary files.