Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread Lucas Cordiviola 

This is probably unrelated but worth trying:

When you get "broken pipe" did it worked in the first place?. i.e it was 
running and you got the error or you get the error as son as you start it?


If you got it as soon as started it could "probably" be that there's 
"white space" somewhere in Pd's path?




--

Mensaje telepatico asistido por maquinas.

On 11/17/2021 11:36 AM, João Pais wrote:
:) I do work on windows, but this issue happens only with macOs (which 
I don't have at home, and maybe now and then would be able to get 
access to).


I can try to have a look, next time I'm near a mac computer.
As my past experience following build instructions is close to 90% 
unsuccess rate - because something is missing in the instructions -, 
any time I see an error I just abort the whole process and don't try 
it anymore. It's usually too much effort and no practical benefit.


D'oh. I don't know why I though Joao was on Windows... Thanks for
the correction!

Note that lldb is the clang debugger and it works slightly
different than GDB. But you can do the same things.

On 17.11.2021 15:07, Lucas Cordiviola wrote:


@Christof,

I think Joao is needing the *macOS* pdmax.

@Joao,

Everything that Christof said applies if you follow the macOS part:

https://github.com/pure-data/pure-data/blob/master/INSTALL.txt

you just need to install xcode with this command on a terminal:

    xcode-select --install

macOS debugger is included and its called (and invoked with) "lldb".

I used it one or two times only. I'm not a mac user.


--

Mensaje telepatico asistido por maquinas.
On 11/17/2021 10:32 AM, Christof Ressi wrote:


You would have to build the pdmax external from source with
debug symbols to get meaningful information in the debugger.
This means you would need to setup Msys2, as described in the
"Windows" section in
https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.

Actually, if the aim is to only get a stacktrace, it is not
necessary to install a graphical frontend for GDB, you can also
run GDB from the command line.

I you never compiled somthing from source it can be a bit
overwhelming at first, but it's a valuable skill to have. There
are a few Windows people on the list who can help you out
(including myself).

So I would say it's not trivial, but also not impossible :-)

---

That's what I'm doing to debug subprocesses (I also needed to do
this with [vstplugin~] a few times):

1) run Pd with DSP off and start the subprocess (here: [pd~ start()

2) find the PID of the subprocess, e.g. with "tasklist | grep
" or with ProcessExplorer

3) attach to the subprocess; terminal:
https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb;
Qt Creator: "Start Debuggin" -> "Attach to Running Application"

4) turn on DSP and wait for the subprocess to crash

If the subprocess crashes immediately even with DSP turned off,
things are a bit harder.

---

If you can build pdmax with Visual Studio (I don't know if this
is supported?) then things are even easier because VS has a very
good built-in graphical debugger that can also attach to running
applications.

Christof

On 17.11.2021 14:04, João Pais wrote:

is that something a "normal user" like me (someone that only
uses the surface of the software) can do, or it has to do with
C or any other custom compiled/prepared versions?

On Wed, 17 Nov 2021 at 01:06, Christof Ressi
 wrote:

You can attach GDB to a running or even a not-yet-running
application.
When that application crashes, you get a backtrace. That's
how I found
the crash in the [pd~] subprocess.

