IRC channel logs


back to list of logs

<dsmith>sneek: botsnack
<dsmith>nckx: Thanks for the heads up.
<dsmith>sneek: later tell nckx Thanks for the heads up regarding the bot.
<sneek>Got it.
<lampilelo>sneek: later tell lampilelo foo
<sneek>Will do.
<sneek>Welcome back lampilelo, you have 1 message!
<sneek>lampilelo, lampilelo says: foo
<leoprikler>sneek tell lampilelo foo
<sneek>lampilelo, leoprikler says: foo
<lampilelo>didn't know about that command
<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>or rather (scandir "/proc") :-)
<civodul>(guix scripts processes) has some stuff
<civodul>and (guix store roots)
<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>no options at all). The relevant part of my program is here:
<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> [0]
<NathanSchmidt>The reference states that for (predicate func), func should be a function accepting a string and returning a bool - which it is.
<NathanSchmidt>(str->num? "42") returns '#t', for example.
<NathanSchmidt>Where str->num? is given as:
<NathanSchmidt>(define (str->num? s) (string-every char-set:digit s))
<RhodiumToad>that sounds like it wants the actual procedure value to be in the form, not a symbol
<RhodiumToad>so the option-spec might need to be like
<RhodiumToad>`((help ...) (length-imem (value #t) (predicate ,str->num?)) ...)
<RhodiumToad>that would be what I'd try first, anyway
<NathanSchmidt>I've since tried that with the backtrace giving:
<NathanSchmidt>ERROR: Wrong type to apply: (unquote str->num?)
<NathanSchmidt>I do appreciate the suggestion, by the way.
<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>I don't get that error
<RhodiumToad>what exactly did you do?
<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.
<NathanSchmidt>I greatly appreciate your help. Thank you.
<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>Exactly, you need to rewrite your imports then.
<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>Yep, you should go for a Guix package.
<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: (eval `(or ,@lst))
<yoctocell>lampilelo: Works like a charm, Thank you!
<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
<chrislck>get the rope!
<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
<chrislck>eval is evil
<lampilelo>yoctocell: so the correct thing to do would be using "(any identity lst)" from srfi-1
<lampilelo>because chrislck is watching
*chrislck stashes the rope now
<lampilelo>i think you meant "for 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>(define myor
<Zelphir> (lambda (. args)
<Zelphir> (cond
<Zelphir> [(null? args) #f]
<Zelphir> [(car args) #t]
<Zelphir> [else
<Zelphir> (apply myor (cdr args))])))
<chrislck>s/#t/=> identity
<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.
<leoprikler>chrislck: What do you think about this use for eval?
<lampilelo>i think defmacro is also frowned upon :D
<leoprikler>This is Elisp.
<lampilelo>idk, feels wrong to mix the two
<Zelphir>So it is Guile outputting Elisp?
<Zelphir>Or completely Elisp?
<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
<lampilelo>guile can interpret elisp
<Zelphir>"Nil - A third boolean." -- That takes me back to database lectures :D
<leoprikler>Zelphir: It's Elisp evaling Scheme.
<leoprikler>@ is a real life-saver in our elisp bindings, it makes so many things possible
<rlb>(Also quite useful for clj dialects.)
<leoprikler>Is Clojure not a Scheme?
<Noisytoot>leoprikler, It's not a Scheme, but it is a Lisp
<leoprikler>Ahh, okay
<lampilelo>it's a scheme to close stuff
<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>but only intra-procedural
<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
<Zelphir> Couldn't that "python-on-guile" be added there?
<leoprikler>sneek later tell Zelphir the manual only talks about languages implemented in Guile itself, not third party projects