IRC channel logs

2014-10-05.log

back to list of logs

<mark_weaver>daviid: who did the non-maintainer upload?
<cmhobbs>i'm trying to work through the guile tutorial and i'm having some 'unbound variable issues'. could someone tell me what i might be doing wrong?
<cmhobbs>here's my registers_functions declaration: https://gitorious.org/guile-noodling/guile_tutorial/source/2c276f8dd0dd72d0296c1989563e87242e4d041f:tortoise.c#L97
<cmhobbs>one sec and i'll post the error
<cmhobbs> http://paste.lisp.org/+332E
<cmhobbs>there's the error
<cmhobbs>i get that with all of the tortoise functions
<cmhobbs>i'm on section 3.3: https://www.gnu.org/software/guile/docs/guile-tut/tutorial.html#Register-Functions
<cmhobbs>well, i figured it out, i forgot to declare some variables and make swallowed the errors
***petercommand is now known as seadogpeter
<lloda`>maybe we need a -Werror option
<janneke>Hi Guilers!
*janneke found some time to spam guile-devel with more patches ;-)
<rlb>mark_weaver: so with 1baa215, what happened when the set-contents was missing?
<daviid>hello guilers
<daviid>mark_weaver, rlb sorry went akb...
<daviid>mark_weaver: you can track here: https://packages.qa.debian.org/g/guile-gnome-platform.html
<daviid>rlb: i beleive removing all not yet removed packages from debian is the best solution for now
<daviid>as far as we are concerned, it means g-wrap, guile-g-wrap and guile-cairo [guile-nome has been removed already, from testing]
<daviid>as it is now, i always recommand users to install from git clone anyway [the very very few users we have]
<rlb>daviid: ok -- I'll poke around -- though it's possible that guile-1.8 will actually stay in jessie (but pretend that it won't)
<rlb>daviid: should those packages be removed from debian regardless, or left in (if guile-1.8 stays), in your opinion?
<daviid>they should go imo, will explain
<daviid>users install from these packages end-up, sometimes not knowing, using guile-1.8 and send error messgaes to the list [guile-user or gtk-general], then we let them know that thjey run 1.8, then it confuses them, by the tme the know what to do, they lost interest and we lost 'reputation'
<rlb>ok, I'll see what's possible
<janneke>hey daviid .. who should i ping for http://lists.gnu.org/archive/html/guile-gtk-general/2014-07/msg00000.html ?
<daviid>janneke: i saw your patch, i did hope wingo would read it [as well] and give us a green light, did he say anything to you maybe? i remember he promised to read, at some point in the past...
<janneke>i didn't hear from wingo about this one yet, but i'm not always here
<janneke>should i just 'wait'?
<nalaginrut>janneke: the LALR one?
<daviid>janneke: i am very busy trying to finalize guile-gnome [devel branch] for a release [2.16.3], then guile-clutter [1.12.2], then g-wrap, guile-cairo for guile 2 [only], then i was thinking to include your patch :) don't hold your breath [the reason not including it now being 'i want to release guile-gnome as it is now, but guile 2 only', and your patch introduces a new api ...
<nalaginrut>oops, seems not
<janneke>daviid: ouch...
<janneke>daviid: i can appreciate that from the vieuwpoint of stability...
<janneke>but it makes the pace of schikkers-list development more glacial than it already is...
<daviid>janneke: i hope you remain 1 of our guile-gnome users. actually i hoped you also use guile-clutter at some point ... [did think aboutn that]
<daviid>did you checkout/use guile-gnome devel ?
<janneke>daviid: possibly...i ported libgnomecanvas
<janneke>but i'm not sure how or why i would use clutter
<daviid>i could see some fancy clutter effects for scores, notes ...
<janneke>i've been "waiting" to publish the latest schikkers list until it would run with stock guile-gnome :-(
<daviid>anyway, was speculating
<daviid>canvas, do you draw using cairo only?
<daviid>janneke: you should recomand guile-gnome devel git clone to your users
<janneke>no, i did do a spike with cairo but didn't get it going
<daviid>but it still would lack the patch as it is... hum
<janneke>daviid: i have had a script that builds autotools, guile, g-wrap and guile-gnome from source ... but people are hesitant about that
<janneke>daviid: ...righhht
<janneke>if it 'just runs' on latest ubuntu/debian, that helps :-)
<daviid>oh well, i am too busy, and of course as all of us, have a 'pay' work that grab a lot of my energy too
<janneke>daviid: yes, i appreciate that!
<daviid>have to go afk, bbl
<janneke>thanks!
<janneke>nalaginrut: yeah that too, and GUD ... ;-)
<nalaginrut>huh~you make lot of contributions these days ;-)
<nalaginrut>I care about the patch of LALR since I saw there's something to eliminate redundant conflicts, but I haven't looked it in detail
<nalaginrut>maybe I don't have to ;-P
<janneke>nalaginrut: i wish i was...i'm sending patches ...
<janneke>nalaginrut: that simple lalr thing you sent me really helped to get me going
<nalaginrut>oh which? Simple lang?
<janneke>yes
<nalaginrut>ah~I'm glad it help
<janneke>nalaginrut: yes thanks
<janneke>it somehow seems to me that such information is very hard to find
<janneke>as if we don't want guile to spread too quickly
<nalaginrut>seems I should post more blogs, I thought no one read them
<janneke>i just found another way to write the lexer, by accident via ludo
<janneke> http://git.savannah.gnu.org/gitweb/?p=guile-rpc.git;a=blob;f=modules/rpc/compiler/lexer.l;h=5d1dd711a0365628a8c438aecc28cdc6ed359c22;hb=HEAD
<nalaginrut>yeah, once I wish Guile integrate silex to provide a lexer generator, but someone think it's not suit for integrate
<janneke>ah...
<paroneayea>hey #guile
<nalaginrut>after then, I decide to excise for manual lexer, then I found manual lexer is nice too..
<nalaginrut>well, it's still good if there could be a lexer generator
*janneke is off for a bit
<nalaginrut>it's reasonable not suit for integrate, since silex have to run out of modules, as a script
<nalaginrut>oh, maybe 'run' plus 'out' is confusing..
<nalaginrut>I mean it may not be called as a function
<nalaginrut>but anyway, it could be added into guild
<paroneayea>hm
<paroneayea>how to hit the right middle ground...
<paroneayea>I really like doing GOOPS style keyword-heavy class instantiation, though that doesn't really seem to enforce "these fields are mandatory"
<paroneayea>I guess you could make an init-form that throws an error
<nalaginrut>paroneayea: could you show some simple code? it's not so easy to understand these with plain text ;-)
<paroneayea>nalaginrut: well, say I want to make something like
<paroneayea>(define-class <party> (place #:init-keyword #:place) (time #:init-keyword #:time) (snacks #:init-keyword #:snacks))
<paroneayea>snacks isn't mandatory, but I want to make place and time mandatory, at the time that I do (make <party>)
<paroneayea>so I'm thinking, maybe do (place #:init-keyword #:place #:init-form (throw 'mandatory-field))
<paroneayea>or something :)
<nalaginrut>let me see...
<nalaginrut>you want to throw exception when certain attribute is inited?
<nalaginrut>initialized
<paroneayea>no, I want to throw if the user fails to init it :)
<paroneayea>seems to work okay anyway :)
<nalaginrut>you may use #:init-thunk (lambda () (if something-failed (throw ...) 'ok))
<paroneayea>yeah
<paroneayea>this seems to work:
<paroneayea>(define-class <tester> () (foo #:init-keyword #:foo) (bar #:init-keyword #:bar #:init-form (error "#:bar is mandatory")))
<nalaginrut>well, I don't know if it's proper to assume #:init-form will run before the assignment
<nalaginrut>paroneayea: and #:init-form will cause some problems, it will be called only once no matter how many instances you made
<nalaginrut>#:init-thunk may avoid such problem
<nalaginrut>but anyway, it depends on situation
<nalaginrut>hmm...wait, it's not #:init-form but #:init-value which may cause the problem
<nalaginrut>" However, if the new instance creation specifies a valid init keyword and value for a shared slot, the slot is re-initialized regardless of its previous value."
<mark_weaver>rlb: regarding "1baa215, what happened when the set-contents was missing?", it's all explained in the bug report linked from the commit log, <http://bugs.gnu.org/17466>
<mark_weaver>
<rlb>mark_weaver: oh, uh -- right -- thanks.
<nalaginrut>paroneayea: For the quote above, I think it's not proper to assume the order of the init
<nalaginrut>it's not "if no init value then run #:init-form" but "run #:init-form first then re-initialize it if there's valid keyword was specified"
<mark_weaver>nalaginrut: as you corrected yourself, indeed #:init-form is evaluated for each instance.
<nalaginrut>mark_weaver: yeah, bad memory for me, since I try to drop OOP from both my mind and code for a time ;-)
<mark_weaver>that's probably a good idea. OOP is vastly overused, IMO (though occasionally it is the right tool for the job)
<nalaginrut>I think the reason is just because there're big and good code base to be reuse for OOP
<nalaginrut>so people don't want drop it
<paroneayea>nalaginrut: ah
<nalaginrut>paroneayea: check it in a thunk is safer
<nalaginrut>you may write a generic checker to reuse
<nalaginrut>I have to go to bed, it's 1:48am
<nalaginrut>night guilers~
<mark_weaver>good night, nalaginrut!
<paroneayea>night nalaginrut
<mark_weaver>rlb: I looked at the explanation in that bug report, but it's not as clear as I'd like, so let me clarify:
<mark_weaver>first, Ludovic wrote "the pointer to the bytevector’s contents would not be left pointing to the old bytevector." and that "not" should be removed from the sentence.
<mark_weaver>but the thing is, bytevectors contain a 'contents' field that points to the actual bytes. for contiguous bytevectors, that data is part of the same block as the bytevector header itself. when this header+bytes combination was resized, the contents pointer was not updated.
<rlb>daviid: lost my scrollback before I had a chance to copy it -- could you repeat the packages you thought we should drop from debian for now?
<rlb>...and would you qualify as the current nominal upstream, or should they be considered currently abandoned?
*rlb needs to know what to tell the ftp-masters
<mark_weaver>he wrote:
<mark_weaver><daviid> rlb: i beleive removing all not yet removed packages from debian is the best solution for now
<mark_weaver><daviid> as far as we are concerned, it means g-wrap, guile-g-wrap and guile-cairo [guile-nome has been removed already, from testing]
<mark_weaver>personally, I think it's a damn shame, because I know it's possible (and not very hard) to build all this stuff for guile 2. but I guess time is short and no maintainer to do the work :-(
<rlb>mark_weaver: and it's not just who can do the one-shot overhaul "right now", it's "who's going to maintain it for the next year(s)"?
<rlb>we may retain them in the end, but I try to keep that in mind when evaluating "packages in debian"...
<rlb>mark_weaver: in any case, thanks -- and wrt bytevectors -- so previously guile was just not setting the new bytevector to point to the correct content?
<rlb>mark_weaver: and I haven't checked to see if any of those packages have rdepends -- if they do, that'll complicate the removal (and make it less likely)
<rlb>but note that the alternative is keeping guile-1.8 in debian for another year or two -- arguably a situation with it's own maintenance "issues"
<rlb>(at least I think we finally banished 1.6)
<mark_weaver>understood
<paroneayea>hm
<paroneayea>I'm not sure how to do this
<paroneayea>hm, let me test again before I ask for help ;)
<paroneayea>got it ;)
<paroneayea>hooooooly sheeot
<paroneayea>davexunit: you weren't kidding
<paroneayea>(ice-9 match) massively improved the readability of cli-builder :)
<rlb>mark_weaver: I'm not entirely sure I can trust dak (debian's removal dep analysis tool), but if so, it's not mentioning g-wrap, but it does mention guile-lib. I'll have to check that one again...
<daviid>rlb: isn't there a guile-lib based on guile 2? I think so
<mark_weaver>rlb: guile-lib-0.2.2 works out of the box with guile 2. I know because we have it in GNU Guix.
<rlb>daviid: weird
<rlb>$ apt-cache search guile-lib
<rlb>guile-library - Library of useful Guile modules
<rlb>
<rlb>$ apt-cache showpkg guile-lib
<rlb>N: Unable to locate package guile-lib
<rlb>
<rlb>not sure what's going on there yet
<rlb>oh, it's the src package...
<rlb> https://packages.debian.org/source/sid/guile-lib
<rlb>hmm, so why is it holding on to guile-1.8...
<mark_weaver>the page you just linked to says it uses guile-2.0
<daviid>rlb: not sure whre I did see it and when :) sorry
<daviid>it's called guile-library and depends on guile-1.8 indeed
<rlb>ahh -- may have been fixed
<rlb> http://metadata.ftp-master.debian.org/changelogs//main/g/guile-lib/guile-lib_0.2.2-0.2_changelog
<rlb>one of the recent nmus (people have been helping)
<rlb>but it hasn't propagated to testing yet
<daviid>ok i found itr
*rlb is fixing his previous fix for drgeo -- which should finish that one off?
<daviid>it's guile-2.0-libs
<mark_weaver>its encouraging to see people helping with the NMUs
<daviid>or is not what you're looking foir guile-2.0-libs
<rlb>daviid: right -- that's actually part of guile-2.0
<rlb>(not the same thing)
<rlb>guile-lib (srcpkg) produces guile-library, and is "something else"
<rlb> http://www.nongnu.org/guile-lib/
<mark_weaver>I think there was a GSoC to update drgeo for guile-2, and he was asking questions here during the summer, but my impression is that he was a bit lost.
<rlb>so... looks like drgeo is a problem
<daviid>ok, then there is guile-slib as well [just to be complete]
<rlb>and I made it worse with my last upload (or not better)
<civodul>i think the new drgeo is not really part of GNU, and written in Smalltalk (Pharo)
<daviid>have to run afk for a little while, bbl
<rlb>i.e. I changed the deps, but not the build-deps -- now when I actually fix the build-deps, I see that it's using gh.h, etc.
<rlb>so... any strong opinions about removing drgeo from debian (if that turns out to be the last thing)?
<mark_weaver>I don't have a good sense of how often it's used. what does popularity-contest have to say about it?
<mark_weaver>(I forget how to look that up)
<rlb> https://qa.debian.org/popcon.php?package=drgeo
<rlb>more than I would have imagined
<rlb>(but I suppose I really had no idea either way)
<ngz>The problem is that there are not many free equivalents to DrGeo.
<rlb>well first thing -- I need to clean up the mess hideki and I made (assuming I understand the situation correctly now)
<rlb>i.e. drgeo does in fact have to depend on guile-1.8 for now
<mark_weaver>it probably wouldn't be hard to get drgeo working with 2.0, but I certainly don't have time to do it before the freeze.
<rlb>mark_weaver: if it were a few years ago, I could too, but when I started poking around the other day wrt gh.h and conversion, etc. (not for drgeo?), I realized some of my more detailed guile knowledge there had a touch of bitrot.
<rlb>so I suspect it'd take me a bit to get going again
<daviid>I think any pkg depending on guile-1.8 shoul d be removed because it is really bad for guile itself, it is terrible actually
<mark_weaver>well, it's also terrible for guile to have packages depending on it removed from debian.
<mark_weaver>worse, in fact, I would argue.
<daviid>ok, i desagree but ...
<mark_weaver>people have to trust that they can use guile without fear of getting screwed by incompatible changes.
<mark_weaver>and 99% of the time, they can, but alas lilypond and texmacs are two counter-examples (the only two I know of, fortunately), because they became too dependent on internal details of how guile 1 worked.
<civodul>rlb: this is DrGeo 1.1 but the one at http://www.drgeo.eu/ is 14.10, and again no longer uses Guile
<civodul>that said, although i'm disappointed TeXmacs and LilyPond didn't migrate, i think it would be unreasonable to remove them just because they depend on the old Guile
<daviid>civodul: it's been 5y
<daviid>are you not just 'scared' to loose 'clients': how could we possibly be responsible that people do not migrate?
<mark_weaver>the truth is, we could have handled the 1.8 -> 2.0 transition a lot better. we made a lot of mistakes. we broke things that we could have avoided breaking.
<daviid>mark_weaver: but you were not there yet, and you made a tremoundous diff since you joined
<mark_weaver>thank you, daviid, that's very kind
<janneke>daviid: i had a stab at the guile-2.0 migration two or thee years ago
<daviid>so all this is history. now they work on it, they can re introduce in debian later, no big deal
<janneke>daviid: i found it too hard to do and got little or no help back then
<daviid>janneke: me too!
<civodul>janneke: you mean no help from other LilyPond hackers, or Guile people?
<civodul>who's guilty? :-)
<janneke>yes, let's have a hanging!
<civodul>heh :-)
<janneke>i just want to turn the sentiment of: 'not wanting to migrate'
<civodul>ok
<daviid>but i think situation is by far much much better now, from 2.0 to 3.0, it will be smooth, i think, thanks to the work of our 3 co-maintainers, strick with spec and maintenance got a lot better recently
<mark_weaver>yeah, anyone who thinks that LilyPond hasn't migrated for lack of effort simply doesn't know the facts. they've had a very rough road of it.
<janneke>it's pretty hard, i think david kastrup is doing some great work now and requested some help from the guile community that may work out well
<civodul>"requested some help", uh ;-)
<janneke>lilypond has some pretty nasty circular define before use macro problems iirc
<mark_weaver>I'm not sure about TeXmacs though. It seems to me that their problems, while not trivial, are vastly more tractable, but when I looked the maintainer seemed simply uninterested in migrating, and was even looking into writing his own new language to replace guile.
<janneke>civodul: conversing/working together with david can be a challenge, i appreciate that
<mark_weaver>janneke: that's for sure!
<civodul>mark_weaver: he's the one who led to the mini-gmp work
<daviid>mark_weaver: thats's too bad [texmacs]
<civodul>Joris
<civodul>we should get in touch again with TeXmacs people
<mark_weaver>civodul: are you sure? I though mini-gmp was done by Niels
<mark_weaver>*thought
<civodul>yes, but that's because Joris complained that "Guile is too big", IIRC
<mark_weaver>oh
<daviid>brb
<janneke>LilyPond has been called the 1000 pound gorilla of music typesetting ;-0
<mark_weaver>I also saw Joris post somewhere that he didn't trust libgc to be robust.
<mark_weaver>(or something to that effect)
<mark_weaver>anyway, I think it's safe to say that any future transition will be an order of magnitude easier than the 1->2 transition.
<rlb>mark_weaver: possibly interesting at the end here (though I haven't had time to understand it yet) -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745995
*daviid think that if we had a good guile-gnome guile-clutter [opengl as well, we have that now], guile-clutter-gtk, well maintained, very very well maintained, we'd have a lot more users
<daviid>and applications based, entirelly on guile
*daviid wishes he had more free time to work on these packages
<daviid>but generally speaking it's all getting so much better
<mark_weaver>rlb: thanks for the link.
<mark_weaver>daviid: yes, I think it's important to have a good guile-gnome stack. I wish I had more time to work on it.
<daviid>mark_weaver: i think we [I] should create a seperate guile-clutter package/webpages, even though it depends on a couple of guile-gnome packages
<daviid>ideas for thought...
<daviid>I did say that already actually
<daviid>also, we should think about g-wrap using the modern ffi, instead of getting rid of it, thoughts?
<daviid>ideally g-wrap should use gir files and allow, maybe optionally to 'goppsify' the wrap
<daviid>s/goppsify/goopsify
<daviid>goops should be well maintain as well, it is not the case, imo.
<mark_weaver>well, it seems to me the most compelling benefit to rebasing guile-gnome on the dynamic FFI is to eliminate all the C code entirely. I think that benefit is the only thing that justifies the large amount of work involved in such a change.
<daviid>mark_weaver: brb
<mark_weaver>I really don't know much about g-wrap though, so I can't really comment.
<mark_weaver>I'd prefer pure scheme bindings, similar to guile-opengl.
<mark_weaver>except using gir, of course
<mark_weaver>but really it's up to whoever does the work :)
<tadni_>Is Guile-GNOME to the 3.x series even of bindings for GNOME software -- or still on 2.x?
<tadni_>Yeah, it's still on 2.x.
<tadni_>I guess this would aprox be a good time to do major restructural changes; too I'm assuming GNU Distro will eventually probably be using it for the full sized installer image.
<mark_weaver>janneke: your emails include the line "/home/janneke/.signature" above the actual signature
<mark_weaver>regarding the updates to 'guile-test-runner', there's a problem: the source-line value in result-alist has already had 1 added to it before you see it, and then you add another 1 to it when printing the error message.
<janneke>mark_weaver: oops ;-) thanks
<mark_weaver>and one last thing: the commit log doesn't conform to our conventions. look through our commit logs for examples.
<janneke>you aren't using GNU changelog style, or have my skills slipped?
<janneke>i'll have look, thanks!
<mark_weaver>(remove the line with the date, keep the '*' in the first column, and indent the continuation lines by two spaces)
<mark_weaver>we follow the gnu changelog style in other respects though.
<janneke>ah! yes, i tend to forget snipping the date out.
<mark_weaver>thanks!
<daviid>tadni_: right now we need help to get from [guile-gnome] 2.16 to 2.40! clone guile-gnome devel, fire your emacs, read HACKING and ... patches welcome
<daviid>!