Re: [PD] "too many open files" error in 0.48.1

[Liam Goodacre]

Thank you for the input. It will be a few days before I can do any serious 
testing, but I can answer some of your questions now.

IOhannes: yes, I upgraded PD, my externals, and my OS, all at the same time. 
I'll try it out with various different versions of the same and let you know 
what happens. But just as a heads-up, it's quite possible that I am trying to 
load more than 10,000 abstractions at once. Quite difficult to count them 
though!

If neither the externals nor the OS turn out to be the problem, I'll try to 
come up with a simple test case and get back to you.

From: Pd-list  on behalf of IOhannes m zm?lnig 

Sent: 21 May 2018 20:50
To: pd-list@lists.iem.at
Subject: Re: [PD] "too many open files" error in 0.48.1

On 05/21/2018 09:37 PM, ub@xdv wrote:
> On 21.05.2018 20:54, Claude Heiland-Allen wrote:
>>
>>
>> On 21/05/18 19:35, ub@xdv wrote:
>>> hello,
>>>
>>> On 20.05.2018 06:50, Liam Goodacre wrote:
 In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
 open patches or create any more abstractions for me. I get an error
 message saying "too many open files". Granted I have a lot open, but
 this is a serious problem as it means I can't access all of my old
 performances. They worked fine in 0.47.

 Any ideas?
>>> this is not really a problem with pd
>>
>> I disagree. The most common cause of "too many open files" is a bug in
>> closing files properly,

intuitively i would agree.

> possible. never occured to me. is it in the issue tracker?

no (afaik). it hasn't been reported before.

>
>> because 1024 simultaneously-open files should be
>> enough for most use cases.definitely, but when someone says "Granted I have 
>> a lot open", that
> could be an understatement. or a regression of some sort.

so i did a test run, with some heavily embedded abstraction, that is
loaded a total of 1 times.
$ ulimit -Sn
1024
$ valgrind --track-fds=yes pd -noprefs -oss -nosound -nomidi -nrt
-stderr -open test.pd
[...]
==29030== FILE DESCRIPTORS: 3 open at exit.
==29030== Open file descriptor 2: /dev/pts/12
==29030==
==29030==
==29030== Open file descriptor 1: /dev/pts/12
==29030==
==29030==
==29030== Open file descriptor 0: /dev/pts/12
==29030==
==29030==
[...]
$

so there seems to be neither a temporary file-handle leak (because my
1 abstractions load just fine) nor an absolute file-handle leak
(since the only handles that are left open by the program are stdin,
stdout, stderr)


so i guess there must be something wrong with the patch.

@liam are there any externals in use? did you upgrade the entire system
or just Pd? when using an older version of Pd, does the problem persist?

gfmtdsar
IOhannes


>
>
>>
>>
>> Claude
>>
>>> , but with your shell- or system
>>> configuration limiting the number of open file descriptors.
>>>
>>> check your current shell-limit with
>>> ulimit -Sn
>>> -S is for soft limit (you can lower, but not raise, the hard limit).
>>> raise the limit in your shell with
>>> ulimit -n 65536
>>> start pd from that shell and see if the situation improves.
>>>
>>> if that doesn't help, you can check the kernel limits with
>>> cat /proc/sys/fs/file-nr
>>> which returns 3 numbers, the first of which is the number of open files,
>>> the last of which is the limit.
>>>
>>> increase the value of "nofile" in  /etc/security/limits.conf
>>> do
>>> sudo sysctl -p
>>>
>>> additional steps are required to make these settings permanent, the
>>> ulimit -n 65536 would have to go into your .bashrc so it's executed at
>>> system startup. if you normally start pd from your GUI you'd have to
>>> restart your system (actually just xorg) so your master shell knows
>>> about the new value. there's other ways, one of which would be to start
>>> pd from a wrapper script, or probably gnome provides that sort of
>>> environmental setup for it's program shortcuts.
>>>
>>> there's more information
>>> -
>>> https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
>>>
>>> -
>>> https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits
>>>
>>>
>>> hope that helps ... cheers,
>>> ub
>>>
 Liam


 ___
 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
