Re: building on macos

[Andras Pahi]

Hi,

I use the following Makefile to build pil21 on macOS Mojave (10.14.6) x86_64,
libreadline, libffi and OpenSSL 3 is used from MacPorts.

I have checked with picoLisp-22.3.tgz version 22.3.16
and pil21.tgz (the rolling release) version 22.5.26.

Regards,
Andras Pahi

~~ cut here ~~

# 24dec20 Software Lab. Alexander Burger

SILENT:

CC = clang
PIL = ../pil  # pil
ASM = opt -O3  # llvm-as
MAIN = -rdynamic -lc -lm -ldl -L/opt/local/lib -lreadline -lffi
# SHARED = -shared
SHARED = -dynamiclib -undefined dynamic_lookup
OS = $(shell uname)
CPU = $(shell uname -m)

BIN = ../bin
LIB = ../lib

INC = lib/llvm.l vers.l defs.l glob.l dec.l
SRC = main.l gc.l big.l sym.l io.l db.l apply.l flow.l subr.l

all: $(LIB)/sysdefs $(BIN)/picolisp $(LIB)/ext.so $(LIB)/ht.so $(BIN)/balance 
$(BIN)/ssl $(BIN)/httpGate

# System definitions
$(LIB)/sysdefs: sysdefs.c
$(CC) -w -D_OS='"$(OS)"' -D_CPU='"$(CPU)"' sysdefs.c  &&  /a.out > 
$(LIB)/sysdefs  &&  rm ./a.out

# Base system
$(BIN)/picolisp: picolisp.bc
mkdir -p $(BIN) $(LIB)
llc picolisp.bc -relocation-model=pic -o picolisp.s
$(CC) picolisp.s -o $(BIN)/picolisp $(MAIN)

picolisp.bc: base.bc lib.bc
llvm-link -o picolisp.bc base.bc lib.bc

base.bc: base.ll
$(ASM) -o base.bc base.ll

base.ll: $(INC) $(SRC)
$(PIL) lib/llvm.l main.l -bye > base.ll
mv base.map $(LIB)/map

lib.bc: pico.h lib.c
$(CC) -O3 -w -c -D_OS='"$(OS)"' -D_CPU='"$(CPU)"' `pkg-config --cflags 
libffi` -emit-llvm lib.c

# Extension libraries
$(LIB)/ext.so: ext.bc
llc ext.bc -relocation-model=pic -o ext.s
$(CC) ext.s -o $(LIB)/ext.so $(SHARED)

ext.bc: ext.ll
$(ASM) -o ext.bc ext.ll

ext.ll: $(INC) ext.l
$(PIL) lib/llvm.l ext.l -bye > ext.ll

$(LIB)/ht.so: ht.bc
llc ht.bc -relocation-model=pic -o ht.s
$(CC) ht.s -o $(LIB)/ht.so $(SHARED)

ht.bc: ht.ll
$(ASM) -o ht.bc ht.ll

ht.ll: $(INC) ht.l
$(PIL) lib/llvm.l ht.l -bye > ht.ll

# Tools
$(BIN)/balance: balance.c
$(CC) -O3 -w -o $(BIN)/balance balance.c

# Gate
$(BIN)/ssl: ssl.c
$(CC) -O3 -w -o $(BIN)/ssl ssl.c -I/opt/local/include -L/opt/local/lib 
-lssl -lcrypto

$(BIN)/httpGate: httpGate.c
$(CC) -O3 -w -o $(BIN)/httpGate httpGate.c -I/opt/local/include 
-L/opt/local/lib -lssl -lcrypto

# Clean up
clean:
rm -f *.ll *.bc *.s

~~ cut here ~~

> On 2022. May 28., at 14:02, Jean-Christophe Helary 
>  wrote:
> 
> 
> 
>> On May 28, 2022, at 19:24, Mike  wrote:
>> 
>> 
>> 
>>> On May 28, 2022, at 13:13, Jean-Christophe Helary 
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On May 25, 2022, at 18:45, Mike  wrote:
>>>> 
>>>> hi all,
>>>> 
>>>>> They used to work (I have a working build of pil21 21.9.3), but they 
>>>>> don't anymore.
>>>>> Maybe there is something wrong with my system but I have no idea what it 
>>>>> is.
>>>> 
>>>> Did you built picolisp?
>>> 
>>> How would I go about building picolisp ?
>>> 
>> I do not know were you stuck.
> 
> At the time of 21.9.3 I was able to build the system according to the 
> instructions here:
> 
> https://picolisp.com/wiki/?alternativeMacOSRepository
> 
> Now that generates the following error message:
> 
> /opt/local/libexec/llvm-10/bin/llvm-link: lib.bc: error: Unknown attribute 
> kind (68) (Producer: 'APPLE_1_1300.0.29.30_0' Reader: 'LLVM 10.0.1')
> /opt/local/libexec/llvm-10/bin/llvm-link: error:  loading file 'lib.bc'
> make: *** [picolisp.bc] Error 1
> 
> That's where I am stuck.
> 
> 
> 
> -- 
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book/
> 
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: quote form in picolisp

[Andras Pahi]

Hi,

McCarthy’s "A micro-manual for Lisp" in 1978 lists 10 rules as the core of LISP.
The first rule states the behavior of QUOTE. If you select a different set of 
rules,
you get a different LISP.

In picoLisp QUOTE is defined differently.

Regards,
Andras Pahi


> On 2021. Dec 16., at 12:17, pd  wrote:
> But there's stablished traditions and there're formal theory you should 
> comply with.   I think quote behaviour is one of them and also list 
> application.  


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

Re: Feature request - 'fill'

[Andras Pahi]

Hi Alex,

What should (fill (1 ^ 7 9)) return ?

Regards,
Andras Pahi

> On 2021. Dec 13., at 18:21, Alexander Burger  wrote:
> 
> So I went ahead and implemented the extended 'fill' behavior.
> 
>   : (fill (1 ^(+ 1 1) 3))
>   -> (1 2 3)
> 
> To make it more consistent, I also changed the '~' read macro in the same way.
> Now this works:
> 
>   : (~(- 4 3) (2 ~(+ 1 2) 4) 5)
>   -> (1 (2 3 4) 5)


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

Re: '(struct ...)' alignment issue

[Andras Pahi]

Hi,

If you know, that struct does its job as if you specified packed in C,
then you can pass packed or aligned structs to C functions, just
you need to do the alignment yourself.

I vaguely remember the pain, when I needed to process BMP graphics
files on DEC Alpha processors...

Andras Pahi

> On 2021. Dec 7., at 14:11, Jason Vas Dias  wrote:
>  But it does not do what it claims ,  because it does not
>  insert the required pad bytes - it lays everything out as
>  if the programmer had specified '#pragma packed' or
>  '__attribute__((packed))' for the whole structure.


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

Re: Returning double results in pil21 ?

[Andras Pahi]

