IRC channel logs
2024-05-26.log
back to list of logs
<euouae>Hello, what is the difference between use-modules and import? I'm using R6RS <ArneBab>Kolev: how do you try to use wisp? How did you install it? <lechner>Hi, calling Guile from C via scm_with_guile, I do not wish to inherit any previous Guile mode. How may I abort if the thread is already in Guile mode or, if possible, enter a new Guile mode. I am concerned about inheriting an unwanted environment. Thanks! <mwette>lechner: I think you want something like scm_eval where you create and control the environment (i.e., module) explicitly. There is a scheme function make-fresh-user-module. <mwette>Check also the ref manual section Sandboxed Evaluation. <lechner>mwette / thanks! the section on sandboxed evaluation, which I read in full, states "Sometimes you would like to evaluate code that comes from an untrusted party." I am rewriting PAM in Guile, so it's really the other way around. I trust the PAM modules, which are written in Guile, but I don't trust the calling process. <lechner>i really just want to make sure Guile runs in a pristine environment. I clear that environment in the caller, but I'm not sure how effective that is when the thread I receive is already in "Guile mode". <mwette>So use `scm_eval' with (make-fresh-user-module). <lechner>mwette / thanks! it's called make-sandbox-value, isn't it? I cannot find make-fresh-user-module <mwette>may be in (system base language) ; it's used in language/xyz/spec.scm <rlb>lechner: my guess is that it may not write history if the repl's not involved, but that it will write .go files in the "normal place" by default, so you'd need to redirect that or similar, depending on what you need. <lechner>rlb / i am clearing the entire environment. will that be considered even after the current process was placed in "Guile mode" before execution reached my shared object? <rlb>Hmm, I suspect I'd have to understand a lot more about the arrangement/goals to be able to answer very coherently, and even then it might require some research in the docs, and or code. <rlb>For example, if you mean you're changing some relevant envt vars after the process has started, and after some guile code may have run, then I think knowning what happens, if not promised in the docs, would require poking around in the code to understand when it checks that var, etc. <rlb>And I'd guess in many case, at that point, you might want to prefer adjusting the corresponding vars like %load-path rather than the envt vars that "at some point after startup" may seed them. <rlb>But of course some of these things are also global, and so if one of the goals is to be able to mess with them in a process that might also be using guile elsewhere, for other reasons, then you'll have even more concerns. <rlb>And fundamentally, if you don't trust the other code running in the process, then you're probably stuck (guile or not) -- not sure if that's what you're worried about. <lechner>rlb / i do not want a caller of a setuid program to be able to change which Guile modules are run with something like $ GUILE_LOAD_PATH=XXX su root <lechner>what does it mean for a process (or thread) to be in "Guile mode" please? <cpli>if i have some library (foo) can i stub out a function called by (@@ (resolve-module '(foo)) 'func) for testing purposes? <rlb>cpli: what do you mean by "stub out"? <cpli>rlib: i.e. replace a call to some procedure 'func-b with my own (define (func-b-stub) 'dummy-value) <rlb>If you're accessing it that way, then you'll have to (mutably) change the actual value in the module via module-set! or similar. Though (if that's viable) you can (and likely should) do that inside a dynamic-wind or something so it's only briefly "wrong". <rlb>Unless you were going to locally mess with @@ or something... But I'd be tempted to step back and see if there's some other way to accomplish what I want. <rlb>(for either), i.e. avoid global mutation or hacking @@ somehow (if that'd even work) <rlb>ACTION would have to think about it... <cpli>rlb: if you could be so nice, could you send me some example of using module-set! for that? <cpli>say on some (ice-9 <module>)? <rlb>(module-set! (module-resolve ...) 'foo bar) <rlb>ACTION double-checks <cpli>does that work? depending on whether or not they're declarative modules, you run into issues with guile inlining calls, no? <cpli>can you module-set!, then tell guile to recompile the module? <rlb> (module-set! (resolve-module '(srfi srfi-1)) 'cons +) <cpli>(oh lord, this is getting convolute-) <rlb>And then woe unto you :0 <rlb>Right -- I'd really suggest stepping back if you can. <rlb>Another option -- define a part of the code to use a parameter, you can change for the testing thread at test time. <rlb>(and just for the testing thread) <rlb>Really depends on what your constraints are. <cpli>that doesn't work if its a "foreign" module (i.e. written by someone else, not written in another language) <rlb>...or if you have control, just rework the module api to be more friendly to testing. I tend to do that with some frequency, myself. <rlb>Right -- much more constrained if you don't control the source but then I'd be very hesitant to go anywhere near @@ if I could avoid it. <rlb>i.e. potentially very fragile.