>
>
> ___
> 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 -> 

Re: [PD] "too many open files" error in 0.48.1

[IOhannes m zmölnig]

On 05/21/2018 09:37 PM, ub@xdv wrote:
> On 21.05.2018 20:54, Claude Heiland-Allen wrote:
>>
>>
>> On 21/05/18 19:35, ub@xdv wrote:
>>> hello,
>>>
>>> On 20.05.2018 06:50, Liam Goodacre wrote:
 In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
 open patches or create any more abstractions for me. I get an error
 message saying "too many open files". Granted I have a lot open, but
 this is a serious problem as it means I can't access all of my old
 performances. They worked fine in 0.47.

 Any ideas?
>>> this is not really a problem with pd
>>
>> I disagree. The most common cause of "too many open files" is a bug in
>> closing files properly, 

intuitively i would agree.

> possible. never occured to me. is it in the issue tracker?

no (afaik). it hasn't been reported before.

> 
>> because 1024 simultaneously-open files should be
>> enough for most use cases.definitely, but when someone says "Granted I have 
>> a lot open", that
> could be an understatement. or a regression of some sort.

so i did a test run, with some heavily embedded abstraction, that is
loaded a total of 1 times.
$ ulimit -Sn
1024
$ valgrind --track-fds=yes pd -noprefs -oss -nosound -nomidi -nrt
-stderr -open test.pd
[...]
==29030== FILE DESCRIPTORS: 3 open at exit.
==29030== Open file descriptor 2: /dev/pts/12
==29030==
==29030==
==29030== Open file descriptor 1: /dev/pts/12
==29030==
==29030==
==29030== Open file descriptor 0: /dev/pts/12
==29030==
==29030==
[...]
$

so there seems to be neither a temporary file-handle leak (because my
1 abstractions load just fine) nor an absolute file-handle leak
(since the only handles that are left open by the program are stdin,
stdout, stderr)


so i guess there must be something wrong with the patch.

@liam are there any externals in use? did you upgrade the entire system
or just Pd? when using an older version of Pd, does the problem persist?

gfmtdsar
IOhannes


> 
> 
>>
>>
>> Claude
>>
>>> , but with your shell- or system
>>> configuration limiting the number of open file descriptors.
>>>
>>> check your current shell-limit with
>>> ulimit -Sn
>>> -S is for soft limit (you can lower, but not raise, the hard limit).
>>> raise the limit in your shell with
>>> ulimit -n 65536
>>> start pd from that shell and see if the situation improves.
>>>
>>> if that doesn't help, you can check the kernel limits with
>>> cat /proc/sys/fs/file-nr
>>> which returns 3 numbers, the first of which is the number of open files,
>>> the last of which is the limit.
>>>
>>> increase the value of "nofile" in  /etc/security/limits.conf
>>> do
>>> sudo sysctl -p
>>>
>>> additional steps are required to make these settings permanent, the
>>> ulimit -n 65536 would have to go into your .bashrc so it's executed at
>>> system startup. if you normally start pd from your GUI you'd have to
>>> restart your system (actually just xorg) so your master shell knows
>>> about the new value. there's other ways, one of which would be to start
>>> pd from a wrapper script, or probably gnome provides that sort of
>>> environmental setup for it's program shortcuts.
>>>
>>> there's more information
>>> -
>>> https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
>>>
>>> -
>>> https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits
>>>
>>>
>>> hope that helps ... cheers,
>>> ub
>>>
 Liam


 ___
 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
> 
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 




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

Re: [PD] "too many open files" error in 0.48.1

[ub@xdv]

On 21.05.2018 20:54, Claude Heiland-Allen wrote:
> 
> 
> On 21/05/18 19:35, ub@xdv wrote:
>> hello,
>>
>> On 20.05.2018 06:50, Liam Goodacre wrote:
>>> In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
>>> open patches or create any more abstractions for me. I get an error
>>> message saying "too many open files". Granted I have a lot open, but
>>> this is a serious problem as it means I can't access all of my old
>>> performances. They worked fine in 0.47.
>>>
>>> Any ideas?
>> this is not really a problem with pd
> 
> I disagree. The most common cause of "too many open files" is a bug in
> closing files properly, 
possible. never occured to me. is it in the issue tracker?

