IRC channel logs

2014-12-10.log

back to list of logs

***fangism is now known as fangism-ctrl-Z
<nalaginrut>morning guilers~
<rekado>tadni`: re XMPP mass usage: the CCC (German computer club) apparently does.
<rekado>I think it's a pity Pubsub never really caught on. There are hardly any clients with actual support.
<tadni`>rekado: Tox is kinda taking it's place and overall, I think that is a good thing.
<tadni`>Potientally casing itself to take it's place, I mean.
<tadni`>Tha being said, yeah, having a guile-xmpp would be nice.
<tadni`>I much rather see a relatively complete set of bindings for guile-tox at some point though, for my own interests.
<rekado>tadni`: I've never even heard of tox.
<tadni`>rekado: https://tox.im
<tadni`>Okay, heading off to study. Be back in like 10 hours, probably.
<lloda`>rekado: I use SRFI-64 for a couple of binding modules (b/c of this channel, actually) and I'm not a fan. Is ggspec https://github.com/yawaramin/ggspec? Why doesn't it support >2.0? I think Guile should come with something better than SRFI-64, I don't care if it's an SRFI or not.
<rekado>lloda`: there's a branch for 2.0
<rekado>lloda`: there's really just one or two statements in the master branch that are deprecated in guile 2.0
<rekado>lloda`: and yes, that's the ggspec I was referring to.
<lloda`>thanx, i'll have a look
<civodul>Hello Guilers!
<_zxq9_>hi
<ijp>happy human rights day
<_zxq9_>In commemoration we should invent new "rights". Enough that enforcement of them means trampling most of the others (but only categories of people we don't like, as per The Code).
<ArneBab>moin nalaginrut
<nalaginrut>ArneBab: heya
<amirouche>I've successfuly rolled a autoconf config for my project
<amirouche> http://www.nongnu.org/guile-reader/ is an example of non-dynamic bindings + guile sources
<amirouche>(and guix config, but that one is easy once the autoconf config done)
<Tsutsukakushi>an option to make menuconfig style dialog to choose the options when installing from sources, this would mak the .scm more complicated but would enable more people to install a package with customized options
<Tsutsukakushi>oh, this was t he wrong channel...
<stis_>hej guilers!
<wingo>ahoy :)
*wingo just made the evaluator 50% faster, whee
<stis_>woah, what was the issue?
<davexunit>wow
<sneek>Welcome back davexunit, you have 1 message.
<sneek>davexunit, civodul says: just tried Sly with 'guix environment', and got "Symbol not found: glGenTextures" in gl/low-level.scm when running 2048
<davexunit>oof!
<davexunit>someday, Sly will run for people that aren't me.
<wingo>stis_: we were doing too much dispatch at runtime
<wingo>i put in a little compiler
<stis_>ok
<davexunit>the limit for my excitement for guile 2.2 approaches infinity.
<davexunit>new release of the Elm language, a pretty cool Haskell-like language for the web: http://elm-lang.org/blog/announce/0.14.elm
<davexunit>they have this interesting packaging tool that can create diffs of a package's public API, so when you upgrade you get precise information about what has changed.
<dsmith-work>Morning Greetings, Guilers
<stis_>hej dsmith-work:
<dsmith-work>wingo: IS that the C evaluator? As in makeing the builds faster?
<wingo>dsmith-work: eval.scm, so it should make the builds faster
<dsmith-work>stis_: Hej hej
<wingo>davexunit: we have that too
<wingo>apicheck or something
<wingo>in guile-lib
<wingo>you can get a diff on api changes
<daviid>wingo: that's wonderfull!
<dsmith-work>wingo: Better and better!
<daviid>wingo: have to ping you :) it's my terrible mission, against my wish, to be the reminder of things to do 'in the past', grab some of your precious energy and dedication to to 2.2 back to 2.0, how sad, but: i'm stuck in fa1a307 and also really wish to see some love to goops: the subclasses a/g/s inheritance bug, it really important, I think
<wingo> http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=95de4f52a8ed34e64c342634add939c7e23214ac
<mark_weaver>wingo: oooh, nice work on the evaluator! :)
<wingo>tx!
<mark_weaver>wingo: but yeah, daviid is right to remind you about <http://bugs.gnu.org/18570>. It's one of the blockers to releasing 2.0.12.
<mark_weaver>if you don't have time to look into it soon, I could revert those commits I suppose and we could revisit them later.
<daviid>i think the goops bug should be raised to important
<daviid>[ if it's not the case yet ]
<mark_weaver>18570 is marked as important.
<wingo>yeah i do need to do that
<wingo>maybe tonight!
<mark_weaver>that would be great!
<daviid>mark_weaver: that's not the foops bug i was refering to: there a serious bug in acessors/getters/setters 'calculus' for subclasses [excuse my bad wording here]
<daviid>i'm trying to find it
<mark_weaver>daviid: I think I remember what bug you're referring to.
<daviid>it is more important then 18570 imo
<mark_weaver>18570 breaks guile-gnome completely, doesn't it?
<mark_weaver>whereas the other problem has been there for years
<mark_weaver>(iirc)
<daviid>mark_weaver: that bug i'm talking about breeaks any goops code
<daviid>if using sublcasses, it is terrible, you understand?
<daviid>any code using sublasses cna _not_ rely on accessors, getters and setters
<mark_weaver>daviid: can you find the bug number? I've forgotten the details
<daviid>yes, trying, i'm bad at this but i reallllly wish we debug it
<mark_weaver>let's put it this way: 18570 is a regression relative to 2.0.11, so it blocks the 2.0.12 release because we don't want to introduce a _new_ bug.
*wingo updates his stable-2.0 checkout
<mark_weaver>the other problem is already present in 2.0.11 (and probably all of 2.0.x, if not earlier), so releasing 2.0.12 wouldn't make anything worse.
<mark_weaver>although I don't remember anything as bad as you're now painting it. maybe I misunderstood.
<wingo>i think we could land a similar eval speedup in stable-2.0 fwiw
<daviid>but that's only for guile-gnome and we can revert, without any problem. while the bug i'm rfering too breaks goops
<wingo>just the eval.scm part
<mark_weaver>daviid: I can't really think about the other issue without seeing the details again, so the next step is to find those details :)
<daviid>bug#17355: #:getter procedure returns unexpected value in GOOPS
*mark_weaver looks
<daviid>mark_weaver: sure, was on the phone sorry
<wingo>daviid: is that one a regression?
<wingo>i don't think it is
<wingo>not sure if it can be fixed tbh
<wingo>i mean, without a specialized composite slot computation
<mark_weaver>wingo: wow, if it really can't be fixed, that's not good. hopefully we can at least do something better than returning the value of the wrong slot.
<wingo>that's the thing -- for goops they are the same slot
<daviid>wingo: it's a serious bug, all i can say [regression, don't know]: it breaks any code using goops, i mean any goops code using inheritance. right now i have to re-write manually all accessors/getters/setters for all subclasses
<wingo>i think the amop has some things to say about this
<wingo>think of the subclass as refining the existing slot to override its initializer
<wingo>you can use a different composite slot resolution thing but that's the default model
*wingo looks
<mark_weaver>wingo: I wonder if you've read the bug report carefully enough.
<wingo>the compute-slots generic
<mark_weaver>(foo-a (make <bar>)) => 42
<daviid>mark_weaver: the bug report is partial
<mark_weaver>42 is the value of the 'b' slot.
<wingo>of the "b" slot! i thought bar redefined the a slot
<wingo>perhaps i did misread
<daviid>slot-ref will work
<wingo>wow that is strange :)
<daviid>it is the accessor/getter/setter that are _not_ good
<wingo>yes i did misread it, thank you mark
<mark_weaver>daviid: can you send a message to 17355@debbugs.gnu.org with whatever is missing from it?
<mark_weaver>wingo: welcome :)
<wingo>what a strange thing
<wingo>i'll take a look at both of those tonight, unless you're on this one mak
<wingo>*mark
*wingo in a happy hackplace
<mark_weaver>wingo: if you could look at both, I'd be grateful. I've never dug into the goops code.
<wingo>no prob
<mark_weaver>thanks!
<mark_weaver>yay for happy hackplace :)
<daviid>mark_weaver: i don't think it is necessary, if i may say, it just shows the getter problem, where i wrote at that time, you can try, that slot-ref is working... what is missing is just a accessor/setter but that is solved once the getter will be solved, imo, since it is the mecanic of a/g/s inheritance that is involved
<mark_weaver>daviid: okay, makes sense.
<daviid>wingo: so many thanks, it would be so cool, i'm really 'suffering' because of these 2
<mark_weaver>daviid: I strongly suspect that when the getter is fixed, the accessor/setters will be fixed too. it's all related.
<daviid>mark_weaver: exactly
<daviid>i mean i strongly suspect too...
<wingo>there is some special logic for getters that tries to access by slot number
<wingo>anyway, will look at tonight when i get to the hotel
*wingo in coruña for work
*mark_weaver marks #17355 as "important"
<daviid>mark_weaver: thank you
<daviid>wingo: be aware whiule debuggin that accessors/setters are not working either [properly recomputed foir subclasses i mean
<daviid>one needs to redefine all of them, just calling next-method, but it's a real pain for big code...
<daviid>bbl
<davexunit>wingo: hmm, I didn't know about apicheck. is guile-lib separate from core guile?
<dsmith-work>sneek: guilelib?
<dsmith-work>sneek: guile-lib?
<mark_weaver>yes, it is separate
<dsmith-work>sneek: guile-lib is http://www.nongnu.org/guile-lib/
<sneek>Okay.
*wingo looks at the goops bug
<taylanub>dsmith-work: hm, but Guile modules are non-pure Scheme by definition :)
<taylanub>ah, I guess what's meant is the absence of C code in the Guile module
<wingo>hoo, so that goops bug is complicated!
<dsmith-work>wingo: Wow. That does seem a lot peppier.
<wingo>dsmith-work: does it? i didn't measure a fresh recompile
<dsmith-work>I din't measure either. And this was one of the very rare times I didn't clean first.
***fangism-ctrl-Z is now known as fangism