<jenia`>how do I save the guile runtime inside the repl? <daviid>jenia`: your question is a bit ambiguous, but iiuc, there is no such feature in Guile as 'save image' 'save session' and 'restore/load image/session'. this said, why would you want this? what are you looking for ? <jenia`>I want to go through the Little Schemer book and don't want to rewrite the entire program each time I pick up the book <daviid>jenia`: ok. I suggest you write your examples in a my-little-schemer.scm, then use (load ...) <jenia`>yup. thanks daviid. maybe if I can write a scheme program to do that by the end of the book ;) <daviid>ok, then we, guilers, recmmend to use geiser <jenia`>does that has an impact on saving scheme state in the REPL? <daviid>jenia`: no, you save your file. next session, you M-x run-guile <daviid>and load your file again ... if you want to reach a specific 'state' in the repl, then you should include these 'steps' in your file.. <daviid>as I said, we do not save the repl <daviid>jenia`: (load "my-little-schemer.scm") <jenia`>daviid: no but when I save the REPL buffer I save it with the prompt text. I can't user (load <filename>) then <daviid>jenia`: you can _not_ save the repl, as I said earlier <daviid>jenia`: everythig you define, all steps you make to use these defs, you enter these in your scheme file. then it is this file you load <daviid>jenia`: after M-x run-guile, use (getcwd) and (chdir ...) <daviid>did you try with a minimal example/test? <daviid>jenia`: what guile version are you using ? <Jookia>In a lot of cases where multiple expressions are run one after another in imperative style, adding another doesn't work unless I use (mbegin or (begin , Could someone explain this to me since it's tripped me up twice and I see no real pattern or reason why one is chosen over the other <wleslie>some forms, such as function bodies, have an implicit begin <Jookia>So when I use cond or something there's no implicit begin <Jookia>wleslie: A switch statement required me to nest an mbegin even though there was an implicit begin, I assume this is because monads? <taylan>Jookia: uh, cond has implicit begin in the clauses, like (cond (<test> <expression> ...) ...) where the '<expression> ...' is implicitly in a begin <taylan>I remember few cases where an implicit begin could be but isn't there, don't have any in mind ATM <taylan>Jookia: in what places do you miss the implicit begin? <Jookia>taylan: I'll point it out when I send my patches for review since I expect they need a lot of changing anyway <satran>Hi, I'm trying to embed guile in an application. Is there a way to disable IO functionality or is there a way to whitelist functionality? <taylan>satran: you would probably be better off doing that at the operating system level <satran>thanks, I assumed that there would be some thing that would allow me to toggle functionality. <satran>I actually want to overwrite the io functionality <Jookia>You could always modify Guile's source code <taylan>satran: is this for security reasons (executing user-provided code safely) or some other purpose? <satran>taylan: yes this is for security reasons. I am allowing users to run their own scripts on my machine and want to limit access to files. <taylan>then AFAIK Guile itself can't help much, as it stands <taylan>theoretically one can create "pure" modules where only selected variables are bound, then evaluate code in that module, but currently Guile uses psyntax for macro expansion and that allows one to inject references to any variables in any module <satran>I was afraid of that as my primary search through the manuals didn't lead me anywhere. <satran>Could you prehaps recommend me any other embedable lisp that has this functionality? <taylan>I can't vouch for the security of any, but I think a *fully* conformant R7RS implementation should do in theory. Chibi is an easily embeddable one AFAIK. in R7RS, libraries are "pure" by default, so no bindings exist whatsoever unless you import anything. <taylan>so you can declare a library like (define-library (sandbox) (import (only (scheme write) display))), and later you can eval code in it like (eval some-sexpr (environment '(sandbox))) <taylan>and it will *only* have the 'display' binding <satran>Thanks. I chose guile for the fact that it is being actively developed and has a huge community behind it. I'll have a look at Chibi. <taylan>the author is Alex Shinn, who frequently appears under the nick 'foof' in #scheme. no big community but he has been very responsive to my bug reports. <lloda``>so one issue I have with c&pasting into the repl or running code from a buffer is that there're no line numbers, so backtraces are less useful. Sometimes I put a fragment of code in a file just to (load "it") and have proper backtraces. <lloda``> Would be great if the system kept track of 'line numbers' on the repl, could recall code you've entered, etc. instead of just compiling and instantly forgetting the text. <Jookia>lloda``: Still a newbie at Guile but the way I solve this is to write things a file as my playground and reload the module and poke it using the REPL ***lloda`` is now known as lloda
<tobiasu>this may seem like a troll, but i have to ask: anyone know why 'guild' is so slow at compiling? <tobiasu>i takes 3 hours on a sparcstation at 150mhz, i've almost given up and considered it broken <tobiasu>normal performance or just really poor on sparc? <Jookia>tobiasu: I don't know much about SPARC but I don't think it's optimized for machines like that <wingo>of course you may have found a bug, who knows <tobiasu>ok so it's not some abnormal thing on sparc only <lloda>have ye poked at the bug in (parallel) where after a while there's a single thread running? I saw it in the list but I can't find it now <civodul>lloda: i don't think there have been changes recently in this area <amz3`>there is already 3 event loop for Guile, who's next? <civodul>AFAIK there's only one generic even loop in the works, no? <civodul>oh actually two, considering the one from the potluck <amz3`>but I still do not use it for something <amz3`>I did send a draft, to the mailling list, but not the debugged version. The code is much shorter than 8sync <rain1>it seems really difficult to use urandom correctly, but I think guile can use the linux randomness syscall on guixsd only so maybe it's worth the trouble for portability? <rain1>goal: secure randomness in guile <amz3`>rain1: what are you trying to do? <rain1>make a randomess library for a password generator <taylan>rain1: on Linux, reading /dev/urandom should be secure. if someone can change your /dev/urandom to a sparse file, they can probably do worse things. it probably means they have root access to the machine. <rain1>that's true it's just very tricky <rain1>I am just really keen on the new linux syscall <taylan>rain1: (let ((bv (get-bytevector-n (open-file-input-port "/dev/urandom") 40))) (assert (= 40 (bytevector-length bv))) ...) <taylan>that's using R6RS Scheme, supported by Guile <rain1>I've heard that it's important to use open instead of fopen <taylan>I don't know how open-file-input-port is implemented, but I know that the above code will *only* execute the '...' if 'bv' ends up being a length-40 bytevector <taylan>the documentation says that a smaller bytevector will be returned if not all requested bytes could be read, so if the length is 40 you can be sure you have 40 bytes from /dev/urandom <taylan>don't entrust anyone's life on my advice, but I think it should be safe :-) this is the benefit of using a high-level language. <rain1>I am sure that what you're saying is fine, even just using guiles built in random is more than good enough imo <peterbrett_work>rain1: Guile's builtin random *isn't* good enough because by default it always produces *exactly* the same sequence of numbers <peterbrett_work>rain1: Don't use it for anything that could be security-related unless you've properly initialised it from a suitable source of high-quality randomness <rain1>oh sorry I also initialize it with <rain1>(set! *random-state* (random-state-from-platform)) <rain1>so that you get different results on each run <mark_weaver>rain1, peterbrett_work: a few issues: (random-state-from-platform) relies on /dev/urandom to work well. on other platforms is does something less good. also, I'm not sure if our PRNG is good enough for cryptographic use. <peterbrett_work>Because the, "I need a random token, look the standard library has a random() function, that'll be good enough right?" hacker thought process has introduced so many security flaws that it's unreal <peterbrett_work>So I wonder if ice-9 boot should also properly initialise the PRNG state by default <mark_weaver>from my perspective, even using /dev/urandom is not necessarily good enough, and on some platforms doing something similar may be expensive <mark_weaver>if code purporting to be cryptographically secure doesn't know enough to properly seed their RNG, then it's not worthy of trust anyway <mark_weaver>and I think there's an interesting case to be made that guile should strive to behave deterministically by default <peterbrett_work>arc4random() is usually "good enough" IMHO — obviously not perfect, but good enough <mark_weaver>when i say that /dev/urandom is not good enough, I'm not referring to their choice of PRNG, but rather that there is no guarantee of how much entropy is actually available there <mark_weaver>it might be that one should be using /dev/random to seed the PRNG depending on the use case <mark_weaver>I guess my take on it is that if you need cryptographically secure random numbers, the application should take responsibility for seeding the PRNG in a way appropriate for that applicatoin <rain1>I've read that there's no difference in security between urandom and random <rain1>at least after you have finished booting <peterbrett_work>And my take on it is that there are a lot of careless/thoughtless/security-unaware/time-pressured developers out there — and it's easy to detect when somethings not deterministic and should be, and hard to detect when something's deterministic and shouldn't be <mark_weaver>there's also the fact that seeding a PRNG properly is, in general, an expensive operation <mark_weaver>and actually, we don't even have a way to do it portably <mark_weaver>so I'm reluctant to commit to every future version of Guile promising to do this job automatically, unconditionally, every time it is run <rain1>we have to do it manually otherwise the RNG is seeded with something deterministic <rain1>I guess I don't know what you mean about automatically <rain1>there's no expectation that it should happen without us doing it in our code? <rain1>ok i've lost the ability to understand this discussion ^^ <mark_weaver>rain1: if you don't understand, then it probably means that you shouldn't be writing a password generator. <rain1>no its because the thing you said didn't make sense <rain1>you said "Guile promising to do this job automatically" <rain1>but we have to seed the RNG manually <mark_weaver>peterbrett_work was suggesting that perhaps Guile should automatically seed the PRNG in a way that is sufficient for cryptographic use, and I responded that "I'm reluctant to commit to every future version of Guile promising to do this job automatically" <mark_weaver>how is this inconsistent with me saying that you need to seed the PRNG manually? <mark_weaver>btw, I want to clarify that my suggestion that perhaps you shouldn't write a password generator was not in any way an insult. writing a good password generator is difficult task, requiring specialized knowledge of the relevant issues. <rain1>it's not really insulting but it makes me think you don't know me well <mark_weaver>perhaps you are more qualified to do this than I know <rain1>I liked your suggestion about increasing the strength of randomness the other day, that's why I brought this up here today <peterbrett_work>Yes. Unfortunately Guile doesn't come out-of-the-box with any API that Does The Right Thing <rain1>about using the kernel syscall vs a device file <peterbrett_work>So rather than doing the Right Thing, which is hard work, people will use (random) and convert it to hexadecimal <mark_weaver>if you think it's sufficient to seed the PRNG using /dev/urandom, then simply using /dev/urandom for all the random numbers you need is just as good <peterbrett_work>mark_weaver: Your argument is, "We can't do this perfectly, so let's just do nothing" <mark_weaver>peterbrett_work: I think that's an unfair summary of my position <mark_weaver>Guile aims to be a portable library, but on some systems, we can't seed the PRNG *at all* <mark_weaver>so my first question is, what do you suggest we do on systems where we don't know how to access any entropy? <rain1>A good example of that would be the password generator thing, you might do something like: shroud hide ... $(shroud password --length=10) <rain1>if shroud password has exited without producing anything, because it can't seed properly.. <rain1>luckily this is a case when a person will do verification before using the output <mark_weaver>my argument is, if we can't do the job properly, then don't promise to do it <mark_weaver>if we don't know what the requirements of the application is, don't assume we know what the requirement are and lead the user to think that we've done the job <peterbrett_work>Yes. In that case, Guile should *never* initialise the PRNG at all, and all entropy-generation should return #f until the user seeds it manually <mark_weaver>making it deterministic has the advantage that it should be fairly easy to notice that every time you run a program that fails to seed the PRNG that you get the same answer every time you run it with the same arguments. <mark_weaver>peterbrett_work: the problem with that is that is will break a lot of existing code <peterbrett_work>I don't think that's adequate given that Guile is being marketed, and indeed used, for implementing web services <mark_weaver>we aren't making promises that we can't keep. we are very explicit about the fact that it's the user's responsibility to seed the PRNG <rain1>I think the current system is good, having a static rng sequence when you don't seed it specifically <peterbrett_work>I don't see a big fat warning at the top of "Random Number Generation", so no, it's hardly "very explicit" <rain1>yeah it needs to be a bigger more visual warning in the documentation <davexunit>peterbrett_work: every language makes you seed the PRNG <peterbrett_work>Right, I'm off. I think I've said everything that needs to be said on the subject. <mark_weaver>if a software author is so incompetent that they don't think to seed the PRNG or read the relevant docs, then that's crap code anyway. we can't make it secure by trying to cover for their incompetence. <mark_weaver>frankly, it's better to make it as obvious as we can that the code is crap <mark_weaver>I'm aware of the other side of this argument, and I don't think it's an unreasonable position, but I respectfully disagree that we should try to do something that we can't do properly. <rain1>could it be possible to have the (secure) randomness library just not exist on platforms that can't do it <rain1>that seems like a good approach because then the code wont even compile <mark_weaver>it's probably true that we should add a more prominent warning to the 'random' docs <rain1>yeah I mean just move the message up top or something, would be really nice! <rain1>what do you think about having that regular rng module and then a secure one that's not always available? <rain1>(regular available everywhere) <mark_weaver>I don't think we should try to seed it by default, but we should probably more ways to seed it from the platform, e.g. a way to seed it from /dev/random or similar (vs urandom), and in a way that raises an error on platforms where we don't know how to do it well. <mark_weaver>but the first step is to add a better PRNG. without that, we don't have what we need for cryptographic use anyway. <rain1>would that be implemented in guile or C? <mark_weaver>there are also issues like side-channel attacks to consider <mark_weaver>it really needs the attention of an expert in this area <mark_weaver>my knowledge in this area is above average, but I'm not an expert <mark_weaver>simply providing an easy API to read /dev/urandom might be a good interim solution, and easy to write <rain1>ah currently uses: This is the MWC (Multiply With Carry) random number generator <rain1>definitely not a cryptographic one :) <rain1>on changing RNG, one thing to consider is if splitting is of any interest <mark_weaver>for now, I suggest just including some code in your own program that reads from /dev/urandom or /dev/random <rain1>oh libguile/random.c has a function read_dev_urandom <rain1>that's only for seeding though, I see <mark_weaver>I agree that we need something better in Guile, but I'd like such a thing to be vetted properly, and that will take time unless someone qualified steps up in the short term. <bavier>in tree-il, one can use make-toplevel-define anywhere to define a procedure in the current module, is there a way to do the same from scheme? <mark_weaver>it sounds like something to avoid, and maybe I can help you find another solution, but section 6.19.8 (Module System Reflection) is the relevant section of the manual. <amz3>Aah! There is officially 4 event loop in Guile!! AHah <amz3>expect mine is rather minimalist <amz3>nalaginrut: will you enter the competition? <nalaginrut>amz3: fortunately, I'm going to write an Artanis specific one, so the answer seems #yes <nalaginrut>but anyway, I think guile-lua-rebirth works tonight <nalaginrut>if everybody likes to play event loop on Guile, it seems proved Guile is nice to do so... <amz3>nalaginrut: yep, maybe.. i've done might to understand better how it works, otherwise I try to focus © <amz3>I try to focus on NLP stuff, but those people each have their own completly different idea of how should be implemented a computer mind so.. <nalaginrut>ACTION think wingo is a big Lua fan, since each time mention guile-lua-rebirth he got excited ;-P <wingo>ACTION not actually a lua fan but it's ok :) <davexunit>wingo: would it be safe to say that you are more of a fan of some of the Lua implementations like LuaJIT than Lua itself? <wingo>davexunit: something like that, but i don't mind using lua, i did it all day today at work. just not a fan :) <bavier>mark_weaver: for the Joy compiler I'm working on, I was toying with the idea of compiling to scheme rather than tree-il <bavier>handling definitions is the thing I'm stuck on at the moment <mark_weaver>compiling to scheme will be problematic for tracking source location information <mark_weaver>tree-il is meant to be quite close to scheme semantically, except for the lack of the macro expander. <bavier>true. I'm mostly concerned about readability, but maybe I can get parse-tree-il working <mark_weaver>see the build-* helper procedures in ice-9/psyntax.scm for examples of helpers to generate tree-il ***linas is now known as ieva
<wirrbel>I don't really get why `values` and `receive` exist <wirrbel>okay, not (values 1 2 3) does not create and return a list object <wirrbel>but are there places where returning a list of values has disadvantages over return multiple values? <rain1>I think receive should be phased out in favor of let-values <wingo>wirrbel: values exists to return multiple values to a continuation, in the same way that calls can take multiple arguments <wingo>you can imagine a guile in which all procedures take just 1 argument <wingo>and if you need more than one parameter, you pack them into a list <wingo>it wouldn't be as efficient and it would be squirrely in some other ways but some ML dialects are like that afaiu <wingo>it's a funny thing to think about, why do most programming languages allow multiple arguments but not multiple return values <wingo>more concretely the calling convention allows multiple values to be returned without allocation, as is the case with multiple arguments <wingo>ACTION not making sense today :) ***ieva is now known as linas
<mark_weaver>wingo: if pairs were immutable, do you suppose that would enable reliable deforestation of lists of arguments and return values? <mark_weaver>I guess it would still be tricky, because it's part of the calling convention of the procedures <wirrbel>if I understand it right, this means that when we would return a list, we would heap-allocate pairs which would make the whole thing less efficient, whereas with values you can put the SCM objects directly to the stack? <wirrbel>not sure if I got your explanation wingo <wingo>i think reliable deforestation would require either static types (to prove things about all callers) or whole-program optimization (same) <wingo>of course locally you can prove many things too <mark_weaver>and loops that can avoid allocation entirely can run a *lot* faster <wingo>multiple values have some other semantic differences too; e.g. (+ (values 1 2) 3) is 4. the extra value is ignored. <mark_weaver>e.g. for procedures like 'floor/' that returns both the quotient and remainder, the use of multiple values enables loops using floor/ to avoid allocatoin. <rain1>is it allowed to ignore the second value? <rain1>i thought they made that illegal in r7rs or something <wingo>rain1: formally in scheme this is unspecified. the implementation can do what it likes <rain1>its so much nicer if it lets you just ignore <wingo>anyway it's not portable but in guile you can ignore extra values for continuations that are not created by call-with-values <wingo>which i guess means i answered my own question :) most pls have single return values for the same reason that guile allows extra values to be discarded :) <wingo>an interesting asymmetry relative to procedure calls <wirrbel>to me, values feels a little like an implementation detail leaking through for something that could (probably) be optimized away by a smart JIT, doesn't it? <rain1>sorta but the idea of a continuation is more fundamental to scheme than just implementation detail <davexunit>multiple return values are much more than an implementation detail <mark_weaver>wirrbel: you could make the same argument that allowing procedures to accept multiple arguments feels like an implementation detail leaking through, and that a smart jit could allow you to always pass multiple arguments as a single list argument. <rain1>how would you make the list though <mark_weaver>making lists in scheme is not difficult. I don't understand your question <davexunit>rephrased: if only single argument functions were allowed, how would one cons? <wirrbel>hmm, it seems there is some connection between `values` and continuations I don't get <rain1>a simple example would be a program like this: (+ (f) 3) <rain1>it would call f and then add the result to 3 <rain1>another way to think about it is: f computes its result and then puts the answer into the continuation "(lambda (x) (+ x 3))" <wirrbel>okay, I know what a Continuatinon is in the CPS literature <rain1>in my example the continuation only has one input <rain1>but way back they thought it would be cool to allow generalized ones that can have multiple values <mark_weaver>I think it was about resolving what seemed like an unnecessary asymmetry between continuations and procedure calls.