> because 1024 simultaneously-open files should be
> enough for most use cases.definitely, but when someone says "Granted I have a 
> lot open", that
could be an understatement. or a regression of some sort.


> 
> 
> Claude
> 
>> , but with your shell- or system
>> configuration limiting the number of open file descriptors.
>>
>> check your current shell-limit with
>> ulimit -Sn
>> -S is for soft limit (you can lower, but not raise, the hard limit).
>> raise the limit in your shell with
>> ulimit -n 65536
>> start pd from that shell and see if the situation improves.
>>
>> if that doesn't help, you can check the kernel limits with
>> cat /proc/sys/fs/file-nr
>> which returns 3 numbers, the first of which is the number of open files,
>> the last of which is the limit.
>>
>> increase the value of "nofile" in  /etc/security/limits.conf
>> do
>> sudo sysctl -p
>>
>> additional steps are required to make these settings permanent, the
>> ulimit -n 65536 would have to go into your .bashrc so it's executed at
>> system startup. if you normally start pd from your GUI you'd have to
>> restart your system (actually just xorg) so your master shell knows
>> about the new value. there's other ways, one of which would be to start
>> pd from a wrapper script, or probably gnome provides that sort of
>> environmental setup for it's program shortcuts.
>>
>> there's more information
>> -
>> https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
>>
>> -
>> https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits
>>
>>
>> hope that helps ... cheers,
>> ub
>>
>>> Liam
>>>
>>>
>>> ___
>>> 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


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

Re: [PD] "too many open files" error in 0.48.1

[Miller Puckette]

Yes, it woulds like there's a bug in Pd... is it possible to reduce your
patch to a reasonably simple test case that causes the problem?

thanks
Miller

On Mon, May 21, 2018 at 07:54:23PM +0100, Claude Heiland-Allen wrote:
> 
> 
> On 21/05/18 19:35, ub@xdv wrote:
> > hello,
> > 
> > On 20.05.2018 06:50, Liam Goodacre wrote:
> > > In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
> > > open patches or create any more abstractions for me. I get an error
> > > message saying "too many open files". Granted I have a lot open, but
> > > this is a serious problem as it means I can't access all of my old
> > > performances. They worked fine in 0.47.
> > > 
> > > Any ideas?
> > this is not really a problem with pd
> 
> I disagree.  The most common cause of "too many open files" is a bug in
> closing files properly, because 1024 simultaneously-open files should be
> enough for most use cases.
> 
> 
> Claude
> 
> > , but with your shell- or system
> > configuration limiting the number of open file descriptors.
> > 
> > check your current shell-limit with
> > ulimit -Sn
> > -S is for soft limit (you can lower, but not raise, the hard limit).
> > raise the limit in your shell with
> > ulimit -n 65536
> > start pd from that shell and see if the situation improves.
> > 
> > if that doesn't help, you can check the kernel limits with
> > cat /proc/sys/fs/file-nr
> > which returns 3 numbers, the first of which is the number of open files,
> > the last of which is the limit.
> > 
> > increase the value of "nofile" in  /etc/security/limits.conf
> > do
> > sudo sysctl -p
> > 
> > additional steps are required to make these settings permanent, the
> > ulimit -n 65536 would have to go into your .bashrc so it's executed at
> > system startup. if you normally start pd from your GUI you'd have to
> > restart your system (actually just xorg) so your master shell knows
> > about the new value. there's other ways, one of which would be to start
> > pd from a wrapper script, or probably gnome provides that sort of
> > environmental setup for it's program shortcuts.
> > 
> > there's more information
> > -
> > https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
> > -
> > https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits
> > 
> > hope that helps ... cheers,
> > ub
> > 
> > > Liam
> > > 
> > > 
> > > ___
> > > 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
> -- 
> https://mathr.co.uk
> 
> 
> ___
> 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] "too many open files" error in 0.48.1

