Re: "macros" in miniPicoLisp

[C K Kashyap]

Thanks Alex!

On Sat, Mar 2, 2024 at 1:02 PM Alexander Burger 
wrote:

> On Sat, Mar 02, 2024 at 10:05:00AM -0800, C K Kashyap wrote:
> > Another installment of the video -
> > https://www.youtube.com/watch?v=O52fRAsr7Vg
>
> Very nice indeed! This is probably the first time PiccLisp does something
> non~triwial on Windows.
>
> Tharks for sharing!
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: "macros" in miniPicoLisp

[C K Kashyap]

Another installment of the video -
https://www.youtube.com/watch?v=O52fRAsr7Vg
I think my over 15 years of pursuit of finding the perfect programming
language is complete :) - The sad thing is that I had discovered PicoLisp
long ago but had discarded it because it was "just an interpreter" :)
I am finally free to explore my actual ideas now!
Regards,
Kashyap

On Fri, Feb 9, 2024 at 2:28 PM C K Kashyap  wrote:

> Super! - thank Alex.
>
> On Fri, Feb 9, 2024 at 11:17 AM Alexander Burger 
> wrote:
>
>> Hi Kashyap,
>>
>> > Does this look like a reasonable way to create the "create-adder"
>> function?
>> >
>> > (de create-adder Args
>> >(let
>> >   (N (car Args)
>> >  Adder (intern (pack "add-" N))
>> >  P
>> >  (list
>> > 'de
>> > Adder
>> > '(X)
>> > (list '+ N 'X) ) )
>> >   (eval P) ) )
>> >
>> > : (create-adder 10)
>> > -> add-10
>> > : (add-10 20)
>> > -> 30
>>
>> Yes, but you can do it a little simpler by directly calling 'def':
>>
>>(de create-adder (N)
>>   (def (intern (pack "add-" N))
>>  (list '(X) (list '+ N 'X)) ) )
>>
>> Note also that I use (N), i.e. an evaluated argument, as this makes the
>> function
>> more general.
>>
>>
>> Even simpler if you use 'curry':
>>
>>(de create-adder (@N)
>>   (def (intern (pack "add-" @N))
>>  (curry (@N) (X)
>> (+ @N X) ) ) )
>>
>> It is especially simpler if the function body, which is here just (+ N
>> X), is
>> more complicated, because then the 'list'ing and 'cons'ing of the body
>> would
>> become very unreadable.
>>
>>
>> > If I understand correctly, the "macro" capability of miniPicoLisp is
>> not at
>> > par with PicoLisp right?
>>
>> The 'macro' function of mini and normal PicoLisp is the same I think.
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: "macros" in miniPicoLisp

[C K Kashyap]

Super! - thank Alex.

On Fri, Feb 9, 2024 at 11:17 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > Does this look like a reasonable way to create the "create-adder"
> function?
> >
> > (de create-adder Args
> >(let
> >   (N (car Args)
> >  Adder (intern (pack "add-" N))
> >  P
> >  (list
> > 'de
> > Adder
> > '(X)
> > (list '+ N 'X) ) )
> >   (eval P) ) )
> >
> > : (create-adder 10)
> > -> add-10
> > : (add-10 20)
> > -> 30
>
> Yes, but you can do it a little simpler by directly calling 'def':
>
>(de create-adder (N)
>   (def (intern (pack "add-" N))
>  (list '(X) (list '+ N 'X)) ) )
>
> Note also that I use (N), i.e. an evaluated argument, as this makes the
> function
> more general.
>
>
> Even simpler if you use 'curry':
>
>(de create-adder (@N)
>   (def (intern (pack "add-" @N))
>  (curry (@N) (X)
> (+ @N X) ) ) )
>
> It is especially simpler if the function body, which is here just (+ N X),
> is
> more complicated, because then the 'list'ing and 'cons'ing of the body
> would
> become very unreadable.
>
>
> > If I understand correctly, the "macro" capability of miniPicoLisp is not
> at
> > par with PicoLisp right?
>
> The 'macro' function of mini and normal PicoLisp is the same I think.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

"macros" in miniPicoLisp

[C K Kashyap]

Hi Alex,

Does this look like a reasonable way to create the "create-adder" function?

(de create-adder Args
   (let
  (N (car Args)
 Adder (intern (pack "add-" N))
 P
 (list
'de
Adder
'(X)
(list '+ N 'X) ) )
  (eval P) ) )

: (create-adder 10)
-> add-10
: (add-10 20)
-> 30

If I understand correctly, the "macro" capability of miniPicoLisp is not at
par with PicoLisp right?

Regards,
Kashyap

Re: miniPicoLisp + libuv +libSDL

[C K Kashyap]

Thanks Alex and RCS :)

On Thu, Feb 1, 2024 at 10:40 AM Alexander Burger 
wrote:

> On Thu, Feb 01, 2024 at 09:05:17AM -0800, C K Kashyap wrote:
> > I finally got around to recording a video (my video recording muscles
> have
> > atrophied :)  )
> >
> > https://www.youtube.com/watch?v=Uv0ZiZAfcGc
>
> Wow, that's cool! Now I see what your intentions are!
>
> Thanks!
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: miniPicoLisp + libuv +libSDL

[C K Kashyap]

I finally got around to recording a video (my video recording muscles have
atrophied :)  )

https://www.youtube.com/watch?v=Uv0ZiZAfcGc

Regards,
Kashyap

On Fri, Jan 26, 2024 at 8:06 AM C K Kashyap  wrote:

> Thanks Alex - I'll take the "very good" for now :)
>
> I think I found a better example for demo - libuv's file change callback
> ... I'll do a demo using that -> make changes to a picolisp script and the
> screen gets updated as I save the script :)
>
> Regards,
> Kashyap
>
> On Fri, Jan 26, 2024 at 7:48 AM Alexander Burger 
> wrote:
>
>> Hi Kashyap,
>>
>> > ping Alex :)
>>
>> Yes, very good! There is just not much I can say here :)
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: minipicolisp with big num

[C K Kashyap]

:) ... thanks Alex!

On Fri, Jan 26, 2024 at 10:37 AM Alexander Burger 
wrote:

> Hi Kashyap, Mike,
>
> > Hey Mike ... I am actually asking if there is such a port/variation of
> > miniPicoLisp that has big num support - just like the regular picoLisp.
>
> I have never heard of any such version. In fact, I believe that at the
> moment
> you are the de-facto specialist of miniPicoLisp.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: minipicolisp with big num

[C K Kashyap]

Hey Mike ... I am actually asking if there is such a port/variation of
miniPicoLisp that has big num support - just like the regular picoLisp.

Regards,
Kashyap

On Fri, Jan 26, 2024 at 9:14 AM Mike  wrote:

>
>
> > On Jan 26, 2024, at 18:19, C K Kashyap  wrote:
> >
> > 
> > Hey all,
> > Has anyone tried a port of miniPicoLisp with the added big num support?
>
> How did you test it?
>
> (mike)
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: docker for pil21

[C K Kashyap]

Nice - I did not know about the --no-cache option :)

On Fri, Jan 26, 2024 at 8:09 AM Dmitry Non  wrote:

> Heya!
> Interestingly, I wrote a dockerfile for myself too at the end of Dec.My
> versions should be lighter due to the lack of build dependencies in the
> final image:
>
> FROM alpine:3.19 AS build
>
> RUN apk add --no-cache readline-dev libffi-dev libressl-dev binutils make
> clang llvm llvm-dev pkgconf
> RUN sh -c ' \
> wget https://software-lab.de/picoLisp-23.12.tgz; \
> tar xfz picoLisp-23.12.tgz; \
> cd pil21/src; \
> make \
> '
>
> FROM alpine:3.19
> RUN apk add --no-cache readline-dev libffi-dev libressl-dev
> COPY --from=build /pil21 /usr/lib/picolisp
>
> # RUN ln -s /pil21 /usr/lib/picolisp
> RUN ln -s /usr/lib/picolisp/bin/picolisp /usr/bin
> RUN ln -s /usr/lib/picolisp/bin/pil /usr/bin
>
> ENTRYPOINT ["pil"]
>
> It's availalbe at https://hub.docker.com/r/dmitrynon/picolisp
> but I didn't intend it for public consumption so you're better off using
> your own dockerfile with some additions from mine
>
> On 24 Jan 2024, at 18:47, picolisp@software-lab.de wrote:
>
> hi all,
>
> I have created a docker file for pil21 you can play with.
> Comments are welcome.
>
> https://git.envs.net/mpech/pil21-docker
>
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>
>

minipicolisp with big num

[C K Kashyap]

Hey all,
Has anyone tried a port of miniPicoLisp with the added big num support?
Regards,
Kashyap

Re: miniPicoLisp + libuv +libSDL

[C K Kashyap]

Thanks Alex - I'll take the "very good" for now :)

I think I found a better example for demo - libuv's file change callback
.. I'll do a demo using that -> make changes to a picolisp script and the
screen gets updated as I save the script :)

Regards,
Kashyap

On Fri, Jan 26, 2024 at 7:48 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > ping Alex :)
>
> Yes, very good! There is just not much I can say here :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: miniPicoLisp + libuv +libSDL

[C K Kashyap]

ping Alex :)

On Wed, Jan 24, 2024 at 7:58 AM C K Kashyap  wrote:

> Hi Alex et al,
> For quite some time now (years), I've been attempting to have a
> miniPicoLisp + libSDL + libUV working (on Windows as well) for a while and
> I have finally got it working :) ... Much of my time was wasted attempting
> "3 part cell" etc.
>
> I thought that I'd record a video of the demo before sharing but I am
> becoming impatient now :). I have the working version here -
> https://github.com/lispware/minilisp/tree/libuv2
> To see the demo, simply execute server.l (which listens on port 8080 for
> the mouse click locations and returns an RGB color). Then execute client.l
> - this opens an SDL window and sends the mouse click location to port 8080
> and draws a square on the window with the color returned from the server.
> [Please take a look at the Docker file to see the dependencies that are
> needed]
>
> I think I need to work on modelling the callbacks better. It would be
> great if I could have some pointers on how to do it better/right. For
> example, I modelled uv_tcp_listen here -
> https://github.com/lispware/minilisp/blob/2c4581d2288eafd4b5f65b88e37411e22993fc5a/src/lisp_sdl_libuv.c#L573
>  I
> execute the callback from the C callback "on_connection
> <https://github.com/lispware/minilisp/blob/2c4581d2288eafd4b5f65b88e37411e22993fc5a/src/lisp_sdl_libuv.c#L533>
> "
>
> Regards,
> Kashyap
>

Re: docker for pil21

[C K Kashyap]

Nice,
Here's some additions to make the image a little lighter (not including the
*-dev packages) and also adding the appropriate soft links as indicated in
the INSTALL file

FROM alpine:latest as builder