Personally, I use Qt Creator because it has a nice
graphical front-end
for GDB where I can easily step through functions while
looking at the
code, watch local variables, etc.

Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> If by any chance you're using pd 0.52 (test version) then
I think
> it can crash when used as a subprocess (this should be
fixed for the next
> test release).  If you're using Pd 0.51-4 the problem is
something else.
>
> The "broken pipe" message means the subprocess died
suddenly for some reason.
> But I can't think of an easy way to figure out what
killed it.
>
> cheers
> Miller
>
> On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> Hello list,
>>
>> I have a max patch with pd inside through the pd~
object. But I'm getting
>> the "broken pipe" error in some cases in a mac, such as:
>>
>> - in a compiled standalone it usually works
>>

Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread João Pais 
:) I do work on windows, but this issue happens only with macOs (which I
don't have at home, and maybe now and then would be able to get access to).

I can try to have a look, next time I'm near a mac computer.
As my past experience following build instructions is close to 90%
unsuccess rate - because something is missing in the instructions -, any
time I see an error I just abort the whole process and don't try it
anymore. It's usually too much effort and no practical benefit.

D'oh. I don't know why I though Joao was on Windows... Thanks for the
> correction!
>
> Note that lldb is the clang debugger and it works slightly different than
> GDB. But you can do the same things.
> On 17.11.2021 15:07, Lucas Cordiviola wrote:
>
> @Christof,
>
> I think Joao is needing the *macOS* pdmax.
>
> @Joao,
>
> Everything that Christof said applies if you follow the macOS part:
>
> https://github.com/pure-data/pure-data/blob/master/INSTALL.txt
>
> you just need to install xcode with this command on a terminal:
>
> xcode-select --install
>
> macOS debugger is included and its called (and invoked with) "lldb".
>
> I used it one or two times only. I'm not a mac user.
>
>
> --
>
> Mensaje telepatico asistido por maquinas.
>
> On 11/17/2021 10:32 AM, Christof Ressi wrote:
>
> You would have to build the pdmax external from source with debug symbols
> to get meaningful information in the debugger. This means you would need to
> setup Msys2, as described in the "Windows" section in
> https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.
>
> Actually, if the aim is to only get a stacktrace, it is not necessary to
> install a graphical frontend for GDB, you can also run GDB from the command
> line.
>
> I you never compiled somthing from source it can be a bit overwhelming at
> first, but it's a valuable skill to have. There are a few Windows people on
> the list who can help you out (including myself).
>
> So I would say it's not trivial, but also not impossible :-)
>
> ---
>
> That's what I'm doing to debug subprocesses (I also needed to do this with
> [vstplugin~] a few times):
>
> 1) run Pd with DSP off and start the subprocess (here: [pd~ start()
>
> 2) find the PID of the subprocess, e.g. with "tasklist | grep " or
> with ProcessExplorer
>
> 3) attach to the subprocess; terminal:
> https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb;
> Qt Creator: "Start Debuggin" -> "Attach to Running Application"
>
> 4) turn on DSP and wait for the subprocess to crash
>
> If the subprocess crashes immediately even with DSP turned off, things are
> a bit harder.
>
> ---
>
> If you can build pdmax with Visual Studio (I don't know if this is
> supported?) then things are even easier because VS has a very good built-in
> graphical debugger that can also attach to running applications.
>
> Christof
> On 17.11.2021 14:04, João Pais wrote:
>
> is that something a "normal user" like me (someone that only uses the
> surface of the software) can do, or it has to do with C or any other
> custom compiled/prepared versions?
>
> On Wed, 17 Nov 2021 at 01:06, Christof Ressi 
> wrote:
>
>> You can attach GDB to a running or even a not-yet-running application.
>> When that application crashes, you get a backtrace. That's how I found
>> the crash in the [pd~] subprocess.
>>
>> Personally, I use Qt Creator because it has a nice graphical front-end
>> for GDB where I can easily step through functions while looking at the
>> code, watch local variables, etc.
>>
>> Christof
>>
>> On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
>> > If by any chance you're using pd 0.52 (test version) then I think
>> > it can crash when used as a subprocess (this should be fixed for the
>> next
>> > test release).  If you're using Pd 0.51-4 the problem is something else.
>> >
>> > The "broken pipe" message means the subprocess died suddenly for some
>> reason.
>> > But I can't think of an easy way to figure out what killed it.
>> >
>> > cheers
>> > Miller
>> >
>> > On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> >> Hello list,
>> >>
>> >> I have a max patch with pd inside through the pd~ object. But I'm
>> getting
>> >> the "broken pipe" error in some cases in a mac, such as:
>> >>
>> >> - in a compiled standalone it usually works
>> >>
>> >> - in the original patch it doesn't
>> >>
>> >> - both patches were made in the same system, with the latest pdmax and
>> pd
>> >> versions were used. I'm not sure anymore which max version or macos
>> system
>> >> was used to compile the standalone, if that's important (it was either
>> max 7
>> >> or 8).
>> >>
>> >> I don't have access to a mac myself, but the system where it was
>> tested was
>> >> a 11.6, with Max 8. It seems to me that in some systems it works, and
>> in
>> >> other it doesn't - but I don't have enough hard data to prove it.
>> >>
>> >> Best,
>> >>
>> >> Joao
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >>

Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread Christof Ressi 
D'oh. I don't know why I though Joao was on Windows... Thanks for the 
correction!


