IRC channel logs
2016-12-15.log
back to list of logs
<amz3>the issue with setlocale seems fixed in 2.1.5 <wingo>probably a guix issue with different libc versions <wingo>what are release blockers for 2.2 <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... <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>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>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 <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>Welcome back lloda, you have 1 message. <sneek>lloda, wingo says: please do :) <lloda>wingo: was checking the logs, done :) <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> 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 <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>but I'm not motivated to write such a parser <davexunit>personally I've started using the commonmark support <paroneayea>rekado: you might be able to make progress by using the "generic" orgmode exporter, which iirc exports to xml <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 <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 <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>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>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>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: 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>(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. <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 <daviid>paroneayea: maybe you can locally fix it yourself <paroneayea>maybe, I don't have a lot of experience that code... <daviid>paroneayea: it's all scheme code <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 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 <daviid>paroneayea: not sure, but i take this as an opportunity to read and play with this ... so to say <daviid>paroneayea: the above is incorrect, need to dig a bit more <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. <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