<cky>mark_weaver: For English, yes, dictionaries are descriptive (of the language spoken by native speakers). <cky>IIRC, for French, it's prescriptive, and what the dictionary says is "law". <cordawyn>Hello! Could anyone update me on the status of fastcgi for Guile? Looks like it's been long dead in the water? <cky>That wouldn't surprise me, but what do I know about Guile web stuff. :-) <ijp>a few of us just use guile's web server behind apache/other <ijp>maybe ttn has something for fastcgi, but I suspect it's probably just cgi <cordawyn>I can see "guile-fgci" package being tossed around in *BSD distros, but it's going away too, apparently <ijp>as far as I know, that was written like a decade ago <ijp>nope, just has cgi, and modlisp <ijp>cordawyn: help me out since I'm not a web guy, but why fastcgi over reverse proxying to guile? <ijp>and don't say because it has 'fast' in the name <mark_weaver>cky: this "descriptive/prescriptive" debate has a long history. france may have a law, but I suspect that linguists who know what they're talking about consider this laughable. I've also heard about some parliaments writing legislation that pi is 3. <cordawyn>ijp: what do you mean by "reverse proxying to guile"? <ijp>fast is on my list of "words programmers shouldn't be allowed to use" <mark_weaver>what exactly does the law say, anyway? what is the punishment for using words that aren't in the dictionary? <ijp>cordawyn: I mean, I run guile's web server, and have apache forward requests to it <cordawyn>ijp: I'm not a CGI fan at all, FastCGI included. I'd hate to use it actually. But I need a simple solution without a server constantly running... <mark_weaver>any of the advanced CGI-like protocols all involve servers running. that's the way you avoid having to launch a process for each request. <cordawyn>mark_weaver: Is there any web app architecture that provides for that? <mark_weaver>wingo played around with modlisp, but eventually came to the conclusion that HTTP was the way to go. <cordawyn>mark_weaver: I mean, one where you launch a script on request <cordawyn>mark_weaver: without a server constantly running <mark_weaver>seriously, if you're going to launch a program on every request, then CGI is the thing, I guess. <mark_weaver>it's easy to write CGI programs in just about any decent language. <cordawyn>DerGuteMoritz: FastCGI doesn't launch a script at every request, it creates sort of a queue, where subsequent requests are processed within a loop in already running script <ijp>mark_weaver: and even most indecent languages <cordawyn>CGI is basically a "server killer", literally. There's nothing like a good DDOSing of a CGI app. <cordawyn>I guess I'll have to go with an "app server" option then <cordawyn>mark_weaver: Looks like I underesimated "web server" package of Guile - it is lightweight enough for me. Thanks for the hint! <cky944>Oops, missed the whole last hour of convos due to netsplit. :-/ <ijp>the past hour? nothing happened :) <cky944>I would ghost my other nick, but NickServ isn't around to do the deed. :-( <ijp>what would you call the "@deffn {scheme procedure} foo bar baz" line? <cky944>Function synopsis? Uh, not sure. <ijp>me neither, maybe I'll go with "function prototype" for this email ***cky944 is now known as cky
<ijp>mark_weaver: since you hadn't posted a your review of nalaginrut's patch earlier, I've taken the liberty of doing one for you <ijp>the call/ec one that is <mark_weaver>ijp: thanks. though I'm a bit confused, because Ludovic's post suggested that he had already pushed a fixed commit, but I don't think he did. <ijp>maybe he did it locally, and forgot to push <ijp>ah no, it's on stable-2.0 <mark_weaver>oh, now I see it. hmm. I was using the savannah web interface, and I wasn't on the right URL. <mark_weaver>ijp: I'm the one who should feel foolish, not you :) <ijp>let's just blame civodul, for not mailing the list ;) <mark_weaver>but he did mail the list, and he gave the commit number. <ijp>hmm, I'm not seeing it <ijp>weird, I'm not seeing that in my gnus <ijp>I think the only issue not covered by civodul, that I addressed is that we have at least 2 other implementations of let/ec in Guile that should be removed. <mark_weaver>he removed the one from ice-9/futures.scm. what others? <ijp>one in peval, one in sxml/match <ijp>incidentally, the latter is broken <ijp>well, I had been planning on leaving it for nalaginrut, but since that's got to pot, sure <mark_weaver>ijp: finally got around to reading your review of the let/ec patch. you explained the issue quite well, thanks. <mark_weaver>ijp: I note that Ludovic kept the name 'let-escape-continuation', and I think that's probably reasonable. 'call-with-*' makes sense because you are passing the continuation to the procedure that's being called. 'let' is different. I'm not sure 'let-with' makes sense. we don't say 'let-with-values', for example. <ijp>tachikoma_: botsnack <ijp>just another rudybot instance <ijp>I'm running it to test some patches I have for rudybot <ijp>for a start, you see it now supports 'botsnack' <ijp>yes okay, in a minute <ijp>I also have a "verb" for easier sock puppeting, the current stategy is silly <ijp>tachikoma_: botsnack *nalaginrut is struggling against ,src <nalaginrut>well, I got that, use match to parse the (define ... is very easy hah~ <nalaginrut>maybe it's time to design a new plugin-able REPL, rather than patch it for new features each time, and make Guile leaner <mark_weaver>I discovered that the unget code in ports.c was quite dumb. <mark_weaver>it put the characters at the start of the buffer, instead of the end. so every time you unget another byte, it shifts the whole buffer up. <mark_weaver>I will soon post a patch to make large ungets very fast. <mark_weaver>(which I need to clean up the coding declaration scanning code) <cky>mark_weaver: Does that change the behaviour of doing multiple ungets? <cky>I mean, if you unget #\\a, then #\\b, then #\\c, will you then read #\\c, then #\\b, then #\\a? <cky>mark_weaver: Your pt->putback_buf_size = ... line is indented one space too far, from a quick inspection of the diff. :-) <cky>(I know it's crazy to comment on such things in a review, but if it sticks out, it's worth commenting on. :-)) <mark_weaver>cky: actually, no. it's just looks that way in the diff because my new lines indent with spaces, and the old code indents with tabs, and so the inserted char at the beginning of the line (for the diff) indents my lines one more than the old ones. <mark_weaver>well, actually the old code is indented with a mixture of tabs and spaces already. it's a mess. <cky>Yeah, the mix of spaces and tabs is what's crazy, then. :-) <mark_weaver>I'd really like to see the tabs go away for good :-/ <mark_weaver>unfortunately, the default value of indent-tabs-mode in emacs is still t. I have mine set to nil though. <mark_weaver>public service announcement: (setq indent-tabs-mode nil) in your .emacs, folks :) <mark_weaver>I just updated the patch to add 'unget-bytevector', and used it to unget 15 megabytes, which was very quick. try that with the old code :) <cky>mark_weaver: I know that pt->read_buf_size = pt->putback_buf_size, but the if (new_len > pt->read_buf_size) /* The putback buffer needs to be enlarged. */ still reads inconsistently to me. :-) <cky>mark_weaver: Very nice with unget performance. :-D <mark_weaver>but I don't know that I want to change read_buf_size to putback_buf_size there. <cky>Also, C really needs an inline function like std::max(), since your code uses it in a couple of places (albeit manually, using the "a > b ? a : b" or similar construction). <mark_weaver>cky: btw, would you be willing to push a small commit to change '(stream . null) [or whatever it was] to use cons? <cky>Yes, at least that's uncontentious. :-) <cky>I still want to get the object printers for streams in before 2.0.8, since the default printer makes for extremely fugly display of streams, but I'm happy to make it acceptable to all and sundry first. :-) <mark_weaver>damn, it's not clear where in the manual to describe 'unget-bytevector'. <cky>Surely, in the same place as, like, get-bytevector-some, right? <mark_weaver>the problem is, 'get-bytevector-some' is documented in the r6rs section, but 'unget-bytevector' is not part of r6rs. <mark_weaver>it's exported from (ice-9 binary-ports), which is not really described anywhere. <mark_weaver>there's just a single mention of it, at the bottom of the r6rs ports section that says "A subset of the `(rnrs io ports)' module is provided by the `(ice-9 binary-ports)' module. It contains binary input/output procedures and does not rely on R6RS support." <cky>I guess it's not a subset any more, then. ;-) <cky>Your patch looks good to me. Of course, I'm keen to see if others have comments to make also. <cky>BTW, part of the reason I don't participate on mailing lists much any more has to do with Gmail. I used to have a local mail server, with local mailboxes, so using mutt with them was easy. Now mutt has to load up a whole IMAP folder, and it's a pain. <cky>I don't want to post using Gmail's web interface, since I only trust mutt to set up the list mail header fields correctly. :-) <cky>.oO(I've had my Gmail address since 2004, so I guess that means I've not really been actively participating on mailing lists for that long. Wow.) <mark_weaver>cky: it's shame that you can't use email properly. I've definitely noticed that it's making it a bit awkward to collaborate. I don't really like using web sites to review your work. <mark_weaver>btw, mutt has an IMAP header caching feature, which has to be enabled manually (as I recall), that dramatically speeds up access to large imap mailboxes. <cky>Cool, I must try to get that set up. <mark_weaver>it's actually quite easy. just a couple of lines in your .muttrc and you're done. <cky>Back in the day, when I used mutt much more regularly, I had a very elaborate .muttrc. <cky>Now on this computer, it's just 4 lines long. <mark_weaver>I've switched to Gnus, but I used mutt for many years. <cky>*nods* I don't live in Emacs, so switching to Gnus would be hard for me. :-) <cky>The only time I fire up Emacs is to use Paredit to edit Scheme files. ;-) <cky>Otherwise, I'm a vi user. <mark_weaver>mutt is a great mail program. I still use it occasionally when nothing else does the job properly. <cky>Cool, it looks like it's written the header cache file. That's a good sign. <mark_weaver>I also used vi (well, vim) as my primary editor for many years, and I still use it periodically for quick editing tasks, especially when I'm root. <cky>I should quit out of mutt and see how fast a reload is. :-) <cky>Not bad, not bad. :-) <cky>Many thanks for your pointer. :-) <mark_weaver>if it causes you to participate more on the mailing lists, then it will make me glad :) <mark_weaver>wingo: yesterday, civodul gave his consent to removal of the auto-coding scan when opening files. are you okay with that? <mark_weaver>(I've had a patch for that since January, and have updated it to current stable-2.0; just working on keyword arguments for the various file-opening procedures now) <mark_weaver>It would make me very happy if this change could be in 2.0.8. After that, I'll stop and move to working on the NEWS, honest :) <mark_weaver>I'm just finishing up a patch to add 'scm_c_bind_kwargs', for easy keyword handling from C. <mark_weaver>(a prerequisite for adding a keyword argument to 'open-file' :) <mark_weaver>as usual, writing the tests and the docs take several times as long as writing the code, heh. <wingo>had a nice day out in the garden <wingo>not much yet! it's still too cold to plant directly here it seems <wingo>mostly preparing the ground currently <wingo>but we'll plant sweet peas tomorrow and start some herbs, and figure out what needs to be sprouted separately <mark_weaver>cherry tomatoes are highly recommended, though I don't know whether they'll grow in your climate. if you get a good variety, they will produce a voluminous amount of tomatoes that are sweeter than anything you'll find elsewhere. <mark_weaver>(in my experience, larger tomatoes have the problem that critters like to eat one bite from each tomato, leaving you with none) <dsmith>mark_weaver, What was the incantation you used to get automake from experimental? <mark_weaver>not ideal, since it doesn't check the sig. the better way is to add experimental to the /etc/apt/sources.list and then use apt-get install -t experimental automake, or something like thta. <dsmith>Yes, that was the route I was taking. Not very successfully, however. <DerGuteMoritz>ah, just found the snapshots! I shall try to build the PKGBUILD with the latest of these <dsmith>mark_weaver, Thanks. It's been a while since I could build from git. Now I can. <dsmith>I must not have my sources.list configured properly. <mark_weaver>I've never added experimental to sources.list, so I don't know if something special needs to be done. <mark_weaver>I'm almost reluctant to ask, but you did "apt-get update", right? :) <wingo>mark_weaver: yes we do have some small tomatoes purchased, and some larger ones too <wingo>we made an absurd order to a french organic seed shop <wingo>now the dilemma is "nice big garden" vs "it's a lot of work to tear up the lawn" ;-) <mark_weaver>well, you can always do it incrementally, i.e. make it a bit larger each year. *DerGuteMoritz waves at wingo <wingo>would be nice if i had more vision into what the future holds, heh <DerGuteMoritz>wingo: let me know when you figure that future vision thing out *mark_weaver just posted his 'scm_c_bind_kwargs' patch. <wingo>DerGuteMoritz: that is a strange warning! <dsmith>mark_weaver, I was attempting the apt-get install package/experimental syntax. <wingo>DerGuteMoritz: i think that's probably enough... <wingo>actually is that git or a release? *DerGuteMoritz really wants to try out geiser <mark_weaver>DerGuteMoritz: only the early ones. the problem is that the compiler has not yet been compiled, so it's being interpreted. <mark_weaver>I think we need a list of dates to update every year. I tried to get them all, but missed that one. <wingo>mark_weaver: was it the va_start <mark_weaver>wingo: yeah, that's why I wrote "<mark_weaver> gah, found an embarrassing mistake. fixed :)" <mark_weaver>wingo: thanks for the review. I'm bad at coming up with names, and tend not to care what they are (within reason :) <mark_weaver>yeah, I struggle with names more than almost anything else in my hacking. <wingo>when i do things in webkit or v8 usually most of the reviews i get are about names <mark_weaver>wingo: regarding the name for ALLOW_REST.. How about ALLOW_NON_KEYWORD_ARGS? I want to avoid ALLOW_NON_KEYWORDS because if the last element of the list is a keyword, that's considered a non-keyword-argument for purposes of this code (and your code seems to do the same, based on experimentation). <mark_weaver>wingo: also, should the prefix be something other than SCM_KWARGS_? what prefix would you use? <mark_weaver>so just SCM_ALLOW_OTHER_KEYS and SCM_ALLOW_NON_KEYWORD_ARGS? <wingo>i would avoid mixing the words "args" and "arguments" <wingo>arguments is probably better... <mark_weaver>regarding advancing tail... tail is never used after that. 'rest' is advanced outside of that 'if'. <mark_weaver>also, 'rest' is advanced within this function, but is not returned. it's just the way I iterate over the list. <mark_weaver>if that's confusing, I guess I could make a new local variable for iteration purposes. <wingo>dunno. would you mind sending an updated patch? <wingo>i don't understand how we deprecated generalized vectors, yet there are new patches going in that use generalized vector interfaces <wingo>i guess it was using generalized vectors through some macros... <wingo>i have spent a lot of time in that code, and it's still a mess straight out of 1993 <mark_weaver>haha. yeah, there are a lot of messes left to clean up. <mark_weaver>wingo: hmm, if I don't have a prefix, then I can't do SCM_NO_FLAGS = 0. I guess I'll just remove that one from your suggested enum. <mark_weaver>wingo: btw, you and civodul give conflicting advice about enums. civodul always wants the typedef separate from the enum decl. <wingo>he has the gnu coding standards burned into his synapses <wingo>i think we're all just trying to do what civodul would do ;) <wingo>so please ignore me if your inner ludo disagrees :) <wingo>ok, zzz. don't hesitate to post an updated patch if you have questions; otherwise push as you like *stis is right now documenting the kanren interface, any-union is pretty cool!