APL386 and DOSemu under Linux and X

[gem...@idirect.com]

I am using the DOSemu version 1.4.0, running under Fedora 9 Linux to
run the old Manugistics APL Plus 2 (APL386.EXE or APL387.EXE)
environment. Previous versions of DOSemu did not run this full-
featured APL environment. Many features of the DOS APL are present and
work - including direct support of large workspaces. I am running
DOSemu version 1.4.0.0, built from source, and have run as "dosemu -
s" (root priv.) to see it that would resolve the problem I've
discovered. It did not. Although I can load and save APL workspaces,
and run excellent high-resolution graphics within the DOSemu/X-windows
environment, I cannot seem to refer to any APL direct-access files,
typically called xxxx.SF files (eg: DATASR1.SF). I have tried numerous
combinations and permutations of file names, but the APL intrinsic to
"tie" a file - a QuadFTIE or QuadFSTIE command, yields a "File Name
Error" or a "File Not Found" error. Curiously, I can execute special
code in a function called "rdASCII" to recognize and successfully read
an ordinary ASCII file. This code uses the QuadNTIE (for Native File
Tie) language intrinsic. The '.SF' files are binary files. What is
curious is how the APL interpreter simply cannot even recognize the
*.SF files, despite being able to load and save workspace files (they
are 'xxxxx.WS' files). The *.WS and *.SF files are just binary files,
and it is curious that only QuadFTIE fails.
Other than not being able to recognize my APL database files, the
DOSemu+APL386 combo seems to perform remarkably well. The graphics is
particularly impressive, and I am seeking a workaround here that would
let me get the APL Plus 2 environment working correctly under Linux.
My Linux version is Fedora Version 9, which is running well, all
features, on 3 machines now - two desktops and a laptop. I don't have
the APL font running - but then, I didn't have it running in Windows-
XP, where I have also been running my APL Plus 2 workspaces for
years... (In the Windows-XP environment, I have no file access
problems, but the graphics routinely scrambles after running for a
while - I get actual "snow crashes" on my Toshiba sometimes, which I
suspect is due to issues with the Nvidia graphics acceleration). But
APL386 running under DOSemu on Fedora 9 Linux, under X-Windows,
provides graphic displays that are solid, and problem-free, so I would
like to find a fix or work-around to the file access problem. Thanx
for any response.
- Rus

[Reinhard Karcher]

gem...@idirect.com schrieb:

> I am using the DOSemu version 1.4.0, running under Fedora 9 Linux to
> run the old Manugistics APL Plus 2 (APL386.EXE or APL387.EXE)
> environment.

You could try to build the latest dosemu from svn yourself.
Use the debug options to find out, what file DOSemu actually is looking
for and where.
Do you use a 32-bit or a 64-bit linux?

Reinhard

[gem...@idirect.com]

On Jan 25, 2:33 am, Reinhard Karcher <karcher1...@gmx.net> wrote:
> geme...@idirect.com schrieb:

Hi,
I'm running an older kernel, Fedora Release 9 (Sulphur), which is
Linux
Kernel 2.6.25.4-30, under a Gnome Desktop 2.22.1. Must be 32 bit.
It works well, and so far, I've been able to run everything correctly
on
APL387, except access to the binary direct-access *.SF files.
The share tie (ie. 'filename' QuadFTIE channelnum) fails with a
message
of 'FILE NAME ERROR'. And yet QuadNTIE can open a 10,000 record
ASCII file, and load it into the workspace successfully in AND
create a chart from it, and display it successfully IN A WINDOW,
which is more than my Windows machines could ever do. (It would
routinely scramble the graphics display after a few charts.)
So, I am very impressed with this emulator, and for now, my
workaround is to just dump the database tables en-mass, into seperate
ascii files, and ftp them to the Linux box. DOSemu/APL387 gives
me what I've always wanted - a bulletproof, bug-free APL, with big
workspaces (I can get 19.5 megabytes on my ancient 256mb Pentium
running Fedora - probably much more on a bigger memory machine).
But I will try your idea. I haven't built from SVN, and will
need to determine how it is done. Do I install "patches" over
the existing code, or is there a "development" tarball somewhere?
- Rus

[Reinhard Karcher]

gem...@idirect.com schrieb:

> But I will try your idea. I haven't built from SVN, and will
> need to determine how it is done. Do I install "patches" over
> the existing code, or is there a "development" tarball somewhere?

To build from svn:
The URL is https://dosemu.svn.sourceforge.net/svnroot/dosemu, look at
the svn documentation how to get it.

Without svn:
Look at http://dosemu.sourceforge.net/stable/. There is a link for the
1.4.0 source tarball and a link to patches for 1.4.1.

The svn version contains some bugfixes not in 1.4.1.

Reinhard

[gem...@idirect.com]

Ah, this patch-stuff was not too difficult. Thanx for the suggestion,
tho it did not solve the problem, it appears the patches address some
possible issues that might come up someday. Here is a quick How-To:

