Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Alexander Burger
Hi Jorge, Rowan,

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:

Yes, it was mentioned occasionally in this thread.

 This whole thread is fascinating :-) and while following up some of

Indeed :)

 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

For the purpose of our discussion, dynamically sized arrays and alloca()
are equivalent. They both have the disadvantage that the stack may grow
unexpectedly.

But for an inherently recursive language like Lisp this is always a
problem; you may end up using rather large amounts of stack space.

Therefore, PicoLisp postulates unlimitedness, by relying on the fact
that modern operating systems maintain the stack in hardware (MMU),
increasing its size up to the total available memory just as needed. It
is recommended to set ulimit -s unlimited.

Still, PicoLisp tries to be economical with stack usage. At each
recursion or function call, as little memory as possible should be
consumed. For this reason, constant array sizes are not optimal, they
will increase stack usage _really_ fast.


So the argument against dynamically sized arrays and alloca() should not
be that they may use too much stack space. They _must_ allocate so much
stack space as is needed anyway.


A memory pool is not giving anything new. The PicoLisp heap is a memory
pool, but it is asynchronous to the stack. In princple, malloc() is also
using a memory pool, and uses the brk() system call to increase it. A
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.

♪♫ Alex

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). 'emu' is even worse in this regard, it
doesn't use the hardware stack at all, and a fixed size pool instead :(
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread 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

2014-05-14 Thread Alexander Burger
Hi Tomas,

  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?

