IRC channel logs

2013-04-07.log

back to list of logs

***adu_ is now known as adu
<duper`>#(1) what is this notation? kinda looks like an F# flexible type
<duper`>Is that something new in R6RS?
<add^_>It's a vector
<add^_>a one element vector..
<duper`>is that a guile-specific type?
<add^_>No?
<duper`>i just don't remember it from R5RS *shrug*
<duper`>I'm coming back to Scheme after a break. forgive me. heh.
<add^_>:-)
<duper`>so what's the diff between a vector and a list?
<duper`>i know the diff between list and set
<duper`>just algorithmic complexity?
<add^_>Well, I can't give you a complete answer because I don't really know. But they are storing their data in two different ways at least (Duh). :-/
<add^_>So vectors is faster for stuff where you need presision.
<add^_>are*
<add^_>lists are more... general I guess.
<add^_>think about every cdr you'd have to put in to get the 86'th element of a list ;-)
*add^_ thinks there probably is a better way to read up on this...
<add^_>Probably the manual
<add^_>Then you don't have to listen to all my crap ;-)
<DerGuteMoritz>algorithmic complexity for random access is constant with vectors
<DerGuteMoritz>also vectors are fixed-length
*add^_ breathes out
<add^_>thanks DerGuteMoritz :-)
<DerGuteMoritz>heh
<add^_>lol
<civodul>Howdy Guilers!
***Guest76703 is now known as micro__
<mark_weaver>hi folks!
<mark_weaver>civodul: when you wrote "What about adding a sentence to mention (ice-9 bytevectors) under “Bytevectors”, and then ‘unget-bytevector’ under “R6RS Binary Input”?", did you mean to write (ice-9 binary-io) instead?
<mark_weaver>
<mark_weaver>duper`: yes, vectors are standard R5RS scheme, as is their read syntax #(a b c ...)
<mark_weaver>duper`: Guile comes with a copy of the R5RS. In the "Standard procedures" chapter, see "Other data types" -> "Vectors".
<mark_weaver>duper`: or see it in this HTML rendering of the R5RS: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.3.6
<civodul>hey mark_weaver!
<mark_weaver>hi civodul!
<civodul>mark_weaver: but you already replied to that email, and i replied to the reply :-)
<mark_weaver>yes, and I like your suggestion, and am implementing it now.
<civodul>ah, good :-)
<mark_weaver>but I didn't ask that question in my email, or at least I don't think I did.
<civodul>are we done then?
<civodul>yeah
<mark_weaver>I'll be very happy if we can get unget-bytevector and the keyword args/coding-scan-off patch into 2.0.8. (still waiting for a review of the latter :)
<mark_weaver>and then I'll consider 2.0.8 done :) (though of course I have lots of NEWS to write :)
<civodul>oh?
<mark_weaver>Subject: [PATCHES] Keyword args for file openers; coding scan off by default
<civodul>right
*civodul looks at the patch
<mark_weaver>thanks!
<janneke>hmm, (case key-val ((gdk:plus)) does not do what i expect
<janneke>(case key-val ((43) however does...
<janneke>do i need (case key-val ((,gdk:plus) or something... hmm?
<civodul>janneke: you need to use 'match' for that
<civodul>like (match key-val ('gdk:plus ...))
<janneke>ah
*janneke is such a newbie
<civodul>mark_weaver: review sent :-)
<janneke>i'm thinking either case or cond
<janneke>thanks!
<mark_weaver>civodul: thanks! :) I just sent an updated 'unget-bytevector' patch with documentation.
<mark_weaver>civodul: good idea for the docs regarding the coding declaration scan :)
<civodul>now for the 2nd patch
<mark_weaver>civodul: I also think that you suggestion "What about adding a sentence to mention (ice-9 bytevectors) under “Bytevectors”, and then ‘unget-bytevector’ under “R6RS Binary Input”?" is a good one, but I don't know enough about (ice-9 bytevectors) to do so competently. would you like to do that as a separate commit?
<civodul>either way is fine
<mark_weaver>sorry, I meant to quote only the first part of that sentence. I took care of adding the docs for 'unget-bytevector'.
<mark_weaver>civodul: the second patch is actually derived from a patch that wingo proposed a while ago; one of his BOM patches IIRC. I don't care that much about it.
*janneke got match to work... thanks civodul
<janneke>it 'feels' so expensive...why doesn't case work with integers?
<mark_weaver>civodul: I do think it would make sense for BOMs to take precedence over the coding declaration in 'file-encoding', but I'm in no rush for that.
<mark_weaver>(that was actually the motivation for fixing up the unget code, because I want to clean up 'scm_i_scan_for_encoding' at some point)
<mark_weaver>but again, this is post 2.0.8 :)
<civodul>:-)
<ijp>janneke: case will work with integers, but since it uses eqv? you need to be careful about exactness
<civodul>and it expects *literal* integers
<ijp>that too
<mark_weaver>ijp, janneke: right, 'eqv?' is fine as long as both numbers are exact. if either number is inexact, then it's the wrong tool for the job.
<ijp>anyway, good afternoon
<mark_weaver>(unless you're doing memoization)
<mark_weaver>hi ijp!
<mark_weaver>s/the wrong tool/probably the wrong tool/
<janneke>civodul: okay, only literals for case ... so: (define plus 43) won't fly with case?
<janneke>i like something like: ((plus) (handle-plus)) much more than
<janneke>((43) (handle-plus)) ;; 43 is ascii plus
<janneke>anyway, i learned match and need to look into eqv? and case :-)
<mark_weaver>janneke: ((plus) ...) has a different meaning in 'case'. it means (eqv? x 'plus).
<mark_weaver>janneke: 'case' is not a primitive. it is built using the macro system. it's easy to build other derived syntax that does what you want. 'match' is a good example.
<janneke>mark_weaver: i understand... so where do i shove the unquote in?
<ijp>you can't
<ijp>it's roughly analogous to the situation with `switch' in C
<mark_weaver>janneke: yeah, you can't do what you want with 'case'.
<mark_weaver>'case' can only match against literals.
<wigs>an alternative would be to use (integer->char key-val), then match against chars #\\+ so it is more readable
<wigs>depends on the range of values that key-val could be
<janneke>aaargh
<janneke> (define plus 43) (define minus 45) (match minus (('hello (who)) "foobar") (0 "found zero") (plus "plus") (43 "43") (minus "minus") (45 "45") (else #f))
<janneke>$14 = "plus"
<janneke>:-)
<mark_weaver>janneke: I second wigs' suggestion. why are you using integers instead of characters for this?
<janneke>mark_weaver wigs: that seems nice!
<ijp>match uses variables for binding, not insertion
<janneke>thanks again!
<mark_weaver>civodul: thanks for the reviews!
<taylanub>The reason case only matches literals is that it can theoretically compile to a "jump table," right ?
<ijp>well, larceny does that
<ijp>one other issue is with evaulation
<mark_weaver>civodul: regarding "heuristics", I actually kept it vague on purpose so that we have license to improve the heuristics later. emacs, for example, does a *much* better job of guessing the encoding.
<ijp>consider (case $foo ((,$bar ,$baz) "quux") ((,$zot) "veeblefetzer) (else "xyzzy"))
<ijp>when do we evaluate $zot
<mark_weaver>civodul: however, I agree that it would be good to describe more precisely what is done today, but perhaps with an added "we may change these heuristics later". does that make sense?
<ijp>I suppose the "natural" semantics is to go one clause at a time, evaluating, and testing each in turn
<mark_weaver>taylanub: not only that. it's so that you can match against literal symbols, which in fact is a very common case.
<ijp>unless you restrict it to only allowing identifiers, and not arbitrary expressions
<ijp>at which point we then have the discussion about why it is only allowed to be an identifier
<taylanub>Well, matching against a literal would just be one apostrophe more, no ?
<ijp>hilarity ensues
<ijp>taylanub: one more each clause, or in clauses that contain variables, for each symbolic literal
<ijp>look at quasipatterns in match
<taylanub>Intuitively I'd expect the evaluating-case to be basically a cond that tests equality against the branches, instead of using them as booleans. The exact equality test used would be the only question.
<mark_weaver>taylanub: sure, you could do that. but then you might as well do (cond ((memv x '(blah blah)) ...))
<mark_weaver>taylanub: the truth is, 'case' is just one simple possibility among a huge set of possible convenient syntactic forms.
<taylanub>True ..
<mark_weaver>it's easy enough to build whatever you want using macros.
<mark_weaver>but yeah, 'case' can be optimized by a clever compiler, so I think that provides some justification for it being the thing that's codified in the standards.
<mark_weaver>(speaking of which, we ought to implement a fast 'case' at some point :)
<ijp>as I say, larceny does it
<mark_weaver>right. clinger wrote a paper on it too.
<mark_weaver>actually, I guess there's no reason why the optimization can't be done using a procedural macro. so that weakens my "why case is codified in the standard" argument :)
<mark_weaver>OTOH, R5RS doesn't have procedural macros.
<civodul>mark_weaver: re heuristics, i can understand that, but OTOH, as a user, i wonder: "what does this really do?", "how can i do the same myself?"
<civodul>so, it's OK to say "this is equivalent to (the-heuristic port)"
<civodul>because i know i can call 'the-heuristic' myself
<civodul>but saying "it does something" is a bit annoying, IMO
<mark_weaver>civodul: ah, right. that makes sense.
<civodul>that said, no big deal
<mark_weaver>civodul: maybe the 'file-encoding' docs should be changed to make it clear that we might use improved heuristics in the future?
<civodul>yes, definitely
<mark_weaver>okay, I'll work on it. thanks :)
<civodul>that would solve the above issue nicely
<mark_weaver>I pushed the first two patches, incorporated your suggestions.
<mark_weaver>will push unget-bytevector soon.
<mark_weaver>civodul: btw, did you notice the build failure on hydra for 'gnu:guile-2-0:build on x86_64-linux' failed again? "FAIL: filesys.test: sendfile: pipe". that seems to be happening sporadically.
<civodul>yeah, that's my impression :-/
<civodul>dunno what could happen
<civodul>if somebody can reproduce it, i'm happy to help debug
<civodul>but now i'm clueless
*mark_weaver looks
<mark_weaver>civodul: I'm clueless too. Maybe have it print the two bytevectors if they don't match, in the hope that it will give us a clue?
<mark_weaver>or just use 'pass-if-equal'
*civodul runs it in a loop
<mark_weaver>good idea :)
<cky>mark_weaver: Hey. I was thinking about your comments about your worry that promise-visit would slow down force. I'm not sure about that: force already uses let, and everybody knows that let is just a lambda was stuff passed in. Well, at least that's my line of thought.
<cky>mark_weaver: I mean, yes, I should do some before-and-after timing tests to verify.
<cky>In fact I might do so now.
<mark_weaver>cky: the slowness comes not from the use of lambda, but from a call via a mutable top-level variable.
<mark_weaver>the optimizer can inline calls to immutable bindings to procedures.
<cky>I see. How can we make it immutable?
<mark_weaver>there's currently no way to make immutable top-level bindings.
<cky>:'(
<mark_weaver>anyway, it would be good to keep the code the same as the SRFI-45 implementation.
<cky>Sure.
<mark_weaver>remember, the copy+paste is just a temporary measure to work around a psyntax bug that prevents 'make-promise-type'
<cky>I am thinking of this print syntax for SRFI 45: #<promise => #<procedure ...>> (for lazy) and #<promise = value> (for eager). Maybe the = is optional, too. The => is to connote going to a lambda, much like the cond and case syntax for same.
<cky>*nods* re temporary.
<cky>That way we can distinguish between a lazy vs an eager that contains a procedure.
<cky>Comments welcome. :-)
<mark_weaver>cky: looks sane to me :)
<cky>Do you like the version with or without the = for eager?
<cky>I'll still solicit feedback from the list, of course, but at least I can get an initial implementation going. :-)
<mark_weaver>actually, I have a counter-proposal :)
<cky>Excellent!
<mark_weaver>we should think about promises that hold multiple values, even if SRFI-45 doesn't yet support yet.
<mark_weaver>*support that.
<mark_weaver>how about print the computed values as a list? then the ambiguity goes away.
<mark_weaver>I dunno, I'm always fuzzy on these types of issues. I'm not a UI person.
<cky>I'm down with that. :-)
<mark_weaver>cool :) I'd be fine with either approach, fwiw.
<cky>Well, I'll make an implementation with what you've described, and we can see what the list thinks.
<mark_weaver>actually, now that I think about it, I think I like your way better.
<mark_weaver>if the computed value is a list, it might be a bit confusing.
<cky>I see.
<mark_weaver>I think I like it better with the '='.
<cky>Cool, that's how I'll implement it then. :-)
<mark_weaver>thanks!
<cky>:-D
<mark_weaver>actually, keeping the '=' also has the nice benefit of disambiguating with core promises (which really should be deprecated when we have (ice-9 promises) or (srfi srfi-??) anyway :)
<cky>Yes, that, too. :-)
<janneke>I'm off for a bit...thanks all! -- https://plus.google.com/116907903457895631414/posts/cESToQutLWr
*stis ahh, finished with the basic documentation of kanren in guile-log.
<stis>kanren on guile-log is about 10x faster then minikanren on pure scheme.
<stis>guile-log is about 2x faster then the same algorithm on the kanren on guile-log
<stis>it is possible to spped this up about 10x more with faster call out to c-code.
<stis>assq and functional trees costs about 7x with comparable algorithm on a stack
<civodul>mark_weaver: it's just that sendfile(2) can send less than asked, like write(2)
<civodul>i suspected that, but didn't know whether it could actually happen
<mark_weaver>civodul: ah, interesting!
<mark_weaver>civodul: nice work hunting that bug :)
<mark_weaver>will you fix Guile's 'sendfile' to call sendfile(2) in a loop?
<civodul>mark_weaver: i don't think so
<civodul>well, dunno
<civodul>WDYT?
<mark_weaver>well, maybe it depends on why it sent less than asked. if the reason is something like EINTR or similar, then I tend to think we ought to handle that automatically.
<civodul>in general we try to keep as thin a layer above POSIX
<civodul>it's not EINTR, it's just that it returns less
<mark_weaver>do you have any idea why it returns less?
<civodul>because it's a pipe, and the other end may not be reading "fast enough"
<civodul>the problem never occurs with files
<mark_weaver>so it's like non-blocking behavior?
<civodul>well, sort-of, but not quite :-)
<mark_weaver>well, I guess not quite. hmm.
<civodul>the man page doesn't say anything about that, of course
<mark_weaver>my question is: what's the benefit of not handling this automatically?
<civodul>good question
<mark_weaver>sometimes, there is a clear benefit. but in this case I don't see it (yet)
<civodul>the "benefit" is that the application is in control
<civodul>just like in C
<mark_weaver>that's not an answer.
<civodul>:-)
<mark_weaver>I can sympathize with that kind of logic, but I have to understand what it allows me to control.
<civodul>in this case, it allows you to notice that the other end is slow
<civodul>i do agree that in most cases, you'll just want to retry
<mark_weaver>the thing is, I don't want programs written in guile to be sporadically buggy.
<civodul>yeah
<mark_weaver>my instinct here is that the default behavior/binding should retry automatically.
<civodul>hmyeah
<mark_weaver>maybe we should provide a keyword option or lower-level binding that doesn't retry, dunno.
<civodul>that's what we do when sendfile(2) is missing, BTW
<mark_weaver>*nod*
<civodul>but then, the return value should be *unspecified* ?
<mark_weaver>civodul: what is Guile's sendfile supposed to return? The manual doesn't say.
<mark_weaver>right now, I see no way to tell whether sendfile sent less than asked.
<mark_weaver>(from the docs; I haven't looked at the code recently)
<civodul> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630029
<civodul>damn, the manual doesn't say
<civodul>who wrote that? :-)
<civodul>well, it carefully returns the number of bytes sent
<civodul>like the underlying function
<mark_weaver>civodul: thanks for finding that!
<civodul>so the bug report mentions an "indication of slow progress", as i suspected
<mark_weaver>civodul: the Guile docs should mention that.
<civodul>yeah
<civodul>you mean the return value?
<civodul>(ofc)
<mark_weaver>civodul: yes
<civodul>so what about this: document the ret. val., and leave the behavior as is
<civodul>(and change the tests accordingly)
<mark_weaver>civodul: also, I really think Guile's 'sendfile' should be robust by default, and not rely on the user to provide a loop.
<civodul>well, what's robust?
<civodul>if the user's app hangs, is it more robust?
<mark_weaver>civodul: writes can hang, in general.
<civodul>i sympathize, but i'm not sure i know enough to make that decision
<civodul>brb
<mark_weaver>civodul: well, okay. I guess we can think of 'sendfile' as being analogous to 'get-bytevector-some' but in the other direction.
<mark_weaver>let's just make that *very* clear in the docs.
<mark_weaver>i.e. change the opening sentence of the description from "Send COUNT bytes ..." to "Send up to COUNT bytes (possibly less) ..."
<mark_weaver>or something to that effect. it's not a footnote, but rather a core part of the semantics.
<mark_weaver>does that make sense?
<mark_weaver>or maybe rename it to 'sendfile-some' :)
<civodul>heh
<civodul>yeah you're probably right
<civodul>i'll commit that a bit later
<mark_weaver>I'm actually kind of serious about that. maybe the current 'sendfile' should be renamed 'sendfile-some', and 'sendfile' should be a wrapper that calls 'sendfile-some' in a loop.
<mark_weaver>well, either way, as long as users can't possibly misunderstand the semantics.
<mark_weaver>thanks :)
<mark_weaver>maybe provide example code that does the loop.
<cky>mark_weaver: I do like the "some" vs "all" idea.
<cky>In the same way POSIX provides both blocking and non-blocking APIs: it's not one-size-fits-all.
<mark_weaver>*nod*
<ijp>I'd have liked sendfile much nicer if it were called copy-port :)
<mark_weaver>heh.
<cky>ijp: If copy-port does what I think it does, I'd use it for Mike121's "cat" challenge.
<cky>It'd simplify the program lots.
<cky>With the caveat it'd become >=2.0.8 only.
<cky>Then again, get-bytevector-* is busted before 2.0.8 anyway.
<cky>(and I mentioned so in my notes with the "cat" submission)
<mark_weaver>cky: regarding EOF handling on terminals, you mean?
<mark_weaver>speaking of which, I think I need to add some calls to 'scm_i_set_pending_eof' to read.c.
*mark_weaver looks
<mark_weaver>civodul: I just sent an updated keyword-args-for-file-openers patch, plus an other patch for the 'file-encoding' docs.
<mark_weaver>s/an other/another/
<cky>mark_weaver: No, prior to 2.0.8, get-bytevector-* used char-based APIs behind the scenes.
<mark_weaver>well, I'll leave read.c alone for now.
<mark_weaver>cky: ah, right.
<cky>mark_weaver: I pointed that out to civodul, who fixed it.
<mark_weaver>cky: any progress on the SRFI-41 and SRFI-45 printing patches? (which should probably be two separate commits, btw)
<mark_weaver>time is running out for 2.0.8
<mark_weaver>regarding 'promise-visit', I think we should just live with the redundancy between that and stream-force.
<mark_weaver>my justification is that the speed of 'stream-force' is paramount, and thus it's acceptable to micro-optimize it a bit. just like I did with 'stream-car' and 'stream-cdr'.
<cky>Okay.
<cky>I'll split them up then.
<cky>They're ready, BTW.
<cky>(except the splitting up part.)
<mark_weaver>can you split them and show me?
<cky>Sure, I'll post to list. :-)
<mark_weaver>sounds good!
<mark_weaver>okay, I'm going to work on NEWS (ugh)
<mark_weaver>(there are times I think that we should update NEWS with each commit, rather than having to look through all the commits for news items just before release)
<mark_weaver>(we could always tighten it up before release, but at least then it would all be there)
<cky>Agree.
<cky>Maybe we should make that our new SOP.
<mark_weaver>+1
<mark_weaver>but then I guess I'm sort of +1'ing myself there, ha
<cky>Hehehehe. :-)
<cky>Okay, message is sent.
<cky>I didn't tag the message with [PATCHES], sorry.
<cky>But it does contain the patches in git format-patch format.
<cky>Should I resent with [PATCHES]?
<cky>*resend
<cky>("T" and "D" on Dvorak are a little close together; that typo is easy to make.)
<mark_weaver>cky: nah, it's fine, thanks!
<cky>:-D
<cky>(BTW: I purposely use a content-type of message/rfc822 so that Gmail will show the diffs inline; apparently "Content-Disposition: inline" isn't enough to make Gmail do that. :-)
<cky>Also the fact that format-patch generates email-like files justifies that choice even further.)
<cky>I mention this in case Gnus throws a cow about message/rfc822 attachments.
<mark_weaver>your mail looked nice in Gnus.
<cky>Awesome. :-)
<mark_weaver>I think you should go ahead and push.
<mark_weaver>thanks for the persevering :)
<cky>You sure I shouldn't see what civodul had to say first? He had comments in the last thread.
<mark_weaver>cky: yeah, you're probably right.
<cky>Also, if we're really running out of time, the patches are already posted and whoever's releasing can just apply them. :-)
<cky>But I remember you saying that NEWS updates have to happen first.
<cky>Good luck with that. :-)
<mark_weaver>thanks :)
<mark_weaver>cky: regarding get-bytevector-* being busted before 2.0.8, how did the problem manifest itself exactly?
<mark_weaver>I guess you had to have the encoding set to ISO-8859-1 or else they didn't work properly?
<mark_weaver>or was it worse than that?
<civodul>so, what's left?
<mark_weaver>I posted an updated keyword-args-for-file-openers patch, plus a new patch to clarify the docs of 'file-encoding'.
<mark_weaver>also cky posted new patches for record-type-printers that I think is ready to push.
<mark_weaver>I'm working on NEWS now.
<mark_weaver>s/is/are/
<cky>mark_weaver: Does iso-8859-1 encoding let you use characters betwees [00,1F] and [80,9F]? I haven't tried.
<mark_weaver>yes, it can handle everything from 00 to FF
<cky>mark_weaver: But yes, that pretty much sums up the issue.
<mark_weaver>okay, thanks!
<mark_weaver>(writing NEWS)
<dsmith>mark_weaver, IF you were writing a app that multiplexes a number of sockets (so just one thread), it mike make sense to NOT have sendfile finish completely.
<cky>:-)
<mark_weaver>dsmith: *nod* though given that we always write out everything on kernels without a sendfile syscall, we're already screwed
<mark_weaver>(at least to the extent one cares about portability)
<mark_weaver>but it's a good point.
<dsmith>mark_weaver, That's what I'm doing on the day job. Except I'm using splice() instead of sendfile().
<mark_weaver>dsmith: okay, in that case you may be the expert we've been looking for on this subject :)
<dsmith>mark_weaver, btw, I just upgraded sneeks box to wheezy between yesterday afternoon and this morning.
<mark_weaver>dsmith: okay. I'm super busy right now, so anything not relevant to 2.0.8 will have to wait :)
<dsmith>heh
<dsmith>np. Just getting ready for the 2.0.8
<mark_weaver>dsmith: but regarding 'sendfile': do you think we should change the code path that doesn't use the sendfile libc call to do something different?
<dsmith>Hmm. You know, I think it depends on how it will be used.
<mark_weaver>dsmith: well, more to the point: what semantics do we want for sendfile? I guess we want to clearly disavow any guarantee that it will copy the number of bytes requested.
<mark_weaver>so clearly document that it might copy less than requested, for any reason whatsoever (or no reason). does that sound about right?
<dsmith>Yes
<mark_weaver>okay, fair enough :)
<mark_weaver>civodul: ^
<mark_weaver>civodul: if we can make that crystal clear in the docs, and maybe provide an example of how to use it properly, then I think we'll have all the bases covered.
<dsmith>IF you allow it to return short, the user can loop. You can't do that if you force the full count.
<dsmith>Guile has writes that are "full" and also some lower level that return "short".
<dsmith>Would it make sense to provide two interfaces? A high level and low level?
<mark_weaver>I think that would be ideal. Whether it'll get done for 2.0.8 is another question :)
<dsmith>I dunno.
<dsmith>Then documenting it can return short would be best I think.
<cky>In that case, probably the non-native sendfile implementation should also return short.
<mark_weaver>what I don't know is whether 'sendfile' can really be used in the way you suggest: to handle multiple requests from a single thread. is it guaranteed (or semi-guaranteed) not to block for very long?
<cky>mark_weaver: I would presume that depends on whether the open file is O_NONBLOCK, surely?
<mark_weaver>if the answer is yes, then this is the use case I was looking for.
*cky should probably UTSL just to verify.
<mark_weaver>if the answer is no, then maybe this returning-short behavior is just useless.
<cky>*nods*
<mark_weaver>cky: well, sendfile seems to return short even with O_NONBLOCK is not set.
<mark_weaver>the question is, it is a reliable non-blocking behavior, is it is just a useless half-baked mode where you can't count on it not blocking, but you also can't count on it finishing the job?
<mark_weaver>s/it is/is it/
<dsmith>I would imaging that when non-blocking, it would write at much as it can without blocking.
<mark_weaver>one would hope.
<mark_weaver>but I'd also expect that when the port is in blocking mode, that it would write what I asked it to write.
<mark_weaver>but that's apparently not the case.
<dsmith>write() is not guaranteed to write all bytes when blocking.
<mark_weaver>dsmith: even if not interrupted by a signal or error?
*dsmith checks before he responds
<mark_weaver>dsmith: you may be right, based on my reading of the man page.
<mark_weaver>though I don't know of other cases that can result in short writes in practice.
<mark_weaver>hi wingo!
<mark_weaver>wingo: I'm working on NEWS.
<wingo>greets :)
<wingo>cool!
<dsmith>mark_weaver, slice() will write at most 64K, which is the size of a pipe buffer. It's actually 16 pages, the usual page size being 4K.
<cordawyn>Hello all! What is a "blessed" library for interfacing SQL databases for Guile? guile-dbi?
<ijp>there is no blessed one
<cordawyn>ok, I see. I just don't like adding to the overall entropy, if possible ;)
<cordawyn>I'll do with guile-dbi then
<dsmith>ijp, phhhthh
<cordawyn>ijp: dsmith: it a set of tools for working with "semantic web", linked data, RDF, SPARQL and such
<cordawyn>let me look-up the project URL...
<cky>civodul: Also, let me know if you have any comments for the promise record type printers (since you had some comments in the other thread about them). :-)
<cordawyn> http://mumble.net/~campbell/darcs/schemantic-web/
<ijp>ah riastradh
<ijp>parscheme, which is a dependency is packaged and on guildhall
<ijp>guile also has a URI abstraction, and a http client
<cordawyn>yep, I think of reusing as much of guile libs as possible, don't want to port just everything from there
<ijp>other than that, if it's useful to you, port it
<ijp>can't say it interests me much though
<cordawyn>speaking of parscheme, I thought guile had a parser lib, forgot its name
<ijp>(ice-9 peg) will be in the next release, there is also (system base lalr)
<cordawyn>right, lalr
<mark_weaver>ijp: regarding peg, by next release, you mean 2.2? It's not in my stable-2.0 tree.
<ijp>perhaps I have misremembered
<mark_weaver>I wonder what's holding that up. it would be good to have peg.
<ijp>well, it has been merged into master
<ijp>I had some reservations about the documentation, but I'd need to reinstall it to remember what those were
<mark_weaver>hmm. I wonder if there's any reason not to copy it to stable-2.0 as well.
<civodul>cky, mark_weaver: the promise printer patch looks good to me
<mark_weaver>civodul: thanks!
<mark_weaver>I'm making good progress on NEWS.
<mark_weaver>civodul: did you look at the stream printer patch also?
<civodul>mark_weaver: yes ↑
<mark_weaver>cky: please push those patches! :)
<mark_weaver>civodul: have you had a chance to look over my latest file-opener-keywords patch?
<cky>Okay!
<cky>mark_weaver: It's done. :-)
<mark_weaver>cky: thanks!
<cky>civodul: Thanks for the review!
<cky>mark_weaver: :-D
<cky>mark_weaver: Thanks for your review too!
<cky>And all your hard work with the I/O stuff, NEWS, etc.
<mark_weaver>np :)
<civodul>mark_weaver: i just replied, no?
<mark_weaver>civodul: great, thanks! :)
<dsmith>Potential as a new Guile language? http://undeadly.org/cgi?action=article&sid=20130401070038
<ijp>I started writing a guile-lolcode, but I stopped when I concluded lci was not fit for purpose
<ijp>which, as the interpreter I was recommended by others, did not give me much hope for any of the rest
<mark_weaver>civodul: any more thoughts on: Outdated section of manual 6.19.10 (Included Guile Modules)
<dsmith>(that was a jk btw)
<mark_weaver>wingo, ijp, and I think that removal would be a positive step, fwiw.
<civodul>mark_weaver: no more thoughts :-)
<mark_weaver>civodul: how would you feel about it being removed?
<cordawyn>ijp: guile-syntax-parse (http://gitorious.org/guile-syntax-parse/guile-syntax-parse/trees/master) looks very close to parscheme, could it be a better fit?
<civodul>Texinfo 5 is a pain
<civodul>mark_weaver: fine, you can go ahead
<mark_weaver>civodul: thanks :)
<ijp>cordawyn: firstly, since schematic-web was written assuming parscheme, it would be much less work to use parscheme than any other parsing library
<ijp>secondly, syntax-parse does not parse strings
<ijp>it is an extension to the macro facility
<cordawyn>ijp: oh, is parscheme ported already? could you point me to the project?
<civodul>ijp: parscheme looks great
<ijp>cordawyn: I've put in in the guildhall, with some changes to make it run a little easier in guile
<ijp>but the r6rs port is at https://gitorious.org/wak/wak-parscheme
<ijp>guildhall is the easiest way, otherwise you'll need to manually work out the transitive closure of dependencies
<cordawyn>erm, guildhall? I'm not that knowledgeable with guile yet, sorry ;-) What is it?
<ijp>package manager
<cordawyn> https://github.com/ijp/guildhall ?
<ijp> https://github.com/ijp/guildhall/wiki/Getting-Started
<mark_weaver>cordawyn: think 'apt-get' for guile modules :)
<cordawyn>great, thank you!
<cordawyn>mark_weaver: ok ;)
<civodul>mark_weaver: sendfile patch in your mailbox :-)
<mark_weaver>civodul: thanks, will look!
<civodul>mark_weaver: it's 10PM here, and i'm traveling tomorrow
<civodul>so i'm starting to think that the upload will be for later
<mark_weaver>civodul: okay, fair enough. the NEWS is taking longer than I'd hoped.
<mark_weaver>I could probably be done with it in an hour or so, but it's probably better to wait a couple of days anyway.
<mark_weaver>civodul: thanks for bearing with me and all my last minute pushes :)
<civodul>heh :-)
<civodul>let's aim for Tuesday evening, then (local time)
<mark_weaver>sounds good!
<civodul>provided my hotel has good Internet connectivity, that is
<mark_weaver>if it gets pushed back a few more days, it's no big deal IMO.
<mark_weaver>it's actually probably good for all this work to get a few days of wider testing before going out the door anyway :)
<civodul>yes, agreed
<civodul>but we must make sure not to push anything else now :-)
<mark_weaver>haha, I'll try to restrain myself :)
<civodul>:-)
<taylanub>What's the reason the regexp-match functions are named match:foo and not match-foo ?
<civodul>historical, i suppose
<ijp>taylanub: guile-sdl uses that convention too
<ijp>as did scsh's define-record macro
<dsmith>namespace management before modules, probably
<taylanub>I guess One Day (TM) we should clear that up.
<mark_weaver>the regexp API needs an overhaul, imo.
<mark_weaver>for now, I would recommend Alex Shinn's irregex package.
<dsmith>Ok! ./autogen.sh on sneeks box takes 44m27
<mark_weaver>dsmith: 44 minutes? yikes!
<dsmith>mark_weaver, Yes
<mark_weaver>civodul: regarding 'sendfile', what would happen if it was called with a file descriptor using O_NONBLOCK?
<mark_weaver>maybe that's not a mode worth supporting, but I'm curious.
<civodul>mark_weaver: yeah, not worth supporting :-)
<civodul>O_NONBLOCK is not easily usable from Scheme, i think
<mark_weaver>okay
<mark_weaver>Your sendfile patch looks good to me. We can always add a lower-level interface later, if it's deemed necessary, but I definitely think this is the right behavior for the primary one.
<civodul>WDYT?
<mark_weaver>I guess the only thing that I'm a little hesitant about is not returning the length.
<mark_weaver>I haven't looked carefully though. I can certainly see the logic of not returning it.
<civodul>well, it would always be equal to COUNT
<mark_weaver>I guess exceptions are the right way to deal with that though. and we could put the partial length in the exception.
<civodul>that's why i changed it to *unspecified*
<mark_weaver>*nod*
<civodul>yeah
<mark_weaver>I think you're right.
<civodul>let's hope so ;-)
<mark_weaver>if we don't want users to have to write a loop, then we might as well not return the length.
<civodul>exactly
<civodul>in a way, put-bytevector & co. do the same wrt. write(2)
<mark_weaver>dsmith was saying that there might be some value to a lower-level interface, but I definitely think that should have a different name, and that the main 'sendfile' API should do this.
<mark_weaver>*should do what your latest patch does.
<mark_weaver>*nod* (regarding put-bytevector & co)
<mark_weaver>so, in summary, I'd say push :)
<civodul>ok :-)
<dsmith>mark_weaver, Yes, I think the high-level interface is going to be more useful to more people. Add a primitive-sendfile() later if needed.
<mark_weaver>dsmith: sounds good, thanks :)
<civodul>dsmith: when do you think the other semantics would be valuable? O_NONBLOCK?
<dsmith>civodul, If someone was writing a multiplexed, non-threaded server
<civodul>hmm, yeah
<mark_weaver>dsmith: can sendfile(2) be used to make a robust server that operates in that mode?
<civodul>yeah, that's unclear
<mark_weaver>dsmith: is it guaranteed not to block for more than a very short time?
<dsmith>I don't know.
<dsmith>I'll take a look on Monday.
<mark_weaver>if we wanted to support that mode of operation, we'd need to change the non-sendfile(2) code path in scm_sendfile.
<mark_weaver>so regardless, I think civodul's latest patch should be pushed.
<mark_weaver>and that the other mode of operation, if supported, should be a different procedure.
<mark_weaver>IMO anyway.
<civodul>damn it
<civodul>i've found a case where sendfile(2) endlessly returns 0
<mark_weaver>civodul: what's wrong?
<civodul>so infinite loop
<civodul>and errno is zero
<mark_weaver>ugh. when?
<civodul>the "pipe with offset" case
*civodul rereads the code
<stis>yey! I just fixed a n^2 complexity bug to n that caused pretty bad performance for zipping guile-log forms
<civodul>mark_weaver: i was doing non-sense with offset_ptr
<civodul>it was pointing past the end of the input file
<civodul>but that means that if the user does that, boom
<mark_weaver>civodul: ah, okay. so the problem is fixed?
<civodul>yes
<mark_weaver>that's good news!
<civodul>but again, users can run into it by passing an offset past the end of IN
<mark_weaver>sorry, I should have done a more careful review.
<mark_weaver>interesting. so something underneath us (maybe libc, maybe Linux) should be returning a more helpful error.
<civodul>well, it just lets the user handle it...
<civodul>Linux, that is
<mark_weaver>*nod*
<mark_weaver>hmm, I wonder if we can handle this more gracefully.
<civodul>nope, unless we do an lseek, etc.
<mark_weaver>maybe we should handle a 0 return code specially.
<civodul>how? :-)
<mark_weaver>maybe if 0 is returned, we should switch to the non-sendfile(2) code?
<civodul>that's always a problem when trying to be smarter than the OS
<civodul>hmm, yes
<civodul>hmm
<mark_weaver>basically, we should have a way of reliably detecting that we reached EOF, no?
<mark_weaver>if we can do that with sendfile, great. if not, then presumably it can be done with 'read', no?
<civodul>well, full_read would return 0, with errno == 0
<civodul>then SCM_SYSCALL ESUCCESS
<civodul>(which is better)
<mark_weaver>I guess my feeling is that if it's hard for us to get this loop right, then it'll also be hard for our users to get it right.
<mark_weaver>so if we can, we should just figure out the right approach and do it. or at least that's what my gut tells me :)
<mark_weaver>maybe we do need a return count after all, in case EOF is reached.
<civodul>yeah
<mark_weaver>one question: if sendfile returns 0 with (errno == 0), can we conclude that we reached EOF?
<mark_weaver>regardless, I suspect that we should exit the loop in that case.
<mark_weaver>maybe we should ask about this on a list with experts.. maybe glibc-alpha, or the linux kernel list, or something.
<taylanub>What exactly is the use of "Feature tracking" in Guile ? Do modules not fulfil that purpose ?
<ijp>taylanub: same reason as web developers do feature detection
*civodul feels like surrounded by worms that escaped the can
<ijp>you want to use $foo, but you might want to support versions that don't have $foo
<taylanub>Hrm, OK, is it for core-features only ? Things for which you would normally not need to use any module ?
<civodul>mark_weaver: http://stackoverflow.com/questions/3697002/with-sendfile-is-it-possible-to-tell-when-in-fd-is-at-eof
<civodul>and http://code.google.com/p/pysendfile/ : if sent == 0 EOF
<mark_weaver>civodul: ugh, what a mess.
<civodul>yep
<civodul>but that means that 0 = EOF
<civodul>basically
<mark_weaver>I think that's probably the best we can do.
<mark_weaver>but we should return the count anyway.
<civodul>yes, definitely
<dsmith>Aaaannnd: ./configure took real 48m29.504s
<ijp>lol
<ijp>dsmith: I appreciate this is a small box, but -C ?
<dsmith>Gotta look at cross-compiling
<mark_weaver>dsmith: if you build from git, and keep the build tree around, incremental builds usually aren't too bad.
<dsmith>fwiw: Though this is a little old, the graph is *very* interesting. "select" style web servers seem to perform very well. http://acme.com/software/thttpd/benchmarks.html
<mark_weaver>oh, definitely.
<civodul>mark_weaver: i'm pushing an updated version, with more tests, etc.
<civodul>comments welcome!
<mark_weaver>civodul: sounds good!
<mark_weaver>civodul: I just pushed an updated NEWS.
<civodul>great
<mark_weaver>it still needs more work, but it's coming along...
<civodul>good!
*civodul goes to bed
<civodul>night!
<mark_weaver>g'night!
<civodul> /day :-)
<mark_weaver>:)
<cky>Good job, you two. :-)