Re: pil21 on Mac, some errors

Hi Alex, Yes, but after the Ctrl-D I have to click in the cube window to make it go away. OK as long as one knows this. The pil21 now seems to be usable on macOS, however, the "(cd src; make)” did not work for me; I got some errors. I used the instructions at

Re: pil21 on Mac, some errors

Hi Jon, > Yes, but after the Ctrl-D I have to click in the cube window to make it go > away. I see! Strange, here it is closed automatically. > The pil21 now seems to be usable on macOS, however, the "(cd src; make)” did > not work for me; I got some errors. I used the instructions at >

Re: pil21 on Mac, some errors

Hi Jon, > All three misc examples now worked quite fine. Great! So we can say pil21 is usable on MacOS. > The only problem I had, was exiting the cube.l in a nice way. I can maybe take > a look at that tomorrow. Just press Ctrl-D at the REPL prompt. ☺/ A!ex -- UNSUBSCRIBE:

Re: pil21 on Mac, some errors

Hi all, I now installed a fresh pil21 from https://software-lab.de/pil21.tgz , followed the build instructions at https://git.envs.net/mpech/pil21-tests/src/branch/master/INSTALL-.md , and

Re: pil21 on Mac, some errors

Hi Andras, > On Ubuntu only -D_GNU_SOURCE helps, -D__USE_GNU is not enough. On plain Debian, only _GNU_SOURCE still gives an error. So I've defined both now (in @src/lib.c, to keep it local). ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

On Sun, Nov 08, 2020 at 01:15:00PM +0100, Alexander Burger wrote: > Yes, I did > >#define _GNU_SOURCE >#include > > This works here on Termux, but on Debian I get > >lib.c:493:33: error: use of undeclared > identifier 'RTLD_DEFAULT' > (p->fun = dlsym(lib ?:

Re: pil21 on Mac, some errors

Hi Andras, > 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. Yes, I did #define _GNU_SOURCE #include This works here on Termux, but on Debian I get

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

On Sun, Nov 08, 2020 at 08:46:23AM +0100, Andras Pahi wrote: > SHARED = -dynamiclib -undefined dynamic_lookup > ... Yes? And does now (native "@" ...) and (%@ ...) work with it? BTW, if '%@' does not work, we should notice immediately, as all network access depends on it now (@lib/net.l). ☺/

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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:

Re: pil21 on Mac, some errors

On Sat, Nov 07, 2020 at 08:01:01PM +0100, Andras Pahi wrote: > Yes, it works. > ... But now it does not build in Linux any more :( I revert for now -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pil21 on Mac, some errors

Hi Alex, I have now changed lib/openGl.l as you described, and when I do $ ./pil misc/sphere.l + then I get a nice sphere. If I do $ ./pil misc/cube.l + then I get a window with a gray background, but no visible cube. If I do $ ./pil misc/pyramids.l + then I get no graphics, only this:

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

On Sat, Nov 07, 2020 at 07:32:29PM +0100, Alexander Burger wrote: > Yes, indeed. Must be. > > I fixed and released it :) .. and that after some Beer and Whiskey. Celebrating the kick-out of the WhiteHouseClown. I hope I didn't code complete nonsense. ☺/ A!ex -- UNSUBSCRIBE:

Re: pil21 on Mac, some errors

Hi Andras, > Nope, native does NOT work with “@“ on Darwin. Aahh! I misunderstood. > The definition of RTLD_DEFAULT is > dlfcn.h:#define RTLD_DEFAULT((void *) -2) > > So it seems that is the culprit. Yes, indeed. Must be. I fixed and released it :) ☺/ A!ex -- UNSUBSCRIBE:

Re: pil21 on Mac, some errors

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,

Re: pil21 on Mac, some errors

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"

Re: pil21 on Mac, some errors

On Sat, Nov 07, 2020 at 05:59:34PM +0100, Andras Pahi wrote: > 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")) Cool! As I suspected. So it must be a

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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 >

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

Hi Andras, > So you’ve found it yourself, that the types and the number of args > should not change between invocations. In fact the type is not critical, at least on a 64-bit machine, as all arguments are passed to a function as opaque word-sized values (pointer, scalar, double or whatever).

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

> 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

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

Re: pil21 on Mac, some errors

> 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

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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.

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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"

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

Hi Alex, I have put the files into lib and misc. However, I have not installed pil21 "globally" with required symlinks. When I cd to my pil21 directory and then do $ pil21 misc/cube.l then I get this: [misc/cube.l:6] !? (load "@lib/openGl.l") "@lib/openGl.l" -- Open error: No such file or

Re: pil21 on Mac, some errors

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

Re: pil21 on Mac, some errors

Hi Jon, > I look forward to refresh my PicoLisp knowledge. ;-) If you like to experiment: I have updated the OpenGL library in @lib/openGl.l (now using a namespace) and put it together with some of your demo files (cube, sphere and pyramid) into a separate tarball:

Re: pil21 on Mac, some errors

Hi Mike, I now started with a fresh pil21 source and followed your updated macOS instructions. This time I got no error messages. Thanks! My setup is this: macOS Mojave 10.14.6 llvm 11.0.0 libffi 3.3 ncurses 6.2 readline 8.0.4 I look forward to refresh my PicoLisp knowledge. ;-) /Jon > On

Re: pil21 on Mac, some errors

Hi Jon, > I now started with a fresh pil21 source and followed your updated macOS > instructions. This time I got no error messages. Thanks! > > My setup is this: > > macOS Mojave 10.14.6 > llvm 11.0.0 > libffi 3.3 > ncurses 6.2 > readline 8.0.4 Cool, congratulations! > I look forward to

Re: pil21 on Mac, some errors

October 26, 2020 10:08 AM, "Jon Kleiser" wrote: > Hi, > > Yesterday I tried installing pil21 on my Mac, following Mike Pechkin's > instructions here: > > https://git.envs.net/mpech/pil21-tests/src/branch/master/INSTALL-.md > > Here’s the output from the last line: > > $ gcc sysdefs.c &&

Re: pil21 on Mac, some errors

> I'm not sure, but after I sent Mike's link to another MacOS user, he answered: > > By following his instruction for macOS 10.15, I was able to build/run on Mac. > I just needed to upgrade homebrew tools, and use GCC-9 for opt assembler. > > No idea what that means, but perhaps you know? >

Re: pil21 on Mac, some errors

> It boils down to: use current versions of your toolchain. On my mint19 > machine i had to manually update llvm from 6(?) to 10 :) > Right, pil21 only works in LLVM7+ environment. (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: pil21 on Mac, some errors

> Is there some easy fix to get rid of these errors? Sure, I will try repeat steps from scratch this evening on Mac and will update the steps p.s. BTW, homebrew switched to LLVM11. Lucky pil21 supports and tested on LLVM11 too. (mike) -- UNSUBSCRIBE:

Re: pil21 on Mac, some errors

Am Mon, 26 Oct 2020 11:15:02 +0100 schrieb Alexander Burger : > Hi Jon, > > > Yesterday I tried installing pil21 on my Mac, following Mike > > Pechkin's instructions here: > > https://git.envs.net/mpech/pil21-tests/src/branch/master/INSTALL-.md > >

Re: pil21 on Mac, some errors

Hi Jon, > Yesterday I tried installing pil21 on my Mac, following Mike Pechkin's > instructions here: > https://git.envs.net/mpech/pil21-tests/src/branch/master/INSTALL-.md > > > Here’s the output from the last line: > ...