No, it is also restricted, but to 4 times the stack segment size of
other coroutines (see doc/refS.html#stack).


 What I initially use a lot of stack and then create
 a coroutine?

Before any coroutine is started, the stack is potentially unlimited.
When the first coroutine is started, however, and it finds that the
stack is already larger than that 4x limit, an error is thrown.


 Are the coroutine stacks allocated on the hardware stack
 too?  In that case, how are coroutines garbage collected?

Yes. The stack segments grow downwards on the hardware stack.

The garbage collector knows about them, and traverses all coroutine
segments which are in use. When a coroutine terminates or goes out of
scope, its stack segment is freed.

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


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Jakob Eriksson
Heartbleed vs custom memory allocator is a false dichotomy. The problem with 
OpenSSL was a bad development model. A security library should have a 
development model focusing on security. Security is a process and taking 
responsibility for design decisions and committing to them, not letting things 
slip out of hand over the years. 
-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Re: Regarding the implementations of PicoLisp

2014-05-14 Thread andreas
 Heartbleed vs custom memory allocator is a false dichotomy. The problem
 with OpenSSL was a bad development model. A security library should have a
 development model focusing on security. Security is a process and taking
 responsibility for design decisions and committing to them, not letting
 things slip out of hand over the years.
 --
 Skickat från min Android-telefon med K-9 E-post. Ursäkta min
 fåordighet.


PicoLisp can and might be used to implement security applications.
So better use standard proved OS mechanisms and have some more initial
effort to get it running, I think.

The heartbleed bug wouldn't have had such a devastating effect if they
wouldn't have implemented their own memory management.


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


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Jakob Eriksson


On May 14, 2014 at 4:03 PM andr...@itship.ch wrote:

 PicoLisp can and might be used to implement security applications.

Of course.

 So better use standard proved OS mechanisms and have some more initial
 effort to get it running, I think.

The standard proved OS mechanism are all different for all the libcs
and platforms out there. Testing is advised. Why do you trust the true
and tested libc on some unpatched Windows XP over your own, highly
vetted and unit-tested custom code?  You shouldn't.

Veering off topic here ...

but sorry, you can't look at OpenSSL, a very, very ill patient, and
decide that one single symptom is the cause of its disease.

OpenSSL had a bad fever. You decide that it was because OpenSSL
made its own socks. You ignore that OpenSSL also smoked crack,
ate only at McDonalds, never exercised, drank a lot, and never wore
anything but a T-shirt in the winter.
Oh, and OpenSSL made the socks not to stay warm, but because
OpenSSL thinks that making his own socks makes him run faster.
Or something...

sorry for the rant, but the take-home from OpenSSL is more like,

don't make your own memory manager without caring even a little
bit about if its secure or not, only that its FASTER than some
old buggy libc you once encountered 10 years ago.




 The heartbleed bug wouldn't have had such a devastating effect if they
 wouldn't have implemented their own memory management.

The heartbleed bug wouldn't have existed in the first place if
these developing protocols would have been in place:


 - test on other memory allocators. Just to ensure conformance.

 - create decent unit tests would
   (including inputting invalid data, black box testing)

 - remove the HUGE chunks of unused code
   (unused code obscures the real code and makes it harder to read)

 - their custom memory allocator would have cleared out memory on free
   (like the OpenBSD allocator does)

 - they would have had any focus security at all


I have no problem with the strategy to for instance use a custom
allocator with an unsecure default allocator, but defaulting to the
system allocator on good platforms like OpenBSD.


Disclaimer though, I have actually no particular axe to grind with the
actual OpenSSL developers. I have more scorn for those USING OpenSSL
in their products. The API is convoluted, the code is questionable.
If possible, avoid. Thankfully the OpenBSD developers have stepped
up to the challenge and forked openssl:

https://en.wikipedia.org/wiki/LibreSSL

(That won't fix the API I guess, but at least the security will improve.)

Although, for all their bragging about security, they should have done
that 10 years ago. But better late than never.

Sorry for the bitterness. :)


--jakob



PS

There is also the larger picture. Which is best, having unencrypted
communications and knowing it, or having encrypted communications,
but unaware of the gaping in holes in security?
-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread rand
On May 14, 2014, at 7:42 AM, Jakob Eriksson ja...@aurorasystems.eu wrote:

 There is also the larger picture. Which is best, having unencrypted
 communications and knowing it, or having encrypted communications,
 but unaware of the gaping in holes in security?

Or even better, encrypting your data before communicating it!
Even that leaves open the question of whether there are back doors in the 
crypto libraries. You can roll your own memory management, but don't try to 
roll your own cryptography--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Alexander Burger
Hi Jakob,

 Veering off topic here ...
 ...
  The heartbleed bug wouldn't have had such a devastating effect if they
  wouldn't have implemented their own memory management.
 ...
  - test on other memory allocators. Just to ensure conformance.
 ...
 I have no problem with the strategy to for instance use a custom
 allocator with an unsecure default allocator, but defaulting to the
 system allocator on good platforms like OpenBSD.

Why I enjoyed your rant very much, I must mention that according to what
I heard about the heartbleed bug, it is not the fault of the memory
allocator.

The bug happened because the _sizes_ of incoming and outgoing data were
not handled correctly:

1. Incoming packet says it is 64k, but in fact is only one byte.
2. The single byte is written to the buffer (here the receiver _must_
   know the size independently of what the packet tells).
3. The reply sends all 64k from the buffer, using the wrong value from
   the packet instead of its known count of written bytes.

For this scenario, it would not help if the buffer were allocated by
another memory manager, or even be static.

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


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread andreas

 Why I enjoyed your rant very much, I must mention that according to what
 I heard about the heartbleed bug, it is not the fault of the memory
 allocator.

 The bug happened because the _sizes_ of incoming and outgoing data were
 not handled correctly

true, but then the leaking memory wouldn't have been restricted on
critical data like private keys and password traffic. so more probing
would have been necessary to gain exploitable data. which of course isn't
better, but afaik the (bad) selfmade memory management somewhat
accelerated the root bug.

Regarding testing, check out John Hughes - Testing the Hard Stuff and
Staying Sane:  http://www.youtube.com/watch?v=zi0rHwfiX1Q
Summary (see http://en.wikipedia.org/wiki/QuickCheck ):
Testing done with predefined behavior specification models, then the code
to be tested gets called with random inputs and the result compared with
the model by using the pattern matching system of Erlang. If the system
finds a bug, it reruns the tests until it can reduce it to the minimal
steps required to trigger the bug and delivers those as output.

It seems to me that a similar test software could be implemented in pil,
using its highly flexible pattern matching (match). Or we extend
QuickQueck with the ability to check picolisp code. Just a random idea.


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


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Jakob Eriksson
Yes, but it would help if the allocator cleared returned memory if I recall 
correctly. 

On May 14, 2014 6:40:59 PM CEST, Alexander Burger a...@software-lab.de wrote:
Hi Jakob,

 Veering off topic here ...
 ...
  The heartbleed bug wouldn't have had such a devastating effect if
they
  wouldn't have implemented their own memory management.
 ...
  - test on other memory allocators. Just to ensure conformance.
 ...
 I have no problem with the strategy to for instance use a custom
 allocator with an unsecure default allocator, but defaulting to the
 system allocator on good platforms like OpenBSD.

Why I enjoyed your rant very much, I must mention that according to
what
I heard about the heartbleed bug, it is not the fault of the memory
allocator.

The bug happened because the _sizes_ of incoming and outgoing data were
not handled correctly:

1. Incoming packet says it is 64k, but in fact is only one byte.
2. The single byte is written to the buffer (here the receiver _must_
   know the size independently of what the packet tells).
3. The reply sends all 64k from the buffer, using the wrong value from
   the packet instead of its known count of written bytes.

For this scenario, it would not help if the buffer were allocated by
another memory manager, or even be static.

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

-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Alexander Burger
On Wed, May 14, 2014 at 07:33:00PM +0200, Jakob Eriksson wrote:
 Yes, but it would help if the allocator cleared returned memory if I recall 
 correctly. 

Only if you would allocate a new buffer for each read, which doesn't
sound reasonable to me.

No, the solution is simply send back (or, in general, process) exactly
as many data as you have received.

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


Re: Regarding the implementations of PicoLisp

2014-05-14 Thread Jakob Eriksson
Sorry for ranting the list again but...

On 2014-05-14 19:17, andr...@itship.ch wrote:
 true, but then the leaking memory wouldn't have been restricted on
 critical data like private keys and password traffic. so more probing
 would have been necessary to gain exploitable data. which of course isn't
 better, but afaik the (bad) selfmade memory management somewhat
 accelerated the root bug.

Hm, I think I was wrong:

Remember, |*payload*| is controlled by the attacker, and it's quite
large at 64KB.
If the actual |*HeartbeatMessage*| sent by the attacker only has a
payload of, say,
one byte, and its |*payload_length*| is a lie, then the above
|*memcpy()*| will read beyond
the end of the received |*HeartbeatMessage*| and start reading from the
victim
process's memory.
(http://www.theregister.co.uk/2014/04/09/heartbleed_explained/)




 Regarding testing, check out John Hughes - Testing the Hard Stuff and
 Staying Sane:  http://www.youtube.com/watch?v=zi0rHwfiX1Q
 Summary (see http://en.wikipedia.org/wiki/QuickCheck ):
 Testing done with predefined behavior specification models, then the code
 to be tested gets called with random inputs and the result compared with
 the model by using the pattern matching system of Erlang. If the system
 finds a bug, it reruns the tests until it can reduce it to the minimal
 steps required to trigger the bug and delivers those as output.

Sounds lovely!
Great idea.



--090209010008000608030107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

html
  head
meta content=text/html; charset=ISO-8859-1
  http-equiv=Content-Type
  /head
  body bgcolor=#FF text=#00
div class=moz-cite-prefixSorry for ranting the list again but...br
  br
  On 2014-05-14 19:17, a class=moz-txt-link-abbreviated 
href=mailto:andr...@itship.ch;andr...@itship.ch/a wrote:br
/div
blockquote
  cite=mid:52a2f948cd5525a5db370643f450f3e0.squir...@www.itship.ch
  type=cite
  pre wrap=
/pre
  pre wrap=
true, but then the leaking memory wouldn't have been restricted on
critical data like private keys and password traffic. so more probing
would have been necessary to gain exploitable data. which of course isn't
better, but afaik the (bad) selfmade memory management somewhat
accelerated the root bug./pre
/blockquote
br
Hm, I think I was wrong:br
br
Remember, codebpayload/b/code is controlled by the
attacker, and it's quite large at 64KB.br
If the actual codebHeartbeatMessage/b/code sent by the
attacker only has a payload of, say,br
one byte, and its codebpayload_length/b/code is a lie, then
the above codebmemcpy()/b/code will read beyondbr
the end of the received codebHeartbeatMessage/b/code and
start reading from the victimbr
process's memory.
(a class=moz-txt-link-freetext 
href=http://www.theregister.co.uk/2014/04/09/heartbleed_explained/;http://www.theregister.co.uk/2014/04/09/heartbleed_explained//a)br
br
br
br
blockquote
  cite=mid:52a2f948cd5525a5db370643f450f3e0.squir...@www.itship.ch
  type=cite
  pre wrap=

Regarding testing, check out John Hughes - Testing the Hard Stuff and
Staying Sane:  a class=moz-txt-link-freetext 
href=http://www.youtube.com/watch?v=zi0rHwfiX1Q;http://www.youtube.com/watch?v=zi0rHwfiX1Q/a
Summary (see a class=moz-txt-link-freetext 
href=http://en.wikipedia.org/wiki/QuickCheck;http://en.wikipedia.org/wiki/QuickCheck/a
 ):
Testing done with predefined behavior specification models, then the code
to be tested gets called with random inputs and the result compared with
the model by using the pattern matching system of Erlang. If the system
finds a bug, it reruns the tests until it can reduce it to the minimal
steps required to trigger the bug and delivers those as output./pre
/blockquote
br
Sounds lovely!br
Great idea.br
br
br
  /body
/html

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


Re: Regarding the implementations of PicoLisp

2014-05-13 Thread Jorge Acereda Maciá

On 13 May 2014, at 07:06, Alexander Burger a...@software-lab.de wrote:

 
 Basically you are implementing you own malloc(), which is still far away
 from a single-instruction push, pop or stack arithmetic.

Am I missing something? alloca() just adds an offset to the stack pointer:

#include stdlib.h
extern void foo(void *);
void test() {
  foo(alloca(100));
}

bash-3.2$ cc -fomit-frame-pointer -fno-stack-protector -c -O3 test.c
bash-3.2$ otool -tV test.o
test.o:
(__TEXT,__text) section
_test:
subq$0x68, %rsp
0004leaq0x4(%rsp), %rdi
0009callq   _foo
000eaddq$0x68, %rsp
0012ret



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


Re: Regarding the implementations of PicoLisp

2014-05-13 Thread Rowan Thorpe
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:

This whole thread is fascinating :-) and while following up some of
this dialogue with my own furious Googling I found a Stack Exchange
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:

 
http://stackoverflow.com/questions/1018853/why-is-alloca-not-considered-good-practice

at one point it links to another useful statement about them:

 http://compilers.iecc.com/comparch/article/91-12-079

One comment caused me to eventually stumble on Memory Pools:

 http://en.wikipedia.org/wiki/Memory_pools

which seems like it might be one of the best compromises for what you
are discussing (in terms of speed vs. safety/predictability). I am no
C-guru, so I'll just throw that in there in case it's useful. Ignore
it if it isn't.
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Will,

thanks for you long explanation!


On Fri, May 9, 2014 at 7:59 PM, Rick Lyman lyman.r...@gmail.com wrote:
 flow.c:60:37: error: fields must have a constant size: 'variable length
 array in

   structure' extension will never be supported
  struct {any sym; any val;} bnd[length(x)];


On Sun, May 11, 2014 at 12:19:46PM -0700, William Cushing wrote:
 The normal thing to do, when encountering this problem, is to replace the
 variable length arrays with pointers.  As in char foo[] - char * foo.

Correct.


 For a LISP VM, for specifically the case of the root type of the VM, it
 might make more sense (than making any a typedef for void *) to make
 any a typedef for a tagged union along the lines of:
 
 typedef union {
   char c;
   short s;
   ...
 } all_builtin_types_type;
 
 typedef struct {
   tag_type tag;
   all_builtin_types_type value;
 } any;


No. any is in fact a fixed-sized structure:

   typedef struct cell {// PicoLisp primary data type
  struct cell *car;
  struct cell *cdr;
   } cell, *any;

This is not the problem.

The problem is that all data sizes (lengths of lists, number of
arguments to functions, sizes of various structures) are dynamic in
PicoLisp, and determined at runtime.


Considering the above case

   struct {any sym; any val;} bnd[length(x)];

which, btw, could also be typedef'd as

   typedef struct myStruct {
  any sym;
  any val;
   } myStruct;

and then written as

   myStruct bnd[length(x)];


So for a compiler not supporting variable length arrays and structures,
the above statement must be rewritten as

   myStruct *bnd;

   ...

   bnd = malloc(length(x) * sizeof(myStruct));


The problem with this is that is horribly inefficient. The dynamic version

   myStruct bnd[length(x)];

simply decrements the stack pointer by length(x) * sizeof(myStruct)
(which is a single machine instruction!), while the malloc() call
involves the whole memory management machinery.

And then, don't forget the free() call!


If the compiler supports alloca(), then it could be used instead of
malloc(), with similar efficiency. But I doubt it will be available,
because it requires the same runtime behavior.

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


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote:
 The problem with this is that is horribly inefficient. The dynamic version
 
myStruct bnd[length(x)];
 
 simply decrements the stack pointer by length(x) * sizeof(myStruct)
 (which is a single machine instruction!), while the malloc() call
 involves the whole memory management machinery.

BTW, this inability of C to properly support stack manipulations was the
main reason to write the 64-bit version of PicoLisp in assembly.


As I wrote this in http://software-lab.de/doc64/README

   The reasons to choose assembly language (instead of C) were, in decreasing 
order
   of importance:

  1. Stack manipulations
 Alignment to cell boundaries: To be able to directly express the 
desired
 stack data structures (see doc64/structures, e.g. Apply frame), a
 better control over the stack (as compared to C) was required.

 Indefinite pushs and pops: A Lisp interpreter operates on list 
structures
 of unknown length all the time. The C version always required two 
passes,
 the first to determine the length of the list to allocate the necessary
 stack structures, and then the second to do the actual work. An 
assembly
 version can simply push as many items as are encountered, and clean up 
the
 stack with pop's and stack pointer arithmetics.

  ...



Pushing and popping data of unknown length is at the heart of the PicoLisp
interpreter. It is done all the time.


Note that even with arrays of variable length, as in the discussed case:

   myStruct bnd[length(x)];

it is still not optimal, because the interpreter has to call length() on
the list first, before actually processing it. The list needs to be
traversed twice.

In a language with proper stack control, you can simply call 'push' in
the loop doing the processing.

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


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Jakob Eriksson
And this is an excellent example of PicoLisp going the extra mile. Instead of 
handling C as the lowest abstraction, going to the actual machine. I imagine 
other interpreted languages could be faster if designed with this attention to 
detail. 

On 12 maj 2014 08:24:13 CEST, Alexander Burger a...@software-lab.de wrote:
On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote:
 The problem with this is that is horribly inefficient. The dynamic
version
 
myStruct bnd[length(x)];
 
 simply decrements the stack pointer by length(x) * sizeof(myStruct)
 (which is a single machine instruction!), while the malloc() call
 involves the whole memory management machinery.

BTW, this inability of C to properly support stack manipulations was
the
main reason to write the 64-bit version of PicoLisp in assembly.


As I wrote this in http://software-lab.de/doc64/README

The reasons to choose assembly language (instead of C) were, in
decreasing order
   of importance:

  1. Stack manipulations
Alignment to cell boundaries: To be able to directly express the
desired
  stack data structures (see doc64/structures, e.g. Apply frame), a
 better control over the stack (as compared to C) was required.

Indefinite pushs and pops: A Lisp interpreter operates on list
structures
of unknown length all the time. The C version always required two
passes,
the first to determine the length of the list to allocate the necessary
stack structures, and then the second to do the actual work. An
assembly
version can simply push as many items as are encountered, and clean up
the
 stack with pop's and stack pointer arithmetics.

  ...



Pushing and popping data of unknown length is at the heart of the
PicoLisp
interpreter. It is done all the time.


Note that even with arrays of variable length, as in the discussed
case:

   myStruct bnd[length(x)];

it is still not optimal, because the interpreter has to call length()
on
the list first, before actually processing it. The list needs to be
traversed twice.

In a language with proper stack control, you can simply call 'push' in
the loop doing the processing.

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

-- 
Skickat från min Android-telefon med K-9 E-post. Ursäkta min fåordighet.

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread andreas
 And this is an excellent example of PicoLisp going the extra mile. Instead
 of handling C as the lowest abstraction, going to the actual machine. I
 imagine other interpreted languages could be faster if designed with this
 attention to detail.


Exactly!

Thank you Alex, for the insightful explanation.

 On 12 maj 2014 08:24:13 CEST, Alexander Burger a...@software-lab.de
 wrote:
On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote:
 The problem with this is that is horribly inefficient. The dynamic
version

myStruct bnd[length(x)];

 simply decrements the stack pointer by length(x) * sizeof(myStruct)
 (which is a single machine instruction!), while the malloc() call
 involves the whole memory management machinery.

BTW, this inability of C to properly support stack manipulations was
the
main reason to write the 64-bit version of PicoLisp in assembly.


As I wrote this in http://software-lab.de/doc64/README

The reasons to choose assembly language (instead of C) were, in
decreasing order
   of importance:

  1. Stack manipulations
Alignment to cell boundaries: To be able to directly express the
desired
  stack data structures (see doc64/structures, e.g. Apply frame), a
 better control over the stack (as compared to C) was required.

Indefinite pushs and pops: A Lisp interpreter operates on list
structures
of unknown length all the time. The C version always required two
passes,
the first to determine the length of the list to allocate the necessary
stack structures, and then the second to do the actual work. An
assembly
version can simply push as many items as are encountered, and clean up
the
 stack with pop's and stack pointer arithmetics.

  ...



Pushing and popping data of unknown length is at the heart of the
PicoLisp
interpreter. It is done all the time.


Note that even with arrays of variable length, as in the discussed
case:

   myStruct bnd[length(x)];

it is still not optimal, because the interpreter has to call length()
on
the list first, before actually processing it. The list needs to be
traversed twice.

In a language with proper stack control, you can simply call 'push' in
the loop doing the processing.

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

 --
 Skickat från min Android-telefon med K-9 E-post. Ursäkta min
 fåordighet.




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


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 8:06 AM, Alexander Burger a...@software-lab.de wrote:
 Hi Will,
 thanks for you long explanation!

Right, and thanks to all for this interesting journey in the internals.

 The problem with this is that is horribly inefficient.

I'm interested by a clang compatible version, just to see what
emscripten will make of it.
For the sake of the experience I'm gonna try anyway.
The problem is it could take me some time. If someone fluent in C could try,
that would be interesting!!! (sorry, I haven't much more to offer).

By the way, is the source of miniPicoLisp in the repo at code.google?
https://code.google.com/p/picolisp/source/browse/


chri

-- 

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg

On Mon, May 12, 2014 at 10:59 AM,  andr...@itship.ch wrote:
 And this is an excellent example of PicoLisp going the extra mile. Instead
 of handling C as the lowest abstraction, going to the actual machine. I
 imagine other interpreted languages could be faster if designed with this
 attention to detail.


 Exactly!

 Thank you Alex, for the insightful explanation.

 On 12 maj 2014 08:24:13 CEST, Alexander Burger a...@software-lab.de
 wrote:
On Mon, May 12, 2014 at 08:06:57AM +0200, Alexander Burger wrote:
 The problem with this is that is horribly inefficient. The dynamic
version

myStruct bnd[length(x)];

 simply decrements the stack pointer by length(x) * sizeof(myStruct)
 (which is a single machine instruction!), while the malloc() call
 involves the whole memory management machinery.

BTW, this inability of C to properly support stack manipulations was
the
main reason to write the 64-bit version of PicoLisp in assembly.


As I wrote this in http://software-lab.de/doc64/README

The reasons to choose assembly language (instead of C) were, in
decreasing order
   of importance:

  1. Stack manipulations
Alignment to cell boundaries: To be able to directly express the
desired
  stack data structures (see doc64/structures, e.g. Apply frame), a
 better control over the stack (as compared to C) was required.

Indefinite pushs and pops: A Lisp interpreter operates on list
structures
of unknown length all the time. The C version always required two
passes,
the first to determine the length of the list to allocate the necessary
stack structures, and then the second to do the actual work. An
assembly
version can simply push as many items as are encountered, and clean up
the
 stack with pop's and stack pointer arithmetics.

  ...



Pushing and popping data of unknown length is at the heart of the
PicoLisp
interpreter. It is done all the time.


Note that even with arrays of variable length, as in the discussed
case:

   myStruct bnd[length(x)];

it is still not optimal, because the interpreter has to call length()
on
the list first, before actually processing it. The list needs to be
traversed twice.

In a language with proper stack control, you can simply call 'push' in
the loop doing the processing.

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

 --
 Skickat från min Android-telefon med K-9 E-post. Ursäkta min
 fåordighet.




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



-- 

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Christophe,

 I'm interested by a clang compatible version, just to see what
 emscripten will make of it.
 For the sake of the experience I'm gonna try anyway.

Nice!

Probably much more interesting (and useful) would be to port the pil64
assembler to clang. I considered that initially, but then gave up for
the same reasons (no control over stack and CPU flags).


 By the way, is the source of miniPicoLisp in the repo at code.google?
 https://code.google.com/p/picolisp/source/browse/

No, miniPicoLisp is separate. In fact, I had already stopped maintaining
it (after pil64 was out), but then went on to keep it in sync with all
relevant changes and fixes.

So it is only available as a tarball at

   http://software-lab.de/miniPicoLisp.tgz

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


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
On Mon, May 12, 2014 at 5:40 AM, Christophe Gragnic 
christophegrag...@gmail.com wrote:

 I'm interested by a clang compatible version, just to see what
 emscripten will make of it.
 For the sake of the experience I'm gonna try anyway.


chri,

I'm also interested in a emscripten compiled minPicoLisp. I've been itching
to try out emscripten and I think having miniPicoLisp available on all
platforms without building could help PicoLisp adoption.

I was able to compile miniPicoLisp on windows under clang. I basically just
replaced all instances of variable array initialization, such as:

struct {any sym; any val;} bnd[length(x = car(expr))+3];

with

//TODO
struct {any sym; any val;} bnd[100];


It builds and runs. I don't see any obvious consequences yet. I would have
assumed something like this would fail:

(setq Z (make (for N 120 (link N

I don't have emscripten geared up on this machine to try to compiling with
it. I figure it's not that far off though as a proof of concept.

Alex, is there a reasonably safe upper bounds that can be used instead of
it being determined dynamically?

(http://clang.llvm.org/compatibility.html#vla)
1. replace the variable length array with a fixed-size array if you can
determine a reasonable upper bound at compile time; sometimes this is as
simple as changing int size = ...; to const int size = ...; (if the
initializer is a compile-time constant);


I can envision a neat tool that lets us share snippets and even run code
directly from rosettacode.

GNU APL.js supports pasting code to it's emscripten compiled version of
apl:
http://baruchel.hd.free.fr/apps/apl/#code=5%205%20%E2%8D%B4%20%E2%8D%B310%0A


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Joe,

 struct {any sym; any val;} bnd[100];
 ...
 It builds and runs. I don't see any obvious consequences yet. I would have
 assumed something like this would fail:
 
 (setq Z (make (for N 120 (link N

This doesn't actually use any variable length array. You may instead try
(be sure to set the stack size to unlimited before):

   $ ulimit -s unlimited
   $ ./pil +
   : (apply + (need 100 1))
   - 100

If you don't exceed the fixed limit, but use a rather large fixed size
like the 100 above, you'll consume a large amount of stack space for
each function call. The 100 structures will occupy (with 4-byte-pointers
for 'sym' and 'val' on a 32-bit system) 800 bytes on each recursion.


 Alex, is there a reasonably safe upper bounds that can be used instead of
 it being determined dynamically?

Hmm, what is safe? In any case you use the generality of the language,
the Unlimited design objective of PicoLisp. You can never be sure that
you don't exceed one of these fixed sizes.


This applies not only to the number of function arguments, where you can
be rather sure that you don't write a function with 100 arguments, but
where it easily happens in the 'apply' family of functions (mapping),
and also everywhere an environment (a closure) in a list is handled
(e.g. in 'job' or 'bind').

Another significant situation is the frequent code snippet

  char nm[bufSize(y)];
  bufString(y,nm);

where strings (symbol names) are handled. You cannot be sure that the
string is not several megabytes in length (e.g. if you read in a whole
file). But reserving several megabytes on the stack is not an option.

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


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
Hi Alex,

Thanks for the reply and the details.

On Mon, May 12, 2014 at 9:56 AM, Alexander Burger a...@software-lab.dewrote:

 Alex, is there a reasonably safe upper bounds that can be used instead of
  it being determined dynamically?

 Hmm, what is safe? In any case you use the generality of the language,
 the Unlimited design objective of PicoLisp. You can never be sure that
 you don't exceed one of these fixed sizes.


The Unlimited design of PicoLisp is incredibly powerful. To clarify, I was
seeking some guidance on a reasonable upper limit on variable length arrays
that doesn't significantly handicap the language for demoing in an
emscripten environment. The proper solution is likely to use malloc/free
but that would introduce additional effort/complexity that might be
unnecessary for a proof of concept. I sometimes prefer hacking a small
change just to see if it's possible before letting myself go down a rabbit
hole.

It sounds like the reasonable upper limit might depend on the function. I
think I may have changed approximately 8 places that use the sym/val
structure.  I'll take a closer look. I was hopeful that there might have
been a quick answer that will work the vast majority of use cases with
little or no impact on run time and memory.


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 2:16 PM, Joe Bogner joebog...@gmail.com wrote:

 I was able to compile miniPicoLisp on windows under clang. I basically just
 replaced all instances of variable array initialization, such as:

 struct {any sym; any val;} bnd[length(x = car(expr))+3];

 with

 //TODO
 struct {any sym; any val;} bnd[100];

 It builds and runs.

I didn't have this luck.
I just set up a repository on github (Alex being OK) and reported my issue here:
https://github.com/Grahack/minipicolisp/issues/1
Could you show me your source files?
Could you try with my source files?
Or tell me the differences?
Would it be easy for you to be granted commit access?

On Mon, May 12, 2014 at 4:31 PM, Joe Bogner joebog...@gmail.com wrote:
 […]
 The proper solution is likely to use malloc/free but
 that would introduce additional effort/complexity that might be unnecessary
 for a proof of concept. I sometimes prefer hacking a small change just to
 see if it's possible before letting myself go down a rabbit hole.

The same for me. My goal being beyond the proof of concept, but not
very far though.


chri

-- 

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
I added my changes to this repo:

https://github.com/joebo/miniPicoLisp

This commit has everything needed to build on clang on windows:

https://github.com/joebo/miniPicoLisp/commit/e34b052bc9c8bd8fa813833294a5830a69ffb56e


I'm using:

C:\Users\jbogner\Downloads\miniPicoLisp\srcclang -v
clang version 3.4 (198054)
Target: i686-pc-mingw32
Thread model: posix
Selected GCC installation:

And my make came from http://sourceforge.net/projects/win-bash/

I am happy to answer any questions/help further




On Mon, May 12, 2014 at 11:50 AM, Christophe Gragnic 
christophegrag...@gmail.com wrote:

 On Mon, May 12, 2014 at 2:16 PM, Joe Bogner joebog...@gmail.com wrote:
 
  I was able to compile miniPicoLisp on windows under clang. I basically
 just
  replaced all instances of variable array initialization, such as:
 
  struct {any sym; any val;} bnd[length(x = car(expr))+3];
 
  with
 
  //TODO
  struct {any sym; any val;} bnd[100];
 
  It builds and runs.

 I didn't have this luck.
 I just set up a repository on github (Alex being OK) and reported my issue
 here:
 https://github.com/Grahack/minipicolisp/issues/1
 Could you show me your source files?
 Could you try with my source files?
 Or tell me the differences?
 Would it be easy for you to be granted commit access?

 On Mon, May 12, 2014 at 4:31 PM, Joe Bogner joebog...@gmail.com wrote:
  […]
  The proper solution is likely to use malloc/free but
  that would introduce additional effort/complexity that might be
 unnecessary
  for a proof of concept. I sometimes prefer hacking a small change just to
  see if it's possible before letting myself go down a rabbit hole.

 The same for me. My goal being beyond the proof of concept, but not
 very far though.


 chri

 --

 http://profgra.org/lycee/ (site pro)
 http://delicious.com/profgraorg (liens, favoris)
 https://twitter.com/profgraorg
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe



Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Joe Bogner
On Mon, May 12, 2014 at 11:50 AM, Christophe Gragnic 
christophegrag...@gmail.com wrote:


 I just set up a repository on github (Alex being OK) and reported my issue
 here:
 https://github.com/Grahack/minipicolisp/issues/1


I think the main difference is your Makefile

https://github.com/Grahack/minipicolisp/commit/15a72e16b097336c3a1d3b4092f3656509183308

Instead of:

clang $*.c

I'm doing this:

$(CC) -w -c $*.c

The -w suppresses warnings

and then linking with:

c:/Progra~2/LLVM/bin/clang.exe -o picolisp $(picoFiles:.c=.o)


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Jorge Acereda
Why not alloca()? 

 El 12 May 2014, a las 16:31, Joe Bogner joebog...@gmail.com escribió:
 
 The proper solution is likely to use malloc/fre
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-12 Thread William Cushing
Ah, I read too quickly, didn't notice/realize the length(...)
subexpression was the variable part.

If you don't have alloca, and you don't want to use assembler, and you
don't want the overhead of malloc/free, and you don't want to, or literally
can't, risk demons flying out of your nose:

typedef char byte;
byte hack[HACK_SIZE];  // hack is meant to remind one of stack
byte * hack_ptr = hack+(HACK_SIZE-1);
void * hack_alloc(size_t num_bytes) {
  return hack_ptr -= num_bytes;
}
void * hack_dealloc(size_t num_bytes) {
  return hack_ptr += num_bytes;
}
// if you don't trust your compiler to inline one-liners (what?! get a new
compiler, and/or file a bug report, but if all else fails):
//#define hack_alloc(n) ((void *)hack_ptr -= n)
//#define hack_dealloc(n) ((void *)hack_ptr += n)
// you can call these push and pop or something similar instead.
// (if you get annoyed by the type casting, you can change to a byte *
interface instead of a void * interface, ofc.)
// Importantly though, dealloc isn't free; you have to track lengths
separately all the way from alloc to dealloc,
// which automation is a (very) small part of the overhead of malloc/free.

-Will

P.S.

If you're feeling dirty, and you know exactly how your compiler allocates
call frames, sometimes you can capture the address of your last local var,
as in:

int sp;
#ifdef STACK_DOWNWARDS
#define salloc(n) (sp -= n)
#define sdealloc(n) (sp += n)
#else
//...
#endif

void my_proc(my_vec x) {
 int i,j,k;
 sp = k;
 salloc(length(x));
 //...
 sdealloc(length(x));
}

But this will surely fail (thankfully at compile-time) for
emscripten/clang.  Also, it will likely fail (at runtime, resulting in
'random' code execution) if the compiler introduces temporaries, or you
call subroutines.

A similar trick is:
  void * get_sp_here(int bogus) { return bogus; }
but, again, this relies on implementation-defined behavior, which will
again be rejected by emscripten/clang.





On Mon, May 12, 2014 at 10:03 AM, Joe Bogner joebog...@gmail.com wrote:


 On Mon, May 12, 2014 at 11:50 AM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:


 I just set up a repository on github (Alex being OK) and reported my
 issue here:
 https://github.com/Grahack/minipicolisp/issues/1


 I think the main difference is your Makefile


 https://github.com/Grahack/minipicolisp/commit/15a72e16b097336c3a1d3b4092f3656509183308

 Instead of:

 clang $*.c

 I'm doing this:

 $(CC) -w -c $*.c

 The -w suppresses warnings

 and then linking with:

 c:/Progra~2/LLVM/bin/clang.exe -o picolisp $(picoFiles:.c=.o)







Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Christophe Gragnic
On Mon, May 12, 2014 at 7:03 PM, Joe Bogner joebog...@gmail.com wrote:

 I think the main difference is your Makefile
 Instead of:

 clang $*.c

 I'm doing this:

 $(CC) -w -c $*.c

 The -w suppresses warnings

Great. It works now. I fixed the warnings and didn't add the -w flag though

Re: Regarding the implementations of PicoLisp

2014-05-12 Thread Alexander Burger
Hi Will,

 If you don't have alloca, and you don't want to use assembler, and you
 don't want the overhead of malloc/free, and you don't want to, or literally
 can't, risk demons flying out of your nose:
 
 typedef char byte;
 byte hack[HACK_SIZE];  // hack is meant to remind one of stack
 byte * hack_ptr = hack+(HACK_SIZE-1);
 void * hack_alloc(size_t num_bytes) {
 ...

Well, nice try, but it is not helpful here.

Basically you are implementing you own malloc(), which is still far away
from a single-instruction push, pop or stack arithmetic.

And it is worse than that, because it violates the Unlimited principle
even more, with the constant HACK_SIZE. If you make 'hack' variably
sized (allocated by malloc() or realloc() again?), you get a full blown
self-made memory manager. So why the trouble? :)

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


Re: Regarding the implementations of PicoLisp

2014-05-11 Thread Christophe Gragnic
On Fri, May 9, 2014 at 7:59 PM, Rick Lyman lyman.r...@gmail.com wrote:
 below are a few of the errors generated [compiling miniPicoLisp with 
 emscripten]:

 flow.c:41:62: warning: '' within '||' [-Wlogical-op-parentheses]
if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
 isNum(car(x)))
 ~~
 ~~^~~~
 flow.c:41:62: note: place parentheses around the '' expression to silence
 this

   warning
if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
 isNum(car(x)))

 ~~^~~~
 flow.c:60:37: error: fields must have a constant size: 'variable length
 array in

   structure' extension will never be supported
  struct {any sym; any val;} bnd[length(x)];
 ^
 flow.c:77:18: warning: using the result of an assignment as a condition
 without
   parentheses [-Wparentheses]
   } while (p = p-link);
~~^

I investigated a bit, with my very limited C knowledge.
Parens are (very) easy to fix, but the «fields must have a constant size»
leaves me clueless, even after dozens of minutes googling.


chri

-- 

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe


Re: Regarding the implementations of PicoLisp

2014-05-11 Thread William Cushing
It seems that any is a typedef for a variable length array, which C
compilers often refuse to support.  Some C compilers are more permissive
regarding variable length arrays; gcc, for example, is more permissive.
Emscripten (or clang/llvm) is, apparently, not.

The normal thing to do, when encountering this problem, is to replace the
variable length arrays with pointers.  As in char foo[] - char * foo.
In Java that would be a lossy transformation (it would lose the length
information), but C doesn't expose the length of a variable-length array as
a runtime-accessible value (because of which, the language permits, but
does not require, compilers to collapse variable-length arrays into
pointers).  The upshot is that C code using variable-length arrays can
always be collapsed into code using pointers without loss.  (Said another
way, working C code which used variable-length arrays had to track the
length separately, often by using 0-termination.)

For a LISP VM, for specifically the case of the root type of the VM, it
might make more sense (than making any a typedef for void *) to make
any a typedef for a tagged union along the lines of:

typedef union {
  char c;
  short s;
  int i;
  long l;
  float f;
  double d;
  void *h;
  void (*t)();
  env_type e;
  pair_type p;
  vec_type v;
} all_builtin_types_type;

typedef struct {
  tag_type tag;
  all_builtin_types_type value;
} any;

(Then one writes code like switch (thing.tag) { case CHAR_TYPE_CODE:
frob_c(thing.value.c); break; case SHORT_TYPE_CODE: frob_s(thing.value.s);
break; ...}.)

..albeit, the normal thing in Lisp VMs is to steal tag bits from the
values themselves, rather than dedicate auxiliary bytes to storing run-time
type info.

Either way, one builds up a layer of macros so that code which accesses the
type tags isn't too aware of the precise representation, i.e., something
like switch (get_tag(thing)) { case CHAR_TYPE_CODE:
frob_c(untag_c(thing)); ... }.

The downside of the union approach is that, for example, statically
allocating any foo[100] will allocate 100 *
sizeof(largest_builtin_type), which, for characters, would represent an
at-least 8 times constant-factor overhead.  If one doesn't use C's type
system to help you manage types, but rather roll your own, then it won't be
possible to statically allocate any foo[100]; (at least, not by using
such simple syntax) --- but it will be possible to ensure that 100
instances of a builtin referred to by an any take up exactly as much
space as 100 instances of that builtin + tag bits for the array type + tag
bits for the element type.

If the Picolisp implementation is already that internally complicated, then
the easiest way forward to get emscripten to work is one of:
  (1) make  any a typedef for a void * (or char * if you want to
lessen the amount of type-casting needed), or,
  (2) make any a typedef for a char and change all of the formal
parameter lists to pass any * rather than any.

Probably the first is what will work, but if the code uses sizeof(any),
then something like the second may be needed in order to achieve the
desired effect (to wit, don't use 8 bytes to store an ASCII character).

-Will






On Sun, May 11, 2014 at 8:31 AM, Christophe Gragnic 
christophegrag...@gmail.com wrote:

 On Fri, May 9, 2014 at 7:59 PM, Rick Lyman lyman.r...@gmail.com wrote:
  below are a few of the errors generated [compiling miniPicoLisp with
 emscripten]:
 
  flow.c:41:62: warning: '' within '||' [-Wlogical-op-parentheses]
 if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
  isNum(car(x)))
  ~~
  ~~^~~~
  flow.c:41:62: note: place parentheses around the '' expression to
 silence
  this
 
warning
 if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
  isNum(car(x)))
 
  ~~^~~~
  flow.c:60:37: error: fields must have a constant size: 'variable length
  array in
 
structure' extension will never be supported
   struct {any sym; any val;} bnd[length(x)];
  ^
  flow.c:77:18: warning: using the result of an assignment as a condition
  without
parentheses [-Wparentheses]
} while (p = p-link);
 ~~^

 I investigated a bit, with my very limited C knowledge.
 Parens are (very) easy to fix, but the «fields must have a constant size»
 leaves me clueless, even after dozens of minutes googling.


 chri

 --

 http://profgra.org/lycee/ (site pro)
 http://delicious.com/profgraorg (liens, favoris)
 https://twitter.com/profgraorg
 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe



Re: Regarding the implementations of PicoLisp

2014-05-09 Thread 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: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
Christophe,

How about porting the c version using: https://github.com/kripken/emscripten
?

-rl


On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them in
 the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on node


Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Joe Bogner
Hi Rick, Christophe,

I was thinking the same thing. miniPicolisp might be a simpler first step
to port


On Fri, May 9, 2014 at 7:51 AM, Rick Lyman lyman.r...@gmail.com wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them
 in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node





Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
Joe,

Something like:

Browser
 Stream IN
  miniPicoLisp (c to asm.js via emscripten)
   PiL i/o
read-eval-print loop
 Stream OUT
  HTML, PiL i/o to Server, JSON, ...
   localStorage, indexedDB, cookies, sessionStorage, ...

Server
 Stream IN
  PicoLisp
   PiL i/o from miniPicoLisp/Browser
read-eval-print loop
 Stream OUT
  PiL i/o to Browser/miniPicoLisp


http://software-lab.de/doc/ref.html#io: ...read-eval-print loop...
http://software-lab.de/doc/tut.html#funio: ...functions operate on implicit
input and output channels...
http://picolisp.com/wiki/?ideasPage: ...pilBrowserDB...


-rl


On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first step
 to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them
 in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node






Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
Joe, Christophe,

re: miniPicoLisp (c to asm.js via emscripten) and stream management:

Simlarly maybe Query could be adapted via emscripten:

https://github.com/tj64/picolisp-by-example/blob/master/mainmatter/rosettacode-C.tex


[
Calling a PicoLisp function from another program requires a running
interpreter.
There are several possibilities, like IPC via fifo's or sockets using the
PLIO
(PicoLisp-I/O) protocol, but the easiest is calling the interpreter in a
pipe.
This is relatively efficient, as the interpreter's startup time is quite
short.
]


[

int Query(char *Data, size_t *Length) {
   FILE *fp;
   char buf[64];

   sprintf(buf, /usr/bin/picolisp query.l \%d -bye, *Length);
   if (!(fp = popen(buf, r)))
  return 0;
   fgets(Data, *Length, fp);
   *Length = strlen(Data);
   return pclose(fp) = 0 \\ *Length != 0;
}
]



On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first step
 to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them
 in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node






Re: Regarding the implementations of PicoLisp

2014-05-09 Thread rand
Hi Tiffany,

This could be quite interesting — indeed in “Salem”. Nothing to really view — I 
can do a “drive by”.

Could you check if there is any thing going on, like “pending”, etc.?

4898 Riverdale Rd S, Salem, OR


Randy



On May 9, 2014, at 7:07 AM, Rick Lyman lyman.r...@gmail.com wrote:

 Joe,
 
 Something like:
 
 Browser
  Stream IN
   miniPicoLisp (c to asm.js via emscripten)
PiL i/o 
 read-eval-print loop
  Stream OUT 
 HTML, PiL i/o to Server, JSON, ...
  localStorage, indexedDB, cookies, sessionStorage, ...
 
 Server
  Stream IN
   PicoLisp 
PiL i/o from miniPicoLisp/Browser
 read-eval-print loop
  Stream OUT
   PiL i/o to Browser/miniPicoLisp
 
 
 http://software-lab.de/doc/ref.html#io: ...read-eval-print loop...
 http://software-lab.de/doc/tut.html#funio: ...functions operate on implicit 
 input and output channels...
 http://picolisp.com/wiki/?ideasPage: ...pilBrowserDB...
 
 
 -rl
 
 
 On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:
 Hi Rick, Christophe,
 
 I was thinking the same thing. miniPicolisp might be a simpler first step to 
 port
 
 
 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman lyman.r...@gmail.com wrote:
 Christophe,
 
 How about porting the c version using: https://github.com/kripken/emscripten?
 
 -rl
 
 
 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:
 Hi,
 
 I'm currently embedding a «pedagogical pseudo-code like language» in PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with 
 Alex),
 which proved to be a good solution for me.
 
 So I had some thoughts, ideas and questions.
 
 1) EmuLisp lacks some functions. The first idea I had was to write them in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking about
 performance here, just functions availability.
 
 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).
 
 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on node
 
 
 



Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
Joe, Christophe,

A downside to asm.js is that it is Firefox only...

http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042

-rl

p.s.: anyone considering c directly via Chrome/NaCL?


On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first step
 to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them
 in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node






Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
Joe, Christophe,

Some links:

http://ricklyman.net:81/!wiki?emscripten


On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough, with
 Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them in
 the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be pushed
 the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on node


Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Joe Bogner
It works in chrome too and IE10 too

Check out: http://pypyjs.org/demo/




On Fri, May 9, 2014 at 10:21 AM, Rick Lyman lyman.r...@gmail.com wrote:

 Joe, Christophe,

 A downside to asm.js is that it is Firefox only...


 http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042

 -rl

 p.s.: anyone considering c directly via Chrome/NaCL?


 On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first step
 to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough,
 with Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write them
 in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be
 pushed the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node







Re: Regarding the implementations of PicoLisp

2014-05-09 Thread andreas
Hi Christophe,
and other interested fellow picolispers :)

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node

I'm highly interested in this.

We must distinguish between:

A) javascript implementation of picolisp, so picolisp runs on
browser/node.js (this requires two different implementations I guess, even
when they share a lot in common)

B) javascript generating from picolisp, so we can program on HTML DOM in
browser using picolisp, or interact with node.js libraries from picolisp
running on / or calling node.js

As I understand it, the JVM lisp language Clojure (and its subset
ClojureScript) are covering both of this. I believe it would be very
interesting to have this for picolisp too.

I guess for having B) really covering everything, it requires A) to be
implemented.
So one way would be to write an pil interpreter on js, which might be
reached in a various of ways as currently being discussed, and then
writting some libraries to interact with the environment
(browser,node.js).