I downloaded the file "dosemu-patch-1.4.0.1" from the DOSemu website,
and from the top-level directory, where the "tar -xvf" unpacked to,
I used patchlevel of one, and applied all the patches:
Eg: If your DOSemu stuff is in /home/dosemu/dosemu-1.4.0, just
cd to that dir, and run "patch" with patchlevel of 1.

patch -p1 < dosemu_patch-1.4.0.1

This updates all the source files, and configure scripts, so one need
only do a
./configure
make
make install

to completely rebuilt "DOSemu" with the patches applied. Once
done, you see "Version DOSemu 1.4.0.1" in your DOS-Box X-window
when you start up dosemu.
To run an APL session, put the "APL-Plus II" DOS-files into a Linux
subdir on your home drive (via ftp, with the bin option - direct
from a Windows-XP box, assuming you have and ftp daemon running
on your Linux box - or use sshd and pscp if you wish...)
Assuming you have a Linux subdir called "aplv5" containing the
DOS APL-PLus II files, you need only do:

dosemu

to start the DOSemu X-window session, and then from within that
window, all the local files and subdirs on your default home
Linux drive, will show up as a DOS "D:\" directory.

Then, just cd to the "D:\aplv5" dir, and fire up APL-Plus II,
as:
D:\> cd aplv5
D:\aplv5 >
and run APL...

D:\>apl387 wssize=10

The above gives a nice, stable 10 meg workspace, and you can
load your APL Plus II workspaces, and run your code.
(The APL Plus II environment was (and is) solid and bug free.
It remains a gold-standard of APL's, IMHO..)


I don't have the APL font working yet, and I still cannot
access any "*.SF" APL direct-access files. But I can load and
save workspaces, and can read ASCII files no problem with the
QuadNTIE. QuadFSTIE still generates an error, but I think it
will take me maybe a day or two, to convert my big .SF datafile
of tables, into a structure of multiple ASCII-file tables, with a
single ASCII table providing control. (I already have all
the code to load and save the ASCII file table formats of every
thing that is in the big time-series database "*.SF" file.)
The more I thought about this idea, the more I liked it, since
disk-space is crazy cheap, and I become less tied to a stupid
proprietary file system.

The real "secret sauce" here, (or the "unique value proposition"),
is the flawless graphics display. I have a problem-free hi-res
display of the images my APL code creates, complete with mouse
support. (I can click on the graph, and get a date and a price,
from an OHLC stock-price chart, for example) That feature hasn't
worked right since the death of DOS.

The entire Linux/X-Windows is the right way to do high-power
workstations. The Windows-on-DOS thing is a nasty burp-fart,
and I look forward to moving away from it.

Given that I already own a copy of APL Plus II, and have all
this code built that uses it - to be able to bring it all back
to life, on a stable and solid technical platform, is nice.

Oh, another thing!

There is a free version of APL, called APLSE, which runs well
under this DOSemu. I just ftp'ed it from the Windows box to the
Linux box, and appears to run perfectly, and - get this - the
APL characters are present, due to the APLFONT.COM DOS program
that seems to work correctly. This mini-interpreter is only
200K in size, and is called APLSE, and the graphics runs
beautifully under this DOSemu. The APLSE was released by
Manugistics in the mid 1990's or something, and a screen comes up
explaining that it is free. (Originally for teaching purposes,
I think...)

Basically, this means that anyone wanting to mess about with
APL and APL-graphics can do so. It would be nice to see something
like this on the iPad. It would be great teaching tool.
Although I understand Apple prevents any programming languages
being sold thru their tunestore. Too bad.


On Jan 26, 2:50 am, Reinhard Karcher <karcher1...@gmx.net> wrote:
> geme...@idirect.com schrieb:

>
> > But I will try your idea.  I haven't built from SVN, and will
> > need to determine how it is done.  Do I install "patches" over
> > the existing code, or is there a "development" tarball somewhere?
>
> To build from svn:

> The URL ishttps://dosemu.svn.sourceforge.net/svnroot/dosemu, look at

> the svn documentation how to get it.
>
> Without svn:

> Look athttp://dosemu.sourceforge.net/stable/. There is a link for the

[Morten Kromberg]

> The real "secret sauce" here, (or the "unique value proposition"),
> is the flawless graphics display.  I have a problem-free hi-res
> display of the images my APL code creates, complete with mouse
> support.  (I can click on the graph, and get a date and a price,
> from an OHLC stock-price chart, for example)  That feature hasn't
> worked right since the death of DOS.

Hmm... I *DO* understand the attraction of getting lots of code to
work without changes, but a modern APL system would allow you to hook
into some pretty nice 3rd party graphics tools and let you concentrate
on doing the "hard" stuff in APL :-).

It is also a while since I saw anyone refer to 19.5Mb as a "large"
workspace :-). We've been testing the latest release of Dyalog APL
with workspaces roughly five thousand times larger than that (just
under 96Gb).

[gem...@idirect.com]

Ha, very nice! "We at Dyalog can do 96gb workspaces.." Great.
Except that I have written my own bloody graphics routines at least
4 times, and I already make extensive use of WGNUPLOT to do all
sorts of slick stuff directly from my APLWIN workspaces. Real
nice curve fitting, visual display of stats calcs, projections,
risk-calcs, and so on.