RUN apk update && apk upgrade
RUN apk add bash git make llvm clang readline libffi openssl
RUN apk add llvm-dev readline-dev libffi-dev openssl-dev
WORKDIR /root
RUN git clone https://github.com/picolisp/pil21
WORKDIR /root/pil21/src
RUN touch *.ll
RUN make

FROM alpine:latest
RUN apk add bash git make llvm clang readline libffi openssl vim
COPY --from=builder /root/pil21 /root/pil21
RUN ln -s /root/pil21 /usr/lib/picolisp
RUN ln -s /usr/lib/picolisp/bin/picolisp /usr/bin
RUN ln -s /usr/lib/picolisp/bin/pil /usr/bin
RUN mkdir -p /usr/share/man/man1
RUN mkdir -p /usr/share/bash-completion/completions
RUN ln -s /root/pil21/man/man1/picolisp.1 /usr/share/man/man1
RUN ln -s /root/pil21/man/man1/pil.1 /usr/share/man/man1
RUN ln -s /root/pil21 /usr/share/picolisp
RUN ln -s /root/pil21/lib/bash_completion
/usr/share/bash-completion/completions/pil

On Wed, Jan 24, 2024 at 10:59 AM  wrote:

> hi all,
>
> I have created a docker file for pil21 you can play with.
> Comments are welcome.
>
> https://git.envs.net/mpech/pil21-docker
>
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

miniPicoLisp + libuv +libSDL

[C K Kashyap]

Hi Alex et al,
For quite some time now (years), I've been attempting to have a
miniPicoLisp + libSDL + libUV working (on Windows as well) for a while and
I have finally got it working :) ... Much of my time was wasted attempting
"3 part cell" etc.

I thought that I'd record a video of the demo before sharing but I am
becoming impatient now :). I have the working version here -
https://github.com/lispware/minilisp/tree/libuv2
To see the demo, simply execute server.l (which listens on port 8080 for
the mouse click locations and returns an RGB color). Then execute client.l
- this opens an SDL window and sends the mouse click location to port 8080
and draws a square on the window with the color returned from the server.
[Please take a look at the Docker file to see the dependencies that are
needed]

I think I need to work on modelling the callbacks better. It would be great
if I could have some pointers on how to do it better/right. For example, I
modelled uv_tcp_listen here -
https://github.com/lispware/minilisp/blob/2c4581d2288eafd4b5f65b88e37411e22993fc5a/src/lisp_sdl_libuv.c#L573
I
execute the callback from the C callback "on_connection

"

Regards,
Kashyap

Re: External allocations using miniPicoLisp

[C K Kashyap]

Thanks Alex,

The penny just dropped for me as I was writing this mail - yup, I remember
now :)
I think "finally" will do what I need :)

Regards,
Kashyap


On Sat, Dec 2, 2023 at 11:35 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > Is there a reference implementation of external allocation using
> > miniPicoLisp?
> >
> > Here's what I'd like to do - Create a new function called "alloc" that
> > allocates some memory.
> >
> > (let A (alloc 100)
> >   (poke A 0 10)) # poke simply writes a byte(10) at offset 0
>
> I do not know if anybody has done this in miniPicoLisp, but the official
> PicoLisp has functions 'buf' and 'byte' which behave that way:
>
>(buf A 100  # Allocate on the stack
>   (byte A 10)
>   (byte (+ A 7) 11)
>   ... )
>
> 'buf' allocates memory on the runtime stack, and cleans it up when done.
>
>
> You can also explicitly allocate system memory to get the same effect, but
> this
> has more overhead:
>
>(let A (%@ "malloc" 'P 100)  # Allocate memory
>   (byte A 10)
>   ...
>   (%@ "free" NIL A) )  # Clean up
>
>
> > The part I want to ensure is that the memory that's allocated by alloc
> gets
> > collected by the GC.
>
> This does not make sense. The garbage collector traverses the 'heap'
> structures,
> managing used and unused cells (as discussed in our last mail). Memory
> allocated
> by 'buf' or malloc() does not contain cells reachable from Lisp data
> structures,
> and is therfore not known by the garbage collector. And as it is not part
> of the
> linked list of 'heap's, it will not be free'd.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

External allocations using miniPicoLisp

[C K Kashyap]

Hi Alex et al,

Is there a reference implementation of external allocation using
miniPicoLisp?

Here's what I'd like to do - Create a new function called "alloc" that
allocates some memory.

(let A (alloc 100)
  (poke A 0 10)) # poke simply writes a byte(10) at offset 0

The part I want to ensure is that the memory that's allocated by alloc gets
collected by the GC.

Regards,
Kashyap

Re: possible bug in miniPicoLisp?

[C K Kashyap]

Got it.

Thanks Alex.

Regards,
Kashyap


On Wed, Nov 29, 2023 at 9:57 PM Alexander Burger 
wrote:

> On Wed, Nov 29, 2023 at 08:08:33PM -0800, C K Kashyap wrote:
> > Thanks Alex - half a dozen worked in my example :)
>
> Great :)
>
> > I completely get the idea of the inefficiency of CELLS=1 - the segfault
>
> OK
>
> > however seems like a silent bug (more likely some optimistic avoidance
> of a
> > NULL check somewhere perhaps). What do you think?
>
> Yes, it is definitely a bug if YOU set the heap to a bad size. As long as
> it is
> big enough, a runtime check is meaningless and will never fire.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: possible bug in miniPicoLisp?

[C K Kashyap]

Thanks Alex - half a dozen worked in my example :)

I completely get the idea of the inefficiency of CELLS=1 - the segfault
however seems like a silent bug (more likely some optimistic avoidance of a
NULL check somewhere perhaps). What do you think?

