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.j
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 i
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 g
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 imple
> 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 would
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
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 communicatin
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
> 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
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 thin
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
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 grea
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
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 an
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 *
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 "stac
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
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":
typ
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
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/Gra
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 ve
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;
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,
>
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 t
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 min
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 t
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
> 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 e
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 wrot
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!), whil
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,
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 encoun
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)))
>
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.
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 Wind
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 (isN
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, Chri
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
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-work
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
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, Christ
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
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 runn
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
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 P
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 br
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
47 matches
Mail list logo
