Re: PilCon 2020
> On Apr 22, 2020, at 14:00, Alexander Burger wrote: > > Hi all, > > yesterday the Oktoberfest, the largest annual event in Bavaria, was canceled. > > I think we will also have to cancel the other large event, PilCon. It is not > sure whether such events will be allowed legally by end of July, and how the > international travel situation will be. > > I hope this is OK for everybody. > > Would it make sense to plan an online conference instead? We are playing > around > with Jitsi Meet currently. Any thoughts? There is a thread on hacknews about jisti vs mumble where they mention issues with a large number of people. https://news.ycombinator.com/item?id=22477785 Maybe it would be nive to do tests with a dozen participants or so before going live ? Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilCon 2020
> On Apr 22, 2020, at 14:00, Alexander Burger wrote: > > Would it make sense to plan an online conference instead? We are playing > around > with Jitsi Meet currently. Any thoughts? You must be aware that the FSF's LibrePlanet was moved from IRL to Jisti (and others) in just a few days of time. In my personal business, I've moved all my IRL interactions to Jisti. I find it very practical. Last night I just had a QA/live support session for a piece of free software that I'm involved with. There were setting issues that probably were personal technical issues but otherwise the meeting went very smoothly. The ability to stream Youtube for already registered presentations is something that could definitely be of use in a conference, leaving the live part for the Q Also, as a "lurker" and very amateur programer, I would never think of joining PilCon in Germany, but I'd love to attend if it were online. I am sure a lot of people interested in other dialects of Lisp would find it easier to join too. Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: MiniPicolisp Questions
Thanks Alex, I was thinking of increased memory space - not exactly doubling - I was thinking it would just be one additional byte per CELL. Ofcourse this additional byte would not have the same lifetime of the CELL so it should not need any extra management. I feel encouraged - I'll give it a try :) Regards, Kashyap On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger wrote: > Hi Kashyap, > > > About the the CELL having an additional byte, I meant that the CELL size > > would be 2*WORD + 1... that should work too right? I would not need any > > masking in that case. > > I see. Yes, that would work. But it would either double the memory usage, > or > require some management of this additional byte (e.g. in a separate, > parallel > byte heap), which complicates things a lot more than it benefits. > > ☺/ A!ex > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: MiniPicolisp Questions
Hi Kashyap, > About the the CELL having an additional byte, I meant that the CELL size > would be 2*WORD + 1... that should work too right? I would not need any > masking in that case. I see. Yes, that would work. But it would either double the memory usage, or require some management of this additional byte (e.g. in a separate, parallel byte heap), which complicates things a lot more than it benefits. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
PilCon 2020
Hi all, yesterday the Oktoberfest, the largest annual event in Bavaria, was canceled. I think we will also have to cancel the other large event, PilCon. It is not sure whether such events will be allowed legally by end of July, and how the international travel situation will be. I hope this is OK for everybody. Would it make sense to plan an online conference instead? We are playing around with Jitsi Meet currently. Any thoughts? ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: MiniPicolisp Questions
Thanks Alex, Yup, I can see what's going on now about RAM vs ROM :) About the the CELL having an additional byte, I meant that the CELL size would be 2*WORD + 1... that should work too right? I would not need any masking in that case. Regards, Kashyap On Mon, Apr 20, 2020 at 11:06 PM Alexander Burger wrote: > Hi Kashyap, > > > 1. About RAM vs ROM. Call me lazy but I would really appreciate a > > description of how the RAM vs ROM decision is taken here (and in general > > too..I mean, it is not clear to me how gen3m.c determines how something > is > > never written to or not) > > if (x > 0) > >Rom[x] = strdup(buf); > > else > >Ram[-x] = strdup(buf); > > The sign of 'x' is determined when reading the symbol, in the functions > romSym() > and ramSym(). > > You can see where something gets stored to by whether RomIx or RamIx is > used. > Cell data all go to ROM, most symbol value cells to RAM (except some > constants > like NIL or T). This allows also symbols in ROM to be redefined at runtime. > > > > 2. Can I try and make the CELL have an additional byte to store the TYPE > > and get rid using tagged pointers? Clearly, it would be less efficient at > > runtime but perhaps it would be more easy to understand. Is there any > > reason that this would not work? > > No, this would work. You could use the most significant byte, but have to > mask > it when using the pointer (and live with the decreased address space size > ;) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: picoLisp 19.12: variable length array in structure fixes
Interesting. You might have also run into no "excution bits" on Intel hardware: https://releases.llvm.org/8.0.1/docs/SpeculativeLoadHardening.html https://en.wikipedia.org/wiki/NX_bit In Lisp, "code is data, data is code". There simply is no separation the like - "code here, data there". Typical Lisp JIT emits machine code, where needed. This is a common and well known problem. Unsure, if you can disable that behavior in Apple BIOS. And even then you must recompile with options. US hardware and software stacks increasingly become nebulous. Have fun, Guido Stepken Am Dienstag, 21. April 2020 schrieb 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()
Re: picoLisp 19.12: variable length array in structure fixes
> 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 > Indeed! I always forget this requirement on Openbsd. $ ulimit -s 32000 and it passed malloc guards. Thanks. (mike) -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Replace LLVW - Was: Stop using US controlled software stacks!!!
Hi Guido, I am very interested to hear about your ASIC Lispm, how can we avail once its out? Can you please share more details? Actually I am also trying to get back from what we have started using FPGA but time is always not on my side these days, but will see.. I really hope to hear from you back, thanks. BR, Geo On Tue, Apr 21, 2020 at 5:37 PM Guido Stepken wrote: > Hi Alex! > > Webassembly already is ported to almost all architectures, where browsers > are available. All those Webassembly containers in those browsers takes > Binary Lisp code and do translate it to native machine code. > > If you would please have a look at that giant list of programming > languages, that transpile to that "Binary Lisp" for being executed in > Webassembly browser containers. > > https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md > > There are couple of server side Webassembly containers out there, that do > either interpret Webassembly Binary Lisp code or can JIT that. > > Means: Your PicoLisp .l code could *directly* run in any browser and on > any hardware in such a Webassembly container. All you need to do is to > tokenize your PicoLisp code. That's one day of work. > > I still haven't the slightest idea, what you are doing there with pil21 > and LLVM. Don't use buggy, backdoored US software stacks, such as LLVM, > GCC, VC++ or JVM any longer! > > We simply *don't need* them!!! > > Webassemby, by JITing Binary Lisp code to machine code already has > everything in it! It's kind of universal AST to machine code compiler, > where the AST only is represented in Binary Lisp form. > > I've recently completed my ASIC Lisp machine, just waiting for the board > designers to get finished. No CPU of any kind neccessary any longer. > PicoLisp .l code then also could directly run on that ASIC. And much > faster, than you can imagine! ;-) > > Best regards, Guido Stepken > > > > > Am Dienstag, 21. April 2020 schrieb Alexander Burger >: > > Hi Guido, > > > > On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote: > >> But this is not the point. The point is, that MetaCola was a code > >> generator, where you can implement whole programming languages within > just > >> a few lines of code. > >> .. > >> OMeta Parser/Interpreter has been translated into many programming > >> languages and is used almost everywhere now to implement DSL (Domain > >> Specific Languages). > >> ... > >> 153 Lines of OMeta code: > >> ... > >> I almost completely stopped writing code in any programming language by > >> hand, since there is not a single problem that cannot be solved with > OMeta > > > > Wonderful! That saves all our problems. No reason to stop pil21 :) > > > > LLVM is only needed to translate the IR code, generated from PicoLisp > pil21 > > sources, to the target machine language. > > > > You can surely write for us such a translator in 160 lines. For now, > targets > > x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would > be > > enough. > > > > Issue closed! :) > > > > ☺/ A!ex > > > > -- > > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > > > >
Re: picoLisp 19.12: variable length array in structure fixes
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
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
Re: Replace LLVW - Was: Stop using US controlled software stacks!!!
Hi Alex! Webassembly already is ported to almost all architectures, where browsers are available. All those Webassembly containers in those browsers takes Binary Lisp code and do translate it to native machine code. If you would please have a look at that giant list of programming languages, that transpile to that "Binary Lisp" for being executed in Webassembly browser containers. https://github.com/appcypher/awesome-wasm-langs/blob/master/README.md There are couple of server side Webassembly containers out there, that do either interpret Webassembly Binary Lisp code or can JIT that. Means: Your PicoLisp .l code could *directly* run in any browser and on any hardware in such a Webassembly container. All you need to do is to tokenize your PicoLisp code. That's one day of work. I still haven't the slightest idea, what you are doing there with pil21 and LLVM. Don't use buggy, backdoored US software stacks, such as LLVM, GCC, VC++ or JVM any longer! We simply *don't need* them!!! Webassemby, by JITing Binary Lisp code to machine code already has everything in it! It's kind of universal AST to machine code compiler, where the AST only is represented in Binary Lisp form. I've recently completed my ASIC Lisp machine, just waiting for the board designers to get finished. No CPU of any kind neccessary any longer. PicoLisp .l code then also could directly run on that ASIC. And much faster, than you can imagine! ;-) Best regards, Guido Stepken Am Dienstag, 21. April 2020 schrieb Alexander Burger : > Hi Guido, > > On Sun, Apr 19, 2020 at 06:41:31PM +0200, Guido Stepken wrote: >> But this is not the point. The point is, that MetaCola was a code >> generator, where you can implement whole programming languages within just >> a few lines of code. >> ... >> OMeta Parser/Interpreter has been translated into many programming >> languages and is used almost everywhere now to implement DSL (Domain >> Specific Languages). >> ... >> 153 Lines of OMeta code: >> ... >> I almost completely stopped writing code in any programming language by >> hand, since there is not a single problem that cannot be solved with OMeta > > Wonderful! That saves all our problems. No reason to stop pil21 :) > > LLVM is only needed to translate the IR code, generated from PicoLisp pil21 > sources, to the target machine language. > > You can surely write for us such a translator in 160 lines. For now, targets > x86-64, arm64, RISC-V and Verilog on Linux, Android, MacOS and iOS would be > enough. > > Issue closed! :) > > ☺/ A!ex > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: MiniPicolisp Questions
Hi Kashyap! Dividing up Lisp Cells (Atoms) in RAM/ROM - i think, you're referring to this: https://picolisp.com/wiki/-A265.html has recently got another aspect: https://en.wikipedia.org/wiki/Remote_direct_memory_access RDMA, Remote Direct Memory Access. With Picolisp and especially miniPicoLisp you can build one (logically) giant Lisp machine across hundreds of servers. I'm using that since a couple of weeks now using some Nokia 400 GbE cards and i must say: It works pretty well! ;-) Distributed in memory database, partly with persistance, Graph, PILOG on top ... It's the simlicity in PicoLisp that allows to do unbelievable things. As i've already said: PicoLisp is a *genius strike*. You can easily do things, that only would be available if you would use those multi million line US software stacks, with all their bugs, NSA backdoors, whatever. Have fun! Best, Guido Stepken Am Dienstag, 21. April 2020 schrieb C K Kashyap : > Hi Alex et al, > I've been working on miniPicoLisp source with the idea of making it more easy to understand - granted, it's really simple but it's simplicity may not be apparent from looking at the source to some (such as myself). For instance, it took me some time to get what's going on with the optimized string storage. So, one of the changes I did was to switch to 7 bits for all. So I am trying to alter the code to make it easy for guys like me :) > I have a couple of questions > 1. About RAM vs ROM Call me lazy but I would really appreciate a description of how the RAM vs ROM decision is taken here (and in general too..I mean, it is not clear to me how gen3m.c determines how something is never written to or not) > if (x > 0) >Rom[x] = strdup(buf); > else >Ram[-x] = strdup(buf); > > 2. Can I try and make the CELL have an additional byte to store the TYPE and get rid using tagged pointers? Clearly, it would be less efficient at runtime but perhaps it would be more easy to understand. Is there any reason that this would not work? > Regards, > Kashyap
Re: MiniPicolisp Questions
Hi Kashyap, > 1. About RAM vs ROM. Call me lazy but I would really appreciate a > description of how the RAM vs ROM decision is taken here (and in general > too..I mean, it is not clear to me how gen3m.c determines how something is > never written to or not) > if (x > 0) >Rom[x] = strdup(buf); > else >Ram[-x] = strdup(buf); The sign of 'x' is determined when reading the symbol, in the functions romSym() and ramSym(). You can see where something gets stored to by whether RomIx or RamIx is used. Cell data all go to ROM, most symbol value cells to RAM (except some constants like NIL or T). This allows also symbols in ROM to be redefined at runtime. > 2. Can I try and make the CELL have an additional byte to store the TYPE > and get rid using tagged pointers? Clearly, it would be less efficient at > runtime but perhaps it would be more easy to understand. Is there any > reason that this would not work? No, this would work. You could use the most significant byte, but have to mask it when using the pointer (and live with the decreased address space size ;) ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
