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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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:

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 *

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)

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

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

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

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,

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

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

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:

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

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

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

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

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

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

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

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