IRC channel logs
2024-10-22.log
back to list of logs
<ArneBab>rlb: Python defers string handling quickly to C, that’s why it’s fast at that. <rlb>ArneBab: well, I suppose so do we, so we should be able to fix that right up eventually :) <rlb>And yeah, I did know that (c)python's fairly solid for say dicts for the same reason. <tohoyn>When I define (define-class <x> () re im) and then try (make <x> 1 2) I get error "Invalid initargs: (1 2)". what is wrong here? <daviid>tohoyn: (make <a-class> ...) expect a list of kw val <tohoyn>daviid: I wrote my own version of make to solve this <daviid>also, your slots do not define #:init-keyword, nor any getter, setter and/or accessor ... and wrt 'your own make', and anything you do using goops, i would highly recommend you stick to the protocol, and only specializes for 'real reason', my 2c <tohoyn>daviid: you are right, but I have lots of old code needing that kind of definition of make <daviid>tohoyn: fwiw, goops has been optimized, by wingo, so that when you define a getter/setter/accessor, those are faster then slot-ref slot-set! <daviid>you should upsate those one by one, as you need them, to get rid of 'heisen designed code' ... it will save you time in the long run <moksh>even though I have added GUIX_LOCPATH in my shell path <jaft_r>moksh: you might have better luck over in the #guix channel; not that there isn't some level of overlap between them but this sounds like it might be a specifically Guix circumstance <lloda>is there any circumstance where (vector-set! literal i x) might not throw? the manual still says Guile lets that pass, but i don't think that has been true for a long time <fantazo>hi, as I'm debugging an issue with compiling a guile library, I wondered how I could get guile to give more meaningful stacktraces. It normally displays something like "In unknown file", even when running guile -l error.scm where other languages would print the exact line number in that file of that error. <ekaitz>fantazo: nah, it's always horrible like that... what people do is some REPL driven development to know where things are failing <fantazo>ekaitz: that's sad. I mean that sounds like a more low hanging fruit to fix. Would help a lot in debugging. <ekaitz>fantazo: if there were any low hanging fruit to make this easier it would probably be fixed <ekaitz>i'm very interested these days on improving Guile, but I need more knowledge <euouae>taeaad: re: what I use guile for <euouae>I'll give you one example, I use gdb and I've tried using GNU poke. They both use guile. You can't use them together because... they both use guile. <euouae>Because /both/ programs use libguile, you can't actually link one with the other. I mean... <euouae>Another example: I've tried using Guile to write some code and I wanted nice documentation. All the solutions I've come across are not good. The gold standard here being what Rust/Python does. <ekaitz>euouae: with documentation you mean something like python's sphinx or these kind of documentation generators? <ekaitz>I normally document my things using texinfo <ekaitz>and it's really nice: web, pdf, info... <euouae>Doctests, docstrings, html output <euouae>whatever method you're using texinfo is subparly documented and doesn't cut the mustard <euouae>I've got a polemic attitude because I've made up my mind that I don't like what Guile is doing -- we flamed in another channel with taeaad and I just joined here to be in the right channel while I express the disatisfaction... <ekaitz>how good you consider it is to go to a place where people is trying to do their best and express your disatisfaction? <ekaitz>there are many things wrong with guile, but we could make them better <ekaitz>the language itself and the implementation are very good <ekaitz>the some other things, we could improve <euouae>I don't know who directs guile's resources and whatnot, but issues like the above that I consider serious I have not been able to get any attention for <euouae>I have some skills, I could work on these, but it's not an entirely volunteer project. There is some direction. At the very least, there's a hierarchy where some people have commit access. Those people should be involved in community input & direct community efforts. <ekaitz>well, that's your opinion about how things should be run <ekaitz>i'm not saying it's wrong, i just want to point out the fact it's just your opinion <ekaitz>if you find a very good way to document guile code, i think we all would love to use it <euouae>What my thought was is that Guile needs to redefine/define new constructs for defining procedures,variables,etc that keep track of redefinitions & has place for documentation <euouae>the main issue with attached documentation (docstrings versus ;; comments) is what the symbol even stands for <euouae>depends on the lexical environment <dthompson>the proposed identifier properties in r7rs-large demonstrate a way to attach documentation to any identifier, which sounds like a good path forward to me. <euouae>If it's any identifier, and not just procedures, yes <euouae>so you can document (define x 1)? <euouae>ah yeah, r7rs is not yet complete <dthompson>it's in the draft for the r7rs large standard <euouae>that's good, is that the intention? docstrings? <euouae>What the next step is, that guile decides on a good format to use for docstrings. If it's texinfo, it should be extendable to include macros like \doctest{} or whatnot. <dthompson>the best practice around docstrings is currently to use texinfo. geiser will now parse that when displaying documentation. <dthompson>is a doctest... code embedded in a docstring? <euouae>Yes, and if doctests are to be part of the identifier properties instead, again, there should be a good system to be able to reference them in the documentation <dthompson>embedding tests in docstrings feels very wrong <dthompson>idk it sounds very opinionated to say "tests need to be in docstrings" <euouae>That's not what I said, I said I want doctests in Guile <dthompson>like sure go ahead and parse out tests from docstrings if you want <dthompson>making it a core part of guile? I don't personally see the value. I much prefer having separate test suite files. <euouae>The value is in providing both doctests & usage examples in one <euouae>It's fast too, as you don't need to spin up a separate file <dthompson>but when I write code I don't want to be inside a string literal <euouae>I've alreade made an alternative suggestion that does not do that <dthompson>sorry, I haven't seen it. apparently I joined the channel in the middle of some larger debate <euouae>"Yes, and if doctests are to be part of the identifier properties instead, again, there should be a good system to be able to reference them in the documentation" <euouae>What is that proposal in r7rs-large called? <euouae>So Guile has not implemented this yet? <euouae>I can't find anything online about srfi-213 for guile <dthompson>it requires macro expander changes. no one has attempted to do it. <euouae>I'm guessing that there hasn't been an effort in trying to bring anyone to do it either <dthompson>identifier properties are still a relatively new idea that many schemers haven't grokked yet, including myself. they sound useful but I don't understand all the details. <euouae>see my last messages to ekaitz starting with "I don't know who directs guile [...]" <dthompson>guile has 2 maintainers. andy wingo and ludovic courtes. <euouae>OK two questions: 1) Is there anyone above in GNU who bothers trying to get people in projects? (probably not, but worth asking) and 2) Do you think either of them would care to for people entering the project and trying to contribute in a more directed manner? <euouae>I'll tell you just from reading the NEWS I've noticed a wishlist item is to change libgmp to use the MPN API. I mean, I could do that maybe. But I don't want to just knock down NEWS TODOs. It would be nice to be able to meaningfully discuss a direction of interest and then be helped somewhat in it. E.g. generate some interest in something. <dthompson>1) Guile being a GNU project is more of a historical footnote. There is no one in the greater GNU project trying to coordinate effort on anything related to Guile that I'm aware of. <dthompson>regarding 2) yes, I think both of them would like to encourage more new contributors. the reality is that they have very little time. <euouae>The reality being that they have little time means that there should be at least a third person with maintainer or sub-maintainer status who can reel people in <dthompson>yes I have mentioned this to both of them in the past. they seem open to it. <euouae>I mean, that's good. So I guess you don't want to do it yourself? <Arsen>GNU technically has a 'volunteer coordination' team <dthompson>no, I would just be a third bottleneck. too busy otherwise. <euouae>You're catching me on the wrong time. I spent the past 10 months doing nothing <euouae>Had we had that discussion 10 months ago I would've definitely volunteered, especially if they wanted me <euouae>but now I might be getting a job soon <euouae>I did try to bring some stuff to your attention some months ago, but I did not get the sense that there was much place for me <euouae>You specifically, I'm also surprised with your response to 1). The "GNU extension language" doesn't seem to get much attention from GNU? <dthompson>oh, well, sorry about that. was it in an email or elsewhere? <Arsen>GDB, Autogen and Make are the only GNU programs I know of that support guile outside of guix <dthompson>the "gnu extension language" is also a historical footnote. the guile project was started with this purpose but gnu as a whole has never accepted guile <Arsen>there's also guilemacs but emacs maintainers, AFAIK, refused to integrate it <euouae>Arsen: GDB's guile implementation has quite a few bugs <dthompson>I think it would do guile well to be free of gnu but it's not my decision to make <euouae>Arsen: and I've said this above I think, but due to gdb and GNU poke using libguile, you literally can't link them together! <euouae>That's a /massive/ bug on GNU guile as an extension language... <euouae>Right right, libgc. That's what I meant to say. In any case. <Arsen>but as I said that's temporary, AFAIK pokes new GC is implemented already and just needs integration <euouae>whether it's the direct guile code or the dependency doesn't matter, the point is that you can't be an extension language and have this issue <euouae>even if poke fixes it, it's still a guile issue, no? just hope that whatever doesn't use libgc... <dthompson>sounds like the libgc issue will be addressed by both guile and poke <euouae>it's good to hear some of these news. I guess I wanted to be part of it but I never got the chance <dthompson>will take some time, but whippet will replace it <euouae>I was particularly pissed about that one because I wanted to hack on gdb with poke <dthompson>extending a C program with Scheme is a very dated concept, anyhow <dthompson>the recommended approach is to write a Scheme program that interacts with C via the FFI when necessary <euouae>well, thank you for the good news. it is uplifting to hear about them. <euouae>If I can't get that job I might mail the maintainers and ask them if they want me as a third/sub maintainer <dthompson>the path to maintainer is through many smaller contributions <orva>Slightly related to the contribution conversation and gnu/fsf detachment: guile webpage says more lengthy contribution require CLA, is that truly a followed practise nowadays? <Arsen>FSFs copyright assignment is not a CLA <Arsen>euouae: no, that's not an implication <Arsen>poke does not collect copyrright assignments, GCC does not require them <euouae>Oh sorry, I thought he was talking about the copyright assignment. I don't know what a CLA is <dsmith>The Copyright assignment thing has changed a bit. <Arsen>the latter is owned by the FSF for the most part <euouae>Arsen: ok, it's per-project then? Emacs does it. <orva>Well okay, not CLA but copyright assignment. In practise those tend to have same end goal, or am I missing something? <Arsen>eliz insists that doesn't prevent contributions.. but it postpones mine ;) <euouae>CLA is a thing about not getting them in legal trouble I tihnk <Arsen>orva: the text of a FSF copyright agreement nowadays (as of a few years ago when I did my latest one) contained clauses about copyright transfer and protection against wrongful copyright transfer <Arsen>but also a grant back to the developer (to ensure you still have rights to your work), some other stuff also <euouae>dthompson: many smaller contributions on what? and at what point are the smaller contributions enough? I've spent time in projects like that, and to be dropped out eventually <euouae>No, that's not what I'm asking Arsen, it's a different line of inquiry. <Arsen>sorry, yes, I get what you mean now <dthompson>orva: copyright assignment is no longer a requirement. <euouae>mwette: yeah, that's contorted. of course there's a million ways to do it if you're willing to script your way to get there. but guile should have the One Way to do it. <euouae>if not The One Way, then at least a recommended way. <euouae>mwette: and I recall talking with you in the past about this issue, either here on in the mailing lists. anyway... I'm just not satisfied with current solutions. It should be simple and part of the tools offered by guile <orva>Or is this.. err, incentive mismatch between fsf and gnu projects where other wants copyrights and other wants contributions (and this is really annoying string of questions and I should take the hint and be silent)? <euouae>orva, there is #fsf as well as #gnu and it might be more appropriate there <Arsen>orva: up to the projects really <Arsen>many have lost faith in the FSF due to.. recent actions.. while others, like emacs, refuse to reconsider allegiances <euouae>Thanks for mentoining the gnu volunteer coordination team. There's actually some direction there, I don't know how I missed this in the past. frustrating. things always come to you when you don't need them. <euouae>I had only seen the FSF high-priority project list, which I couldn't contribute to (not my kind of thing) <orva>Well regardless of those, at least most younger people (well, I do still count myself as one) are quite firmly on "copyrights should be held (for code or art), unless you are getting paid for those". So that kind of copyright assignment clauses will put huge barrier of entry for some <orva>Regardless of organization to which those copyrights should be assigned <Arsen>despite numerous maintainers being against it <Arsen>but, people still insisting on assignments are very stuck in the past.. to the point where it holds up development of software they maintain.. <euouae>orva, you get nothing by holding copyright to patches you contribute to FSF projects <singpolyma>Even if you are getting paid you would keep your copyrights, ideally. Until the glorious day we can abolish copyright completely <singpolyma>euouae: sure, if contributors held copyrights they could enable the enforcement of the GPL for example, which FSF will not do if it holds the copyright <Arsen>it kinda saddens me that RMS, as out of touch as he appears to be on various MLs I see him on, still leads GNU (he seems to not yet be aware that ISO C is the norm and that GNU maintainers staff WG14 and WG21 for instance) <euouae>singpolyma: it's the opposite, the FSF argues it will be better able to enforce copyright violations <Arsen>it would be, but so would the SFC.. the argument is mostly about relicensing <Arsen>(the FSF would like to be able to switch code to GPLv4) <singpolyma>euouae: the FSF does not do enforcement, whatever they might claim about reasons for assignment <euouae>singpolyma: why are you saying that? <Arsen>the FSF did, at least, do enforcement <orva>dthompson: Oh! Thank you for digging that up! <Arsen>not sure when their last case was <euouae>singpolyma: what examples do you have where they did not follow up? apart from tiktok <dthompson>the fsf has been on a trajectory of slow decline for a long time. I wouldn't count on them to make a gplv4 that's any good, or do any meaningful enforcement action <Arsen>wrt gpl4, if it happens it'd once again be a community effort with hired lawyers rather than an FSF authored document, likely <Arsen>but yes, I agree, slow decline etc etc <dthompson>signs point to them doing poorly financially <euouae>singpolyma: it's not cheap to sue <euouae>& with what's happening nowadays, it's hard to sue for /that/. <euouae>I mean, big AI companies just steal left and right <euouae>You think you can sue because your 10 LoC function was found in some binary? <dthompson>fsf was ineffective to fight the rise of SaaS, and they're even more ineffective to fight what's happening with LLMs <Arsen>I've not seen them do literally anything on the matter.. <euouae>Nobody can fight what's happening with LLMs, that's like trying to stop the vietnam war with peaceful protesting <singpolyma>We have an infinite number of traditional GPL violations, no need to worry about AI yet <Arsen>the SFC has at least put out a statement <orva>euouae: "you get nothing" is kind of same "nothing" as you get from signing your drawings or name associated to songs you wrote. For some it might be nothing and for some it is everything as it is way to have pride of your handiwork (and leave mark, and numerous other reasons) <lampilelo>euouae: something happened between tiktok and fsf? <singpolyma>No one is talking about 10 line patches either. Usually such small contributors have trouble to prove standing or to even know if their code was used <euouae>singpolyma: just a hyperbole. my point is that big AI companies have siphoned the entire internet into their training sets <singpolyma>Sure. I'm not too worried about that. More concerned with direct GPL violations <euouae>and for all the crap RMS got, I mean look at good ol' Bill. Friends with Epstein and everything, but it's all good <euouae>You don't see people having any trouble accepting paychecks from Microsoft. <euouae>(I haven't followed what makes RMS bad as a board member of the FSF, maybe indeed he's bad.) <Arsen>it is uncertain whether FSF can enforce OBSes copyright, mind you <euouae>I'm kind of impressed with the stuff you know Arsen. Always on point. <euouae>You're welcome. That would imply that the FSF *is* working on these violations unlike what singpolyma has said. Or is this about a differentiation between SFC and FSF? <Arsen>no, the SFC is doing this, not the FSF <euouae>I see. I don't know what the SFC is or how it relates to GNU <Arsen>the FSF might have had a tiny part in this case.. ISTR them writing about it or publishing a statement or such <singpolyma>In an attempt to get them to say something to discredit the case <singpolyma>Yes the case hasn't been "to court" yet for main arguments <euouae>I remember that Vizio case, I've read it before. I guess there's going to be an update "soon" (before 2025?) <Arsen>since it's the US, the winner is the last man not bled to death usually.. hopefully not here <euouae>if it's any comfort, vizio's stock is not doing well <singpolyma>Hopefully they survive long enough that we can make use of the court case results 🙂 <old>well that was an interesting read. I have not read all the messages, but I agree with some of the points mentionned by euouae. Guile has two main maintainers, which are both busy a lots and review/feedback can take a long time. Nothing excessive I believe. I think they are well aware of this problematic and the frustration that this can incur. <old>That being said, for new features like doctests, I think that as a maintainer, if I were to not have enough time for reviewing patch fixes, I would probably avoid adding new features to maintain <old>And, Scheme is like C. Minimal and flexible enough for you to actually implement your own doctests. You don't need it to be part of core Guile. This is not Python with PEP standard. Just implement what you need and maintain it yourself <Arsen>cmon now, scheme is far more elegant than C <old>but they are both minimals in their core. And you are not bound to use the standard library, at the exception for things like threads. <old>The philosophy of C and Scheme are very similar in many ways <ekaitz>from my side, i'm trying to make more Guix people get involved in Guile <ekaitz>i think we share interests so it shouldn't be very hard <ekaitz>I'll prepare an email for the Guix ML calling for people, we'll see <old>Even if there are more peoples, the current structure is a bottleneck I believe <old>Guix has how many maintainers with commit access? Guile how many? <ekaitz>with time, increasing the interest in Guile may be a good way to find good developers that might become maintainers in the future <ekaitz>this is not a short term solution but a long term one <ekaitz>in the short term i don't think there's much we can do <old>Well I for one use Guile a lots. I've made a few patches in the past, but I don't know how I can help more than that <old>I do have free time and is very good in C, while good in Scheme. But still, don't know how can I contribute more <old>the list of bugs to fix seems really just a bag of dust hanging there for 10 years now. Which one are a priorities? idk <old>so I fix the one I encountered during my usage of Guile, but that's pretty much it <ekaitz>old: well, that's more than enough, if we just had more people doing the same it would be great <ekaitz>different people, different usecases, different problems <euouae>old, and ... just like C, Guile does not have it implemented. You know it's almost impossible to find a hash table implementation in pure C89 in C? Even something as trivial as that does not exist. <euouae>of course hash table implementations exist, but strict adherence to C89 makes it almost impossible to find <old>Well I for one don't care about C89 <euouae>There are solutions to the docstring issue, but I wasn't satisfied... <old>I work moslty in GNU99 and almost everybody now is using a toolchain that support the C11 memory model <euouae>I contributed to a strict C89 project that is still used by old machines and it needed a hash table implementation <euouae>the main maintainer actually got around to writing one eventually to fix some optimization issue <old>sure. Can't be that hard <old>Well then move on to C11. I don't see a reason to stick to C89. Just cross-compile if the old machine does not have a recent toolchain <euouae>C makes sure of it with all the issues around integer sizes and whatnot... anyway the point was that sometimes being authoritative is nice <old>look at _Atomic in C11 <old>look at other stuff the commitee is putting in the language. They all get it wrong <euouae>I like how Rust is doing documentation <old>Now they could add some hashtable. They won't get it right <old>I for one, use Userspace RCU for hashtable <euouae>I don't want C to add a hashtable though -- that wasn't my point <euouae>My point was that some things, despite being desired and certainly possible, have not been done. You need to at least nudge people <euouae>but yeah... I'll ... stop talking about this now. I need to wait for the newer advances in Guile and see where it stands afterwards. It's exciting to know that, at least, I'll be able to use gdb + GNU poke <old>what is your use case with Poke? <old>I've look into it, but I haven't found a practical use case yet <euouae>I wanted to write some tutorials for gdb and poke exploring ELF binaries and such. Maybe better suited for Ghidra. Just naive stuff. <euouae>But honestly, I wanted to write a tutorial on how ELF files work. <tohoyn>I've got a Tree-IL line with about 20k lines giving error message "Throw to key `match-error' with args `("match" "no matching pattern" ())'." when I try to compile it with guild. I use guile 3.0.10 (Oct 12 version from git). Is there any way to find the location of the error in the source file? <tohoyn>but it would be good to obtain locations of Tree-IL errors in source files <dthompson>the match error should at least say where in guile's compiler the error happened <dthompson>that will identify the 'match' form that could throw a more useful exception rather than a generic match-error <lampilelo>debuggability of guile is not very good overall <lampilelo>about the maintainer situation, i think that the few people active on mailing lists triaging code submissions and giving feedback to potential contributors should get the commit rights, or at least some special treatment and recognition when it comes to rasing awarenes of the maintainers to look through patches already code reviewed by them <dthompson>well, we have rlb going a great job in this regard. <euouae>re special rights. both courtes and wingo are obviously seasoned experts in the subjects, but it doesn't hurt to have more layers in the project <euouae>and yes debuggability is /another/ issue of guile... <euouae>at the very least, identifying these issues in the front page of guile instead of hiding them may motivate people to work on small parts to impove these issues. <euouae>but even modifying the front page of guile is a large task, it'd have to go through courtes/wingo, again both are pretty busy, etc <lampilelo>but it doesn't really make sense to complain about "this needs work", "that would be nice", it's just a matter of making a prototype and talking about it here and mailing lists <lampilelo>i remember reading emacs-devel and people discussing some problem there in a hundreds of mails long thread and the conversation would always just die down because people couldn't agree on the design, until someone finally just made a prototype <lampilelo>this is how we got tree-sitter in emacs afair <euouae>I'm not investing that kind of time before at least confirming that there is interest <euouae>that is a success story but there's many times where I've invested my time and efforts to be shut down because the maintainer didn't want X <lampilelo>the i guess you're doing the right thing to gauge if there's interest <lampilelo>euouae: so what would YOU want to work on then? i don't think we should change from texinfo to something else since it's one of the things that keep me using guile over any other scheme, but it doesn't mean the current system can't be improved <ekaitz>euouae: but there is interest, you have the interest <old>Now why would this need to be in core Guile <old>you are free to write anything in the doc of a function. Your own format included <euouae>I did not ask this to be in core Guile. The first misinterpretation (which I corrected...) was from dthompson in this regard <euouae>I also understand what the task is, the docstring is parsed, the unit tests are extracted, and ran. yes. <euouae>I just wish people wouldn't assume the worst interpretation of something -- a very common thing on IRC. There's a very real distance between the tooling of Guile and Rust, and you won <euouae>you won't cover it by telling people that it can be done and here's a poc <euouae>(also, I'm confused about how your "Throw to key" works) <euouae>And also a poc can be very far from an actual, attractive solution. <euouae>For example: your doctest: doesn't work with texinfo does it? i.e. it's not rendered specially or anything. <euouae>Another issue: your eval of the doctests has side effects. certainly not desirable inter-procedure wise, and I'm not even sure if between doctests in a single procedure it's desirable. <old>hey I made a poc in 5 mins. nothing robust here. I don't care about doctest at all anyway <old>I think it is actually a very bad way of testing <old>we get it, Rust is the best thing that happened to the field of CS in the past 100 years <euouae>I didn't say that either, I'm specifically enjoying the documentation generation in rust <ane>wait, isn't there doctesting in guile-lib <dthompson>rust/python are ecosystems with huge amounts of money flowing through them. <euouae>manuals are more "expensive" which is why less projects have them <dthompson>I really don't see much in the rust space that I would want to copy <euouae>like I said, python does it right too w.r.t docs <euouae>anyway I don't know if you guys are arguing with me or just discussing your tangent about rust, but I have to go now, thanks for the discussion, I appreciate the new things I learned, have a good one. <dthompson>it's not just me that feels a somewhat hostile tone is it? <dthompson>I personally don't like cluttering my implementation with tests but using procedure properties seems like a good way to do it as it's actual scheme data and not code stuffed into a string literal <mwette>dthompson: no, you are not the only one <ane>dthompson: wait, yes, ArneBab spoke about that last week here <ArneBab>I’ve been using that for a long time now, and it is one of the nicest ways to write code ☺ <ArneBab>I came from tests in docstrings, by the way, posted the initial idea on guile-devel, and then someone said, procedure properties would be better. I tried and they were right. So I wrapped srfi-64 around procedure properties — with a few simplifications (like taking the test name directly from the procedure name) to minimize the ceremony. <ArneBab>ACTION likes leveraging existing tools to build something that just works and requires as little maintenance as possible :-) <jaft_r>ArneBab: would you be able to provide a small example? Not coming together in my head, just from descriptions. <ArneBab>jaft_r: here’s one from the email linked above: (define (foo) #((tests (test-equal "bar" (foo)))) "bar") <ArneBab>I also tend to add a main block to the files, so I can run all tests of that file with ./filename.scm --test <ArneBab>And then I have an emacs binding: ;; (progn (defun test-this-file () (interactive) (save-current-buffer) (async-shell-command (concat (buffer-file-name (current-buffer)) " --test"))) (local-set-key (kbd "<f9>") 'test-this-file) <ArneBab>So my development workflow becomes: add a test, hit F9 (see that it fails), make it succeed. Add the next test. <ArneBab>This does not replace an external testsuite with integration tests, but it gives a really nice base of unit tests. <shcv>how do I eval code that contains a (use-modules ...) in it? <ekaitz>shcv: (eval '(use-modules (ice-9 peg)) (interaction-environment))