I say this because, even with CELLS=1, most of the stuff just works
(meaning no segfault - granted, highly inefficient)
If sample.l is the following - no problem
(de test (Pat . Prg)
   (bind (fish pat? Pat)
  (unless (match Pat (run Prg 1))
 (msg Prg)
 (quit 'fail Pat) ) ) )

(test '(B) (find pair (1 A 2 (B) 3 CDE)))
(test 4 (find > (1 2 3 4 5 6) (6 5 4 3 2 1)))
(test 4 (find '((A B) (> A B)) (1 2 3 4 5 6) (6 5 4 3 2 1)))
(let (A -1  B 2  C 3)
   (test 'B (find '((X) (gt0 (val X))) '(A B C)))
   (test 2 @@) )
# (test "h"
#(pick '((X) (get X 'str))
#   (list (box) (prog1 (box) (put @ 'str "Hello")) (box)) ) )


Regards,
Kashyap

On Tue, Nov 28, 2023 at 10:51 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I attempted to use 1 as the CELLS value in pico.h and immediately ran
> into
> > segfault
>
> Yes, this is not a good idea ;)
>
> CELLS is the number of cells per heap
>
>typedef struct heap {
>   cell cells[CELLS];
>   struct heap *next;
>} heap;
>
> and PicoLisp allocates as many heaps as needed.
>
> Setting it to 1 creates a huge overhead, because then you'll have one
> 'next'
> link for every cell.
>
> The cells in the heaps are maintained to hold internal linked lists for the
> unused cells. Probably this will not work if CELLS is 1.
>
>
> > Why am I trying CELLS = 1? Just poking around - I was just trying to
> figure
> > out the min number of CELLS I needed for certain programs.
>
> You can get the number of cells in a function with 'size':
>
>: (size '(a b c))
>-> 3
>
>: (pp 'test)
>(de test ("Pat" . "Prg")
>   (bind (fish pat? "Pat")
>  (unless (match "Pat" (run "Prg"))
> (msg "Prg")
> (quit "'test' failed" "Pat") ) ) )
>-> test
>
>: (size test)
>-> 23
>
> Even a minimal system needs a few thousand cells.
>
> Setting CELLS to just a few dozens would work, but the overhead of
> maintaining
> so many heaps will become relatively large.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

possible bug in miniPicoLisp?

[C K Kashyap]

Hi Alex,
I attempted to use 1 as the CELLS value in pico.h and immediately ran into
segfault at mark(ApplyArgs); in gc.c. I got around the segfault by simply
doing this -

   if(ApplyArgs)mark(ApplyArgs);
   if(ApplyBody)mark(ApplyBody);

After that, most things work but I ran into another segfault while trying
to run this sample.l file

## sample.l
(de test (Pat . Prg)
   (bind (fish pat? Pat)
  (unless (match Pat (run Prg 1))
 (msg Prg)
 (quit 'fail Pat) ) ) )

(test "Hello"
   (pick '((X) (get X 'str))
  (list (box) (prog1 (box) (put @ 'str "Hello")) (box)) ) )

kashyap@DESKTOP-NICP8CC:~/s/miniPicoLisp/src$ ../bin/picolisp sample.l
Segmentation fault


I'd appreciate any pointers.

Why am I trying CELLS = 1? Just poking around - I was just trying to figure
out the min number of CELLS I needed for certain programs.

Regards,
Kashyap

Re: minipicolisp pointers

[C K Kashyap]

Thanks Tomas,

By "call", I mean the regular PicoLisp "call", which is used to call
external programs.

My link should take you to github - I tried the link on an incognito mode
browser and it does take me to the code.

On Sat, Oct 21, 2023 at 12:11 PM Tomas Hlavaty 
wrote:

> On Sat 21 Oct 2023 at 10:50, C K Kashyap  wrote:
> > Could I have some pointers on extending MiniPicoLisp to implement
> > "call" and external objects?
>
> not sure what do you mean by "call" and external objects
> but https://logand.com/sw/mplisp/files.html shows how to extend
> minipicolisp with ffi.
>
> > My attempt at external object is here -
> >
> https://github.com/ckkashyap/pl/blob/bcf834075358e21abd4c7ec4adf6862e76df4348/miniPicoLisp/09012023/miniPicoLisp/src/main.c#L764
>
> this does not show any code, does it require javascript?
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

minipicolisp pointers

[C K Kashyap]

Hi all,
Could I have some pointers on extending MiniPicoLisp to implement "call"
and external objects? My attempt at external object is here -
https://github.com/ckkashyap/pl/blob/bcf834075358e21abd4c7ec4adf6862e76df4348/miniPicoLisp/09012023/miniPicoLisp/src/main.c#L764
I am simply looking to avoid any known pitfalls in this area.
Regards,
Kashyap

Re: building pilos

[C K Kashyap]

>
>
>
> > (using UART for io using --serial stdio option in qemu). The drivers/rest
> > of the kernel infrastructure could then be crowd sourced :)
>
> Will you give it a try?
>

I think that I am close to doing it with miniPicoLisp :)



> You mean Pil64 and PilOS? (Beause pil21 has no assembly sources)
>
> The sources of Pil64 and PilOS *are* Lisp files. They are evaluated via
> 'load'
> in "src64/mkAsm.l". That's why I said in the last mail that a running
> PicoLisp
> is nneded to bootstrap the build.
>
>
I think I misunderstood. I'll get back to this later.

Regards,
Kashyap

>
>

Re: building pilos

[C K Kashyap]

How about something that runs on qemu using a bootloader like limine/grub?
It could be really vanilla without even the need for a keyboard driver
(using UART for io using --serial stdio option in qemu). The drivers/rest
of the kernel infrastructure could then be crowd sourced :)

Btw .. perhaps you have already answered this but, does it make sense to
have a different extension for the assembly files? Technically, I don't
believe that they are plicolisp sources right?

Regards,
Kashyap


On Thu, Oct 5, 2023 at 8:03 AM Alexander Burger 
wrote:

> On Thu, Oct 05, 2023 at 07:32:26AM -0700, C K Kashyap wrote:
> > Any chance that we could expect a pil21 based pilos?
>
> This would indeed be fascinating. Perhaps there is some LLVM backend to
> Verilog?
> But PilOS is a huge task, and needs lots of drivers etc. for some target
> hardware. I have no hope for the near future.
>
>
> > I had not been watching pil21 for a while - I looked at it now and I
> really
> > liked "lib.c" :)   If I understood right, then all the platform
> > dependencies are in there (atleast as far as the picolisp executable)
>
> Yes, this is correct. In that way it is possible to distribute the
> pre-built
> *.ll files, and a running PicoLisp is no longer needed to bootstrap the
> build.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: building pilos

[C K Kashyap]

Thanks Alex,
Any chance that we could expect a pil21 based pilos?

I had not been watching pil21 for a while - I looked at it now and I really
liked "lib.c" :)   If I understood right, then all the platform
dependencies are in there (atleast as far as the picolisp executable)


On Thu, Oct 5, 2023 at 2:09 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > It looks like pilos build may be broken :( I think it has dependency on
> > pil64.
>
> This may well be. PilOS is built by PicoLisp, and is a modified and
> partially
> scaled down version of Pil64.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: pilog on minipicolisp

[C K Kashyap]

Thanks Alex!

Once I included lib/pilog.l, the example friends.l at
https://picolisp-explored.com/learning-pilog-2-facts-rules-queries?source=more_series_bottom_blogs
worked!

I had to comment out the section below "# Basic Rules" though - even (be
repeat) simply causes a segfault.

Regards,
Kashyap

On Thu, Oct 5, 2023 at 2:03 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > It looks like the pilog support in minipicolisp is perhaps different from
> > picolisp. Am I missing something? The "diff" file does not really call
> out
> > anything.
>
> Hmm, I did not look at MiniPicoLisp for a long time ... ;)
>
> > kashyap@DESKTOP-NICP8CC:~/s/embeddedpicolisp/miniPicoLisp/src$ ../pil
> > :  (be age (Paul 19) )
> > !? (clause CL)
> > clause -- Undefined
>
> 'clause' is defined in "mini/lib/pilog.l". "mini/pil" however loads only
> "lib/misc.l". This would explain it.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

building pilos

[C K Kashyap]

Hey Alex,
It looks like pilos build may be broken :( I think it has dependency on
pil64.
I will take a look more later but it would be great if you could share the
updated instructions :)
Regards,
Kashyap

pilog on minipicolisp

[C K Kashyap]

Hey Alex et al,

It looks like the pilog support in minipicolisp is perhaps different from
picolisp. Am I missing something? The "diff" file does not really call out
anything.

kashyap@DESKTOP-NICP8CC:~/s/embeddedpicolisp/miniPicoLisp/src$ ../pil
:  (be age (Paul 19) )
!? (clause CL)
clause -- Undefined
? (bye)

Regards,
Kashyap

Re: Question about get/put REPL vs executing a file

[C K Kashyap]

Got it - I'll just use non-transient symbols like 'A instead :)

Thanks Alex!
Kashyap

On Sat, Sep 23, 2023 at 12:02 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > kashyap@CPC-ckk-S75640M:~$ cat a.l
> > (de add (N D)
> >(put 'STORE N D) )
> > (add "A" 10)
> > (add "B" 20)
> > (prinl (get 'STORE "A"))
> > (prinl (get 'STORE "B"))
> > kashyap@CPC-ckk-S75640M:~$ pil a.l
> > 10
> > 20
> > : (get 'STORE "A")
> > -> NIL
> > : version
> > -> 274406
> >
> > Shouldn't I get 10 as a result of (get 'STORE "A") from the REPL?
>
> No, because transient symbols like "A" and "B" have a file-local scope
> (just
> like symbols in the 'private' namespace).
>
> Property functions like 'put' and 'get' access the value by the symbol
> itself
> (using pointer equality, '=='), not by the name. So the "A" in
>
>(get 'STORE "A")
>
> in the REPL *after* the file is loaded is another symbol than the "A" in
> the
> file *while* it is loaded.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Question about get/put REPL vs executing a file

[C K Kashyap]

Hi Alex et al,
Following illustrates the inconsistent behaviour of get/put between file
and REPL.

kashyap@CPC-ckk-S75640M:~$ cat a.l
(de add (N D)
   (put 'STORE N D) )
(add "A" 10)
(add "B" 20)
(prinl (get 'STORE "A"))
(prinl (get 'STORE "B"))
kashyap@CPC-ckk-S75640M:~$ pil a.l
10
20
: (get 'STORE "A")
-> NIL
: version
-> 274406

Shouldn't I get 10 as a result of (get 'STORE "A") from the REPL?

Regards,
Kashyap

Re: Question about , in the tweet

[C K Kashyap]

Got it ... I had done a quick check last night to validate and I had the
wrong observation because "Language" was already set by the call with the
"," so it appeared to work without the comma :)

Regards,
Kashyap

On Thu, Jun 30, 2022 at 6:39 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I believe that the comma was not strictly necessary in this tweet
> > https://twitter.com/PicoLispREPL/status/1542382434066788352  - the one
> > before "Language". Is that correct?
>
> No, in fact it is very important. Without it, nothing gets translated, and
> all
> calls to 'f' always return the string "Language".
>
> The comma is a read macro:
>
>https://software-lab.de/doc/ref.html#macro-io
>
> It is normally used for collecting strings which are meant to be
> translated in
> an application. Any call to (locale Ctry Lang) will then translate all
> strings.
> In this twitter example only a single string "Language" was used though for
> brevity.
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Question about , in the tweet

[C K Kashyap]

Hey Alex,
I believe that the comma was not strictly necessary in this tweet
https://twitter.com/PicoLispREPL/status/1542382434066788352  - the one
before "Language". Is that correct?
Regards,
Kashyap

Re: PicoLisp REPL on Twitter

[C K Kashyap]

Very cool ... although the subject line made me think of something else :)
- you tweet a picolisp expression and it replies with the evaluation!!!

On Tue, Apr 19, 2022 at 6:25 AM pd  wrote:

> Nice!
>
> On Tue, Apr 19, 2022 at 7:36 AM Alexander Burger 
> wrote:
>
>> Hi all,
>>
>> I started a new Twitter account @picolispRepl
>>
>>https://twitter.com/picolispRepl
>>
>> >From time to time I will post tips and tricks as short code snippets.
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: An assembly question from the past

[C K Kashyap]

This may be of interest to you Henry - https://picolisp.com/wiki/?PilOS

On Wed, Mar 30, 2022 at 4:42 PM Henry Baker  wrote:

> I haven't been following this thread terribly closely, so I hope this
> question isn't off-base.
>
> Is there a version of picolisp that runs on 80386/80486/80586 'bare metal'
> (or at least 'bare VM') -- talking directly to a HW serial port and reading
> from a FAT file system?
>
> -Original Message-
> From:
> Sent: Mar 30, 2022 10:38 AM
> To:
> Subject: Re: An assembly question from the past
>
> On Wed, Mar 30, 2022 at 08:13:00AM -0700, C K Kashyap wrote:
> > Just to give some background - I've been working on the attempt to port
> > miniPicoLisp to windows (more like making vanilla C as the only
> > dependency).
>
> Good, but isn't miniPicoLisp plan vanilla C anyway? I think it uses only
> stdio
> library functions.
>
>
> > For the stack - I believe that Pil
> > successfully existed without coroutines for decades right :)
>
> Yes. Coroutines are very nice in some situations, but with more programming
> effort you can always implement a conventional solution instead.
>
> > Somehow llvm - even though it's "industry standard" now - I feel that it
> > imposes too much as a dependency - the very fact that it's written in c++
> > is a turn off for me :)
>
> I agree with both statements.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: An assembly question from the past

[C K Kashyap]

> Good, but isn't miniPicoLisp plan vanilla C anyway? I think it uses only
> stdio
> library functions.
>

Thanks :Alex :) ... almost Vanilla C I think - with some gcc toppings (VLA
particularly) ;) I also moved away from pointer tagging in favor of an
extra "part" in the cell. This takes away any alignment requirement as well

Re: An assembly question from the past

[C K Kashyap]

Thanks for the clear explanation Alex,
Just to give some background - I've been working on the attempt to port
miniPicoLisp to windows (more like making vanilla C as the only
dependency). I wanted to make sure that I understood the cost of not going
with assembly. Since I use https://github.com/libtom/libtommath for BigNum
I think I am okay on the flags front. For the stack - I believe that Pil
successfully existed without coroutines for decades right :) and I can see
how I could mimic coroutines in the "user space".
Somehow llvm - even though it's "industry standard" now - I feel that it
imposes too much as a dependency - the very fact that it's written in c++
is a turn off for me :)
Regards,
Kashyap

On Wed, Mar 30, 2022 at 12:13 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I can see how you would have to end up writing the whole thing in
> assembly
> > - in the example you shared. Would it be right to say that its only the
> > carry flag that you need or is it just an example and there are other
> flags
> > too?
>
> Pil64 used three flags (zero, sign and carry). CPUs usually have a lot more
> of them, e.g. overflow, but I decided to go without them.
>
> Some functions returned values in one or more registers, plus some flags.
> This
> is much more powerful than the single return value supported by C.
>
> > Can I say that the need is restricted to the use of BigNum?
>
> On the machine instruction level, the carry is used in a lot more
> situations,
> like comparisons or arithmetic shifts.
>
>
> > The ability to set/get the stack I presume needs to be compared with
> > setjmp/longjmp - correct? Is setjmp/longjmp insufficient or is it not
> > efficient enough?
>
> No, setjmp/longjmp is fine. Pil21 uses it too. But in some situations you
> need
> to set the stack pointer explicitly (e.g. when allocating coroutine stack
> areas)
> or read it (stack overflow checks).
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: An assembly question from the past

[C K Kashyap]

Thank you Alex,
I can see how you would have to end up writing the whole thing in assembly
- in the example you shared. Would it be right to say that its only the
carry flag that you need or is it just an example and there are other flags
too? Can I say that the need is restricted to the use of BigNum?

The ability to set/get the stack I presume needs to be compared with
setjmp/longjmp - correct? Is setjmp/longjmp insufficient or is it not
efficient enough?

Regards,
Kashyap


On Tue, Mar 29, 2022 at 12:31 PM Tomas Hlavaty  wrote:

> On Tue 29 Mar 2022 at 18:49, Alexander Burger  wrote:
> > As C does not allow access to the carry bit, you have to do ugly and
> inefficient
> > tricks, by looking at the most significant bit of the result and trying
> to
> > detect an overflow. For example, in bigAdd() in pil32's src/big.c:
> >
> >carry = (unDig(src) & ~1) > num(setDig(dst, (unDig(src) & ~1) +
> (unDig(dst) & ~1)));
> [...]
> > Concerning the stack, assembly code can handle the hardware stack
> pointer just
> > like any other register.
>
> interesting
>
> Did you consider GCC inline assembly?
> What were the reasons you did not use it?
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

An assembly question from the past

[C K Kashyap]

Hey Alex,

I had reached out to you about the need for assembly in the past and
you had mentioned the following -


> 'c' implementation of pil32?

>> Pil32 and miniPicoLisp are written in C, and C does not support calling 
>> other functions in a generic way. This is one of the reasons pil64 was 
>> written in assembly (in addition to stack control and CPU status bits).


Could you please throw some more light on the "stack control" and "CPU
status bits". I imagine that "CPU status bits" should be easy with
inline assembly right? (although potentially introducing a bunch of
#ifdef's for individual platform/compiler). I am not sure of the stack
control though.


Regards,

Kashyap

Re: 3 part cell miniPicoLisp

[C K Kashyap]

Hi all,
I've dropped the idea of libuv for now. I have however got unlimited string
back and also unlimited big num support (using libtommath
<https://www.libtom.net/LibTomMath/>)
Regards,
Kashyap

On Thu, Dec 31, 2020 at 11:52 AM C K Kashyap  wrote:

> Hi All,
> I had been exploring the miniPicoLisp source for several months now. My
> goal was to make it compile with Microsoft C compiler and Tiny C Compiler (
> TCC <https://download.savannah.gnu.org/releases/tinycc/>) on windows -
> and gain a deeper understanding of the implementation in the process. In
> order to compile using Microsoft C compiler, it was sufficient to remove
> the use of VLA(variable length array). However, making it work with TCC was
> a different ballgame. It turns out that TCC does not generate functions at
> word boundaries - so pointer tagging does not work. The way I addressed it
> is by changing the CELL to contain 3 parts instead of 2 - the third part
> for type and GC.
>
> I just got "done" with it - https://github.com/lispware/minilisp . It has
> limited string/symbol support since it only allows strings that can be
> packed in a word. Bringing back full string support would be the first
> thing. Or perhaps breaking the single C file up would be first - I found
> collapsing all the miniPicoLisp C files into one easier during the change :)
>
> My eventual goal is to get it hooked up with libuv - perhaps by next year
> :)
>
> Happy New Year!
> Kashyap
>

Re: Clarifications about evExpr

[C K Kashyap]

Got it! ... thank you so much Alex!
The (X Y . Z) and the @ scenarios fill the gap in my understanding!
Regards,
Kashyap

On Wed, Oct 13, 2021 at 7:11 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I was going over the evExpr functions in miniPicoLisp/PicoLisp 32 and
> had a
> > couple of questions -
> >
> > If I understand correctly - if (isNil(y)) block deals with expressions
> such
> > as
> > (F 1 2) where F => (de F (X Y) (+ X Y)) and the else if (y != At) block
> > deals with the scenario where F => (de F X (for I X (prinl I))) .
>
> Correct, but the latter deals also with
>
>(de F (A B C . X) ...
>
> because A, B and C are eaten up by the while (isCell(y)) above.
>
>
> > My questions are as follows -
> >
> > 1. Why do we have this block of code? It seems to evaluate the args which
> > is only used in the if(isNil(y)) block.
>
>
> No, it does not evaluate. Evaluation took place already in the loop above

Clarifications about evExpr

[C K Kashyap]

Hi Alex,

I was going over the evExpr functions in miniPicoLisp/PicoLisp 32 and had a
couple of questions -

If I understand correctly - if (isNil(y)) block deals with expressions such
as
(F 1 2) where F => (de F (X Y) (+ X Y)) and the else if (y != At) block
deals with the scenario where F => (de F X (for I X (prinl I))) .

My questions are as follows -

1. Why do we have this block of code? It seems to evaluate the args which
is only used in the if(isNil(y)) block. Why is it not like the "binding"
that happens in doLet - to back up the values of the symbols?
   while (isCell(y)) {
  f.bnd[f.cnt].sym = car(y);
  f.bnd[f.cnt].val = EVAL(car(x));
  ++f.cnt, x = cdr(x), y = cdr(y);
   }

2. In what scenario is the final else block used?

I think, I am essentially asking for an annotation of the evExpr function?
I'd really appreciate any pointers.

Regards,
Kashyap

Re: Big int in picolisp

[C K Kashyap]

Thanks Alex,
Regards,
Kashyap

On Sun, May 16, 2021 at 10:08 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I am trying to understand how big integers are stored in Picolisp. I
> notice
> > that the ASCII values of the digits are stored in some cases - for
> example
> > 1234 is stored as 0x34333231.
>
> Big integers are always stored in binary representation.
>
> I think what you saw was inside a symbol name. ASCII values are only
> stored in
> the names of symbols, which are technically numbers consisting of the
> shifted
> and combined UTF-8 characters.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Big int in picolisp

[C K Kashyap]

Hi Alex,
I am trying to understand how big integers are stored in Picolisp. I notice
that the ASCII values of the digits are stored in some cases - for example
1234 is stored as 0x34333231. That does not look like the format that's
used always - I am going by the "> 9" references in the code. I
cant seem to understand it by reading the code :( I'd really appreciate
some explanation.
Regards,
Kashyap

Unsubscribe

[k]

Šo'¤“*-¢ç!r‰˜¢æ«zz0º{.nÇ+‰·



发自我的小米手机

Re: Question about the "next ptr" in heapAlloc

[C K Kashyap]

Got it ... makes sense ... thanks Alex :)
Regards,
Kashyap

On Tue, Mar 2, 2021 at 10:04 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I noticed that in the linked list of free cells, "car" is used as the
> next
> > pointer. Is the choice arbitrary? I could've been "cdr" too right? Just
> > curious if there is some interesting reason behind it :)
>
> It is almost arbitrary. A very tiny, very theoretical, reason is a possibly
> faster traversal of the heap when the CDRs are not needed (e.g. when
> counting
> the length of the free list), because then the access is a direct pointer
> dereference without the need for an offset in the CPU instruction.
>
> On a modern CPU the effect is not measurable at all.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Question about the "next ptr" in heapAlloc

[C K Kashyap]

Hi Alex,

I noticed that in the linked list of free cells, "car" is used as the next
pointer. Is the choice arbitrary? I could've been "cdr" too right? Just
curious if there is some interesting reason behind it :)

Regards,
Kashyap

Re: Picolisp Outlook

[C K Kashyap]

I also believe that the simplicity of PicoLisp by itself is a "killer app".
I've explored several languages in the past but PicoLisp is the only one
that allowed me to understand the implementation of the language all the
way (I still have to work on the external symbol bit :) . I was so used to
seeing documents of concepts of other languages that don't directly map to
the source code that it took me a while to realize the accuracy of PicoLisp
documentation.

Regards,
Kashyap

On Tue, Feb 23, 2021 at 2:26 AM Manuel Cano  wrote:

> Hi,
>
> That's surely because it isn't made in Picolisp! :D
>
> Kind regards,
> Manu
>
>
> El mar, 23 feb 2021 a las 10:32, Alexander Burger ()
> escribió:
>
>> Hi all,
>>
>> sorry for the multiple mails! Seems I have a DNS problem on
>> the server ...
>>
>> On Tue, Feb 23, 2021 at 09:18:57AM +0100, Alexander Burger wrote:
>> > Hi Thorsten,
>> > ...
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>>

Re: native/lisp in picoLisp 32

[C K Kashyap]

Thanks Alex...wow, I completely forgot about itsorry about that. I'll
make sure I look up the list once before posting...that I surely can
remember:)

On Tue, Feb 9, 2021, 10:18 PM Alexander Burger  wrote:

> On Wed, Feb 10, 2021 at 05:59:10AM +, Mike wrote:
> > February 10, 2021 7:29 AM, "C K Kashyap"  wrote:
> >
> > > Hi all,
> > > Has anyone done the C implementation of the native and lisp (for
> callback)? I am trying to work it
> > > out based on the 64bit source but I think it will be a lot easier if I
> had a C implementation for
> > > reference :)
> > >
> >
> > You already asked this here and Great Mr.Pahi already answered:
> > https://www.mail-archive.com/picolisp@software-lab.de/msg09811.html
> > His repo is the only choice.
>
> Or, you take a look at pil21. It implements a large part of 'native' in C
> (as a
> glue to libffi in @src/lib.c) and the rest in PilSrc (which is easier to
> read
> than PilAsm).
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

native/lisp in picoLisp 32

[C K Kashyap]

Hi all,
Has anyone done the C implementation of  the native and lisp (for
callback)? I am trying to work it out based on the 64bit source but I think
it will be a lot easier if I had a C implementation for reference :)
Regards,
Kashyap

3 part cell miniPicoLisp

[C K Kashyap]

Hi All,
I had been exploring the miniPicoLisp source for several months now. My
goal was to make it compile with Microsoft C compiler and Tiny C Compiler (
TCC ) on windows - and
gain a deeper understanding of the implementation in the process. In order
to compile using Microsoft C compiler, it was sufficient to remove the use
of VLA(variable length array). However, making it work with TCC was a
different ballgame. It turns out that TCC does not generate functions at
word boundaries - so pointer tagging does not work. The way I addressed it
is by changing the CELL to contain 3 parts instead of 2 - the third part
for type and GC.

I just got "done" with it - https://github.com/lispware/minilisp . It has
limited string/symbol support since it only allows strings that can be
packed in a word. Bringing back full string support would be the first
thing. Or perhaps breaking the single C file up would be first - I found
collapsing all the miniPicoLisp C files into one easier during the change :)

My eventual goal is to get it hooked up with libuv - perhaps by next year :)

Happy New Year!
Kashyap

Re: PicoLisp Chess

[C K Kashyap]

Merry Christmas to you too Alex!
Merry Christmas to the picolisp family!!!
Regards,
Kashyap

On Thu, Dec 24, 2020 at 7:02 AM Alexander Burger 
wrote:

> Hi all,
>
> I should announce the new version of PicoLisp Chess here too.
>
> Not that it is a strong chess program (not at all!), but it has some good
> examples of PicoLisp programming (e.g. interactive graphics on a
> server-based
> framework using canvas and coroutines).
>
> It comes in three flavors: A CLI program, a web application, and a PilBox
> app.
>
> All three use the same code base, and the incarnations being only 32 lines
> for
> CLI, 21 lines for web version, and 15 lines for the PilBox app (the rest
> in the
> PilBox directory are just symbolic links).
>
>
> A description is here:
>
>https://software-lab.de/chess/README
>
>
> The sources are at
>
>https://software-lab.de/chess.tgz
>
> (Needs pil21)
>
>
> You can try the web application by going with a browser to
>
>https://picolisp.com/chess
>
> or install PilBox from Google Play and type "Chess" in the settings.
>
> Have fun! :)
>
> A merry Christmas to everyone!! :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Array avoidance example

[C K Kashyap]

Got it! makes sense.
Thanks a lot Alex and Alex :)

On Fri, Nov 13, 2020 at 9:30 AM Alexander Burger 
wrote:

> Hi all,
>
> On Fri, Nov 13, 2020 at 06:05:11PM +0100, Alexander Shendi wrote:
> > I'm the wrong Alex (and I'm probably wrong),
>
> You are not wrong (in any case ;)
>
>
> > but I would think that memory allocated by malloc() isn't managed by the
> GC.
> > IDK if you can install finalizers or something similar.
>
> Indeed, that's also possible:
>
>(let P (%@ "malloc" 'P 99)
>   (finally (%@ "free" NIL P)
>  (struct ...)
>  ... ) )
>
> The free() will also be called upon throw or error exit.
>
> But surely the (buf P ...) way is the most efficient one.
>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Array avoidance example

[C K Kashyap]

Thanks Alex,
Is the allocated memory purged by the GC in your example? If not, would it
be straightforward to plug it in a manner that the GC handles the free?
Regards,
Kashyap

On Thu, Nov 12, 2020 at 11:21 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > Could you please share the example where you shared how native code
> > interface could be used to malloc a section of the heap? I believe you
> > shared this in the last PiCon.
>
> I don't remember exactly, but it could have been something like (using
> pil21):
>
># Allocate 99 bytes
>: (setq P (%@ "malloc" 'P 99))
>-> 512227229696
>
># Store a long integer -1 (or )
>: (struct P NIL (-1 . 8))
>-> NIL
>
># Read a list of 8 bytes
>: (struct P '(B . 8))
>-> (255 255 255 255 255 255 255 255)
>
># Store 3 bytes
>: (byte P 65) (byte (inc P) 66) (byte (+ P 2) 0)
>-> 0
>
># Read 8 bytes again
>: (struct P '(B . 8))
>-> (65 66 0 255 255 255 255 255)
>
># Read the same as a string
>: (struct P 'S)
>-> "AB"
>
># Free the memory
>: (%@ "free" NIL P)
>-> NIL
>
>
> Instead of heap malloc() / free() you can (again, pil21) also use a local
> buffer
> on the stack:
>
>: (buf P 99
>   (byte P 65)
>   (byte (inc P) 0)
>   (struct P 'S) )
>-> "A"
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Array avoidance example

[C K Kashyap]

Hi Alex,
Could you please share the example where you shared how native code
interface could be used to malloc a section of the heap? I believe you
shared this in the last PiCon.
Regards,
Kashyap

Re: PilCon Friday

[C K Kashyap]

Thanks for the summary Wilhelm!
Regards,
Kashyap

On Fri, Nov 6, 2020 at 12:33 PM Wilhelm Fitzpatrick  wrote:

> Only topics whose questioners were present were discussed, so we didn't
> talk about the interpreter only approach, holding it as a topic for future
> session.
>
> Alex addressed the "array avoidance" question, explaining the how arrays
> would complicate the core single data type implementation and approach of
> picolisp (that single data type being the cell). Further he talked about
> how most approaches that in other languages fall to arrays by default can
> be handled through picolisp lists, or creating more purpose built data
> structures rather than reaching for an array. Finally he showed how
> picolisp's native code interface can be used to malloc a section of heap
> memory and address it directly to create a direct access array like
> structure if that is absolutely required.
>
> Then the question of how picolisp interacts with Java was discussed, and
> Alex showed examples in the Pilbox, and showed the named pipe mechanism
> used to send commands to the Java side and receive responses back to the
> picolisp world.
>
> Olaf showed off his experimentation of using picolisp to communicate with
> JavaScript running in a browser to dynamically update SVG objects, creating
> animation. Olaf & Alex dug into some of the issues in the original
> experiment, and one source of problems was that the ServerEvent facility
> that Olaf was using only sends a single line at time to the other side.
>
> Olaf's motto for the evening: "when you read the picolisp documentation,
> you have to read every word"
>
> There may have a been a few other small topics that I am failing to
> recollect.
>
> -wilhelm
> On 11/6/20 8:03 AM, C K Kashyap wrote:
>
> As bad an excuse that it may sound, it is the truth - I messed up my alarm
> setting (AM vs PM) :) and missed the meeting.
>
> Could I request someone to please summarize what was discussed?
> particularly about the "interpreter only" approach. If it was not discussed
> then perhaps I can request Alex to write down his thoughts.
>
> Regards,
> Kashyap
>
> On Thu, Nov 5, 2020 at 2:59 PM Kevin Ednalino 
> wrote:
>
>> 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: PilCon Friday

[C K Kashyap]

As bad an excuse that it may sound, it is the truth - I messed up my alarm
setting (AM vs PM) :) and missed the meeting.

Could I request someone to please summarize what was discussed?
particularly about the "interpreter only" approach. If it was not discussed
then perhaps I can request Alex to write down his thoughts.

Regards,
Kashyap

On Thu, Nov 5, 2020 at 2:59 PM Kevin Ednalino  wrote:

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

[C K Kashyap]

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: A question about the definition of tail in miniPicoLisp

[C K Kashyap]

Thank you Alex and AlexG,

The definition of tail was the only thing I had to change in order to make
mPL work after expanding the cell to 4 words :) (ofcourse, I had to change
gen3m as well).

Using an index into an array to encode the function pointer seems like an
interesting idea. Although I think I would have to adjust how isNum is used
everywhere. I will perhaps try it after I am done with my 4 word experiment
:) [my eventual goal with this experiment is to run mPL with libuv :) and
then perhaps try a 3 word cell]

Regards,
Kashyap



On Thu, Aug 27, 2020 at 3:28 AM Alex Gilding  wrote:

> One technique in C for mapping incompatible pointer or alignment sizes
> (for when you can't, or don't want to, convert directly between
> pointer and `intptr_t`) is to use an intermediate array, and instead
> of storing native pointers, store indexes into this array.
>
> For your case you could put all the native functions in a C array, and
> expose them to miniPicoLisp by taking the index in this array and
> shifting it up by miniPicoLisp's _assumed_ alignment, to make space
> for the tag bits (which becomes a "virtual" alignment with no special
> connection to the C implementation). To dereference the mPL reference
> to a native function, shift the tag bits away again, and look up the
> function pointer at that index in the intermediate array.
>
> While this does also impose a size cost, it doesn't impose that cost
> on all Lisp-side objects the way changing the cell structure would,
> only on native functions (or, on any other C-side object you wanted to
> do this for), which will probably (hopefully?) only make up a very
> small minority of the objects a Lisp program wants to manipulate, and
> is also a constant-sized container in most programs. The shift and
> indirection instead of no-op conversion from integer to callable
> pointer introduces a runtime cost, but it wouldn't be all that high.
>
> This is one way to simulate C function pointers on targets that don't
> expose function pointers in a directly-convertible way at all (e.g.
> JVM).
>
> Using indices instead of native pointers generalizes to any object
> kind for similar costs, e.g. you can translate a 16-bit Lisp word size
> for a 64-bit C host program by doing the same thing for cells in
> general, if you really want. One interesting consequence of this is
> that if you put different base cell types into different heap arrays,
> you get a reinterpretation of the tag bits as a heap-selection index
> for different types, instead of as sub-cell pointers. This starts to
> become a completely different model from picoLisp's very simple and
> elegant word-offset manipulation, though (almost the exact opposite).
>
> Whereas _limiting_ the idea to function pointers has the advantage
> that since a function pointer is strictly supposed to be "opaque"
> anyway from the C perspective - it's not data, it's not expected to be
> accessible as data, the pointer's value isn't meaningful in
> object/size/etc. terms, only as an identity - you don't fundamentally
> change the meaning of the interpreter model on the C side, you just
> change the cast operation from a no-op to an actual conversion. The
> rest of the picoLisp word manipulation system remains untouched,
> keeping the pointer adjustment concept and the homogeneous heap.
>
> AlexG
>
>
> On 27/08/2020, Alexander Burger  wrote:
> > On Wed, Aug 26, 2020 at 11:16:48PM -0700, C K Kashyap wrote:
> >> About why I am trying it - it's primarily just a learning exercise for
> >> me.
> >> What I am trying is expanding the cell to 4 words instead of two and use
> >> the extra words as the meta data and not require tagged pointers. This
> >> way
> >
> > I see.
> >
> >> I could even build it with TCC that does not seem to align functions at
> 4
> >> byte boundary.
> >
> > OK, function pointer alignment is a different issue. You can however
> encode
> > the
> > pointer in different ways. Some versions of PicoLisp shift'ed and or'ed
> it.
> >
> >
> >> Sorry if I am missing something, but wouldn't x-1 result in shifting the
> >> pointer by 8 bytes instead of 4 (since size of cell is 8). Which is
> >> probably why cdr is used instead of car?
> >
> > Yes. x-1 is minus 8 bytes, and the cdr adds 4 bytes. So the physical
> access
> > goes
> > to -4.
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>
>

Re: A question about the definition of tail in miniPicoLisp

[C K Kashyap]

Thanks Alex,
About why I am trying it - it's primarily just a learning exercise for me.
What I am trying is expanding the cell to 4 words instead of two and use
the extra words as the meta data and not require tagged pointers. This way
I could even build it with TCC that does not seem to align functions at 4
byte boundary.

Sorry if I am missing something, but wouldn't x-1 result in shifting the
pointer by 8 bytes instead of 4 (since size of cell is 8). Which is
probably why cdr is used instead of car?

regards,
Kashyap

On Wed, Aug 26, 2020 at 10:56 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I am still working on the idea of using non-tagged pointers in
> miniPicoLisp
> > - in order to get rid of the requirement that function pointers be word
> > aligned.
>
> Why would you want to do that? The concept of encoding the tags in the
> lowest
> bits of a pointer is the core idea of PicoLisp. Pointer alignment to 8
> bytes (on
> 32 bits) gives three tag bits for free.
>
> Three tag bits are needed (gc mark, number and symbol tag). If you use
> other
> bits (e.g. the highest ones) you lose 87.5 percent of the address space.
> And
> runtime checks for higher bits are more expensive. Similar for other
> concepts
> like using separate heaps.
>
> The alignment comes at low cost, only once when the heap is allocated.
> After
> that all cells are guaranteed to be properly aligned. Most hardware has
> that
> requirement anyway. If not, word accesses become intolerably slow.
>
>
>
> > #define tail(x) (((x)-1)->cdr)
> >
> > Does this not result in going outside the 0th cell? Would this be more
> > appropriate?
>
> No, because 'x' points to an offset of four (because of the tag bit!) to
> the
> symbol
>
> Symbol
> |
> V
>   +-+-+
>   |  |  | VAL |
>   +--+--+-+
>  | tail
>  |
>  V  name
>
> so that 'tail' points to the start address of that cell.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

A question about the definition of tail in miniPicoLisp

[C K Kashyap]

Hi Alex,
I am still working on the idea of using non-tagged pointers in miniPicoLisp
- in order to get rid of the requirement that function pointers be word
aligned. In the process I noticed that the definition of tail is as follows
-

#define tail(x) (((x)-1)->cdr)

Does this not result in going outside the 0th cell? Would this be more
appropriate?

#define tail(x) (((cell *)((long*)(x)-1))->car)

Regards,
Kashyap

Re: Question about miniPicoLisp

[C K Kashyap]

Thanks Alex!

On Thu, Aug 20, 2020 at 11:02 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > init.s defines append as follows -
> > append {doAppend}
> > ,NIL @X @X)) (((@A . @X) @Y (@A . @Z)) (append @X @Y @Z))) . T)
> >
> > I gather that the second line that starts with ',' adds properties to the
> > symbol.
>
> Yes, that's correct.
>
> > It is not clear to me what the properties are for. Can you please throw
> > some light on this?
>
> These are the Pilog predicates for append/3
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Question about miniPicoLisp

[C K Kashyap]

Hi Alex,
init.s defines append as follows -
append {doAppend}
,NIL @X @X)) (((@A . @X) @Y (@A . @Z)) (append @X @Y @Z))) . T)

I gather that the second line that starts with ',' adds properties to the
symbol.
It is not clear to me what the properties are for. Can you please throw
some light on this?
Regards,
Kashyap

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

OopsI did not plan my day well...its at 1am here :(I'll have to
join in the morning to see if the meeting is still on.

On Thu, Jul 2, 2020, 6:43 PM Bruno Franco 
wrote:

> Unfortunately, 8 UTC is too early for me XD, I'll have to wait for the 16
> UTC meeting
>
> On Thu, Jul 2, 2020 at 12:06 PM C K Kashyap  wrote:
>
>> I can't wait :)
>>
>> On Thu, Jul 2, 2020 at 9:46 AM Alexander Burger > > wrote:
>>
>>> On Thu, Jul 02, 2020 at 09:28:09AM -0700, C K Kashyap wrote:
>>> > Just to confirm - is this at 8am UTC on 3rd July?
>>>
>>> Yes, that's right. About 15 hours and 20 minutes from now ;)
>>>
>>> ☺/ A!ex
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

I can't wait :)

On Thu, Jul 2, 2020 at 9:46 AM Alexander Burger  wrote:

> On Thu, Jul 02, 2020 at 09:28:09AM -0700, C K Kashyap wrote:
> > Just to confirm - is this at 8am UTC on 3rd July?
>
> Yes, that's right. About 15 hours and 20 minutes from now ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Just to confirm - is this at 8am UTC on 3rd July?
regards,
Kashyap

On Wed, Jul 1, 2020 at 8:42 AM C K Kashyap  wrote:

> Yes, I agree. I am totally onboard with "meet and greet" ... It will be
> good to just interact with folks with similar interests!
>
> Regards,
> Kashyap
>
> On Wed, Jul 1, 2020 at 7:48 AM Alexander Burger 
> wrote:
>
>> Hi Kashyap,
>>
>> > Would this be recorded?  There is just not enough picoLisp  video
>> content
>> > out there in my opinion.
>> > I would like a session on History/evolution of Picolisp in your own
>> words
>>
>> AFAIK not in the current setup. Jitsi allows some connection to youtube
>> iirc,
>> but I have not investigated. (beneroth?)
>>
>> I don't mind, but I don't expect linear stuff at this stage, no really
>> useful
>> presentation, more informal talks (e.g. introducing each other).
>>
>> For useful presentations to be recorded for eternity it would be better to
>> prepare *real* presentations. But for such presentations, we don't need to
>> gather at such meetings at all, instead anybody could upload such videos
>> and
>> others may look when they have time :)
>>
>> What do you other guys think?
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Yes, I agree. I am totally onboard with "meet and greet" ... It will be
good to just interact with folks with similar interests!

Regards,
Kashyap

On Wed, Jul 1, 2020 at 7:48 AM Alexander Burger  wrote:

> Hi Kashyap,
>
> > Would this be recorded?  There is just not enough picoLisp  video content
> > out there in my opinion.
> > I would like a session on History/evolution of Picolisp in your own words
>
> AFAIK not in the current setup. Jitsi allows some connection to youtube
> iirc,
> but I have not investigated. (beneroth?)
>
> I don't mind, but I don't expect linear stuff at this stage, no really
> useful
> presentation, more informal talks (e.g. introducing each other).
>
> For useful presentations to be recorded for eternity it would be better to
> prepare *real* presentations. But for such presentations, we don't need to
> gather at such meetings at all, instead anybody could upload such videos
> and
> others may look when they have time :)
>
> What do you other guys think?
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Would this be recorded?  There is just not enough picoLisp  video content
out there in my opinion.

