hi Luis, i know i'm running ahead of things, but you can find a few patches available at: darcs pull http://common-lisp.net/project/cl-dwim/darcs/babel/ hint: you may consider adding Stelian and me to the babel group, so that the open source fairies could set up an official babel repo... ;) or even a minimalistic site if you don't find that offending. -- attila
[Cc-ing Stelian in case he's not subscribed to babel-devel.] On 23/02/2008, Attila Lendvai <attila.lendvai@gmail.com> wrote:
i know i'm running ahead of things, but you can find a few patches available at:
No, you're just walking by the main developer who is standing still. :-)
darcs pull http://common-lisp.net/project/cl-dwim/darcs/babel/
I have a few questions: Sat Feb 23 22:01:55 WET 2008 attila.lendvai@gmail.com * fix: lookup-mapping of already looked up concrete-encoding instances I'm curious about your use case for (lookup-mapping ht <some-mapping-instead-of-an-encoding>). I would we want that to work? Sat Feb 23 22:06:59 WET 2008 attila.lendvai@gmail.com * Added declaims to make it possible to locally inline string-to-octets and friends upon explicit request Somewhere in your code (cl-rdbms maybe?) I saw you used the mappings directly. Is this related to that? What's the gain? (In either case: funcalling the mappings directly or inlining string-to-octets.) Sat Feb 23 22:48:45 WET 2008 attila.lendvai@gmail.com * Added an exported lookup-string-vector-mapping for special uses of the encoders directly This one is related to the previous question, I suppose. I'm curious about why you want to call the encoders directly. ISTR having some ideas about more features for string-to-octets and friends, so I might imagine some uses for calling the encoders directly if I could remember what those ideas were.
hint: you may consider adding Stelian and me to the babel group, so that the open source fairies could set up an official babel repo... ;) or even a minimalistic site if you don't find that offending.
I've sent a request to add you both to the group. Also, I moved my babel tree into the project's public_html. I usually screw the permitions up, so let me know if anything's wrong. I set up a minimalistic site. Feel free to improve it. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
Sat Feb 23 22:01:55 WET 2008 attila.lendvai@gmail.com * fix: lookup-mapping of already looked up concrete-encoding instances
I'm curious about your use case for (lookup-mapping ht <some-mapping-instead-of-an-encoding>). I would we want that to work?
baah, i fooled myself with an old change of mine. and in the light of the compiler macro i think this is BS and should be rolled back. i've unpulled stuff from my repo and amended the patches according to this mail.
Sat Feb 23 22:06:59 WET 2008 attila.lendvai@gmail.com * Added declaims to make it possible to locally inline string-to-octets and friends upon explicit request
Somewhere in your code (cl-rdbms maybe?) I saw you used the mappings directly. Is this related to that? What's the gain? (In either case: funcalling the mappings directly or inlining string-to-octets.)
i didn't measure anything, but it seems to be a good decision from a lib to allow inlining _when explicitly requested_ in a local declare block. (for inlining to work at all, the declaim inline must be enabled while compiling the definition) i think inlining those functions could make them a little faster due to the additional type inferencing.
Sat Feb 23 22:48:45 WET 2008 attila.lendvai@gmail.com * Added an exported lookup-string-vector-mapping for special uses of the encoders directly
This one is related to the previous question, I suppose. I'm curious about why you want to call the encoders directly. ISTR having some ideas about more features for string-to-octets and friends, so I might imagine some uses for calling the encoders directly if I could remember what those ideas were.
all i have now is the buffer reuse idea, which does not really balance an exported symbol. so let's scratch that lookup-string-vector-mapping patch for now. another interesting usecase i was considering is an encoder that can write into a (socket) stream using a local byte vector buffer and call write-sequence when the buffer gets full. calling write-byte is damn slow... but this is more like a random optimization idea than something really needed.
hint: you may consider adding Stelian and me to the babel group, so that the open source fairies could set up an official babel repo... ;) or even a minimalistic site if you don't find that offending.
I've sent a request to add you both to the group. Also, I moved my babel tree into the project's public_html. I usually screw the permitions up, so let me know if anything's wrong.
I set up a minimalistic site. Feel free to improve it.
ok, i'll try to be useful as time allows. -- attila
On 24/02/2008, Attila Lendvai <attila.lendvai@gmail.com> wrote:
baah, i fooled myself with an old change of mine. and in the light of the compiler macro i think this is BS and should be rolled back. i've unpulled stuff from my repo and amended the patches according to this mail.
Sun Feb 24 01:16:39 WET 2008 attila.lendvai@gmail.com * Added a compiler macro for lookup-mapping Hmm, the compiler macro also checks if encoding is a concrete-mapping. Did that slip through or is it intentional? Does this compiler macro kick in when string-to-octets is inlined? Otherwise, there isn't much point. But if it does kick in I can imagine how inlining might be desirable if we're converting a bunch of strings in a tight loop. Doing some profiling to check whether it is in fact worthwhile would be nice, though. I'm being paranoid because I got bitten by a (possibly premature) optimization patch in CFFI some time ago. :-)
Sat Feb 23 22:48:45 WET 2008 attila.lendvai@gmail.com * Added an exported lookup-string-vector-mapping for special uses of the encoders directly [...] all i have now is the buffer reuse idea, which does not really balance an exported symbol. so let's scratch that lookup-string-vector-mapping patch for now.
I don't have anything against the patch per se. The mappings have an exported, albeit low-level, interface anyway. I'm just curious what it's for because I'd probably prefer to add that functionality in string-to-octets in a more convenient way.
another interesting usecase i was considering is an encoder that can write into a (socket) stream using a local byte vector buffer and call write-sequence when the buffer gets full. calling write-byte is damn slow... but this is more like a random optimization idea than something really needed.
Ah yes, iolib should definitely do that. But why isn't that doable with string-to-octets? To put it in another way, what would be necessary to make that doable with string-to-octets? Would adding a vector argument and returning the number of characters consumed and number of bytes output as extra return values be enough? BTW, I've pushed your patches to the main tree. Yesterday, I had pushed them to the old tree in my c-l.net home by mistake. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
On Sun, Feb 24, 2008 at 02:26:40AM +0100, Attila Lendvai wrote:
Sat Feb 23 22:48:45 WET 2008 attila.lendvai@gmail.com * Added an exported lookup-string-vector-mapping for special uses of the encoders directly
This one is related to the previous question, I suppose. I'm curious about why you want to call the encoders directly. ISTR having some ideas about more features for string-to-octets and friends, so I might imagine some uses for calling the encoders directly if I could remember what those ideas were.
all i have now is the buffer reuse idea, which does not really balance an exported symbol. so let's scratch that lookup-string-vector-mapping patch for now.
the concatenate-strings-to-octets version that Luís just pushed still uses lookup-string-vector-mapping, btw -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.
On 24/02/2008, Stelian Ionescu <sionescu@common-lisp.net> wrote:
the concatenate-strings-to-octets version that Luís just pushed still uses lookup-string-vector-mapping, btw
Should be fixed now. Thanks. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
the concatenate-strings-to-octets version that Luís just pushed still uses lookup-string-vector-mapping, btw
it's my bug, i should have tun the test suite... what do you think about moving the tests to stefil? i feel kinda strange by pushing our stuff, but i find it much more convenient than any other test lib... (what a surprise... :) -- attila
participants (3)
-
Attila Lendvai -
Luís Oliveira -
Stelian Ionescu