<dsmith>sneek: later tell nckx Thanks for the heads up regarding the bot. <sneek>Welcome back lampilelo, you have 1 message! <sneek>lampilelo, lampilelo says: foo <sneek>lampilelo, leoprikler says: foo <apteryx>is anything available in Guile as an alternative to shelling out to pgrep? <leoprikler>you'd probably have to stitch it together using ffi calls <civodul>(guix scripts processes) has some stuff <nckx>dsmith-work: Thank you for fixing it! <chrislck>Small query about the schemified read() -- this slowdown is during compile only, right? if my code doesn't use eval, .go files will still be as lightning fast as ever? <NathanSchmidt>Hello! I'm currently trying to figure out an error pertaining to the use of predicate checking in (ice-9 getopt-long). I'm using guile-2.2 on Debian 10. Currently getting a backtrace ending in "ERROR: Wrong type to apply: str->num?" whenever I run it with an option which does predicate checking (e.g. for --length-dmem 1024, but not with --help or <NathanSchmidt>According to the reference[0], "you may need to use quasiquotes to get it into grammar" pertaining to the predicate property. I'm not entirely sure of what that means. Perhaps that has something to do with it? <NathanSchmidt>The reference states that for (predicate func), func should be a function accepting a string and returning a bool - which it is. <RhodiumToad>that sounds like it wants the actual procedure value to be in the form, not a symbol <RhodiumToad>`((help ...) (length-imem (value #t) (predicate ,str->num?)) ...) <NathanSchmidt>I have come across something that leads me to believe the docs are inadequate. ***sneek_ is now known as sneek
<NathanSchmidt>By using the docs for chicken, I have made progress, though I'm still working at getting the desired result from my program <RhodiumToad>did you remember to change the ' to ` before the value? <RhodiumToad>(because the error you got is the error you would get if you failed to do so) <NathanSchmidt>I did not remember to change the ' to `. It is now working, it seems. <Zelphir>Hi! I have a question about organizing imports or modules. I often have modules in subdirectories and stuff. I see myself facing the following 3 ways of dealing with it: (1) add subdirectories to the load path when calling guile via the -L argument (2) adding the whole location of a module to its name, as in: (library (app lib mymodule) (export ...) (import ...)) or (define-module (app lib mymodule) ...) or (3) make use of (add-to-loadpath ...) <Zelphir>stuff. Which one is the preferred way? Or is there yet another way? <leoprikler>Zelphir, the preferred way is to have GUILE_LOAD_PATH point to the top of you module tree, e.g. /path/to/src/modules and construct load paths from there <leoprikler>e.g. if you have /app/lib/mymodule.scm, you'd use that as (app lib mymodule) <leoprikler>you may want to re-export stuff from (app lib mymodule) in a more top-level module <leoprikler>for instance, in Tsukundere (a VN engine I'm developing), I use subdirectories for the implementation parts and export all functions, that should be publicly available from (tsukundere) <leoprikler>(ice-9 peg) is also divided into parts, that are re-exported <leoprikler>As are many things in the Guile source code itself. <Zelphir>Ah, ok with re-export I could shorten that list of parts that identify a module. I will consider that in my case, thanks! <Zelphir>I was also thinking about: "What if I need to move the module into another directory?" Then I would have to adapt the module identifying list again and all the places where I import it. But I guess that's normal? Like in any (most?) other languages, I would have to adapt at least the imports. <leoprikler>If lib is usable as its own outside the context of app, perhaps you should implement it separately (i.e. as (lib)), but other than that I see few issues <Zelphir>Yep, that's what I try with fslib. Basically I don't want to have a copy in each project and then modify them all independently. If I can install them as dependency with guix, I should be able to reference it without adding manually to the load path or having a copy everywhere. <leoprikler>Perhaps also provide an Automake setup for traditional distros if that's a concern. <yoctocell>Is there a way to "apply" a macro? Let's say I had a list of booleans, and I wanted to "apply" the 'or' macro on the elements of the list. If 'or' was a procedure, I would do (apply or LIST-OF-BOOLS), but it is a macro so that won't work. <lampilelo>yoctocell: wait, what? i thought it was #emacs, this shouldn't work for guile, would work with primitive-eval <lampilelo>people here don't take kindly to using eval, though <lampilelo>last time i mentioned it someone added it to a ban list <lampilelo>i think someone even mentioned "root of all evil" or something like that <lampilelo>yoctocell: so the correct thing to do would be using "(any identity lst)" from srfi-1 *chrislck stashes the rope now <Zelphir>You could also put ~or~ in a procedure and then apply the procedure using apply. <Zelphir>Not sure this is entirely correct, but something like the following: <Zelphir>Ah yes, that makes sense. You would not want to return only #t, if you got other things than booleans in that list of arguments. <lampilelo>it's elisp written for guile vm, it creates a binding to guile's define-peg-pattern so that it can be used from elisp <Zelphir>"Nil - A third boolean." -- That takes me back to database lectures :D <leoprikler>@ is a real life-saver in our elisp bindings, it makes so many things possible <rlb>(Also quite useful for clj dialects.) <Noisytoot>leoprikler, It's not a Scheme, but it is a Lisp <rlb>It has a lot of similarities with Scheme, but among any number of other things, it's notably polymorphic by default (e.g. with respect to functions that operate on "sequences" rather than concrete types like vector, cons-pair, etc.). Also notable for being "persistent (immutable) by default", fwiw. <wingo>here's a concept: $kfun whose clause is $kargs instead of $kclause. could denote a function that doesn't have to check number of incoming args <wingo>could only be called via $callk, and requires caller to provide the right arity <wingo>would be nice to unify with $kclause somehow such that body of $kclause could be one of these new $kfun's <wingo>would allow eliding argument checks for calls within a compilation unit <wingo>could allow some callees to avoid checking if stack space were available, if we had a red zone... <rlb>Sounds interesting. Do we already support any kind of type-check elision? <wingo>there is "global" (i.e. across basic blocks) type analysis <wingo>can elide redundant type checks <wingo>redundant == type check A dominates type check A' <wingo>but interprocedural, there's nothing <rlb>Ahh, ok. If it were feasible, I suppose interprocedural could give another advantage to scheme code over C implementations... <cheim0>davexunit: for the multisampling capability check in chickadee, I'm gonna focus on adding a binding for SDL_GL_ExtensionSupported to guile-sdl2 <leoprikler>sneek later tell Zelphir the manual only talks about languages implemented in Guile itself, not third party projects