Note that lldb is the clang debugger and it works slightly different 
than GDB. But you can do the same things.


On 17.11.2021 15:07, Lucas Cordiviola wrote:


@Christof,

I think Joao is needing the *macOS* pdmax.

@Joao,

Everything that Christof said applies if you follow the macOS part:

https://github.com/pure-data/pure-data/blob/master/INSTALL.txt

you just need to install xcode with this command on a terminal:

    xcode-select --install

macOS debugger is included and its called (and invoked with) "lldb".

I used it one or two times only. I'm not a mac user.


--

Mensaje telepatico asistido por maquinas.
On 11/17/2021 10:32 AM, Christof Ressi wrote:


You would have to build the pdmax external from source with debug 
symbols to get meaningful information in the debugger. This means you 
would need to setup Msys2, as described in the "Windows" section in 
https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.


Actually, if the aim is to only get a stacktrace, it is not necessary 
to install a graphical frontend for GDB, you can also run GDB from 
the command line.


I you never compiled somthing from source it can be a bit 
overwhelming at first, but it's a valuable skill to have. There are a 
few Windows people on the list who can help you out (including myself).


So I would say it's not trivial, but also not impossible :-)

---

That's what I'm doing to debug subprocesses (I also needed to do this 
with [vstplugin~] a few times):


1) run Pd with DSP off and start the subprocess (here: [pd~ start()

2) find the PID of the subprocess, e.g. with "tasklist | grep " 
or with ProcessExplorer


3) attach to the subprocess; terminal: 
https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb; 
Qt Creator: "Start Debuggin" -> "Attach to Running Application"


4) turn on DSP and wait for the subprocess to crash

If the subprocess crashes immediately even with DSP turned off, 
things are a bit harder.


---

If you can build pdmax with Visual Studio (I don't know if this is 
supported?) then things are even easier because VS has a very good 
built-in graphical debugger that can also attach to running applications.


Christof

On 17.11.2021 14:04, João Pais wrote:
is that something a "normal user" like me (someone that only uses 
the surface of the software) can do, or it has to do with C or any 
other custom compiled/prepared versions?


On Wed, 17 Nov 2021 at 01:06, Christof Ressi 
 wrote:


You can attach GDB to a running or even a not-yet-running
application.
When that application crashes, you get a backtrace. That's how I
found
the crash in the [pd~] subprocess.

Personally, I use Qt Creator because it has a nice graphical
front-end
for GDB where I can easily step through functions while looking
at the
code, watch local variables, etc.

Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> If by any chance you're using pd 0.52 (test version) then I think
> it can crash when used as a subprocess (this should be fixed
for the next
> test release).  If you're using Pd 0.51-4 the problem is
something else.
>
> The "broken pipe" message means the subprocess died suddenly
for some reason.
> But I can't think of an easy way to figure out what killed it.
>
> cheers
> Miller
>
> On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> Hello list,
>>
>> I have a max patch with pd inside through the pd~ object. But
I'm getting
>> the "broken pipe" error in some cases in a mac, such as:
>>
>> - in a compiled standalone it usually works
>>
>> - in the original patch it doesn't
>>
>> - both patches were made in the same system, with the latest
pdmax and pd
>> versions were used. I'm not sure anymore which max version or
macos system
>> was used to compile the standalone, if that's important (it
was either max 7
>> or 8).
>>
>> I don't have access to a mac myself, but the system where it
was tested was
>> a 11.6, with Max 8. It seems to me that in some systems it
works, and in
>> other it doesn't - but I don't have enough hard data to prove it.
>>
>> Best,
>>
>> Joao
>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=

Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread Lucas Cordiviola 

@Christof,

I think Joao is needing the *macOS* pdmax.

@Joao,

Everything that Christof said applies if you follow the macOS part:

https://github.com/pure-data/pure-data/blob/master/INSTALL.txt

you just need to install xcode with this command on a terminal:

    xcode-select --install

macOS debugger is included and its called (and invoked with) "lldb".

I used it one or two times only. I'm not a mac user.


--

Mensaje telepatico asistido por maquinas.

On 11/17/2021 10:32 AM, Christof Ressi wrote:


