Re: fns creation using libapl (c code)

[Dr . Jürgen Sauermann]

    enztec,
      
      some more explanation of what is, to the best of my knowledge,
      happening.
      
      If you build GNU APL as a full interpreter, then is essentially
      consists of
      two parts: an interactive frontend and a core interpreter:
      
          ┌──────────┐   ┌──────────┐
          │ frontend ├───┤ APL core │
          └──────────┘   └──────────┘
        
      The frontend does the interactive and I/O part, while the core
      does the
      APL primitives and some of the workspace related APL commands. In
      thi
       model, )COPY of an .xml workspace happens in the APL core while
      )COPY
      of an .apl workspace happens in the frontend.
      
      Now libapl is a thin API towards the APL core:
      
          ┌────────┐   ┌──────────┐
          │ libapl ├───┤ APL core │
          └────────┘   └──────────┘
        
      In your example you have an C application that uses libapl:
      
          ┌───────┐   ┌────────┐   ┌──────────┐
          │ fns.c ├───┤ libapl ├───┤ APL core │
          └───────┘   └────────┘   └──────────┘
        
      Since the frontend is not used, its functions are gone with it, in
      particular )COPY of .apl scripts, while )COPY of .xml workspaces
      should still work because it is done on the APL core.
      
      You want me to fix libapl which makes no sense in the
      above model.
      What you should maybe do instead is:
      
                  ╔═══ APL interpreter
          ═════════╗
          ┌───────┐   ║ ┌──────────┐   ┌──────────┐ ║
          │ fns.c ├───╫─┤ frontend ├───┤ APL core │ ║
          └───────┘   ║ └──────────┘   └──────────┘ ║
                      ╚═════════════════════════════╝
        
      There are some examples in the GNU APL code how to do this,
      see e.g. Quad_FIO::do_FIO_57() but using fork() followed
      by
      execve(APL interpreter) in the child.

On 3/14/23 8:18 PM, Dr. Jürgen Sauermann wrote:

> On
>       3/14/23 6:42 PM, enztec@gmx.com wrote:
>       
> > Jürgen
> >         
> >         
> >         your )copy is clearly broken in libapl  - it works properly in
> >         apl ws and apl scripting but is broken in libapl
> >         
> >       
>       Did you follow my advice to )COPY only )SAVEed workspaces and not
>       )DUMPed ones?
>       
>       I'm guessing you never tested that advice to begin with.
>       
> > I'm guessing you never tested my code to
> >         begin with
> >         
> >       
>       I did and I figured that using the ∇-editor in )DUMPed scripts
>       will not work in libapl.
>       
>       At least not in the way you are trying to use it (which apparently
>       differs from how
>       
>       the inventor of libapl expected it to be used).
>       
> > I am not interested in changing my code to
> >         use the ⎕fx directly - i'm guessing you need to apply your new
> >         functions to the )copy code in libapl to fix it
> >         
> >         
> >         I have done a working workaround and found this bug and want to
> >         make libapl work as it should
> >         
> >         ---
> >         
> >         
> >         I explained what the workaround is doing pretty clearly in the
> >         post(s)- have you even looked at it?
> >         
> >       
>       My definition of "explained pretty clearly" seems to be different
>       from yours.
>       
> > the fns headers (∇f1 ∇f2) in the fns.enz
> >         after )copy fns.enz don't create the fns (like they would in apl
> >         ws and apl scripting after )copy fns.enz) but if
> >         apl_exec("∇f1");  is used in fns.c after the )copy fns.enz in
> >         fnc.c then the fns f1 and f2 are created
> >         
> >       
>       As I tried to explain earlier, using ∇ is not a good idea. If you
>       do it nevertheless, then
>       
>       after opening the ∇-editor you have to apl_exex() the subsequent
>       function lines including
>       
>       the final ∇.
>       
> >         
> >         On Tue, 14 Mar 2023 13:21:21 +0100
> >         
> >         Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de>
> >         wrote:
> >         
> >         
> > > On 3/13/23 10:50 PM, enztec@gmx.com
> > >           wrote:
> > >           
> > > > Jürgen
> > > >             
> > > >             
> > > >             your code change didn't fix my problem and actually broke my
> > > >             workaround
> > > >             
> > > >           
> > >           I am sorry to hear that. I have no idea though what the
> > >           purpose of your
> > >           
> > >           workaround actually is. work around which problem? Your
> > >           initial issue
> > >           
> > >           was the lack of a way to define APL functions, which is fixed
> > >           now.
> > >           
> > > > please test agains my code okay ?
> > > >             
> > > >           
> > >           No. please test my code and let me know precisely why it does
> > >           
> > >           not fix your problem.
> > >           
> > > > enztec
> > > >             
> > > >           
> > >         
> >       
>       
>