[Claude Heiland-Allen]

On 21/05/18 19:35, ub@xdv wrote:

hello,

On 20.05.2018 06:50, Liam Goodacre wrote:

In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
open patches or create any more abstractions for me. I get an error
message saying "too many open files". Granted I have a lot open, but
this is a serious problem as it means I can't access all of my old
performances. They worked fine in 0.47.

Any ideas?

this is not really a problem with pd


I disagree.  The most common cause of "too many open files" is a bug in 
closing files properly, because 1024 simultaneously-open files should be 
enough for most use cases.



Claude


, but with your shell- or system
configuration limiting the number of open file descriptors.

check your current shell-limit with
ulimit -Sn
-S is for soft limit (you can lower, but not raise, the hard limit).
raise the limit in your shell with
ulimit -n 65536
start pd from that shell and see if the situation improves.

if that doesn't help, you can check the kernel limits with
cat /proc/sys/fs/file-nr
which returns 3 numbers, the first of which is the number of open files,
the last of which is the limit.

increase the value of "nofile" in  /etc/security/limits.conf
do
sudo sysctl -p

additional steps are required to make these settings permanent, the
ulimit -n 65536 would have to go into your .bashrc so it's executed at
system startup. if you normally start pd from your GUI you'd have to
restart your system (actually just xorg) so your master shell knows
about the new value. there's other ways, one of which would be to start
pd from a wrapper script, or probably gnome provides that sort of
environmental setup for it's program shortcuts.

there's more information
-
https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
-
https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits

hope that helps ... cheers,
ub


Liam


___
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

--
https://mathr.co.uk


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

Re: [PD] "too many open files" error in 0.48.1

[Liam Goodacre]

Thanks for this feedback, it looks very thorough. I'll work through your 
suggestions later on this week or at the weekend.

So that I can get a better handle on what's causing the issue, am I right in 
saying that each instantiation of an abstraction constitutes one file 
descriptor?

Liam

From: Pd-list  on behalf of ub@xdv 
Sent: 21 May 2018 19:35
To: pd-list@lists.iem.at
Subject: Re: [PD] "too many open files" error in 0.48.1

hello,

On 20.05.2018 06:50, Liam Goodacre wrote:
> In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
> open patches or create any more abstractions for me. I get an error
> message saying "too many open files". Granted I have a lot open, but
> this is a serious problem as it means I can't access all of my old
> performances. They worked fine in 0.47.
>
> Any ideas?
this is not really a problem with pd, but with your shell- or system
configuration limiting the number of open file descriptors.

check your current shell-limit with
ulimit -Sn
-S is for soft limit (you can lower, but not raise, the hard limit).
raise the limit in your shell with
ulimit -n 65536
start pd from that shell and see if the situation improves.

if that doesn't help, you can check the kernel limits with
cat /proc/sys/fs/file-nr
which returns 3 numbers, the first of which is the number of open files,
the last of which is the limit.

increase the value of "nofile" in  /etc/security/limits.conf
do
sudo sysctl -p

additional steps are required to make these settings permanent, the
ulimit -n 65536 would have to go into your .bashrc so it's executed at
system startup. if you normally start pd from your GUI you'd have to
restart your system (actually just xorg) so your master shell knows
about the new value. there's other ways, one of which would be to start
pd from a wrapper script, or probably gnome provides that sort of
environmental setup for it's program shortcuts.

there's more information
-
https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
-
https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits

hope that helps ... cheers,
ub

>
> Liam
>
>
> ___
> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] "too many open files" error in 0.48.1

[ub@xdv]

hello,

On 20.05.2018 06:50, Liam Goodacre wrote:
> In 0.48.1 on Ubuntu, I'm getting a horrible scenario where PD refuses to
> open patches or create any more abstractions for me. I get an error
> message saying "too many open files". Granted I have a lot open, but
> this is a serious problem as it means I can't access all of my old
> performances. They worked fine in 0.47.
> 
> Any ideas?
this is not really a problem with pd, but with your shell- or system
configuration limiting the number of open file descriptors.

