[babel-devel] patches :)

[Attila Lendvai]

>  Sat Feb 23 22:01:55 WET 2008  attila.lendvai at 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 at 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 at 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