Another way might be reimplementing pil on top of ClojureScript, not sure
if that makes sense.
Might be easier to implement it a lisp dialect instead of javascript.




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


Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
re: http://pypyjs.org/demo/

Success:
Chrome: 34
Internet Explorer: 11

Failure:
Safari: 5


On Fri, May 9, 2014 at 10:50 AM, Joe Bogner joebog...@gmail.com wrote:

 It works in chrome too and IE10 too

 Check out: http://pypyjs.org/demo/




 On Fri, May 9, 2014 at 10:21 AM, Rick Lyman lyman.r...@gmail.com wrote:

 Joe, Christophe,

 A downside to asm.js is that it is Firefox only...


 http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042

 -rl

 p.s.: anyone considering c directly via Chrome/NaCL?


 On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first
 step to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough,
 with Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write
 them in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be
 pushed the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not talking
 about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs on
 node








Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Rick Lyman
just a note:

Downloaded miniPicoLisp.
Building under Linux/gcc ok

Downloaded Emscripten (for Windows)
Using c files (from Linux re: above) I tried: emcc -O2 flow.c -o flow.bc

below are a few of the errors generated:

flow.c:41:62: warning: '' within '||' [-Wlogical-op-parentheses]
   if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
isNum(car(x)))
~~
~~^~~~
flow.c:41:62: note: place parentheses around the '' expression to silence
this

  warning
   if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
