--
Keenan Paul Lynch
Software Craftsmen - {.NET, Web}
*[image: Image result for coding]*
Controlling complexity is the essence of computer programming.
On Sun, Apr 12, 2020 at 06:25:11PM +0200, Alexander Shendi (Web.DE) wrote:
> 1. Yes, Makefile and lib.c as included in pil21/src.
> ...
> The problem is that I can't regenerate the bitcode files from the Lisp files.
> Otherwise the executable seems to work fine.
Good to know.
Concerning the
Hi all
1. Yes, Makefile and lib.c as included in pil21/src.
2. No, I built pil21/bin/picolisp directly. The two bitcode files base.bc and
ext.bc were already included and I was able to build lib.bc from the modified
lib.c (with the clang C compiler).
After that I just typed: touch *.bc ; make.
thank you!
On Sun, Apr 12, 2020 at 2:01 AM Mike wrote:
> > I'm studying lib/sumul.l, specifically the 'grid function.
>
> In my repo you would find a lot of usage examples for grid:
> https://git.envs.net/mpech/tankf33der/
>
> (mike)
>
> --
> UNSUBSCRIBE:
Hi Alexander,
> Sorry to follow up on my own post, but with some hacking at lib.c and changing
> the Makefile I was able to bootstrap a working picolisp binary.
The lib.c and Makefile in pil21/src/? So it worked with emu?
> However I can't seem to be able to regenerate the *.bc files from the
Hi again,
Sorry to follow up on my own post, but with some hacking at lib.c and changing
the Makefile I was able to bootstrap a working picolisp binary.
However I can't seem to be able to regenerate the *.bc files from the Lisp
files. Two questions:
1. would anyone be interested in the
Hi Alexander,
> I have tried building pil21 under NetBSD 9/aarch64. I tried to use
> Ersatz-picolisp under OpenJDK8 to generate the *.ll files to bootstrap pil21,
> but it seems some language constructs used in llvm.l are not supported.
Unfortunately, neither Ersatz, nor pil32 or miniPicoLisp
Dear Lisp,
Happy Easter!
I have tried building pil21 under NetBSD 9/aarch64. I tried to use
Ersatz-picolisp under OpenJDK8 to generate the *.ll files to bootstrap pil21,
but it seems some language constructs used in llvm.l are not supported.
What is the best way to work around thus? TIA.
Am Sonntag, 12. April 2020 schrieb Alexander Burger :
> Hi Guido,
>
>> All you need to do, is to let PicoLisp Interpreter convert PicoLisp
Source
>> into that Lisp dialect, Webassembly VM does understand, and you're done!
>
> OK, if it is so easy, why don't you do it?
I've hoped, you would have
Hi Guido,
> All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source
> into that Lisp dialect, Webassembly VM does understand, and you're done!
OK, if it is so easy, why don't you do it?
Still it doesn't solve the portability issue. I want PicoLisp to run also in iOS
(also
Like that WISP example. Indendation here replaces "("
https://wiki.gnome.org/Projects/Genie#Block_Indentation
Same for Python.
Means: Lisp code generally can be stripped off most brackets without losing
"meaning". And it should. For readabilty reasons, public acceptance - and
typing speed: With
Hi Alex!
Maybe, i am repeating myself. But Webassembly containers use LLVM already.
https://github.com/WAVM/WAVM/blob/master/README.md
All you need to do, is to let PicoLisp Interpreter convert PicoLisp Source
into that Lisp dialect, Webassembly VM does understand, and you're done!
Greetings
Hi Alex!
You might perhaps have noticed, that modern CPUs execute "unoptimized"
compiler code almost as fast as code produced by highly optimizing
compilers (-Os vs. -O3). Difference is almost zero!
You also might have noticed, that AMD with EPYC Rome and Threadripper are
far ahead of Intel in
On Sun, Apr 12, 2020 at 10:36:58AM +0200, Guido Stepken wrote:
> Why porting Picolisp onto LLVM, when there already is a JIT compiler in
> every Webassembly container, that accepts Lisp code?
The answer is "portability"
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Quoting Guido Stepken :
Hi all!
Parenthesis sometimes unneccessarily seem to keep people away from Lisp as
"all day programming language". It's confusing their brain.
How about this "innovative" new Lisp syntax?
https://github.com/birchb1024/genyris/blob/master/examples/queens.g
It's the
Happy Easter, Alex!
Nothing brings me to waste just a second on LLVM compiler suite. And i
directly will tell you why:
https://bellard.org/otcc/
OTCC is a C compiler implemented in 2048 bytes of code. It can compile
itself and translates to 386 machine code. Fully 'Turing complete'! Its
Hello Domingo Alvarez Duarte :-)
You are now subscribed
Hello !
Happy to join !
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Happy Easter, Rowan!
Unlike (Pico-)Lisp, where operator comes first "> (+ 2 3)" Forth is
*Reverse Polish notation*, so (2) values are pushed onto a stack and
operator (+) comes last "> 3 2 +". That's von Neumann friendly in so far,
as CPU also has to load values first and then calls the add()
On Sun, Apr 12, 2020 at 08:09:46AM +0200, Tomas Hlavaty wrote:
> Rowan Thorpe writes:
> > parentheses are not used because as is stated at
> > https://picolisp.com/wiki/?src64 "Assembly language is not a
> > functional language, i.e. the individual instructions do not "return"
> > a value. So a
Me too, love the podcast, thanks for sharing!!
Happy Easter everyone!!
BR,
Geo
On Sunday, 12 April 2020, 01:49:21 pm GMT+9, C K Kashyap
wrote:
Thanks for sharing ... loved the podcast!
Regards,
Kashyap
On Fri, Apr 10, 2020 at 2:28 PM Guido Stepken wrote:
> A highly inspiring,
> I'm studying lib/sumul.l, specifically the 'grid function.
In my repo you would find a lot of usage examples for grid:
https://git.envs.net/mpech/tankf33der/
(mike)
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Hi Rowan,
> By the way what I love most about Picolisp is that it feels like as
> good a hybrid as you can get between the "typical functional
> lisp/scheme" mental model and something that feels "forth-like" in
> terms of minimalism/precision/close-to-the-metal von-neumann
>
Hi Bruno,
> I'm studying lib/sumul.l, specifically the 'grid function. I understand how
> it works now, but I have two doubts:
>
> 1) why are symbols in the grid interned?
> ...
>(if (> DX 26)
> (box)
>
Rowan Thorpe writes:
> parentheses are not used because as is stated at
> https://picolisp.com/wiki/?src64 "Assembly language is not a
> functional language, i.e. the individual instructions do not "return"
> a value. So a fully parenthesized syntax is useless and just tedious."
because picolisp
24 matches
Mail list logo