[PD] sending image from of / libpd

[Peter Brinkmann]

Okay, I just pushed the latest version of libpd (including dynamic
allocation of the t_atom array for assembling list messages, i.e., no
a-priori limit of the message size).  I also updated the Android and iOS
branches as well as the wiki.
Cheers,
     Peter



On Tue, Aug 30, 2011 at 1:25 PM, Peter Brinkmann <
peter.brinkmann at googlemail.com> wrote:

>
>
> On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard <matju at artengine.ca>wrote:
>
>> On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:
>>
>>  why not simply resize the internal array as needed, starting with 32
>>> elements and doubling whenever the limit is reached?
>>>
>>
>> binbuf could be used for that, if the libc's realloc does in effect the
>> same thing. i think that this is the case with modern glibc (Linux/CygWin)
>> as well as Perl's allocator (when I looked at it 10 years ago), but not
>> necessarily other libc implementations (FreeBSD/OSX, Google, Microsoft) that
>> I didn't try it with, so if anyone could check, that would be interesting.
>>
>> To test that, add millions of atoms to a binbuf and see how much time it
>> takes. A «bad» implementation will roughly quadruple the time each time you
>> double the number individual additions, whereas a «good» one will just
>> double the time.
>>
>
> For the time being, I have something much simpler in mind: Just take the
> current call "int libpd_start_message(void)", which returns the current
> limit, and replace it with "int libpd_start_message(int length)", which
> takes a parameter indicating the length of the message and returns a nonzero
> error code if the length is too big.
>
> I like this idea because it's almost as simple as the original approach,
> and the API agnostic with respect to the policy for handling long messages.
> The tentative implementation that I have right now still has the hard-coded
> limit of 32 elements, and libpd_start_message simply returns an error code
> when asked for a message with more than 32 elements.  The next revision will
> dynamically resize the array if the requested length exceeds the current
> size, and it will only return an error code if the allocation of a larger
> array fails.  Either way, there's no need to reallocate because the array
> contains nothing of interest when libpd_start_message is called, and so we
> can simply throw away the old array and allocate a new one.
>
> The only disadvantage I see is that this doesn't sit well with the
> streaming-style C++ wrapper that Dan created for ofxPd, but I can think of
> workarounds for that.
> Cheers,
>      Peter
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20110830/cbd5de8d/attachment.htm>