***jonsger1 is now known as jonsger
***scs is now known as Guest16503
***scs is now known as Guest44817
<daviid>anyone has a module they maintain in several diff versions? reading the doc, i fail to understand what file name the module should have <daviid>so, i thought i'd have a file named mod-1.scm containing (define-module (mod) #:version (1)), then (use-modules ((mod) #:version (1))) but that fails <tohoyn>"cumulative seconds" in statprof output does not work <tohoyn>I get cumulative seconds 30000 in a program with total 870 seconds ***chrislck_ is now known as chrislck
<daviid>i also tried to create a mod dir, with a 1.scm file in it, but (use-modules ((mod) #:version (1))) equaly fails with "no code for module"(mod) <daviid>i fail to understand how to create and maintain several versions of a module - <leoprikler>for version, you need to put #:version into the define-module <RhodiumToad>I think the question is whether it's possible to have multiple versions of a module and let the client module ask for the one it wants <leoprikler>Well, you can, but you'll have to manipulate load paths in order to do so. <leoprikler>also IIRC Guile does not support loading multiple versions of the same library <RhodiumToad>I think the answer is if you want different versions of a library with different interfaces, maybe they should be different libraries, possibly re-exporting from a common source <RhodiumToad>but my experience is insufficient to know whether that's a good idea <daviid>leoprikler: RhodiumToad is right, the question was, and it doesn't seem you tried :), since it does not work, to have a module created and maintinaed in diff version - of course the user would load one version only :) <daviid>and i was looking for builtt-in functionality, not a hacky hack of mine ... which i can always do of course that was not the question <leoprikler>well, the "built-in" functionality would be one based on load paths <daviid>I actually missundeertood the purpose and associated functionality of #:version in guile's module system, it is just a number and guile will check that what is defined is >= to what the user ask ... <daviid>but it is not a way to acheive what i need <leoprikler>guile-gnome once did this, perhaps because the had the grand idea of at some point doing gnome-3, but that turned out to have been a bit too eager <daviid>leoprikler: i am a guile-gnome co-maintainer :) - in guile-gnome, it is in the module name <daviid>I could do that though, of course <leoprikler>for the record, what exactly are you trying to achieve here? <leoprikler>btw. version is not only >=, it can also be <= and = <daviid>leoprikler: hum, i'll try and check =, i thought it would always check for >= <daviid>it won't work in guile because there can be only one mod def (in memory) with a given name, since the version is a field, not a key to retreive the module def ... <daviid>so the only way is to use a diff module name, g-golf, g-golf3, g-golf-3, g-golf4 g-golf-4 ... which is ok i guess, sqlite3 does that to :) <daviid>or i can opt not to support gt3/gdk3 as well, since g-golf somehow 'does not really exists out there yet' - <leoprikler>GI does not support loading Gtk-4 and Gtk-3 in parallel either, but if you did want to be "future-proof" you could do it like Guile-GI and simply name your modules (g-golf gtk-3) (g-golf gtk-4) etc. <leoprikler>As long as you only load those modules on request, everything should be fine <daviid>leoprikler: ther are no such gtk-xx module in g-golf <daviid>leoprikler: no bindings on earth can support loading -4 and -3, this is by typelib anf gi desiugn,m it is not a property or a lack of prtoperty of the binding <daviid>and fwiw, g-golf is future proof, it already import and runs gdk/gsk/gtk4 ... <leoprikler>Exactly, hence why you can translate GI typelibs <=> modules just like that. <daviid>what id not future proof is gnome <nixo_>Hi! I cannot figure out if there's a way to make a deep copy of a record in guile 3. I thought copy-tree would work, but then changing a field in the copy changes the original