check your current shell-limit with
ulimit -Sn
-S is for soft limit (you can lower, but not raise, the hard limit).
raise the limit in your shell with
ulimit -n 65536
start pd from that shell and see if the situation improves.

if that doesn't help, you can check the kernel limits with
cat /proc/sys/fs/file-nr
which returns 3 numbers, the first of which is the number of open files,
the last of which is the limit.

increase the value of "nofile" in  /etc/security/limits.conf
do
sudo sysctl -p

additional steps are required to make these settings permanent, the
ulimit -n 65536 would have to go into your .bashrc so it's executed at
system startup. if you normally start pd from your GUI you'd have to
restart your system (actually just xorg) so your master shell knows
about the new value. there's other ways, one of which would be to start
pd from a wrapper script, or probably gnome provides that sort of
environmental setup for it's program shortcuts.

there's more information
-
https://askubuntu.com/questions/162229/how-do-i-increase-the-open-files-limit-for-a-non-root-user
-
https://unix.stackexchange.com/questions/29577/ulimit-difference-between-hard-and-soft-limits

hope that helps ... cheers,
ub

> 
> Liam
> 
> 
> ___
> 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] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 15:31 +0200, Christof Ressi wrote:
> this has been on my wish list for a while and I want to do a PR. do
> you guys have suggestions which kind of interface you would prefer?
> these come to my mind:
> * [delete] object: send it a pointer and it will delete the scalar

I thought this one to be the most natural, since there is also an
[append] object.

