Hi Andy,
> There's another thing that really should be fixed, for the sake of
> preserving our ability to change the implementation `local-eval' in the
> future.
>
> Since (the-environment) can be included in code compiled to disk, the
> lexical environment objects that it returns are effectively
Hi Neil!
It looks like fun, and it’s great that the FFI allows for quick &
fruitful experiments like this.
Thanks,
Ludo’.
Andy Wingo skribis:
> (define-syntax lexicals
> (lambda (x)
> (syntax-case x ()
> ((lexicals) #'(lexicals lexicals))
> ((lexicals scope)
> (with-syntax (((id ...)
> (filter (lambda
Hi Noah,
Noah Lavine skribis:
> As long as we're pinging people for 2.0.5, I don't think this patch
> ever got pushed. :-)
Apparently it was applied as 4eb286127c41e67eb90ef1b69f61f613bcd830b2.
Thanks,
Ludo’.
Hi,
Mark H Weaver skribis:
> Because it breaks your nice equivalence. For example:
>
> (let ((x 1))
> (syntax-local-binding #'x))
>
> is not equivalent to:
>
> (let ((x 1))
> (local-eval '(syntax-local-binding #'x) (the-environment)))
>
> Put another way: if anyone uses `syntax-loca
Just in case anyone else is interested in these areas... I had a really
fun time today using the dynamic FFI to hack up Guile code to access
oFono's D-Bus API. It's really great to be able to do this, even if it
might be more efficient in the long run to write a proper C binding.
I've attached t
Andy Wingo writes:
> Hi Neil,
>
> On Sat 14 Jan 2012 22:48, Neil Jerram writes:
>
>> Andy Wingo writes:
>>
>> Of the possibilities above, I think I prefer
>>
>>> (add-to-load-path (dirname (current-source-filename)))
>
> Done. Actually I called it "current-filename", so it would be:
>
> (a
l...@gnu.org (Ludovic Courtès) writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Rob: Would it be possible for you to try out this patch on one of the
>> Debian SPARC machines?
>
> And here's the patch. ;-)
It looks like that doesn't fix the problem -- it failed on ia64 this
time:
https:
David Kastrup writes:
> Mark H Weaver writes:
>
>> Remember, (current-module) is a compile-time concept, not a run-time
>> concept.
I should clarify this statement. (current-module) is used by the code
that's doing the compiling (e.g. the REPL), _not_ by the code that's
being compiled. It is
Mark H Weaver writes:
> Remember, (current-module) is a compile-time concept, not a run-time
> concept.
Then current-module should probably be a macro, not a function. In
which case the tail call problem would take care of itself.
--
David Kastrup
David Kastrup writes:
> Mark H Weaver writes:
>
>> Ideally, I think that `eval' should set (current-module) during
>> expansion, but _not_ during evaluation. Then it can be properly tail
>> recursive. However, some code out there might depend on the existing
>> behavior, so I guess we can't ch
Mark H Weaver writes:
> Ideally, I think that `eval' should set (current-module) during
> expansion, but _not_ during evaluation. Then it can be properly tail
> recursive. However, some code out there might depend on the existing
> behavior, so I guess we can't change this, at least not in 2.0.
David Kastrup writes:
> Actually, you don't need a PRNG at all. Generate a _good_ random
> starting value, and count sequentially from there.
This is _exactly_ what my patch does, on a per-thread basis.
The starting value is read directly from /dev/urandom if available.
However, if /dev/urandom
13 matches
Mail list logo
