IRC channel logs

2016-12-15.log

back to list of logs

<amz3>the issue with setlocale seems fixed in 2.1.5
<nalaginrut>amz3: what issue? ;-)
<wingo>probably a guix issue with different libc versions
<wingo>so
<wingo>what are release blockers for 2.2
<wingo>any ideas?
<lloda>maybe the C-c kills repl? #20219
<lloda>it happened before too I think, not sure what 'blocker' should be
<taylan>wingo: I never found the time to look further into guix's issues with 2.2 :(
<lloda>the one that I think is serious is the 'write-into-literal' thing b/c it can lead to segfaults
<lloda>1.8 didn't have it, but I think 2.0 did, so...
<janneke>wingo: the debugger?
<wingo>janneke: probably a good thing to fix, i wonder why it isn't working
<wingo>as you can see i never use it :P
<janneke>yeah
<janneke>it would be nice to have guile+backtrace use gnu style error messages too
<janneke>so that emacs (and other ide) integration works easier
<wingo>that's not a blocker tho
<wingo>actually none of these bugs are blockers i don't think, because they all can be fixed in 2.2
<wingo>a blocker is something that can't be fixed except in a 3.0 -- seems to me anyway
<wingo>we are not getting enough testing of our 2.1.x prerels so at this point we need to have a less-polished 2.2.0 in order to get a nice 2.2.1, i think
<lloda>that makes sense
<janneke>sure
<janneke>wingo: have you looked at nash? anything incompatible needed for things like that?
<wingo>janneke: good question, i looked a little bit but not deeply
<wingo>we should make it so that 2.2 can be used with nash
<lloda>wingo: ok to push test for the format bug? there's not one test of ~f with parameter in format.test, so I think it should be added anyway
<wingo>sneek: later tell lloda please do :)
<sneek>Got it.
<lloda>electricity was cut
<sneek>Welcome back lloda, you have 1 message.
<sneek>lloda, wingo says: please do :)
<lloda>wingo: was checking the logs, done :)
<wingo>:)
<dcluna>Hello, guilers! Sorry if this is a noob question, but I'm running Guile 2.0.5.1389-ddda4, with Geiser (it reports that its version is "@PACKAGE_STRING@", so something may be wrong here). While trying to evaluate (+ 1 2), I get the following error: "ERROR: In procedure memoize-variable-access!:
<dcluna>ERROR: Unbound variable: ge:compile
<dcluna>
<dcluna> 0 (memoize-variable-access! #<memoized ge:compile> #<directory (geiser emacs) 24c0e10>)". Can someone advise?
<OrangeShark>I think @PACKAGE_STRING@ is something that should be replaced with the version when configure is ran when building guile
<paroneayea>hello #guile friends
<dsmith>Thursday Greetings, Guilers
<paroneayea>hi dsmith
<paroneayea>what's the haps
<daviid>hello guilers!
<rekado>hello Guilers!
<rekado>davexunit: I’m currently working on a new website with haunt and I’m looking for an alternative to writing the pages in skribe syntax.
<rekado>(due to some quirks that I couldn’t sort out so far)
<rekado>any chance to get minimal org-mode syntax support…?
<davexunit>rekado: I'd love that
<davexunit>but I'm not motivated to write such a parser
<davexunit>personally I've started using the commonmark support
<davexunit>which I find to be quite nice
<paroneayea>rekado: you might be able to make progress by using the "generic" orgmode exporter, which iirc exports to xml
<paroneayea>so you could then open that with sxml
<paroneayea>or, you could export to html then use guile-lib to read it
<paroneayea>rekado: I'd also love an orgmode reader if it exists.
<paroneayea>you'd have to call out to emacs in the scenarios I'm describing
<paroneayea>if you wanted to do it in pure guile, there is some document describing orgmode syntax... but I imagine that would be a lot of work to write.
<davexunit>I believe wingo wrote a parser for a subset of org-mode
<davexunit>and skribilo has an outline-mode-like parser
<davexunit>so I think there are some existing options.
<rekado>cool!
<rekado>it’s not urgent, but I got *really* comfortable with org mode…
<paroneayea>rekado: orgmode is the fastest way from thoughts -> writing for me
<daviid>wingo: hello! this guile-gnome error I was talking about the other day is short enough so I can paste here:
<daviid>(gnome-program-init "Foliot" "0.9.6-beta")
<daviid>oop/goops.scm:410:13: In procedure %allocate-instance:
<daviid>oop/goops.scm:410:13: In procedure struct-vtable?: vtable has invalid layout: (unbound)
<daviid>then with quite some surprise, I tried today and the error msg is different !?, here:
<daviid> (gnome-program-init "name" "version")
<daviid>ERROR: Not a slot: (app-id #:allocation #:gproperty)
<daviid>wingo: so, anyway, could you tell me if you think that scm_sys_allocate_gvalue in gvalue.c needs to be updated? (line 114 in this file)?
<daviid>wingo: it is called by allocate-instance on <gvalue-class> (gvalue.scm line 94), though that method specialization first call next-method. with this in mind, I'm thinking that 2.1.x instance allocation returns an 'object' that 'old' C code does not understand anymore, does that make sence?
<paroneayea>is it more efficient in any way to select slots via GOOPS setters than using slot-ref? Or is it just considered better form?
<daviid>sometimes ,bt in a geiser repl buffer does not end giving me the pŕompt, then I have to hit twice C-c, does this happens for you guys?
<dsmith>paroneayea: Ya, org-mode is awesome. I might end in something else, but I start in org-mode
<daviid>paroneayea: iiuc, (a) I beleive getter(s) and slot-ref is/are equally efficient and (b) from a style point of view I have a pref for (getter <instance>) over (slot-ref <instance> 'name), but it really is not that important. setters is another story since you generally define them because some other code needs to run (then just slot-set!), and defining a setter, you actually need to call slot-set! (or slot-fset :))
<paroneayea>daviid: ok, useful to know. I generally agree that getters are nicer, though for a case I have here using slot-ref is slightly preferable
<paroneayea>I was wondering if the getter pre-computed an index offset or something
<paroneayea>and if that would result in it being faster
<paroneayea>er, index, not index offset I guess.
<daviid>paroneayea: note that setters are not inherited, so the trick is to define a method (define-method set-foo (..) ...) and if you prefer the setter syntax, you have to define on each class subclass ...
<paroneayea>daviid: setters are not inherited?!
<paroneayea>even when ths lot is not redefined?
<paroneayea>ok, no, they are inherited
<paroneayea>I guess it's when you don't explicitly say #:setter and you do redefine a slot
<daviid>paroneayea: setters are not inheritied, this is a (terrible) error of the past, but the trick above allows to 'have them', until we fix this ...
<paroneayea>daviid: I just tried it and it seems inherited
<paroneayea>let me paste...
<paroneayea>daviid: http://paste.lisp.org/display/334133
<paroneayea>seems inherited here
<paroneayea>that's in guile 2.1.5
<paroneayea>daviid: aha
<paroneayea>daviid: but it doesn't seem to be in Guile 2.0
<paroneayea>so it seems fixed :)
<paroneayea>no wait
<paroneayea>that was an error on my part
<paroneayea>seems fine in Guile 2.0 also
<paroneayea>I guess you mean when you define a new slot on the subclass and don't add a #:setter field?
<daviid>paroneayea: no, let me find the bug report
<daviid>bug#19770
<daviid>paroneayea: but it actually is even easier, in these particular 'cases' jusat not define #:accessors but 'only' the setter method, see wingo comment for the explaination: goops is currently 'unable' to both define an accessor and inherit a setter method, but it will propely inherit either of those 'option'
<paroneayea>hm, I'm not familiar with defining the setter of the generic method of the accessor
<paroneayea>that's a bit too much goops-fu for me to follow at this moment
<daviid>paroneayea: it's ok
<daviid>paroneayea: 1 day you'll need a setter method, because you want 'extra' code then just the slot-set! effect, then this comes in action .. I'll help you when ...
<paroneayea>:)
<paroneayea>huh, weird thing in Guile 2.2
<paroneayea>(define-class <foo>
<paroneayea> (dis-slot #:allocation #:class
<paroneayea> #:init-value 1))
<paroneayea>works in Guile 2.0, but not in Guile 2.1
<paroneayea>but!
<paroneayea>(define-class <foo>
<paroneayea> (dis-slot #:init-value 1
<paroneayea>switch the order and it's fine :)
<paroneayea>must be a bug
<daviid>probably yes
<daviid>paroneayea: for curiosity, here is an example: http://git.savannah.gnu.org/cgit/grip.git/tree/grip/clutter/apple.scm (line 324), which, if both !gravity and setters would be inherited I would have wrote (define-method ((setter !gravity) (self <clus-apple>) gravity) ... however (define-method (set-gravity ... provide the exact same functionality, so no big deal
<paroneayea>hm
<paroneayea>probably related:
<paroneayea>class-slot-ref is broken in Guile 2.2.
<paroneayea>(class-slot-ref <foo> 'dis-slot) ; works in Guile 2.0, not 2.2
<paroneayea>that's too bad. That blocks a feature I was about to add. Hm.
<paroneayea>ACTION files bug
<daviid>paroneayea: to conlude this conversation, in the spirit of CLOS, I would not have to define !gravity, set-gravity, get-gravity, but only !gravity and its method setter, and the module would g-export !gravity, istead of all the above .. imo, it is a lot better, but as I said, since at least we have a counter way, that is fine, for now
<paroneayea>daviid: *nod*
<daviid>paroneayea: maybe you can locally fix it yourself
<paroneayea>daviid: fix GOOPS in 2.1? :)
<paroneayea>maybe, I don't have a lot of experience that code...
<daviid>paroneayea: it's all scheme code
<paroneayea>I've been reading it
<daviid>ler me look
<daviid>paroneayea: I don't know goops internal either, but may be this is an easy fix, it's sounds like it is, but then ... :)
<paroneayea>daviid: regardless, best to file the bug first before attempting a fix :)
<daviid>oh yes, but since you say you depend on it ..
<paroneayea>well, to add the much nicer feature I was hoping for, I do at least :)
<daviid>paroneayea: that is very interesting, and could be related to the guile-gnome proiblem I was talking about
<paroneayea>ACTION bumps into (oop goops save)
<paroneayea>that's a curious module
<paroneayea>read/write for whole goops objects...?
<paroneayea>ACTION not sure he would trust it, but interesting
<daviid>I did see that module in the past too, never used it. I've always wanted to write a pgoops module (permanent goops), but never had time ... I would use database if ...
<daviid>i think the problem is in %compute-layout
<daviid>in this mexample you wrote, in this case the slot type as %compute-layout sees it is #:init-value , and it shold be #:class
<paroneayea>daviid: oh interesting
<daviid>paroneayea: not sure, but i take this as an opportunity to read and play with this ... so to say
<paroneayea>daviid: :)
<daviid>paroneayea: the above is incorrect, need to dig a bit more
<paroneayea>daviid: thanks and good luck :)
<daviid>paroneayea: well, I'm not being very usefull here, but thanks :) I have to code on something else now, but will look later, for fun and learning...
<paroneayea>daviid: yep, it's the allocation, it's set to the wrong thimg.
<paroneayea>ok, filing bug now
<paroneayea>daviid: luckily, #:each-subclass still works
<paroneayea>so it turns out I can do things using that
<paroneayea>still a bug that should be fixed though.
<paroneayea>bug filed!
<paroneayea>bug #25211
<daviid>paroneayea: good!
<cbaines>Any tips on dealing with readdir and filename character encoding?
<cbaines>As in how to handle readdir results that include filenames containing non ascii characters, they appear as ?? for me currently