Jürgen your code change didn't fix my problem and actually broke my workaround
please test agains my code okay ? enztec On Sat, 11 Mar 2023 12:06:05 +0100 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > Hi enztec, > > see *info libapl* (after make install). > > Best Regards, > Jürgen > > > On 3/10/23 10:59 PM, enz...@gmx.com wrote: > > hi Jürgen > > > > sorry but would you mind giving me an example of how to use this new code? > > > > thanks > > > > On Fri, 10 Mar 2023 16:31:06 +0100 > > Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > > > >> Hi enztec, > >> > >> I have added fix_function() and fix_function_NL() to libapl. > >> They are ⎕FX equivalents on the C/C++ side and should simplify > >> the creation of defined APL functions considerably. > >> > >> SVN 1658. > >> > >> Best Regards, > >> Jürgen > >> > >> > >> On 3/8/23 9:20 PM, enz...@gmx.com wrote: > >> Hi Jürgen > >> > >> thanks for the quick replies - i now have some free time the rest of > >> today to do some more work on this > >> you gave me some things to work with (ie things i didn't know before) > >> > >> i'll let you know what i come up with > >> > >> thanks > >> > >> enztec > >> > >> > >> On Wed, 8 Mar 2023 20:27:43 +0100 > >> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > >> > >> Hi enztec, > >> > >> the use of )COPY in libapl may depend on whether the workspace that > >> is being copied was )SAVED or )DUMPED. The latter may use the ∇-editor > >> which functions only if a proper I/O system is available. I can't say > >> whether > >> that is the case or not in libapl. > >> > >> Maybe you should )SAVE (and not )DUMP) all workspaces used with )COPY. > >> In that case the ∇-editor should not be called because functions are > >> created > >> directly with ⎕FX. The ∇-editor is actually only a front-end that > >> calls ⎕FX > >> when the function editing is finished with the final ∇. > >> > >> Best Regards, > >> Jürgen > >> > >> > >> On 3/8/23 7:40 PM, enz...@gmx.com wrote: > >> Hi Jürgen > >> > >> please go down the email > >> > >> On Wed, 8 Mar 2023 18:42:03 +0100 > >> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > >> > >> Hi enztec, > >> > >> I don't quite understand what the actual problem is. > >> > >> I tested your files fns.c and fns.enz. > >> > >> Everything looks more or less fine, but I noticed e.g.: > >> > >> > >> if the folllowing line is commented in fns.c then the f1 fns is not > >> created from what the fns.enz )copy puts into some buffer - so the ∇f1 > >> (nabla editor) is clearly being used in the libapl - it is just that the > >> ∇f1 in the fns.enz when )copied in is not recognized like it is in the > >> 'apl fns.enz' and ap[ then )copy fns.enz examples > >> apl_exec("∇f1") > >> > >> which produces: > >> > >> > >> the error is only produced if the fns definition header is > >> uncommented in fns.enz - so 2 fns headers are run with the above > >> apl_exec("∇f1") being the only code that currently actually creates the > >> fns definition header > >> SYNTAX ERROR+ > >> Tokenizer: No token for Unicode U+2207 (∇) > >> Input: ∇f1 > >> > >> i think the problem is is that )copy does not properly parse the > >> fns header properly when used in libapl as it does in apl ws > >> because the fns body and closing ∇ are sitting somewhere waiting > >> for proper fns definition header to be given as it is in the fns.c with a > >> working apl_exec("∇f1") to produce good fns > >> > >> > >> As a matter of fact, the ∇ which opens the Nable editor is > >> being detected and processed before the tokenizer is invoked > >> and therefore the tokenizer will never see it (and complain > >> > >> the use of the apl_exec("∇f1") in the fns.c clearly disproves this > >> as above when it does). The ∇-editor is a purely interactive > >> feature not intended to be used in libapl. I suppose (since I > >> haven't written libapl) that input chain looks roughly like this: > >> > >> ┌───────┐ > >> │ input │ > >> └───────┘ > >> ↓ > >> ┌─────┐ > >> ┌←yes←←│ ∇ ? │→→no→→┐ > >> ↓ └─────┘ ↓ > >> ┌────────┐ ┌────────────┐ > >> │ Nabla │ │ apl_exec() │ > >> │ editor │ └────────────┘ > >> └────────┘ ↓ > >> ┌───────────┐ > >> │ Tokenizer │ > >> └───────────┘ > >> > >> Instead of messing around with the ∇-editor you should: > >> > >> 1. take your function lines (header and body lines), > >> 2. quote them so that the lines are valid APL literals, > >> 3. concatenate all quoted lines, separated with a blank, > >> 4. prefix the entrie beast with ⎕FX (unquoted). > >> 5. call apl_exec(). > >> > >> See my previous email for an example. I did the concatenation > >> in steps 2.-4. in APL to simplify the example, but you can easily > >> do > >> the same in C/C++ before calling apl_exec(). > >> > >> Best Regards, > >> Jürgen > >> > >> > >> On 3/7/23 7:01 PM, enz...@gmx.com wrote: > >> Thanks Jürgen, > >> > >> I'd like to keep the situation i gave in my post using the > >> ')copy fns.enz' method as i do fns developement first in the apl ws then > >> test it with apl scripting then to the libapl program and using the > >> apl_exec method you gave would not be practicle. > >> > >> could you give it an analysis as i think this is a bug and > >> fixing it would be a real plus to the apl/scripting/libapl system > >> > >> thanks > >> > >> enztec > >> > >> On Tue, 7 Mar 2023 16:28:26 +0100 > >> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > >> > >> Hi enztec, > >> > >> see below. > >> > >> On 3/6/23 9:31 PM, enz...@gmx.com wrote: > >> Hi > >> > >> it doesn't seem possible to create apl fns with apl_command > >> or apl_exec directly using libapl This premiss seems wrong: > >> > >> #include <apl/libapl.h> > >> > >> // compile with: gcc libapl_test.c -L /usr/local/lib/apl > >> -lapl -lstdc++ -o libapl_test > >> > >> int > >> main(int argc, char * argv[]) > >> { > >> init_libapl(argv[0], 0); > >> > >> apl_exec( "TEXT ← ⊂ 'Z←A SUM B'" ); > >> apl_exec( "TEXT ← TEXT, ⊂ 'Z←A + B'" ); > >> apl_exec( "⎕FX TEXT" ); > >> apl_command( ")FNS" ); > >> apl_exec( "'⎕CR SUM:' (⎕CR 'SUM')" ); > >> apl_exec( "1 SUM 2" ); > >> } > >> > >> which produces: > >> > >> eedjsa@server68:~/apl-1.8/src$ ./libapl_test > >> SUM > >> ⎕CR SUM: Z←A SUM B > >> Z←A + B > >> 3 > >> > >> Or, even shorter: > >> > >> apl_exec( "⎕FX 'Z←A SUM B' 'Z←A + B'"); > >> > >> > >> > >> > >> On 3/6/23 9:31 PM, enz...@gmx.com wrote: > >> Hi > >> > >> it doesn't seem possible to create apl fns with apl_command > >> or apl_exec directly using libapl > >> but i can successfully create a llibapl environment with > >> fns and variables with the following setup and workaround > >> > >> - > >> > >> 2 files fns.enz and fns.c > >> > >> -- > >> > >> situation 1 : shows good fns created from fns.enz > >> > >> /usr/local/bin/apl fns.enz > >> > >> in apl workspace run > >> f1 > >> f2 not created if it's fns definition header is > >> commented in fns.enz but is created if uncommented > >> > >> -- > >> > >> situation 2 : > >> > >> /usr/local/bin/apl > >> > >> in apl workspace run > >> )copy fns.enz > >> f1 > >> f2 not created if it's fns definition header is > >> commented in fns.enz but is created if uncommented > >> > >> -- > >> > >> situation 3 : > >> > >> g++ -O2 fns.c -o fns -L /usr/local/lib/apl -lapl > >> ./fns gives my output below and creates fns1.xml > >> fns2.xml and fns3.xml that can hopefully be of use for analysis of what is > >> happening > >> > >> in fns.c i can use apl_command(")copy fns.enz"); or > >> apl_exec(")copy fns.enz"); with the fns definition header workaround to > >> get working fns f1 and f2 > >> but without the f1 and f2 fns definition headers in fns.c i > >> get no f1 or f2 created > >> > >> in the fns.enz ∇f1 and ∇f2 fns definition headers don't > >> work as would hope/expect without the f1 and f2 function definition > >> workaround in fns.c > >> > >> as you can see in the fns.c after the )copy fns.enz if i > >> do a workaround apl_exec("∇f1"); i get good fns f1 and f2 > >> > >> it seems the ∇f1 fns header doesn't work but the bodies of > >> the fns in fns.enz and closing ∇ are in some 'buffer' and get put into the > >> f1 fns when the f1 function header definitions workarounds is done in fns.c > >> > >> the interesting thing is is that if i comment the f1 fns > >> definition header in the fns.enz the fns are still created by the > >> corresponding workaround line in fns.c but if i leave it uncommented > >> (which is what it would be if it worked) when i run the correspinding fns > >> header workaround in fns.c it gives the syntax error when run but doesn't > >> prevent it from creating the good f1 fns - so it seems the f1 function > >> definition header in fns.enz is doing something but not creating the fns. > >> > >> i left the fns.enz f1 function header uncommented and the > >> fns.enz f2 function header commented to show the difference > >> fns f2 is not created in situation 1 or situation 2 if it's > >> fns definition header is commented in fns.enz but commenting does not > >> affect it's creation in situation 3 (libapl) if f2 workaround fns > >> definition header is used in fns.c > >> > >> the correct order of the functions in fns.enz and the > >> corresponding fns headers workarounds must be maintained to get proper > >> working fns with the correct names > >> > >> i have been using this workaround successfully but would > >> love to know what is happening and see if there can be a fix > >> > >> i have added 3 )save commands at 'strategic' points in > >> fns,c to create the fns1.xml fns2.xml and fns3.xml in hope they give some > >> information that can be used to analyze what is happening > >> > >> thanks, > >> > >> enztec > >> > >> --- > >> > >> this is my output from ./fns from libapl situation 3 > >> > >> )wsid > >> IS CLEAR WS > >> )copy fns.enz > >> DUMPED 2023-03-06 12:31:44 (GMT-7) > >> )wsid > >> IS CLEAR WS > >> > >> )wsid fns1 > >> WAS CLEAR WS > >> )save > >> 2023-03-06 13:11:51 (GMT-7) fns1 > >> > >> ∇f1 workaround 1 in fns.c for f1 fns header in fns.enz > >> SYNTAX ERROR+ > >> Tokenizer: No token for Unicode U+2207 (∇) > >> Input: ∇f1 > >> > >> )fns > >> f1 > >> > >> )wsid fns2 > >> WAS fns1 > >> )save > >> 2023-03-06 13:11:51 (GMT-7) fns2 > >> > >> ∇f2 workaround 2 in fns,c for f2 fns header in fns.enz > >> > >> )wsid fns3 > >> WAS fns2 > >> )save > >> 2023-03-06 13:11:51 (GMT-7) fns3 > >> > >> )fns > >> f1 f2 > >> > >> f1 fns executed > >> ⍴⍕1 2 3 : 5 > >> > >> f2 fns executed > >> ⍴⍎"1 2 3" : 3 > >> > >> --- > >> > >> > >> > >> > >> > >> > >> >