On Mon, 31 Jul 2000, Edwin Wiles wrote:
> Theoretically, we do have a list now.  I'm going to try using it.  It's
> also a personal experiment, since I'm subscribed to 'all', but not to
> 'language'.
> 

Works for me.  Thanks, Ask!
 
> Not if I can help it!  I've run into some fairly complex binary data
> structures before.  (Working on store&forward fax switches.  In that
> case, we not only had <length><varlengthstring>, but also
> <countofstructs>, <length><offset>, <length><offset>, ...,
> <varlengthstring>, <varlengthstring>, ...
> 
> In some of the cases, the variable length portions were nested within
> each other, recursively.
> 
> Honestly, if you're dealing with something that complex, perhaps writing
> C code or something is a better idea.  Still, we can give it a look!

Same here, for the most part.  Perl probably shouldn't compete with C
(or assembler) for raw bit-processing power.  But it should be a little
better at it than a factor of 500.  

I do/did packet processing for signals processing - certainly something
of questionable production value in Perl.  But I had a difficult time
simply prototyping a new algorithm in Perl - which it is usually
wonderful for.

Perl provides the bitwise ops, and pack and unpack, and that's about it.
One of my submissions to Horos's list was the ability to have a little
more hooks in for raw buffer manipulation.  

-- 
Bryan C. Warnock
([EMAIL PROTECTED])

Reply via email to