isNum(car(x)))

 ~~^~~~
flow.c:60:37: error: fields must have a constant size: 'variable length
array in

  structure' extension will never be supported
 struct {any sym; any val;} bnd[length(x)];
^
flow.c:77:18: warning: using the result of an assignment as a condition
without
  parentheses [-Wparentheses]
  } while (p = p-link);
   ~~^

..




On Fri, May 9, 2014 at 11:20 AM, Rick Lyman lyman.r...@gmail.com wrote:

 re: http://pypyjs.org/demo/

 Success:
 Chrome: 34
 Internet Explorer: 11

 Failure:
 Safari: 5


 On Fri, May 9, 2014 at 10:50 AM, Joe Bogner joebog...@gmail.com wrote:

 It works in chrome too and IE10 too

 Check out: http://pypyjs.org/demo/




 On Fri, May 9, 2014 at 10:21 AM, Rick Lyman lyman.r...@gmail.com wrote:

 Joe, Christophe,

 A downside to asm.js is that it is Firefox only...


 http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042

 -rl

 p.s.: anyone considering c directly via Chrome/NaCL?


 On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first
 step to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough,
 with Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write
 them in the
 available functions (like 'glue' with 'pack'). It worked for some, but
 some others
 needed to be implemented in JS. Now my question: how far could be
 pushed the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not
 talking about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs
 on node









Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Joe Bogner
I bet it's the same problem as this:
https://www.mail-archive.com/picolisp@software-lab.de/msg04411.html

