Re: Call native wrapper function with double argument

2020-11-15 Thread Alexander Burger
Hi Thorsten,

> (de pwilcox (X Y Z I J)
> ...
> : (rmath~pwilcox 2.7 6.20 5.4 1 3)
> (native "libRmath.so" "pwilcox" 1 (cons X 1) (cons Y 1) (cons Z 1) I "J")
> ...
> ! J
> -> NIL
> Why is that second Integer argument interpreted as transient symbol, and
> then NIL although the actual arg = 3?

This is strange. I tried the same here, and get

   (native NIL "pwilcox" 100 (cons X 100) (cons Y 100) (cons Z 
100) I J)

And I get 3 as expected for 'J'.

Note the scaled integers! It seems your *Scl is zero. But this does not explain
what you see. Are you sure you pasted exactly what you tested?


> In the docs I only find:
> "The number of fixpoint arguments is limited to six."
> but that looks irrelevant here.

Yes, for pil64. For pil21 this no longer holds. There is no more limit on the
number of float or double arguments.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Common Lisp macros in PicoLisp

2020-11-15 Thread Alexander Burger
Hi Erik,

> More 'macro' madness and lisp jokes to brighten your weekend
> 
> https://github.com/erdg/pl-defmacro

Nice! Lots of fun indeed! :)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Common Lisp macros in PicoLisp

2020-11-15 Thread Alexander Burger
On Sun, Nov 15, 2020 at 09:20:36AM +0100, Alexander Burger wrote:
> Hi Erik,
> 
> > More 'macro' madness and lisp jokes to brighten your weekend
> > 
> > https://github.com/erdg/pl-defmacro
> 
> Nice! Lots of fun indeed! :)

.. and very impressing! You are a power-picolisper!

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Call native wrapper function with double argument

2020-11-15 Thread Thorsten Jolitz
Hi Alex,
this is strange indeed.
I checked on Bash/Archlinux as well, same problem as Win Term / WSL2, so
this is not about WSL or so.

I can like you define a dummy wrapper, and debug it, and it looks fine:

: (de foo (I J) (! native NIL NIL 1.0 I J))
-> foo
: (foo 2 3)
(native NIL NIL 1 I J)
! J
-> 3

So here I can use J as argument name, and it works.

But with my real wrapper functions, where ever I use J, as first or second
arg, its interpreted as a transient symbol and is NIL, even if I create a
fake wrapper without any real lib reference:

: (rmath~exp_rand_fake2 3 2)
(native NIL NIL 1 "J" B)
! J
-> NIL

But when I rename J to H in my real wrapper function, the problem is gone:
: (rmath~pwilcox 1.2 2.1 3.2 3 2)
(native "libRmath.so" "pwilcox" 1 (cons X 1) (cons Y 1) (cons Z 1) I H)
! H
-> 2

So I think I know whats the problem here: its reading the function
definitions from a library file vs defining the definition directly in the
repl.
(load "libRmath.l") seems to have a problem with the char J used for a
paramter, and somehow converts it into a transient symbol.

The easy solution is therefore to avoid J as parameter name ;-)
But maybe I found a bug?

Cheers
Thorsten

Am So., 15. Nov. 2020 um 09:01 Uhr schrieb Alexander Burger <
a...@software-lab.de>:

> Hi Thorsten,
>
> > (de pwilcox (X Y Z I J)
> > ...
> > : (rmath~pwilcox 2.7 6.20 5.4 1 3)
> > (native "libRmath.so" "pwilcox" 1 (cons X 1) (cons Y 1) (cons Z 1) I "J")
> > ...
> > ! J
> > -> NIL
> > Why is that second Integer argument interpreted as transient symbol, and
> > then NIL although the actual arg = 3?
>
> This is strange. I tried the same here, and get
>
>(native NIL "pwilcox" 100 (cons X 100) (cons Y 100) (cons Z
> 100) I J)
>
> And I get 3 as expected for 'J'.
>
> Note the scaled integers! It seems your *Scl is zero. But this does not
> explain
> what you see. Are you sure you pasted exactly what you tested?
>
>
> > In the docs I only find:
> > "The number of fixpoint arguments is limited to six."
> > but that looks irrelevant here.
>
> Yes, for pil64. For pil21 this no longer holds. There is no more limit on
> the
> number of float or double arguments.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


Re: Call native wrapper function with double argument

2020-11-15 Thread Alexander Burger
Hi Thorsten,

> But with my real wrapper functions, where ever I use J, as first or second
> arg, its interpreted as a transient symbol

So somewhere 'J' is bound to "J".


> But when I rename J to H in my real wrapper function, the problem is gone:

Right, so it is a binding issue. Think hard what values are exactly bound to
which variables at runtime. Such things happen usually only in FEXPRs or when
evaluable expressions are passed around through binding environments.


> So I think I know whats the problem here: its reading the function
> definitions from a library file vs defining the definition directly in the
> repl.
> (load "libRmath.l") seems to have a problem with the char J used for a

Is "libRmath.l" written by you?


> The easy solution is therefore to avoid J as parameter name ;-)
> But maybe I found a bug?

