Re: PilCon Friday

[Kevin Ednalino]

Personally, I work business hours so Friday mornings I'm generally
unavailable (GMT).

I think at least one on the weekday in the afternoon/evening and one on the
weekend might be the most convenient with the latter more convenient for
non-European timezones. For example, if it's hosted on Saturday at noon
then it'd be roughly morning for the Americas and evening for Asia.

If doing 2x meetings a month, then alternating each month with the
weekday/weekend day might maximize availability like if someone is busy
during the week and/or busy during the weekend (if busy both times, just
have to wait untill the next meeting!):

Month: Week 1 / Week 2
Nov: Wed/Sat
Dec: Fri/Sun
Jan: Wed/Sat
..

Or even alternate just weekends weekly between Saturday and Sunday.

On Thu, Nov 5, 2020 at 6:42 PM Alexander Burger  wrote:

> On Thu, Nov 05, 2020 at 01:23:13PM -0500, r cs wrote:
> > Raw video would be welcomed.  The timing of the PilCon can be challenging
> > in some time zones.
>
> Independent of the recording issue, the current scheduling is not an
> absolute
> must. I did a proposal initially, and nobody complained, so we stayed with
> it.
>
> Should we consider a change for the future? Perhaps Saturday would be
> better
> than Friday? And/or some other UTC time(s)? Should we try some democratic
> decision process?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: pil21 on Mac, some errors

[Mike]

> Right. But it is needed so that it also runs on other systems.
> The else-bodo of the 'if' works for me under Debian.

Just hack for testing.

(mike)

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

Re: pil21 on Mac, some errors

[Alexander Burger]

On Thu, Nov 05, 2020 at 08:30:18PM +0100, Alexander Burger wrote:
> In fact, in pil21 I decided simply *not* to support ffi calls to functions 
> with
> a variable number of arguments. The reason is to keep it simple (and because
> such functions are not frequent).

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

☺/ A!ex

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

Re: pil21 on Mac, some errors

[Mike]

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

(mike)



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

Re: pil21 on Mac, some errors

[Mike]

November 5, 2020 7:09 PM, "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?
> 

1. it was system integrity protection, disabled for dtruss for future run.

2. installation
brew cask install xquartz
brew install freeglut
reboot

3. changed pathes to glut libraries in @lib/openGl.l
 (default
  *GluLib "libGLU1.dylib"
  *GlutLib "libglut.3.dylib" ) )

4. and now i am getting this error:
$ pil21 @misc/cube.l
: !? (native "libGLU.1.dylib" "gluPerspective" NIL "*Dbl1" "*Dbl2" "*Dbl3" 
"*Dbl4")
"libGLU.1.dylib" -- [DLL] dlopen(libGLU.1.dylib, 9): image not found
? 
: 


(mike)

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

Re: pil21 on Mac, some errors

[Alexander Burger]

On Thu, Nov 05, 2020 at 08:10:49PM +0100, Andras Pahi wrote:
> For reference see https://github.com/pahihu/picoLisp/blob/master/README 
> 

Cool: "fixed arguments must be marked with T". Good idea!

In fact, in pil21 I decided simply *not* to support ffi calls to functions with
a variable number of arguments. The reason is to keep it simple (and because
such functions are not frequent).

☺/ A!ex

-- 
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: PilCon Friday

[Davide BERTOLOTTO]

For me later in the evening after 17-18 CET would be Better.

On Thu, Nov 5, 2020, 19:41 Alexander Burger  wrote:

> On Thu, Nov 05, 2020 at 01:23:13PM -0500, r cs wrote:
> > Raw video would be welcomed.  The timing of the PilCon can be challenging
> > in some time zones.
>
> Independent of the recording issue, the current scheduling is not an
> absolute
> must. I did a proposal initially, and nobody complained, so we stayed with
> it.
>
> Should we consider a change for the future? Perhaps Saturday would be
> better
> than Friday? And/or some other UTC time(s)? Should we try some democratic
> decision process?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: pil21 on Mac, some errors

[Mike]

hi all,


> 3. It is the general problem with libffi which was mentioned by Mike. I don't
> know more about it atm.

I've got access to MacOs again to test libffi interface:

