[aplusdev] A+ Workspace incompatibility? AEdit vs Aplus

Art pinaart at yahoo.com
Tue Mar 25 10:08:06 EST 2003


--- John.Mizel at morganstanley.com wrote:
> Hi Art.
> 
> Try the following for additional debug inforation.
> 
>   $dbg 1
>   $load eratos.a

Thanks, John.
I just did. I just get two more lines, i.e.,
     $dbg 1
     $load eratos
a    Loading ./eratos.a . . .
 undefined
...
a    Load of ./eratos.a finished

  vs:
     $load eratos
 undefined
...

> Have you tried the windows version from:
>   http://www.vector.org.uk/aflat/download/index.htm
Yes. That is where I got the orginal Windows binary executable code.
However, this web site does not have the "Windows" taylored code
for Aplus nor AEdit. I managed to tweak the source code to build
under Cygwin and it behaves EXACTLY the same way as the distributed
binaries and I recently observed the workspaces, e.g., "eratos.a"
manifests the same behaviour under Linux. Hence my strong suspicion
that there is a lack a of compatibility in the workspaces.

I did observe that I get more information in the Linux Xemacs
window suggesting there might be an extra "^M" embedded in the
workspace "eratos.a" which I openned from my Microsoft Windows
directory! I didn't see any funny characters with Xemacs, however,
I just peeked with Vi under Ms Windows and it shows this is
a DOS text file with no EOL.

Just to do some debug on-the-fly, I did:
 :set ff=unix
in my Vi session, saved the "eratos.a"

..... AND.....

  IT WORKS! :->

Whoa! I should'a thunk!
I've had so many problems running between Unix and Windows to
realize that DOS/Unix text are more problematic than one realizes!

Since I have the source code, would anyone at your organization
want to get the changes I make to detect this problem?
Since the ".a" files appear to be scripts, rather than what I
think of as an "APL WorkSpace" (which is just a mystic binary
object of a quasi-proprietary format), one could let the OS
handle the parsing. However, if you REALLY want them to be
binary objects, then my Un-Zipping them is what automatically
converted them to DOS text and this was wrong.

Philosophically, I would want to keep them binary vs text.
My rational is architecture. You are handling the APL symbols
which may include overstrikes and other well defined byte sequences
which I would hate to complicate with DOS vs Unix vs Mac newlines.

BTW, I am still interested in the AEdit source code. :->

Thanks & Regards,

Art


__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com



More information about the apluslist mailing list