IRC channel logs


back to list of logs

<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>$11 = #f
<ijp>so far so good
<ijp>scheme@(guile-user)> #b#o1010
<ijp>$12 = 520
<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?
*ijp checks
<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>indeed it does
<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 :-/
<mark_weaver>I can see why it happens though.
<ijp>the easy way to fix it is to push them back into the string
<mark_weaver>yeah, that sounds good to me.
<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
<nalaginrut>morning guilers~
<zacts>lo #guile
<aidalgol>ijp: Got time to hack on cbot a bit?
<mark_weaver>zacts: any news on guile 2 for freebsd ports?
<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
<aidalgol>for now, anyway
<aidalgol>why are you up?
<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>impaktor: yeah, 2.0.11 for me too
<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>I'm curious what else they want you to do.
<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.
<mark_weaver>what needs to fixed in the pkgconfig port?
<mark_weaver>s/to/to be/
<mark_weaver>that seems rather outside of the scope of this job.
<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.
<mark_weaver>I think it'll be okay.
<zacts>ok, yeah
<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>Hello, Guilers!
<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 ?
<joolean>It's only gotta work in Guile
<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>heya Andy!
<joolean>wingo: ooh, that sounds like what I want. But the info docs say you might try and take it away from me later!
<joolean>Such is life, I suppose.
<wingo>heya :)
<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
<joolean>Oh yeah! I guess Mark told you.
<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.
<joolean>Yeah, sure thing.
<joolean>I'll do that today.
<wingo>coolios, thanks
<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
<joolean>shall I email it to guile-devel?
<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
<mark_weaver>hmm, okay
<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
<joolean>yeah, figured.
<saul>Interesting look back at the future of programming from PyCon:
<dsmith-work>Happy Friday, Guilers!!
<joolean>Hey dsmith-work!
***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.
<dsmith-work>It's the same board layout too.
<ft>Yeah, would be pretty silly to change something that works. :)
<dsmith-work>Not sure if all the components are identical.
<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.