bug-apl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fns creation using libapl (c code)


From: Dr . Jürgen Sauermann
Subject: Re: fns creation using libapl (c code)
Date: Sat, 11 Mar 2023 12:06:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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
---




reply via email to

[Prev in Thread] Current Thread [Next in Thread]