IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<civodul>Hello Guilers!
<wingo>morning :-)
<wingo>welcome back :)
<wingo>er, maybe i was confused thinking you were on holiday
<civodul>i was!
<wingo>civodul: i wrote a gdb extension in guile for v8; was pretty fun :)
<stis>evening guilers!
<taylanub>Guile-Emacs is on GSoC again ... I assume Robin Templeton is bipt ?
<b4283>what's bipt
<taylanub>b4283: A nick in this channel. :P Previously I've only seen em use the name "BT Templeton" here and there so was a little confused.
<b4283>ah, forgive my ignorance
<ArneBab>taylanub: yay!
<unknown_lamer>taylanub: yes
<rlb>wingo: right now in the debs I have to sed guile-config and guild to change them to refer to guile-2.0 (for example) instead of guile. I wonder if some alternate solution might be acceptable upstream.
<rlb>i.e. could we have support for versioned binaries (internal and external) upstream -- either always on, with some way to automatically set up the convenience links by default (guile -> guile-2.0), or optional.
<rlb>i.e. in debian we handle the convenience links via update-alternatives, so I wouldn't want that.
<wingo_>right i think we should make those respect --program-suffix
<rlb>ok -- not familiar enough with --program-suffix, but that sounds reasonable.
<rlb>so without it, we'd just get what we have now, but with it, we'd get guile-X.Y everywhere?
<wingo_>it's a configure argument -- probably you should be using that, no?
<rlb>wingo_: sounds plausible
<wingo_>i think in fact it works already
<rlb>ok, so even for the internal invocations, etc.?
<rlb>(I'll check)
<wingo_>the guild-2.0 -> guile-2.0 mapping
***wingo_ is now known as wingo
<civodul>i think there was a fix to allow --program-suffix to be honored some time ago
<mark_weaver>rlb: btw, on another subject (while you're here), it might be good to rig this channel so that when people join, they are told: "This channel is logged, see <>."
<rlb>mark_weaver: good point.
<mark_weaver>rlb: and maybe wingo and civodul should be given ops privs to this channel (I might be using improper terminology)
<rlb>(didn't know -- and had forgotten I was the op)
<rlb>mark_weaver: yes
*rlb will have to remember how to do that.
<wingo>yes please op mark_weaver as well
<rlb>anyone know the incantation offhand?
<wingo>hoo, it's obscure
<mark_weaver>civodul added me as an op to #guix recently, so maybe he remembers?
<rlb>I'll find it, but if I don't do it soon, just ping me. I'm normally on freenode, even if not here.
<wingo>so it seems to work for me
<wingo>once i identify
<wingo>so i can do it
<mark_weaver>ah, good!
<rlb>wingo_: ok, so maybe you were already an op?
<rlb>(or maybe this channel isn't protected somehow?)
<wingo>i think we went through this dance a few years ago
<rlb>oh, ok -- so you just need to be identified
<wingo>only some people can op themselves, and it has to be by /msg ChanServ op #guile
*wingo looks how to get that list and add mark to it
<mark_weaver>wingo: thanks!
<rlb>I think it will also op you whenever you identify?
<wingo>rlb: i think it can if you configure it that way
<rlb>wingo: I'll let you change the topic
<rlb>(set in 2007 ;>)
<wingo>haha :)
<rlb>(last set)
<rlb>I built it to last.
<wingo>"Welcome to #guile, IRC home of GNU Guile ( This channel is logged; see"
<wingo>something like that?
<rlb>Sounds good to me.
<wingo>mark_weaver ?
<mark_weaver>that would be an improvement, but on #guix we have it rigged differently, so that ChanServ actually sends a message to the joiner.
<rlb>oh, iswym
<wingo>should we do that?
<civodul>mark_weaver: i can't seem to find the magic invocation
*wingo doesn't care too much :)
<mark_weaver>someone got on #guix and made noise about the lack of notification, and told civodul how to do these things, and I suspect he has since forgotten.
<daviid>sometimes channel mention the latest release number, don't know...
<daviid>the latest stable i ment
<mark_weaver>wingo: well, changing the topic should be sufficient for now anyway.
<rlb>daviid: yeah, but then you can't just leave it set for 7-ish years.
<rlb>(I hope)
<wingo> /msg ChanServ FLAGS #channelname nick flags
<wingo>is the incantation
<civodul>aah yes
<wingo>mark_weaver: i think you should be able to /msg ChanServ op #guile
<mark_weaver>oooh, the power! :)
<mark_weaver>of course, I'm totally clueless about what I can do as an op, but if the need arises I can ask around :)
<wingo>haha as you can see i don't know either :)
<rlb>mark_weaver: about the only thing I know how to do is "/topic foo"
<dsmith-work>wingo: Did you do anything to get that libgc "wrong size" thing fixed? I don't see it happening any more.
<wingo>but it's useful if someone needs to be shunned :P
<rlb>I have to look up anything else (assuming I know what to look for).
<wingo>dsmith-work: the GET_MEM thing? it is fixed in upstream bdw-gc
<wingo>i didn't fix it in guile
<dsmith-work>Yeah, the GET_MEM thing
<rlb>has there been any more discussion of module versioning (since way back) -- i.e. perhaps sonamish? Assuming it's still considered an issue.
<rlb>i.e. straw-man: (use-modules (foo bar :v 9)) or whatever
<rlb>which would require a version compatible with "9".
<mark_weaver>R6RS has module versioning. I guess we would do something based on that.
<rlb>oh right -- shows what I (don't) know. I'll look.
<mark_weaver>as far as I know, no one has worked on it for Guile, and I haven't looked closely at it, so I'm not educated on the relevant issues.
<mark_weaver>rlb: let me know what you think of the R6RS versioning scheme, and whether you think it's sufficient.
<mark_weaver>I am going to have to make some changes to the module loading mechanism soonish, because there are thread-safety issues there.
<rlb>ok, though I'm by no means the expert -- just one who's suffered (lately mostly in the jvm) the consequences of not having one
<ijp>i thought there was a #:version argument to define-module, and r6rs modules used that
<rlb>perhaps unsurprisingly, the r6rs spec appears to be a substantial superset of what I was hoping for.
<mark_weaver>ijp: interesting.
*mark_weaver looks
<mark_weaver>rlb: so, indeed there does seem to be some support for versioning in the guile module system.
<mark_weaver>the 'define-module' form accepts a #:version argument, as does 'resolve-interface', and see 'version-matches?' in boot-9.scm
<rlb>nice -- the main thing I wanted was just the sonameish bit, and r6rs appears to have something at least as effective.
<mark_weaver>rlb: and 'use-modules' accepts #:version
<rlb>i.e. have a module that provides some set of api versions, and some way to ask for a particular version from use-modules.
<mark_weaver>ijp: thanks for the tip!
<rlb>and some way for the system to sort out which one to load if there are multiple providers available.
<mark_weaver>the only thing is, I doubt there's any support for having more than one version of the same module in the load-path at once.
<mark_weaver>i.e. I suspect you can have only one version of a particular module available, and if that doesn't match what you're looking for it will fail.
<mark_weaver>but admittedly I've not looked carefully, so maybe I'm mistaken.
<rlb>well, that might not be ideal, but it's better than nothing.
<rlb>of course the ugly hack fallback is to just version your module names, i.e. foo-2 :/
<rlb>but then the consumers have to have conditional code, i.e. use foo-5 if available else foo-4 ...
<rlb>wingo: not sure it's feasible, but even better if --program-suffix could work for the info pages too.
<daviid>do we have a read-file-string-all ?
<daviid>or likewise I mean
<ijp>in (rnrs io ports) there is a get-string-all
<ijp>which uses a read-string
<ijp>which I think is in (ice-9 rdelim)
<ijp>so to get the file as a string, you'd just do (call-with-input-file file-name read-string)
<daviid>ijp, tx just did this, wdyt?
<daviid>I guess I should set the port encoding according to the user locale to be complete/exact
<mark_weaver>daviid: why not just do (call-with-input-file file-name read-string), and ijp suggested?
<mark_weaver>you can wrap (false-if-exception ...) around it if you want.
<mark_weaver>as for the encoding, just call (setlocale LC_ALL "") early in initialization and that will take care of the default port encoding.
<daviid>mark_weaver: I wrote it before :) and wanted to know which would be best when reading his solution ... I'am under the [maybe false] impression that get-string-all would be faster ?
<mark_weaver>'get-string-all' just calls 'read-string'. the former is more portable though, so that's an advantage I suppose.
<rlb>daviid: you may still want protection for exceptions (i.e. to close the file)
<rlb>so the resource doesn't leak
<daviid>mark_weaver: tx. actually portable is not important to me
<rlb>(assuming you don't want ijp's version)
<mark_weaver>daviid: do you really want to ignore errors like that?
<mark_weaver>rlb: good point
<daviid>rlb: you're right
<rlb>anyway, if file io's involved, you likely have a lot of slack wrt performance.
<mark_weaver>'get-string-all' raises R6RS condition objects in the case of errors, 'read-string' raises native guile exceptions.
*rlb needs to look at r6rs more -- been away from scheme for a while...
<mark_weaver>(IMO, R6RS condition objects are an excellent design for error reporting, whereas the native guile stuff is barely adequate)
<daviid>I'll use ijp's solution, but for the sake of learning, is this good:
<ijp>well, any errors with io are unlikely to come at the close stage, so it would be better to wrap the let*
<ijp>second, depending on your use case it may be better to return #f, or rethrow the original exception
<mark_weaver>daviid: the API seems bad to me. exceptions are generally better than special error return values that have to be checked. this is regressive. also, is there a good reason to accept #f as filename without raising an exception?
<mark_weaver>maybe your use case really justifies these things, but that's unclear.
<mark_weaver>there's also a TOCTTOU problem with the 'access?' check.
<daviid>mark_weaver: it does not. but then to be really good, i'd need to catch 2 different errors: 1) the file does not exists or the user can not read it, then a possible OS error opening, reading and/or closing it right?
<zacts>mark_weaver: sorry, kind of have a busy day today, but once I'm done with a music lesson / schoolwork, I'll have a look into that FreeBSD lang/guile2 patch again. Sorry it's taken so long.
<daviid>mark_weaver: I'll leave the TOCTTOU problem aside for now [you mean I should lock right?], but I'd like to get this small example right now that I did ask and you guys kindly answer ...
<mark_weaver>daviid: no, rather that you should catch the error when trying to open the file.
<mark_weaver>there's no way to do this with locking.
<daviid>I see, not using access?
<mark_weaver>there's no lock that can guarantee that some other process doesn't move the file out of the way, or change its perms, or whatever, in between the check and the open attempt.
<daviid>ok, I'll have to review some old code, tx. I'll correct my example now, give me a sec
<mark_weaver>if you want good error handling, I'd recommend using the R6RS interfaces to open and read the file, and put a big 'guard' around the whole thing, with the common cases caught to generate a nice error message for the user.
<daviid>I'd like to do that yes, any example somewhere?
<mark_weaver>I don't know where to find a good example, but if you ask nicely, maybe ijp will show you some example code :)
<mark_weaver>or just read the relevant sections of the R6RS at
<daviid>let me try then
<mark_weaver>daviid: what you need is in the R6RS standard libraries document.
<mark_weaver>chapter 7 on the basics of exceptions and conditions.
<daviid>ok, tx
<mark_weaver>8.1 on the I/O error condition types
<mark_weaver>and 8 on R6RS I/O.
<daviid>mark_weaver: tx a lot: I'll read it later, and come back with a better solution, I've to jump on something else, but really nice to learn...
<daviid>ijp: tx as wel of course!
<mark_weaver>daviid: you're welcome! happy hacking :)