Re: string.pack with bit resolution

[Francisco Olarte <folarte@...>]

bil til ( is this the name? )

One thing. Sending this without any quoting to provide context makes
knowing what you are referring to a wild guess.

That being said:

On Wed, Oct 16, 2019 at 1:03 PM bil til <flyer31@googlemail.com> wrote:
> Yes of course this should be done in C. I can do it in my own lib.

I'm assuming you may be replying to a previous message of mine ( this
is the lack of context I was referring to ).

> But to
> send message to devices of other people, it would be very nice to have a
> standard way to define this packing. If there would be lua support for this,
> at least for the basic things, it would be VERY nice if they can be done
> "intrinsic" in Lua.

Well, lua is not python, no batteries included. I think this problem
is a very specialized one and I would put it in a module anyway ( like
the standard modules which are supplied in Lua ), specially given it
can be nicely defined and delimited.

The sending to other devices is easy. You have to send them the format
strings anyway, send them the packing library. In fact you can make a
C-level library plus a lua binding and send it, so they can either use
it in C or in lua. In fact, given lua does not make backwards
compatibility guarantees among version this could greatly help you to
future-proof your devices, which can be tricky to upgrade.

> To keep things simple, the bit-/byte-count values could be restricted quite
> much. I would be happy with the following additional types:
> a,a2,a3,a4,a5,a6,a7,b3,h3 (+ the corresponding unsigneds with large letter),
> plus r for short-float. And we could agree, that all types automatically
> aling to byte, except the bit-types a...a7, they really need bit packing if
> they succeed on each other... .

Even if you preserve the byte align for other types, you still need
bit packing logic. In fact the bit packer is made (theoretically) more
complex by the need to fall back to byte alignement ( point is
probably moot since normally any packer will have ops to align to
8/16/32 bits boundaries ).

And, for me, I would prefer to have a byte-packer with a simple
definition and a bit-packer with another simple definition more than
having both mixed, specially as the byte one is proven and should have
few bugs left. And lets not enter on whether the BYTE string produced
by the BIT packer should have bits LSB or MSB first inside bytes, and
numbers LSB or MSB first into the bit stream. I think you are grossly
understimating the consequences of adding bit-packing to string.pack.

Francisco Olarte.