Re: Graph database

[George-Phillip Orais]

Thank you beneroth and Joh-Tob for this impressive and insightful
explanation, very informative for me as well, thank you, I will put this on
my PicoLisp notes.

On Thu, Mar 26, 2020 at 8:29 AM Joh-Tob Schäg  wrote:

> Have you already looked at the family example?
>
> Here is my brief overview of ascending order of abstractedness:
> PicoLisp had no graph database. What is has is this:
>  - The ability to serialize/de-serialize all structures in the heap
> (Lists, numbers, functions, symbols etc)
>  - It has the ability to fetch and deserialize structures when they
> are accessed by their reference (also called external symbol) and also
> GC the loaded content when it is no longer accessable
>  - the ability to make atomic changes to such structures (by write
> locking the database).
>  - it has relations which allow the database to place pointers in one
> or multiple directions, make space for indexes etc... (I have not
> fully grasped that myself)
>  - The are indexes which automatically maintained and those are
> accessible to the database allowing you to discover objects placed in
> the database.
>  - It has an mechanism which allows you to maintain database
> consistent of different machines (replication)
>
> In PicoLisp you can solve many graph database problems with those
> structures, however PicoLisp does not care or know what a vertex is.
> It does not come support for weighted vertexes, you could build your
> own class but is usually more efficient to just implement what you
> actually need, not implement some paradigm because you heard of
> it/like it.
>
> Tailor PicoLisp to your problem, not your paradigm. This is a thing i
> had to learn over a long time.
>
> On Wed, 25 Mar 2020 at 21:46, Lawrence Bottorff  wrote:
> >
> > I'm afraid at my level of CS theory I don't really know what is meant by
> a picolisp atom being persistent, much less across distributed picolisp
> instances. Could someone give me a concrete example of what you describe
> as: "Any named bag of items automatically represents a (directed,
> undirected) graph. The name then is the node, the items in the bag then
> there represent the edges." I do understand the tree structure of a lisp
> program. But that doesn't make it a graph database. When I tried to fathom
> the Picolisp "graph database" example, I was quickly confused. The GUI
> actually added confusion, AFAIC. I'm guessing from what I could ausknobeln
> from example that the Picolisp version of a CLOS object is a vertex, and
> the inheritance of that object from other (higher, more general?) objects
> is a sort of edge. Correct me if I'm wrong. But then there was talk of
> "records." Is creating a record the same as creating an object instance --
> and this record/object is a vertex? Where, what are the edges?
> >
> > Don't get me wrong, I have long felt that Lisp -- with its parsing
> actually visible in the code you write -- is or could be very
> graphDB-friendly; however, Lisp is functional, i.e., you write functions.
> And even though they are set up as a graph-like tree in nested lists form,
> they are not in themselves data in the traditional sense, rather, code
> meant to take you from a domain/input to a range/result. This is not a
> "record" (or graph vertex?) creation/query/deletion paradigm.
> >
> > But this relates to a long-standing question I've had about software
> libraries. As it stands, they may be auto-indexed for our viewing pleasure,
> but they aren't in any real database form so that you might simply have
> your program "query-and-plug-in" a library. (Although I've heard Haskell's
> hlint almost writes your code for you!) No, you have to find the module,
> plug it in yourself. The whole "code is data", therefore, doesn't seem to
> get past the higher-order function trick of passing in a function as an
> argument. What more is there to "code is data?" In Fortran the data was in
> fact parked just below the code.
> >
> > At some point I'm just scared and rambling on
> >
> > On Wed, Mar 25, 2020 at 7:12 AM Guido Stepken 
> wrote:
> >>
> >> Lawrence, you haven't yet understood, that any Lisp, by default, is
> it's own Graph Database. Especially Picolisp, where Alex has made any
> Picolisp Atom persistent and even distributed across other Picolisp
> instances. 'Data is code, code is data'.
> >>
> >> Any named bag of items automatically represents a (directed,
> undirected) graph. The name then is the node, the items in the bag then
> there represent the edges. Even Picolisp sources you can consider a
> (directed) graph, often also called 'syntax tree'.
> >>
> >> If you like, you can put, group all "edges" with same properties into a
> new, searchable bag of edges for fast lookup. Since it's all lazy evaluated
> (even the persistent nodes), as Alex already pointed out, it's still ultra
> fast. And since in Picolisp everything can be persisted distributed,
> Picolisp automatically represents a distributed graph database (with
> sharding and 

Re: PicoLisp on windows

[r cs]

Gosh, no!

On Wed, Mar 25, 2020 at 9:02 PM  wrote:

> Does anyone realize that there's an LLVM-based port of picolisp being
> worked on by Alex? :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>


-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: PicoLisp on windows

[C K Kashyap]

Indeed Rick - it was listed in my original email as one of the options :)