You would have to build the pdmax external from source with debug 
symbols to get meaningful information in the debugger. This means you 
would need to setup Msys2, as described in the "Windows" section in 
https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.


Actually, if the aim is to only get a stacktrace, it is not necessary 
to install a graphical frontend for GDB, you can also run GDB from the 
command line.


I you never compiled somthing from source it can be a bit overwhelming 
at first, but it's a valuable skill to have. There are a few Windows 
people on the list who can help you out (including myself).


So I would say it's not trivial, but also not impossible :-)

---

That's what I'm doing to debug subprocesses (I also needed to do this 
with [vstplugin~] a few times):


1) run Pd with DSP off and start the subprocess (here: [pd~ start()

2) find the PID of the subprocess, e.g. with "tasklist | grep " 
or with ProcessExplorer


3) attach to the subprocess; terminal: 
https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb; 
Qt Creator: "Start Debuggin" -> "Attach to Running Application"


4) turn on DSP and wait for the subprocess to crash

If the subprocess crashes immediately even with DSP turned off, things 
are a bit harder.


---

If you can build pdmax with Visual Studio (I don't know if this is 
supported?) then things are even easier because VS has a very good 
built-in graphical debugger that can also attach to running applications.


Christof

On 17.11.2021 14:04, João Pais wrote:
is that something a "normal user" like me (someone that only uses the 
surface of the software) can do, or it has to do with C or any other 
custom compiled/prepared versions?


On Wed, 17 Nov 2021 at 01:06, Christof Ressi  
wrote:


You can attach GDB to a running or even a not-yet-running
application.
When that application crashes, you get a backtrace. That's how I
found
the crash in the [pd~] subprocess.

Personally, I use Qt Creator because it has a nice graphical
front-end
for GDB where I can easily step through functions while looking
at the
code, watch local variables, etc.

Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> If by any chance you're using pd 0.52 (test version) then I think
> it can crash when used as a subprocess (this should be fixed
for the next
> test release).  If you're using Pd 0.51-4 the problem is
something else.
>
> The "broken pipe" message means the subprocess died suddenly
for some reason.
> But I can't think of an easy way to figure out what killed it.
>
> cheers
> Miller
>
> On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> Hello list,
>>
>> I have a max patch with pd inside through the pd~ object. But
I'm getting
>> the "broken pipe" error in some cases in a mac, such as:
>>
>> - in a compiled standalone it usually works
>>
>> - in the original patch it doesn't
>>
>> - both patches were made in the same system, with the latest
pdmax and pd
>> versions were used. I'm not sure anymore which max version or
macos system
>> was used to compile the standalone, if that's important (it
was either max 7
>> or 8).
>>
>> I don't have access to a mac myself, but the system where it
was tested was
>> a 11.6, with Max 8. It seems to me that in some systems it
works, and in
>> other it doesn't - but I don't have enough hard data to prove it.
>>
>> Best,
>>
>> Joao
>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->

Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread Christof Ressi 
You would have to build the pdmax external from source with debug 
symbols to get meaningful information in the debugger. This means you 
would need to setup Msys2, as described in the "Windows" section in 
https://github.com/pure-data/pure-data/blob/master/INSTALL.txt.


Actually, if the aim is to only get a stacktrace, it is not necessary to 
install a graphical frontend for GDB, you can also run GDB from the 
command line.


I you never compiled somthing from source it can be a bit overwhelming 
at first, but it's a valuable skill to have. There are a few Windows 
people on the list who can help you out (including myself).


So I would say it's not trivial, but also not impossible :-)

---

That's what I'm doing to debug subprocesses (I also needed to do this 
with [vstplugin~] a few times):


1) run Pd with DSP off and start the subprocess (here: [pd~ start()

2) find the PID of the subprocess, e.g. with "tasklist | grep " or 
with ProcessExplorer


3) attach to the subprocess; terminal: 
https://stackoverflow.com/questions/14370972/how-to-attach-a-process-in-gdb; 
Qt Creator: "Start Debuggin" -> "Attach to Running Application"


4) turn on DSP and wait for the subprocess to crash

If the subprocess crashes immediately even with DSP turned off, things 
are a bit harder.


---

If you can build pdmax with Visual Studio (I don't know if this is 
supported?) then things are even easier because VS has a very good 
built-in graphical debugger that can also attach to running applications.