emscripten uses clang, right?


On Fri, May 9, 2014 at 1:59 PM, Rick Lyman lyman.r...@gmail.com wrote:

 just a note:

 Downloaded miniPicoLisp.
 Building under Linux/gcc ok

 Downloaded Emscripten (for Windows)
 Using c files (from Linux re: above) I tried: emcc -O2 flow.c -o flow.bc

 below are a few of the errors generated:

 flow.c:41:62: warning: '' within '||' [-Wlogical-op-parentheses]
if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
 isNum(car(x)))
 ~~
 ~~^~~~
 flow.c:41:62: note: place parentheses around the '' expression to
 silence this

   warning
if (isNum(x = EVAL(x)) || isNil(x) || x == T || isCell(x) 
 isNum(car(x)))

  ~~^~~~
 flow.c:60:37: error: fields must have a constant size: 'variable length
 array in

   structure' extension will never be supported
  struct {any sym; any val;} bnd[length(x)];
 ^
 flow.c:77:18: warning: using the result of an assignment as a condition
 without
   parentheses [-Wparentheses]
   } while (p = p-link);
~~^

 ...




 On Fri, May 9, 2014 at 11:20 AM, Rick Lyman lyman.r...@gmail.com wrote:

 re: http://pypyjs.org/demo/

 Success:
 Chrome: 34
 Internet Explorer: 11

 Failure:
 Safari: 5


 On Fri, May 9, 2014 at 10:50 AM, Joe Bogner joebog...@gmail.com wrote:

 It works in chrome too and IE10 too

 Check out: http://pypyjs.org/demo/




 On Fri, May 9, 2014 at 10:21 AM, Rick Lyman lyman.r...@gmail.comwrote:

 Joe, Christophe,

 A downside to asm.js is that it is Firefox only...


 http://www.infoworld.com/t/javascript/apple-has-its-own-javascript-accelerator-in-the-works-242042

 -rl

 p.s.: anyone considering c directly via Chrome/NaCL?


 On Fri, May 9, 2014 at 8:19 AM, Joe Bogner joebog...@gmail.com wrote:

 Hi Rick, Christophe,

 I was thinking the same thing. miniPicolisp might be a simpler first
 step to port


 On Fri, May 9, 2014 at 7:51 AM, Rick Lyman 
 lyman.r...@gmail.comlymanr...@gmail.com
  wrote:

 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

 -rl


 On Thu, May 8, 2014 at 5:08 PM, Christophe Gragnic 
 christophegrag...@gmail.com wrote:

 Hi,

 I'm currently embedding a «pedagogical pseudo-code like language» in
 PicoLisp.
 As using plain browsers is a nice thing to have in front of students,
 I tried with
 EmuLisp (PicoLisp in JS, by Jon Kleiser, that I won't thank enough,
 with Alex),
 which proved to be a good solution for me.

 So I had some thoughts, ideas and questions.

 1) EmuLisp lacks some functions. The first idea I had was to write
 them in the
 available functions (like 'glue' with 'pack'). It worked for some,
 but
 some others
 needed to be implemented in JS. Now my question: how far could be
 pushed the
 idea to write a maximal subset of Picolisp in a minimal subset of
 Picolisp? Like in
 the original paper of McCarthy or «the Jewel» in SICP? I'm not
 talking about
 performance here, just functions availability.

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

 3) Regarding EmuLisp again, and for your information, I've created
 (and am using seriously!) a JS pil, that I named `piljs` which runs
 on node