I would like a session on History/evolution of Picolisp in your own words
Alex!

Regards,
Kashyap




On Wed, Jul 1, 2020 at 3:59 AM Alexander Burger  wrote:

> Hi all,
>
> On Thu, Jun 18, 2020 at 08:42:48AM +0200, Alexander Burger wrote:
> > The first one is on 3rd of July, 8:00 UTC
> >
> >https://meeting.itship.ch/PilCon
>
> My proposal would be to start free-form, exchanging ideas and questions.
>
> If there is interest, I could explain and demonstrate "FireFight", a
> non-trivial
> PicoLisp project I'm writing for the Catalonian Forest Fire volunteers. It
> involves many aspect of PicoLisp application development, like a central
> database communicating with remote Android (PilBox) devices, replicating
> databases between them, and showing the states in interactive
> OpenStreetMaps.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

+ 1 ... looking forward to it

On Wed, Jun 17, 2020 at 11:48 PM Alexander Burger 
wrote:

> Hi all,
>
> On Wed, Jun 03, 2020 at 07:54:22AM +0200, Alexander Burger wrote:
> > I would propose informal Jitsi meetings every second Friday or so. The
> time
> > could be alternating 8:00 and 16:00 UTC, to allow attendance from most
> time
> > zones. No big planning and schedule. Let's start with questions,
> tutorials and
> > demonstrations.
>
> OK, so let's try it!
>
> The first one is on 3rd of July, 8:00 UTC
>
>https://meeting.itship.ch/PilCon
>
> I'm looking forward to it :)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: cells in picolisp [tutorial, slides]

