IRC channel logs


back to list of logs

<RhodiumToad>daviid: tested on 3.0.7
<RhodiumToad>daviid: the problem seems to be with trying to re-export the merged generic
<RhodiumToad>i.e. I have a module (foo) that uses various submodules (foo bar) (foo baz) etc. and (foo bar) and (foo baz) both define a method with the same name on different classes,
<RhodiumToad>and I want the module that includes (foo) to be able to use it
<RhodiumToad>it works to predefine the generic in a third module used by both (foo bar) and (foo baz), but that's annoying
<RhodiumToad>and I can reproduce the thing where it behaves differently depending on whether it recompiled the module or not
<RhodiumToad>sneek, later tell daviid
<psyklax>Looks like it works fine in Guix, but the library itself.. I'm not sure
<psyklax>;;; <stdin>:8:3: warning: possibly unbound variable `draw-text'
<psyklax>;;; <stdin>:8:30: warning: possibly unbound variable `vec2'
<psyklax>the hello world example on the chickadee page
<psyklax>without using GUIX_PROFILE first, I get "no code for module (chickadee)" so I know that it is actually loading now.
<daviid>RhodiumToad: will look at it and get back asap, tx for the example
<sneek>Welcome back daviid, you have 1 message!
<sneek>daviid, RhodiumToad says:
<RhodiumToad>daviid: note that removing the #:re-export makes it work perfectly, _except_ that then the module that uses (gentst) can't then see the foo generic at all
<RhodiumToad>whereas with the #:re-export, it blows up even inside the (gentst) module
<RhodiumToad>oh now this is interesting
<daviid>RhodiumToad: right, all this is 'known' conflicts between the module system and clos, which by definition does not want any module 'protection'
<RhodiumToad>if you remove the #:re-export and put (re-export foo) in the body of the gentst module, it seems to work
<RhodiumToad>so maybe the issue here is that something is being processed in the wrong order?
<daviid>RhodiumToad: yes, but the problem is a bit more complicated than that though, and you'd want a 100% all time functionning solution to the problem ... i mean even when/after you or user(s) change 'things' and all of a sudden, module1 is not the one that defines the generic anymore more ...
<RhodiumToad>why would that matter?
<daviid>i'll try and fix it here, then get back...
<daviid>because redefinibng a generic in goops, unlikethe clos std specify, woulkd notraise anerror, butredeing a new bindibng,silently hidding thepreviousdef ... among other problems ...
<daviid>[my spacebar key 'borke' ... sorry]
<daviid>RhodiumToad: your setting is correct, though i still would suggest/make a few comments, but 1st things 1st, i suspect that you do/did not set things correctly in your repl - as in having a .guile that use (oop goops) and calls default-duplicate-binding-handler
<RhodiumToad>the only thing in .guile is enabling readline
<daviid>that is the cause of the warning
<daviid>could you try to add this
<RhodiumToad>(use-modules (ice-9 readline)) (activate-readline)
<daviid>(use-modules (oop goops))
<daviid> '(merge-generics replace warn-override-core warn last))
<daviid>quit and retry
<RhodiumToad>in .guile? why would I want to do that, since that wouldn't be in effect when running a script?
<daviid>please try, then w'll 'talk'
<daviid>or call manually before use gentst if you prefer
<RhodiumToad>still get the warning
<RhodiumToad>and it still fails
<RhodiumToad>still fails when not recompiling the module, that is
<RhodiumToad>that's with running ,use (oop goops) and (default-duplicate-binding-handler '(merge-generics replace warn-override-core warn last)) in the repl before doing ,use (gentst)
<daviid>could you try 'forcing a recompilation', after you ,use (oop goops) and ddefault-duplicate-binding-handler
<RhodiumToad>if I touch the files, so that it recompiles, I still get the WARNING from ,use but calling (test) works,
<RhodiumToad>if I don't touch them, I get the WARNING but (test) fails with a missing method
<daviid>ok, here i don't get any warning
<RhodiumToad>can you show an exact transcript, using guile -q to take the .guile contents out of the issue?
<daviid>but (test) fails here as well -
<RhodiumToad>ok, even weirder: if I compile the modules in advance with guild compile, I still get the WARNING, but (test) works
<RhodiumToad>oh, scratch that, user error
<daviid>RhodiumToad: i'll fix this here and paste... give me a few minutes
<RhodiumToad>ok, tried precompiling again, it gives the same result as auto-compilation, i.e. (test) fails
<daviid>RhodiumToad: but you need those commands in your .guile, or init.scm _and_ any script (as in user's script, not knowing if they have a 'proper .guile' setting with this respect ...)
<daviid>also note that you do not re-export the classes
<RhodiumToad>that shouldn't matter, whether the script can see the class names doesn't affect whether it might see instances and call methods on them
<RhodiumToad>ok. take a look at this:
<daviid>RhodiumToad: well, you shouldn't need to re-export foo either then :)
<RhodiumToad>uh, without the re-export, the caller can't do (foo whatever) because foo is unbound
<RhodiumToad>anyway, adding the class names to #:re-export changes nothing, just tried
<daviid>i know - just making a side note, how would you inspect the class(ers) in the repl for example
<RhodiumToad>further oddity: if I do (default-duplicate-binding-handler '(merge-generics replace check)) I still get warnings and not errors
<RhodiumToad>in fact... nothing I do with default-duplicate-binding-handler seems to have any effect at all?
<RhodiumToad>default-duplicate-binding-handler affects only (current-module)
<RhodiumToad>or not... reading
<daviid>i got it working fine here.
<daviid>but ineeded to change a few things
<daviid>sorry i am a bit on/off here so a bit slow to communicate
<RhodiumToad>does it still work even if it's already compiled, and is that with guile -q or did you change the files at all?
<daviid>RhodiumToad: yes, it will always work :) - you can't do guile -q, it needs the setting i told you ... but 1st things 1st, let1s try to get it work on your side, then i can explain and then you may change things 'as you porefer' ...
<daviid>RhodiumToad: can you grab 2 modules from g-golf, install/rename them where you wish, we'll need them in my updated 'your example'
<daviid> and
<RhodiumToad>if you didn't use guile -q, then paste your whole .guile
<daviid>RhodiumToad: could you instead comment the readline 'stuff'
<daviid>and here is your updated example files -
<RhodiumToad>I tried it with guile -q so it's nothing to do with the readline stuff
<daviid>note that i touched only gentst1 and gentst2 to remove the inheritance to <object>, which you don't need
<RhodiumToad>ok but I told you before that moving the #:re-export in the define-module to a (re-export foo) form in the body makes it work
<RhodiumToad>so none of your extra stuff is relevant to this, it may be fixing other problems, but unrelated ones
<RhodiumToad>this is why I think this is an order-of-operations problem
<daviid>RhodiumToad: that #:re-export and (re-export ...) behave differently is actually a guile bug, imo - and the problem is 'larger' then that imo
<daviid>(a) as a user, you should never have to know when to use export or re-export [when dealing with methods and generic functions that is, ofc]
<daviid>then (b) you(users) should never call define-generic 'themselves', certainly not if you share the code with others
<daviid>anyway, does this work on your side?
<RhodiumToad>I haven't tested it because I already know that moving the re-export out of the define-module form works
<RhodiumToad>ok. and looking at the code for define-module*, it is GLARINGLY obvious
<RhodiumToad>re-export is processed before duplicates
<RhodiumToad>so at the point of processing re-export, the duplicates-handlers slot of the current module is empty, causing the hardcoded default to be used
<RhodiumToad>(which can't be overridden at that point)
<daviid>in your intial example, you do not even need to #:re-export, nor (re-export foo - unless you'd want to call it manually in the repl that is
<RhodiumToad>I do need the re-export for the actual use-case, which is specifically to call (foo ...) in the outer script
<RhodiumToad>without re-exporting it _somehow_ it is not visible
<RhodiumToad>the actual use-case is that (libarchive reader) defines an <archive-reader> class with an (open-filename ...) method,
<RhodiumToad>and (libarchive writer) defines <archive-writer> with a method of the same name
<RhodiumToad>a script that wants, say, to copy an archive will need to import both, and call (open-filename) on either kind of object
<daviid>RhodiumToad: ok, then you (gentst) need to re-export the class-names as well
<RhodiumToad>yes, the real code does that
<RhodiumToad>the example didn't because it was a minimal example :-)
<daviid>it's ok
<RhodiumToad>I also verified that re-exporting the class names made no difference
<RhodiumToad>this is definitely down to the order in which define-module* processes the various parameters
<RhodiumToad>you can see it does exports, replacements, imports, re-exports, re-export-replacements, autoloads, and _then_ processes the duplicates keyword
<RhodiumToad>haha. this also works:
<RhodiumToad>(define-module (gentst) #:use-module (oop goops) #:duplicates (merge-generics replace check))
<RhodiumToad>(define-module (gentst) ...real definition here...)
<RhodiumToad>i.e. define it twice, forcing the duplicate handler to be set the first time
<RhodiumToad>ok. next challenge: what is the best way to define a (close ...) method
<RhodiumToad>all the obvious attempts break given that (close) is a builtin procedure
<daviid>RhodiumToad: look at and 'reproduce what is done in g-golf for connect,let me paste
<daviid> - line 48, then 76 - 81
<daviid>and your 'new method' after the above ofc ...
<RhodiumToad>I tried this:
<RhodiumToad>(define close (ensure-generic (@@ (guile) close) 'close))
<RhodiumToad>which seemed to suffice
<RhodiumToad>(along with a #:replace (close) in the define-module)
<RhodiumToad>that saves having another layer of wrapping around the builtin (close)
<RhodiumToad>(it still ends up as a method in the generic, but without needing an intermediate procedure between the method object and the builtin)
<RhodiumToad>also, while this doesn't matter for connect, I think it preserves the arity better
<RhodiumToad>oh, maybe it doesn't
<daviid>wingo, civodul, fwiw -
<daviid>wingo, civodul it also crashes if call a none existing proc or a proc that exist but with a none existing arg, here, again, fwiw -
<RhodiumToad>ok. so the manual contains an example of a macro, (aif test then else) which binds 'it
<RhodiumToad>as far as I can tell, the solution given works on its own, but can't be used inside another macro
<RhodiumToad>(define-syntax-rule (foo bar) (aif bar (display it) (display "no"))) (foo 123) gives Unbound variable: it
<RhodiumToad>I'm guessing that that's just a shortcoming of the specific unhygenic implementation
<RhodiumToad>looks like it can be done better with syntax parameters
*civodul just sent a scary-looking bug report: threads! memory corruption!
<dsmith-work>Monday Greetings, Guilers
<sneek>I've been running for 6 days
<sneek>This system has been up 12 weeks, 4 days, 23 hours, 41 minutes
***chris is now known as chrislck
<daviid>civodul: hello, forinfo, yesterday i pasted (here in the channel) and 'quoted' the pastes for you and wingo [you were off channel, hence my msg now ...] two pastes related to situations where instead of an 'intelligible' error msg, as in 2.2, when using 3.0, we get an unusable error msg, repeated, then guile crashes - the pastes are valid 3d