IRC channel logs

2014-10-07.log

back to list of logs

<rlb>irc sparc's not a jessie release arch, but any idea offhand why fluids.test fails? https://buildd.debian.org/status/fetch.php?pkg=guile-2.0&arch=sparc&ver=2.0.11%2B1-8&stamp=1412627578
<rlb>s/irc/iirc/
<nalaginrut>morning guilers~
<paroneayea>tricky question... is there any way in ice-9 match to do a predicate test on what's returned from the (= ) match?
<paroneayea>so for example
<nalaginrut>(? valid? (= func x))
<paroneayea>oh, yeah that's what I thought! though I can't seem to refer to x after that
<paroneayea>maybe I'm doing it wrong
<paroneayea>(match '(1 . 2) ((? number? (= car x)) x))
<davexunit>maybe you have to compose the procedures? (? (compose foo? bar) x)
<paroneayea>I know you can do something more smart than (car) for this example, it's a dumb example
<paroneayea>because I don't want to show my complex structure setup :)
<paroneayea>the thing I'd *like* to do is do a (? correct-type? (= field-of this-object))
<paroneayea>and then refer to the assigned version that I get back in the body
<paroneayea>but that seems not possible
<davexunit>I don't think that can work because that syntax isn't valid within the ? form.
<davexunit>where you have (= field-of this-object) is supposed to an identifier
<davexunit>to be*
*paroneayea nods
<paroneayea>yeah... seems there's no good way to do it.
<davexunit>(? (compose correct-type? field-of) this-object)
<davexunit>looks elegant to me :)
<paroneayea>davexunit: yeah, but then I'll have to pull the object out again afterwards right?
<paroneayea>because ? doesn't return the sub-field, it just checks that the predicate is true?
<paroneayea>in this case, I'm checking to see if a task string is in a list of structures with task-string-identifiers ;)
<paroneayea>so one way or another, looks like I have to run that operation twice if I want to use match... ?
<paroneayea>not the worst thing, though
<davexunit>maybe you want to map over the list first?
<paroneayea>I could... assuming I already knew this pattern matched ;)
<paroneayea>otherwise I might not have enough variables
<paroneayea>I'll just do the slightly wasteful way
<paroneayea>n*2 isn't so bad in this case, I doubt there'll be much there.
<paroneayea>thx davexunit , nalaginrut
<davexunit>yeah, probably nothing to worry about
<paroneayea>I do like that I can use (and )
<davexunit>maybe knows how to do it the way you want, though.
<paroneayea>and do the wastefulness all in the matcher ;)
<davexunit>yeah I was looking at 'and'
<nalaginrut>paroneayea: I checked out what I've suggested, it's incorrect since it'd be reversed order
<nalaginrut>so please ignore it
<davexunit>but wasn't sure how to form the expression
<paroneayea>nalaginrut: np, thanks for helping explore :)
<nalaginrut>;-)
<paroneayea>this wasn't one of those urgent needing-a-solution moments, just wondering if I was missing an obvious one :)
<davexunit>not obvious to me, anyway :)
*davexunit goes afk
<mark_weaver>paroneayea: if it helps, it's possible to do extra checking in the body of a match clause, and optionally indicate "failure", causing match to act as if the current clause had failed (proceeding to the next one)
<mark_weaver>it's not documented in the manual, but it's described in the comments in module/ice-9/match.upstream.scm . Search for "=> failure" in that file.
<mark_weaver>it's probably not worth it in this case though.
<mark_weaver>oh wait, nevermind. I see exactly how to do what you want.
<mark_weaver>sneek: later tell paroneayea: I think this is what you want: (match '(1 . 2) ((= car (? number? x)) x))
<sneek>Got it.
<mark_weaver>sneek: botsnack
<sneek>:)
<paroneayea>mark_weaver: whoa, yeah, that worked!
<sneek>paroneayea, you have 1 message.
<sneek>paroneayea, mark_weaver says: I think this is what you want: (match '(1 . 2) ((= car (? number? x)) x))
<mark_weaver>more generally, the second "argument" to '=' can be any pattern, and that pattern is matched against the 'car' in this case.
<paroneayea>mark_weaver: thanks
<mark_weaver>np!
<paroneayea>mark_weaver: it's tricky, because it does the opposite of what I expect :)
<paroneayea>the fact that the car'ed value gets pushed into the inner expression...
<mark_weaver>hmm, dunno, seems to make sense to me. the outer pattern corresponds to the entire thing being matched, and the inner pattern to just a part of what's being matched.
<mark_weaver>this is generally how patterns work. inner parts of patterns correspond to inner parts of the thing being matched.
<mark_weaver>the key is to think of it as a pattern, and not as a procedure call.
<mark_weaver>I guess maybe it takes some getting used to though
<paroneayea>mark_weaver: that does make sense, but it will take some getting used to for me!
<mark_weaver>btw, in the case of 'car', it could be more elegantly written as (match '(1 . 2) (((? number? x) . _) x))
<paroneayea>mark_weaver: yeah, car insn't a good example, but it's a simple example :)
<mark_weaver>*nod*
<paroneayea>here's the code I just wrote
<paroneayea> http://pamrel.lu/dd922/
<mark_weaver>paroneayea: fwiw, I'd probably (define (host? x) (is-a? x <host>)) and then the pattern could be (= get-host (? host? host))
<mark_weaver>which I think is more readable
<paroneayea>mark_weaver: agreed, I'll do that, thanks!
<mark_weaver>also, the first operand of 'match' usually looks better on the same line as 'match', but perhaps it's a matter of taste :)
<mark_weaver>but otherwise looks good!
<paroneayea>true! :)
<mark_weaver>paroneayea: will 'get-host' always return either #f or a <host> ?
<paroneayea>yes
<paroneayea>so I guess, could be considered a predicate :)
<paroneayea>(though it's pulling it out of another structure)
<mark_weaver>well, it's fine as is. it's not clear to me how to improve it.
<mark_weaver>sneek: later tell rlb: regarding the fluids.test failure on sparc, I don't know! I haven't seen any reports of that problem before.
<sneek>Okay.
<mark_weaver>sneek: later tell rlb: nor have I seen the problem on my own sparc box with guile-2.0.11, although that box is still running squeeze.
<sneek>Okay.
<mark_weaver>sneek: later tell rlb: btw, I don't see any sign of guile-2.0 -8 in <http://anonscm.debian.org/cgit/users/rlb/guile.git/log/?h=deb/guile-2.0/d/sid/master>
<sneek>Got it.
<mark_weaver>sneek: later ask rlb: is that expected?
<sneek>Will do.
<paroneayea>mark_weaver: thanks for being so helpful! You really help make #guile a friendly place!
<mark_weaver>paroneayea: you're welcome! glad to help :)
<mark_weaver>(and thanks for saying so :)
<paroneayea>:)
<paroneayea>yay, remote command execution is starting to work in userops :)
<mark_weaver>\\o/
<nalaginrut>heh, seems the exactness of real is only 15 digits, interesting~
<nalaginrut>significant figures
<mark_weaver>nalaginrut: huh? guile's inexact reals are just C doubles.
<mark_weaver>do you think we have less precision than something else that uses hardware floating point? if so, what makes you think so?
<nalaginrut>I see, I haven't had the time to learn deeper about it
<ahills>floating point, meaning no guaranteed precision whatsoever :)
<nalaginrut>mark_weaver: no, I thought there's something special for implementing real, but seems no
<nalaginrut>I just don't get it before
<nalaginrut>nothing more
<mark_weaver>okay
<nalaginrut>;-)
<mark_weaver>:)
<mark_weaver>since 2.0.9 we have a very nice 'number->string' for inexacts though, probably better than many others out there. it prints just enough digits (and no more) to ensure that when read back in, you'll get precisely the same number.
<mark_weaver>if something else prints more digits, that's most likely suboptimal behavior on their side.
<mark_weaver>We use the algorithm described in "Printing Floating-Point Numbers Quickly and Accurately" by Robert G. Burger and R. Kent Dybvig
<mark_weaver>and when reading inexact numbers, we guarantee correct IEEE rounding.
<mark_weaver>well, I shouldn't use the term "guarantee". there's no guarantees, of course, but it's designed to work in all cases, backed by a careful test suite.
<mark_weaver>anyway, time for me to sleep.
*mark_weaver --> zzz
<janneke>Morning guilers!
<civodul>Hello Guilers!
***heroux___ is now known as heroux
***heroux is now known as 7JTAA4WJ5
***heroux_ is now known as 16WAAR95O
***7JTAA4WJ5 is now known as heroux
***nalaginrut__ is now known as nalaginrut
***madsy is now known as Madsy
***rlb` is now known as rlb
<davexunit>paroneayea: how do you do the code blocks on pump.io?
<davexunit>I want to reply to your guile code snippets with my own code snippet
<paroneayea><code><pre></pre></code>
<davexunit>okay
<davexunit>paroneayea: gah, my formatting didn't work
<paroneayea>davexunit: you can hit "edit" if in pumpa
<davexunit>I'm not :(
<davexunit>I should get it
<paroneayea>pumpa is nice
<paroneayea>pumpa the volume, dianara
<paroneayea>the jam
<paroneayea>if you were using the web interface, I guess my advice didn't apply, sorry!
<davexunit>all good :)
<davexunit>I'm gonna build pumpa
<davexunit>I wonder if the deps for pumpa are in guix...
<rlb>We needed to set CC=gcc-4.8 on arm in Debian to deal with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762238 for now.
<sneek>Welcome back rlb, you have 4 messages.
<sneek>rlb, mark_weaver says: regarding the fluids.test failure on sparc, I don't know! I haven't seen any reports of that problem before.
<sneek>rlb, mark_weaver says: nor have I seen the problem on my own sparc box with guile-2.0.11, although that box is still running squeeze.
<sneek>rlb, mark_weaver says: btw, I don't see any sign of guile-2.0 -8 in <http://anonscm.debian.org/cgit/users/rlb/guile.git/log/?h=deb/guile-2.0/d/sid/master>
<sneek>rlb, mark_weaver says: is that expected?
<mark_weaver>rlb: okay
<rlb>mark_weaver: perhaps fluids.test is "newer gcc related" (unfounded speculation)
<rlb>mark_weaver: wrt -8 -- I don't know what you're talking about ;>
<rlb>(just pushed it)
*rlb was about to ask a question about CC but may have answered it himself...
<daviid>heya guilers!
<rlb>I was about to mention that setting CC also embeds gcc-4.8 into guile-snarf, and if that's the only place it's needed, then that adds a non-trivial dep to guile-2.0-dev -- so I wondered if there was already some way to just set the compilation gcc, not the snarf/tools gcc.
<rlb>Hmm, maybe that's still a reasonable question...
<rlb>if that's likely to work OK, then I can always sed guile-snarf (already do), but that's of course also always a bit fragile...
<rlb>Wonder if it could make any sense to have an override that lets you distinguish between the build gcc and the runtime/tools gcc.
<rlb>i.e. the build gcc is likely to be more sensitive than that used by guile-snarf?
<rlb>or do they need to match fairly closely?
<daviid>nice, gnucash has been updated, prob a while ago, to depend on guile-2 and g-wrap dependency dropped [was concerned because g-wrap guile-1.8...]
*daviid just uploaded the g-wrap new manual pages to savannah, in an hour or so they shold be there...
<davexunit>what do people think about adding a macro to (ice-9 hash-table) for declaratively building a hash table?
<davexunit>(define myhash (hash-table (foo 1) (bar 2)))
<daviid>anyonw knows how, if possible, to change my savannah login name? [looking but so far so bad]
<rlb>davexunit: don't know that anything like it is desirable for plain guile, but clojure's map and set syntaxes are handy: {foo 1 bar 2} and #{1 2 3}
<davexunit>rlb: I know that a reader macro is not desirable. I'm wondering about a simple syntax-rules macro.
<mark_weaver>rlb: regarding fluids.test, I'm running libgc-7.2d on my sparc server (compiled locally).
<mark_weaver>rlb: regarding allowing two different compilers to be specified: it's something to consider. I'd like to hear civodul's opinion on it.
<mark_weaver>davexunit: hmm, dunno! what about just using the alist->hash table procedures you added?
<davexunit>mark_weaver: I wrote a macro that was a bit of sugar over that.
<mark_weaver>can you post to guile-devel about it?
<davexunit>mark_weaver: sure.
<daviid>mark_weaver: do we change doc/version.texi [UPDATED, UPDATED-MONTH] when changes concern the manual only ? I did change these [locally still] for g-wrap, but now i wonder?
*tadni ponders why Skribilo doesn't seemed to be used for any Guile based GNU projects.
<mark_weaver>daviid: yes, I think that's appropriate
<daviid>ok tx
<daviid>rlb: just to make sure, if gwrap/guile-gwrap go, libgwrap* should all go as well
<rlb>daviid: ok -- the current plan is to wait until next week, and then figure out "what to do", i.e. do we keep guile-1.8 or drop it and the remaining rdepends...
<rlb>(there aren't that many now, at least according to dak rm -s testing
<rlb>)
<rlb>anubis dico drgeo guile-cairo guile-lib lilypond mailutils trackballs libmatheval
<rlb>and I think maybe the last one was just fixed (10 days to propagate)
<daviid>ok [the above list lacks guile-gwrap and libgwrap* [several packages]]
<daviid>guile-cairo [debian] does not list gwrap in its dependency [a bug] but appart from that, guile-gwrap has 0 dependency, as well as guile-cairo, so as far as we are concerned, these pkg should not trigger a 'hold on' flag
<rlb>daviid: if they're missing, then yeah, there's a bug in their deps somewhere -- but then how did they get built on all the arches?
*rlb wonders
<rlb>daviid: or do you mean that they're runtime deps, not build-deps -- so the autobuilders wouldn't be affected by the missing deps.
<daviid>rlb: ah sorry, guile-cairo does not use g-wrap [I've always thought it did, but looking at the code now, it does not, it's been manually bind, wowh]
<daviid>anyway, these packages have 0 dependecy since guile-gnome has been removed
<rlb>ok, thanks
<daviid>and gnucash does not use g-wrap anymore
<mark_weaver>rlb: I know that guile-lib works "out of the box" with guile-2.0, so I don't know why that's in the list you gave.
<rlb>mark_weaver: wrt the ongoing guile/emacs discussion, I wonder if at some point more concrete proposals might help. i.e. say functions that accept a "bad char" handler, or whatever might require/allow the user to specify what should handle...
<rlb>s/should handle/should happen/
<mark_weaver>rlb: also, guile-cairo-1.4.1 works with guile-2.0 with very minimal tweaks.
<daviid>mark_weaver: guile-cairo git clone yes, but there has been no release with the modifications wingo did at that time, so no tarball ready for a debian maintainer
<mark_weaver>rlb: for details on those tweaks, see the 'guile-cairo' recipe in http://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/gtk.scm
<wingo> http://download.savannah.gnu.org/releases/guile-cairo/ for a more recent release
<sneek>Welcome back wingo, you have 1 message.
<sneek>wingo, mark_weaver says: regarding the case you outlined just before your run: if a marking function is called on an object that's collectable and not on the free list, then that seems to indicate to me that the object is not actually collectable. I mean, this is what marking is all about, right?
<wingo>i should make another one tho
<mark_weaver>wingo: ah, okay
<rlb>mark_weaver: wrt guile-library -- offhand I'd guess it's because the relevant version isn't in jessie/testing yet.
<rlb> https://buildd.debian.org/status/package.php?p=guile-lib&suite=jessie
<mark_weaver>rlb: okay
<daviid>guile-cairo git clone configure.ac still list guile-1.8 [for info]
<rlb>though oddly the buildd can't find guile-lib or guile-library in sid !?
<rlb> https://buildd.debian.org/status/package.php?p=guile-lib&suite=sid
<wingo>rlb: do you need a new release?
<daviid>wingo: any news? https://lists.gnu.org/archive/html/bug-guile/2014-09/msg00047.html
<wingo>daviid: ack, need to fix that
<wingo>sorry, will do!
<daviid>np, tx!
<daviid>wingo: glib/gnome/gobject/utils.scm defines 'with-accessors', should that not become a goops provided core macro?
<rlb>wrt guile-cairo -- looks like someone tried to nmu a fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746001
<rlb>but it didn't quite work: https://buildd.debian.org/status/package.php?p=guile-cairo&suite=sid
<rlb>but once we fix the guile-snarf issue, that may work...
<rlb>mark_weaver: it looks like only guile-snarf refers to CC (i.e. gcc-4.8) in the resulting binary packages. Any idea if it's OK (for debian) to just sed that to gcc?
<rlb>i.e. any reason guile-snarf has to have the same version of gcc as the build?
<civodul>rlb: no particular reason i think, just that @CC@ is known to work
<rlb>ok, I think we'll probably just use sed for now on armel/armhf so that the fact that we need to pull in gcc-4.8 to build won't also cause it to be pulled in whenever guile-2.0-dev is installed.
<rlb>mark_weaver: know anything about how the lilypond port is going? It's beginning to look like that might end up being the primary remaining rdepends.
<rlb>(if not, don't worry about it -- I'll check)
<mark_weaver>Ian Grant just sent me a very threatening email.
<mark_weaver>I forwarded it to the list, since he said I could.
<mark_weaver>he's basically saying that we could end up prosecuted for computer misuse, criminal negligence, etc, unless we stop everything we're doing and rewrite all our software in the radical new way he's been pushing.
<mark_weaver>I have it up to here with him.
<paroneayea>mark_weaver: I think he defined himself as 100% dismissible when he gave that response to your #3 on https://lists.gnu.org/archive/html/guile-devel/2014-10/msg00010.html
<paroneayea>if you look, you'll find out I've not insulted anyone, but you are complete idiots
<paroneayea>oh hey, nice reasoning there, guy
<tadni>Who is this? Anyone notable, in the GNU and/or Free Software community?
<civodul>mark_weaver: i think it's become FUD, and we should stop feeding the troll
<mark_weaver>al new way he's been pushing. [16:49]
<mark_weaver><mark_weaver> I have it up to here with him.
<mark_weaver><paroneayea> mark_weaver: I think he defined himself as 100% dismissible when
<mark_weaver> he gave that response to your #3 on
<mark_weaver> https://lists.gnu.org/archive/html/guile-devel/2014-10/msg00010.html
<mark_weaver>ugh, sorry :-(
<mark_weaver>civodul: I agree. it's best to ignore him at this point.
<paroneayea>mark_weaver: no problem, by the timestamp I can tell you're an erc user :)
<mark_weaver>yep :)
<civodul>heh
<paroneayea>somehow unintentional pastes on irc seems to happen more to erc users than anyone else...
*paroneayea is an erc user, so ;)
<tadni>jave: o/