> * [delete ( message for canvases

There are no other uses where  a method uses a pointer as argument, are
there?

> * [delete( message for [pointer]: deletes the scalar of the currently
> stored pointer.

Sounds good, too, and seems what has the most thumb-ups yet.

> I tend towards the last option, since [pointer] is already used to
> traverse a subpatch, so [delete( could go well with [traverse(,
> [bang( and [next(. the canvas messages would also makes sense to me.
> having a dedicated object seems rather overkill.

You're probably right.


Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Data structures - delete specific scalar?

[Roman Haefeli]

On Sun, 2018-05-20 at 05:40 -0700, Derek Kwan wrote:
> Roman Haefeli  writes:
> 
> > Hey all
> > 
> > Following up a thread from 2011:
> > https://lists.puredata.info/pipermail/pd-list/2011-04/088306.html

> If I'm not mistaken, this relates to a thread I started in Jan 2017
> and
> I think this bit from Christof Ressi might prove releavant to these
> discussions so hopefully this link could help with the current
> discussion:
> 
> https://lists.puredata.info/pipermail/pd-list/2017-01/117295.html

Oh yes. I didn't find this one when using search machines. This
basically answers my questions. Thanks.

Roman

signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Using externals with libpd on Windows

[Christof Ressi]

hmmm, I might try it myself in the next few days.

BTW,

> also using the windows .lib to statically import the symbols.

the import library (.lib) is only necessary if you work with MSVC, GCC can 
directly link to a DLL
 
 

Gesendet: Montag, 21. Mai 2018 um 12:10 Uhr
Von: "Joe White" 
An: "Christof Ressi" 
Cc: Pd-list 
Betreff: Re: Re: [PD] Using externals with libpd on Windows

I'm linking against libpd dynamically, also using the windows .lib to 
statically import the symbols.
 
On 18 May 2018 at 19:35, Christof Ressi 
 wrote:just to be sure: 
are you using a static or dynamic version of libpd in your program?

Gesendet: Freitag, 18. Mai 2018 um 17:38 Uhr
Von: "Joe White" 
An: "Christof Ressi" 
Cc: Pd-list 
Betreff: Re: [PD] Using externals with libpd on Windows

Thanks for the info Christof!
 
It seems to me that compiling libpd via the makefile [0] in mingw already 
exports all the symbols correctly.

 
Seems like the solution in your link [1] suggests to export the symbols in the 
exe, and also update the plugins to load the functions via GetProcAddress. I'm 
trying to avoid touching the 3rd party externals if possible as I can already 
re-link them against the libpd.dll but don't feel that is very maintainable. 
 
Has anyone managed to successfully load pre-compiled externals in a 
libpd-embedded Windows application?
 
I'm currently trying to see if it's possible to point the externals to the find 
the pd symbols elsewhere as they get loaded, but my hopes aren't high!
 
Thanks,
Joe
 
[0] 
https://github.com/libpd/libpd/blob/master/Makefile#L23[https://github.com/libpd/libpd/blob/master/Makefile#L23]
[1] 
http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW]]
 
On 11 May 2018 at 20:04, Christof Ressi 

 wrote:yes, this is a limitation on windows where a DLL can't automatically 
import symbols from the executable where it was loaded (what you get on Linux 
with --export-dynamic). for Pd the solution is to make the app itself a thin 
wrapper around a DLL (pd.dll) which plugins can link to.

I found this link which might be helpful:

http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW][http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW[http://forums.codeguru.com/showthread.php?536343-RESOLVED-accessing-symbols-in-appllication-from-within-dynamic-library-MinGW]]

I guess if you compile libpd as a DLL (with "--export-all-symbols") existing 
externals should load.
 


Gesendet: Freitag, 11. Mai 2018 um 19:21 Uhr
Von: "Joe White" 

An: Pd-list 

Betreff: [PD] Using externals with libpd on Windows

Hi all, 
 
I recently spent a bit of time tracking down why a patch wasn't loading a 
couple of externals in a windows application that embeds libpd.
 
The patch was using vbap [0] and soundfile_info from iemlib [1].
 
The issue I found was that the pre-built binaries that work in the window 
version of the Pd authoring environment were linking against pd.dll (I'm 
assuming from Pd/bin/) in order to correctly link against the plugin API 
methods exposed in m_pd.h.
 
The solution I recently came to, though admittedly a bit of a hack, was to 
generate a custom VS2017 dll project for both vbap, and soundfile_info, include 
the relevant source files, and link against the compiled version of libpd to 
resolve the missing symbols instead of the authoring libraries.
 
The downside of this approach is that the manually compiled externals will no 
longer run in the Pd authoring environment, and it's not really maintainable 
from a development perspective. 
 
From my days of making externals for macos, I don't think I ever had to link 
against Pd, but just include m_pd.h and be done.
 
My question is whether this 

Re: [PD] Escaping/not resolving dollar argts in msgs/objects?

[Derek Kwan]

Ingo Stock  writes:

> On 05/20/2018 02:12 PM, Derek Kwan wrote:
>> As a side note, I don't really particular about this situation right now
>> and don't have a use case as of yet, but it looks like both the $$
>> approach and the tosymbol approach don't work with trying to insert
>> literal "$0, $1, $2" and so on in [text]s the "patching" sort of way via
>> [text insert]? You can enter those literals just fine via the popup Pd
>> text window and those will save just fine, but both the $$ and tosymbol
>> methods via [text insert] yield input that looks to be their escaped
>> \$0, \$1 versions within the popup Pd text window and then when you try
>> to save the contents of that window they get resolved (so $0 goes to 0
>> and $1 yields \\$1: argument number out of range warnings).
>
> Yes, the escape mechanism seems to be a bit quirky at times. For
> example, in the attached patch create-arrays5.pd, the array names are
> being created the way described above in the thread and put into a
> [text] object, where they occur escaped. The contents of the [text] can
> be saved with the patch. If you create the arrays from the [text] after
> writing to it, the arrays are created fine. But if you reload the patch,
> $0 is escaped in the array objects, although the contents of [text] look
> exactly the same. Maybe a bug, maybe some quirk.
>
> Anyhow, there is a solution for writing $0 into [text] and easily
> generate objects from there that is robust against saving the [text]
> contents with the patch, using [text fromlist], which is demonstrated in
> the attached patch create-arrays7.pd. :)
>
> best wishes, ingo
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list


ah, well that answers that hah. thx!

and yeah, i suppose its' a bit quirky given that at least functionally
texts are collections of lists but I suppose these sorts of things fall
more into the "not officially supported" category than not...

derek

-- 
Derek Kwan
www.derekxkwan.com

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