[C K Kashyap]

I liked it :)
Thanks,
Kashyap

On Fri, Jun 5, 2020 at 5:37 AM Mike  wrote:

> hi all,
>
> https://envs.net/~mpech/cells-tutorial.pdf
>
> I've created tutorial about cell as root of data type hierarchy.
> Goal of PDF is understanding of destructive functions.
> I hope you will learn something new.
>
> Happy coding,
> (mike)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Thanks beneroth! It works for me :)

On Wed, Jun 3, 2020 at 8:48 AM  wrote:

> Hi Kashyap
>
> No, there is an webinterface and the app. Feel free to try out my server:
> https://meeting.itship.ch
>
> The webinterface is usually run on the server which is hosting the video
> conference, but they're separate pieces of software ("jitsi meet" and
> "jitsi video bridge"). The app can connect to every publicly accessible
> server, by default it connects to the one operated by the jitsi project
> itself (https://meet.jit.si/).
>
> The webinterface has actually more features (e.g. screen sharing), but the
> app is more optimized (I expect better stream quality / less bandwidth
> load).
> Chrome/chromium is better supported. In the past a single Firefox client
> in a conference could apparently cause higher/multiplication of bandwidth
> load for every participant, though this should be much better with the
> newest version of Jitsi and the newest Firefox.
> See:
> - https://github.com/jitsi/jitsi-meet/issues/4758
> -
> https://bugzilla.mozilla.org/buglist.cgi?columnlist=bug_type%2Cshort_desc%2Cproduct%2Ccomponent%2Cpriority%2Cassigned_to%2Ccf_status_firefox75%2Ccf_status_firefox76%2Ccf_status_firefox77%2Ccf_status_firefox_esr68%2Cbug_status%2Cresolution%2Cchangeddate&query_format=advanced&status_whiteboard=jitsi-meet&status_whiteboard_type=substring&query_based_on=
>
> Regards,
> beneroth
> On 03.06.20 16:57, C K Kashyap wrote:
>
> Is Jitsi a phone only tool? I only see an apple/android download here -
> https://jitsi.org/#download
>
> Regards,
> Kashyap
>
> On Wed, Jun 3, 2020 at 7:55 AM C K Kashyap  wrote:
>
>> Wonderful idea indeed!
>>
>> On Wed, Jun 3, 2020 at 6:01 AM Davide BERTOLOTTO <
>> davide.bertolo...@gmail.com> wrote:
>>
>>> Wonderful idea
>>>
>>> On Wed, Jun 3, 2020, 13:27 O.Hamann >
>>> wrote:
>>>
>>>> ++
>>>>
>>>> On 03.06.20 07:54, Alexander Burger wrote:
>>>> > I would propose informal Jitsi meetings every second Friday or so.
>>>> The time
>>>> > could be alternating 8:00 and 16:00 UTC, to allow attendance from
>>>> most time
>>>> > zones. No big planning and schedule. Let's start with questions,
>>>> tutorials and
>>>> > demonstrations.
>>>>
>>>> --
>>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>>
>>>>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Is Jitsi a phone only tool? I only see an apple/android download here -
https://jitsi.org/#download

Regards,
Kashyap

On Wed, Jun 3, 2020 at 7:55 AM C K Kashyap  wrote:

> Wonderful idea indeed!
>
> On Wed, Jun 3, 2020 at 6:01 AM Davide BERTOLOTTO <
> davide.bertolo...@gmail.com> wrote:
>
>> Wonderful idea
>>
>> On Wed, Jun 3, 2020, 13:27 O.Hamann  wrote:
>>
>>> ++
>>>
>>> On 03.06.20 07:54, Alexander Burger wrote:
>>> > I would propose informal Jitsi meetings every second Friday or so. The
>>> time
>>> > could be alternating 8:00 and 16:00 UTC, to allow attendance from most
>>> time
>>> > zones. No big planning and schedule. Let's start with questions,
>>> tutorials and
>>> > demonstrations.
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>>
>>>

Re: Fridays for Functions (Was: PilCon 2020)

[C K Kashyap]

Wonderful idea indeed!

On Wed, Jun 3, 2020 at 6:01 AM Davide BERTOLOTTO <
davide.bertolo...@gmail.com> wrote:

> Wonderful idea
>
> On Wed, Jun 3, 2020, 13:27 O.Hamann  wrote:
>
>> ++
>>
>> On 03.06.20 07:54, Alexander Burger wrote:
>> > I would propose informal Jitsi meetings every second Friday or so. The
>> time
>> > could be alternating 8:00 and 16:00 UTC, to allow attendance from most
>> time
>> > zones. No big planning and schedule. Let's start with questions,
>> tutorials and
>> > demonstrations.
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>>

Re: Native callbacks in PicoLisp

[C K Kashyap]

Thanks for the clarification Alex! ... I am not a fan of threads - just
wanted to confirm.
Regards,
Kashyap

On Fri, May 22, 2020 at 9:58 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > In the section about callbacks (
> > https://software-lab.de/doc/native.html#funptr) it is not explicitly
> > mentioned that the callback (lisp ...)  cannot be called from a different
> > thread.
>
> Yes, the docs nowhere mention threads, as they are not an issue in
> PicoLisp. It
> rather uses communicating processes.
>
> You *could* probably use PicoLisp in a threaded program, but it would need
> precautions like creating all locally bound symbols in thread-private
> namespaces.
>
>
> > However, since PicoLisp does not have threads, I'd imagine that
> > callbacks cannot be called from a different thread. Is that correct
> > understanding?
>
> I have not thought about this. Not sure atm what kind of conflicts might
> show
> up.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

MiniPicoLisp with SDL on GNU/Linux, Mac, Windows

[C K Kashyap]

Hi all,
It is super cool to see SDL graphs driven through miniPicoLIsp :) ... I am
too excited and wanted to share it before doing some polishing

https://github.com/ckkashyap/MiniPicoLisp/tree/SDL

This code builds and runs on "all" the operating systems :)

