<nalaginrut>oops, seems I can find no way to write comments, or I may write some better suggestions for his code <wleslie>I don't think I know this person, but I think I should <davexunit>I'm happy this person likes Guile, but I disagree with many of their suggestions <wleslie>awesome background gif, lots of python, and some Guile <davexunit>they say 'use-modules' is ugly, but it seems they don't know how to use the #:select keyword <davexunit>well, I guess they do, because of the macro they wrote. <davexunit>as for #3, do they know that currying isn't really something that Scheme does? <wleslie>it's considered so very distasteful to open import in python that seeing it anywhere is offputting if you're a python native <davexunit>I've written a lot of Guile at this point, and it's rare that I need to use #:select <davexunit>don't know what to say there. let isn't changing. <wleslie>so I'm currently playing with a C++ project called mapnik. it's not bad, but 99% of the time I'm trying to answer the question "where is this thing defined?" <davexunit>oh, this was written by Amirouche Boubekki, I know that name. <wleslie>even with gtags and frequent grepping that seems not to be a sensible question to ask. <davexunit>and with Geiser in Emacs, you can press M-. to jump to the definition. <wleslie>having the process running is helpful, yes <wleslie>it's a bit spoiled to be able to answer the question of 'where did this name get bound' with either 'I defined it', 'It's built in', or 'it came from this import statement' <wleslie>by looking only at the current module. <doki-wor`>The linked script does not run, presumbly because -l factorial and -e main -s are on different lines ***doki-wor` is now known as doki-worry
<ArneBab>davexunit: regarding use-modules: I think #:prefix solves most of the issues. In python I stopped using “from X import Y”, because that still clutters up the namespace. I prefer using the plain “import X”, and then using “X.Y”. <ArneBab>that’s (use-modules ((srfi srfi-1) #:prefix srfi-1:)) <dje42>Hi. Does anyone know why fports.c:fport_write, when a write exactly fills the buffer, flushes it? [instead of deferring the write to later] <mark_weaver>what would be the advantage to postponing the write, given that there will not be an opportunity to combine it with a later write operation? <dje42>dunno. seems odd though. the buffer size is really N-1 then. <dje42>Plus, I'm writing tests to exercise gdb memory ports, and wanted to exercise this edge case. <mark_weaver>one issue is that unbuffered ports actually have a single-byte buffer, which I guess simplifies some things <mark_weaver>also, I'm not sure I would say "the buffer size is really N-1", because if that were the case, you couldn't write N bytes in one backend operation. <mark_weaver>and furthermore, if you write one character at a time, it will be flushed after N bytes, right? <dje42>Well, I'm applying "really" in a precise mathematical sense. <dje42>But if I write N bytes, those N bytes never really sit in the buffer. <dje42>s/I'm applying/I'm *not* applying/ <mark_weaver>to my mind, if there's no possible advantage to postponing a write, it shouldn't be postponed. <mark_weaver>the advantage to buffering is to combine multiple smaller write operations into a single backend operation. <mark_weaver>but once the buffer is full, there is no longer any advantage to postponing. <mark_weaver>dje42: btw, why does 'open-memory' raise an error when size==0 ? <dje42>Patch in progress to change this. [I already saw you're message. That's why I'm hacking in this area. :-)]