Hi Alex,

My post is indicated by Mia’s blog entry ;) since I have cross-checked the 
results
between pil21 and my 64bit pil32 fork.

pil32 flawlessly converted double results to bignums, but I understand the 
efficiency
consideration.

Thanks,
Andras Pahi



> On 2021. Sep 29., at 16:37, Alexander Burger  wrote:
> 
> On Wed, Sep 29, 2021 at 04:28:20PM +0200, Alexander Burger wrote:
>> BTW, pil64 did the same.
> 
> Side note: Mia's blog from today has an interesting case of floating point
> versus fixpoint.
> 
> PicoLisp fixpoint arithmetics turns out to be superior:
> 
>   https://picolisp-blog.hashnode.dev/the-fibonacci-sequence
> 
> It is the implementation of Binet's formula at the end.
> 
> ☺/ A!ex
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Returning double results in pil21 ?

[Andras Pahi]

Hi Alex,

I understand that the result will be correct for 56bits only 
(as for every double FP number), but we lose the dynamic range.

So pil21 will only return 60bits worth of doubles ;)

Thanks,
Andras Pahi


> On 2021. Sep 29., at 16:16, Alexander Burger  wrote:
> 
> Ah, yes, that's correct. This is because even a double has only 56 bits of
> precision, so the 60 bits of a short number should be enough.


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

Re: Returning double results in pil21 ?

[Andras Pahi]

Hi Alex,

Thanks.
I mean that in pil21 src/lib.c boxFloat() and boxDouble() restricts the range 
of float/doubles to short numbers only…

Thanks,
Andras Pahi



> On 2021. Sep 29., at 15:41, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> As I see, the native function with the scaled fixpoint specification can 
>> return only a short number ?
>> Is it a bug or a feature ?
> 
> It can also return a 'double'. A single precision 'float' number is returned 
> via
> the -1.0 spec, and a 'double' is returned via the +1.0 spec.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Returning double results in pil21 ?

[Andras Pahi]

Hi,

As I see, the native function with the scaled fixpoint specification can return 
only a short number ?
Is it a bug or a feature ?

Thanks,
Andras Pahi


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

Re: New blog - "PicoLisp for beginners"

[Andras Pahi]

Hi Jean-Christophe,

If you succeeded to install pil21 on macOS and want the latest and greatest,
you can ignore my fork entirely. 

I loosely track picoLisp v21 features on my fork, which only needs a C compiler
to compile and can bootstrap pil21.

Regards,
pahihu

> On 2021. Sep 5., at 8:18, Jean-Christophe Helary  
> wrote:
> 
>>> The only way to build/install on macOS is by using this fork:
>>> 
>>> https://github.com/pahihu/picoLisp
> 
> So, can I now safely remove your gihub repository ?


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

Re: New blog - "PicoLisp for beginners"

[Andras Pahi]

Hi Jean-Cristophe,

I’ve built pil21 on macOS 10.14:

1) I use MacPorts, installed mp-llvm-10, readline, libffi, and openssl packages.
Run ‘port select —set llvm mp-llvm-10’ to use the MacPorts version of LLVM.

2) I’ve modified the latest pil21 Makefile in the src directory:

# 19aug21 Software Lab. Alexander Burger
  
SILENT:

CC = clang -I/opt/local/include -L/opt/local/lib
PIL = ../pil # pil
ASM = opt -O3  # llvm-as
LLC = llc
LINK = llvm-link
MAIN = -rdynamic -lc -lutil -lm -ldl -lreadline -lffi
# SHARED = -shared
SHARED = -dynamiclib -undefined dynamic_lookup
STRIP = : # strip

It builds cleanly and passes all the included tests.

Regards,
pahihu

> On 2021. Sep 4., at 16:25, Jean-Christophe Helary 
>  wrote:
> 
> Hello all,
> 
> The installation procedure that says "macos is ok" seems misleading.
> https://picolisp-blog.hashnode.dev/how-to-install-picolisp
> 
> I've followed the instruction here:
> https://git.envs.net/mpech/pil21/src/branch/master/INSTALL
> And obviously I can't install the Debian dev libraries.
> 
> I tried this:
> https://macappstore.org/picolisp/
> 
> but brew does not seem to list picolisp anymore.
> 
> The only way to build/install on macOS is by using this fork:
> 
> https://github.com/pahihu/picoLisp
> 
> Or am I mistaken ?
> 
> By the way, the wiki here:
> https://picolisp.com/wiki/?home
> 
> seems to confirm that picolisp won't build/run on macos
> 
> Jean-Christophe 
> 
> ps: thank you for the blog.
> 
>> On Sep 1, 2021, at 18:57, Mia Burger  wrote:
>> 
>> Hi all,
>> 
>> I'm Mia, one of Alex' daughters, nice to meet you!
>> 
>> I started to play around with PicoLisp a few months ago. So I checked
>> the available resources, and after a while I thought it might be good to
>> have a little bit more "beginner's level" content, with a low threshold
>> and fun to read. Because I feel that a lot of it is already quite
>> advanced (or of rather mixed difficulty), which can be quite frustrating.
>> 
>> So we started to put up a blog together. Today I have posted the first
>> article, and there will be one post per day for the next few weeks. If
>> you're interested, feel free to follow!
>> 
>> - This is the blog homepage: https://picolisp-blog.hashnode.dev/
>> 
>> - And here is the repository with some ideas for structure and content:
>> https://gitlab.com/picolisp-blog/structure
>> 
>> I'm always happy about feedback or further inputs - for example, I think
>> it would be really nice to feature some community projects, like Nehal's
>> mind maps. Always open for your ideas! Also, please let me know if
>> something requires further explanation or maybe is even wrong.
>> 
>> 
>> Wish you a nice rest of the week!
>> 
>> Best regards, Mia
>> 
>> 
>> PS. Also I have to apologize, obviously most of the content is not
>> originally from me but from the community. Sometimes I even copied
>> complete sentences if I liked them. Hope that was ok!
>> 
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 
> -- 
> Jean-Christophe Helary @brandelune
> https://mac4translators.blogspot.com
> https://sr.ht/~brandelune/omegat-as-a-book/
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: struct behavior in pil21

[Andras Pahi]

Hi Alex,

I’ve replaced (model) in the old pil64 version of rcsim with your (model) 
function
from the pil21 version, and it works with the old key assignments as expected.

Thank you,
pahihu

> On 2021. May 19., at 18:52, Alexander Burger  wrote:
> 
> On Tue, May 18, 2021 at 08:27:14PM +0200, Alexander Burger wrote:
>> I will play with rcsim again :)
> 
> Did it! Ported rcsim to pil21 :)
> 
> It needs the latest pil21, as I added a lib for inline C compilation analog to
> what we had in pil32 and pil64.
> 
> The files @lib/z3d.l and misc/rcsim.l are in
> 
>   https://software-lab.de/rcsim.tgz
> 
> Note that I had to change the key controls. Pil21 no longer has an 'fkey'
> function (because of readline()). I use keys convenient for PentiKeyboard,
> please change to some other keys, whichever you like.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: struct behavior in pil21

