IRC channel logs
2014-04-21.log
back to list of logs
<rlb>Is guild needed for anything other than "development"? i.e. right now it's in the Debian guile-X.Y-libs package, but I'm wondering if it should be in the guile-X.Y-dev package alongside guile-config, guile-snarf, and the guile-tools symlink that points to it. <rlb>oh, right -- but do they depend on guile-X.Y-dev? <rlb>i.e. do they already need the other things in the "dev" package? (if you know) <zacts>I don't know, but someone else will probably answer soon <rlb>Of course this is mostly just a debian-specific packaging question -- the dev package contains the headers, .so link(s), etc. <rlb>So if all of those (for example) need the .h files, then it'd be fine to move it. <rlb>And really I suppose I'm also asking where it belongs *conceptually*. <rlb>Since the guile-X.Y-dev package is version-specific, and you can only have one installed at a time. <rlb>hmm, perhaps that (partially) answers my question... <daviid>rlb: I've noticed that guile-1.6 is still in wheezy sid and experimental [but not in jessie <rlb>I'm hoping to get it removed from everything soon. <rlb>i.e. before we freeze. <rlb>neither should have stayed as long as they did, but there was the thread ABI problem... *rlb should have 2.0.11 in sid soon, fwiw. <daviid>nice. about 1.8, I did write to rooty, guile-gnome-platform-2 still depends on 1.8 on debian, but it's been years that it compiles fine with 2.0, we should remove that depedency... [I did offer to help but I would need help to help :)] <rlb>ok, well I've badgered all the reverse-deps (I found) a number of times -- I'll probably look again soon and see where we stand, but honestly, at some point, we may just have to remove it and anything else that depends on it -- then presumably the things that people still want in debian, will get fixed and re-uploaded for 2.0. *zacts still needs to gain the strength and energy to port guile2 to FreeBSD <daviid>guile-gnome-platform is important, how can i help to get it using 2.0 on debian? <rlb>daviid: either rotty will need to upload a new version, or if he's MIA, someone else will either need to NMU, or (if really MIA) take over the package. <rlb>NMU == Non Maintainer Upload. <rlb>If the changes are trivial, I could consider it, but I don't want to make a mess that I might not have time to support if they're not. <zacts>I would love to see lilypond use 2.0 also <daviid>rlb: is there a debian package maintainer tutorial/manual somewhere <rlb>daviid: depends on what you mean, but yes either way? <rlb>If you just want to be able to help fix packages, then you might prefer the packaging documentation. <daviid>rlb: I understand, I beleive the change is trivial: guile-gnome 2.16.2 has been built [the tarball] to work with guile 2.0, more then 2 years ago... <daviid>wel, I guess one starts by fixing here and there ... then who knows ... <rlb>And for packaging docs, we have our own references, but I'm sure there are also a lot of tutorials, etc. on the net. Personally, (if you're starting from scratch) I recommend using debhelper in most cases, and *I* also use git-dpm when possible. <rlb>Unfortunately, I'm not deeply familiar with the details since I haven't experienced that end in a very long time. <rlb>but as I said, I suspect there are also a lot of good bits elsewhere, wiki, tutorials, etc. <daviid>ok, tx. right now i'll see if I can read/fix guile-gnome dependency and talk to someone to review ... let's se, I am quite busy right now... <rlb>Quick start if you have a sid system: "# apt get build-dep PKG", "$ apt-get source PKG", "$ fakeroot debian/rules binary", but I'd suggest something like pbuilder for official builds (i.e. upload candidates). <wingo>daviid: i think guild should be in the package that installs the guile binary <rlb>wingo: ok, so it's not -dev only? <wingo>rlb: yeah not -dev only; (hi! :); it's a general tool-runner for guile utilities <rlb>sadly I'm not as involved with guile right now (obviously), or I'd already know... <wingo>including the "guildhall" cpan-alike <wingo>it's user-extensible; adding sub-commands just means installing a (scripts FOO) module <wingo>i think of -dev as being related to linking to libguile, whereas guild is not really related to that <rlb>wingo: ok I'll put it in guile-2.0, though that means it'll need to be versioned, and handled by update-alternatives, etc. Any idea if that's going to be hard? <rlb>wingo: guile-config in in -dev too fwiw <wingo>rlb: yeah that sounds about right i guess. i think versioning should be fine. though... packages do tend to invoke guild at build-time to compile scheme files <wingo>well then the easy thing for you is to do the same thing with guile-tools as with guild <rlb>i.e. the non-dev package is just to provide stuff you need to run guile itself, not things that just need the libs, etc. <wingo>i am not sure whether that is the right split though <rlb>right, though I'm also wondering how it "ought to be" <rlb>to some extent, there's a practial distinction -- it's easier to put things in -dev because it's exclusive, i.e. only one version installed at a time, so we don't have to worry about versioning. <rlb>(versioning the executable names, and the internal invocations, etc.) <wingo>afaiu the only issue you will run into is packages calling "guild compile ..." in their Makefiles <rlb>iirc guile's much more "multiple version" friendly now -- it'd be great if the support was "complete". <wingo>i guess we should provide a way to go from guile-2.0.pc to a particular "guild" location <wingo>rlb: not sure what is missing, but we're happy to fix it <rlb>i.e. if the upstream just directly supported multiple versions installed in a debian/fhs friendly way ;> <wingo>i think that might be possible with --program-suffix <rlb>I'd be happy to help with that -- would also make my job easier (assuming it's not already possible) <wingo>not sure what the implications are for other projects, or how (if at all) guile.m4 should change <rlb>The less debian-specific weirdness, the better. <wingo>the only other collision that i know of is the manual <rlb>yes -- and that at least used to be partially an issue with info (standalone and emacs). There wasn't a good way to have multiple versions installed and see them all, etc. <rlb>wingo: short-term, now I'm wondering if it might be best to just move guild to guile-2.0-dev alongside guile-tools... <wingo>rlb: sounds like a fine short-term solution <rlb>because regardless, not sure it should be in libs. <wingo>it seems like a silly distinction, given that all of its functionality is in libs :) <wingo>but i understand the headaches involved in names and versions <wingo>and it's attractive to just work around this issue :) <rlb>yeah, I meant for *now*, i.e. can't be in libs b/c it'll conflict with guile-2.2-libs. <rlb>i.e. I already have a problem? <wingo>yeah i guess that is the case <rlb>May have to make guile-2.2-libs "Conflicts:/Replaces:" "guile-2.0-libs (<< 2.0.11)" or whatever... <rlb>I assume I just wasn't paying close enough attention when I packaged 2.0. <wingo>hopefully we can release a guile 2.2 prerelease soon. i just finished what i think is the last blocker today <wingo>so after a round of news updates and such we can get on the 2.1.x prerelease train... <rlb>Nice (and DOH -- more work for me ;>) <rlb>So are there any major incompatibilities between 2.0 and 2.2? i.e. wondering how long 2.0 might have to linger (hopefully not as long as 1.6/1.8). <wingo>much fewer than 1.6->1.8 of course, and fewer than 1.8->2.0 (practically no scheme-level changes, only C level changes are removing deprecated interfaces) <wingo>so hopefully 2.0 won't /need/ to be around as long <wingo>it's tough to know exactly how it will play out but i am optimistic :) <zacts>wow this HURD actually has some interesting ideas. <zacts>I would be totally interested in implementing guile-scheme bindings to the HURD eventually. <zacts>I'm currently learning SICP / scheme, and don't know C. So this would be a few years down the road. <zacts>even better would be someone to implement the bindings for me, so I can just start playing around with HURD + scheme <zacts>oh really, like a dual boot? <zacts>cool. if I get the gnu glug laptop I'll try that also. <zacts>I'm now way more interested in the HURD now that I kind of understand its design philosophy better <zacts>sorry to flood #guile with HURD stuff, I'm just a bit excited about it. <zacts>mark_weaver: it kind of also reminds me of what you said about implementing fewer things with C as much as is possible. <zacts>cluck: so I'm reading the wikipedia page on FFI <zacts>so an FFI allows you to call functions written in another language? <zacts>guile could call C functions for example? <ft>Yes. The manual has an example that calls a function from the system's C math library. <ft>A bessel function, IIRC. <rlb>zacts: though note that if things haven't changed (and they may have in guile), a runtime-ffi layer is often slower and "riskier" than a compile-time ffi. <rlb>the riskier is because you (normally) have to keep track of the underlying type (sizes) yourself. <zacts>I don't know the difference. <rlb>i.e. what's a g_long? <zacts>I'm on a 64bit platform Intel i3 cpu <zacts>I don't know enough C to answer that question, honestly.. <rlb>zacts: right, but if you handle the wrappers at compile-time, the c-compiler knows exactly what the foreign type is. <rlb>normally with runtime-ffi, if you're trying to wrap say "g_integer foo(g_float)", you have to tell the ffi call what the type sizes are, i.e. (wrap "foo" :int [:double]) or whatever. <rlb>but on some platforms g_integer might be a long, or a long long, or... <rlb>only the compiler (by parsing the .h files) knows. <rlb>or *you* by figuring it out on each platform you care about. <rlb>(or by running the compiler and having it compute and spit out the info you need) <zacts>rlb: but once that info is compiled, you can just extend the C api using guile scheme from then on right? <rlb>wingo: that's one interesting bit about clojurec -- it uses clang (or rather libllvm I think) at compile time to DTRT. <rlb>i.e. it just asks llvm what the types are <rlb>I hacked it (in my own branch) to support doing that more generally for non-ios programs (seems like Mark may be focused more on ios). <wingo>guile could do similar things via parsing dwarf, or via running the C compiler at expansion time as ludo does in libchop <wingo>portability is tricky tho; both approaches have their downsides <rlb>btw (all) -- been (very vaguely) toying with the idea of a clojure/guilevm -- and aside from feasibility, I wondered if there was likely to be many others interest... <wingo>rlb: DerGuteMoritz might have some thoughts; he's a chickener who clojures in the dayjob <rlb>wingo: interesting -- long ago I toyed with the idea of having a schemish that just requires gcc (at runtime). <rlb>though (and I understand the reasons why not) having a libgcc could be even more interesting. <rlb>it's unfortunate that the non-technical stuff (which also matters) is so at odds with the technically exciting stuff. <rlb>(i.e. no libgcccompiler) <rlb>wingo: just tested at least the no-op guile startup -- pretty fast (and vastly faster than clojure/jvm) <rlb>not that a microbenchmark like that tells you all that much. <rlb>but it does set a floor <rlb>looks like guile's about the same as python -- both much slower than perl, but plenty fast for interactive work as long as adding your first (format ...) doesn't kill you. <wingo>guile is much faster than python for me at startup <wingo>rlb: how fast is perl and guile for you? <ArneBab>guile is a bit faster than Python in this <ArneBab>wingo: but from what you wrote about guile 2.2, the startup time will improve by factor 2 (which I like a lot) <ArneBab>abusing the c compiler sounds really neat… <rlb>wingo: $ time guile -c '' <rlb>that's with a hot cache <rlb>wingo: wrt abusing-c, sure (assuming I understand), but that doesn't help for ffi does it? i.e. for libs that guile's never seen before. <rlb>i.e. it's more like compile-time ffi than run-time ffi <rlb>wingo: about the same <wingo>i get something similar indeed <wingo>$ time for i in 0 1 2 3 4 5 6 7 8 9; do /opt/guile-2.2/bin/guile -c 1; done <wingo>$ time for i in 0 1 2 3 4 5 6 7 8 9; do /opt/guile/bin/guile -c 1; done <wingo>so indeed, about those times... <wingo>time for another optimization spree i think ;) <rlb>what you really need is everyone to adopt self-describing c libs (i.e. some convention, preferably in the lib). <ArneBab>to make that more representative: time for i in {1..100}; do guile -c 1 ; done <ArneBab>time for i in {1..100}; do perl -e '' ; done <wingo>that's quite a lot for the guile part <ArneBab>it’s the usual runtime for me. I would guess that most of it is down to disk seek times. <ArneBab>sys 0.3s (guile) vs. sys 0.03s (perl) <wingo>you have a spinning-metal hard drive i guess *wingo just fixed the 8/12 bit addressing limitations in master; unfortunately needs a rebuild <rlb>wingo: has guile made any progress on versioned "linking", i.e. (use-modules (foo bar :v 2)) or whatever? <ArneBab>I got down to 2.1s now - I guess my filesystem was still cold *rlb thinks both guile and clojure (or more likely the jvm) need something like sonames. <rlb>the jvm is a mess on that front <rlb>(or at least java and clojure are) <dsmith-work>Well, my beaglebone black arrived over the weekend. Still trying to get Debian on it. I've got the SD card booting it, but I have had no success getting it on the eMMC flash. <ft>dsmith-work: Are you happy with the board otherwise? manufacturing etc.? <dsmith-work>The SD card slot was/is very stiff. It doesn't do the push/push thing properly. <dsmith-work>It was very cool how it booted up first time though. <rlb>I really want something like that, but where you can just plug in a debian-installer usb-stick. <dsmith-work>Just plugged it in to a usb, and I had a new ethernet interface and I could http and ssh to it over that. Had mdsn (avahi) running too. <rlb>i.e. I there to be some boards like that, that we support natively in debian. <rlb>but I imagine some of the work there is upstream-kernel-ish. <dsmith-work>I don't like that the serial needs special hardware. Usually a usb converter. <rlb>I was surprised that the (much more expensive -- and power-hungry) atom NUC was as cheap as it is ~$140? <rlb>for my purposes, that might be better... <rlb>(has built in wireless too) <dsmith-work>And you can't jsut wire rs-232 standard signals to it. Will blow the chip apparaently. (so no MAX-232 or simiar chip on board) <rlb>(and a place to mount a drive) <rlb>dsmith-work: assume you have a rev b? <rlb>(saw the rev c announcement) <ft>rev-c is the same as rev-b but with a bit more mmc, IIRC <ft>Yeah, the debian switch is in the making for a while now. <rlb>but I'll probably get one of those nucs for now... <rlb>don't need *really* tiny yet, or that much cheaper <dsmith-work>I need this for another project, but soon it will be sneeks home. <rlb>...think it is about $140 <rlb>but you still have to buy ram and provide your own storage of some kind. <dsmith-work>The rpi is cute, but I don't like the broadcom blob, and I've had many SD card issues. <zacts>I like the beagle bone black > rpi <rlb>(more likely what I'd want too -- if/when I need smaller/cheaper) <dsmith-work>Ahh! There was a red blob of glue or epoxy that oozed out from underneath the SD card slot and was in the way, making insertion/removal "stuff". <dsmith-work>A little scraping with a knife and I can pop it accross my desk now!