Re: [PD] [packOSC] reentrancy problem

2015-11-19 Thread IOhannes m zmoelnig
On 2015-11-19 09:49, IOhannes m zmoelnig wrote: > i had a quick glance at the code (didn't even try it out), now that i did try it out, it seems that something is going wrong, since when i do deeper recursion, i either get weirdo printout or segfaults (which makes me think of memory corruption).

Re: [PD] [packOSC] reentrancy problem

2015-11-18 Thread Martin Peach
On Tue, Nov 17, 2015 at 4:15 AM, Roman Haefeli wrote: > Hey, thanks for addressing the issue. > > On Mon, 2015-11-16 at 15:25 -0500, Martin Peach wrote: > > So I updated packOSC in svn to detect reentrancy and post a message. > > The message says: > error: packOSC: Use bundle

Re: [PD] [packOSC] reentrancy problem

2015-11-18 Thread Martin Peach
On Wed, Nov 18, 2015 at 11:56 AM, Martin Peach wrote: > On Tue, Nov 17, 2015 at 4:15 AM, Roman Haefeli wrote: > >> Hey, thanks for addressing the issue. >> >> On Mon, 2015-11-16 at 15:25 -0500, Martin Peach wrote: > > > >> > It seems too complicated to

Re: [PD] [packOSC] reentrancy problem

2015-11-17 Thread Roman Haefeli
On Tue, 2015-11-17 at 10:58 +0100, IOhannes m zmoelnig wrote: > On 2015-11-17 10:15, Roman Haefeli wrote: > >> > It seems too complicated to allow it. > > I see. It's not complicated at all on a patch level to make [packOSC] > > allow reentrancy. See attached patch. I can live easily without it

Re: [PD] [packOSC] reentrancy problem

2015-11-17 Thread IOhannes m zmoelnig
On 2015-11-17 10:15, Roman Haefeli wrote: >> > It seems too complicated to allow it. > I see. It's not complicated at all on a patch level to make [packOSC] > allow reentrancy. See attached patch. I can live easily without it being > fixed in [packOSC]. i forgot whether i already mentioned this,

Re: [PD] [packOSC] reentrancy problem

2015-11-17 Thread Roman Haefeli
Hey, thanks for addressing the issue. On Mon, 2015-11-16 at 15:25 -0500, Martin Peach wrote: > So I updated packOSC in svn to detect reentrancy and post a message. The message says: error: packOSC: Use bundle to send multiple messages I find this message a bit misleading as I'm not at all

Re: [PD] [packOSC] reentrancy problem

2015-11-16 Thread Martin Peach
So I updated packOSC in svn to detect reentrancy and post a message. It seems too complicated to allow it. Here's a patch that does what I believe you want using the preferred method of bundles. Martin On Fri, Nov 6, 2015 at 4:53 AM, Roman Haefeli wrote: > On Thu,

Re: [PD] [packOSC] reentrancy problem

2015-11-06 Thread Roman Haefeli
On Thu, 2015-11-05 at 16:23 -0500, Martin Peach wrote: > As I see it, the only way that [packOSC] can receive a message before > it has completed the previous message is if its own output triggers > another message to its input. It may be possible to detect that > special case and either let it

Re: [PD] [packOSC] reentrancy problem

2015-11-05 Thread Roman Haefeli
Oops.. the test patch is bogus. If [packOSC] wouldn't throw away the second message, the patch would trigger a stack overflow. Attached is a patch that wouldn't trigger any problems if [packOSC] would support reentrancy. Roman On Thu, 2015-11-05 at 13:54 +0100, Roman Haefeli wrote: > Hi all > >

Re: [PD] [packOSC] reentrancy problem

2015-11-05 Thread Martin Peach
What do you expect the patch to do, hang Pd? For me it prints this in the Pd 0.46.7 console: packOSC: This packet is not a bundle, so you can't write another address packOSC: Problem writing address. packOSC: According to the type tag I didn't expect any more arguments. packOSC: usage

Re: [PD] [packOSC] reentrancy problem

2015-11-05 Thread Roman Haefeli
On Thu, 2015-11-05 at 11:11 -0500, Martin Peach wrote: > > In your patch, if you put a [delay] after the bang outlet it will > start an infinite loop at the delay interval. I'm not sure why the > delay is necessary though, as [packOSC] should have finished > processing the previous message by

Re: [PD] [packOSC] reentrancy problem

2015-11-05 Thread Martin Peach
As I see it, the only way that [packOSC] can receive a message before it has completed the previous message is if its own output triggers another message to its input. It may be possible to detect that special case and either let it happen or not, but it's tricky because the buffer for the list is