Re: Regarding the implementations of PicoLisp

2014-05-09 Thread Christophe Gragnic
Hi,
Thanks for all your answers.

On Fri, May 9, 2014 at 8:48 AM, Tomas Hlavaty t...@logand.com wrote:
 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 implementation:

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

Interesting. Both for the Java use (these seem to be good starting files for
a newbie like me, or maybe there are some others examples in the wild?),
and for the PicoLisp implemented in PicoLisp.

Could you please include a readme with some instructions about where
to begin?

 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?

A new VM? the generic one (base source files of pico64) seemed to be a
good (existing) candidate. Now there must be a translation to js.

On Fri, May 9, 2014 at 1:51 PM, Rick Lyman lyman.r...@gmail.com wrote:
 Christophe,

 How about porting the c version using:
 https://github.com/kripken/emscripten?

The first idea came because of the three letters A.S.M.
I realise that asmjs is far from having the semantics of assembly. I cannot even
find an assembly written using asmjs. This is quite misleading.

On Fri, May 9, 2014 at 2:19 PM, Joe Bogner joebog...@gmail.com wrote:
 I was thinking the same thing. miniPicolisp might be a simpler first step to
 port

Right. But it's the Emscripten route, which was not the one I suggested, but
surely a valid one. Someone?

On Fri, May 9, 2014 at 4:21 PM, Rick Lyman lyman.r...@gmail.com wrote:
 A downside to asm.js is that it is Firefox only...

