Moving from Dyalog to APLX
Aaron W. Hsu
can go from APLX to Dyalog using transfer files, but Dyalog does not seem
to support those as an output format according to the manual. I'm using
Dyalog 13.0 Unicode and APLX 5.03 Linux.
Of course, the other thing is that Namespaces aren't supported in APLX,
and these would normally be converted to Classes, but I don't think these
are done automatically, so I was hoping there might be some way to do this
without a lot of hand twiddling.
Aaron W. Hsu
--
Programming is just another word for the lost art of thinking.
Morten Kromberg
> Does anyone know of a good way to move workspaces from Dyalog to APLX?
Aaron,
Have you tried using the ]OUT user command? It should produce a
standard ATF file that we believe APLX should be able to import. The
document you are looking for is the "Workspace Transfer Guide" which
you can find at http://docs.dyalog.com.
Hope this works, if not please report any problems to our help desk.
Regards,
Morten
Aaron W. Hsu
wrote:
> Have you tried using the ]OUT user command? It should produce a
> standard ATF file that we believe APLX should be able to import. The
> document you are looking for is the "Workspace Transfer Guide" which
> you can find at http://docs.dyalog.com.
This does work to create a Transfer file, but that transfer file doesn't
actually work to get me something I can use in APLX from a file like the
Dyalog programming contest workspace, which uses namespaces.
Ibeam2000
do it often, and if you have only functions, you might try cut and
paste. You might want to try it with and without unicode. This works
pretty well going between Dyalog and APL2000. There were a few
translation errors (zilde does not translate correctly).
If you only have a couple functions, just copy them over one at a time
using the function editors of both systems.
If there are a lot of functions, I would do the following: (only one
cut and paste)
On the SOURCE system, execute:
[]VR each drop []NL 3 4 (display all functions and operators)
Then copy the entire output string to the clipboard
On the TARGET system, do the following:
X := 0 0 rho ''
Edit the empty variable
Paste the contents of the clipboard to the variable
Write an expression to break up the matrix into smaller matrices
depending on the presence of the "del" character in column 6 (?)
Every odd-numbered Del is the start of a new function
[]FX each sub-matrix - either drop off the first 6 columns (no line
numbers or Dels) - OR - if the system supports it, add carriage
returns
If the function does not fix (perhaps on account of differences in
header syntax), edit the sub-matrix by hand and try again.
You can do variables this way too, but it can be rather labourious if
they are not short numeric variables.
Aaron W. Hsu
Thanks for the suggestion. :-)
Aaron W. Hsu
Richard Nabavi
transfer format, suitable for modern APLs, for exchanging data and
programs. XML is the obvious standard to base it on.
We'd be happy to join others in defining such a format. There are
obviously some tricky issues, but I think that with a bit of careful
implementation it would be possible to come up with something very
useful.
Richard Nabavi
MicroAPL
Aaron W. Hsu
<micr...@microapl.demon.co.uk> wrote:
> We'd be happy to join others in defining such a format.
I've done a little bit of academic research in this area concerning the
portable metadata schemas surrounding Scheme code, which is much more
difficult to define than APL (which has less vendors to worry about).
I'd be interested in seeing if I can help with something like this, time
permitting.
Aaron W. Hsu
Phil Last
wrote:
I've suggested this as another agenda item at BAA-London's next
meeting on 24 of this month.
Morten Kromberg
wrote:
Yes, we should get this done this. We (Dyalog) do not have the
resource to take the lead on this at this point in time, but we agree
that it is a worthy project and, if someone else will lead the effort,
we will do our best to participate.
Morten
Dick Bowman
Before ideas get too complicated, can I modestly point anyone interested
to...
http://www.dogon.myzen.co.uk/APL/Papers/Code%20Interchange.html
Phil Last
Good, But I'd have thought the main thing would be to publish a
specification for output that as many of the vendors as are willing to
play can agree to. This would require O(n) interfaces rather than the
O(n*2) required for a bespoke two-way interface for each combo.
Any add-ons such as namespaces and classes would have to be agreed by
the players who currently support them or have expressed an intention
to do so. So long as the spec is flexible enough there's no reason
that grounded and floating nested arrays shouldn't both be included. A
vendor-specific input routine could then make of it what it wills.
The main reason for making it XML would be merely that it's a pre-
existing independent framework and wouldn't itself have to be argued
over. Not because it's intrinsically better than anything else. I
guess tagnames would necessarily have to be english but they could
easily mirror the more-or-less universal usage of terms such as
<function>, <array>, <rank>, <shape> &c.
One other reason is that the shining example of inter-vendor co-
operation is ⎕XML that is all ready and waiting to read and write the
stuff.
Morten Kromberg
> Before ideas get too complicated, can I modestly point anyone interested
> to...
>
> http://www.dogon.myzen.co.uk/APL/Papers/Code%20Interchange.html
Aside from the main thread here, just wanted to point out that your
comment on this page:
"As to whether abandoning a tightly-integrated IDE in favour of a
decoupled edit-run-reedit-rerun model is a good idea, I offer no
comment here."
... seems to be based on a false asumption: The move in the direction
of using source code in external text files is NOT intended to require
a "decoupled model" - the intention is to allow anyone who prefers the
tightly integrated IDE to stay with that model (it is VASTLY superior
in the view of most APL dusers). However, it does ALLOW other models,
for anyone who is coming to APL from a more traditional background, or
is developing web pages or other types of applications where "tweaking
an external script files and refreshing the page" is actually a
convenient way of working (but with the IDE popping up when something
fails, if you like).
It is true that there have been some issues with respect to editing
entire namespaces and classes in a single operation, but this is
really unrelated to the fact that the source code is external, and I
do believe that most of the teething problems are now behind us.