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