Re: Stream from call

[Tomas Hlavaty]

On Thu 25 Apr 2024 at 11:03, Patrick Lebas  wrote:
> How can I get the Stream-out from
> (call 'ls) and put it into a string  (setq str...) ?  THANKS.

(in '(ls) (read))

you might want something else than read

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

Re: Printed representation of (char 0) ?

[Tomas Hlavaty]

On Tue 13 Feb 2024 at 08:35, Thorsten Jolitz  wrote:
> But shouldn't hex 23232424 print to something like ##^N^N$$
> instead of

no

^N could mean SO character with byte value 14
see the program ascii

a NUL character would be displayed as ^@

> So the printed ASCII string (as char) carries all the information from the
> hex string, and can be converted back to the exact same hex string?

no, you are using wrong tool for the job

as Alex said, a picolisp string cannot contain NUL byte

> At least in some special cases when it's needed?

arbitrary binary data is not a string
parse the binary data properly

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

Re: Printed representation of (char 0) ?

[Tomas Hlavaty]

On Tue 13 Feb 2024 at 08:28, Thorsten Jolitz  wrote:
> But when I have a hexadecimal message string with fixed length, and the
> positions inside the string carry semantics? A certain value in a certain
> position has a meaning?

it is not a string, at least not in picolisp/C/unix sense

you need to properly parse the binary data into your own representation
and also write your own code to translate your own representation to
that binary data

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

Re: Printed representation of (char 0) ?

[Tomas Hlavaty]

On Tue 13 Feb 2024 at 00:25, Thorsten Jolitz  wrote:
> I would like to achieve a roundtrip like this:

why?

NUL is often a string sentinel value
so trying to use it as a character value
will lead to issues
do not do that

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

Re: Printed representation of (char 0) ?

[Tomas Hlavaty]

On Mon 12 Feb 2024 at 23:25, Thorsten Jolitz  wrote:
> Shouldn't the (char 0) representation print to something
> like ^N or so too, like (char 1), (char 2) etc?

^@

what are you trying to achieve?

why not use base64, for example?

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

Re: minipicolisp pointers

[Tomas Hlavaty]

On Sat 21 Oct 2023 at 12:26, C K Kashyap  wrote:
> By "call", I mean the regular PicoLisp "call", which is used to call
> external programs.

I see.  Maybe you could take the "call" function from the old full
picolisp which was in C.

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

Re: minipicolisp pointers

[Tomas Hlavaty]

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

Re: Hello from the bakery

[Tomas Hlavaty]

On Mon 14 Aug 2023 at 09:05, Abraham Palmer  wrote:
> I'm really a bread baker 

its fascinating how much IT stuff one needs to know to run a bakery

i like muffins but the link to picture of muffins is broken
https://boxturtlebakery.com/products/culturedmuffins.jpg

> my bakery in Python running against Google's Datastore database.

do your customers know and agree with their info being given to google?

> but the churn of research languages is
> just as bad with things breaking pretty much every year.

PicoLisp has the same problems, there are many "variants" and it is hard
to keep up.  That is why I am stuck with old 32 bit C variant.  But it
still works very well.

If you want something fossilized, try common lisp.

> tried Elm. It is very nice, but one is still very much embedded in the
> browser and JavaScript ecosystem and the churn of running things there
> is too much for me.

I thought Elm has stabilized now?

> I hope that that web approach of just using the browser for just the
> UI will keep things working on old and changing browsers without all
> the testing, polyfilling, etc.

Why is this good in case of PicoLisp and not in case of Elm?
Because you insist on doing the backend in the same language?

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

Re: An assembly question from the past

[Tomas Hlavaty]

On Thu 31 Mar 2022 at 15:25, Henry Baker  wrote:
> An aside: if one is executing on a 64-bit machine, how hard is it to
> execute a 32-bit 'application'? Can one easily start up a 32--bit
> thread inside a 64-bit machine?    This 32 inside 64 question is
> purely theoretical (for the moment)...

I use the 32 bit picolisp written in C.
It runs fine on amd64 machines with 64 bit GNU Linux
and also runs fine on 32 bit and 64 bit raspberry pi.

Alex wrote several picolisp implementations which have different
dependencies, for example:

- minipicolisp: minimal dependencies, less functionality

- 32 bit picolisp in C (the one I am using)

- pil64: 64 bit picolisp in assembly

- picolisp in java

- pil21: picolisp using llvm

There are other projects like bare metal picolisp or picolisp in fpga
but I haven't kept track of those.

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

Re: An assembly question from the past

[Tomas Hlavaty]

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

Re: quote form in picolisp

[Tomas Hlavaty]

On Thu 16 Dec 2021 at 21:48, Alexander Burger  wrote:
> 'quote' is the mother of all functions. It does nothing, and just returns 
> Args.
> No need for "special forms"!

Because there is no concept of compiler.
Compilation in picolisp is done ahead of time manually in another
language.

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

Re: wiki function: _render

[Tomas Hlavaty]

On Sat 11 Sep 2021 at 18:11, Jean-Christophe Helary 
 wrote:
>(prin "<" C D " id=\"h" D "-" E "\">")
> which would give us:
> My heading

What if the value of E is something like

   ">alert('xss');

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

Re: Enumerated Trees in PicoLisp

[Tomas Hlavaty]

On Thu 25 Mar 2021 at 12:23, Alexander Burger  wrote:
> On Thu, Mar 25, 2021 at 12:11:55PM +0100, Alexander Burger wrote:
>> Binary heaps are close, but not the same.
>
> And useless for the intended purpose. At least I see no way to insert and look
> up by number (?)

because you always take the position in the binary heap as the key.  if
picolisp had arrays, your use case would be reduced to trivial constant
time array lookup

but binary heaps can be much more useful if one can use a key which is
not a position in the binary heap

btw iirc representing trees this way was invented by a german guy a few
centuries ago, when he tried to draw those family trees so popular with
aristocrats

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

Re: Enumerated Trees in PicoLisp

[Tomas Hlavaty]

On Thu 25 Mar 2021 at 10:40, Alexander Burger  wrote:
> Probably this algorithm exists already, because it is so simple and obvious. 
> But
> I found it by myself and did not bother to search for it (mainly because I 
> don't
> know what name to search for).

binary heap

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sun 14 Mar 2021 at 09:34, Alexis  wrote:
> My guess is that Tomas is using the latter meaning, and wants 
> 'pure' functions that simply return strings, without sending them 
> to an output device. The final string to be output would be 
> created by combining the return values of multiple functions, 
> possibly performing transformations on them along the way, then 
> sending _that_ string to an output device. Is that correct, Tomas?

Pretty much, except instead of strings the values should be cons trees.
Strings do not "compose" but cons trees do.  Also with strings, the
structure is lost but cons trees preserve the structure making it
possible to know what exactly is being output and automatically escape
accordingly.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 21:13, Alexander Burger  wrote:
> On Sat, Mar 13, 2021 at 08:59:37PM +0100, Tomas Hlavaty wrote:
>> On Sat 13 Mar 2021 at 19:09, Alexander Burger  wrote:
>> > On Sat, Mar 13, 2021 at 06:48:22PM +0100, Tomas Hlavaty wrote:
>> >>(de  (Col . Prg)
>> >>   (prin "")
>> >>   (run Prg)
>> >>   (prin "") )
>> >> 
>> >> prin has side-effect.
>> >
>> > Nonsense! 'prin' *is* the only and desired effect.
>> 
>> see https://en.wikipedia.org/wiki/Side_effect_(computer_science)
>> for explanation what side-effect means
>
> I think I know what a side effect is ...
>
> But OK, "In computer science, an operation, function or expression is said to
> have a side effect if it modifies some state variable value(s) outside its 
> local
> environment".
>
> Please where does  have a side effect?

prin performs I/O

 calls prin

   Example side effects include [...] performing I/O or calling other
   side-effect functions.

> Again: This discussion is Kindergarten. I wonderhow many members of this list 
> we
> drive off.

hmm

> Haha, come on! Don't be picky! In this case 'Cls' is a simple class name.
> Garbage in garbage out.

Similar attitude have developers of beA - Das besondere elektronische
Anwaltspostfach - BRAK.  They do not escape their XML properly but use
string concatenations.  The result is that their XML responses are
invalid and I cannot use proper validating XML parser but have to
extract relevant data ad-hoc using text search.  And using this software
is mandated by German law!  I would not be surprised if the whole thing
is totally insecure.  Goodbye mandant/lawyer confidentiality.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 19:09, Alexander Burger  wrote:
> On Sat, Mar 13, 2021 at 06:48:22PM +0100, Tomas Hlavaty wrote:
>>(de  (Col . Prg)
>>   (prin "")
>>   (run Prg)
>>   (prin "") )
>> 
>> prin has side-effect.
>
> Nonsense! 'prin' *is* the only and desired effect.

see https://en.wikipedia.org/wiki/Side_effect_(computer_science)
for explanation what side-effect means

>> Col is not properly escaped!
>
> How so? It generates
>
>
>
> What kind if escape do you want?

( "\">") -> ">

which is invalid html.

>> So will I see the generated html in stderr?
>
> Sigh! Please think a little. I said the output goes to the current stream and
> debug info to stderr. Good old Unix style.

Exactly, so debug info will not show me the generated html which means
trace does not show me what I need.  Trace is useful for pure functions.
Trace is less useful for functions with side-effects because those
side-effects are not captured by trace.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 18:48, Tomas Hlavaty  wrote:
>  would be better written as:
>
>(de p @ (cons 'p (args)))

s/args/rest:

(de p @ (cons 'p (rest)))

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 19:09, Alexander Burger  wrote:
> On Sat, Mar 13, 2021 at 06:48:22PM +0100, Tomas Hlavaty wrote:
>>(de  (Col . Prg)
>>   (prin "")
>>   (run Prg)
>>   (prin "") )
>> 
>> prin has side-effect.
>
> Nonsense! 'prin' *is* the only and desired effect.

see https://en.wikipedia.org/wiki/Side_effect_(computer_science)
for explanation what side-effect means

>> Col is not properly escaped!
>
> How so? It generates
>
>
>
> What kind if escape do you want?

( "\">") -> ">

which is invalid html.

>> So will I see the generated html in stderr?
>
> Sigh! Please think a little. I said the output goes to the current stream and
> debug info to stderr. Good old Unix style.

Exactly, so debug info will not show me the generated html which means
trace does not show me what I need.  Trace is useful for pure functions.
Trace is less useful for functions with side-effects because those
side-effects are not captured by trace.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 16:04, Alexander Burger  wrote:
> I don't get your problem with side effects!

in your example:

   (de  (Col . Prg)
  (prin "")
  (run Prg)
  (prin "") )

prin has side-effect.

Col is not properly escaped!

This example:

   (de  Prg
  (prin "")
  (run Prg)
  (prin "") )

These functions output the formatted html immediatelly, which is too
early for reasons I wrote about already.

 would be better written as:

   (de p @ (cons 'p (args)))

This has no side-effects.  It also allows me to postpone serialisation
to a better point in time, when I call a function called html.  Similar
to xml function in picolisp, this html function serializes cons tree
into a stream with html syntax.  This way I never have to care about
escaping and other issues.  Separating p, div etc and html function
opens new possibilities.

> Why do you open new issues like like SVG and PDF generation, when the
> task is to print a page to to a socket?

Because cons trees can brilliantly represent pretty much anything, from
lisp code to html, xml, svg, pdf, docx, odt, der, json etc.  You can
easily construct them, pretty-print them, trace them, transform them and
serialize them.  Picolisp way of implementing  has fundamental flaws
which the cons tree approach solves elegantly.

>> > If you want output with a pre-calculated width, you can still do it in the
>> > FEXPR.
>> 
>> Not pre-calculated.  The bounding box is known after the thing is drawn.
>
> That's trivial. Just calculate while printing then.

That does not work, because with and height are not known yet at that
time!  They are known after the printing is finished, which is too late.

>> If my code outputs html to /tmp/a.html and I trace it, where would the
>> arguments and return values be written to?  Where would the side-effect
>> be written to?
>
> I already explained that tracing goes to stderr.

So will I see the generated html in stderr?

If yes then /tmp/a.html is empty and tracing breaks my program.

If no then stderr will not contain the generated html and tracing is
useless.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 15:03, Alexander Burger  wrote:
> On Sat, Mar 13, 2021 at 02:09:30PM +0100, Tomas Hlavaty wrote:
>> Avoiding allocations is wrong thing to do for this use-case.  Printing
>> directly is severely inconvenient.  Do you have a neat solution to the
>> svg viewBox problem I wrote about?
>
> You are talking about a different problem domain. Width calculations
> were not an issue in that discussion.

I am talking about an example which shows how inconvenient the standard
picolisp your solution with side-effect is.

Yet another example, writing out pdf.
https://logand.com/sw/emacs-pdf/file/emacs-pdf.el.html#l110 creates cons
tree and implements insert-pdf function to serialize it in the right
format.  One of the issues here are pdf object references, which need to
output "before" being known, making side-effect solution unuseable.

Cons trees and garbage collection are one of the best things about lisp.
Trading allocations for side-effects is a bad trade off.

> If you want output with a pre-calculated width, you can still do it in the
> FEXPR.

Not pre-calculated.  The bounding box is known after the thing is drawn.

> But if you insist, just switch function pointers to do width
> calculation instead of printing. Given our example
>
>(de  Prg
>   (prin "")
>   (run Prg)
>   (prin "") )
>
>(de  (Col . Prg)
>   (prin "")
>   (run Prg)
>   (prin "") )
>
> we add a width-calculating function for each tag:
>
>(de pWidth Prg
>   (+ 3 (run Prg) 4) )
>
>(de divWidth (Col . Prg)
>   (+ 12 (length Col) 2 (run Prg) 6) )

Why separate and duplicate functions.  What if the drawing is not so
trivial?  This is not a good solution.  Generally, I want to update *W
and *H during arbitrarily complex drawing without all those extra
functions you suggest.

> Note that this again does not produce a single cell. Optimal.

So optimal means writing to a file is cheaper than consing a cell?  I am
not convinced.

> I do not understand. We are talking about the 'trace' of function calls for
> debugging, showing whe called function, and its arguments, then recursively
> indented the trace of sub-function calls, and then the return of the function
> and its value, right? Works fine with FEXPRs.
>
> 'trace' prints to stderr, so it does not interfer with other printing.

If my code outputs html to /tmp/a.html and I trace it, where would the
arguments and return values be written to?  Where would the side-effect
be written to?

>> In reality it is misoptimisation because it optimizes for irrelevant
>> advantage of no allocation but it severely criples what one can do.
>
> No. It cripples nothing. It is the most powerful concept. You can
> express anything with it.

I am not disputing that FEXPRs are the most powerful concept.

I am saying that using it for html output is using wrong tool for the
job.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 14:09, Tomas Hlavaty  wrote:
>> But the FEXPR solution explained at PilCon allocates no new cells at all. It
>> prints directly.
>
> Avoiding allocations is wrong thing to do for this use-case.  Printing
> directly is severely inconvenient.  Do you have a neat solution to the
> svg viewBox problem I wrote about?

Another example:  you have to be careful not to get an error in the
middle of the side-effect otherwise you get partial output.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 13:33, Alexander Burger  wrote:
> It does. Just the syntax is different:
>
>(de  (@Str) (fill '(p @Str)))
>
> This also creates just 2 cells.

True, I forgot about fill.

> But the FEXPR solution explained at PilCon allocates no new cells at all. It
> prints directly.

Avoiding allocations is wrong thing to do for this use-case.  Printing
directly is severely inconvenient.  Do you have a neat solution to the
svg viewBox problem I wrote about?

> Also, needing two separate functions for every HTML function is ugly, tedious
> and error-prone.

Not sure what do you mean.  There would be only one function, lets call
it html which takes a cons tree and prints it using html syntax.
Opposite of tedious and error-prone.  Similar to the xml function in
picolisp.

> Side-effects like printing? No problem! In PicoLisp, you can trace,
> break and single-step FEXPRs (with or without side-effects) like any
> other function (unlike macros in e.g. Common Lisp).

You can trace it but the trace does not show the side-effect thus making
trace useless.

>> Using FEXPRs for html output is misoptimisation.
>
> Wrong.

In reality it is misoptimisation because it optimizes for irrelevant
advantage of no allocation but it severely criples what one can do.

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

Re: FEXPRs / PilCon

[Tomas Hlavaty]

On Sat 13 Mar 2021 at 08:27, Alexander Burger  wrote:
>(de  Prg
>   (prin "")
>   (run Prg)
>   (prin "") )
>
> [...]
>
> One question that came up was why FEXPRs could not be replaced with normal
> functions (EXPRs), simply 'pack'ing strings:
>
>(de  (Str)
>   (pack "" Str "") )
>
> [...]
>
> While this would surely work, I answered that it is a big overhead to
> generate the whole page as strings just to print them.

Packing strings is not a good idea.

It would be much better to create a cons tree instead, something like:

(de  (Str) `(p ,Str))

and have a separate function to print the cons tree into a stream
formatted as html.  Notice how little memory such  function allocates
-- 2 cons cells -- compared to the version with pack.

Unfortunatelly, picolisp does not have a convenient way of creating cons
tree templates with backquote.

> But I forgot to explain: The real reason for FEXPRs goes beyond that. They 
> have
> the power of passing executable code bodies, with arbitrary flow control, to 
> the
> function.

This also nicely shows how the power of FEXPRs can easily lead one
astray.

For example:

(let (*X NIL *Y NIL)
   (draw-svg-thing-and-determine-width-and-height)
   `(svg (@viewBox "0 0 " ,*W " " ,*H) ...))

The above will not work when  is not pure and does side-effect write.
One has to draw it twice, once to /dev/null to determine width and
height and then second time inside the three dots.

When draw-svg-thing-and-determine-width-and-height is pure and returns
cons tree, it does not need to be called second time but the return
value can be used inside the three dots.  If consing and garbage
collecting a cons tree is cheaper than calling
draw-svg-thing-and-determine-width-and-height once again, it is already
a win.

Another drawback is that side-effects break tracing and make debugging
much harder.

Using FEXPRs for html output is misoptimisation.

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 12:09, Alexander Burger  wrote:
> On Sun, Nov 22, 2020 at 11:49:11AM +0100, Tomas Hlavaty wrote:
>> it is only mess because you really want to find a loophole
>
> I don't want to find a loophole. I leave everything as it is (MIT/X11). I just
> want to point out how nonsensical it all is.

why is tomato vegetable?

why is it allowed to shoot welschman with bow and arrow in chester after
midnight?  (this one is actually funny
<https://www.cheshire-live.co.uk/whats-on/no-you-cant-you-shoot-16302109>)

why are some people systemrelevant?

why is football allowed and music not?

why can viener filharmonie go for a concert tour to japan and be
excluded from corona rules?

why is Grundgesetz worked around again?

   Bund und Länder dürfen mit einfachen Rechtsverordnungen in
   grundrechtliche Freiheiten eingreifen – ohne Vorbehalt des
   Parlaments.  Angekratzt ist auch eine weitere Hoheit des Bundestags:
   das Budgetrecht.“

i don't think laws are meant to make sense

> I would rather re-activate and perhaps rewrite the old lib/led.l

this seems like a reasonable solution

> I don't care what RMS says. He is a docmatic actually *restricting*
> freedom.

i'd rather discuss ideas than people

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:16, Alexander Williams  wrote:
> Tomas, you're allowed to relicense the MIT version of PicoLisp you 
> received, as GPLv3, as long as you maintain the MIT license text.

what about customers that ban GPL on their machines?

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:12, Davide BERTOLOTTO  
wrote:
> Right, but apparently nobody went to court for such topics, so it is still
> gray zone.

what if i don't want to risk going to court because of this?

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 11:23, Alexander Burger  wrote:
> On Sun, Nov 22, 2020 at 11:03:31AM +0100, Alexander Burger wrote:
>> In my understanding it is irrelevant how the library is linked, or the fact 
>> that
>> pil21 "depends" on it
>
> This is all such a mess! What is "linking" other than calling external code at
> runtime?
>
> In pil you can call any other library at any time with 'native'. At that 
> moment
> the library gets linked. How should we prevent that?

it is only mess because you really want to find a loophole

> Or calling a GPLed program with (call "program" "arg" ...). This is 
> functionally
> also equivalen to linking, as it "uses" the code in another program.

it is completely different

otherwise you could use rlwrap as already suggested and call it a day

and you already clearly explained, why rlwrap is not an option iirc

> If 'native' does not violate the GPL, then pil21 could be rewritten to use
> 'native' to call the readline API.

this is what Stallman said to Haible:

   The FSF position would be that this is still one program, which has
   only been disguised as two.  The reason it is still one program is
   that the one part clearly shows the intention for incorporation of
   the other part.

   I say this based on discussions I had with our lawyer long ago.  The
   issue first arose when NeXT proposed to distribute a modified GCC in
   two parts and let the user link them.  Jobs asked me whether this was
   lawful.  It seemed to me at the time that it was, following reasoning
   like what you are using; but since the result was very undesirable
   for free software, I said I would have to ask the lawyer.

   What the lawyer said surprised me; he said that judges would consider
   such schemes to be "subterfuges" and would be very harsh toward them.
   He said a judge would ask whether it is "really" one program, rather
   than how it is labeled.

   So I went back to Jobs and said we believed his plan was not allowed
   by the GPL.

   The direct result of this is that we now have an Objective C front
   end.  They had wanted to distribute the Objective C parser as a
   separate proprietary package to link with the GCC back end, but since
   I didn't agree this was allowed, they made it free.

   So I don't think the GPL actually requires a correction for this.
   But perhaps it would be a good idea to add a note explaining this.

you are not the only one trying to find loopholes in GPL.
you should read why clisp is under GPL.

another thought experiment: say my customers ban GPL software on their
machines.  0 GPL there.  would i be able to use pil21 for those
customers?  no because pil21 needs GPL software.

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 09:59, Davide BERTOLOTTO  
wrote:
> In my personal opinion it will be okay if we use the readline library in
> pil21, since it is a *library* and we are not making a 'derivative' work
> out of it

this is wrong

there is exactly the same precedent already, see clisp
https://raw.githubusercontent.com/JoshCheek/clisp/master/doc/Why-CLISP-is-under-GPL

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

Re: Licence Dilemma

[Tomas Hlavaty]

Hi Alex,

On Sun 22 Nov 2020 at 09:22, Alexander Burger  wrote:
> Yes, I want pil21 as a piece be completely "free", in the spirit of MIT.

then it cannot depend on GPL library

>>From what I underseod so far, the GPL is all about "distributing". PicoLisp 
>>does
> *not* distribute any GPLed code (neither source nor binary), but "uses" what 
> it
> finds on the target system at runtime and just *calls* it by creating a 
> dynamic
> link. Am I wrong?

why would that be relevant?

if you combine MIT and GPL software in the same process, the combined
work must conform to GPL

if you want the combined work not to conform to GPL, do not use GPL
software in the same process

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 07:00, Alexander Burger  wrote:
> It is not even linked at *compile* time, but - dynamically - at runtime
> (shared library).

i don't think this makes any difference

the question is: does pil21 depend on GPL software?  if yes, the
combined work has GPL licence.  if not, pil21 has MIT licence.  if you
load GPL library, the combined work is GPL.  that's why LGPL exists iirc

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

Re: Licence Dilemma

[Tomas Hlavaty]

On Sun 22 Nov 2020 at 01:32, Alexander Williams  wrote:
> Not a lawyer here, but PicoLisp 21 does **not** need to be GPL'd.

it does not because it is already compatible with GPL

> Everyone seems to confuse "linking to a GPL'd library that exists on the 
> host computer" VS "linking to a GPL'd library that's included with the 
> source code".
>
> Please stop mixing these things.

strange, i don't think that's right

> If you don't have libreadline on your system, you can't compile pil21.

this means that pil21 depends on GPL software

and the combined work is licensed under GPL

> Finally, it is also possible for PicoLisp to be "dual-licensed" under
> GPL and MIT, allowing the recipients to choose which license applies
> to them, but that solves nothing since MIT is already compatible with
> GPL. People would normally dual-license for commercial reasons, or
> when the license isn't compatible with GPL.

this does not solve the issue because of the above

even though pil21 is MIT licensed, the GPL dependency makes the combined
work GPL licensed

if i understand the raised issue correctly, alex wants the combined work
to be MIT licensed, which means pil21 cannot depend on GPL software

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

Re: httpGate for non-picolisp apps

[Tomas Hlavaty]

Hi Alex,

On Sat 29 Aug 2020 at 09:22, Alexander Burger  wrote:
>> This could be fixed by adding a fallback case to httpGate.
>
> httpGate does have such a fallback: If a file (or symbolic link) named "void"
> exists, it is sent as a reply for terminated sessions. It may contain 
> anything,
> e.g. a redirect to the application's login page.

thanks, this is good to know as this didn't exist when I needed it.

Where should such file or symlink exist?  Do you have an example?

Cheers,

Tomas

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

Re: httpGate for non-picolisp apps

[Tomas Hlavaty]

Hi Grant,

On Sat 29 Aug 2020 at 01:04, Grant Shangreaux  wrote:
>> I suspect other apps cannot handle this.
>
> i thought this was probably the case. just wondered if someone out
> there may have tried and come up with a solution already :)

unfortunately, httpGate has a fatal flaw: when a session ends, users end
up with a dead url.  You have to train your users to know what to do in
such situation.

This could be fixed by adding a fallback case to httpGate.

Or simply use a different server, where this is easier to do already.
For example, see nginx config with fallback described here
https://logand.com/blog/picolisp-behind-nginx-proxy.html

Cheers

Tomas

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

Re: cells in picolisp [tutorial, slides]

[Tomas Hlavaty]

nice presentation

andr...@itship.ch writes:
> Hi George, You know you can display PDFs also in 'presentation mode' ?
> Depends on the PDF reader software, but most can do that.

For example, open the PDF in Emacs after installing pdf-tools.  Press P
for fit to page.  Press n for next page, p for previous page.  It is the
best PDF viewer I know so far.

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

Re: native/lisp in picolisp32

[Tomas Hlavaty]

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

[Tomas Hlavaty]

Hi Alex,

> I always used the Jitsi Meet app on Android for audio and video, and sometimes
> additionally Firefox on a Debian PC to demonstrate things on a shared
> screen.

firefox sounds good

Yesterday I tried to watch the Lisp conference but streaming kept
stopping so I had to give up.  Not sure if it was server side issue with
twitch.tv or because of poor internet in Berlin.  If you do a trial run
in advance I should try joining in.

Tomas

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

Re: PilCon 2020

[Tomas Hlavaty]

Hi Alex,

Alexander Burger  writes:
> I think we will also have to cancel the other large event, PilCon. It is not
> sure whether such events will be allowed legally by end of July, and how the
> international travel situation will be.

makes sense.  Thanks for letting us know.

> Would it make sense to plan an online conference instead? We are playing 
> around
> with Jitsi Meet currently. Any thoughts?

I tried Jitsi and it seems broken on NixOS (throwing some Java exception
about a DNS class not found).

Does Jitsi also work in Firefox?

Or another sip client, e.g. linphone?

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

thanks for the links

> With nuclear energy, there came a requirement for more
> authoritarianism, stronger vertical power structures. Why?  Because
> the potential for damage is huge. See, for example, the radioactive
> boy scout, David Hahn [6].  I do recall that there was some similar
> incident in Europe, but couldn't easily find the reference.  Besides
> requiring more authoritative power, nuclear energy is also related to
> several disasters, and there is thenuclear waste problem.

I once talked to a random guy on my flight from Wien to Tokyo who
happened to be travelling from an International Atomic Energy Agency
meeting.  He was working for the Japanese government as a regulator
trying to restart Japanese nuclear powerplants.  He was annoyed about
opposition from local people.  He worked for Toshiba in his previous
job.  (regulating his previous self?)  The Westinghouse fiasco did not
bother him too much, just commented that there was an avoidable issue
with the contract.

I think the problem with nuclear is more human than technical.  It is
the problem of corruption, likely due to such level of centralisation,
concentration of power, scale and magnitude of possible damage, as you
suggest.

I remember reading about another guy from Hitachi working on the steel
containment vessel.  It was a good read.  Found it:
http://www.bloomberg.com/news/2011-03-23/fukushima-engineer-says-he-covered-up-flaw-at-shut-reactor.html

Also "solving" the problem of nuclear waste by shiping it to Mongolia
speaks for itself:
http://www.reuters.com/article/2011/05/09/energy-nuclear-mongolia-idUSL3E7G80HD20110509

It is a shame, really.

We did cycle today to see sakura blossom in Berlin and it was amazing.
Clean air, clear sky, no airplains...  I wish we had clean energy.

>  With LibreCMC

interesting

I use openwrt on some routers.

Do you run picolisp on librecmc or openwrt?  which picolisp?

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Guido Stepken  writes:
> Well, perhaps you could find a few papers about "Frank" at Viewpoint
> Research homepage. Bert Freudenberg, Ian Piumarta, Alan Kay certainly have
> the full "Frank" code.

I might have heard something about that research.  Probably related to
that concise vector graphics library.

> But this is not the point. The point is, that MetaCola was a code
> generator, where you can implement whole programming languages within just
> a few lines of code. What you're seeing here is an OMeta (a MetaCola
> descendant) Lisp interpreter.
>
> http://www.tinlizzie.org/ometa-js/#Lisp
>
> What you're seeing here is the complete Lisp machine!!!
>
> OMeta Parser/Interpreter has been translated into many programming
> languages and is used almost everywhere now to implement DSL (Domain
> Specific Languages). Here a Common Lisp Implementation with OMeta:
>
> 153 Lines of OMeta code:
>
> https://github.com/thiago-silva/cl-ometa/blob/master/src/ometa-parser.g
>
> Means: What you're seeing there, that's the *complete* Common Lisp parser
> and Interpreter ...

interesting

common lisp has a programable reader and does not really have syntax to
be parsed

> I use it all the time, not only to implement new languages, compilers, but
> also to design my own FPGA and ASIC CPUs, my compilers then are generating
> code for. I directly parse any programming language with OMeta and
> transpile to VHDL. Only a couple of minutes later i can upload my "CPU of
> choice" onto my FPGA board.
>
> The complete toolchain (parser, lexer, compiler) is automatically
> generated. And after running a couple of tests i can handover everything to
> my customer(s).
>
> I almost completely stopped writing code in any programming language by
> hand, since there is not a single problem that cannot be solved with OMeta
> .. New is, that you also can generate your own CPU (implemented in FPGA or
> much faster ASIC) and compiler, tools in one go. ASICs go up to 10 GHz
> clock frequency, ultra fast!

fascinating

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Tomas Hlavaty  writes:
> Guido Stepken  writes:
>> Using US software stacks, even if open source and under a free license are
>> not tolerable. For any nation, for any kind of project.

> Where can I learn more about your work?

probably here:

   https://stepken.blogspot.com/

hidden behind javascript wall and here:

   https://plus.google.com/+GuidoStepken/

also not securely accessible

(and both US software stacks)

shame, I'd love to learn something about your ideas
but this is impossible without javascript

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Jo-To Schäg  writes:
> However the PicoLisp community does not like to solve problems for
> other people.  Especially if it is motivated for political reasons.
> Do not expect Alex to spend his time on satisfying your paranoia or
> political motivations.

Where I live we had freedom of movement for about 30 years.  Now for the
first time since the fall of communism, the borders closed.  In many
countries power is getting more centralised and many governments are
regressing back to authoritarianism.

I think he raises important points which will be even more important in
the (probably near) future.

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Alexander Burger  writes:
> In case of pil21, where is the problem?

> llvm assembler to convert to machine code

  ^
  I think he is pointing here

> Do you seriously believe the libraries contain backdoors?

I don't think he said anything like that.

My understanding is that he said that llvm is not reasonably reviewable
and that it is under control of people with questionable reputation and
that it poses potentially serious risk which he does not want to take.

The problem with trust is that it is not transitive.  I might trust
Alex, Alex might trust llvm but that does not mean I trust llvm.

> They would be detected very quickly.

If you take the optimistic point of view, you can certainly ignore the
issue completely.

Detection can take years or decades if at all, then somebody needs to
find a way to fix it if there is a will to fix it at all and then
actually fix it and then make sure it does not happen again.

> The generated machine code and runtime behavior I debug and observe
> permanently.

Because you observe software does not mean it does not contain so far
unobserved behaviour.  Also iirc that famous C guy had a talk about
backdoors in compilers.  Interesting stuff.

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Guido Stepken  writes:
> That group implemented a whole operating system in MetaCola language within
> 20.000 lines of code only. GUI, TrueType Fonts, mouse, keyboard driver ...
> everything included, called "Frank" for Frank - enstein.

interesting, where can I learn more?

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Guido Stepken  writes:
> Picolisp, thanks to Alex' brilliant ideas, behind the scenes, serves as
> prototype of a new kind of "minimalistic, highly efficiency" software
> strategy within the EU. Goal is: Back to the roots, small modules, security
> review everywhere, minimal hardware requirements, driving down energy
> consumption massively.

does EU fund Picolisp as part of the software strategy?

If not, why and how could that be achieved?

Where can I read about the EU software strategy?

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

Hi Guido,

Guido Stepken  writes:
> Using US software stacks, even if open source and under a free license are
> not tolerable. For any nation, for any kind of project.
>
> US Cloud Act, Patriot Act, by law, force US companies as well US
> organisations in general, such as Linux Foundation as well as Apache
> Foundation and LLVM Foundation to comply with US law.

is using google mail tolerable?

> And i can assure you: My influence is **much bigger** than you might think!
> Stop that, immediately!

You raise interesting points.

Where can I learn more about your work?

Cheers

Tomas

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

Re: Stop using US controlled software stacks!!!

[Tomas Hlavaty]

andr...@itship.ch writes:
> I have to disagree with your tone.

I empathise with his tone.

This issue is frustrating.

Just this week a friend of mine was told by her employer to install
whatsapp so that they can keep her updated about the suspended work due
to the pandemic.  I told her about the downsides and possible
alternatives.  She did install whatsapp on her private phone in the end.

I see the same problem everywhere and it's very hard not to ignore the
downsides because e.g. I won't pay her bills.

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

Re: PicoLisp Sources

[Tomas Hlavaty]

Hi Alex,

interesting.  Thanks for explanation.

Tomas

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

Re: PicoLisp Sources

[Tomas Hlavaty]

Hi Alex,

interesting.

Alexander Burger  writes:
> Now in pil21 the source is (in "src/subr.l"):
>
># (car 'var) -> any
>(de _car (Exe)
>   (car (needVar Exe (eval (cadr Exe )

 ^
what is this car?

Tomas

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

Re: Did you know? Webassembly Containers are (Pico-)Lisp machines!

[Tomas Hlavaty]

Rowan Thorpe  writes:
> parentheses are not used because as is stated at
> https://picolisp.com/wiki/?src64 "Assembly language is not a
> functional language, i.e. the individual instructions do not "return"
> a value. So a fully parenthesized syntax is useless and just tedious."

because picolisp doesn't have a compiler (program)

it is "compiled" to the picolisp assembly manually ahead of time by Alex
(human)

once you have a compiler (lisp program), parenthesis make sense because
they simply show lisp datastructures manipulated by the compiler

you can write lisp without parenthesis in similar spirit (see common
lisp loop for example) but that is rather "ugly"

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

Re: Installation and update

[Tomas Hlavaty]

On NixOS, picolisp has been available out of the box on 32 and 64 bit
intel and arm:

$ nix-shell -p picolisp

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

Re: Version 17.12 question / error

[Tomas Hlavaty]

Henrik Sarvell  writes:
> I should probably create a small writeup on how to do that
> for a typical PL project listening on a non standard port.

https://logand.com/blog/picolisp-behind-nginx-proxy.html

from 22sep2009, time flies!

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

Re: Let's Encrypt Expiry

[Tomas Hlavaty]

I got these emails too and everything worked well for me.
The email also said:

   For details about when we send these emails, please visit
   https://letsencrypt.org/docs/expiration-emails/. In particular, note
   that this reminder email is still sent if you've obtained a slightly
   different certificate by adding or removing names. If you've replaced
   this certificate with a newer one that covers more or fewer names
   than the list above, you may be able to ignore this message.

Maybe added or removed names?

It looks like picolisp.com was renewed on 2017-05-21, see
https://crt.sh/?q=picolisp.com

Tomas

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

Re: Header parsing

[Tomas Hlavaty]

What about using Maildir on the email server?  Then you don't have any
issues with parsing and locking the spool file.

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

Re: PicoLisp on Ubuntu

[Tomas Hlavaty]

Hi Jon,

> My old Mac mini has an Intel Core 2 Duo, and that is supposed to be a
> 64-bit machine. However, when I should pick the Ubuntu version for
> this Mac from this page http://www.ubuntu.com/download/desktop both
> the drop-down menus says "32-bit — for machines with less than 2GB
> RAM". That is what I picked, and I am afraid that prevents me from

you can try "uname -a" or "cat /proc/cpuinfo" to find out more about the
machine architecture.

Cheers,

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

Re: PicoLisp on Ubuntu

[Tomas Hlavaty]

Hi Jon,

> model name: Intel(R) Core(TM)2 CPU T7200  @ 2.00GHz

the processor is 64 bit:
http://ark.intel.com/products/27255/Intel-Core2-Duo-Processor-T7200-4M-Cache-2_00-GHz-667-MHz-FSB
so it should be possible to install 64 bit linux.

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

Re: Trying to build pil64 on Raspberry Pi

[Tomas Hlavaty]

Hi Jon,

> just wanted to try if 64-bit PicoLisp could run on this Pi Zero, but I

Pi is 32 bit.  64 bit picolisp doesn't work there.  You could try
ersatz.  32 bit picolisp works, you just need to fix makefile manually
yourself.  If you search this mailing list, you'll find out how to
achieve this.

Cheers,

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

Re: Hosting PicoLisp

[Tomas Hlavaty]

Hi Christophe,

Christophe Gragnic  writes:
> My host of choice is quite nice but doesn't allow me to run my own
> processes. Everything must live behing Apache.  I guest most people on
> this list run their own servers but maybe you'll have some answers to
> these two questions: 1) Is it possible to serve a PicoLisp app behing
> Apache?  2) Do you know a web host where we can easily deploy a
> PicoLisp app?

It is possible to run picolisp app behind apache.  You just need to
configure apache so that the request are proxied to the port opened by
your picolisp app.

You might look for VPS hosting, where you get a whole virtual machine
with root access and you can setup things the way you like.  It is
possible to rent such machines for about 5 EUR/month these days, which
should be more than enough for any picolisp app.

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

Re: picolisp in nix

[Tomas Hlavaty]

Hi Mattias,

Mattias Sundblad  writes:
> I believe you can look at http://software-lab.de/doc/ChangeLog to
> check for new versions?

good idea, I could just poll the first line of the link for changes.

Thank you,

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

Re: picolisp in nix

[Tomas Hlavaty]

Hi Alex,

Alexander Burger  writes:
> Yes, I've announced it always in Twitter. I'm planning a new release in
> about a month or so.

i see.  Unfortunatelly, I don't read twitter.  If it is not too much
duplicated work, would it be possible to send announcements to this
mailing list?

Thank you,

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

Re: low level VM and disassemble

[Tomas Hlavaty]

Hi Erik,

one of the immediate steps for pil64 compilation goes through asm file.
You can study that.  Otherwise picolisp doesn't have a disassembler and
it also doesn't have a compiler.

Cheers,

Tomas

Erik Gustafson erik.d.gustaf...@gmail.com writes:

 Hi List,

 I'd like to develop a better intuition for how things work in
 the lower levels of 64bit PicoLisp, how cells are passed between
 registers, and all that. I need to spend more time with the code
 in /src64 and going over the docs, obviously. Any other ways you
 all have found to be effective in developing that sense? 'trace'
 and 'debug' have been very helpful, but they seem to operate on
 a higher level. 

 I imagine something like CL's 'disassemble' that, given an
 arbitrary lisp expression, returns the sequence of VM
 instructions the expression maps to. Would something like this
 be possible to implement? If so, where might be a good place to
 start exploring? 

 Or is this another existing feature that I've managed to miss
 this whole time? :) 

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

compiling on arm

[Tomas Hlavaty]

Hi Alex,

I am trying to compile the latest picolisp 3.1.10 on 32 bit ARM.

I remember I sent a patch fixing ARM compilation a while ago but that
wasn't accepted, because the aditional cases would make the Makefile
ugly.

I ca fix it quickly simply by calling

   (cd src ; sed -i s/-m32//g Makefile)

but then I get another error which I don't remember seeing before:

   gcc -o ../lib/ext -shared -export-dynamic ext.o  -lcrypt
   /nix/store/gkg7ha29gwl5vci9khk1x86zhbc6ayc7-binutils-2.23.1/bin/ld:
   ext.o: relocation R_ARM_MOVW_ABS_NC against `Nil' can not be used when
   making a shared object; recomp\ile with -fPIC
   ext.o: could not read symbols: Bad value
   collect2: error: ld returned 1 exit status
   Makefile:151: recipe for target '../lib/ext' failed
   make: *** [../lib/ext] Error 1

So my questions:

1) is it ok to simply compile everything with -fPIC?  E.g. fixing the
   makefile by calling

   (cd src ; sed -i s/-m32/-fPIC/g Makefile)

   or the picolisp binary should not be compiled with -fPIC?

2) How do I run the picolisp test suite to verify, that the build is
   successful?

Thanks a lot,

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

pil keeps parent shell around

[Tomas Hlavaty]

Hi Alex,

is it expected that calling pil keeps the parent shell process around?

tomas@x ~ % pstree | grep pi
 |  |-zsh---pil---picolisp

I can see pil in the process list but I would prefer if it was replaced
by the picolisp process (aka shell exec).

Thank you,

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

Re: compiling on arm

[Tomas Hlavaty]

Hi Alex,

 I am trying to compile the latest picolisp 3.1.10 on 32 bit ARM.
 
 I remember I sent a patch fixing ARM compilation a while ago but that
 wasn't accepted, because the aditional cases would make the Makefile
 ugly.

 Really? When was that? Please excuse my bad memory .. ;)

I managed to find those emails now:

https://www.mail-archive.com/picolisp%40software-lab.de/msg03802.html
https://www.mail-archive.com/picolisp%40software-lab.de/msg03434.html

 1) is it ok to simply compile everything with -fPIC?  E.g. fixing the
makefile by calling
 
(cd src ; sed -i s/-m32/-fPIC/g Makefile)
 
or the picolisp binary should not be compiled with -fPIC?

 I would say that this is not right. The PIC flag (position independent
 code) is - as I understand it - needed for the shared object libraries
 (lib/ext and lib/ht), but not for the base system. But, on the other
 hand, this is a matter of the system. On Mac OS, for example, position
 independent code seems to be always necessary.

Ok, so -fPIC does not break anything.

 2) How do I run the picolisp test suite to verify, that the build is
successful?

 This is an easier question. It is, BTW, also noted in the test file
 @lib/test.l itself:

### Unit Tests ###
# Local usage:
# ./pil lib/test.l $(/bin/pwd) -bye +

# Global usage:
# pil @lib/test.l $(/bin/pwd) -bye +

 If something goes wrong, it stops in an error break. Otherwise it simply
 prints OK.

Thanks for this.

What do I need to do for it to exit with non-zero exit code?

It would be nice if it was also available as a make check target for
more traditional convention.  That way people could run the tests
without having to think about it too much:-)

 I am trying to compile the latest picolisp 3.1.10 on 32 bit ARM.

 You could also take a look at how Debian (Kan-Ru Chen?) is doing it.

Ok.  But it is a shame that compiling picolisp doesn't work out of the
box, especially when it is easy to achieve.

 I'm using PicoLisp on my Kobo E-Book reader, which has an ARM
 CPU. Works perfectly out of the box with apt-get install picolisp :)

You obviously never compiled it yourself and rely on debian instead.

I dont have debian on my ARM machine, so I have to duplicate the fixing
effort.

Thank you,

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

Re: pil keeps parent shell around

[Tomas Hlavaty]

Hi Alex,

  tomas@x ~ % pstree | grep pi
   |  |-zsh---pil---picolisp
  
  I can see pil in the process list but I would prefer if it was replaced
  by the picolisp process (aka shell exec).
 
 This can be done with the (surprise!) 'exec' function
 
http://software-lab.de/doc/refE.html#exec

 On the other hand, if you need to use (fork) 0 for example because you
 want to inherit something from the parent pil process to the child - you
 can simply (bye) in the parent after forking the child.

my question is about the bin/pil shell script.  Thinking about it now,
this script is not for production iirc, so an extra shell process is not
a problem actually.

Thank you,

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

Re: https server side

[Tomas Hlavaty]

Hi Luis,

PicoLisp comes with httpGate, which is a http and https proxy using
openssl library.  It is usually run on port 80 and proxies connections
to PicoLisp processes.  I don't remember the exact command line
arguments.

I don't use httpGate, but use nginx instead, see
http://logand.com/blog/picolisp-behind-nginx-proxy.html

Cheers,

Tomas

Luis P. Mendes luisl...@gmail.com writes:

 Hi,


 I couldn't find anything about the support of https in server side in
 'Picolisp by Example' and in 'Picolisp Works' books.
 But, there's a thread
 http://t8373.lisp-picolisp-general.lispforum.info/picolisp-ssl-problem-t8373-20.html
 that seems to imply that https/SSL has been implemented.
 So my question, can a https server application be build in Picolisp
 with a certificate signed by some CA?
 If so, what part of the documentation am I missing?

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

Re: Installation issues

[Tomas Hlavaty]

Hi Lawrence,

 alias pil='~/opt/picoLisp/pil +'

 This works fine from shell; starts up REPL However emacs can't
 start the REPL (run-picolisp):

 Searching for program: no such file or directory, pil

 What can I do to make emacs see ~/opt/picoLisp/pil  ?

have you tried

   alias pil=~/opt/picoLisp/pil

i.e. just the path to the program?

Cheers,

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

Re: PicoLisp roots

[Tomas Hlavaty]

Hi Jerome

a good starting point is http://software-lab.de/doc/tut.html

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Christophe,

 Christophe Gragnic christophegrag...@gmail.com writes:
 It should be possible to
 find the original values from another instance of picolisp, for example.

 Is it always possible?

try it:

in 1st console:

$ ~/picoLisp/p
: call
- 267631
: ^d

in 2nd console:

$ ~/picoLisp/p
: call
- 267631
: ^d

The number is the same.

If you bind 'call' to NIL, I could (setq call 267631) and revert your change.

 Or simply call something that crashes PicoLisp, e.g.
 […]

 Here comes the power of embedded interpreters, which PicoLisp
 does not have.

Well, you could write one in PicoLisp!  It should not be that hard and
you would have a complete control over what you allow to be executed.

Cheers,

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

Re: Swimming against the tide, again (this time with numbers)

[Tomas Hlavaty]

Hi Christophe,

 Christophe Gragnic christophegrag...@gmail.com writes:
 is my suggestion:
 «…by multiplying with (or dividing by) the scale factor.»
 could become
 «…by multiplying with (or dividing by) the scale factor, which is always 
 `1.0`.»

it doesn't have to be always 1.0.  If it was, it would not need to be
there at all.

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Christophe,

 Christophe Gragnic christophegrag...@gmail.com writes:
 On Sat, Aug 30, 2014 at 11:31 AM, Tomas Hlavaty t...@logand.com wrote:

 Executing a script doesn't mean every line will work as expected!
 `rm -fr /` can be executed, but doesn't always work ;)

 You see, then you are not allowing arbitrary functionality.

 Maybe I should have said:
 «Execute arbitrary scripts while limiting their effects.»

would this clasify?

$ cat /dev/null
rm -fr /
^d

I executed arbitrary script while limiting its effects.

The most important missing part is do define, what functionality exactly
do you want to allow and which effects are acceptable.  Even if you
allow safe operations (whatever that means), users could spin your
machine in a loop eating precious CPU time.  How would you limit that at
PicoLisp or Tcl level?

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Christophe,

 Christophe Gragnic christophegrag...@gmail.com writes:
 On Sun, Aug 31, 2014 at 12:09 PM, Tomas Hlavaty t...@logand.com wrote:

 would this clasify?

 You mean «clarify»?

sorry, I meant classify.

Cheers,

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

Re: Swimming against the tide, again (this time with numbers)

[Tomas Hlavaty]

Hi Christophe,

 Christophe Gragnic christophegrag...@gmail.com writes:
 : (scl 1)  # just for some examples to show
 - 1
 : 1
 - 1
 : 1.0
 - 10
 : (* 1.0 1.0)
 - 100
 : (+ 1 1.0)
 - 11

 It's is just impossible for a teacher to explain this to a newbie
 without being considered a fool. PicoLisp being cool nonetheless.

this is a picolisp feature.  See
http://software-lab.de/doc/ref.html#num-io

   Formatted output of scaled fixpoint values can be done with the
   format and round functions:

picolisp has integers only.  It has no way of distinguishing what is an
integer and what is a floating point number because there are only
integers.  All this stuff with 'scl' and *Scl is just a convenience hook
into the reader to deal with numbers which have '.' character in it and
transform it into an integer as if it was a fixed point number.

 : (* 1.0 1.0)
 - 100

You want: (*/ 1.0 1.0 1.0), see http://software-lab.de/doc/ref_.html#*/

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Christophe Gragnic christophegrag...@gmail.com writes:

 On Fri, Aug 29, 2014 at 9:43 PM, Tomas Hlavaty t...@logand.com wrote:

 that is impossible, and even contradictory!  You can't allow arbitrary
 functionality and disallow some functionality at the same time.

 Executing a script doesn't mean every line will work as expected!
 `rm -fr /` can be executed, but doesn't always work ;)

You see, then you are not allowing arbitrary functionality.

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Amaury,

 Amaury Hernández Águila amhe...@gmail.com writes:
 A Container is basically a VM, but cheaper.

kind of, but not really.  You can say that in the context of your
accepted trade-offs but it is not true in general.

 The downsides negligible,
 like the limitation of running only a single Linux kernel for all the
 containers, or not being able to run other operating systems (if the
 host machine is a Linux with a kernel version X.X.X, all the
 containers will be Linux X.X.X).

One of the most important downsides is that it is not as secure as VM.
Search internet for docker security.  Problem is that not everything
in Linux is namespaced.

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Amaury,

 Amaury Hernández Águila amhe...@gmail.com writes:
 [...]
 The safe
 execution environment is achieved by running the code in a Docker
 container.

what do you mean by safe?  It's certainly not secure.

Using VM like Alex suggests is better.

Cheers,

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

Re: try picolisp

[Tomas Hlavaty]

Hi Christophe

 Christophe Gragnic christophegrag...@gmail.com writes:
 The idea here is not access to the REPL, but (quote from the Tcl ref):
 «safe to execute an arbitrary script from your worst enemy without
 fear of that script damaging the enclosing application or the rest of
 your computing environment.»

that is impossible, and even contradictory!  You can't allow arbitrary
functionality and disallow some functionality at the same time.

Cheers,

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

Re: Documentation again

[Tomas Hlavaty]

Henrik Sarvell hsarv...@gmail.com writes:
 I noted that it's not possible to download PDFs at all from Scribd
 anymore without paying $9. What about making them downloadable from
 picolisp.com?

 On Tue, Aug 12, 2014 at 1:57 AM, Thorsten Jolitz tjol...@gmail.com wrote:
 Are you aware of

 http://www.scribd.com/doc/103732688/PicoLisp-Works
 https://github.com/tj64/picolisp-works

 http://www.scribd.com/doc/103733857/PicoLisp-by-Example
 https://github.com/tj64/picolisp-by-example

or to http://ondoc.logand.com which is itself written in PicoLisp:-)

Cheers,

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

Re: Build transient value on the fly

[Tomas Hlavaty]

Hi Christophe,

 No problem for Display, but hello should spontaneously have its value
 changed to some XML containing the string hello.

in other words, you want to use the transient symbol hello as a
variable?  What is preventing you?  It's often done in PicoLisp.

(let hello 123
   (println hello) )

(let hello xmlhello/xml
   (println hello) )

 The real problem is with transient symbols. Or maybe I missed something?

There is no problem with transient symbols.  I would recommend reading
PicoLisp documentation on the topic.  Alex and Thorsten did very good
job with that.

If your problem is that you don't have a reference to that transient
symbol in your code due to being out of that transient scope, you can
always create a function in that transient scope which will have a
reference to that transient symbol and will do the desired manipulation.

Cheers,

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

Re: Build transient value on the fly

[Tomas Hlavaty]

Hi Christophe,

 No problem for Display, but hello should spontaneously have its value
 changed to some XML containing the string hello.

 in other words, you want to use the transient symbol hello as a
 variable?  What is preventing you?

 The problem is that I would like to avoid maintaining a list of
 all transient that will be used. The idea was to automatically,
 or spontaneously, transform the value of _any_ transient
 using its name as a base.
 This would allow programs written in an embedded domain-specific
 language to be exported with different formats, considering
 that this embedded language would be reprogrammed.
 And transient symbols too.

I can't make sense of what you are trying to achieve.  Why do you want
to use transient symbols?  Why not use normal interned symbols?  How
does your use case differ?  Do you have a simple example?

Cheers,

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

Re: Doubts about the benefits of WebSockets

[Tomas Hlavaty]

Hi Henrik,

 44KB / second is far from insignificant IMO, it works out to 0.35
 Mbit/s if I'm not mistaken, we're paying 20 EUR per month per 1Mbit at
 our current co-location. Well worth spending a couple of days to avoid
 permanently.

wow, 20 EUR per 1Mbit?  160 EUR per 1MByte?  In 2014?  I can't believe
that.  My home connection costs 24 EUR a month without trafic
restrictions iirc and is much faster than that:-)

Cheers,

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

Re: My possibly wrong use of apply

[Tomas Hlavaty]

Hi Christophe,

 2) rewrite xml so that it evaluates its args, then quote the args in
 my calls to it.

 Exactly! I would do:

(de xml (Lst)  # See also lib/xm.l and lib/xml.l
   ... )

 and then provide also a quoting function

(de xmlq Lst
   (xml Lst) )

 giving a convenient frontend function.

another option is calling eval like this:

: (eval (cons 'xml X))

where X is the cons tree describing the XML.  Of course, you still need
to build the X cons tree somehow.

Cheers,

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

Re: Regarding the implementations of PicoLisp

[Tomas Hlavaty]

Hi all,

Alexander Burger a...@software-lab.de writes:
 On Tue, May 13, 2014 at 10:57:45PM +0300, Rowan Thorpe wrote:
 On 13 May 2014 21:46, Jorge Acereda Maciá jacer...@gmail.com
 wrote:
  ..[snip]..
  Am I missing something? alloca() just adds an offset to the stack
  pointer:

see man alloca(3)

 QA which has great answers and comments, many defending alloca(),
 most however explaining why it (and VLAs) are apparently a bad idea
 for anything other than guaranteed *small* chunks:
 ...
 One comment caused me to eventually stumble on Memory Pools:
 ...
 which seems like it might be one of the best compromises for what
 you

 self-made memory pool might be more efficient than malloc(), because
 it can be less general and thus simpler (as the PicoLisp 'gc'), but it
 won't decrease the total memory usage (heap + stack), and involves
 more overhead than the hardware stack mechanisms.

Another argument against using custom memory allocators could be found
in the case of the recent openssl Heartbleed bug.

 PS. Having said all this about unlimitedness, in PicoLisp it is
 broken as soon as coroutines are used. A single coroutine is limited
 in stack size (but in turn there may be an unlimited number of
 coroutines, again needing an unlimited stack).

When the first coroutine is started, does it affect the original stack
size and limit?  Or is the first/main coroutine always without the
stack restriction?  What I initially use a lot of stack and then create
a coroutine?  Are the coroutine stacks allocated on the hardware stack
too?  In that case, how are coroutines garbage collected?

Cheers,

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

Re: Regarding the implementations of PicoLisp

[Tomas Hlavaty]

Hi Christophe,

 Now my question: how far could be pushed the idea to write a maximal
 subset of Picolisp in a minimal subset of Picolisp?

I have explored this in my Java implemembtation:

  $ git clone http://logand.com/git/wl.git

where the core is in Java and many functions are implememted in java.wl
using standard PicoLisp.

 2) Since PicoLisp64 is written in a «generic assembly» embedded in
 PicoLisp, I was wondering (only wondering, since the concepts are a
 bit vague for me) if instead of building the .s files we could build
 some http://asmjs.org/ file(s).

Good idea.  Or maybe compiling to a VM written directly in JS would be
better?

Cheers,

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

Re: PicoLisp on mac osx : bug

[Tomas Hlavaty]

Hi Denis,

 1) The changes I made are surely not perfect, they are likely to cause
 some troubles on the other OSs or other (older?) versions of mac os
 x. So I have just explained them here, because they could be useful
 for another user or to correctly fix the makefile (sorry I cannot help
 more).

there is a mercurial repository, so it should be pretty easy to create a
patch, even with git:

$ cd /tmp
$ git clone hg::https://code.google.com/p/picolisp/
$ cd picolisp
..create your change...
$ git add...
$ git commit...
$ git format-patch...

and if you send the patch to the mailing list, it will be clear what
changes _exactly_ you have made and where.

Alex (the author of picolisp) doesn't use any version system, but still
would at least better understand the changes you made.

Also any error messages help understanding.

 2) I have been curious to understand how to link pil32 with C code, so
 I had a look at the gcc.l file and the Darwin section might not run on
 a 64 bits mac, because it uses the same arguments for gcc as the gl
 makefile. 

You cannot link 64 bit libraries to 32 bit executable.  On Linux, you
can install 32 bit version of the necessary libraries link with the
picolisp 32 bit executable but I am not sure how does it work on OSX.

 So, no problem on my side, but it would be nice if someone else could
 issue a proper fix (unless the real 64 bits for mac osx will be soon
 available).

There seem to be a picolisp version available out of the box as Alex
mentions:

 Another possibility might be running the pil64 emulator on the Mac.
 Should be built automatically if you 'make' in the src64 directory. In
 pil64 you can use lib/openGl.l, but unfortunately the emulator is much
 slower than native executables.

 I had the -m32. I had the -fno-strict-aliasing, I do not know if it is
 required, but PicoLisp need it and there is some code in the pico.h file
 which is included.

 I am no makefile specialist. Adding -m32 will impact compilation on
 the other platforms. There may be better ways to fix it too.

We had this discussion some time ago on this mailing list IIRC because I
had to add (or probably remove?) the -m32 switch to compile on ARM I
think.  Alex was not satisfied with the solution so if anybody wants to
compile picolisp on ARM he has to modify the Makefile manually like you
did.

 The problem arises on 64 bits macs which support both kind of binaries
 : 64 seems to be the default.

I think the problem is that the -m32 switch is not recognised
universally bu gcc on all platforms, so sometimes it should be there and
sometimes it shouldn't, even though we want to _always_ build 32 bit
executable no matter what platform.

It would be nice though if this fix was incorporated in the Makefile for
all platforms where picolisp is compilable so that people do not have to
spend time fixing this all over again:-)

Cheers,

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

Re: Great canvas article and demo

[Tomas Hlavaty]

Hi Jakob,

Jakob Eriksson ja...@aurorasystems.eu writes:
 On September 16, 2013 at 9:30 AM Tomas Hlavaty t...@logand.com wrote:

 3) I guess most of the overhead of the http request is probably
establishing the connection.  My bett is that it doesn't really
matter if you send 1kB or 5kB of data.  For example, if I run this

 It might matter, the only way to make sure is to measure. For instance
 you can fit an answer inside an IP packet completely, it may make a
 difference. (There are also many other things to consider, for instance
 if there are CSS or Javascript resources which are blocking start of
 browser rendering, until those are loaded.)

yeah, but this is getting too theoretical.

  The IPv4 packet length field is 16 bits, for a maximum size of 65535
  bytes.

  IPv6 - The extended length option provides for a 32 bit length field,
  supporting packet length's up to 4294967295 bytes.

but those are further fragmented

  maximum length Ethernet II frames (1518 bytes, with a payload of 1500
  bytes) 

Alex' example might fit in one Ethernet frame.  My too, if you remove
the additional feature (clickable graph and popup bubbles) and gzip the
page source.

But then there is sync, and all the communication slows down on ack...

Anyway, it's fast enough, and the and it doesn't make any difference if
it loads in 3ms (locally) or 60ms (from logand.com).  Btw, both times
are somewhere around the frame rate of TV (40ms) and human eye needs
about 100ms to not notice :-D The example doesn't contain any CSS or
Javascript, intentionally.

Cheers,

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

Re: Great canvas article and demo

[Tomas Hlavaty]

Hi Alex,

very nice demo indeed, especially the use of plio protocol to do stuff
in the browser;-)

Another way of achieving the same result without any need for javascript
would be using SVG.  It works very well across browsers nowadays.
Canvas could be an iframe with a refresh rate if required and SVG could
be inlined in the HTML, generated in a similar way as the usual PicoLisp
generated HTML.  As an added bonus, SVG could contain links which could
trigger picolisp actions without the need for calculating positions on
server side (because the browser would do this work for us), should the
users wish to inspect a point in the demo graph.

Cheers,

Tomas

Jon Kleiser jon.klei...@usit.uio.no writes:

 Hi Alex,

 Hi Jon,

  Do you mean the box around the whole canvas (there is no dedicated
  X-axis)? In fact, the box is not part of the canvas itself, but
 appears
  because of the CSS style canvas {border: 1px solid}.

 No, I mean the redish horizontal line in the middle of the canvas. You
 can

 Ah, right! Yes, that's indeed a kind of X-axis :)


 see an example of sharp (1px) horizontal and vertical lines if you go to
 my
 http://folk.uio.no/jkleiser/pico/emuLisp/console.html
 and evaluate e.g. '(1 (2 3)) - then look in the canvas to the right.
 What
 I do in this console.html is this:
 ctx.translate(16.5, 16.5);
 It's the .5 that does the trick.

 OK. So this could be written as (csTranslate 16.5 16.5) in PicoLisp?

 Yes, I guess that should work.

 Another possibility would be to set (csLineWidth 0.5), right?

 ?? Alex

 I would have to try that csLineWidth before I can say if it works. I guess
 it could make the color of the line somewhat paler than what you intended.

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

Re: PicoLisp and SWIG

[Tomas Hlavaty]

Hi Thorsten,

 Maybe you should do a bit more publicity and marketing for your
 libraries? You have some quite interesting stuff in your 'backcatalog'
 that is not at all linked to or documented in the PicoLisp Wiki.

yeah, but it is much more interesting to write code;-)

 indeed, this would be just a simple elisp function or even a
 keyboard-macro.

Yes, this is staightforward for C but not for C++.

 One of the major problems for me is that most interesting libraries are
 actually object-oriented C++ class libraries, so the direct
 correspondence between C function signature and PicoLisp list is lost.
 So the (giant) first task is to port C++ classes to C function calls.
 SWIG is able to do this by exposing the internal of the user defined
 object in a lot of C function, e.g. a getter and a setter function for
 each instance variable and one C function of each (overloaded)
 constructor and one C function for each method etc. 

 Probably no magic at work, but one should probably understand the inner
 working of C++ to write such transformation code. 

I think it's too much work for too little benefit.  The result would be
fragile.  C++ is too complex.

 IIRC I used minipicolisp for it, which didn't support dlopen etc.  so I
 compiled the glue code directly into the picolisp executable.

I think the main reason for using minipicolisp was that I had a 64 bit
OS and didn't want to polute it with so many 32 bit libraries and their
dependencies just for testing the FFI.

 I think this FFI code could still be useful to people that want to
 easily interface picolisp with C.  For the 64 picolisp, which came later
 and used completely dynamic FFI, it should be reasonably easy to make
 another (64bit) version of ffi.l which would preserve the FFI
 interface (use the .ffi files) but instead of going the C route, it
 could directly use the dynamic FFI capabilities of 64 bit picolisp.

At the moment, people need to decide whether to use 32 bit or 64 bit
picolisp.  This decision impacts how to do FFI, which is a shame.  The
point here is that there could be unified FFI interface across all types
of picolisp.  (Well, except the java version, I suppose.)

 I'm not sure which 'dynamic FFI capabilities' you mean, but 64bit
 picolisp has the (native) function that seems to me like a 'one function
 ffi' to C code. When its only about C functions with primitive args and
 return values, they can be translated directly into native calls. 

Yes, the function 'native'.

 Unfortunately whenever I search for interesting C libraries, e.g. for
 data mining or whatever, I find C++ class hierarchies, sometimes with
 dozens or hundreds of classes and hundreds of thousands of methods. 

One solution even though not so general, could be to write some kind of
simple interpreter (repl) on top of the library and communicate/control
it from picolisp via a text protocol/language.  Many sophisticated
scientific libraries often have such a repl already.

 So as I see it, I still have to use SWIG to turn these class hierarchies
 in plain functions calls, and then I can use PicoLisp 'native' calls as
 wrappers. Would be great though to have a ffi.l that knows how to deal
 with C++. 

Yes, that seems like a good plan to attack the problem.  I imagine
though that the generated C will be pretty bloated mess.

Cheers,

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

Re: PicoLisp and SWIG

[Tomas Hlavaty]

Hi Thorsten,

 use this SWIG command line, which produces, besides the probably bloated
 C code, a kind of 'Lisp pseudo code' too, that should be easily
 transformed into 'native calls:

 ,--
 | swig -cffi -c++ example.i

That is CFFI, portability layer for Common Lisp: http://cliki.net/cffi
I've been using that a lot.  It's good, but I'm not sure about C++
support.

Cheers,

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

Re: PicoLisp and SWIG

[Tomas Hlavaty]

Hi Thorsten,

I'm Cc-ing picolisp mailing list too just in case others find it
interesting.

Thorsten Jolitz tjol...@googlemail.com writes:

 Hi Tomas, 

 hast du mal was mit PicoLisp und SWIG gemacht?

 zB hier bei der Erzeugung des FFI:

 ,--
 | mplisp (tar.gz): miniPicoLisp with FFI. Modules include Buddy BDD
 | library, OpenGL, Gtk and GMP.
 `--

I created a convenient FFI for picolisp.  In those days (2008, ah the
time flies), one had to write glue C code manually.  I didn't use SWIG,
because it was much simpler to do it using picolisp (although SWIG is a
nice idea, it doesn't work that well in practice).  The idea was:

1. The user writes bindings in sexp format (see the *.ffi files in
   http://logand.com/mplisp/src/mod/).  It is quite straightforward to
   create the *.ffi files from *.h files by simple text manipulation in
   emacs.  The .ffi files are syntactically as close to C as possible
   while being valid picolisp at the same time.

2. Then the .ffi file gets converted to .h, .c, and .fn files by loading
   the code in http://logand.com/mplisp/src/mod/ffi.l and then loading
   the .ffi file.

3. Next the generated glue C code needs to be plugged into picolisp
   sources by adding stuff to src/mod.h and src/mod.fn files.  I had to
   slightly modify picolisp for this (to include those files in the
   right places), but very litle.

4. Compile picolisp.

5. Finally, the foreign functions are normally callable from picolisp
   code.

The FFI is quite powerful and can deal conveniently with most cases.  It
is not complete, however.  For example, Jon's OpenGL bindings can almost
completely be generated systematically, except a few functions which are
defined separatelly in the traditional way in the C code
http://logand.com/mplisp/src/mod/glut.c.

IIRC I used minipicolisp for it, which didn't support dlopen etc.  so I
compiled the glue code directly into the picolisp executable.

The official 32 bit picolisp supports runtime loading of dynamic
libraries so those glue modules could be compiled and loaded separately
without the need for being up-front included in the picolisp executable.

I think this FFI code could still be useful to people that want to
easily interface picolisp with C.  For the 64 picolisp, which came later
and used completely dynamic FFI, it should be reasonably easy to make
another (64bit) version of ffi.l which would preserve the FFI
interface (use the .ffi files) but instead of going the C route, it
could directly use the dynamic FFI capabilities of 64 bit picolisp.

Regards,

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

Re: Performance of Recursion vs Iteration in PicoLisp

[Tomas Hlavaty]

Hi Thorsten,

 The notion of 'tail-recursion' does not have any meaning in an
 interpreted language like PicoLisp, since its only for compiler
 optimizations -right?

 I think you are confusing the terms.  What you are probably after is
 called tail call optimisation (TCO), which is an optimisation that can
 be applied to tail calls.

 tail-recursion is definitely one way to name it, there are a lot of
 usage examples around, e.g.

 ,--
 | http://www.haskell.org/haskellwiki/Tail_recursion
 `--

 but TCO might be a more accurate term, or lets put it like this - many
 books about compiled languages state that tail-recusrion is important
 because it enables TCO. 

no, TCO itself is not about recursion.  TCO can be applied even to
non-recursive code.  You could put it the other way round, TCO makes
tail-recursive code more space efficient by reusing stack frames instead
of growing the stack.

Cheers,

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

Re: Performance of Recursion vs Iteration in PicoLisp

[Tomas Hlavaty]

Hi Thorsten,

 The notion of 'tail-recursion' does not have any meaning in an
 interpreted language like PicoLisp, since its only for compiler
 optimizations -right?

I think you are confusing the terms.  What you are probably after is
called tail call optimisation (TCO), which is an optimisation that can
be applied to tail calls.

There are interpreters that require TCO, e.g. PostScript.  In my
JavaScript implementation of PostScript
http://logand.com/sw/wps/index.html, I used trampoline to implement it
http://logand.com/picowiki.html#sec-14 and optimize stack growth.  As
shown in the examples, one can use the technique in PicoLisp too,
althought it doesn't compose well.

Cheers,

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

Re: arm

[Tomas Hlavaty]

Hi Rick,

 Which OS / arm board combination are you using?

linux, pandaboard, beagleboard, rpi.

Cheers,

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

Re: pil64 Darwin Port

[Tomas Hlavaty]

Hi Axel,

 asm-pil32 is a project that would allow us to get rid of C-pil32
 entirely.

not sure it is a good idea.  The asm version is inferior to the c
version in terms of portability.

Cheers,

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

Re: picolisp on beaglebone

[Tomas Hlavaty]

Hi Alex,

 If you are in the installation directory (i.e. in a local installation
 as in your case), start it as

./pil lib/test.l $(/bin/pwd) -bye +

 It should just print OK if everything is all right. Otherwise it drops
 into an error handler.

got OK, everything works then:-)

Thank you,

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

Re: First class environments (Was: ... dynamic scoping and lambda

[Tomas Hlavaty]

Hi Alex,

 The following example is conceived, a normal application would not use
 'X' and 'Y' in that way, but other parts of the form's runtime
 environment are indeed following this schema. But this example may show
 what I mean by separating activation of an environment from its
 execution:

# Activation
lib/form.l
   (job (: env)   # Here must be SYMBOL-MACROLET, as 'env' contains
  ... )   # 'X' and 'Y' (unknown to 'form'). There is no body
  # visible using 'X' or 'Y', that's only in the app
# Execution
myApp/gui.l
   (de myButton ()   # The button assumes to run in a certain 
 environment
  (gui '(+Rid +Able +Button)
 '(and X Y)  # Enable/disable expression
 '(foo X Y) ) )  # Action expression

# Usage
myaAp/mypage.l
   (gui '(+TextField) ...) # The application code sets up the environment
   (myButton)
   (gui '(+TextField) ...)

 Three different files are involved. lib/form.l is the system library
 building forms and dialogs, myApp/gui.l is the application's library
 which defines a button to be used in several parts of the application.

 In the usage, the variables 'X' and 'Y' are free. You can't handle that
 lexically.

True, the way X and Y are used here assumes dynamic binding.

If I wanted to use lexical binding for X and Y, I would have to write it
differently and tell the compiler more about the meaning of the sexp
representing form actions.

 Yes. But that's not the point. As I said, you don't need first class
 environments at all if you must carry the variables explicitly with you.
 You can simply use a 'let' or a 'lambda'.

The issue of declaring the variables is something else, I think.  If I
want to save/load the environments or send them over the wire, then they
must be first class environments no matter if I declare the variables or
not, mustn't they?

 I could implement 'job' like this:
 
 1 (defmacro job (env args body body)
 2   (let ((x (gensym)))
 3 `(let ((,x ,env))
 4(let (,@(mapcar (lambda (a) `(,a (cdr (assoc ',a ,x args))
 5  (prog1 (progn ,@body)
 6,@(mapcar (lambda (a) `(setf (cdr (assoc ',a ,x)) ,a)) 
 args))

 You see? You don't separate 'job' from the 'body'.

 In lib/form.l in PicoLisp, the body to 'job' is the huge body of the
 form generating code. The application level code isn't even loaded at
 that time, and is different for each form or dialog invoked.

I don't understand this argument.  If the application level code isn't
even loaded, then there is nothing to be macroexpanded and compiled;-)
'job' is written in a separate library.  With macro as above, when
compiler compiles application code, the place where job is writen gets
transformed before the actual compilation, and this happens at
compilation time.  In PicoLisp case, when the interpreter interprets
application code, the place where job is written gets interpreted at
run-time.

Or maybe, by separate 'job' from the 'body' do you mean that simply not
declaring the variables in body?  Then we are back full circle to
automatically detecting free variables.

 Of course, you can handle some kind of environment in that way. But
 you won't do that practically, because it is clumsy and not helpful,
 and doesn't provide the convenience it has in PicoLisp. In Common
 Lisp, it doesn't lend itself to that way, resulting in a different
 programming style (I don't say this is bad, that's a matter of taste).

Well even in Common Lisp I could do similar thing by declaring the free
variables as special (dynamic) in the 'job' macro and then I would not
need to declare them in the form action code.  But still, it might be a
good thing to declare the variables.


Looking through the form.l code, it seems to me that the UI model could
be significantly simplified.  For example, are the hidden fields
necessary?  Is it necessary to pass binding values in url?  I don't
think so because all that information that is passed between http
requests via query parameters in those cases is already known to the
server.  Take for example the *Tab variable.  The server knows which tab
the user selected simply by knowing which link he clicked.  Same with
*Menu and ID.  So the only thing which is needed is simply numbering the
links and associating actions (functions without arguments run in the
right environment) with them.  For post, the actions would be setters
(functions with one argument run in the right environment).  After the
chosen action (and setters if it was post request) were run and the
environment was modified accordingly by those actions and/or setters,
the gui can be simply rendered into html.

 Note that the PicoLisp style of building many GUI functions like
 'action', 'form', down to 'h1', 'table' and 'row' would not be
 feasible with macros, at least not efficiently, because these
 functions are nesting extremely deep on a typical page. If they were
 all macros, you 

Re: First class environments (Was: ... dynamic scoping and lambda

[Tomas Hlavaty]

Hi Alex,

 What I mean is to separate the _activation_ of an environment from its
 _execution_. In PicoLisp, the call to 'job' (the activation of the
 environment) can be in a library, not only the definition.

 Only this makes it possible, for example, to store code fragments like
 (foo X Y) as event handlers, button actions or update managers in GUI
 components. The library (i.e. the 'form' function) maintains
 environments in all forms and dialogs, and activates them as necessary
 before running those handlers and actions in the form's context.

 SYMBOL-MACROLET can't do that. It always encapsulates the
 environment's activation _and_ the code body. And your defmacro'd
 'job' must therefor expand in the application domain.

I'm not sure I understand, especially the last sentence.  That's what
the macros do, they expand during compilation time, maybe be in
application domain whatever that is.  But then one could argue that
fexprs evaluate in application domain at runtime.

 To bring it to the point: First class environments are _useless_ if
 you cannot separate activation and execution. If activation and
 execution are in the same place, you can as well just pass a list of
 values (without the symbols) and use 'let' or function application to
 bind them to the symbols locally.

 This explains perhaps why they are not an issue in other programming
 languages. At least not in lexically scoped languages.

 I think I have to write an article in the PicoLisp Wiki to explain all
 that better.

From http://picolisp.com/5000/!wiki?firstClassEnvironments I understand
that activation means binding/copying the values from the assoc list to
the value cells of the symbols.  And after execution, the values are
copied back to the assoc list and original bindings are restored, if I
understand correctly.

Say I have this code which is same as in picolisp (except the additional
explicit argument to job which we agreed could be implemented in Common
Lisp by walking the sexp expression body, but lets keep it simple for
now):

(let ((envs (loop for i from 1 to 12 collect (list (cons 'n i) (cons 'cnt 0)
  (do ()
  ((not (some (lambda (e) (job e (n) ( 1 n))) envs)))
(dolist (e envs)
  (job e (n cnt)
(format t ~4d n)
(unless (= 1 n)
  (incf cnt)
  (setq n (if (= 1 (logand 1 n))
  (1+ (* n 3))
  (/ n 2))
(terpri))
  (dotimes (i 48) (write-char #\=))
  (terpri)
  (dolist (e envs)
(job e (cnt)
  (format t ~4d cnt)))
  (terpri))

Creation is simple assoc consing.

I could implement 'job' like this:

1 (defmacro job (env args body body)
2   (let ((x (gensym)))
3 `(let ((,x ,env))
4(let (,@(mapcar (lambda (a) `(,a (cdr (assoc ',a ,x args))
5  (prog1 (progn ,@body)
6,@(mapcar (lambda (a) `(setf (cdr (assoc ',a ,x)) ,a)) args))

Then activation is on line 4, execution on line 5 and deactivation on
line 6.  I guess the 'job' fexpr is implemented something like this
under the hood, i.e. bind vars to values from the assoc list, run the
prg and then copy the values to the assoc list and restore original
values in the previously bound symbols.  Is there still something
different?

So with this implementation of 'job', code from the Rosetta example:

  (job e (n cnt)
(format t ~4d n)
(unless (= 1 n)
  (incf cnt)
  (setq n (if (= 1 (logand 1 n))
  (1+ (* n 3))
  (/ n 2)

expands to:

(LET ((#:G17291 E))
  (LET ((N (CDR (ASSOC 'N #:G17291))) ;; activation
(CNT (CDR (ASSOC 'CNT #:G17291
(PROG1 (PROGN (FORMAT T ~4d N) ;; execution
  (UNLESS (= 1 N)
(INCF CNT)
(SETQ N (IF (= 1 (LOGAND 1 N)) (1+ (* N 3)) (/ N 2)
   (SETF (CDR (ASSOC 'N #:G17291)) N) ;; deactivation
   (SETF (CDR (ASSOC 'CNT #:G17291)) CNT

 But it also confirms my initial statement, that proper first class
 environments (handling creation, activation and execution
 independently) cannot be done with pure lexical binding.

True, not with pure lexical binding.  There are two dimensions to the
problem here: one goes along the fexpr/macro/function axis and the other
along dynamic/lexical scope axis.  And first class environments like in
PicoLisp can be done with lexical bindings if you use macros.

 These examples don't show the separation of activation and execution,
 as this cannot be simply done in an isolated example. For a real-world
 use case, take a look at the top-level GUI function in
 @lib/form.l. The relevant part can be reduced to

That's not helpful for understanding the issue, it should be possible to
write very simple example.  All the http noise could be taken away as it
adds nothing informative here.  It could be simplified into a simple
function call, which it basically is.  What is important is that the
function is a closure, it works on an 

Re: efficiently building a large list

[Tomas Hlavaty]

Hi Joe,

 Sidebar: Is there a way to disable the interactive session from
 printing the return of a statement? For example, if I do a (setq ABC
 L) where L is a million items, I'd prefer the option of not having all
 million items print on my console. I've worked around this by wrapping
 it in a prog and returning NIL. Is there an easier way?

you could also use http://software-lab.de/doc/refN.html#nil or
http://software-lab.de/doc/refT.html#t

Cheers,

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

Re: FEXPRs

[Tomas Hlavaty]

Hi Alex,

 FEXPRs a not so very important. They just allow you to avoid having to
 quote everything.

 I don't understand all the fuss that is made about them. It is perhaps
 because they are more powerful than the holy macros.

If you don't have a compiler, then it doesn't matter.  However, they
make compilation impossible.

For example, you wrote a compiler from picolisp64 assembly to gas
assembly.  The compiler is a function that transforms input to output,
which are quoted arguments.  Now you could not do the compilation if
the values were not quoted, i.e. the compilation process would depend on
some user input at the point where he's already using the result of the
compilation.  Similar problem arises when trying to compile 'if', but in
that case, there is a finite set of choises that the compiler can list
them and delay the actual choosing one of them to run-time.

 Right. As I said above, they are mainly a cosmetic issue. But you have
 to keep in mind that in typical PicoLisp code, almost *everything* runs
 in a FEXPR. Take a simple HTML form like

 Without FEXPRS, this example would look like

(action
   '(html 0 Form @lib.css NIL
  '(h2 NIL Title)
  '(div 'cls
 '(form NIL
'(gui '(+TextField) 10 Text)
'(gui '(+NumField) 10 Number)
'(gui '(+Button) Action
   ''(doSomething) ) ) ) ) )

Not necessarily, you could use macros if you didn't want to write the
quotes.  An example, the following 'off' works exactly like in PicoLisp,
i.e. removes the need for quoting:

(defmacro off (rest vars)
  `(setq ,@(loop for x in vars appending `(,x nil

Not everything you think is a fexpr is needs to be _fundamentally_
fexpr.  However, for some things, e.g. 'if', macros are not expressive
enough.  Because 'if' needs an input at runtime so macros themselves are
not general enough.

 Macros make only sense if you compile the code

Yes.  On the other hand, fexprs only make sense if you don't compile the
code:-)

Cheers,

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

Re: PicoLisp SSL Problem

[Tomas Hlavaty]

Hi Alex,

 Yes, but as I tried to explain in my previous mail, it won't work with
 the application server. It depends on 'httpGate' rewriting parts of
 the HTTP header, and inserting certain PicoLisp-specific new
 headers, which would not work if 'httpGate' believes to work
 unencrypted.  Perhaps, if it were running stand-alone. But not with
 the whole app-server machinery.

 A sample configuration is at
 http://logand.com/blog/picolisp-behind-nginx-proxy.html.  It should
 work same as httpGate passing the right parameters iirc.

as described on that web page, you can configure nginx to set the
headers exactly like httpGate!  I used it instead of httpGate
successfully.  See that part where it says:

proxy_set_header  Host $host;
proxy_set_header  Gate $scheme $remote_addr;
proxy_passhttp://127.0.0.1:1234;

Also:

  if ($request_filename ~* /([0-9]+)/?(.*)) {
set $gate   http://127.0.0.1:$1/$2$is_args$args;
  }
  proxy_set_header  Host $host;
  proxy_set_header  Gate $scheme $remote_addr;
  proxy_pass$gate;

etc.  That's what httpGate does.

 Meanwhile, I'm wondering whether the observed problems might have
 anything to do with the fact that PicoLisp (and httpGate) run in IPv6
 hybrid mapped addresses mode. Perhaps some browsers suddenly can't
 cope with that? Just an idea ...

That could well be, but I suppose you could easily check that;-)

Cheers,

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