IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<civodul>Hello Guilers!
<civodul>for the purposes of line-buffering, shouldn't \\r be considered a line ending?
*civodul prepares a patch
<taylanub>civodul: IIRC only legacy MacOS used sole \\r for line-endings.
<taylanub>but I guess it doesn't have any other semantics attached so it sure wouldn't hurt to support that
<civodul>on Unices \\r goes to the beginning of the line
<taylanub>hrm, terminal emulators still support that, it might perhaps cause problems when one does (read-line) and only gets the part up to \\r from a line that really meant to control a terminal?
<nalaginrut>the current read-line doesn't eat \\r, which caused a bug in my multiform-data parser, then I add \\r to trimming list
<taylanub>nalaginrut: WDYM "doesn't eat"? on 2.0.11:
<taylanub> (with-input-from-string "foo\\rbar\\n"
<taylanub> (lambda ()
<taylanub> (display (read-line))
<taylanub> (newline)))
<nalaginrut>taylanub: I mean remove
<nalaginrut>I thought \\n\\r would be treated as a newline
<nalaginrut>but only \\n
<taylanub>it should
<taylanub>This also works fine:
<taylanub> (with-input-from-string "foobar\\r\\n"
<taylanub> (lambda ()
<taylanub> (display (read-line))
<nalaginrut>but anyway I trimmed it, because the string has to be trimmed for other chars later
<taylanub> (newline)))
<nalaginrut>there's #\\return invisible
<taylanub>I think both of these behaviors are correct, and might even be explicitly desired or relied upon when one deals with a terminal. I'm not sure how common it is for a sole '\\r' to be desired to delimit a line
<nalaginrut>this bug caused my uploaded filename has a redundant #\\return
<nalaginrut>anyway, it's not a problem for me anymore
<civodul>taylanub: that's because it's coarse grain: as soon as there's a line ending in the string, it flushes the port, including what's after the line ending
<civodul>also, line buffering is for file ports only (surprisingly)
<taylanub>civodul: what I wanted to demonstrate is that it doesn't stop at the \\r, it includes it and what follows, resulting in "foo" being overwritten by "bar"
<civodul>yes, we agree on that :-)
<civodul>but there's no real line buffering for non-file ports anyway
<civodul>so string ports cannot be used to test for that
<civodul>taylanub: i've posted a patch, comments welcome!
<taylanub>civodul: I kind of confused buffering with actual line-delimitation. should be fine I guess
<madsy>Woo.. can hardly wait for my Xtion PRO LIVE
<add^_>Happy Friday?
<add^_>I have a question, I just compiled guile from the 2.0.11 branch on git, but when I start guile it says it's version 2.0.9
<madsy>add^_: Probably an oversight
<add^_>hm, ok
<add^_>nothing to bother worrying about them :-)
<daviid>add^_: you need to make _version
<add^_>but why would I need that? It's the first time I install guile on this system
<add^_>I haven't needed that the first times the other times
<add^_>ahwell, I'll try
<daviid>did you remove the other version?
<daviid>that does not make sence you probably stil run another version imo
<add^_>the other version?
<add^_>It's a newly installed system
<add^_>Shouldn't be a guile on it
<add^_>Unless it's preinstalled with it
<daviid>well you're not new to this chanel, so I assumed you were using guile already
<add^_>I did say that it was the first time on *this* system
<add^_>but fair enough
<add^_>I'm still trying what you said :-)
<add^_>geh, git
<add^_>Need to redo something.. You'll have to wait for the result a while longer :-/
<lloda>add^: running ./ before make & make install will set the version tag.
<add^_>I've been doing that from the start
<add^_>Now it's correct, thanks guys :-)
<add^_>It might have been that I was in the wrong branch, should have been in origin/stable2.0 but I was in v2.0.11
<add^_>So I changed that, and ran the make _version besides the normal stuff
<dsmith-work>Happy Friday, Guilers!!
<civodul>Happy Friday! :-D
<daviid>ahh! yes, now it's a nice friday :)
<add^_>Finally, dsmith-work has approved!
<add^_>Ah, feels good to be back in scheme/lisp world. <3
<add^_>I was in Haskell world for a short visit, was nice, but I consider the scheme/lisp world to be home.
<add^_>And like people say in Sweden "Borta bra men hemma bäst" which translates to "Gone is good, but home is best" roughly.
<atheia>What a lovely saying…