On 2015-11-19 09:49, IOhannes m zmoelnig wrote:
to keep the performance of a heap allocated buffer, i would suggest to:
- use the original scheme for an "immediate" (non-recursive) message
- detect recursion, and if so, allocate buffers on the stack.
attached is a patch that implements that. the patch is against current HEAD, though i really worked on HEAD~1, so it reverts a number of (imho unneccessary) things.
it only touches functions that actually do output things (minus the revert-last-commit),
fgmaf IOhannes
Thanks for that. It also works up to a point but it's causing trouble as in the attached patch. The original message gets scrambled if its payload is not of the same type as the intervening message.
Also I find that bundles don't actually work. If you try to add another message to a bundle it fails:
packOSC: According to the type tag (i) I expected more arguments. packOSC: Problem writing address. packOSC: According to the type tag I expected an argument of a different type. * Expected s, string now in
packOSC: According to the type tag I expected an argument of a different type. * Expected s, string now in
packOSC: usage error, write-msg failed. packOSC: According to the type tag (i) I expected more arguments. packOSC: Problem closing bundle.
I'm not sure this ever worked or if got broken at some point. Bundles with one message are fine.
Martin
On Thu, Nov 19, 2015 at 4:53 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2015-11-19 09:49, IOhannes m zmoelnig wrote:
to keep the performance of a heap allocated buffer, i would suggest to:
- use the original scheme for an "immediate" (non-recursive) message
- detect recursion, and if so, allocate buffers on the stack.
attached is a patch that implements that. the patch is against current HEAD, though i really worked on HEAD~1, so it reverts a number of (imho unneccessary) things.
it only touches functions that actually do output things (minus the revert-last-commit),
fgmaf IOhannes
On 11/19/2015 07:02 PM, Martin Peach wrote:
Thanks for that. It also works up to a point but it's causing trouble as in the attached patch. The original message gets scrambled if its payload is not of the same type as the intervening message.
afaict this is a problem of [unpackOSC] not allowing reentrancy either.
at least if i replace [unpackOSC] with an abstraction build with [oscparse] (see attachments) this problem goes away.
Also I find that bundles don't actually work. If you try to add another message to a bundle it fails:
indeed.
packOSC: According to the type tag (i) I expected more arguments. packOSC: Problem writing address. packOSC: According to the type tag I expected an argument of a different type.
- Expected s, string now in
packOSC: According to the type tag I expected an argument of a different type.
- Expected s, string now in
packOSC: usage error, write-msg failed. packOSC: According to the type tag (i) I expected more arguments. packOSC: Problem closing bundle.
I'm not sure this ever worked or if got broken at some point. Bundles with one message are fine.
i was pretty sure that i have been able to send bundles with multiple messages in the past. but then: "[, send /bar bar, send /foo foo foo, ]" works fine, wheras if i switch the messages "[, send /foo foo foo, send /bar bar, ]" it fails.
with the power of git bisect i tried finding out when this behaviour was introduced, only to find that it has always been there! (that is: since revision 5629, when "osc" was added to the repository)
mgfasr IOhannes
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach