IRC channel logs

2018-07-10.log

back to list of logs

<ison[m]>Why is it that I can't compare classes in a "case" statement such as (case (class-of obj) ((<my_class>) ...)) and it always falls through to the "else" block? Even though "case" is said to use eqv? as its comparison and (eqv? (class-of obj) <my_class>) returns true?
<ison[m]>Oh it looks like the class names were cut out due to the greater-than less-than signs. If I use square brackets instead then it should be (case (class-of obj) (([my_class]) ...)) which fails, and yet (eqv? (class-of obj) [my_class]) succeeds
<rekado_>I found some odd differences in behaviour between compiled and interpreted Scheme code.
<rekado_>I have a module that uses the SDL2 bindings.
<rekado_>when it is compiled everything works fine.
<rekado_>when it is not compiled, however, Guile crashes.
<amz3>the Scheme 2018 CfP is prolonged to 23 July https://brinckerhoff.org/scheme2018/
<rekado_>the error is not very helpful: In procedure symbol->string: Wrong type argument in position 1 (expecting symbol): #:sdl2
<rekado_>“sdl2” is the prefix that I use for the (sdl2 mixer) import.
<amz3>that looks like a keyword
<rekado_>the backtrace shows (resolve-interface (sdl2 mixer) …), and then “for-each” over all exported symbols, then “(symbol-append #:sdl2 %default-chunk-size)”, where “%default-chunk-size” is the first exported value.
<rekado_>I don’t know why it wants to prepend a keyword instead of the plain symbol that I asked it to use as a prefix.
<amz3>that's the question I was going to ask
<rekado_>I don’t have this problem when compiling the module.
<amz3>because the REPL says:
<amz3>scheme@(guile-user)> (symbol? #:sdl2)
<amz3>$2 = #f
<rekado_>this is with Guile 2.2.4 (but I had the same problem with 2.2.3)
<amz3>and there is the difference between compiled and non-compiled
<amz3>rekado_: are you sure the use-modules expression doesn't have invisible characters in the prefix argument?
<amz3>sometime it happens when typing stuff like alt-gr + space
<amz3>by mistake
<amz3>anyway, good luck
<rekado_>I’m sure there are no invisible characters.
<daviid>rekado_: I would write a snipset that reproduce this 'false/unexpected' keyword, but using a guile core module instead, say (ice-9 popen) for example, then report a bug
<rekado_>I wonder if maybe this is due to some reader shenanigans in one of the modules I use.
<rekado_>maybe in guile-sdl2 or in chickadee.
<rekado_>because it seems fine when using a prefix that does not end on a colon.
<rekado_>hmm, (chickadee render) includes this line “#:use-module (srfi srfi-88)”. This is intended to cause (keyword? foo:) to be #t.
<rekado_>is it a bug that this affects the interpreter globally?
<daviid>rekado_: from what you wrote so far, I think the bug is in the compiler, which should also trigger the error, since #:sdl2 is a kw? but to go ahead, may be you can enhance your code to use keyword? (srfi-88) and symbol?, then either use keyword->string or symbol->string ... maybe
<rekado_>my module does not use srfi-88.
<rekado_>it’s just a module I use that happens to use srfi-88.
<daviid>rekado_: but once it has been imported, the reader has been affected
<rekado_>my expectation is that the effects of srfi-88 are local to the module using it.
<daviid>rekado_: I don't think reader options are local, not sure though
<rekado_>this caught me by surprise, because as a user I cannot know what modules are used in other libraries.
<daviid>rekado_: reader options are terrible beasts!! usually highly discouraged, afaict, but again, 'just' to go ahead (you may analyse and report a bug later), you could import srfi-88 and do as I suggested above
<daviid>rekado_: in oder to confirm (or not) that reader options are not local, you may print (read-options) from your module, and see, maybe I'm wrong
<civodul>oh yes, srfi-88 should avoided
<daviid>or (read-options 'help)
<civodul>rekado_: if you use reader extensions, you have to enable them both at macro-expansion time and at eval/load time
<civodul>so you need an eval-when
<civodul>though i suppose if you #:use-module (srfi srfi-88) it does the right thing?
<rekado_>I don’t but davexunit does in chickadee :)
<civodul>what happened to davexunit? :-)
<rekado_>the use of srfi-88 in chickadee appears to affect the prefix argument “baz:” in “#:use-module ((foo bar) #:prefix baz:)” in my own code.
<rekado_>this is “#:prefix baz:” for those of you who see a smiley face instead
<daviid>haha
<rekado_>I have another problem involving chickadee, guile-sdl2, and Guix.
<rekado_>I’m trying to build a Guix package for the latest development version of chickadee, but the compilation of one module (chickadee input keyboard) fails with “no code for module (sdl2 input keyboard)”, even though it exists.
<civodul>rekado_: because reader macros are global, "baz:" is transformed into keyword #:baz
<civodul>bad bad bad!
<rekado_>the (chickadee input keyboard) module is trivial and other modules that use sdl2 modules can be compiled just fine.
<daviid>rekado_: I would display (pk ...) %load-path from your guix attempt to build ... surely it misses a path
<rekado_>oops, the load path is fine, but guile-sdl2 did not install the (sdl2 input keyboard) module…
<rekado_>maybe a problem in the Makefile.am
<rekado_>yup, the file is not listed.
<rekado_>sorry for the noise: it’s because latest chickadee depends on latest (unreleased) guile-sdl2.
<daviid>rekado_: that was not noise, but fun and insteresting (it reminded me about these reader options side effects ...) and it is so much more fun when #guile is lively ... please make more 'noise' like this :)
<dsmith-work>Morning Greetings, Guilers
<dsmith-work>ison[m]: Notice that for case "Each <datum> is an external representation of some object."
<dsmith-work>ison[m]: I think that basicly means the things are quoted.
<davexunit>rekado: I didn't realize that srfi-88 introduced weird reader macros
<davexunit>I hadn't noticed any issues from it
<davexunit>I included it for one small thing so I can get rid of it and get the job done another way
<davexunit>yeah, keyword->string is all I use it for
<civodul>heya davexunit :-)
<davexunit>hey civodul
<davexunit>I'll just use (compose symbol->string keyword->symbol) instead
<civodul>sounds reasonable
<davexunit>two hops is no big deal because the code is evald at macro expansion time anyway
<davexunit>I had no idea that srfi 88 introduced global reader macros
<davexunit>civodul: what is the definitive right place to install .go files?
<davexunit>I feel like I've used 3 different places over the years and I always get some mail about how I'm doing the wrong thing
<civodul>davexunit: the Definitively Right Place is $libdir/guile/2.2/site-ccache
<davexunit>the latest being rekado saying he had to patch guile-sdl2 and chickadee for guix. but I've been using them with guix without an issue :(
<davexunit>civodul: okay thanks, that is what I have now.
<davexunit>I'm not sure why rekado needed to patch my makefiles to use $moddir
<davexunit>I just checked and the official guix package recipe for guile-sdl2 includes such a patch
<davexunit>I want to make new releases of guile-sdl2 and chickadee but don't want to have this problem anymore
<rekado>… I added that when adding guile-chickadee, because it would not find the sdl2 modules at build time :-/
<rekado>so you shouldn’t take that patch as confirmation that I’m right.
<rekado>I could also be wrong in two places.
<davexunit>heh, so I'm reading through my own sources to refresh my memory a bit and I can see that I do this, too
<davexunit>something is not right here, and I suspect it's a Guix bug.
<davexunit>my profile manifest clearly lists 2 search paths for GUILE_LOAD_COMPILED_PATH: lib/guile/2.2/site-ccache and share/guile/site/2.2
<davexunit>however only share/guile/site/2.2 ends up in my shell environment
<davexunit>'guix package' seems to do the right thing, 'guix environment' does not
<davexunit>well, nevermind. seems to be an issue with my shell configuration. ignore me.
<civodul>:-)
<davexunit>... well... now I'm back to suspecting a guix bug.
<davexunit>I'll just shut up until I have something nailed down
<rekado>:D
<OrangeShark>I have this for my go files godir=$(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/site-ccache
<davexunit>OrangeShark: that is correct, from what I understand
<OrangeShark>daviid has argued that this doesn't really follow the GNU Coding Standards though. It seems what we currently do is similar to how GNU Emacs packages are installed.
<davexunit>rekado: found it! small typo that I just couldn't see for a long time
<davexunit>"ccache" instead of "site-ccache" in the Makefile. I probably have this issue in most of my projects. sigh...
<OrangeShark>I separated the guile bits from my automake files so they can be easily copied and pasted to my projects
<davexunit>OrangeShark: good idea
<brendyn> https://www.gnu.org/software/guile/manual/html_node/SLIB-installation.html#SLIB-installation
<brendyn>This pages links to a page that doesn't exist https://www.gnu.org/software/guile/manual/slib/Installation.html#Installation