IRC channel logs


back to list of logs

<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
<mark_weaver>yeah, so there's 'export'.
<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?
<mark_weaver>ijp: I don't recall which hacks you mean.
<daviid`>mark_weaver: re-exporting the public interface of the imported modules...
<daviid`>see (gnome gw support 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.
<daviid`>yes give me a se
<mark_weaver>fixing that is probably not going to trivial.
<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"
<daviid`>mark_weaver: here
<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
<daviid`>see re-export-modules
<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
<mark_weaver>texmacs also does.
<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?
<jemarch>ijp: I could live with that
<mark_weaver>could live with what?
<jemarch>with 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?
<jemarch>yes, something like that
<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
<ijp>jemarch: is what I did last time I tried this sort of thing
<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
<jemarch>so tempting... :P
<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>but I don't have time to discuss it now.f
<mark_weaver>the last time we discussed it on the ML was March 2013, subject "Help required with exporting and using GOOP generics"
*jemarch takes a look
<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
<mark_weaver>okay, sounds good!
<jemarch>thanks to you all for your help :)
<mark_weaver>you're welcome!
***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>Say, is is (car '()) supposed to be uncachable from a guard?
<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>tuhannetkoirat: seems?
<janneke>here's what i get:
<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, I used the r6rs guard form though
<tuhannetkoirat>janneke, anyway though, what it raises is not an r6rs &assertion though.
<waxysubs>tuhannetkoirat: what version of guile are you using?
<tuhannetkoirat>guile (GNU Guile) 2.0.9
<tuhannetkoirat>Copyright (C) 2013 Free Software Foundation, Inc.
<tuhannetkoirat>License LGPLv3+: GNU LGPL 3 or later <>.
<tuhannetkoirat>This is free software: you are free to change and redistribute it.
<tuhannetkoirat>There is NO WARRANTY, to the extent permitted by law.
<tuhannetkoirat>Sorry for the many lines
<waxysubs>tuhannetkoirat: you may find that guile 2.0.11 does what you expect.
<tuhannetkoirat>Ahh, excellent
<waxysubs>see the "Improved integration between R6RS and native Guile exceptions" in the guile 2.0.11 NEWS
<waxysubs>s/in/item in/
***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
<tuhannetkoirat>Oh no wait
<tuhannetkoirat>I implemented that myself once and put it there
***karswell` is now known as karswell
***micro` is now known as Guest8063