Hello, Is it the desired behaviours that deken did not find externals when used with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
I suppose a part of deken is not loaded when pd is started with -noprefs flag, but is that really what we want? (if not, I'll fill a bug report)
cheers Cyrille
On 24.08.20 15:16, cyrille henry wrote:
Hello, Is it the desired behaviours that deken did not find externals when used with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
hmm, that would be weird as deken does not keep track of installed externals.
I suppose a part of deken is not loaded when pd is started with -noprefs flag, but is that really what we want?
hmm, that would be weird as well. i'm not aware of any deken component that would interact with "-noprefs" (actually i think that deken - being run only on the GUI-side) completely ignores the "-noprefs" flag, for good or bad)
could you post a complete search-string and the desired and actual result (which externals are you searching; which results to you get; which results did you expect?) ...1
(if not, I'll fill a bug report)
...either here on the list or in new bugreport.
gfsdmar IOhannes
ok, my guess are probably wrong, you can ignore them. the fact are : starting "pd -noprefs", a deken search for nusmuk gives me :
deken-plugin/0.5.0 (Deken externals downloader) Uploaded by zmoelnig @ 2018-06-05 21:38:10
deken-plugin/0.4.1 (Deken externals downloader) Uploaded by zmoelnig @ 2018-04-05 11:59:59
deken-plugin/0.3.1 (Deken externals downloader - MINIMUM VERSION REQUIRED FOR NEW PACKAGES) Uploaded by zmoelnig @ 2018-04-05 12:00:26
it's not the desired result.
starting "pd", a deken search for nusmuk gives me :
nusmuk-utilsv2015(Darwin-i386-32)(Linux-amd64-32)(Windows-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-03-13 10:12:20
nusmuk-audiov2015(Darwin-i386-32)(Linux-amd64-32)(Linux-i386-32)(Windows-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-03-13 10:11:12
nusmuk-utilsv2019(Darwin-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-04-03 16:53:21
nusmuk-utilsv2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:15:54
nusmuk-audiov2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:13:43
it's the desired result. can someone else confirm this behaviour?
I also tried pmpd, shmem and various other libs, with the same kind of result in both case (with and without -noprefs flag)
cheers
Le 24/08/2020 à 16:16, IOhannes m zmoelnig a écrit :
On 24.08.20 15:16, cyrille henry wrote:
Hello, Is it the desired behaviours that deken did not find externals when used with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
hmm, that would be weird as deken does not keep track of installed externals.
I suppose a part of deken is not loaded when pd is started with -noprefs flag, but is that really what we want?
hmm, that would be weird as well. i'm not aware of any deken component that would interact with "-noprefs" (actually i think that deken - being run only on the GUI-side) completely ignores the "-noprefs" flag, for good or bad)
could you post a complete search-string and the desired and actual result (which externals are you searching; which results to you get; which results did you expect?) ...1
(if not, I'll fill a bug report)
...either here on the list or in new bugreport.
gfsdmar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
FWIW, I cannot reproduce this here on Windows. "-noprefs" doesn't make a difference for Deken and I can see all the libraries you've mentioned.
What is your system?
Christof
On 24.08.2020 16:29, cyrille henry wrote:
ok, my guess are probably wrong, you can ignore them. the fact are : starting "pd -noprefs", a deken search for nusmuk gives me :
deken-plugin/0.5.0 (Deken externals downloader) Uploaded by zmoelnig @ 2018-06-05 21:38:10
deken-plugin/0.4.1 (Deken externals downloader) Uploaded by zmoelnig @ 2018-04-05 11:59:59
deken-plugin/0.3.1 (Deken externals downloader - MINIMUM VERSION REQUIRED FOR NEW PACKAGES) Uploaded by zmoelnig @ 2018-04-05 12:00:26
it's not the desired result.
starting "pd", a deken search for nusmuk gives me :
nusmuk-utilsv2015(Darwin-i386-32)(Linux-amd64-32)(Windows-i386-32)(Sources).dek
Mis en ligne par 'chnry' le : 2019-03-13 10:12:20
nusmuk-audiov2015(Darwin-i386-32)(Linux-amd64-32)(Linux-i386-32)(Windows-i386-32)(Sources).dek
Mis en ligne par 'chnry' le : 2019-03-13 10:11:12
nusmuk-utilsv2019(Darwin-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-04-03 16:53:21
nusmuk-utilsv2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:15:54
nusmuk-audiov2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:13:43
it's the desired result. can someone else confirm this behaviour?
I also tried pmpd, shmem and various other libs, with the same kind of result in both case (with and without -noprefs flag)
cheers
Le 24/08/2020 à 16:16, IOhannes m zmoelnig a écrit :
On 24.08.20 15:16, cyrille henry wrote:
Hello, Is it the desired behaviours that deken did not find externals when used with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
hmm, that would be weird as deken does not keep track of installed externals.
I suppose a part of deken is not loaded when pd is started with -noprefs flag, but is that really what we want?
hmm, that would be weird as well. i'm not aware of any deken component that would interact with "-noprefs" (actually i think that deken - being run only on the GUI-side) completely ignores the "-noprefs" flag, for good or bad)
could you post a complete search-string and the desired and actual result (which externals are you searching; which results to you get; which results did you expect?) ...1
(if not, I'll fill a bug report)
...either here on the list or in new bugreport.
gfsdmar IOhannes
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
i'm on ubuntu linux 18.04 pd 0.51.0
Le 24/08/2020 à 17:11, Christof Ressi a écrit :
FWIW, I cannot reproduce this here on Windows. "-noprefs" doesn't make a difference for Deken and I can see all the libraries you've mentioned.
What is your system?
Christof
On 24.08.2020 16:29, cyrille henry wrote:
ok, my guess are probably wrong, you can ignore them. the fact are : starting "pd -noprefs", a deken search for nusmuk gives me :
deken-plugin/0.5.0 (Deken externals downloader) Uploaded by zmoelnig @ 2018-06-05 21:38:10
deken-plugin/0.4.1 (Deken externals downloader) Uploaded by zmoelnig @ 2018-04-05 11:59:59
deken-plugin/0.3.1 (Deken externals downloader - MINIMUM VERSION REQUIRED FOR NEW PACKAGES) Uploaded by zmoelnig @ 2018-04-05 12:00:26
it's not the desired result.
starting "pd", a deken search for nusmuk gives me :
nusmuk-utilsv2015(Darwin-i386-32)(Linux-amd64-32)(Windows-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-03-13 10:12:20
nusmuk-audiov2015(Darwin-i386-32)(Linux-amd64-32)(Linux-i386-32)(Windows-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-03-13 10:11:12
nusmuk-utilsv2019(Darwin-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-04-03 16:53:21
nusmuk-utilsv2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:15:54
nusmuk-audiov2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:13:43
it's the desired result. can someone else confirm this behaviour?
I also tried pmpd, shmem and various other libs, with the same kind of result in both case (with and without -noprefs flag)
cheers
Le 24/08/2020 à 16:16, IOhannes m zmoelnig a écrit :
On 24.08.20 15:16, cyrille henry wrote:
Hello, Is it the desired behaviours that deken did not find externals when used with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
hmm, that would be weird as deken does not keep track of installed externals.
I suppose a part of deken is not loaded when pd is started with -noprefs flag, but is that really what we want?
hmm, that would be weird as well. i'm not aware of any deken component that would interact with "-noprefs" (actually i think that deken - being run only on the GUI-side) completely ignores the "-noprefs" flag, for good or bad)
could you post a complete search-string and the desired and actual result (which externals are you searching; which results to you get; which results did you expect?) ...1
(if not, I'll fill a bug report)
...either here on the list or in new bugreport.
gfsdmar IOhannes
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
strange... here on Ubuntu 16.04, pd 0.51-1 with "-noprefs", I got expected results.
Le lun. 24 août 2020 à 17:20, cyrille henry ch@chnry.net a écrit :
i'm on ubuntu linux 18.04 pd 0.51.0
Le 24/08/2020 à 17:11, Christof Ressi a écrit :
FWIW, I cannot reproduce this here on Windows. "-noprefs" doesn't make a
difference for Deken and I can see all the libraries you've mentioned.
What is your system?
Christof
On 24.08.2020 16:29, cyrille henry wrote:
ok, my guess are probably wrong, you can ignore them. the fact are : starting "pd -noprefs", a deken search for nusmuk gives me :
deken-plugin/0.5.0 (Deken externals downloader) Uploaded by zmoelnig @ 2018-06-05 21:38:10
deken-plugin/0.4.1 (Deken externals downloader) Uploaded by zmoelnig @ 2018-04-05 11:59:59
deken-plugin/0.3.1 (Deken externals downloader - MINIMUM VERSION
REQUIRED FOR NEW PACKAGES)
Uploaded by zmoelnig @ 2018-04-05 12:00:26it's not the desired result.
starting "pd", a deken search for nusmuk gives me :
nusmuk-utilsv2015(Darwin-i386-32)(Linux-amd64-32)(Windows-i386-32)(Sources).dek
Mis en ligne par 'chnry' le : 2019-03-13 10:12:20nusmuk-audiov2015(Darwin-i386-32)(Linux-amd64-32)(Linux-i386-32)(Windows-i386-32)(Sources).dek
Mis en ligne par 'chnry' le : 2019-03-13 10:11:12nusmuk-utilsv2019(Darwin-i386-32)(Sources).dek Mis en ligne par 'chnry' le : 2019-04-03 16:53:21
nusmuk-utilsv2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:15:54
nusmuk-audiov2015(Sources).dek Mis en ligne par 'lucarda' le : 2019-03-15 21:13:43
it's the desired result. can someone else confirm this behaviour?
I also tried pmpd, shmem and various other libs, with the same kind of
result in both case (with and without -noprefs flag)
cheers
Le 24/08/2020 à 16:16, IOhannes m zmoelnig a écrit :
On 24.08.20 15:16, cyrille henry wrote:
Hello, Is it the desired behaviours that deken did not find externals when
used
with "pd -noprefs" ? It look like deken propose only already downloaded externals, but not the one on the server.
hmm, that would be weird as deken does not keep track of installed externals.
I suppose a part of deken is not loaded when pd is started with
-noprefs
flag, but is that really what we want?
hmm, that would be weird as well. i'm not aware of any deken component that would interact with
"-noprefs"
(actually i think that deken - being run only on the GUI-side) completely ignores the "-noprefs" flag, for good or bad)
could you post a complete search-string and the desired and actual result (which externals are you searching; which results to you get; which results did you expect?) ...1
(if not, I'll fill a bug report)
...either here on the list or in new bugreport.
gfsdmar IOhannes
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 -> https://lists.puredata.info/listinfo/pd-list
On 24.08.20 17:20, cyrille henry wrote:
i'm on ubuntu linux 18.04 pd 0.51.0
are you sure about the Pd-version?
my interpretation of the issue you see is:
- there has been a single change to the deken package format; the
minimum deken version required for the new package format is deken-0.3.0. luckily, the deken-server knows about this; if it detects that you are using an older version of deken, it will always suggest to upgrade deken first. it tries hard to nudge the user into upgrading deken (without actually forcing them). this is why you get a capital letter warning "MINIMUM VERSION REQUIRED FOR NEW PACKAGES". this is really true: if you are using an old version of deken, you will not see any new-style packages (because deken cannot ectract them anyhow).
- you are using an older version of Pd, that comes with deken<<0.3.1
(sidenote: Ubuntu-18.04 comes with Pd-0.48-1 preinstalled [1]; Pd-0.48-1 includes deken-0.2.4 [2]
- a while ago, you have followed the instructions and installed the
updated deken package. now updating deken does not overwrite the existing source code in the Pd application folder, but instead installs a gui-plugin (in the usual path, where deken installs stuff). when you start Pd, it will first load the included (outdated) deken-plugin, and then load the plugin (there's a version check that prevents an older plugin to overwrite the included one). so you end up with a new and shiny deken plugin that can find and install all the nifty nusmuk packages.
- however, when starting Pd with "-noprefs", you are telling Pd to not
take the "usual" extra-folder into account, where you (or rather: deken) installed the updated deken-plugin. this usual extra folder is probably "~/Documents/Pd" or some self-defined folder (as the usual-usual extra folders like ~/.local/lib/pd/extra are searched regardless of the "-noprefs" flag). so the updated deken-plugin is neither found nor loaded, sending you back to square 1 and you can no longer find the new-style deken packages.
there's a couple of ways to fix the problem:
- include the /path/to/the/deken-plugin/ manually in your start-up flags
(e.g. ~/Documents/Pd/deken-plugin/, so you don't get the full ~/Documents/Pd/ search-path but only the portion that you want)
- manually include an updated version of deken into the
application-specific extra folder (it should go e.g into /usr/lib/pd/extra(deken-plugin/)
to conclude: i don't see this as a bug in deken (nor Pd). (esp. there's nothing *fixable*; new versions of deken (and Pd, which include a newer version of deken) don't have the problem.
gfmasdr IOhannes
[1] https://packages.ubuntu.com/bionic/puredata-gui [2] https://github.com/pure-data/pure-data/blob/0.48-1/tcl/pd_deken.tcl#L62
Thanks for your mail. I do use pd 0.50.0, but you are right: it's not the same deken version with or without the -noprefs flag.
the old deken plugin was in ~/pd-externals the new was in ~/Document/pd/externals I removed the old plugin, now pd find the new one with or without the -noprefs flag.
I was not aware that ~/pd-externals was a default search path even if it's not listed in the preference dialogue and that this path was used even with -noprefs.
There is still something strange : When using pd -noprefs now that I remove the old deken, pd can still find the new deken, so ~/Document/pd/externals is still in the search path. Since this 2 paths are searched with the -noprefs flag, why did the new plugin did not overwrite the old one, just like without this flag?
Anyway, it's working now.
thanks for your help cheers c
Le 25/08/2020 à 09:36, IOhannes m zmoelnig a écrit :
On 24.08.20 17:20, cyrille henry wrote:
i'm on ubuntu linux 18.04 pd 0.51.0
are you sure about the Pd-version?
my interpretation of the issue you see is:
- there has been a single change to the deken package format; the
minimum deken version required for the new package format is deken-0.3.0. luckily, the deken-server knows about this; if it detects that you are using an older version of deken, it will always suggest to upgrade deken first. it tries hard to nudge the user into upgrading deken (without actually forcing them). this is why you get a capital letter warning "MINIMUM VERSION REQUIRED FOR NEW PACKAGES". this is really true: if you are using an old version of deken, you will not see any new-style packages (because deken cannot ectract them anyhow).
- you are using an older version of Pd, that comes with deken<<0.3.1
(sidenote: Ubuntu-18.04 comes with Pd-0.48-1 preinstalled [1]; Pd-0.48-1 includes deken-0.2.4 [2]
- a while ago, you have followed the instructions and installed the
updated deken package. now updating deken does not overwrite the existing source code in the Pd application folder, but instead installs a gui-plugin (in the usual path, where deken installs stuff). when you start Pd, it will first load the included (outdated) deken-plugin, and then load the plugin (there's a version check that prevents an older plugin to overwrite the included one). so you end up with a new and shiny deken plugin that can find and install all the nifty nusmuk packages.
- however, when starting Pd with "-noprefs", you are telling Pd to not
take the "usual" extra-folder into account, where you (or rather: deken) installed the updated deken-plugin. this usual extra folder is probably "~/Documents/Pd" or some self-defined folder (as the usual-usual extra folders like ~/.local/lib/pd/extra are searched regardless of the "-noprefs" flag). so the updated deken-plugin is neither found nor loaded, sending you back to square 1 and you can no longer find the new-style deken packages.
there's a couple of ways to fix the problem:
- include the /path/to/the/deken-plugin/ manually in your start-up flags
(e.g. ~/Documents/Pd/deken-plugin/, so you don't get the full ~/Documents/Pd/ search-path but only the portion that you want)
- manually include an updated version of deken into the
application-specific extra folder (it should go e.g into /usr/lib/pd/extra(deken-plugin/)
to conclude: i don't see this as a bug in deken (nor Pd). (esp. there's nothing *fixable*; new versions of deken (and Pd, which include a newer version of deken) don't have the problem.
gfmasdr IOhannes
[1] https://packages.ubuntu.com/bionic/puredata-gui [2] https://github.com/pure-data/pure-data/blob/0.48-1/tcl/pd_deken.tcl#L62
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 25.08.20 10:35, cyrille henry wrote:
why did the new plugin did not overwrite the old one, just like without this flag?
iirc, there's some logic built into Pd to prevent double loading of plugins.
(this does not effect the built-in deken, as it comes under a slightly different filename and/or because the "built-in plugins" bypass the protection)
gfmnasdr IOhannes
ah! I just realise that the deken plugin in ~/Documents/pd is also useless with pd 0.50.0. Cheers c
Le 25/08/2020 à 12:08, IOhannes m zmoelnig a écrit :
On 25.08.20 10:35, cyrille henry wrote:
why did the new plugin did not overwrite the old one, just like without this flag?
iirc, there's some logic built into Pd to prevent double loading of plugins.
(this does not effect the built-in deken, as it comes under a slightly different filename and/or because the "built-in plugins" bypass the protection)
gfmnasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Antoine Rousseau -
Christof Ressi -
cyrille henry -
IOhannes m zmoelnig