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
14 matches
Mail list logo
