Re: fns creation using libapl (c code)

[enztec]

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 <mail@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, enztec@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 <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
> >>                
> >>                ---
> >>              
> >>            
> >>          
> >>        
> >>      
> >>    
> >>
>