Re: Regarding the implementations of PicoLisp
useful? links: http://www.cs.indiana.edu/~dyb/pubs/3imp.pdf http://clang.llvm.org/compatibility.html http://www.linuxplumbersconf.org/2013/ocw/system/presentations/1221/original/VLAIS.pdf http://events.linuxfoundation.org/slides/2011/lfcs/lfcs2011_llvm_lelbach.pdf http://www.biwascheme.org/ asm.js performance: https://hacks.mozilla.org/2014/05/asm-js-performance-improvements-in-the-latest-version-of-firefox-make-games-fly/ http://asmjs.org/faq.html 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
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 Sorry for ranting the list again but... On 2014-05-14 19:17, mailto:andr...@itship.ch";>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/";>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";>http://www.youtube.com/watch?v=zi0rHwfiX1Q Summary (see http://en.wikipedia.org/wiki/QuickCheck";>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-- -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Regarding the implementations of PicoLisp
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
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 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
> 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
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
On May 14, 2014, at 7:42 AM, Jakob Eriksson 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
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
> 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
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
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
Hi all, Alexander Burger writes: > On Tue, May 13, 2014 at 10:57:45PM +0300, Rowan Thorpe wrote: >> On 13 May 2014 21:46, Jorge Acereda Maciá >> wrote: >> > ..[snip].. >> > Am I missing something? alloca() just adds an offset to the stack >> > pointer: see "man alloca(3)" >> Q&A 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
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á 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 :) > Q&A 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
On 13 May 2014 21:46, Jorge Acereda Maciá 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 Q&A 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
On 13 May 2014, at 07:06, Alexander Burger 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
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
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
On Mon, May 12, 2014 at 7:03 PM, Joe Bogner 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
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 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
Why not alloca()? > El 12 May 2014, a las 16:31, Joe Bogner escribió: > > The proper solution is likely to use malloc/fre -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Regarding the implementations of PicoLisp
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
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\src>clang -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 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 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
On Mon, May 12, 2014 at 2:16 PM, Joe Bogner 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 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
Hi Alex, Thanks for the reply and the details. On Mon, May 12, 2014 at 9:56 AM, Alexander Burger wrote: > 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
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
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
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
On Mon, May 12, 2014 at 8:06 AM, Alexander Burger 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, 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 >> 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
> 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 > 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
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 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
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
Hi Will,
thanks for you long explanation!
On Fri, May 9, 2014 at 7:59 PM, Rick Lyman 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
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(), 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 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
On Fri, May 9, 2014 at 7:59 PM, Rick Lyman 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
Hi, Thanks for all your answers. On Fri, May 9, 2014 at 8:48 AM, Tomas Hlavaty 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 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 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 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 wrote: > http://ricklyman.net:81/!wiki?emscripten Thanks for the links. On Fri, May 9, 2014 at 4:59 PM, 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
Re: Regarding the implementations of PicoLisp
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 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 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 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 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 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
>
> > 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
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 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 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 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 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
> 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
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 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 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 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 >>> >>> > 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
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
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 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 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 >> >> > 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
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
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 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 > > > 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
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 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 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 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 > 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
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 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
>
> > 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
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 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 > > > 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
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 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
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
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
