<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 <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! <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 <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 ... <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 <daviid>that is the cause of the warning <daviid>(default-duplicate-binding-handler <daviid> '(merge-generics replace warn-override-core warn last)) <RhodiumToad>in .guile? why would I want to do that, since that wouldn't be in effect when running a script? <daviid>or call manually before use gentst if you prefer <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? <RhodiumToad>ok, even weirder: if I compile the modules in advance with guild compile, I still get the WARNING, but (test) works <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 <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) <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' <RhodiumToad>if you didn't use guile -q, then paste your whole .guile <daviid>RhodiumToad: could you instead comment the readline 'stuff' <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>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 <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>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>the example didn't because it was a minimal example :-) <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>(define-module (gentst) #:use-module (oop goops) #:duplicates (merge-generics replace check)) <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>and your 'new method' after the above ofc ... <RhodiumToad>(define close (ensure-generic (@@ (guile) close) 'close)) <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>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! <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