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.
[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.
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.
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.
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
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.
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 Lendvai -
Luís Oliveira -
Stelian Ionescu