1. trivial test works:
$ pil21 +
: (native "./native.so" "returnbyte" 'B)
-> 255
: 

2. (native "@" ...) will fail because macos has different libc system name:
$ pil21 + 
: (native "@" "getenv" 'S "TERM")
Bad ffi
? 
: (native "libSystem.B.dylib" "getenv" 'S "TERM")
-> "xterm-256color"

In general should be fine.

(mike)

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

Re: pil21 on Mac, some errors

[Alexander Burger]

On Thu, Nov 05, 2020 at 07:35:58PM +0100, Andras Pahi wrote:
> Hi all,
> 
> You need to change glutMainLoopEvent to glutCheckLoop on MacOS.

Interesting.

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.


Still the question remains if and what is wrong with openGl in pil21.

☺/ A!ex

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

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

Re: PilCon Friday

[Alexander Burger]

On Thu, Nov 05, 2020 at 01:23:13PM -0500, r cs wrote:
> Raw video would be welcomed.  The timing of the PilCon can be challenging
> in some time zones.

Independent of the recording issue, the current scheduling is not an absolute
must. I did a proposal initially, and nobody complained, so we stayed with it.

Should we consider a change for the future? Perhaps Saturday would be better
than Friday? And/or some other UTC time(s)? Should we try some democratic
decision process?

☺/ A!ex

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

Re: PilCon Friday

[r cs]

Raw video would be welcomed.  The timing of the PilCon can be challenging
in some time zones.

Cheers,
rcs

On Thu, Nov 5, 2020 at 1:09 PM Edgaras Šeputis  wrote:

> Yes, please, find some way to record it. Even if fully unedited and
> unstructured. One can download video from youtube and do quick seeks to
> find stuff.
>
> On Thu, Nov 5, 2020 at 9:14 AM C K Kashyap  wrote:
>
>> While at it, it would be good to touch on the "interpreter only" approach
>> of PicoLisp. It is objectively simpler than an interpreter AND compiler
>> implementation. However, I would love for some expansion on the explanation
>> of "True equivalence of code and data". Also, is there any update to the
>> view on performance in the context of new machines.
>>
>> Would it be possible to record these?
>>
>> Regards,
>> Kashyap
>>
>> On Wed, Nov 4, 2020 at 8:32 AM Alexander Burger 
>> wrote:
>>
>>> Hi Alex,
>>>
>>> > For me the greatest obstacle in using picolisp is the lack of arrays.
>>> Let's
>>> > talk about what I'm doing wrong and why I don't need them!
>>>
>>> Yes, good idea. This is a valid and common question.
>>>
>>> Maybe, as a warm-up, you could also check "Array Abstinence" at
>>>
>>>https://picolisp.com/wiki/?arrayabstinence
>>>
>>> ☺/ A!ex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>

-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: PilCon Friday

[Edgaras Šeputis]

Yes, please, find some way to record it. Even if fully unedited and
unstructured. One can download video from youtube and do quick seeks to
find stuff.

On Thu, Nov 5, 2020 at 9:14 AM C K Kashyap  wrote:

> While at it, it would be good to touch on the "interpreter only" approach
> of PicoLisp. It is objectively simpler than an interpreter AND compiler
> implementation. However, I would love for some expansion on the explanation
> of "True equivalence of code and data". Also, is there any update to the
> view on performance in the context of new machines.
>
> Would it be possible to record these?
>
> Regards,
> Kashyap
>
> On Wed, Nov 4, 2020 at 8:32 AM Alexander Burger 
> wrote:
>
>> Hi Alex,
>>
>> > For me the greatest obstacle in using picolisp is the lack of arrays.
>> Let's
>> > talk about what I'm doing wrong and why I don't need them!
>>
>> Yes, good idea. This is a valid and common question.
>>
>> Maybe, as a warm-up, you could also check "Array Abstinence" at
>>
>>https://picolisp.com/wiki/?arrayabstinence
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: pil21 on Mac, some errors

[Alexander Burger]

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

Re: pil21 on Mac, some errors

[Alexander Burger]

Hi Andras,

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

Yes, I remember, you patched some files to use clang.

On the other hand, the original @lib/openGl.l was widely extended
and ported to Mac by Jon.

I hear from Mike that "Darwin" is not correct for pil21.

"Macos"?

☺/ A!ex

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

[Alexander Burger]

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

Re: pil21 on Mac, some errors

[Alexander Burger]

Hi Andras,

> Yes. It works with emu under MacOS.

Thanks! Good to know. :)


So perhaps the output of strace tells us more.

@Jon or @Mike:

I would recommend to use "sphere.l" instead of "cube.l", because the latter goes
into a REPL after that and produces too much output.

It can be started as

   $ strace bin/picolisp lib.l lib/misc.l misc/sphere.l 2>err

A mouse click in the OpenGl window closes it. The pastebin the resulting "err"
file.

☺/ A!ex

-- 
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: pil21 on Mac, some errors

[Alexander Burger]

Hi Mike,

> 2. (native "@" ...) will fail because macos has different libc system name:
> $ pil21 + 
> : (native "@" "getenv" 'S "TERM")
> Bad ffi

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.

I think 'strace' shows where it goes wrong.

☺/ A!ex

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

Re: pil21 on Mac, some errors

[Jon Kleiser]

Hi Alex,

I tried
$ ./pil misc/cube.l +

and then I got

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

/Jon

> On 4 Nov 2020, at 21:28, Alexander Burger  wrote:
> 
> Hi Jon,
> 
>> I have put the files into lib and misc.
> 
> This is all right.
> 
> 
>> However, I have not installed pil21 "globally" with required symlinks. When I
> 
> This is also good. Here on my systems I haven't installed it globally either 
> (I
> usually leave the Linux distro's (older) version global as it is).
> 
> 
>> cd to my pil21 directory and then do
>> $ pil21 misc/cube.l
> 
> Out of the box, the command is
> 
>   $ cd pil21
>   $ ./pil misc/cube.l +
> 
> or anything analog, like
> 
>   $ pil21/pil pil21/misc/cube.l +
> 
> i.e. with relative pathes.
> 
> (the '+' is optional, as ever)
> 
> 
>> then I get this:
>> 
>> [misc/cube.l:6] !? (load "@lib/openGl.l")
>> "@lib/openGl.l" -- Open error: No such file or directory
> 
> PicoLisp determines the value of "@.." from the start path. I don't know what
> 'pil21' is in your case.
> 
> 
>> What is the minimal thing (symlink) I have to fix for the lib/openGl.l to be
>> found?
> 
> If you really want to install it globally, I believe the description in the
> INSTALL file is correct.
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> 


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

Re: PilCon Friday

[O.Hamann]

On 04.11.20 11:55, Alexander Burger wrote:
>  we'll meet at 8:00 UTC.
Because of the time change, it's already at 9:00 central european time,
right?

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

Re: pil21 on Mac, some errors

[Alexander Burger]

Hi Jon,

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

Probably one or more of:

1. openGl.l says (if (= *OS "Darwin"). Perhaps this is not properly set by
   Makefile?

2. "libglut.so.3" does not exist. In fact, originally it was just "libglut.so",
   but at least on my system a proper link or so was not set.

3. It is the general problem with libffi which was mentioned by Mike. I don't
   know more about it atm.

☺/ A!ex

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