<taylanub>hrm, some `with-working-directory' form would have been neat. or am I not finding it? <taylanub>it's kind of nasty that the filenames `scandir' gives to its predicate argument cannot be simply passed on to another procedure because one only gets the pathless file names <mark_weaver>jemarch: I would be careful not to play games with the module system based on the results of experiments. <mark_weaver>we are going to be revamping the module system at some point, and you should try to be future proof. <jemarch>yes, that sounds like a sensible advise :) <mark_weaver>if you can have just one file with 'define-module' and then use 'include' within that file for the other files, that would certainly be safe. <mark_weaver>as for exports, it's documented and acceptable to use 'define-public', or to sprinkle (export foo) in the various files. <jemarch>hm, there is no define-class-public nor define-method-public <jemarch>although I gues I could use a (define-class ...) folllowed by a (export ..) <mark_weaver>I would definitely avoid putting multiple files with 'define-module' defining the same module, and expecting guile to merge those somehow. there's no guarantee that will work the same way in the future. <ijp>I think we might play some tricks like that in guile <jemarch>ok, what about having (set-current-module ..) and then using (export...) ? <ijp>of course, our game, our rules <ijp>jemarch: slightly better <jemarch>I can guarantee that the "main" file containing the define-module is loaded first <mark_weaver>jemarch: hmm, I think that's of dubious future-proof-ness. <ijp>mark_weaver: how about the usual re-export hacks? <daviid`>mark_weaver: re-exporting the public interface of the imported modules... <mark_weaver>can you remind me where to find that in the guile-gnome tree? <mark_weaver>I should explain why I'm worried about this. It's not that I wish to break compatibility without reason, but we have a serious problem: right now module auto-loading is not thread safe. <mark_weaver>what happens if two threads concurrently do something that cause the same module to be auto-loaded? <mark_weaver>somehow, the module should only be loaded once, and both threads should wait until the module is finished loading. <ijp>there are quite a few weird cases with modules <ijp>I think you were the one that pointed out to me tha modules know their "submodules" <mark_weaver>but right now, we don't even have a way of telling when a module is finished loading, because they are so dynamic. you just create a module, and then add bindings to it anytime you want, and it's never clear when the job is done. <ijp>or maybe it was vice versa <mark_weaver>now, the modern scheme standards (R6RS and R7RS) have much more restricted module systems, where a module has a static set of bindings, and it's straightforward to load them in an atomic way. <ijp>whatever happens, we'll need to doublecheck with lilypond, since history suggests they do weird stuff with guile modules <ijp>I've done weird things with them too, but not in serious code <mark_weaver>they basically implemented their own module system using undocumented low-level modules procedures in Guile, and do not yet work with Guile 2. <mark_weaver>I don't know how this is going to shake out, because frankly I haven't yet thought of a satisfactory way to make module auto-loading thread-safe without hurting compatibility. <mark_weaver>but it leads to suggest that if jemarch can simply use 'include' and 'export' sprinkled in the files, that would be safest. <mark_weaver>having now looked at the 're-export-modules' macro in (gnome gw support modules), I would try hard to avoid such hacks. <ijp>jemarch: are you exporting all the classes? <ijp>then, you might try rebinding define-class to define-public-class, then includes would see that version <ijp>where define-public-class is a trivial one line macro <ijp>it would save a small amount of typing <jemarch>but the `include' approach does not suite my needs, because it must be possible to add a new .scm file with more classes in a running system without having to re-evaluate everything <mark_weaver>fwiw, the semantics of 'include' is that it's as if the contents of the include file is spliced in place of the 'include' form. <ijp>*running* makes everything more annoying <mark_weaver>whereas 'load' is a lot different. it's a first-class procedure. it's not really suitable for this. <ijp>you'd need to use something like inotify to check for new files <jemarch>it is actually done manually. You add a new file to your library, then you invoke a command that will intern all the classes into the package <mark_weaver>there's a deep problem with being able to add bindings to a module dynamically. in order to make it thread safe, then it means that even _looking-up_ a binding requires locking a mutex (or perhaps merely using atomic barriers, though those are not as portable) <mark_weaver>I realize that Guile has always had the ability to dynamically add bindings to modules at arbitrary points, but this is fundamentally unsafe in a threaded program. <jemarch>hm, then it is time to stop using the module system as a collection of obstacks? <mark_weaver>and I don't see a good way to fix it without significantly hurting efficiency. <jemarch>I mean, I could certainly manage my own hash tables and everything, but I would rather avoid it :) <ijp>is this for plugins in an application or something? <mark_weaver>it's possible that we'll have to lock mutexes every time a binding is looked up, for the sake of compatibility. <jemarch>the modules are nice because they provide a kind of namespace support to goops classes <mark_weaver>with caching of variable objects to prevent that from being a huge slowdown. <mark_weaver>another possibility is that we'll have two different kinds of modules: static modules and dynamic modules, the former being for efficient implementation of modern standard Scheme modules, and the latter for legacy guile programs. <daviid`>mark_weaver: yep, this is [dynamicly adding to module...] what made guile-gnome generic functions landing in a module possible indeed, and i understand your point [thread safe...] but i would be scared if that disapeared, at lest until we solve the export/re-export mags [methods, accessors, getter setters] 'problem' <daviid``>i've just hit it [again] in a real situation [not a just theoretical example i mean] developping a guile-clutter example. i've no time to expain it in detail, hopefully i'll find sometime soon <mark_weaver>jemarch: could each one of these plugins be in a separate module? <mark_weaver>daviid```: I'm not quite sure what you mean, but we can talk about it when you have more time. <jemarch>could I get a list of all the classes interned in a given module and all its "submodules"? <jemarch>"submodules" of the module (foo bar) would be (foo bar baz), (foo bar bleh), etc <daviid```>mark_weaver: yes, sorry i am not being very clear here, but i'll find time to properly expose the problem and hopefully we'll find a solution <mark_weaver>jemarch: you could write some macros to define your plugins and classes, that add themselves to a global data structure as a side-effect when they are loaded. <mark_weaver>or you could use various hacks that might be less future proof. <jemarch>mark_weaver: yes, I thought about maintaining a global hash <jemarch>but things like #:duplicates (merge-generics) are really handful <mark_weaver>well, there's a can of worms, especially if new modules to merge will be done dynamically after the program starts running. <mark_weaver>well, this practice of merging generics is something I've advocated strongly against on several occasions, and I know that daviid disagrees strongly with me and has much more experience using CLOS/GOOPS. <mark_weaver>the last time we discussed it on the ML was March 2013, subject "Help required with exporting and using GOOP generics" <daviid```>jemarch: i have a much clearer idea of what's wrong now and how to explain it, that discussion was not good [my fault], neither complete. but i also do not have time right now :( <jemarch>I am near to go to sleep, but will be working on this for the next two weeks, so will connect here often ***aksatac__ is now known as aksatac
<dunsmoreb>quick question: is it possible to limit the language that can be used with guile? so users can only use scheme per se and neither ecmascript nor elisp? ***dunsmoreb is now known as yomac
***turbo_islaam is now known as tuhannetpikkukis
***tuhannetpikkukis is now known as tuhannetkoirat
<tuhannetkoirat>The r6rs standard seems to imply that it has to raise a normal &assertion exception but whatever it raises seems to immediately terminate the program making it entirely uncatchable. <janneke>scheme@(guile-user)> (catch #t (lambda () (car '())) (lambda (key . args) (format #t "caught: ~a ~a" key args))) <janneke>caught: wrong-type-arg (car Wrong type argument in position ~A (expecting ~A): ~S (1 pair ()) (()))$2 = #t <tuhannetkoirat>janneke, anyway though, what it raises is not an r6rs &assertion though. <waxysubs>tuhannetkoirat: what version of guile are you using? <tuhannetkoirat>This is free software: you are free to change and redistribute it. <waxysubs>tuhannetkoirat: you may find that guile 2.0.11 does what you expect. <waxysubs>see the "Improved integration between R6RS and native Guile exceptions" in the guile 2.0.11 NEWS ***dje is now known as Guest39399
<tuhannetkoirat>waxysubs, 2.0.11 doesn't seem to have srfi-28 though which 2.0.9 seemed to come with ***karswell` is now known as karswell
***micro` is now known as Guest8063