I don't think it is a bug. But you must take care of the implications of dynamic
binding, exwlained e.g. in:

   https://software-lab.de/doc/faq.html#problems

Such things are best fixed with transient or private symbols, or even a separate
namespace.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe



Re: Call native wrapper function with double argument

2020-11-15 Thread Alexander Burger
On Sun, Nov 15, 2020 at 06:44:20PM +0100, Alexander Burger wrote:
> So somewhere 'J' is bound to "J".
> ...
> Right, so it is a binding issue. Think hard what values are exactly bound to
> which variables at runtime.

I forgot to add:

You can perhaps see what is happening, by inspecting a backtrace with (bt) at
the breakpoint.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Call native wrapper function with double argument

2020-11-15 Thread Thorsten Jolitz
Hi Alex,
I actually do use a namespace, and there is not much going on wrt to
assignments:
>From line 8 on there are only some 100+ mostly trivial wrapper functions,
see PS. I first thought it might have something to do with Picolisp
Linebreaks "delta J", but I have seen the same issue now with an Y
parameter name, not just J.

With a definition like in PS 1, I would be on the safe side?
When I use (bt) on the original signature specification, it looks like
this:
(native NIL "pwilcox" 1000 (cons X 1000) (cons Y 1000) (cons Z 1000) I "J")
 ! (bt)
("pwilcox" 2700 6200 2100 3 ..)
   X 2700
   Y 6200
   Z 2100
   I 3
   "J" 2

Cheers
Thorsten

PS 1
(de pnorm_both ("X" "Y" "Z" "I" "J")
(! native `*LibRmath "pnorm_both" 1.0 (cons "X" 1.0) '("Y" (1.0 . 4))
'("Z" (1.0 . 4)) "I" "J" ) )
  ## void›pnorm_both(double, double *, double *, int, int);/* both
tails */

: (rmath~pnorm_both 2.1 3.2 4.1 3 2)
(native "libRmath.so" "pnorm_both" NIL (cons "X" 1000) '("Y" (1000 . 4))
'("Z" (1000 . 4)) "I" "J")
! (bt)
("pnorm_both" 2100 3200 4100 3 ..)
   "X" 2100
   "Y" 3200
   "Z" 4100
   "I" 3
   "J" 2

PS 2

   1 # libRmath.l - (native) PicoLisp bindings for Rmath
   2 # copyright (C) 2020 Thorsten Jolitz
   3
   4 (symbols 'rmath 'pico)
   5
   6 (default *LibRmath "libRmath.so")
   7
   8 (de Rlog1p (X)
   9 (native `*LibRmath "Rlog1p" 1.0 (cons X  1.0) ) )
  10 ## double  Rlog1p(double);

Am So., 15. Nov. 2020 um 18:50 Uhr schrieb Alexander Burger <
a...@software-lab.de>:

> Hi Thorsten,
>
> > But with my real wrapper functions, where ever I use J, as first or
> second
> > arg, its interpreted as a transient symbol
>
> So somewhere 'J' is bound to "J".
>
>
> > But when I rename J to H in my real wrapper function, the problem is
> gone:
>
> Right, so it is a binding issue. Think hard what values are exactly bound
> to
> which variables at runtime. Such things happen usually only in FEXPRs or
> when
> evaluable expressions are passed around through binding environments.
>
>
> > So I think I know whats the problem here: its reading the function
> > definitions from a library file vs defining the definition directly in
> the
> > repl.
> > (load "libRmath.l") seems to have a problem with the char J used for a
>
> Is "libRmath.l" written by you?
>
>
> > The easy solution is therefore to avoid J as parameter name ;-)
> > But maybe I found a bug?
>
> I don't think it is a bug. But you must take care of the implications of
> dynamic
> binding, exwlained e.g. in:
>
>https://software-lab.de/doc/faq.html#problems
>
> Such things are best fixed with transient or private symbols, or even a
> separate
> namespace.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>


Re: Call native wrapper function with double argument

2020-11-15 Thread Alexander Burger
Hi Thorsten,

hmm, this is not correct:

> (de pnorm_both ("X" "Y" "Z" "I" "J")
> (! native `*LibRmath "pnorm_both" 1.0 (cons "X" 1.0) '("Y" (1.0 . 4))
> '("Z" (1.0 . 4)) "I" "J" ) )

"Z" is an argument to the function, so it is bound to some evaluated value.

But this value is ignored, because in

   '("Z" (1.0 . 4))

"Z" is a *return* value. Also, (1.0 . 4) makes no sense here. A structure
argument is

   '(Var ( . mailto:picolisp@software-lab.de?subject=Unsubscribe