IRC channel logs

<davexunit>paroneayea: cool!

<davexunit>hmm, I've gotten pretty good at eliminating scm->f64 and f64->scm instructions, but I've got some scm->u64 instructions that are killing me.

<amz3>héllo :)

<roelj>What's the shortest way of creating an empty file with Guile?

<civodul>roelj: (call-with-output-file "foo" (const #t))

<civodul>:-)

<roelj>civodul: Cool, thanks!

<lloda`>last patch on master gives me this

<lloda`>scheme@(guile-user)> (define x 0.0) (< 0.0 1e-15)

<lloda`>$5 = #t

<lloda`>scheme@(guile-user)> (define x 0.0)

<lloda`>scheme@(guile-user)> (< x 1e-15)

<lloda`>$6 = #f

<lloda`>

<lloda`>???????

<lloda`>can anyone confirm.

<roelj>lloda`: Sorry, I don't have the latest Guile. On 2.0.13 it returns #t on $6.

<ft>I get #t on 2.1.4.125-b0ccf, which is a few weeks old.

<ft>Ah, latest patch on master is "Add unboxed floating point comparison instructions" which seems related. Let me build that.

<lloda`>ft: yes

<lloda`>I have already tested HEAD~1 and it's fine

<ft>lloda`: Can confirm!

<ft>Also, incremental builds don't seem to update git version information correctly.

<ft>My binary now shows the buggy behaviour, but still says "2.1.4.125-b0ccf" when starting up, like my previous build did.

<ft>(major-version), (minor-version) and (micro-version) show the correct information, though.

<lloda`>ah thx

<lloda`>I think ./autogen.sh fixes the version

<lloda`>sneek: later tell davexunit your f64 unboxing patch may be buggy, could you check the irc logs at 13:01 ff

<sneek>Will do.

<ft>CET :)

<ft>And yes, running autogen.sh fixes the generated version string. Running configure alone is not enough.

<ft>I apologize if this is documented somewhere. :)

<lloda`>ft: HACKING mentions the ./autogen.sh step, but it says nothing about re-running or versions etc. I found out by trial & error

<ft>lloda`: Thanks in any case! :)

<davexunit>lloda`: if you believe my patch to be buggy, then revert it.

<davexunit>or I'll revert it. whatever.

<davexunit>just revert it when you get the chance. fuck it.

<davexunit>I don't have time to investigate today and I'm ready to just cut my losses.

<lloda`>whoa man, take it easy

<lloda`>patches have bugs, happens all the time

<lloda`>I'm not a maintainer and I don't revert other people's patches

<lloda`>if wingo thought the patch was worthwhile, so it was

<lloda`>I'm sure it can be fixed, it doesn't have to be right now

<lloda`>I can use the version before no problem, breakage on master is expected

<lloda`>just a report, fyi, etc.

***karswell` is now known as karswell

<jmd>I want to specify a match expression for a pair whose cdr is a record. How do I do it?

<sneek>jmd, you have 1 message.

<sneek>jmd, alezost says: that font is from 'font-misc-misc' package: look at "/gnu/store/...-font-misc-misc-1.1.2/share/fonts/X11/misc/fonts.dir" - it should be listed there

<jmd>(yes I have read the manual)

<davexunit>jmd: (match thing ((first-thing . (? is-this-a-foo? second-thing)) ...))

<davexunit>if you have access to the record type internals you can destructure the record directly, usually you only have access to that if you are writing some internal api

<davexunit>(match thing ((first-thing . ($ <my-record-type> foo bar ...)) ...))

<jmd>That second way is exactly what I tried.

<jmd>... wait no. What are foo and bar?

<davexunit>fields

<jmd>names or values?

<davexunit>those are identifiers that the struct fields will be bound to

<davexunit>consider this

<davexunit>(define-record-type <foo> (make-foo bar baz) (bar foo-bar) (baz foo-baz))

<davexunit>(match (make-foo 1 2) (($ <foo> x y) (+ x y)))

<davexunit>=> 3

<davexunit>x is bound to the bar field, y to the baz field

<jmd>Ok. I must use the first way then. I had misunderstood what $ does.