Re: fns creation using libapl (c code)

[enztec]

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 <mail@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, enztec@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 <mail@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, enztec@gmx.com wrote:
>       Hi Jürgen 
>       
>       please go down the email
>       
>       On Wed, 8 Mar 2023 18:42:03 +0100
>       Dr. Jürgen Sauermann <mail@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, enztec@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 <mail@xn--jrgen-sauermann-zvb.de> wrote:
>           
>             Hi enztec,
>             
>             see below.
>             
>             On 3/6/23 9:31 PM, enztec@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, enztec@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
>               
>               ---
>             
>           
>         
>       
>     
>   
>