Christof

On 17.11.2021 14:04, João Pais wrote:
is that something a "normal user" like me (someone that only uses the 
surface of the software) can do, or it has to do with C or any other 
custom compiled/prepared versions?


On Wed, 17 Nov 2021 at 01:06, Christof Ressi  
wrote:


You can attach GDB to a running or even a not-yet-running
application.
When that application crashes, you get a backtrace. That's how I
found
the crash in the [pd~] subprocess.

Personally, I use Qt Creator because it has a nice graphical
front-end
for GDB where I can easily step through functions while looking at
the
code, watch local variables, etc.

Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> If by any chance you're using pd 0.52 (test version) then I think
> it can crash when used as a subprocess (this should be fixed for
the next
> test release).  If you're using Pd 0.51-4 the problem is
something else.
>
> The "broken pipe" message means the subprocess died suddenly for
some reason.
> But I can't think of an easy way to figure out what killed it.
>
> cheers
> Miller
>
> On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
>> Hello list,
>>
>> I have a max patch with pd inside through the pd~ object. But
I'm getting
>> the "broken pipe" error in some cases in a mac, such as:
>>
>> - in a compiled standalone it usually works
>>
>> - in the original patch it doesn't
>>
>> - both patches were made in the same system, with the latest
pdmax and pd
>> versions were used. I'm not sure anymore which max version or
macos system
>> was used to compile the standalone, if that's important (it was
either max 7
>> or 8).
>>
>> I don't have access to a mac myself, but the system where it
was tested was
>> a 11.6, with Max 8. It seems to me that in some systems it
works, and in
>> other it doesn't - but I don't have enough hard data to prove it.
>>
>> Best,
>>
>> Joao
>>
>>
>>
>>
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->

https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pdmax - broken pipe in macos?

2021-11-17 Thread João Pais 
is that something a "normal user" like me (someone that only uses the
surface of the software) can do, or it has to do with C or any other
custom compiled/prepared versions?

On Wed, 17 Nov 2021 at 01:06, Christof Ressi  wrote:

> You can attach GDB to a running or even a not-yet-running application.
> When that application crashes, you get a backtrace. That's how I found
> the crash in the [pd~] subprocess.
>
> Personally, I use Qt Creator because it has a nice graphical front-end
> for GDB where I can easily step through functions while looking at the
> code, watch local variables, etc.
>
> Christof
>
> On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:
> > If by any chance you're using pd 0.52 (test version) then I think
> > it can crash when used as a subprocess (this should be fixed for the next
> > test release).  If you're using Pd 0.51-4 the problem is something else.
> >
> > The "broken pipe" message means the subprocess died suddenly for some
> reason.
> > But I can't think of an easy way to figure out what killed it.
> >
> > cheers
> > Miller
> >
> > On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
> >> Hello list,
> >>
> >> I have a max patch with pd inside through the pd~ object. But I'm
> getting
> >> the "broken pipe" error in some cases in a mac, such as:
> >>
> >> - in a compiled standalone it usually works
> >>
> >> - in the original patch it doesn't
> >>
> >> - both patches were made in the same system, with the latest pdmax and
> pd
> >> versions were used. I'm not sure anymore which max version or macos
> system
> >> was used to compile the standalone, if that's important (it was either
> max 7
> >> or 8).
> >>
> >> I don't have access to a mac myself, but the system where it was tested
> was
> >> a 11.6, with Max 8. It seems to me that in some systems it works, and in
> >> other it doesn't - but I don't have enough hard data to prove it.
> >>
> >> Best,
> >>
> >> Joao
> >>
> >>
> >>
> >>
> >> ___
> >> Pd-list@lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pdmax - broken pipe in macos?

2021-11-16 Thread João Pais 
It's still 0.51-4 being used. But the strange part is that it works in 
one version and it doesn't in the other. I think I remember also working 
completely in an older system, but now I would need to have access to it 
again.




If by any chance you're using pd 0.52 (test version) then I think
it can crash when used as a subprocess (this should be fixed for the next
test release).  If you're using Pd 0.51-4 the problem is something else.

The "broken pipe" message means the subprocess died suddenly for some reason.
But I can't think of an easy way to figure out what killed it.

cheers
Miller

On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:

Hello list,

