@betseg The only reason to ever use Classic is if you are trying to solve a challenge that involves the binary representation of your code's characters. (And very large databases with accented characters may save some memory by using Classic.) For all normal purposes (even golfing), you should use Unicode, as you can (implicitly) refer to SBCS so that you may count each character as a single byte.
$ /opt/mdyalog/16.0/64/unicode/mapl
Please execute /opt/mdyalog/16.0/64/unicode/make_scripts to generate a configured /opt/mdyalog/16.0/64/unicode/mapl
$ /opt/mdyalog/16.0/64/unicode/make_scripts
$ /opt/mdyalog/16.0/64/unicode/mapl
Stream 0: /opt/mdyalog/16.0/64/unicode/aplkeys/default line : 1 file not ASCII / not terminated by newline. ""
@betseg (This is Jay typing as Adam) did you manually unpack the .deb or .rpm package? Have you seen the post-install script that normally gets run after a proper automated install?
@betseg Did you use rpm2cpio? If so, I think the problem is that it doesn't preserve hard links. aplkeys/default and apltrans/default should each be a link to the "xterm" file in the same directory.
OK, I used a script called debtap that turns .deb files into Arch Linux package files and I was struggling with the post-install script because debtap removed an if block but forgot to remove the fi, but after fixing the script dyalog is installed.
i.sstatic.net/qEBql.png @JayFoad CLI interpreter works but Ride still says it can't find it, is there more to the packages then hard links because rpm2cpio didn't output anything more than what I could do without it.
@betseg Does the drop-down box just above that say "v16.0, 64-bit, Unicode" ?
@betseg If you hit F12 in RIDE after it has failed to start the interpreter, you can get a Javascript console. Are there any useful error messages there?
@betseg Does your mapl script definitely have executable permissions?
$ wolfram
Wolfram Language 11.2.0 Engine for Linux x86 (64-bit)
Copyright 1988-2017 Wolfram Research, Inc.
In[1]:= ExternalEvaluate["Python", "from pynapl import APL; APL.APL().eval('2+2')"]
Out[1]= 4
Yes, but before that: ExternalEvaluate["Python", "from pynapl import APL; APL.APL().eval('''⎕sh 'python -c \"print(2+2)\"' ''')"] ==> {4}
@Adám {{}, {}}, {}, and {}, respectively.
@Adám I'm also intrested in how namespaces would be evaluated, what's some APL I can test? I don't really know namespaces yet.
I've just tested, you can't evaluate an APL function and get back a Mathematica function. This is a limitation of pynapl. Although really, that would be borderline wizardry if it worked.
Python gets back an empty dictionary from pynapl, then sends the empty dictionary to Mathematica.
@Adám Going the other way (call mathematica from Dyalog) would be much harder. There isn't anything that exists to call Mathematica from any language and get back an actual object in that language. However, Mathematica provdes a means to export functions as a dll. I don't know how loading this dll from C would go.
@Pavel Association lists will probably not work, but I don't see why simple (non-nested) arrays shouldn't arrive in a sane format. E.g. Math calls Fortran90 functions to compute Eigenvalues.
@Adám Because even compiled functions can return Mathematica symbolic values (e.g. Pi) rather than floats that Dyalog can make sense of. It could work sometimes, but not consistently enough to be useful.
@Pavel 'first line',(⎕UCS 10),'second line' Yes, it is verbose, but at least there are no characters that need escaping etc. When I need it multiple times, I define nl←⎕UCS 10 and then 'first line',nl,'second line',nl,'third line'
@Pavel To write a Unicode file is just (⊂content)⎕NPUT 'filename' or (⊂content)⎕NPUT 'filename' 1 if you want to overwrite rather than throw an error on clash with existing file.
@Pavel To append you either need to use the methods @J.Sallé linked to, or do additional_content ((⊂,∘⊃∘⎕NGET)⎕NPUT 1,⍨⊢) filename'`
@Pavel I would love to. However, know that I just arrived home from work so my responses may be delayed. My wife leaves for work tomorrow at 8:15 UTC so at least then I'll have time… What have you got?
# Wolfram code to evaluate is stored in $CODE
echo 'Needs["CCodeGenerator`"]' > /tmp/INTEROP.wls
echo -n 'LibraryGenerate[Compile[{}, (' >> /tmp/INTEROP.wls # `echo -n` just means no newline
echo -n $CODE >> /tmp/INTEROP.wls
echo ')], "export"]' >> /tmp/INTEROP.wls
wolframscript /tmp/INTEROP.wls > /dev/null
# Creates file called "~/.Mathematica/SystemFiles/LibraryResources/Linux-x86-64/export.so" on Linux
# This is a shared object (dll) containing the function `export`
# Called with no arguments, this function gives the result of evaluated code
This shell snippet produces a dll (or rather an so on my Linux machine)
On Mac it produces the same file but export.dylib instead of export.so. I'm not sure where it goes on Windows
The function for import the result could have its argument all as string (and Mathematica does conversion) the same the result as string (and Mathematica does conversions)
@Adám The function export isn't doing the exporting, it's the exported function. If you call the above script with $CODE='2+2', export would be roughly equal to return 4;. It doesn't take anything as a parameter.
@Adám Remember my original concern that the data wouldn't be comprehensible to Dyalog? You can take a look at the generated C for a function called interopfun and the expression 2+2:
@Pavel While I know almost nothing of C, it does look like we need to capture that I0_0 somehow, but if the function doesn't return it, it seems a bit hopeless.
@Pavel Never mind.
@Pavel Wait, doesn't all this mean that export.so will have a function called interopfun which returns that mint *Res which is the result we want?
The result is stored in whatever *Res points to. Mathematica knows what Res is pointing to, but Dyalog doesn't.
Code export functionality in Mathematica is not at all there for the purpose of allowing you to use Mathematica constructs in other languages. They're there just to increase performance of mathematica libraries, since compilation is faster than interpretation.
I actually think it's intentionally designed like this, and nothing can be done since Mathematica is proprietary software.
The only way I can imagine this working is to produce C, then modify that C to return Res. This will let Dyalog to look at the blob of binary data that represents the return value. From there, it would have to be parsed - it's not just a number, it's a list that first contains the type, than other metadata, and then the number. For complex types like arrays it would be near impossible.
@Adám It would still have to go through that other lang's python interop library f it has one and then pynapl. I'm not good enough to marshal, say, Ruby objects to APL objects without builtins.
@Pavel Question is if there is anything to be gained for an APLer to be able to call those languages… Python has a lot of useful libraries, and R has a lot of statistical tools, but we already have good bridges to those two. C/C++ (and other languages which can compile to so/dylib/dll) are easy to use. What other bridges would actually be useful? Though of course everyone (except for J) may benefit from the ability to call APL.
@Pavel Me neither (duh, I only know APL), but again, I doubt there is much for the APLer to gain there, and MATLAB/Octave users may as well just switch to APL if they desire APL…
@wizzwizz4 You're very welcome. Yeah, I think especially the first 10 lessons turned out really well. I'm thinking of editing them into a booklet "APL a day – APL in 24 hours for the impatient programmer"
@EriktheOutgolfer Why? May I not quote two messages from SE chat without quoting what's between them? Anyway, I didn't intend to include anything verbatim, just follow the order and looking at questions that were asked to know what to include.
@EriktheOutgolfer Happens to me a lot that I end up editing my previous message rather than responding with a new message.