But it is my old, DOS-based APL II code that holds the bucket of
diamonds and gold... Its funny - its code I wrote a long time
back, which implements some interesting views of the world that
allow me to see things that are not obvious - or maybe are *too*
obvious?? I am really not sure. (just like in a trade that
pays off really well - you always need to remain aware that it
might just have been random luck, right?)

Anyway, I have found that my old DOS=based stuff captured some
pretty basic truth, and let me see it in clear pictures.
That code helped me avoid the insanity of the dot-com bubble,
avoid getting whacked by the runaway markets of the 2002 - 2008
bubble, and then back up the truck in late 2008 and load up,
to recover. Its been a wild, and violent ride, but I am *very*
impressed with my early efforts, that I coded up in old DOS
APL II. To bring this old code successfully back to life, on a
solid and stable platform, provides a truly wonderful opportunity.
(I have run it for years under Windows 2000 and XP, but it never
ran right.) It was not stable, due obviously to deliberate
Microsoft policies. The Microsoft programmers cannot be as
stupid as their code makes them appear. It must be part of a
simple strategy to force continuous upgrades on the kids who
now have grown up using their dreck. THey need you to buy a
new copy of gunk every year, to keep the cashflow happening,
right? So they probably have an internal "Department of
Dis-continuity", which introduces incompatibilities so that
previous software efforts are rendered worthless.

What I have learned, is that nothing really changes. All
the modern gunk just lets people watch TV on their computers,
and play virtual reality games. It burns their time, their
money, and their spirit.

Its more fun to use old code to make piles of real money,
and very carefully, deploy it in the real world, to live
away from the techno-gunk that pervades so much of current
discourse, no? Unlike most who have profited by the modern
techno-buildout, I live out in a rural area, and need to use
the wild, broken global markets to make money. I don't have
the luxury, (like most modern state-subsidized corporations)
of raising billions, destroying that wealth, and then invoicing
the taxpayer for more billions to keep the fraud running.
I live in a small, self-financing environment, and need to
actually use my computers to make money. (and not by selling
my stuff on eBay, either :) )

My old DOS APL II code turns out to provide a series of pictures
of the world that have remained clearly focused since the 1990's
(heck, really since the 1980's - since I started on this stuff
back when Ron Reagan was US prez. - We called him Ron RayGun at
the time, but he was a great man. I miss him a lot.)

I've built all sorts of goofy stuff since my old DOS stuff, but
for good old-fashioned money-making, nothing has come close.
If I had the resources of bloody Goldman-Sachs, I could have
done better. But being a "lone wolf" type, I found playing as
an independent was better. I have just seen way too many smart
guys (with 96 gigabyte workspaces?) carried out on their shields.

I tried to build my first AI for trading the news flow from the
markets back in 1981, on a Horizon North Star Z80 box. I used
Sorcim Pascal, and had a grand total of 48 kilobytes to
play with, so that I had to page program segments in and
out from the floppy, in order to get around that restriction.
When I started using APL, (which I had learned in University),
and I first got a 1 megabyte workspace, I thought I had died
and gone to heaven. The memory space seemed limitless...
Then, of course, I discovered graphics programming...

Now, I run Skype and have datafeeds to the markets, and a
microwave link to a cell-tower, and a bunch of boxes that are
fast enough... And the iPad.

I love the iPad. It is magic. But it is a just an appliance,
like a stove or a radio.

We have come full circle. I learned Javascript and Java, so
I could write some running code to do some wildly trivial
calcs on the iPad - fibonacci's, actually. Silly simple,
but at least I could multiply and divide some numbers.
The iPad without APL on it is a joke.
But it is typical of what has happened with all the power
and capability we now have. It is being used to simply
replicate all the analog gunk we already had.

But I may have the last laugh. My return to the "large" APL
workspace environment of 19mb, and quality, solid interactive
graphics - all under open-source Linux - is very, very
liberating. I am free from all the "social management"
nonsense of the modern internet, and able to return to
good, old-fashioned, hard-edged moneymaking. You have
no idea, after the crap-storm we have all been thru, just
how satisfying this is.

Hope that 96gigabyte workspace works well for ya all!
-Rus

[rusi]

On Feb 21, 11:34 pm, geme...@idirect.com wrote:
<snipped>

> But I may have the last laugh.  My return to the "large" APL
> workspace environment of 19mb, and quality, solid interactive
> graphics  - all under open-source Linux - is very, very
> liberating.   I am free from all the "social management"
> nonsense of the modern internet, and able to return to
> good, old-fashioned, hard-edged moneymaking.  You have
> no idea, after the crap-storm we have all been thru, just
> how satisfying this is.
>
> Hope that 96gigabyte workspace works well for ya all!
> -Rus

May not be what you want but I got Aplus running in linux under gnu-
emacs here:
http://www.emacswiki.org/emacs/AplInDebian

Someone recently informed me that it does not work unless emacs is
started with:
$ LANG=C emacs