I have a max patch with pd inside through the pd~ object. But I'm getting
the "broken pipe" error in some cases in a mac, such as:

- in a compiled standalone it usually works

- in the original patch it doesn't

- both patches were made in the same system, with the latest pdmax and pd
versions were used. I'm not sure anymore which max version or macos system
was used to compile the standalone, if that's important (it was either max 7
or 8).

I don't have access to a mac myself, but the system where it was tested was
a 11.6, with Max 8. It seems to me that in some systems it works, and in
other it doesn't - but I don't have enough hard data to prove it.

Best,

Joao




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pdmax - broken pipe in macos?

2021-11-16 Thread Christof Ressi 
You can attach GDB to a running or even a not-yet-running application. 
When that application crashes, you get a backtrace. That's how I found 
the crash in the [pd~] subprocess.


Personally, I use Qt Creator because it has a nice graphical front-end 
for GDB where I can easily step through functions while looking at the 
code, watch local variables, etc.


Christof

On 17.11.2021 00:49, Miller Puckette via Pd-list wrote:

If by any chance you're using pd 0.52 (test version) then I think
it can crash when used as a subprocess (this should be fixed for the next
test release).  If you're using Pd 0.51-4 the problem is something else.

The "broken pipe" message means the subprocess died suddenly for some reason.
But I can't think of an easy way to figure out what killed it.

cheers
Miller

On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:

Hello list,

I have a max patch with pd inside through the pd~ object. But I'm getting
the "broken pipe" error in some cases in a mac, such as:

- in a compiled standalone it usually works

- in the original patch it doesn't

- both patches were made in the same system, with the latest pdmax and pd
versions were used. I'm not sure anymore which max version or macos system
was used to compile the standalone, if that's important (it was either max 7
or 8).

I don't have access to a mac myself, but the system where it was tested was
a 11.6, with Max 8. It seems to me that in some systems it works, and in
other it doesn't - but I don't have enough hard data to prove it.

Best,

Joao




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] pdmax - broken pipe in macos?

2021-11-16 Thread Miller Puckette via Pd-list 
If by any chance you're using pd 0.52 (test version) then I think
it can crash when used as a subprocess (this should be fixed for the next
test release).  If you're using Pd 0.51-4 the problem is something else.

The "broken pipe" message means the subprocess died suddenly for some reason.
But I can't think of an easy way to figure out what killed it.

cheers
Miller

On Sat, Nov 06, 2021 at 08:45:28PM +0100, João Pais wrote:
> Hello list,
> 
> I have a max patch with pd inside through the pd~ object. But I'm getting
> the "broken pipe" error in some cases in a mac, such as:
> 
> - in a compiled standalone it usually works
> 
> - in the original patch it doesn't
> 
> - both patches were made in the same system, with the latest pdmax and pd
> versions were used. I'm not sure anymore which max version or macos system
> was used to compile the standalone, if that's important (it was either max 7
> or 8).
> 
> I don't have access to a mac myself, but the system where it was tested was
> a 11.6, with Max 8. It seems to me that in some systems it works, and in
> other it doesn't - but I don't have enough hard data to prove it.
> 
> Best,
> 
> Joao
> 
> 
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist=DwICAg=-35OiAkTchMrZOngvJPOeA=XprZV3Fxus2L1LCw80hE4Q=sR96adpeL4KB76yEfQG-D8WqWrtlw2sW2qCwz_nEjLiuLt0KgKMIh-Lc-HCrSJcC=K9LPmjo4sdbRhF9wuUqbYoL5l1WxeUKav5yEeAse22o=

-- 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] pdmax - broken pipe in macos?

2021-11-06 Thread João Pais 

Hello list,

I have a max patch with pd inside through the pd~ object. But I'm 
getting the "broken pipe" error in some cases in a mac, such as:


- in a compiled standalone it usually works

- in the original patch it doesn't

- both patches were made in the same system, with the latest pdmax and 
pd versions were used. I'm not sure anymore which max version or macos 
system was used to compile the standalone, if that's important (it was 
either max 7 or 8).


I don't have access to a mac myself, but the system where it was tested 
was a 11.6, with Max 8. It seems to me that in some systems it works, 
and in other it doesn't - but I don't have enough hard data to prove it.


Best,

Joao




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list