Re: fns creation using libapl (c code)

[enztec]

On Wed, 15 Mar 2023 12:28:09 +0100
Dr. Jürgen Sauermann <mail@xn--jrgen-sauermann-zvb.de> wrote:

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

libapl can indeed do )copy of apl scripts - it just needs the apl_exec("∇f1"); 
workaround after the )copy statement in fns.c

yes without the workaound libapl cannot do the )copy - that would be a nice 
thing for you to fix

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

i actually don't want or need you to fix the )copy in libapl - my workaround 
works just fine - just a pain to keep track of the fns order in my workaround 
code vs the order in fns.enz - i do the workaround in an extra fpc 'header.prd' 
file that would not be needed if )copy worked properly to begin with

i was trying to give back to apl because others might want to use )copy in 
libapl in the future and might not think of using my workaround
it would have been nice to have a real fix to the )copy apl script  problem  
but to be honest i no longer have any concern about it

i had the same motivation for wanting to get the apl stdout into a 
ansistring/tstringlist in the calling program from an apl_exec statement
the 900000⍴'ae '  test data i use to test the 3 methods i now have takes 18 
msec  to create
these methods bring the apl_exec results into fpc both as an ansistring and a 
tstringlist
soa.prd  takes 40 msec               this is my workaround using apl and 
bringing it into fpc
soc.prd  takes 10" 219 msec      this is the use of the libapl call back in fpc 
- i had to fix the faux fpc's devs call back results as they were broken
sof.prd   takes 12" 464 msec      this is a pure fpc stdout workaround - i had 
to fix the results as they gave broken results as well

i only use apl/scripting/libapl now for prototyping since i now convert all my 
apl fns directly to fpc functions as fpc gives me a 200-250 times (yes times) 
perormance enhancement over running the 'same' code in apl - i posted my 
initial testing results in the list a while back

when you do get around to fixing the )copy use my fns.c/fns.enz code and 
comment the workaround lines in fns.c  to verify that your fixes work

see ya

enztec

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