***adu_ is now known as adu
<duper`>#(1) what is this notation? kinda looks like an F# flexible type <duper`>i just don't remember it from R5RS *shrug* <duper`>I'm coming back to Scheme after a break. forgive me. heh. <duper`>so what's the diff between a vector and a list? <duper`>i know the diff between list and set <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^_>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^_>Then you don't have to listen to all my crap ;-) <DerGuteMoritz>algorithmic complexity for random access is constant with vectors ***Guest76703 is now known as micro__
<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>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". <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. <mark_weaver>but I didn't ask that question in my email, or at least I don't think I did. <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 :) <mark_weaver>Subject: [PATCHES] Keyword args for file openers; coding scan off by default *civodul looks at the patch <janneke>hmm, (case key-val ((gdk:plus)) does not do what i expect <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 is such a newbie <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 :) <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? <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) <ijp>janneke: case will work with integers, but since it uses eqv? you need to be careful about exactness <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 <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>it's roughly analogous to the situation with `switch' in C <mark_weaver>janneke: yeah, you can't do what you want with 'case'. <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> (define plus 43) (define minus 45) (match minus (('hello (who)) "foobar") (0 "found zero") (plus "plus") (43 "43") (minus "minus") (45 "45") (else #f)) <mark_weaver>janneke: I second wigs' suggestion. why are you using integers instead of characters for this? <ijp>match uses variables for binding, not insertion <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>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. <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>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 :) <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: maybe the 'file-encoding' docs should be changed to make it clear that we might use improved heuristics in the future? <civodul>that would solve the above issue nicely <mark_weaver>I pushed the first two patches, incorporated your suggestions. <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>if somebody can reproduce it, i'm happy to help debug <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? *civodul runs it in a loop <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. <mark_weaver>anyway, it would be good to keep the code the same as the SRFI-45 implementation. <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. :-) <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>we should think about promises that hold multiple values, even if SRFI-45 doesn't yet support yet. <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. :-) <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>Cool, that's how I'll implement it then. :-) <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 :) *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>will you fix Guile's 'sendfile' to call sendfile(2) in a loop? <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 <civodul>because it's a pipe, and the other end may not be reading "fast enough" <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? <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 <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. <mark_weaver>my instinct here is that the default behavior/binding should retry automatically. <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 <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>well, it carefully returns the number of bytes sent <civodul>so the bug report mentions an "indication of slow progress", as i suspected <civodul>so what about this: document the ret. val., and leave the behavior as is <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>if the user's app hangs, is it more robust? <civodul>i sympathize, but i'm not sure i know enough to make that decision <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>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>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. <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. <ijp>I'd have liked sendfile much nicer if it were called copy-port :) <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>speaking of which, I think I need to add some calls to 'scm_i_set_pending_eof' to read.c. <mark_weaver>civodul: I just sent an updated keyword-args-for-file-openers patch, plus an other patch for the 'file-encoding' docs. <cky>mark_weaver: No, prior to 2.0.8, get-bytevector-* used char-based APIs behind the scenes. <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>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>I'll split them up then. <cky>(except the splitting up part.) <cky>Sure, I'll post to list. :-) <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>Maybe we should make that our new SOP. <mark_weaver>but then I guess I'm sort of +1'ing myself there, ha <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>("T" and "D" on Dvorak are a little close together; that typo is easy to make.) <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. <cky>You sure I shouldn't see what civodul had to say first? He had comments in the last thread. <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>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>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. <cky>mark_weaver: Does iso-8859-1 encoding let you use characters betwees [00,1F] and [80,9F]? I haven't tried. <cky>mark_weaver: But yes, that pretty much sums up the issue. <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. <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) <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>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? <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>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. <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? <dsmith>I would imaging that when non-blocking, it would write at much as it can without blocking. <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. <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. <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>ijp: dsmith: it a set of tools for working with "semantic web", linked data, RDF, SPARQL and such <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). :-) <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) <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: did you look at the stream printer patch also? <mark_weaver>civodul: have you had a chance to look over my latest file-opener-keywords patch? <cky>mark_weaver: It's done. :-) <cky>civodul: Thanks for the review! <cky>mark_weaver: Thanks for your review too! <cky>And all your hard work with the I/O stuff, NEWS, etc. <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) <mark_weaver>wingo, ijp, and I think that removal would be a positive step, fwiw. <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? <ijp>cordawyn: I've put in in the guildhall, with some changes to make it run a little easier in guile <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? <civodul>mark_weaver: sendfile patch in your mailbox :-) <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>let's aim for Tuesday evening, then (local time) <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>but we must make sure not to push anything else now :-) <taylanub>What's the reason the regexp-match functions are named match:foo and not match-foo ? <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>for now, I would recommend Alex Shinn's irregex package. <dsmith>Ok! ./autogen.sh on sneeks box takes 44m27 <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>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. <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>if we don't want users to have to write a loop, then we might as well not return the length. <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. <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. <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 <mark_weaver>dsmith: can sendfile(2) be used to make a robust server that operates in that mode? <mark_weaver>dsmith: is it guaranteed not to block for more than a very short time? <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. <civodul>i've found a case where sendfile(2) endlessly returns 0 *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 <civodul>but again, users can run into it by passing an offset past the end of IN <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... <mark_weaver>hmm, I wonder if we can handle this more gracefully. <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 <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 <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. <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 ? <dsmith>Aaaannnd: ./configure took real 48m29.504s <ijp>dsmith: I appreciate this is a small box, but -C ? <mark_weaver>dsmith: if you build from git, and keep the build tree around, incremental builds usually aren't too bad. <civodul>mark_weaver: i'm pushing an updated version, with more tests, etc. <cky>Good job, you two. :-)