My next goal is integrate it with openssl - perhaps implement a generic
"call" like function.

Regards,
Kashyap

Native callbacks in PicoLisp

[C K Kashyap]

Hi Alex et al,

In the section about callbacks (
https://software-lab.de/doc/native.html#funptr) it is not explicitly
mentioned that the callback (lisp ...)  cannot be called from a different
thread. However, since PicoLisp does not have threads, I'd imagine that
callbacks cannot be called from a different thread. Is that correct
understanding?

Regards,
Kashyap

Re: picoLisp 19.12: variable length array in structure fixes

[C K Kashyap]

Super ...Congratulations Andras!

I just gave it a spin and it just worked. I generated 64bit and 32bit
executables (after installing libffi-dev and libffi-dev:i386) and tried
(call "ls") :)
I am particularly happy since I will be able to reference C code for the
FFI implementation that I could potentially use in miniPicoLisp.

Regards,
Kashyap


On Fri, May 22, 2020 at 10:05 AM Alexander Burger 
wrote:

> Hi Andras,
>
> > The code at https://github.com/pahihu/picoLisp <
> 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.
>
> Wow! Big achievement, thanks a lot!!
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: native/lisp in picolisp32

[C K Kashyap]

I get a feeling that most of the folks on this list have Alex as the first
name :)

