<daviid>hello guilers [for those of you who like to know who's who :), I've changed nickname (from tupi)] <daviid>about copyright lines, is this change ok: "* Copyright (C) 2008 - 2014 Free Software Foundation, Inc." or we do have to specify all years (in its current version, the file I will send a patch for only list 2008) <ijp>mark_weaver: (string->number "#b1010" 10) ; 10 <ijp>has it always been like that, or was it an executive decision on your part? <ijp>I'm conflicted as to whether it is sensible <ijp>as to my earlier issue, I'm not sure we can give a meaningful error without some surgery <ijp>scheme@(guile-user)> (string->number "#b#o1010") <ijp>scheme@(guile-user)> #b#o1010 <ijp>but you don't get a third level <ijp>scheme@(guile-user)> #b#b#o1010 <ijp>While reading expression: <ijp>ERROR: In procedure scm_lreadr: #<unknown port>:60:11: unknown # object <ijp>who wants to guess why? <mark_weaver>ijp: regarding (string->number "#b1010" 10) => 10, it's always been like that, and that's what the R5RS specifies. <ijp>mark_weaver: is that so? <mark_weaver>in the definition of string->number, the R5RS says "If supplied, RADIX is a default radix that may be overridden by an explicit radix prefix in STRING (e.g. "#o177")." <ijp>it feels like it should be error territory, but I suppose it is simpler <mark_weaver>having the reader accept #b#o1010 is not so good though :-/ <ijp>the easy way to fix it is to push them back into the string <ijp>but overall, the use of string->number doesn't lend to nice error handling <ijp>you get a blanket #f, and need to reconstruct the error <ijp>ideally, you'd have a more primitive form prim:string->error that returned an error, but that sounds like hard work :) <ijp>ah, I've found a good justification for the r5rs behaviour <ijp>because it makes a lot of sense in the (no supplied radix) case <mark_weaver>or just reading things with a default radix that can be overridden. <mark_weaver>(where the default is usually 10, but in some contexts a different default might be sensible) ***fangism is now known as fangism-ctrl-Z
<ijp>aidalgol: it's 4:30 am. what do you think ? :) *aidalgol really needs to check the world clock before asking. <ijp>just swap am with pm, and you'll be close enough <zacts>mark_weaver: I've been sort of busy <zacts>so no progress since last time <zacts>but, I'll look at it this weekend <ijp>aidalgol: I wrecked my body clock about a week ago and I haven't managed to readjust <zacts>I'm also growing tired of pkgng + FreeBSD ports, it's painful for me. <zacts>I can't wait to be done with it now <ijp>aidalgol: I should update my guile first, but sure <zacts>hm.. If I can finish my homework tonight, I'll try to fix up as much as I can tonight. <impaktor>Hm, guile on Arch Linux is still 2.0.7. I was expecting 2.0.10. <didi>impaktor: 2.0.11 would be better. <alezost>i mean i am on Arch and "pacman -Q guile" says it is 2.0.11 <impaktor>alezost: right you are. Right now I'm trying to reproduce how my terminal told me 2.0.7, could be that I ran it in the wrong terminal, on a ssh connection to another computer. <zacts>I need to get my virtual machines working again, then I'll clean up my FreeBSD guile-2.0 port <mark_weaver>zacts: cool. I realize you want to move on, but it just seems so close :) <mark_weaver>it would be great if you could make guile-2-in-freebsd-ports a reality. <mark_weaver>(of course, if you really want to abandon this work, that's your choice) <zacts>lang/guile2 on FreeBSD may require updating and cleaning up other poorly written ports, such as boehm-gc / pkgconfig. Also, I need to fix and cleanup a few issues with my port's Makefile. <zacts>also, I need to strip libraries <zacts>and I need to figure out how to install guile2 alongside guile-1.8 <zacts>or if we should only allow one or the other, there are conflicts <mark_weaver>guile 2 alongside guile-1.8 should not be an issue at all. they are designed for parallel installation. <zacts>can you do that with ./configure or gnu make? <mark_weaver>the library names and install directories are all different, so they don't conflict. the only issue is the name of the executable itself, and you can use the --program-suffix argument to configure for that. <mark_weaver>although it seems a shame to give guile-2 a different name, when guile-1.8 is obsolete and many years unsupported. <zacts>mark_weaver: it just needs to be updated to the latest version <mark_weaver>guile 2 doesn't work properly with the version in freebsd? <zacts>no, for some reason guile/gmake wants a newer version, but I'll check again in just a minute. <zacts>they may have updated pkgconfig since the last time I tried <mark_weaver>zacts: fwiw, debian installs /usr/bin/guile-2.0 and /usr/bin/guile-1.8, so I guess that they use the --program-suffix argument <mark_weaver>and then I guess maybe they use their "alternatives" system to make /usr/bin/guile a symlink to one or the other, according to the users preference. <mark_weaver>zacts: actually, debian doesn't use --program-suffix, but rather renames the guile binary after installation. <mark_weaver>(after "make install" into the staging directory, that is) <mark_weaver>I guess part of the issue is that many other programs that use guile rely on "guile-config" and won't want it to be renamed. <mark_weaver>it might be simpler to just make the two packages conflict. guile-1.8 should really be phased out anyway. <zacts>mark_weaver: maybe if we can convince the lilypond / gnome games devs to upgrade to use guile-2.0 instead of guile-1.8 I could phase out guile-1.8 on FreeBSD <mark_weaver>lilypond is a tough one. they want to upgrade, but it turns out that it's a difficult job for them to accomplish. <mark_weaver>it'll get done, but it may be many months before it is done. <mark_weaver>well, why don't you just use --program-suffix=-2.0 and be done with it. <shifty>I'm trying to cons a list using C bindings. I want to achieve this: (set! mylist (cons (random 100) mylist)) <shifty>The best I can come up with is: symbol = scm_from_locale_symbol("mylist"); lookup = scm_c_lookup("mylist"); ref = scm_variable_ref(lookup); scm_define(symbol, scm_cons(scm_from_int(random()%100), ref)); <shifty>It "works", but seems very round-about. Is there a better way? <stis>shifty: if you want set! I think you need to use scm_variable_set_x in stead of scm_define <stis>else I think that this is the dance you need to do for what I know <shifty>OK - thanks. It's slightly less noxious. So now we have: lookup = scm_c_lookup("mylist"); ref = scm_variable_ref(lookup); scm_variable_set_x(lookup, scm_cons(scm_from_int(random()%100), ref)); *stis is planning GC of logical variables in guile-log. <shifty>thanks people. after consideration, it does make sense - even if it's a little unwieldy. <joolean>I have a question: Is there a way to capture the enclosing module of a "define" form? I've got some code that's trying to create a qualified reference to a procedure, a la (@ (module …) procedure), and I find that (current-module) does not do the trick <joolean>Essentially, I've got something like: <joolean>(library (foo) (export bar) … (define (bar) …) (make-reference bar)) <joolean>And I would like the result of "make-reference" to be a datum that looks like '((foo) bar)' <taylanub>joolean: Maybe something like (eval-when (expand) (define module-name (module-name (current-module)))) <taylanub>(Well, that shadows the procedure `module-name' .. I'm clearly programming too much in languages with several namespaces. :P) <joolean>taylanub: Yeah, I tried something like that but it's not predictable — I've found that that produces #<unspecified> <taylanub>joolean: Are you trying to write portable R7RS-small code ? <taylanub>I think it works with the usual (define-module (foo)), after which you can have a top-level (define name (module-name (current-module))) and I think the `eval-when' is not even needed. <taylanub>if I'm not mistaken, the value-expression of a top-level `define' is evaluated at "module initialization" time, during which the current module is probably temporarily set to the module being initialized. <joolean>Interesting. I'm not sure if I want to force the introduction of a new top-level definition. Ideally, I'd want to use this behavior as part of a define-syntax or in a procedure definition <joolean>Anecdotally, I've also observed that if I try to capture the value of (current-module) during syntax expansion, it's always (guile-user) <taylanub>The problem with calling `current-module' from a procedure is that the current-module value is in a sense dynamically scoped, it will just return the module that is "current" during that procedure-call, which could be e.g. any module that imported yours and called that procedure ... <joolean>Yeah. I'm less clear on what it means to do it from syntax. <joolean>I suspect that it's not well-defined in Guile's syncase implementation, but I don't really know <wingo>you could use syntax-module perhaps <wingo>but yeah, our module system is a bit of a mess :P <joolean>wingo: ooh, that sounds like what I want. But the info docs say you might try and take it away from me later! <wingo>yeah i think it's a good interface, but caveat emptor :) <joolean>Was playing with 2.2 the other night, by the way — very cool to see 'ELF' at the top of my .go files <wingo>hey i heard you found some infinite looper on some file <wingo>any way you could get in a repl, do (compile-file "foo/bar.scm"), do a control-c at some point and send me a backtrace? <joolean>Yeah, there was some weirdness during compilation. <wingo>there's a lot of fixed-point iteration in the compiler and there is the possibility for bugs there <joolean>actually, just revived my 2.2 environment and did it <mark_weaver>joolean: regarding your code "that's trying to create a qualified reference to a procedure, a la (@ (module …) procedure)", why do this manually? hygienic macros take care of this automatically for you. <joolean>mark_weaver: True, but I want to serialize it <joolean>The context is that I'm trying to create a serializable reference to a module-qualified procedure name that can be persisted to disk and read back again <joolean>I have a (somewhat exotic) application that needs to be able to persist a task queue in the form of a list of procedure names <mark_weaver>joolean: anyway, if you don't hear back from wingo soon, then I think you should just post to guile-devel ***fangism-ctrl-Z is now known as fangism1
***jemarch is now known as GNU|jemarch
***GNU|jemarch is now known as jemarch
***cluck` is now known as cluck
<stis>hmm gc hooks are not documented, dangerous to use? <stis>also the sweep versions of the gc hooks semas to not be implemented, is that right? <dsmith-work>Looks like my new beaglebone black will arrive tomorrow! Whoo! <ft>So hard to get one on germany. :-/ <ft>But should get better if you can trust the beagleboard blog. :) <dsmith-work>Getting mine from Newark (Element 14), they are so backordered, they decided to build their own. <ft>Yeah, they got a licencing deal with the beagle folks now. <ft>So they may use the logo, or something like that, too. <ft>Yeah, would be pretty silly to change something that works. :) <dsmith-work>We will see. I did heard good reports in the beaglebord channel. <ft>They (element 14) should have the capacity to properly build the boards.