[Andras Pahi]

Hi Alex,

Thank you for your explanation.
I will check @doc/diff from now.

pahihu

> On 2021. May 18., at 19:59, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> The example below is taken from the documentation of ‘struct’ in pil21.
>> In this case ’struct’ no longer returns the address of the memory region.
> 
> Hmm, yes, this changed a little. Is mentioned in the @doc/diff file.
> 
> It is very useful for atomic result specifications, i.e. to dereference a
> pointer for any kind of pointed type:
> 
>   : (setq P (%@ "malloc" 'N 32))
>   -> 537873387608
> 
>   : (struct P 'N -7 -4)  # Store 2 int's, return value as a long
>   -> 17179869191  # hex "40007"
> 
>   : (struct P 'I)  # Fetch first int
>   -> 7
> 
>   : (struct (+ 4 P) 'I)  # Fetch second int
>   -> 4
> 
> 
>> With this change misc/rcsim.l no longer runs (I’ve learned it the hard way).
> 
> Oops, haven't looked at rcsim since pil21 :(
> 
> 
>> I would like to ask, that this was intentional ?
> 
> Yes, it is a lot more useful, used heavily in e.g. in @lib/net.l.

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

struct behavior in pil21

[Andras Pahi]

Hi,

The example below is taken from the documentation of ‘struct’ in pil21.
In this case ’struct’ no longer returns the address of the memory region.

With this change misc/rcsim.l no longer runs (I’ve learned it the hard way).

I would like to ask, that this was intentional ?

Thanks,
pahihu

## /* We assume the following C structure */
## typedef struct value {
##int x, y;
##double a, b, c;
##long z;
##char nm[4];
## } value;

# Allocate structure
: (setq P (native "@" "malloc" 'N 56))
-> 9204032

# Store two integers, three doubles, one long, and four characters
: (struct P 'N -7 -4 (1.0 0.11 0.22 0.33) (7 . 8) 65 66 67 0)
-> 9204032

Re: math.l library in picoLisp

[Andras Pahi]

Hi Alex,

Yesterday SJain asked about namespaces in 32bit picoLisp
and I assumed he is using the 32bit version.

Sorry, I am living in a combined picoLisp world ( pil/pil64/pil21 ;)
My 32bit version calls the math functions directly too, since 
(== 64 64) is true.

pahihu



> On 2021. May 17., at 10:34, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> The src/ directory contains the source (ext.c or ext.l), the lib/ directory
>> contains the shared lib (ext or ext.so).
> 
> Correct for pil32.
> 
> For pil21 (and also pil64) the built-in standard functions are
> called directly via 'native'.
> 
> ☺/ A!ex
> 
> BTW, strange, but I did not see SJain's original mail.
> 
> 
>> pahihu
>> 
>>> On 2021. May 17., at 7:27, SJain  wrote:
>>> 
>>> I use fixed point math quite a bit and have the following question about 
>>> the default math.l library of picoLisp:
>>> 
>>> The trigonometric function Sin is derived in math.l from the shared library 
>>> and function specification ext:Sin. Where can I find this shared library 
>>> 'ext'?
>>> 
>>> Would appreciate if some one could answer this.
>>> 
>>> SJain
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: math.l library in picoLisp

[Andras Pahi]

Hi,

The src/ directory contains the source (ext.c or ext.l), the lib/ directory 
contains the shared lib (ext or ext.so).

pahihu

> On 2021. May 17., at 7:27, SJain  wrote:
> 
> I use fixed point math quite a bit and have the following question about the 
> default math.l library of picoLisp:
> 
> The trigonometric function Sin is derived in math.l from the shared library 
> and function specification ext:Sin. Where can I find this shared library 
> 'ext'?
> 
> Would appreciate if some one could answer this.
> 
> SJain


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Alex,

Perfect, it works as expected on macOS.

Finally I’ve got demoApp working: the culprit was the Safari browser.
With Firefox it works!

Regards,
Andras Pahi

> On 2021. Apr 17., at 16:54, Alexander Burger  wrote:
> 
> On Sat, Apr 17, 2021 at 04:35:09PM +0200, Alexander Burger wrote:
>> OK, as ppoll() works fine on Linux (tests passed), I will keep it. This 
>> covers
>> most use cases, including Servers (Debian), PilBox (Android) and smaller 
>> stuff
>> (Raspi).
>> 
>> I put an #ifdef for other systems, using poll() and setting infinite timeout
>> above 24 days.
> 
> Done!! Released a new pil21.tgz :)
> 
> @Andras: Can you test on Mac again?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Alex,

Just one remark, ppoll(2) is Linux-specific.
I know there is a perfectly portable API - Linux.

Regards,
Andras Pahi

> On 2021. Apr 17., at 15:53, Alexander Burger  wrote:
> 
> On Sat, Apr 17, 2021 at 02:15:42PM +0200, Alexander Burger wrote:
>> But as you saw in my last mail, the whole question is obsolete. I have to 
>> adjust
>> pil21 anyway.
> 
> I will use ppoll(2).
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Alex,

Maybe the definition of

#define __INT_MAX__ 2147483647

could be used ? It is predefined by the clang/gcc preprocessor.

Regards,
Andras Pahi


> On 2021. Apr 17., at 13:02, Alexander Burger  wrote:
> Unfortunately, "#if sizeof(int) == 4" is not allowed in C, that's why I used 
> the
> above construct.
> 
> Does anybody have a better idea?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Alex,

Thank you for looking after this.

According to the man page on macOS, poll returns:

 [EINVAL]   The nfds argument is greater than OPEN_MAX or the
timeout argument is less than -1.

The check at compile time is not triggered on macOS, the following program
prints “false”:

#include 
#include 

int main(int argc, char*argv[])
{
#if (int)-1 == 0x
printf("true");
#else
printf("false");
#endif
  return 0;
}

Regards,
Andras Pahi

> On 2021. Apr 17., at 11:42, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
>> values which when casted to (int) results in values less than -1 (eg. -3).
>> This results in EINVAL errors in poll().
> 
> The EINVAL is indeed strange. According to the man page any negative timout
> should result in an infinite wait.
> 
> 
>> I have inserted a code snippet which truncates the timeout to -1 then I can 
>> get
>> to the login page in the demo app.
> 
> This should not be necessary since PicoLip 21.4.15. It checks at compile time
> whether it is a system with 32-bit int's, and then passes -1 for larger 
> numbers:
> 
>   #if (int)-1 == 0x
>  else if (timeout > 2147483647)  // Fit into 32 bits (max 24 days)
> timeout = -1;
>   #endif
> 
> I cannot test it here. Can you verify that it works?
> 
> 
>> Entering eg. “ben”, “ben” results in dropping the connection. The task 
>> handling the connection
>> is forked, as I see in the process list.
> 
> Hmm, so the above is not enough. There must be some other problem, perhaps 
> also
> related to 32-bit integers.
> 
> ☺/ A!ex
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi,

It is very strange indeed, on macOS Mojave gPoll() receives sometimes timeout
values which when casted to (int) results in values less than -1 (eg. -3).
This results in EINVAL errors in poll().

I have inserted a code snippet which truncates the timeout to -1 then I can get
to the login page in the demo app.

Entering eg. “ben”, “ben” results in dropping the connection. The task handling 
the connection
is forked, as I see in the process list.

Any ideas how to get further ?

Thanks,
Andras Pahi

> On 2021. Apr 16., at 7:43, Andras Pahi  wrote:
> 
> Hi Alex,
> 
> Thank you for your suggestions, I have traced listen and wait and both have
> The parameters are as expected (Ms is NIL, Sd is 17).
> 
> As Mike tested on macOS Big Sur and it worked, the problem is in my setup.
> 
> Regards,
> Andras
> 
>> On 2021. Apr 15., at 19:11, Alexander Burger  wrote:
>> 
>> Hi Andras,
>> 
>>> 
>>> /pil app/main.l -ap~main -'go 4040' +
>>> 6538 = 58885 48782252818959702~
>>> ap: !? (wait Ms T "Sd")
>>> Select error: Invalid argument
>>> ...
>>> It has the same behavior as the previous version of pil21.
>> 
>> Yeah, I thought about it, and came to the conclusion that today's change in
>> gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout 
>> is
>> seldom used, I think.
>> 
>> So what causes the above error?
>> 
>> It happens in 'listen' (line 94 in @lib/net.l):
>> 
>>  (de listen (Sd Ms)
>> (loop
>>(NIL (wait Ms T Sd))
>>(T (accept Sd) @) ) )
>> 
>> "Select error" is issued by poll(). But which argument is ivalid?
>> 
>> Can you try to trace or debug?
>> 
>> Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen 
>> is
>> called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd().
>> 
>> Any idea?
>> 
>> ☺/ A!ex
>> 
>> -- 
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Alex,

Thank you for your suggestions, I have traced listen and wait and both have
The parameters are as expected (Ms is NIL, Sd is 17).

As Mike tested on macOS Big Sur and it worked, the problem is in my setup.

Regards,
Andras

> On 2021. Apr 15., at 19:11, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> 
>> /pil app/main.l -ap~main -'go 4040' +
>> 6538 = 58885 48782252818959702~
>> ap: !? (wait Ms T "Sd")
>> Select error: Invalid argument
>> ...
>> It has the same behavior as the previous version of pil21.
> 
> Yeah, I thought about it, and came to the conclusion that today's change in
> gPoll() is only relevant for very large (> 24 days) timeouts. Such a timeout 
> is
> seldom used, I think.
> 
> So what causes the above error?
> 
> It happens in 'listen' (line 94 in @lib/net.l):
> 
>   (de listen (Sd Ms)
>  (loop
> (NIL (wait Ms T Sd))
> (T (accept Sd) @) ) )
> 
> "Select error" is issued by poll(). But which argument is ivalid?
> 
> Can you try to trace or debug?
> 
> Is the socket descriptor invalid? The 'Ms' argument must be NIL cause listen 
> is
> called by 'server' as (listen P). Thus 'wait' passes 292MY to waitFd().
> 
> Any idea?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi Mike,

Thank you for the test, I am still on Mojave.
I will check my setup where it went wrong.

Regards,
Andras

> On 2021. Apr 15., at 21:13, Mike  wrote:
> 
> Andras,
> 
> https://webirc.envs.net/uploads/5d228d2686705b27/8AB6ED6B-5EAC-4CBC-BCF8-84BB26447763.jpeg
> this is my try on latest big sur
> 
> 
> 
> April 15, 2021 7:53 PM, "Andras Pahi"  wrote:
> 
>> Hi,
>> 
>> I grabbed the latest pil21.tgz and demoApp.tgz.
>> 
>> "pil @lib/test.l +" runs without errors.
>> 
>> On macOS I've got
>> 
>> ./pil app/main.l -ap~main -'go 4040' +
>> 
>> 6538 = 58885 48782252818959702~
>> 
>> ap: !? (wait Ms T "Sd")
>> 
>> Select error: Invalid argument
>> 
>> ap? Select error: Invalid argument
>> 
>> ap? Select error: Invalid argument
>> 
>> …
>> ap? Select error: Invalid argument
>> ap? Segmentation fault: 11
>> 
>> It has the same behavior as the previous version of pil21.
>> 
>> Regards,
>> Andras Pahi
>> 
>>> On 2021. Apr 15., at 12:51, Alexander Burger  wrote:
>>> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
>>>> Looks like I should do that.
>>> 
>>> Done!
>>> 
>>> Can somebody test on a Macintosh or other BSDs?
>>> 
>>> ☺/ A!ex
>>> 
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi,

I grabbed the latest pil21.tgz and demoApp.tgz.
"pil @lib/test.l +" runs without errors.

On macOS I've got

/pil app/main.l -ap~main -'go 4040' +
6538 = 58885 48782252818959702~
ap: !? (wait Ms T "Sd")
Select error: Invalid argument
ap? Select error: Invalid argument
ap? Select error: Invalid argument
…
ap? Select error: Invalid argument
ap? Segmentation fault: 11

It has the same behavior as the previous version of pil21.

Regards,
Andras Pahi

> On 2021. Apr 15., at 12:51, Alexander Burger  wrote:
> 
> On Thu, Apr 15, 2021 at 09:34:50AM +0200, Alexander Burger wrote:
>> Looks like I should do that.
> 
> Done!
> 
> Can somebody test on a Macintosh or other BSDs?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: Why do waitFd and gPoll use 292MY for timeout?

[Andras Pahi]

Hi,

Yes, ‘int’ is 32bit on macOS, even when compiling to 64bit.
The pil21 demoApp does not work on macOS.

pahihu

sizeof(char) = 1
sizeof(short) = 2
sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 16
sizeof(void*) = 8


> On 2021. Apr 15., at 7:46, Alexander Burger  wrote:
> 
> In summary, the problem seems to be that 'int's on the Mac are only 32 bit. 
> But
> that would break many other things, no? Any other Mac users here? I thought
> pil21 runs on the Mac (?).
> 
> ☺/ A!ex

Re: Pil21 feature questions

[Andras Pahi]

Hi Alex,

Thank you for the descriptions.

Regards,
Andras

> On 2020. Nov 10., at 12:49, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> I would like to ask some questions on Pil21 features.
>> It is enough if you points to some examples where I could dig into the
>> details...
> 
> These are indeed very good questions! Thanks that you ask, they need to be
> clarified.
> 
> 
>> - What is special in the ‘priv’ namespace handling?
>>  pil64 used it to store (private) symbols.
> 
> I noticed that the way pil64 implemented the 'private' function was not good.
> 
> It created a normal namespace 'priv' on-the-fly, interned the given symbols 
> into
> that namespace, and then put 'priv' as the *second* namespace in the search
> order:
> 
>   : (private) foo  # Intern 'foo' in 'priv'
> 
>   : (symbols)  # Search order
>   -> (pico priv)
> 
> So now 'foo' is indeed private. The problem is that *if' another symbol named
> "foo" exists in 'pico', it overshadoes the 'foo' in 'priv', and this is not 
> what
> is expected for a private symbol.
> 
> 
> Pil21 implements a special handling for 'priv'. Now 'priv' is part of the
> interpreter core, and behaves a little different from normal namespaces.
> 
>   : (private) foo  # Intern 'foo' in 'priv'
> 
>   : (symbols)  # Search order
>   -> (pico)
> 
>   : (all 'priv)
>   -> (priv~foo)
> 
> 'priv' is not put into the search order at all, but internally it is always
> searched first. That way it will not be overridden by symbols with the same
> names in 'pico', but still *new* symbols will be interned in 'pico'.
> 
> 
>> - What is the purpose of the ‘~’ marker in the namespaces?
> 
> This is only used for error checking: To check in 'symbols' that the arguments
> are really namespaces, and that 'nsp' in 'nsp~foo' is OK.
> 
> 
>> - What does it mean, that map functions accept atomic arguments?
>>  It is not required to pass lists as arguments?
>>  Atomic arguments are handled as 1-item lists or infinite lists with the 
>> same item?
> 
> Yes, the latter.
> 
> In pil32 and pil64 you could call
> 
>   : (mapcar * (1 2 3 4 5 6) (2 .))
>   -> (2 4 6 8 10 12)
> 
> i.e. supply an infinite list of 2's.
> 
> Now in pil21 you can simply call
> 
>   : (mapcar * (1 2 3 4 5 6) 2)
> 
> This is especially useful if '2' is not a constant, e.g.
> 
>   (mapcar * Lst Factor)
> 
> In pil64 you would need to build the circular list explicitly:
> 
>   (mapcar * Lst (circ Factor))
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Pil21 feature questions

[Andras Pahi]

Hi Alex,

I would like to ask some questions on Pil21 features.
It is enough if you points to some examples where I could dig into the 
details...

- What is special in the ‘priv’ namespace handling?
  pil64 used it to store (private) symbols.

- What is the purpose of the ‘~’ marker in the namespaces?

- What does it mean, that map functions accept atomic arguments?
  It is not required to pass lists as arguments?
  Atomic arguments are handled as 1-item lists or infinite lists with the same 
item?

Thank you,
Andras


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

On Ubuntu only -D_GNU_SOURCE helps, -D__USE_GNU is not enough.
It seems that the portability of the glibc API is gone as well…

Regards,
Andras

PS: I found the following on stackoverflow:

_GNU_SOURCE is the only one you should ever define yourself. __USE_GNU is 
defined internally through a mechanism in features.h (which is included by all 
other glibc headers) when _GNU_SOURCE is defined, and possibly under other 
conditions. Defining or undefining __USE_GNU yourself will badly break the 
glibc headers.

> On 2020. Nov 8., at 13:59, Alexander Burger  wrote:
> 
> On Sun, Nov 08, 2020 at 01:48:16PM +0100, Alexander Burger wrote:
>> Should we really do that? How portable are we then?
> 
> Anyway, I released it. Though I don't like it.
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

I’ve checked pil21.tgz which you reverted yesterday on Ubuntu Linux with 
llvm-10.
I need to define _GNU_SOURCE to get the definition of RTLD_DEFAULT to compile 
lib.c.
It passes the pil21 tests with ./pil @lib/test.l +
(%@ “cos” 1.0 (1.0 . 1.0)) and (native “@“ “cos” 1.0 (1.0 . 1.0)) works also.

Why do you reverted the sources ?
It works perfectly on Darwin (macOS Mojave 10.14.6) and Ubuntu Linux 18.04.5 
LTS.

Regards,
Andras



> On 2020. Nov 8., at 9:51, Alexander Burger  wrote:
> 
> On Sun, Nov 08, 2020 at 08:46:23AM +0100, Andras Pahi wrote:
>> SHARED = -dynamiclib -undefined dynamic_lookup
> 
> Also, SHARED does not address the problem.
> 
> It is used for linking the *libraries* ext.so and ht.so
> 
> The problem with native is that symbols in the *executable* bin/picolisp are 
> not
> found by dlsym() at runtime.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi all,

I modified the Makefile to match my llvm-10 installation (the executables
Are postfixed with “-mp-10”) and added include and lib directory pathes,
modified the SHARED define as

SHARED = -dynamiclib -undefined dynamic_lookup

Then issued

make
make clean
make

To rebuild the resulting picolisp executable with itself.

Regards,
Andras


> On 2020. Nov 8., at 7:14, Alexander Burger  wrote:
> 
> On Sat, Nov 07, 2020 at 09:22:48PM +0100, Alexander Burger wrote:
>> On Sat, Nov 07, 2020 at 08:01:01PM +0100, Andras Pahi wrote:
>> I revert for now
> 
> Perhaps it needs some command-line flag expoting the symbols in the 
> executable?
> 
> ☺/ A!ex
> 
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

Yes, it works.

Running @lib/test.l returns “OK” and all openGl examples 
are working on Darwin replacing glutMainLoopEvent with glutCheckLoop.

As I see you’ve updated the documentation on pil21.
So it’s time to include those changes in my fork as well.

Regards,
Andras

> On 2020. Nov 7., at 19:32, Alexander Burger  wrote:
> 
> I fixed and released it :)
> 
> ☺/ A!ex


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

Nope, native does NOT work with “@“ on Darwin.

The definition of RTLD_DEFAULT is

dlfcn.h:#define RTLD_DEFAULT((void *) -2)

So it seems that is the culprit.

Regards,
Andras


> On 2020. Nov 7., at 18:37, Alexander Burger  wrote:
> 
> On Sat, Nov 07, 2020 at 06:17:30PM +0100, Alexander Burger wrote:
>>> : (de %@ @ (pass 'native "libSystem.B.dylib"))
>> ...
> 
> Hmm, an idea:
> 
> Can it be that RTLD_DEFAULT is not zero (null) in Darwin?
> 
> Looks like 'native' has such an assumption. But then, on the other hand, 
> neither
> (native "@" "foo" ..) nor (%@ "foo" ...) would work. And, as I understood you,
> 'native' *does* work with "@" ...
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

Yes, it is the same issue as Mike pointed out: accessing the main binary with 
“@“ does not work.

But with some cheating:

===> ./pil +
: (de %@ @ (pass 'native "libSystem.B.dylib"))
# %@ redefined
-> %@
: (scl 6)
-> 6
: (%@ "cos" 1.0 (1.0 . 1.0))
-> 540302
: (load "misc/pyramids.l")

pyramids.l works as expected.

Regards,
Andras

> On 2020. Nov 7., at 17:36, Alexander Burger  wrote:
> 
> Hi Jon & Andras,
> 
>> I have now changed lib/openGl.l as you described, and when I do
> 
> OK, so "Darwin" is generated in 'make', and not "Macos". I change it back.
> 
>> $ ./pil misc/sphere.l +
>> then I get a nice sphere.
> 
> Cool!
> 
> 
>> If I do
>> $ ./pil misc/cube.l +
>> then I get a window with a gray background, but no visible cube.
> 
> So this might be what Andras wrote: It needs glutCheckLoop instead of
> glutMainLoopEvent?
> 
> 
>> If I do
>> $ ./pil misc/pyramids.l +
>> then I get no graphics, only this:
>> [misc/pyramids.l:182] !? (%@ "cos" 100 "Dbl1")
>> Bad ffi
> 
> And this is the issue Mike talked about: Accessing code in the main binary 
> with
> "@" does not work.
> 
> Perhaps it is only '%@'? If
> 
>   : (%@ "cos" 1.0 (1.0 . 1.0))
>   -> 540302
> 
> does not work, how about this one?
> 
>   : (native "@" "cos" 1.0 (1.0 . 1.0))
>   -> 540302
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex & Jon,

I’ve grabbed the latest pil21 sources (6nov2020), and compiled on macOS Mojave.
*OS gives back:

===> ./pil +
: *OS
-> "Darwin"
:

Running @lib/test.l produces:

===> ./pil @lib/test.l +
[test/src/main.l:19] !? (%@ "socket" 'I AF_INET6 "Type" 0)
Bad ffi
?

The openGl examples cube.l and sphere.l works as expected.
Running misc/pyramids.l produces:

===> ./pil @misc/pyramids.l +
[misc/pyramids.l:182] !? (%@ "cos" 100 "Dbl1")
Bad ffi
openGl?


Regards,
Andras


> On 2020. Nov 7., at 11:31, Alexander Burger  wrote:
> 
> On Sat, Nov 07, 2020 at 11:14:13AM +0100, Andras Pahi wrote:
>> I’ve checked Alex’s code on my picoLisp fork only.
>> What is the value of *OS on pil21 ?
>> It seems, that it is NOT “Darwin”, because *GlutLib is “libglut.so.3” 
>> instead of “GLUT.framework/GLUT"
> 
> Yes, I have already changed
> 
>   < (if (= *OS "Darwin")
>   ---
>> (if (= *OS "Macos")
>   17,18c17,18
>   <   *GluLib "libGLU.so.1"
>   <   *GlutLib "libglut.so.3" ) )
>   ---
>>  *GluLib "libGLU.so"
>>  *GlutLib "libglut.so" ) )
> 
> in lib/openGl.l
> 
> Not sure what the right lib names are, depending
> on the system.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Jon,

I’ve checked Alex’s code on my picoLisp fork only.
What is the value of *OS on pil21 ?
It seems, that it is NOT “Darwin”, because *GlutLib is “libglut.so.3” instead 
of “GLUT.framework/GLUT"

Regards,
Andras

> On 2020. Nov 7., at 10:56, Jon Kleiser  wrote:
> 
> Hi Andras,
> 
> I have now modified my openGl.l the same way, but I still get this:
> 
> [misc/cube.l:13] !? (native "libglut.so.3" "glutInit" NIL '(NIL (8) . 0))
> "libglut.so.3" -- [DLL] dlopen(libglut.so.3, 9): image not found
> openGl? 
> 
> Am I missing some libglut.so? I have macOS Mojave 10.14.6.
> 
> /Jon
> 
>> On 5 Nov 2020, at 19:42, Andras Pahi > <mailto:pa...@t-online.hu>> wrote:
>> 
>> Hi all,
>> 
>> I’ve modified openGl.l as follows:
>> 
>> (if (= *OS "Darwin")
>>(default
>>   *GluLib "OpenGL.framework/OpenGL"
>>   *GlutLib "GLUT.framework/GLUT"
>>   *GlutCheckEvent "glutCheckLoop" )
>>(default
>>   *GluLib "libGLU.so.1"
>>   *GlutLib "libglut.so.3"
>>   *GlutCheckEvent "glutMainLoopEvent" ) )
>> 
>> ...
>> (de glutMainLoopEvent ()
>>(native `*GlutLib `*GlutCheckEvent) )
>> 
>> Regards,
>> Andras
>> 
>>> On 2020. Nov 5., at 19:35, Andras Pahi >> <mailto:pa...@t-online.hu>> wrote:
>>> 
>>> Hi all,
>>> 
>>> You need to change glutMainLoopEvent to glutCheckLoop on MacOS.
>>> Everything works as expected on my fork (not pil21, sorry).
>>> 
>>> I have attached the screenshots.
>>> 
>>> Regards,
>>> Andras
>>> 
>>> 
>>> 
>>> 
>>>> On 2020. Nov 5., at 19:00, Alexander Burger >>> <mailto:a...@software-lab.de>> wrote:
>>>> 
>>>> On Thu, Nov 05, 2020 at 07:50:01PM +0200, Mike wrote:
>>>>> 
>>>>>> I hear from Mike that "Darwin" is not correct for pil21.
>>>>>> 
>>>>>> "Macos"?
>>>>> 
>>>>> This is not issue anymore, I have manually disabled this if to use 
>>>>> correct definitions. 
>>>> 
>>>> Right. But it is needed so that it also runs on other systems.
>>>> The else-bodo of the 'if' works for me under Debian.
>>>> 
>>>> ☺/ A!ex
>>>> 
>>>> -- 
>>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe 
>>>> <mailto:picolisp@software-lab.de?subject=Unsubscribe>
>>> 
>> 
> 

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

So you’ve found it yourself, that the types and the number of args 
should not change between invocations.

So I’ve changed the native call syntax to mark variable-args functions,
instead of using a fresh binding for every call.

Regards,
Andras

> On 2020. Nov 6., at 8:07, Alexander Burger  wrote:
> 
> On Thu, Nov 05, 2020 at 11:00:39PM +0100, Alexander Burger wrote:
>> Also, I see no reason why 'native' should not work with normal variable-args
>> functions like printf() in pil21. As far as I see, it works fine.
>> 
>>   : (native "@" "printf" 'I "abc%d%s^J" (+ 3 4) (pack "X" "Y" "Z"))
>>   abc7XYZ
>>   -> 8
> 
> Well, this is not completely true. It works under certain conditions (if the
> types of the calls stay the same, and the number of args is not increased in
> subsequent calls). Even such cases can be handled though, by simply using a
> fresh transient for the function argument symbol.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi all,

On macOS Mojave 10.14 the system supplied GLUT.framework/GLUT
does not contain glutMainLoopEvent, only glutCheckLoop.
I’ve just made it work on my Mac.

I use the pil21-version of @lib/openGl.l
See the sources at https://github.com/pahihu/picoLisp/blob/master/lib/openGl.l 

For reference see https://github.com/pahihu/picoLisp/blob/master/README 


Regards,
Andras

> On 2020. Nov 5., at 19:50, Alexander Burger  wrote:
> 
> It was Jon who wrote those demos (and large parts of @lib/openGl.l), so we
> should better let him decide what to do.
> 
> 
>> Everything works as expected on my fork (not pil21, sorry).
> 
> Great! For me on Debian (pil21) it works fine too.
> 
> As you have your own system, I presume you did also not use the pil21-version 
> of
> @lib/openGl.l, right? It is heavily re-coded, using a separate namespace.

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi all,

I’ve modified openGl.l as follows:

(if (= *OS "Darwin")
   (default
  *GluLib "OpenGL.framework/OpenGL"
  *GlutLib "GLUT.framework/GLUT"
  *GlutCheckEvent "glutCheckLoop" )
   (default
  *GluLib "libGLU.so.1"
  *GlutLib "libglut.so.3"
  *GlutCheckEvent "glutMainLoopEvent" ) )

..
(de glutMainLoopEvent ()
   (native `*GlutLib `*GlutCheckEvent) )

Regards,
Andras

> On 2020. Nov 5., at 19:35, Andras Pahi  wrote:
> 
> Hi all,
> 
> You need to change glutMainLoopEvent to glutCheckLoop on MacOS.
> Everything works as expected on my fork (not pil21, sorry).
> 
> I have attached the screenshots.
> 
> Regards,
> Andras
> 
> 
> 
> 
>> On 2020. Nov 5., at 19:00, Alexander Burger > <mailto:a...@software-lab.de>> wrote:
>> 
>> On Thu, Nov 05, 2020 at 07:50:01PM +0200, Mike wrote:
>>> 
>>>> I hear from Mike that "Darwin" is not correct for pil21.
>>>> 
>>>> "Macos"?
>>> 
>>> This is not issue anymore, I have manually disabled this if to use correct 
>>> definitions. 
>> 
>> Right. But it is needed so that it also runs on other systems.
>> The else-bodo of the 'if' works for me under Debian.
>> 
>> ☺/ A!ex
>> 
>> -- 
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe 
>> <mailto:picolisp@software-lab.de?subject=Unsubscribe>
> 

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi Alex,

Yes, I have some experience.
I use libffi to implement native calls in my picoLisp fork (32bit/64bit) on 
MacOS.

Andras

> On 2020. Nov 5., at 17:47, Alexander Burger  wrote:
> 
> On Thu, Nov 05, 2020 at 05:14:03PM +0100, Alexander Burger wrote:
>> So perhaps the output of strace tells us more.
> 
> Hmm, not really. Mike posted one in IRC. It says "invalid kernel access" 
> several
> times, but I have no idea what it means.
> 
> Does anybody have experience with libffi on Mac?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: pil21 on Mac, some errors

[Andras Pahi]

Hi all,

> On 2020. Nov 5., at 16:03, Alexander Burger  wrote:

> This is strange, because "@" is *no* lib at all. It is a special token
> interpreted by PicoLisp as "in this executable binary".
> 
> Did it work with "emu" under MacOS? It used the same mechanism.

Yes. It works with emu under MacOS.

Andras Pahi


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

Re: picoLisp 19.12: variable length array in structure fixes

[Andras Pahi]

Hi all,

The code at https://github.com/pahihu/picoLisp 
 fulfils Mike’s super
goal - all pil64 specific tests passed as well. It has namespaces,
native C calls and coroutines and the documented features of
pil64 - except the external symbol and database format.

Andras

> On 2020. Apr 19., at 13:11, Mike  wrote:
> !!!
> Super goal - huge.l should pass all code with your patch set.
> 
> 
> p.s. I dont have enough energy right now to debug all this.  
> 
> (mike)

Re: native/lisp in picolisp32

[Andras Pahi]

Hi,

If you are still interested in native/lisp in picolisp32 then I am working to 
support the pil64
features in picolisp32. The development branch of 
https://github.com/pahihu/picoLisp 
just missing the coroutines (stay tuned), and builds on 64bit/32bit targets.
It uses libffi for the native C calls.

Regards,
Andras

> On 2020. May 8., at 16:36, C K Kashyap  > wrote:
> 
> Thanks Alex,
> I think I'll try and see if I can get a simple SDL callback to work with 
> miniPicoLisp - that way, I can really understand the issues better.
> If I remember correctly - pil21 initially did not have the POSIX requirement. 
> Is there a way to get older versions of pil21 (I know that it is a strange 
> request for a POC :) )
> 
> Thanks Tomas for your ffi link.
> 
> Regards,
> Kashyap
> 
> On Fri, May 8, 2020 at 2:24 AM Tomas Hlavaty  > wrote:
> Hi Kashyap,
> 
> C K Kashyap mailto:ckkash...@gmail.com>> writes:
> > I am now trying to figure out how to do FFI min miniPicoLisp and I
> > realized that only pil64 has native/lisp support. Is there any reason
> > it could not be done in the 'c' implementation of pil32? I just wanted
> > to make sure that there is no "impossibility" about attempting to port
> > the native/lisp functions to miniPicoLisp.
> 
> here is an example of ffi with minipicolisp:
> https://logand.com/sw/mplisp/files.html 
> 
> 
> Cheers
> 
> Tomas
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de 
> ?subject=Unsubscribe

Re: Structure sharing bignums in pil32

[Andras Pahi]

Thank you Alex.

> On 2020. May 4., at 7:06, Alexander Burger  wrote:
> 
> Hi Andras,
> 
>> I would like to ask that structure sharing is used in pil32 bigNums or not ?
>> In doSub(), doAbs() it uses structure sharing, but otherwise in big.c
>> it copies the argument then modifies it.
> 
> Correct. And also in pil64 and pil21.
> 
> All other arithmetic operations except add/sub cannot share structures, 
> because
> the whole number is modified. What *is* used whenever possitle are destructive
> operations to avoid unnecessary copies.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Structure sharing bignums in pil32

[Andras Pahi]

Hello all,

I would like to ask that structure sharing is used in pil32 bigNums or not ?
In doSub(), doAbs() it uses structure sharing, but otherwise in big.c
it copies the argument then modifies it.

Thanks,
Andras




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

Pil transformed

[Andras Pahi]

Hi all,

I have changed the 32bit pil version written in C to compile in 64bit mode
and to support short numbers encoded in the pointers themselves.
That means that (== 64 64) is T for both the 32bit and the 64bit version.

It passes the picoLisp test suite and tankf33der’ test suite as well.
The tests should be modified to detect this particular version with
(and *CPU (== 64 64)) because it does not support the constructs of pil64.

No doubt pil64 still has the performance advantage, running tankf33der’s
Test suite:

pil64 9m40s
pil, 64bit 14m 
pil, 32bit 18m40s

If anyone is interested the sources can be found at 
https://github.com/pahihu/picoLisp 

Happy Lisping!

Andras

Re: picoLisp 19.12: variable length array in structure fixes

[Andras Pahi]

Hi,

Maybe not related to this one, but on Mac OS X the heap size is limited
to 65532KB. On startup picolisp fails to set the unlimited stack size,
And use the actual ulimit so on the first run I’ve got a SIGSEGV running 
code2015.l

Andras


> On 2020. Apr 21., at 10:38, Mike  wrote:
> 
> hi all,
> 
>> If you are interested I have patched the 19.12 32bit sources to compile 
>> without GCC.
>> I have attached the changed files: pico.h, main.c, apply.c and flow.c
>> 
>> Since clang does not support variable length array in structures I allocate 
>> the bindFrame
>> with alloca() and provided a macro in pico.h to ease this: allocFrame().
>> 
>> I know that the 32bit version is not the mainstream version, but feel free to
>> abuse the patches.
> 
> FYI
> 
> Breaking news from secret testing laboratory:
> pil32-original and pil32-VLA killed by malloc guard in OpenBSD 6.6+syspatch:
> $ sysctl -w vm.malloc_conf="SC"
> $ pil code2015.l +
> Segmentation fault (core dumped)
> $ dmesg | tail -1
> [picolisp]35577/479639 sp=cefce000 inside cefcf000-cf7ce000: not MAP_STACK
> 
> p.s. BTW, ASan from gcc and clang - ok
> p.s.s. Several years ago (6.2-6.4 ?) it worked.
> 
> (mike)
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: picoLisp 19.12: variable length array in structure fixes

[Andras Pahi]

Hi Mike,

pil32, x64 means you’ve built the contents of the src/ dir in x64 mode ?

Thanks,
Andras

> There are more numbers for the only task "advent2015":
> pil64, x64 - 1 min
> pil32, x64 - 9 min
> pil32, 686 - 9 min
> pil32, 686, -O3 - 7 min
> VLA patch, 686 - 10 min
> 
> (mike)
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

Re: picoLisp 19.12: variable length array in structure fixes

[Andras Pahi]

Hi Mike,

You don’t need energy, you need some patience.

Andras

===> time pil huge.l -bye
OK-UTF8
OK-Montgomery
OK-Leibniz
OK-math
OK-forth
OK-parse2list
OK-mapreduce
OK-pow
OK-destr
OK-test-car
OK-bitwise
# reduce redefined
# pow redefined
OK-4clojure
# pow redefined
OK-AoC15
OK-SimplyScheme
# lcm redefined
# evenp redefined
# second redefined
# mystery redefined
# add1 redefined
# numbers redefined
# half redefined
OK-Touretzky
# prime? redefined
OK-Menshikov
# pow redefined
# exp redefined
# log redefined
# sin redefined
# cos redefined
# tan redefined
# asin redefined
# acos redefined
# atan redefined
# atan2 redefined
# create redefined
# inrow redefined
# f3-1 redefined
# f3-2 redefined
# f3-3 redefined
# f4-2 redefined
# f4-3 redefined
# f8-22 redefined
OK-Gorlansky
OK-Stepanoff
SIPHASH-OK
# mod32+ redefined
# endian redefined
Hash-ALL-OK
OK-RNG
OK-HKDF
OK-test-pbkdf2
# pow redefined
# exp redefined
# log redefined
# sin redefined
# cos redefined
# tan redefined
# asin redefined
# acos redefined
# atan redefined
# atan2 redefined
OK-HMAC
OK-test-MD5
OK-test-MD2
OK-test-aes
# totwo redefined
# fromtwo redefined
# tilde redefined
OK-test-KECCAK
OK-test-SHA512
OK-test-SHA256
OK-test-RIPEMD160
# mod32+ redefined
# hex2L redefined
OK-test-Blowfish
OK-test-bcrypt
# mod32+ redefined
# mod32* redefined
# hex2L redefined
OK-test-twofish
# endian redefined
OK-test-threefish
# hex2L redefined
OK-test-RC2
# mod32* redefined
# hex2L redefined
OK-test-rc5
OK-test-rc6
# f redefined
# num64 redefined
# create redefined
OK-test-camellia
# expand redefined
OK-test-idea
OK-test-MD4
OK-test-SHA1
# num64 redefined
# sbox redefined
OK-test-Tiger
# wsbox redefined
OK-test-Whirlpool
OK-test-JH256
# num32 redefined
OK-test-anubis
# rol redefined
OK-test-scrypt
# endian redefined
OK-test-blake2s
# endian redefined
OK-test-blake2b
# i redefined
OK-test-Kangaroo12
crypto-ALL-OK
OK-All

real13m46.284s
user13m58.501s
sys 0m15.341s


> On 2020. Apr 19., at 13:11, Mike  wrote:
> 
> hi all,
> 
>> If you are interested I have patched the 19.12 32bit sources to compile 
>> without GCC.
>> I have attached the changed files: pico.h, main.c, apply.c and flow.c
> 
> My testing status for https://github.com/picolisp/picolisp
> 
> 1. pil @lib/test.l +
> clang  - ok
> clang+asan - ok
> tcc-git- ok
> 
> 
> 2. huge.l - failed (you must take care)
> $ git clone https://git.envs.net/mpech/tankf33der.git
> $ cd tankf33der
> $ pil huge.l + 
> OK-UTF8
> OK-Montgomery
> OK-Leibniz
> OK-math
> OK-forth
> OK-parse2list
> OK-mapreduce
> OK-pow
> OK-destr
> OK-test-car
> OK-bitwise
> # reduce redefined
> # pow redefined
> OK-4clojure
> # pow redefined
> // hangs in advent2015/code2015.l
> // is it hangs or very-very slow?
> // the same in crypto/test.l
> 
> !!!
> Super goal - huge.l should pass all code with your patch set.
> 
> 
> p.s. I dont have enough energy right now to debug all this.  
> 
> (mike)
> 
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


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

picoLisp 19.12: variable length array in structure fixes

[Andras Pahi]

Hello, 

If you are interested I have patched the 19.12 32bit sources to compile without 
GCC.
I have attached the changed files: pico.h, main.c, apply.c and flow.c

Since clang does not support variable length array in structures I allocate the 
bindFrame
with alloca() and provided a macro in pico.h to ease this: allocFrame().

I know that the 32bit version is not the mainstream version, but feel free to
abuse the patches.

Regards,
Andras Pahi



srchanges.tgz
Description: Binary data

Subscribe

[Andras Pahi]

Hello Andras Pahi  :-)
You are now subscribed



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