<br>
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.<br>
Cheers,<br>
Peter<br>
<br><br><br><div class="gmail_quote">On Tue, Aug 30, 2011 at 1:25 PM, Peter Brinkmann <span dir="ltr"><<a href="mailto:peter.brinkmann@googlemail.com">peter.brinkmann@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Tue, Aug 30, 2011 at 12:51 PM, Mathieu Bouchard <span dir="ltr"><<a href="mailto:matju@artengine.ca" target="_blank">matju@artengine.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div>On Tue, 30 Aug 2011, IOhannes m zmoelnig wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
why not simply resize the internal array as needed, starting with 32 elements and doubling whenever the limit is reached?<br>
</blockquote>
<br></div>
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.<br>
<br>
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.<br>
</blockquote></div><div><br>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.<br>
<br>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.<br>
<br>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.<br>Cheers,<br><font color="#888888"> Peter<br>
<br></font></div></div>
</blockquote></div><br>