***slyfox_ is now known as slyfox
***Server sets mode: +nt
<rlb>nb. it looks like g-wrap, guile-cairo, and guile-gnome-platform are orphaned in debian, and still depend on guile-2.0. We're going to want to remove guile-2.0 from debian, and so unless I either manage to find the time to try to upgrade all of those packages (I very likely won't become the maintainer), or someone else takes them over, they're likely to be removed from debian "at some point". <rlb>And if I *do* manage to upload guile-2.2 versions, that may just delay the removal unless someone adopts them. (I also don't know anything about their current state upstream -- just wanted to mention the situation.) <daviid>rlb: they all work with guile-2.2, fwiw. however, (a) upstream guile-gnome requires guile-cairo 1.10, which has never officially been release; (b) guile-gnome 2.16.5 'only' will work with guile-2.2 <rlb>daviid: thanks -- I suppose one outcome is that they end up leaving debian until there's enough demand for someone to bring them back. I also haven't checked on an other possible reverse dependencies (or build dependencies), i.e. would we just need updates to those, or is it going to require a substantial coordinated decisions (partially why I suspect I won't have time to handle it myself). <daviid>the debian guile-cairo package is 1.4 iirc <rlb>s/decisions/transition/ <daviid>unless one of the two guile-cairo maintainers make a release, I do't see what I can do to make it o guile-gnom is kept in debian <daviid>though i already prepared guile-gnome, 2.16.5, which works fine here (buster, which droped 2 gnome libs), so technically, guile-gnome upstream is fine to be and remain in buster <daviid>I received a debian bug report recently though, but that is for 2.16.4, with guile-cairo 1.4 ... saying that automatic build fails, and tha is becuse it can't find makeinfo, iiuc, and sunded very strange to me (as the reason it would be dropped from stretch) <daviid>it seems g-wrap is the latest in buster, so on that side we wuld be fine <rlb>but I think g-wrap is built against guile-2.0, so it'd need to be rebuilt? And so I was wondering what else might have to be rebuilt along with g-wrap (as a transition). <rlb>i.e. what depends on g-wrap that would be affected by its rebuild against 2.2. <daviid>note that gule-gnome 2.16.5 depends on guile-lib 0.2.5, and buster only has 0.2.2 <rlb>If I understand that bug, maybe it just needs to build-depend on makeinfo? <daviid>but why would this 'trigger' now, that I don't understand <rlb>Oh, might be that dpkg or something had a wrapper that's now deprecated/gone or something. <rlb>dunno, or something else it does build-depend on no longer build-depends indirectly on texinfo. <rlb>dpkg used to have it's own isntall-info? I forget. <daviid>yes, but the debian maintainer could easily add texinfo right? <rlb>Sure, but there isn't one. <rlb>(maintainer that is)? <daviid>we're i a sort of a dead end then <rlb>it's orphaned as is g-wrap and guile-cairo <rlb>that's the main thing I was bringing up <rlb>And we really don't want to ship guile-2.0 in buster, so we may end up having some hard decisions. <daviid>you mean when buster becoes the next stable? I agree <rlb>yes, and we'll need to have things mostly settled in the next few months. <daviid>anyway, even if we can ask for a guile-cairo release, then eveythig would be ok upstream, the fact that there is no debian maintainer is a blocker <rlb>I think we've finally gotten the guile-2.2 tests passing more reliably on the release architectures, but that may still leave a lot of transition work. Haven't checked again yet -- mostly involves badgering maintainers, etc. <daviid>i am looking at the page, but i don't know where to look about this <daviid>and the latest is 0.2.6.1 (not 0.2.5.1) sorry <daviid>it's unfortunate they became orphan, I see g-wrap is not orphan <daviid>the solution would be: (a) to (ask for) release guile-cairo; (b) I release gule-gnome to depend on it; (c) debian finds a maintainer for gule-cairo and guile-gnome but I fear (c) is not going to happen <lloda>I lost your question the other day <lloda>the reason I haven't tried to release the guile-cairo bugfixes is that I cannot get the doc to build :-/ <lloda>I get some parsing error in guile-gnome somewhere that stumps me <daviid>yes I know (though I don't know how to fix it either) <daviid>in guile-cv, I have im-multiply, the matrix multiplication proc name,then working on iage textures, I realized I needed im-times (elts per elts multiplication), and im-divide (elts per elts div, but that name is used for matrix mult. of the inverse ...) hence I thought I should rename ... as octave does things <daviid>octave uses times, mtimes, divide and mdivide <daviid>now, I think I should rename im-multiply -> im-mtimes, im-divide im-mdivide, and then create im-divide, im-times ... WDYT? <lloda>those look regular but easily confused tbh <lloda>I'd just call im-times = im* and im-divide im/ <lloda>maybe I'm not the best judge of this <lloda>paralleling octave seems like a good idea <daviid>im- is the prefix of all procedures and methods in guile-cv, whchis fine, then the thng is to have mtimes, times, mdivide and divide, I guess it's ok <daviid>i was about to leave actually, so see you ... ***rekado_ is now known as rekado
<lloda>is there anyone I can bug about (gnome gw support gtk-doc) ? <wingo>lloda: it's unmaintained afaiu <wingo>i wrote it, can answer anything superficial, but i don't want to get into anything deep <lloda>my problem is that when I run make generate-defuns ... <lloda>../env guile -c "(apply (@ (gnome gw support gtk-doc) gtk-doc->texi-defuns) (cadr (program-arguments)) 'heuristics '((cairo)) (cddr (program-arguments)))" ./overrides.texi somewhere/somewhere/cairo-svg.xml ... <lloda>it bombs on the first definition <lloda>is it ok if I post details in guile-user, you think? <lloda>maybe someone else will want to try and dig <lloda>honestly I don't have the time for it either <lloda>but I wrote something on top of guile-cairo and I think it's the best way to draw stuff in Guile, and fairly simple too <wingo>i am guessing that gtk-doc simply changed its output format <wingo>sure, guile-user is fine for that <jcowan>Is there a good reason why u8vectors and bytevectors aren't the same type in Guile? <civodul>jcowan: they are disjoint types but they're "compatible" <civodul>that is, you can use the bytevector API on a u8vector <jcowan>but why are they disjoint in the first place? <civodul>because SRFI-4 and R6RS are disjoint :-) <civodul>i think we wanted to have a way to distinguish between these two types <jcowan>I can't find any other R6 or R7RS Scheme that has SRFI 4 and makes the two types disjoint, and it doesn't make much sense to me <jcowan>I suppose an argument in favor is that you know whether to write them as #u8 or #vu8 <jcowan>Larceny accepts both but writes #u8 by default; you can configure the output port to do #vu8 instead <lloda>it seems to be a historical artifact of implementing SRFI & bytevectors separately or something <lloda>from what I've seen of the code <lloda>vu8 and u8 should be one and the same <jcowan>I'm writing a SRFI 4 implementation on top of rnrs bytevectors; the hard part is getting a working set of rnrs bytevectors tests ***Server sets mode: +nt
***rekado_ is now known as rekado
<daviid>rlb: I trust you :), but I visitied the debian g-wrap page yester., and it does not mentioned it's orphan (but I may have miss read), and I see it's been updated in july 2017 ... <daviid>lloda: did you actually changed anything wrt the doc in gule-cairo? <daviid>I released guile-gnome several time without being able to (re)build the doc as well (but its unchanged doc is available online), and I think it wuld be better to release guile-cairo (which also has its doc online...) <daviid>I wonder what guile-cairo version is in guix? <daviid>hum, it has guile-cairo 1.4.1 ???? <daviid>even guile-cairo 1.9.x would not be good enough (to run guile-clutter)