Here's my problem. I am convinced that PicoLisp is my final language but
unfortunately I am unable to use it on Windows where I have to spend most
of the time :(
I just got it working with SDL on windows a couple of weeks ago (It's on my
github page but I have not talked about it since it needs polishing :) )

It would be great if picoLisp could have a OS abstraction layer that
normalizes all the POSIX calls - while P in POSIX is meant to be portable -
my personal experience has been that there are subtle differences between
HPUX/AIX/Solaris and GNU/Linux - ofcourse this personal experience is from
15 years ago so  I am not sure of the current situation.  One could then
implement the OS abstraction layer on windows and have picoLisp running on
windows too. Actually, its not just windows - this approach could perhaps
make it easier for other platforms too - but since most new platforms
support GNU/Linux these days, perhaps there is not a strong motivation
there.

Anyway, I agree with your statements Alex.

Regards,
Kashyap






On Sat, May 16, 2020 at 10:15 AM Alex Gilding  wrote:

> With a system like miniPicoLisp, like any ultra-light footprint
> interpreter - does a general purpose FFI really gel with the design?
>
> IMO the way people normally use interpreters in this weight class (see
> also, Lua, Chibi, picoC, Jim, ...) is to embed them: i.e. the interpreter
> becomes a first-class part of the hosting C (or equivalent) program. In so
> doing it gains first-class access to all of the host's API on the runtime
> level, and instead of using a dynamic API load native functions at runtime,
> it has the ability to statically expose them as part of what effectively
> becomes a domain-specific extension of the interpreter that provides the
> useful parts of the program's internal C API as "builtins".
>
> This isn't necessarily a very picoLisp way to structure a program - I get
> the impression picoLisp is usually the "host" by design - but I wonder
> whether, if you avoid that and try to make miniPicoLisp the conceptually
> freestanding language, you'd end up erasing most of what makes it distinct
> from the main picoLisp anyway.
>
> AlexG
>
> On Sat, 16 May 2020, 16:43 C K Kashyap,  wrote:
>
>> Oh btw Andras,
>> The main reason I would love those features in pil32 (C) is so that I can
>> more easily translate it to miniPicoLisp
>> I really want to be able to have a system that requires nothing more than
>> C :)
>> Regards,
>> Kashyap
>>
>> On Fri, May 15, 2020 at 10:53 PM C K Kashyap  wrote:
>>
>>> Absolutely!!!
>>> If that is done - I believe there is no reason not to have pil64 in C
>>> too right :)
>>> Regards,
>>> Kashyap
>>>
>>> On Fri, May 15, 2020 at 9:55 PM Andras Pahi  wrote:
>>>
>>>> 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  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: native/lisp in picolisp32

[C K Kashyap]

Oh btw Andras,
The main reason I would love those features in pil32 (C) is so that I can
more easily translate it to miniPicoLisp.
I really want to be able to have a system that requires nothing more than C
:)
Regards,
Kashyap

On Fri, May 15, 2020 at 10:53 PM C K Kashyap  wrote:

> Absolutely!!!
> If that is done - I believe there is no reason not to have pil64 in C too
> right :)
> Regards,
> Kashyap
>
> On Fri, May 15, 2020 at 9:55 PM Andras Pahi  wrote:
>
>> 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  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: native/lisp in picolisp32

[C K Kashyap]

Absolutely!!!
If that is done - I believe there is no reason not to have pil64 in C too
right :)
Regards,
Kashyap

On Fri, May 15, 2020 at 9:55 PM Andras Pahi  wrote:

> 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  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: native/lisp in picolisp32

[C K Kashyap]

Got it - thanks Alex.

I wish there was a libposix (perhaps using libuv) that PicoLisp would work
against and then it would magically work on Mac and Windows too :)

I was working on miniPicoLIsp with the idea of building in those
features into miniPicoLisp (since it already works on Windows - builds
using MS C compiler after VLA removal and Mac). I think an SDL (libSDL) app
may be a good POC.

Regards,
Kashyap

On Fri, May 8, 2020 at 9:56 AM Alexander Burger  wrote:

> On Fri, May 08, 2020 at 06:42:33PM +0200, Alexander Burger wrote:
> > Yes, miniPicoLisp and Ersatz do not depend on POSIX. Mini just uses the C
> > standard I/O stuff. "POSIX" basically means "Unix".
>
> It means processes (yes, fork()) and process groups, terminal handling,
> signals,
> pipes, file control (fcntl()), asynchronous I/O (select() or poll()) and
> so on.
> The PicoLisp infrastructure completely depends on these things.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: native/lisp in picolisp32

[C K Kashyap]

>
>
> How do you mean that? Pil21 is not even finished for the first version.
>
> Perhaps I am remembering it incorrectly - I thought pil21 (a couple of
months ago I think) - did not support 'fork'/'call' etc thereby making me
thing it did not depend POSIX as heavily yet - when I say that I mean,
depending on a wider range of the POSIX API set.

But anyway it was always POSIX (as pil32 and pil64).
>

again, miniPicoLisp is also POSIX compliant right - but it uses a very
narrow slice of the POSIX API. Or am I understanding POSIX wrong here?


>
> ☺/ A!ex
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: native/lisp in picolisp32

[C K Kashyap]

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

native/lisp in picolisp32

[C K Kashyap]

Hi Alex,
I think I have fully digested gen3m.c at this point :). 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.

A quick question on gen3m.c - I noticed an unused parameter '*mem' in mkSym
- is there a reason to let it remain?

Regards,
Kashyap

Re: miniPicoLisp cons(Nil, Nil);

[C K Kashyap]

Oh yes thanks Alex,
Regards,
Kashyap

On Sat, May 2, 2020 at 7:10 AM Alexander Burger  wrote:

> Hi Kashyap,
>
> > Could you please tell me why we have the cons(Nil, Nil); in gen3m.c right
> > after insert(&Intern, "NIL", romSym("NIL", "(Rom+1)")); ?
>
> This allocates a dummy cell, required by 'NIL'. From doc/structures you see
>
>   NIL:  /
> |
> V
>   +-+-+-+-+
>   |'NIL'|  /  |  /  |  /  |
>   +-+-+-+-+
>
>   ^
>   |
>   This is the dummy cell
>
> This cell is needed to allow for the dual nature of NIL, being both a
> symbol and
> as a cell (= empty list). PicoLisp demands that both (car NIL) and (cdr
> NIL)
> return NIL.
>
> If you do (val NIL) or (car NIL), the CDR of the first cell is accessed,
> but for
> (cdr NIL) the access goes to the next cell in memory, i.e. the dummy cell

miniPicoLisp cons(Nil, Nil);

[C K Kashyap]

Hi Alex,
Could you please tell me why we have the cons(Nil, Nil); in gen3m.c right
after insert(&Intern, "NIL", romSym("NIL", "(Rom+1)")); ?
Regards,
Kashyap

Re: Pil21 Status

[C K Kashyap]

Congratulations Alex

On Fri, May 1, 2020 at 1:06 PM cilz  wrote:

> Congrats! Thank you very much for your hard work. PicoLisp has been my
> best friend during this quarantine :) Best, Eric
>
> Le 01/05/2020 à 15:41, Alexander Burger a écrit :
> > Hi all,
> >
> > pil21 reached the first milestone:
> > It passes the bignum tests in @misc/bigtest :)
> >
> > Next goal is self-bootstrap
> >
> > ☺/ A!ex
> >
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PilCon 2020

[C K Kashyap]