I'm not looking for performance, just JS implementation.

On Fri, May 9, 2014 at 4:39 PM, Rick Lyman lyman.r...@gmail.com wrote:
 http://ricklyman.net:81/!wiki?emscripten

Thanks for the links.

On Fri, May 9, 2014 at 4:59 PM,  andr...@itship.ch wrote:
 I'm highly interested in this.

Great news! Some here too!

 We must distinguish between:

 A) javascript implementation of picolisp, so picolisp runs on
 browser/node.js (this requires two different implementations I guess, even
 when they share a lot in common)

Could you elaborate on this? I don't feel the need for now, but my goal is
quite basic: embed a very simple language.

 B) javascript generating from picolisp, so we can program on HTML DOM in
 browser using picolisp, or interact with node.js libraries from picolisp
 running on / or calling node.js

«javascript generating from picolisp» do you mean «compiling PicoLisp code
to JS code»?

I don't think it's needed to act on the DOM or interact with node libs. A simple
interface could be written. Well maybe this interface is what you mean, but
in this case, just to be sure we are in phase, not ALL the PicoLisp code should
be compiled/translated.

 I guess for having B) really covering everything, it requires A) to be
 implemented.

Could you elaborate on this?

 So one way would be to write an pil interpreter on js, which might be
 reached in a various of ways as currently being discussed, and then
 writing some libraries to interact with the environment
 (browser,node.js).

Indeed. Did you try piljs? It's not in the master branch right know.
I'm waiting for the green flag of my boss (Jon?) ;)
There are some important features young enough to be in branches only.
http://grahack.github.io/EmuLisp/
https://github.com/grahack/emulisp/tree/bye_exit_code
And of course:
https://github.com/grahack/emulisp/tree/piljs

 Another way might be reimplementing pil on top of ClojureScript, not sure
 if that makes sense.
 Might be easier to implement it a lisp dialect instead of javascript.

If we want PicoLisp, I'm not sure the peculiarities of it can be easily achieved
in other Lisp dialects (thinking about dynamic binding for one).


Christophe

-- 

http://profgra.org/lycee/ (site pro)
http://delicious.com/profgraorg (liens, favoris)
https://twitter.com/profgraorg
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe