Sounds good, thanks!
On Fri, Dec 10, 2021 at 7:23 PM Alexander Burger
wrote:
> Hi Jason,
>
> > o Interpretation of a 'struct descriptor value of '( NIL . sz )'
> > or '( F . sz ) ( Fill / Fix ( since 'P and 'I are taken)) ?
>
> This sounds like a good idea. Using NIL would be along the li
Hi Jason,
> o Interpretation of a 'struct descriptor value of '( NIL . sz )'
> or '( F . sz ) ( Fill / Fix ( since 'P and 'I are taken)) ?
This sounds like a good idea. Using NIL would be along the line of "void" in the
context of result specifications. Let me investigate.
>And, as o
Many thanks for most informative replies !
OK, I agree, leave 'struct and 'native as they are -
maybe / perhaps with ONLY the addition of:
o Interpretation of a 'struct descriptor value of '( NIL . sz )'
or '( F . sz ) ( Fill / Fix ( since 'P and 'I are taken)) ?
meaning PAD of size sz
Hi Beneroth,
> Just a question/idea, maybe nonsense:
> Is (struct) really limited to use with (native)?
Not explicitly, but on the Lisp level such formatted buffers are not really
useful. They don't need to be passed to 'native' though, calls to libraries in
the form (lib:foo 'arg) are also possi
Hi Jason,
Perhaps the PicoLisp documentation needs some updating, but the
functionality of 'native' and 'struct' is as it should be.
You have to understand that PicoLisp is not Ruby or NodeJS. There is no
hand-holding whatsoever. If you ask for X, that's what you get, by design.
As a somewhat l
Hi everyone,
Great discussion, thank you all!
> 'native' and 'struct' do exactly what the programmer tells them. Nothing
> tricky
> or clever behind the scenes. I do not want them to insert bytes based on
> assumptions.
Sounds right to me, no hidden magic please. But yes to more comfort.
Maybe
Hi Cesar,
> You can disagree, but cannot keep disagreeing and maintain the
> documentation related to the implementation "Creates or extracts data
> structures, suitable to be passed to or returned from native C functions."
Exactly. Of course this buffer, filled with any data, can always be pass
Alex,
You can disagree, but cannot keep disagreeing and maintain the
documentation related to the implementation "Creates or extracts data
structures, suitable to be passed to or returned from native C functions."
If the idea is as you describe, then the doc should be reformed and the
user instr
Hi Jason,
> But I have to respectfully disagree - 'struct' should know
> that if its current offset is 10, and it next needs to layout
> a 4-byte integer, it should insert 2 pad bytes to begin
Equally respectful I have to re-disagree ;)
1. "'struct' should know" is not the case. It should just d
Hi,
If you know, that struct does its job as if you specified packed in C,
then you can pass packed or aligned structs to C functions, just
you need to do the alignment yourself.
I vaguely remember the pain, when I needed to process BMP graphics
files on DEC Alpha processors...
Andras Pahi
> On
Thanks Alex -
But I have to respectfully disagree - 'struct' should know
that if its current offset is 10, and it next needs to layout
a 4-byte integer, it should insert 2 pad bytes to begin
the integer at offset 12 - the same as it should know
in the 'struct tm' case, that if it has jus
On Mon, Dec 06, 2021 at 11:21:27PM +0100, Alexander Burger wrote:
> No, it is correct. It stores (all little-endian):
>
>(1 . 8) 1 0 0 0 0 0 0 0 # 8 bytes
>(2 . 2) 2 0 # 2 bytes
>(3 . 4) 3 0 0 0 # 4 bytes
The point is: 'struct' does exactly what you tell it to d
Hi Jason,
> But the main point I was trying to make is that this behaviour
> is just plain wrong IMHO :
> : (struct Ptr '( P W I ) '(1 . 8) '(2 . 2) '(3 . 4))
> -> (1 2 3)
> : (struct Ptr '( B . 32 ))
> -> (1 0 0 0 0 0 0 0 2 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0)
>
>The '3' value should b
Much thanks for your most informative reply, Alex -
But the main point I was trying to make is that this behaviour
is just plain wrong IMHO :
: (struct Ptr '( P W I ) '(1 . 8) '(2 . 2) '(3 . 4))
-> (1 2 3)
: (struct Ptr '( B . 32 ))
-> (1 0 0 0 0 0 0 0 2 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0
Hi Jason,
thanks a lot for your long post!
> '(struct ...)' can guess C native structure alignment wrong:
> ...
> So, please ammend 'struct' et al to get this
> alignment right.
I think we have a misunderstanding here. The 'struct' function does not "guess"
anything. It does not even have the sl
15 matches
Mail list logo