On Wed, Mar 25, 2020 at 6:02 PM  wrote:

> Does anyone realize that there's an LLVM-based port of picolisp being
> worked on by Alex? :)
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PicoLisp on windows

[rick]

Does anyone realize that there's an LLVM-based port of picolisp being worked on 
by Alex? :)

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

Re: Graph database

[andreas]

Dear Lawrence

Sounds to me that your head got stuffed a bit too well with
over-complicated concepts. No offense! That is the nature of most
software education, and its even worse in the business world. And we
programmers have a high tendency to believe we are more clever when we
are working on more complex systems:"Weeks of coding can save you hours
of planning."

PicoLisp is radical in its focus on simplicity, although it is not an
easy language. Less so if one is trained by education and other
languages to think in more complicated patterns than really necessary. I
went through this struggles too, and it made me into an overall much
better software developer, also in other languages & stacks.

Some fundamentals:

  * PicoLisp has not much in common with CommonLisp, though they share
common ancestors
  * As with lisp languages in general: the source code is not a list of
instructions, but an abstract syntax tree (AST)
  o compilers (in the mainstream sense) for other programming
languages construct internally an AST from source code, and then
they optimize that AST and translate it to machine code
  o for PicoLisp, the reader (R of REPL) translates source code
(which can also be repl text input) into an AST, basically trees
of pointers
  o this AST /is/ nothing else than a data structure, the source
code (textual data) becomes a tree in RAM (lists of lists)
  o PicoLisp can modify this AST (the code data structure) during
execution - primarily by interpret it as code or data, both is
the exact same stuff in memory (more so in PicoLisp than some
other lisps)
  * PicoLisp is a multi paradigm language
  o it is not purely functional (like e.g. Haskell)
  o operations can be immutable or mutable
  * In Lisp (*l**is*t *p*rocessor) languages are based on lists
(everything with parentheses around it is a list)
  o A list is always a grouping of (possibly) multiple elements
  o Elements which are not lists themselves are called *atoms*
(single things)
  * PicoLisp has only 3 fundamental data types:
  o Number
  + signed integer of arbitrary size
  + this is an atom (atomic type)
  o Lists
  + singly linked list (so always an ordered sequence of
elements, not a unordered set)
  + may contain lists and atoms
  o Symbol
  + has a name
  + has a value
  + may have an arbitrary number of properties
  # a property consists of a name and a value
  + this is an atom (atomic type)
  o a /value/ always is of one of these 3 data types
  + other than in other languages, variables don't have a data
type (the value has a data type)
  + variables in PicoLisp are just symbols
  + the data type of an value is both static and strong (cannot
be changed)
  o all other data types (e.g. classes / objects) are based on these
3 fundamental PicoLisp types
  + non-fundamental types have practically no enforcement, no
checks - unless explicitly called
  # not entirely true, the fundamental data types have
built-in sub-variants for which certain rules apply
(e.g. transient symbols, primarily used as string type)
  +  so all non-fundamental types are *duck typed*

  + this enables easier code reuse
  o for example: the OOP system in PicoLisp is primarily based on
the symbol data type
  + classes and objects are symbols which follow certain principles
  # member variables (attributes) are stored as properties
of the symbol
  # the value of the symbol is a list containing parent
