Empty entries in $GUILE_LOAD_PATH
Hello! Try something like: $ GUILE_LOAD_PATH=/foo/bar: make check … and see the LALR tests fail with: ERROR: In procedure primitive-load-path: Unable to find file "home/ludo/src/guile/test-suite/lalr/common-test.scm" in load path (These tests use ‘load’.) Is that expected? What’s the meaning of empty entries in the load path? Should ‘meta/uninstalled-env’ & co. clear $GUILE_LOAD_PATH? Thanks, Ludo’.
Re: Psyntax security hole prevents secure sandboxing in Guile
Hi Mark, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: >> Mark H Weaver skribis: >> >>> Every once in a while someone asks about secure sandboxing with Guile, >>> and generally the response is that it should be fairly easy, by creating >>> a module with carefully selected bindings, but there's nothing ready >>> "out of the box". >>> >>> I just realized that psyntax has a security hole that prevents secure >>> sandboxing, and wanted to post this fact before it was forgotten. >> >> There are many other holes, such as the fact that ‘@@’ is compiled to >> the ‘toplevel-ref’ instruction, which can search inside modules. > > '@@' can be rebound, so that its default binding is no longer available: Right. However, code compiled outside the sandbox, with the real ‘@@’, does have that ‘toplevel-ref’ in it. > Can you think of anything else that would need to be fixed, besides this > problem with forgeable syntax-objects? CPU/memory resource revocation, the ability to pass immutable references to existing objects (variables, vectors, etc.), and mediated access to OS resources such as file descriptors. Also, a simple way to create a new module hierarchy based on an existing one is needed. To goal would be to make it easy, for instance, to invoke code within a module hierarchy that lacks (system foreign), has no POSIX procedures in (guile), and where (set! + -) would not affect the outside world. All this is currently doable, but a high-level API to do it is lacking. Thanks, Ludo’.
Re: Who moderates the scheme-reports list?
Hi, Alex Shinn skribis: > As Mark says, the public scheme-repo...@scheme-reports.org > list is a mailman list open to anyone. OK, I stand corrected. Thanks, Ludo’.
syntax parse link
Hi, I would like to add a link to the syntax-parse repo from guile's home page. I was told to try get the rights to do this myself. If that doesn't work I will need help from any of the maintainers to make the linkage. NEWS: for syntax parse I have written a fresh module using syntax parse to do racket's for, for/list, etc. interface. And have also started to work with an implementation of racket's match. It has indeed been a pleasure to work with the syntax parse framework and these two examples can be studied to see syntax-parse in action. It has also been a test-bed and I found that racket's syntax parse is lacking with respect to mutual recursive syntax-classes. Hence I added a sane support for this feature. E.g. First prepend the code by declarations e.g. (define-syntax-class ...) Here the declaration has to be rich enough to contain all of the interface that is later used for the syntax-class. (syntax-class-set! ...) (New) Has the same format as define-syntax-class but modifies the old syntax-class in such a way that a new parser function is added. To do this the interfaces has to match or else a helpful message will be supplied. Ergo the idea follows closely the define/set! method in scheme The procedure is a little clunky due to the expressiveness of the syntax-class macro but still straightforward and the code is easy to debug. Have fun Stefan
stack closures for guile-log
hi all,
I have now implemented stack closures that can be pushed out to the heap
if we want to store a state. This is how it works.
I have three stacks
1. a control stack that stores undo information scheme hooks aka
dynamic-wind and stack references to the other stacks.
2. stack from which data is allocated from like the bulk of a closure
and special pairs
3. a cons stack, e.g. an array of allocated conses
So to allocate a closure we allocate a cons c and a sequence of bytes
transformed
to a vector let the vector be located at the cdr and store a identifying
SCM object
that identifies that the cons represents a closure. and the cons is
returned as
the closure object with the vector filled with the closure data like C
function pointer
and associated closure data. Now If we mark a state as stored we simple
mark
the stacks for storage and when unwinding and seeing this mark the closure
data is copied
over to a heap allocated vector and then modify the same cons cell cdr
position with it
and then remove the cons from the cons stack and allocate a new cons to
that position.
I'm about to make this robust but I can run the einstein case quite fine
right now.
---
That is in managing these closures. The c function signature for these
closures is designed as
int f(SCM **sp, int nargs, SCM *closure_data)
{
}
So for the VM code we do not need any extra instructions, just modify the
call logic
to add a check for a cons with a car object that matched the identity for
this kind of
closure. it will also unpack a reference to the closure data and call the c
function f
retry:
SCM spp = sp
nargs = f(&spp,nargs,clodure_data);
sp = spp;
if(nargs < 0)
A RETURN VALUE IS ON THE STACK
else
A NEW FUNCTION IS ON THE STACK
if(C_STACK_VERSION)
goto retry:
else
goto vm_tail_call or vm_call
E.g. we have constructed a trampoline for the c code to use. The logic code
in kanren and guile-log is
centered around tail calls and this tool does not infere much with the rest
of guile.
Now this is a bit dangerous to use but I have compiled a macro package in
scheme called
clambda
https://gitorious.org/clambda
And with this one can write essentially
(:define: (memb x l)
(:match: (l)
((x . _) (:cc:))
((_ . ,l) (:call: member x l
(:define: (righ x y l)
(:match: (l)
((x y . _) (:cc:))
((_ . ,l) (:call: right x y l
(:define: (nextto item1 item2 rest)
(:or: (:call: right item1 item2 rest)
(:call: right item2 item1 rest)))
compile it to C, write a little hook code that can be automized and
then the einstein case takes 25ms compared with compiled gprolog
that takes 12ms on my machine.
I did test how far I could take this code and with some reworking it's
possible
to run the code as fast as 13.5ms which was about 7.5 times faster when
using an
assq which took around 100ms to run.
So there is some overhead due to a more complex mechanism then in ordinary
prolog
but it's pretty close in the what it can be capable of.
Have fun
Stefan
