<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>i get that with all of the tortoise functions <cmhobbs>well, i figured it out, i forgot to declare some variables and make swallowed the errors ***petercommand is now known as seadogpeter
*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>mark_weaver, rlb sorry went akb... <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 <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 <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 ... <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>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>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>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 <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 <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 <nalaginrut>yeah, once I wish Guile integrate silex to provide a lexer generator, but someone think it's not suit for integrate <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 <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)) <nalaginrut>you want to throw exception when certain attribute is inited? <paroneayea>no, I want to throw if the user fails to init it :) <nalaginrut>you may use #:init-thunk (lambda () (if something-failed (throw ...) 'ok)) <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>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." <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 <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><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) <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>$ apt-cache search guile-lib <rlb>guile-library - Library of useful Guile modules <rlb>$ apt-cache showpkg guile-lib <rlb>N: Unable to locate package guile-lib <rlb>not sure what's going on there yet <rlb>oh, it's the src package... <rlb>hmm, so why is it holding on to guile-1.8... <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>one of the recent nmus (people have been helping) <rlb>but it hasn't propagated to testing yet *rlb is fixing his previous fix for drgeo -- which should finish that one off? <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" <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? <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>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>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>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 <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 <civodul>janneke: you mean no help from other LilyPond hackers, or Guile people? <janneke>i just want to turn the sentiment of: 'not wanting to migrate' <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 <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 <civodul>mark_weaver: he's the one who led to the mini-gmp work <daviid>mark_weaver: thats's too bad [texmacs] <civodul>we should get in touch again with TeXmacs people <mark_weaver>civodul: are you sure? I though mini-gmp was done by Niels <civodul>yes, but that's because Joris complained that "Guile is too big", IIRC <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>anyway, I think it's safe to say that any future transition will be an order of magnitude easier than the 1->2 transition. *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>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>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>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. <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. <tadni_>Is Guile-GNOME to the 3.x series even of bindings for GNOME software -- or 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. <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? <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. <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