classes and methods
  * PicoLisp database mechanisms is multi paradigm
  o *on lowest level: a /key-value store/*
  + just values of the symbol data type which are persisted to disk
  + the so-called *external symbols* - a sub-variant of the
fundamental symbol data type
  + the name of such an external symbol is the logical block
address of the data within the database file(s)
  + external symbols are automatically loaded into RAM on first
access (lazy loading)
  o *external symbols combined with PicoLisp OOP system: /object
database/*
  + persistent OOP objects
  + no translation/copying between objects in RAM and database
(no ORM problem)
  + as the objects are just external symbols which follow
certain principles, they're lazy loaded when accessed
  o *relationships between database classes (entities) defined in a
schema: /graph database/*
  + not exactly following the strict academic definitions for
graph database
   

Small Docker container builds the latest pil in Alpine image

[David Bloom]

For work reasons I have strayed from the beloved PicoLisp into Erlang for
some time.  While I have much love for using Erlang/OTP to build robust,
distributed systems, it handles a different job than PicoLisp in my
opinion.  Even though work kept me in the Erlang world for a while I still
followed the mailing list and one day saw instructions on how to build pil
with musl.  After a single attempt in a fresh Alpine container it worked so
I felt compelled to share with the group.  BEHOLD!

https://hub.docker.com/r/progit/pil-alpine-minimal

Big, big thanks again to Alex and this entire community.  Happy hacking!

Re: Graph database

[Lawrence Bottorff]

I'm afraid at my level of CS theory I don't really know what is meant by a
picolisp atom being persistent, much less across distributed picolisp
instances. Could someone give me a concrete example of what you describe
as: "Any named bag of items automatically represents a (directed,
undirected) graph. The name then is the node, the items in the bag then
there represent the edges." I do understand the tree structure of a lisp
program. But that doesn't make it a graph database. When I tried to fathom
the Picolisp "graph database" example, I was quickly confused. The GUI
actually added confusion, AFAIC. I'm guessing from what I could
ausknobeln from example that the Picolisp version of a CLOS object is a
vertex, and the inheritance of that object from other (higher, more
general?) objects is a sort of edge. Correct me if I'm wrong. But then
there was talk of "records." Is creating a record the same as creating an
object instance -- and this record/object is a vertex? Where, what are the
edges?

Don't get me wrong, I have long felt that Lisp -- with its parsing actually
visible in the code you write -- is or could be very graphDB-friendly;
however, Lisp is functional, i.e., you write functions. And even though
they are set up as a graph-like tree in nested lists form, they are not in
themselves data in the traditional sense, rather, code meant to take you
from a domain/input to a range/result. This is not a "record" (or graph
vertex?) creation/query/deletion paradigm.

But this relates to a long-standing question I've had about software
libraries. As it stands, they may be auto-indexed for our viewing pleasure,
but they aren't in any real database form so that you might simply have
your program "query-and-plug-in" a library. (Although I've heard Haskell's
hlint almost writes your code for you!) No, you have to find the module,
plug it in yourself. The whole "code is data", therefore, doesn't seem to
get past the higher-order function trick of passing in a function as an
argument. What more is there to "code is data?" In Fortran the data was in
fact parked just below the code.

At some point I'm just scared and rambling on

On Wed, Mar 25, 2020 at 7:12 AM Guido Stepken  wrote:

> Lawrence, you haven't yet understood, that any Lisp, by default, is it's
> own Graph Database. Especially Picolisp, where Alex has made any Picolisp
> Atom persistent and even distributed across other Picolisp instances. 'Data
> is code, code is data'.
>
> Any named bag of items automatically represents a (directed, undirected)
> graph. The name then is the node, the items in the bag then there represent
> the edges. Even Picolisp sources you can consider a (directed) graph, often
> also called 'syntax tree'.
>
> If you like, you can put, group all "edges" with same properties into a
> new, searchable bag of edges for fast lookup. Since it's all lazy evaluated
> (even the persistent nodes), as Alex already pointed out, it's still ultra
> fast. And since in Picolisp everything can be persisted distributed,
> Picolisp automatically represents a distributed graph database (with
> sharding and everything) which you can build, implement on your own with
> just a few lines of code. It's a no-brainer!
>
> Picolisp is a genius strike, but most people can't see the forest for all
> the trees.
>
> Have fun!
>
> Regards, Guido Stepken
>
> P.S. Keep away from Windows and other viruses!
>
> Am Donnerstag, 12. März 2020 schrieb Lawrence Bottorff  >:
>
>> I take it the picolisp graph database follows more the Neo4j property
>> graph idea than any RDF/OWL triples, correct? That seems obvious, but I
>> thought I'd check. I haven't dived in deep, buy you seem to use Lisp
>> objects to create a vertex. But then what are the edges? Again, I'm just
>> getting started.
>>
>> LB
>> Grand Marais, MN, Oberer See
>>
>

Re: Review request for the patch for 64bit compilation of miniPicoLisp

[C K Kashyap]

Got it! ... thanks Alex!
Regards,
Kashyap

On Wed, Mar 25, 2020 at 10:29 AM Alexander Burger 
wrote:

> On Wed, Mar 25, 2020 at 10:09:19AM -0700, C K Kashyap wrote:
> > I see, if the assumption was long to be 64 bits then perhaps all the
> > "long"s in the code should be changed to int64_t  I see that there
> are
> > several usages of long in the code other than the couple of places I
> > changed.
>
> The general assumption in PicoLisp is that the "normal" scalar size is the
> same
> as the pointer size. On 32 bits both a pointer and a long are 32 bits, and
> on
> all 64 bit Unix systems I saw so far both were 64 bits. Thus, miniPicoLisp
> compiled fine both on 32 and 64 bit systems.
>
>
> > I was wondering though if there is some implementation of miniPicoLisp
> out
> > there that I could use as reference - perhaps just with the ability to
> call
> > an external program.
>
> You could perhaps use some parts of pil32 (?).
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: Review request for the patch for 64bit compilation of miniPicoLisp

[Alexander Burger]

On Wed, Mar 25, 2020 at 10:09:19AM -0700, C K Kashyap wrote:
> I see, if the assumption was long to be 64 bits then perhaps all the
> "long"s in the code should be changed to int64_t  I see that there are
> several usages of long in the code other than the couple of places I
> changed.

The general assumption in PicoLisp is that the "normal" scalar size is the same
as the pointer size. On 32 bits both a pointer and a long are 32 bits, and on
all 64 bit Unix systems I saw so far both were 64 bits. Thus, miniPicoLisp
compiled fine both on 32 and 64 bit systems.


> I was wondering though if there is some implementation of miniPicoLisp out
> there that I could use as reference - perhaps just with the ability to call
> an external program.

You could perhaps use some parts of pil32 (?).

☺/ A!ex

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

Re: Review request for the patch for 64bit compilation of miniPicoLisp

[C K Kashyap]

Thanks Alex,
I see, if the assumption was long to be 64 bits then perhaps all the
"long"s in the code should be changed to int64_t  I see that there are
several usages of long in the code other than the couple of places I
changed.

I was wondering though if there is some implementation of miniPicoLisp out
there that I could use as reference - perhaps just with the ability to call
an external program.

Regards,
Kashyap

On Wed, Mar 25, 2020 at 10:01 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > I've decided to try and extend miniPicoLisp with networking(or perhaps
> just
> > the capability to call into external program) to make it useful as a
> > scripting system that I can share with my colleagues. Please do let me
> know
> > if that's not a good idea.
>
> This is surely a good idea. Ersatz is too slow, and Java in general is a
> hog.
> Pil21 is not ready yet, and will be loaded with all that POSIX stuff.
>
>
> > Towards that, as a first step, I tried to compile miniPicoLIsp with
> 64bit C
> > compiler and ran into some errors. Could you please take a look at this
> > patch and confirm if these changes are sufficient? I essentially changed
> > the use of long to long long in a couple of places :)
>
> I see. I would have expected 'long' to be 64 bits in a 64-bit environment

Re: Review request for the patch for 64bit compilation of miniPicoLisp

[Alexander Burger]

Hi Kashyap,

> I've decided to try and extend miniPicoLisp with networking(or perhaps just
> the capability to call into external program) to make it useful as a
> scripting system that I can share with my colleagues. Please do let me know
> if that's not a good idea.

This is surely a good idea. Ersatz is too slow, and Java in general is a hog.
Pil21 is not ready yet, and will be loaded with all that POSIX stuff.


> Towards that, as a first step, I tried to compile miniPicoLIsp with 64bit C
> compiler and ran into some errors. Could you please take a look at this
> patch and confirm if these changes are sufficient? I essentially changed
> the use of long to long long in a couple of places :)

I see. I would have expected 'long' to be 64 bits in a 64-bit environment.
Strange. Another option might be considering int64_t explicitly.

The changes are good I think.

☺/ A!ex

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

Review request for the patch for 64bit compilation of miniPicoLisp

[C K Kashyap]

Hi Alex,

I've decided to try and extend miniPicoLisp with networking(or perhaps just
the capability to call into external program) to make it useful as a
scripting system that I can share with my colleagues. Please do let me know
if that's not a good idea.

Towards that, as a first step, I tried to compile miniPicoLIsp with 64bit C
compiler and ran into some errors. Could you please take a look at this
patch and confirm if these changes are sufficient? I essentially changed
the use of long to long long in a couple of places :)


 diff --git a/io.c b/io.c
index 7b86c60..bb0f77c 100644
--- a/io.c
+++ b/io.c
@@ -282,7 +282,7 @@ static any rdList(void) {
 static any anonymous(any s) {
int c, i;
word w;
-   unsigned long n;
+   unsigned WORD_TYPE n;
heap *h;

if ((c = getByte1(, , )) != '$')
diff --git a/main.c b/main.c
index 9c3e588..19f3647 100644
--- a/main.c
+++ b/main.c
@@ -64,7 +64,7 @@ void heapAlloc(void) {
heap *h;
cell *p;

-   h = (heap*)((long)alloc(NULL, sizeof(heap) + sizeof(cell)) +
(sizeof(cell)-1) & ~(sizeof(cell)-1));
+   h = (heap*)((WORD_TYPE)alloc(NULL, sizeof(heap) + sizeof(cell)) +
(sizeof(cell)-1) & ~(sizeof(cell)-1));
h->next = Heaps,  Heaps = h;
p = h->cells + CELLS-1;
do
@@ -295,7 +295,7 @@ long compare(any x, any y) {
  return -1;
   a = name(x),  b = name(y);
   if (a == txt(0) && b == txt(0))
- return (long)x - (long)y;
+ return (WORD_TYPE)x - (WORD_TYPE)y;
   if ((c = getByte1(, , )) == (d = getByte1(, , )))
  do
 if (c == 0)
diff --git a/math.c b/math.c
index acf5e66..a2e9e62 100644
--- a/math.c
+++ b/math.c
@@ -264,7 +264,7 @@ any doMul(any ex) {
 // (*/ 'num1 ['num2 ..] 'num3) -> num
 any doMulDiv(any ex) {
any x, y;
-   long long n;
+   WORD_TYPE n;

x = cdr(ex);
if (isNil(y = EVAL(car(x
@@ -457,7 +457,7 @@ any doBitXor(any ex) {
 // (sqrt 'num ['flg|num]) -> num
 any doSqrt(any ex) {
any x;
- long m, n, r;
+ WORD_TYPE m, n, r;

x = cdr(ex);
if (isNil(x = EVAL(car(x
@@ -468,7 +468,7 @@ any doSqrt(any ex) {
x = cddr(ex);
if (isNum(x = EVAL(car(x
   n *= unBox(x);
- m = 1L << BITS-4;
+ m = (WORD_TYPE)1 << BITS-4;
  r = 0;
  do {
  if ((r += m) > n)
diff --git a/pico.h b/pico.h
index 687b493..c5d483d 100644
--- a/pico.h
+++ b/pico.h
@@ -15,10 +15,13 @@
 #define CELLS (1024*1024/sizeof(cell))
 #endif

-#define WORD ((int)sizeof(long))
+#ifndef WORD_TYPE
+#define WORD_TYPE long long
+#endif
+#define WORD ((int)sizeof(WORD_TYPE))
 #define BITS (8*WORD)

-typedef unsigned long word;
+typedef unsigned long long word;
 typedef unsigned char byte;
 typedef unsigned char *ptr;

@@ -88,7 +91,7 @@ typedef struct catchFrame {
 #define Free(p) ((p)->car=Avail, Avail=(p))

 /* Number access */
-#define num(x)  ((long)(x))
+#define num(x)  ((WORD_TYPE)(x))
 #define txt(n)  ((any)(num(n)<<1|1))
 #define box(n)  ((any)(num(n)<<2|2))
 #define unBox(n)(num(n)>>2)

Re: Graph database

[Guido Stepken]

Lawrence, you haven't yet understood, that any Lisp, by default, is it's
own Graph Database. Especially Picolisp, where Alex has made any Picolisp
Atom persistent and even distributed across other Picolisp instances. 'Data
is code, code is data'.

Any named bag of items automatically represents a (directed, undirected)
graph. The name then is the node, the items in the bag then there represent
the edges. Even Picolisp sources you can consider a (directed) graph, often
also called 'syntax tree'.

If you like, you can put, group all "edges" with same properties into a
new, searchable bag of edges for fast lookup. Since it's all lazy evaluated
(even the persistent nodes), as Alex already pointed out, it's still ultra
fast. And since in Picolisp everything can be persisted distributed,
Picolisp automatically represents a distributed graph database (with
sharding and everything) which you can build, implement on your own with
just a few lines of code. It's a no-brainer!

Picolisp is a genius strike, but most people can't see the forest for all
the trees.

Have fun!

Regards, Guido Stepken

P.S. Keep away from Windows and other viruses!

Am Donnerstag, 12. März 2020 schrieb Lawrence Bottorff :

> I take it the picolisp graph database follows more the Neo4j property
> graph idea than any RDF/OWL triples, correct? That seems obvious, but I
> thought I'd check. I haven't dived in deep, buy you seem to use Lisp
> objects to create a vertex. But then what are the edges? Again, I'm just
> getting started.
>
> LB
> Grand Marais, MN, Oberer See
>

Re: Bug in rand

[Alexander Burger]

Hi Alfonso,

> I've noticed that the "rand" function doesn't work with negative arguments:
>
> Version 20.3.16
>
> : (rand -10 10)
>
> -> 1152921504606846966
>
> Version 19.12.28
>
> : (rand -10 10)
>
> -> -5
>
> I don't know in which exact version the bug appeared.

Oops, thanks a lot! This is my fault, I changed something recently in a stupid
way (while going through the pil64 code in the course of writing pil21).

I'll revert that as quickly as possible!

Thanks again,

☺/ A!ex

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

Re: PicoLisp on windows

[Guido Stepken]

Hi to all!

Before s.b. is reinventing wheels, like porting Picolisp onto .net, please
consider Femtolisp, which is the base underlying Julia programming language
JIT compiler. It's LLVM based and ultra fast, tiny and quite useful as PoC
for implementing Picolisp on your own.

https://github.com/JeffBezanson/femtolisp/blob/master/README.md

Picolisp on Windows and .NET ... i could never have imagined that s.b.
could want that ... is Windows still in use anywhere? I mean: After Emotet,
newest Zero Day Exploits, ? Still no antidote against, after one year
now!

Sorry, that i must say that, but whole Microsoft infrastructure has
collapsed under its own weight, cross site complexity!

"End of lifetime" for Microsoft, i would say!

Have fun!

Am Dienstag, 24. März 2020 schrieb C K Kashyap :

> Hi All,
> I've been using PicoLisp under docker on my windows machine but a
> challenge that I face is in my ability to share the scripts with my
> colleagues. It would be awesome to run picolisp on Windows.
>
> minipicolisp is easy to build on Windows (with mingw). However, it does
> not really have networking and bignum among other things.
>
> I was wondering if it would be easier/better -
>
> 1. Try to figure out how to use networking in minipicolisp - perhaps using
> libuv (the io library that's used by nodejs)
> 2. Figure out how to patch the Posix calls needed by Picolisp
> 3. Use PicoLisp LLVM as the base
> 4. Any other idea :)
>
> Regards,
> Kashyap
>

Bug in rand

[Alfonso Villén]

Hello,

I've noticed that the "rand" function doesn't work with negative arguments:

Version 20.3.16

: (rand -10 10)

-> 1152921504606846966

Version 19.12.28

: (rand -10 10)

-> -5

I don't know in which exact version the bug appeared.

Regards,

Alfonso V.


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

Re: Local install problem

[Alexander Burger]

Hi Wilhelm,

> After downloading and building the 19.12
> tarball, I find that the pil script in
> picoLisp/bin has /usr/bin/picolisp as the
> shbang, so it wouldn't actually work as a
> local installation.

There is also a local 'pil' script, i.e. "picoLisp/pil". You can call it with an
absolute or relative path.

☺/ A!ex

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

Local install problem

[Wilhelm Fitzpatrick]

I tried doing a local install of picolisp in my Chromebook's Linux 
container (Debian Buster).


After downloading and building the 19.12 tarball, I find that the pil 
script in picoLisp/bin has /usr/bin/picolisp as the shbang, so it 
wouldn't actually work as a local installation.


Did I miss a step?

-wilhelm


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