+1 for online :)

On Wed, Apr 22, 2020 at 4:48 AM David Bloom  wrote:

> +1 lurker interested in an online conference. While it is disappointing to
> not be able to meet people in person it seems that attendance will be
> dramatically increased.  Happy to help with testing online tools if needed.
>
> On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
> jean.christophe.hel...@traduction-libre.org> wrote:
>
>>
>>
>> > 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&A.
>>
>> 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?subjectUnsubscribe
>>
>

Re: MiniPicolisp Questions

[C K Kashyap]

oops .. hit send too early -
Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and remove the word aligned function
address restriction. Yes, a separate byte heap would totally be much more
complex. One of the reasons of this desire was to build miniPicoLis with
TCC :) which does not seem to generate WORD aligned function addresses. The
second reason for this desire was to have a system for "instructive"
purposes - where it seems that doubling the space may not be such a bad
idea. The wasted space would be clearly visible and perhaps help with the
appreciation for the tagged pointer as an optimization.

But yes, I can clearly see that a 9byte cell is not a good idea :)

On Wed, Apr 22, 2020 at 8:27 AM C K Kashyap  wrote:

> Got it. The idea was not to encode more types - just reduce the
> "complexity" of tagged pointers and impose the word aligned function
> address restriction but from what I gather. Yes, a separate byte heap would
> totally be much ore complex. One of the reasons of this desire was to build
> miniPicoLis with TCC :) which does not seem to generate WORD
> aligned function addresses. The second reason for this desire was to have a
> system for "instructive" purpose - where it seems that doubling the space
> may not be such a bad idea. The wasted space would be clearly visible and
> perhaps help with the appreciation for the tagged pointer as an
> optimization.
>
> But yes, I can clearly see that a 9byte cell is not a good idea :)
>
> Regards,
> Kashyap
>
> On Wed, Apr 22, 2020 at 7:28 AM Alexander Burger 
> wrote:
>
>> Hi Kashyap,
>>
>> > Quick question - when you mentioned "doubling of space" - perhaps you
>> were
>> > talking about systems that can only have WORD aligned pointers - is that
>> > correct?
>>
>> Not only. Also on a byte-addressed machine, imagine if you make a cell of
>> two
>> 9-byte words, you get every cell aligned at another offet, with terrible
>> performance. On most machines you will get a bus error anyway.
>>
>> So my second proposal was to use a separate heap of bytes. But this also
>> gets
>> extremely uncomfortable and inefficient, as you need to index into two
>> heaps for
>> each access. You won't get a simpler system, as you intended.
>>
>> And what to do with that byte? Encode more types than fit into the 4 bits
>> in
>> Pil? Then you must also interprete those types at runtime during
>> interpretation.
>> Seems you open a pandora box ;)
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: MiniPicolisp Questions

[C K Kashyap]

Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and impose the word aligned function
address restriction but from what I gather. Yes, a separate byte heap would
totally be much ore complex. One of the reasons of this desire was to build
miniPicoLis with TCC :) which does not seem to generate WORD
aligned function addresses. The second reason for this desire was to have a
system for "instructive" purpose - where it seems that doubling the space
may not be such a bad idea. The wasted space would be clearly visible and
perhaps help with the appreciation for the tagged pointer as an
optimization.

But yes, I can clearly see that a 9byte cell is not a good idea :)

Regards,
Kashyap

On Wed, Apr 22, 2020 at 7:28 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > Quick question - when you mentioned "doubling of space" - perhaps you
> were
> > talking about systems that can only have WORD aligned pointers - is that
> > correct?
>
> Not only. Also on a byte-addressed machine, imagine if you make a cell of
> two
> 9-byte words, you get every cell aligned at another offet, with terrible
> performance. On most machines you will get a bus error anyway.
>
> So my second proposal was to use a separate heap of bytes. But this also
> gets
> extremely uncomfortable and inefficient, as you need to index into two
> heaps for
> each access. You won't get a simpler system, as you intended.
>
> And what to do with that byte? Encode more types than fit into the 4 bits
> in
> Pil? Then you must also interprete those types at runtime during
> interpretation.
> Seems you open a pandora box ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: MiniPicolisp Questions

[C K Kashyap]

Hi Alex,
Quick question - when you mentioned "doubling of space" - perhaps you were
talking about systems that can only have WORD aligned pointers - is that
correct?
Regards,
Kashyap


On Wed, Apr 22, 2020 at 6:56 AM Guido Stepken  wrote:

> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a
> MMU and you get "Memory Access Violation", so no pointer rage checks needed
> to be handled by CPU any longer. Those formerly needed range checks, eating
> up clock cycles, now are deeply sticking in MMU and IOMMU ... Bang! -
> Exception!
>
> Also reading about modern "multi generational garbage collectors" will
> explain, why garbage collected (functional, pure OO) languages have kept up
> with C/C++ statically machine code. Julia language, sitting on FemtoLisp
> JIT engine, in some times even ist faster than C
>
> Have fun!
>
> Am Mittwoch, 22. April 2020 schrieb Alexander Burger  >:
> > Hi Geo,
> >
> >> I think you mean 0xF000 for everything? This is indeed cool! but hmm
> does
> >> it limit the memory for each data type?
> >
> > Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
> terrible
> > solution. Doesn't scale, and is extremely inefficient due to the
> necessary
> > pointer range checks.
> >
> > PicoLisp's way is far superior, because the tag bits come "free", they
> are
> > implicit by the natural pointer alignments.
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-labde 
> ?subject=Unsubscribe
> >
> >

Re: MiniPicolisp Questions

[C K Kashyap]

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

[C K Kashyap]

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
>

MiniPicolisp Questions

[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: Tiny C Compiler

[C K Kashyap]

Thanks Guido,
I was not able TCC to align the functions though :(
Regards,
Kashyap

On Mon, Apr 13, 2020 at 2:05 PM Guido Stepken  wrote:

> That's kind of tabulator for structs of data in memory ... only of real
> use for handing over to vector instructions (SSE, AVX2, AVX512 ... ARM
> NEON). It's a GCC thing, not a C standard! ;-)
>
> https://stackoverflow.com/questions/7895869/cross-platform-alignx-macro
>
> Hope, that helps.
>
> Am Montag, 13. April 2020 schrieb C K Kashyap :
> > Hi all,
> > I just noticed that TCC was mentioned in another thread so I wanted to
> share my experience with it. I had tried to build miniPicoLisp with it but
> unfortunately, TCC does not seem to generate aligned functions :( it did
> not seem to honor  __attribute__((aligned))
> > Does anyone else have any experience with using TCC to build
> miniPicoLIsp or PicoLisp for that matter?
> > Regards,
> > Kashyap

Tiny C Compiler

[C K Kashyap]

Hi all,
I just noticed that TCC was mentioned in another thread so I wanted to
share my experience with it. I had tried to build miniPicoLisp with it but
unfortunately, TCC does not seem to generate aligned functions :( it did
not seem to honor  __attribute__((aligned))

Does anyone else have any experience with using TCC to build miniPicoLIsp
or PicoLisp for that matter?

Regards,
Kashyap

Re: Lisp, a language for "Stratified Design" Podcast and paper.pdf

[C K Kashyap]

Thanks for sharing ... loved the podcast!
Regards,
Kashyap

On Fri, Apr 10, 2020 at 2:28 PM Guido Stepken  wrote:

> A highly inspiring, philosophical Podcast about Abstractions in Lisp, that
> - until today - you simply can't do in other programming languages:
>
> https://podcasts.google.com/?q=Lisp+stratified
>
>
> https://www.researchgate.net/profile/Gerald_Sussman/publication/37596906_Lisp_A_Language_for_Stratified_Design/links/53d142ce0cf220632f392c19/Lisp-A-Language-for-Stratified-Design.pdf
>
> Also see that strage discussion about PicoLisp and 'Graph Database':
>
> https://www.mail-archive.com/picolisp@software-lab.de/msg09451.html
>
> Even with a Bachelor in Computer Science, people simply don't get the
> power of Picolisp. They don't see the forest for the trees.
>
> Have fun listening!
>
> Guido Stepken
>
>
>

Re: 64bit miniPicoLisp

[C K Kashyap]

Got it.
Thanks Alex.
Regards,
Kashyap

On Thu, Apr 9, 2020 at 10:14 PM Alexander Burger 
wrote:

> On Thu, Apr 09, 2020 at 09:46:05PM -0700, C K Kashyap wrote:
> > gcc. Things work fine when I use gcc 7.5 or above on Linux. However,
> when I
> > use gcc 6.3, I find that some of the symbols are not found. I have not
> dug
>
> Not sure, this looks like an issue with linker options for exported
> symbols.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: miniPicoLisp/picoLisp difference

[C K Kashyap]

I just noticed that all the picolisp emails were going into my spam
folder!!!

Thanks Alex -- phew - I thought I had messed up something!

On Thu, Apr 9, 2020 at 10:02 PM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > (let (A 1 (B . C) (2 3)) B) -> 2
> >
> > where as in miniPicoLisp (compiled using gcc 7.5 on ubuntu with -m32
> added
> > to gcc in the Makefile) I get NIL for the same expression. Is that
> expected?
>
> Yes, 'let' with list arguments (destructuring bind) is supported only in
> pil64.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

64bit miniPicoLisp

[C K Kashyap]

Hi Alex,

I am running into a weird situation when I build miniPicoLisp with 64 bit
gcc. Things work fine when I use gcc 7.5 or above on Linux. However, when I
use gcc 6.3, I find that some of the symbols are not found. I have not dug
into this much but I was wondering if there is any advice on the
possibilities that I should chase?

Regards,
Kashyap

miniPicoLisp/picoLisp difference

[C K Kashyap]

Hi Alex,
I noticed that in picoLisp the following is true

(let (A 1 (B . C) (2 3)) B) -> 2

where as in miniPicoLisp (compiled using gcc 7.5 on ubuntu with -m32 added
to gcc in the Makefile) I get NIL for the same expression. Is that expected?

Regards,
Kashyap

minipicolisp with Microsoft C compiler

[C K Kashyap]

[Sorry if this message messes up your thread - something went wrong with my
email and my sent emails got deleted]

I just realized that picolisp source has tests and I am going to try and
find out how many of them are valid for miniPicoLisp. If someone knows of a
better way to get the tests for miniPicoLisp, please do let me know.

Regards,
Kashyap





Hi all,
I am working on building minipicolisp with Microsoft C compiler the last
few days. It looks like getting rid of the uses of variable length array is
the bulk of the work. I was able to get it running after compiling with
CL.exe (32bit) - https://github.com/ckkashyap/miniPicoLisp/tree/remove-vla (you
can build it by simply running "cl main.c gc.c apply.c flow.c sym.c subr.c
math.c io.c" .

I was wondering if there is a test suite that I could use to gain some
confidence in the build.

Regards,
Kashyap