<wingo>er, maybe i was confused thinking you were on holiday <wingo>civodul: i wrote a gdb extension in guile for v8; was pretty fun :) <taylanub>Guile-Emacs is on GSoC again ... I assume Robin Templeton is 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. <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.? <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 <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 will have to remember how to do that. <wingo>yes please op mark_weaver as well <rlb>anyone know the incantation offhand? <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. <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 <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 <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. <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... <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. <wingo> /msg ChanServ FLAGS #channelname nick flags <wingo>mark_weaver: i think you should be able to /msg ChanServ op #guile <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 <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>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. <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. <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 ? <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>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? <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) <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 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 www.r6rs.org <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>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...