hi all,
i would like to change the way the "find externals" search currently works.
right now, whenever you enter a simple search term (e.g. "foo"), the search will return all libraries and objects that have the string "foo" somewhere in their name. i think this is wrong, as it makes it extra hard to search for an exact name that happens to also be used as a part of library/object names.
the problem is somewhat enlarged, as by default both libraries and objects are searched, and the object-results are kind of opaque (e.g. looking for "lim" will return 10 hits. among them is "bandLIMited", zexy and iemlib.
to the user it's a bit mysterious why they get these results (they probably don't know that there's a [limiter~] in zexy, or a [speedlim] in iemlib).
i think it would help a lot if a search term like "lim" would only return exact matches.
it's probably little known, but you can already use wildcards in your search term. so if you do want to search for any string containg 'lim', you can (already) use "*lim*". you can also use "lim*" (to match any strings that start with 'lim') resp "*lim" (for strings that end with 'lim').
right now, the logic is: if there is no wildcard in the searchstring, the server will automatically add '*' around the term (so 'lim' really becomes '*lim*')
i'd like to require the user to add wildcards explicitely.
the thing is: the implicit wildcards are added on the server-side. if i change it there, suddenly all searches are going to behave different than how they do now. regardless of the Pd-veresion (or deken-plugin version) you are using.
how would you see such a change? would the disruption be acceptable? or not? (in which case i need to find some other solution; however, if the current behaviour is annoying to most people anyhow, i'd rather change it for good)
gfmadrs IOhannes
On Fri, 2021-02-26 at 11:12 +0100, IOhannes m zmoelnig wrote:
how would you see such a change?
I very much welcome it.
would the disruption be acceptable?
The reason which triggered me to bring up the "detect dependencies from patch" thread was the fact that I got reports from users who were confused by the search results of "osc". Currently, it seems hard to pick the right one. Removing implicit wildcard matching would help greatly. I don't know if removing implicit wildcard matching would cause troubles, but I can't think of any right now.
Roman
On Fri, 2021-02-26 at 13:58 +0100, Roman Haefeli wrote:
On Fri, 2021-02-26 at 11:12 +0100, IOhannes m zmoelnig wrote:
how would you see such a change?
I very much welcome it.
would the disruption be acceptable?
The reason which triggered me to bring up the "detect dependencies from patch" thread was the fact that I got reports from users who were confused by the search results of "osc". Currently, it seems hard to pick the right one. Removing implicit wildcard matching would help greatly. I don't know if removing implicit wildcard matching would cause troubles, but I can't think of any right now.
On second read, my reasoning seems based on one specific issue I experienced, so that's not a strong point.
But I honestly think that far more often you follow instructions and know exactly the name of the externals you want to install. I believe remembering only part of the name of an external is less common. As you say: If you only remember a part and you know it, you still can employ explicit wildcard characters. So yes, removing implicit wildcard matching would be an improvement.
Roman
On 2/26/2021 7:12 AM, IOhannes m zmoelnig wrote:
how would you see such a change?
Sounds good but needs documentation.
would the disruption be acceptable? or not? (in which case i need to find some other solution; however, if the current behaviour is annoying to most people anyhow, i'd rather change it for good)
We can document
- "require the user to add wildcards explicitely"
and
in a the html manual chapter 4.2.3.
May be Deken can have a [?] button that opens that chapter in the browser. (the html can even show the 204kB mp4 video from #84).
--
Mensaje telepatico asistido por maquinas.
On 2/26/21 8:40 PM, Lucas Cordiviola wrote:
On 2/26/2021 7:12 AM, IOhannes m zmoelnig wrote:
how would you see such a change?
Sounds good but needs documentatio > We can document
- "require the user to add wildcards explicitely"
and
in a the html manual chapter 4.2.3.
May be Deken can have a [?] button that opens that chapter in the browser. (the html can even show the 204kB mp4 video from #84).
the problem is, that the change is server side and will affect all versions of deken and Pd. so even if you add some documentation to Pd-0.52, this won't help those people that use the Pd-0.51.
anyhow. let's see how people complain in real life.
gfmasdr IOhannes
On 2/26/21 8:40 PM, Lucas Cordiviola wrote:
We can document
[...]
note that this doesn't yet work with Pd-vanilla, as it requires a (tiny) bit of changes on the Pd-core side.
there's a branch in the pure-data repository that has these changes (named "feature/dekenception" or somesuch), but not even a pull-requests. this branch also requires the latest deken incorporated into Pd (for which there isn't a PR yet either).
i'm planning to do the deken PR later this week, but as i did a bit of code-refactoring, it would require some more testing. volunteers are welcome.
I really like the new feature where you can search explicitly for an object or a library.
one thing though is that people expect all objects are findable, but ones uploaded earlier (like the ones from pd extended) do not have an object list, right?
On facebook someone was searching for "envgen", hoping to find the one from 'ggee' (only that he didn't know it was from ggee, hence he looked for the object) but found a library called "jl", with an object with the same name, which wasn't a GUI so he thought there was a bug with Pd Vanilla...
not sure if there's an easy way to add all objects to deken to minimize this issue. At least for all externals in extended. Do we need to reupload them one by one (newer uploads to deken automatically provide an object list, right?)??? Is it too much work and no one wants that? I can help with tedious work...
cheers
Em seg., 1 de mar. de 2021 às 07:16, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
On 2/26/21 8:40 PM, Lucas Cordiviola wrote:
We can document
[...]
note that this doesn't yet work with Pd-vanilla, as it requires a (tiny) bit of changes on the Pd-core side.
there's a branch in the pure-data repository that has these changes (named "feature/dekenception" or somesuch), but not even a pull-requests. this branch also requires the latest deken incorporated into Pd (for which there isn't a PR yet either).
i'm planning to do the deken PR later this week, but as i did a bit of code-refactoring, it would require some more testing. volunteers are welcome.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
My wrongly named 0.0.extended(1) versions for Windows-amd64 have the objectlist.txt.
Sometimes you get more results if you don't hide "foreign architectures" in Deken preferences.
(1) On my uploads "0.0.extended" means the the sources are from the last "pd-extended" but they are not bit by bit exact as there was no Windows-amd64 binaries in the pd-extended era.
--
Mensaje telepatico asistido por maquinas.
On 3/1/2021 2:18 PM, Alexandre Torres Porres wrote:
I really like the new feature where you can search explicitly for an object or a library.
one thing though is that people expect all objects are findable, but ones uploaded earlier (like the ones from pd extended) do not have an object list, right?
On facebook someone was searching for "envgen", hoping to find the one from 'ggee' (only that he didn't know it was from ggee, hence he looked for the object) but found a library called "jl", with an object with the same name, which wasn't a GUI so he thought there was a bug with Pd Vanilla...
not sure if there's an easy way to add all objects to deken to minimize this issue. At least for all externals in extended. Do we need to reupload them one by one (newer uploads to deken automatically provide an object list, right?)??? Is it too much work and no one wants that? I can help with tedious work...
cheers
Em seg., 1 de mar. de 2021 às 07:16, IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> escreveu:
On 2/26/21 8:40 PM, Lucas Cordiviola wrote: > We can document [...] > - https://github.com/pure-data/deken/issues/84#issuecomment-786533931 <https://github.com/pure-data/deken/issues/84#issuecomment-786533931> note that this doesn't yet work with Pd-vanilla, as it requires a (tiny) bit of changes on the Pd-core side. there's a branch in the pure-data repository that has these changes (named "feature/dekenception" or somesuch), but not even a pull-requests. this branch also requires the latest deken incorporated into Pd (for which there isn't a PR yet either). i'm planning to do the deken PR later this week, but as i did a bit of code-refactoring, it would require some more testing. volunteers are welcome. _______________________________________________ Pd-list@lists.iem.at <mailto:Pd-list@lists.iem.at> mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <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 think it's pretty related, though :) we're talking about finding matches, matching specifically to externals, but there's this issue where there are some stuff there missing to be found and I think we should also improve that so it all makes better sense. But tell me what you think I should do, open a ticket to deken? Open a new thread?
Em seg., 1 de mar. de 2021 às 17:31, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 3/1/21 6:18 PM, Alexandre Torres Porres wrote:
I really like the new feature where you can search explicitly for an
object
or a library.
cool ;-)
the rest of your email isn't really related to "find exact matches", is it?
gfmsrd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 3/1/21 6:18 PM, Alexandre Torres Porres wrote:
not sure if there's an easy way to add all objects to deken to minimize this issue. At least for all externals in extended. Do we need to reupload them one by one (newer uploads to deken automatically provide an object list, right?)??? Is it too much work and no one wants that? I can help with tedious work...
well. objectlists are just files that sit besides the deken package (on the server). they need to follow a special naming convention (basically: they need to have the same name as the deken package) and live in the very same directory. so: you don't really need to upload all packages again, just to add objectlists. (however, you do need write-permissions on the folder that contain the original packages.)
the real show stopper is, that objectlists are only supported with the deken-v1 format (.dek files), but not with the deken-v0 format (which was used to upload the v0.0.extended packages).
mgfds. IOhannes
Em seg., 1 de mar. de 2021 às 17:36, IOhannes m zmölnig zmoelnig@iem.at escreveu:
On 3/1/21 6:18 PM, Alexandre Torres Porres wrote:
not sure if there's an easy way to add all objects to deken to minimize this issue. At least for all externals in extended. Do we need to
reupload
them one by one (newer uploads to deken automatically provide an object list, right?)??? Is it too much work and no one wants that? I can help
with
tedious work...
well. objectlists are just files that sit besides the deken package (on the server). they need to follow a special naming convention (basically: they need to have the same name as the deken package) and live in the very same directory. so: you don't really need to upload all packages again, just to add objectlists. (however, you do need write-permissions on the folder that contain the original packages.)
the real show stopper is, that objectlists are only supported with the deken-v1 format (.dek files), but not with the deken-v0 format (which was used to upload the v0.0.extended packages).
so we actually really need to reupload them, given the scenario, huh?
On Mon, 2021-03-01 at 17:45 -0300, Alexandre Torres Porres wrote:
so we actually really need to reupload them, given the scenario, huh?
Oh no, please don't. I'm grateful for all the effort that went into making these packages available through Deken. It made the transition from Pd-extended a breeze. But since how long is Pd-extended dead now? Let those packages die in peace.
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use *today* and put that to Deken, along with an objects file. IMHO, the original binaries should be left alone.
Do you have any particular libraries in mind?
Roman
On 3/1/2021 6:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use*today* and put that to Deken, along with an objects file. IMHO, the original binaries should be left alone.
I agree. Not sure if there's a "disk space concern" on the server side.
I'm planning to redo all [0.0extended windows-amd64] with proper names/version and better makefiles. (but this is only for the 0.0extended win-amd64 that are on my puredata.info folder).
If we do proper pd-lib-builder makefiles for the 0.0extended versions (and upload pkgs with sources) then when we have the proper *double precision extension* compiling and uploading will be really fast and easy.
Mensaje telepatico asistido por maquinas.
Em seg., 1 de mar. de 2021 às 18:33, Lucas Cordiviola lucarda27@hotmail.com escreveu:
If we do proper pd-lib-builder makefiles for the 0.0extended versions (and upload pkgs with sources) then when we have the proper *double precision extension* compiling and uploading will be really fast and easy.
Forgot about pd 64 bits!!! Good thinking :) we'll need to reupload it all then...
Off topic:
pd 64 bits
*argh* Let's stop confusing "64-bit" with "double precision"!
On 02.03.2021 00:16, Alexandre Torres Porres wrote:
Em seg., 1 de mar. de 2021 às 18:33, Lucas Cordiviola <lucarda27@hotmail.com mailto:lucarda27@hotmail.com> escreveu:
If we do proper pd-lib-builder makefiles for the 0.0extended versions (and upload pkgs with sources) then when we have the proper *double precision extension* compiling and uploading will be really fast and easy.Forgot about pd 64 bits!!! Good thinking :) we'll need to reupload it all then...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I had opened a feature request already: https://github.com/pure-data/pure-data/issues/902
Is not a re-upload but an plain "upload"
--
Mensaje telepatico asistido por maquinas.
On 3/1/2021 8:16 PM, Alexandre Torres Porres wrote:
Forgot about pd 64 bits!!! Good thinking :) we'll need to reupload it all then...
I had opened a feature request already: https://github.com/pure-data/pure-data/issues/902
Is not a re-upload but an plain "upload"
--
Mensaje telepatico asistido por maquinas.
On 3/1/2021 8:16 PM, Alexandre Torres Porres wrote:
Em seg., 1 de mar. de 2021 às 18:33, Lucas Cordiviola <lucarda27@hotmail.com mailto:lucarda27@hotmail.com> escreveu:
If we do proper pd-lib-builder makefiles for the 0.0extended versions (and upload pkgs with sources) then when we have the proper *double precision extension* compiling and uploading will be really fast and easy.Forgot about pd 64 bits!!! Good thinking :) we'll need to reupload it all then...
On 3/1/21 10:31 PM, Lucas Cordiviola wrote:
On 3/1/2021 6:16 PM, Roman Haefeli wrote:
I agree. Not sure if there's a "disk space concern" on the server side.
there was a recent thread about excessive disk usage by some externals on this list.
the gist is that disk space on deken.puredata.info is *not* unlimited. i don't know the full size of all the old externals from Pd-extended on all supported archs, but i think any batch upload should be coordinated with the site-admins¹ first.
gfamsdr IOhannes
¹ yours truely
Em seg., 1 de mar. de 2021 às 18:18, Roman Haefeli reduzent@gmail.com escreveu:
Oh no, please don't. I'm grateful for all the effort that went into making these packages available through Deken. It made the transition from Pd-extended a breeze. But since how long is Pd-extended dead now? Let those packages die in peace.
If there are libraries only available with the v0.0-extended version,
then I propose to give them a version proper, compile them for the architectures in use *today* and put that to Deken, along with an objects file. IMHO, the original binaries should be left alone.
For a moment I thought you were saying "screw who needs those old externals", but now I see your point is different, right? :) Well, as someone who's working on a new library that offers many alternatives to unsupported/old libraries, I actually tend to think like that, but that's bad! I've seen people really frustrated trying to restore old extended patches that used more obscure externals, and I've seen them give up on Pd (all forks) or on vanilla for that.
Do you have any particular libraries in mind?
All of them, that's it! Let's get *every* object from extended listed and findable via deken with its corresponding library. Yeah, it's a dirty, lame and arguable job, but I think someone's gotta do it, and I'm game.
Now, if we'll leave the packages alone or have new versions, I don't know. I like the idea of making it clear that the library belonged to Extended and if it only has "v0.0extended" I don't really see the point in having a new version, but I don't really have a strong opinion on this.
One way or another, what actually brought this up was someone having trouble finding 'envgen' from ggee in deken, finding the one from 'jl' instead (which is not from Extended by the way). Now, ggee has a repository that you collaborated on => https://github.com/pd-externals/ggee So... yeah, you've already uploaded a new version of ggee to deken, so maybe you can get a new version or the object list with it?
thanks and cheers
On Mon, 2021-03-01 at 20:13 -0300, Alexandre Torres Porres wrote:
One way or another, what actually brought this up was someone having trouble finding 'envgen' from ggee in deken, finding the one from 'jl' instead (which is not from Extended by the way). Now, ggee has a repository that you collaborated on => https://github.com/pd-externals/ggee So... yeah, you've already uploaded a new version of ggee to deken, so maybe you can get a new version or the object list with it?
Yeah, I think that is the way forward. Can you open an issue?
Roman
On Mon, 2021-03-01 at 20:13 -0300, Alexandre Torres Porres wrote:
Now, ggee has a repository that you collaborated on => https://github.com/pd-externals/ggee So... yeah, you've already uploaded a new version of ggee to deken, so maybe you can get a new version or the object list with it?
I've just uploaded ggee 0.28 to Deken that ships with an object list.
For those interested:
I merged a PR [1] that prevents Pd from crashing when Gem and [shell] are used together. As a side-effect, [shell] now returns the correct exit code and not just 0.
[1] https://github.com/pd-externals/ggee/pull/10
Roman
On 3/1/21 10:16 PM, Roman Haefeli wrote:
On Mon, 2021-03-01 at 17:45 -0300, Alexandre Torres Porres wrote:
so we actually really need to reupload them, given the scenario, huh?
Oh no, please don't. I'm grateful for all the effort that went into making these packages available through Deken. It made the transition from Pd-extended a breeze. But since how long is Pd-extended dead now? Let those packages die in peace.
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use *today* and put that to Deken, along with an objects file. IMHO, the original binaries should be left alone.
+10
fgdret IOhannes
On 3/1/21 10:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper,
coincidentally i wrote an email to lucas yesterday about avoiding to use the "0.0.extended" dummy-version for uploads. this was before *this* thread got momentum (although lucas alluded to my post).
since i now think that this post is of general merit, here's the gist of it:
I used the "0.0.extended" version for all libraries when I did the initial batch upload back then when deken started. this special version means two things:
- this package is the very same version of the library that was bundled
with the last release of Pd-extended
- this package *has been bundled* with the last release of Pd-extended
(it's the one library; bit-for-bit identical) note the use of "package" which really refers to the binary files (rather than just the version)
now the first meaning ("same library version") has a very profane background: we uploaded several hundreds of packages, and there was no sane way to get the correct version number for each of them (some had a meta.pd file, others didn't; nobody felt like doing a manual investigation for all these packages).
the idea was, that whenever somebody as not happy with the binaries (e.g. because they fail with newer versions of Pd; or because there's a new architecture,...) they would investigate in the real version of the library and use that for uploading. (if you only upload a single library, that shouldn't be too much of a hurdle).
now i guess, I never told anybody about all those "meanings" of the "0.0.extended" version. which would explain why people like you just used that "0.0.extended" version, presumably (only) meaning that "this is built from the same sources as the other '0.0.extended' packages of this library".
obviously the 2nd meaning of the dummy-version ("this binary was bundled with Pd-extended") is just plain wrong four your uploads (as there haven't been a Windows64 version of Pd-extended, so these versions just didn't exist). the 1st meaning *might* be true for your packages, but that is really hard to tell, as the batch-uploaded '0.0.extended' packages lack sources.
gfdmasr IOhannes
PS lucas might notice that I changed a couple of "we" to "me" - so i take full blame for all the decisions.
On 3/1/21 10:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use*today* and put that to Deken, along with an objects file.
and first migrate those libraries to github. i probably could do a batch import (from https://git.puredata.info) of all those libraries into the https://github.com/pd-externals/ namespace.
however, a number of libs are actively maintained in their own namespaces, and I think those should be left alone.
so I would need a list of libraries to import.
fmgdar IOhannes
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
so I would need a list of libraries to import.
There might be more but these are not maintained AFAIK:
adaptive arraysize bassemu~ boids chaos ekext hexloader log markex mediasettings motex PDContainer pddp pmpd cxc ext13 windowing pmpd moocow
--
Mensaje telepatico asistido por maquinas.
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
On 3/1/21 10:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use*today* and put that to Deken, along with an objects file.
and first migrate those libraries to github. i probably could do a batch import (from https://git.puredata.info) of all those libraries into the https://github.com/pd-externals/ namespace.
however, a number of libs are actively maintained in their own namespaces, and I think those should be left alone.
so I would need a list of libraries to import.
fmgdar IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
pmpd is maintained!!!
Le 02/03/2021 à 10:31, Lucas Cordiviola a écrit :
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
so I would need a list of libraries to import.
There might be more but these are not maintained AFAIK:
adaptive arraysize bassemu~ boids chaos ekext hexloader log markex mediasettings motex PDContainer pddp pmpd cxc ext13 windowing pmpd moocow
--
Mensaje telepatico asistido por maquinas.
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
On 3/1/21 10:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use*today* and put that to Deken, along with an objects file.
and first migrate those libraries to github. i probably could do a batch import (from https://git.puredata.info) of all those libraries into the https://github.com/pd-externals/ namespace.
however, a number of libs are actively maintained in their own namespaces, and I think those should be left alone.
so I would need a list of libraries to import.
fmgdar 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
<3
On 02.03.21 11:18, cyrille henry wrote:
pmpd is maintained!!!
Le 02/03/2021 à 10:31, Lucas Cordiviola a écrit :
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
so I would need a list of libraries to import.
There might be more but these are not maintained AFAIK:
adaptive arraysize bassemu~ boids chaos ekext hexloader log markex mediasettings motex PDContainer pddp pmpd cxc ext13 windowing pmpd moocow
--
Mensaje telepatico asistido por maquinas.
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
On 3/1/21 10:16 PM, Roman Haefeli wrote:
If there are libraries only available with the v0.0-extended version, then I propose to give them a version proper, compile them for the architectures in use*today* and put that to Deken, along with an objects file.
and first migrate those libraries to github. i probably could do a batch import (from https://git.puredata.info) of all those libraries into the https://github.com/pd-externals/ namespace.
however, a number of libs are actively maintained in their own namespaces, and I think those should be left alone.
so I would need a list of libraries to import.
fmgdar 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
On 3/2/21 10:31 AM, Lucas Cordiviola wrote:
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
so I would need a list of libraries to import.
There might be more but these are not maintained AFAIK:
adaptive arraysize bassemu~ boids chaos ekext hexloader log markex mediasettings motex PDContainer pddp pmpd cxc ext13 windowing pmpd moocow
"hexloader" and "mediasettings" are maintained.
"arraysize" has been superseded by "array size" (and it was a test-project in the first place, let's not resurrect it).
but more interestingly: how did you come up with this list?
i tried:
import requests
import json
data=json.loads( \
requests.get("https://deken.puredata.info/search.json").text \
)["result"]["libraries"]
xlibs=[]
for lib in data:
if not [_ for _ in data[lib] \
if _ not in ('0.0.extended', '0-0extended')]:
xlibs.append(lib)
# remove libs hosted (and maintained) at the iem:
xlibs = [_ for _ in xlibs if not _.startswith("iem")]
xlibs = [_ for _ in xlibs if not _.startswith("pix_")]
# and some more libs that are known to be maintained
xlibs = [_ for _ in xlibs if _ not in ("hexloader", "pmpd")]
for lib in sorted(set(xlibs)):
print(lib)
which gives me: PDContainer adaptive apple arraysize bassemu bassemu~ boids chaos earplug earplug~ extra flatgui gem2pdp hcs hidin jasch_lib la-kitchen libdir log mapping markex motex nsend oscx pan pd-wavelet pdcontainer pddp pdlua pdogg pdp plugin~ purepd rtc search-plugin sfruit syslog tclpd testtools timestretch unauthorized vanilla vbap
there's a few duplicates ("bassemu~" vs "bassemu", "earplug~" vs "earplug", "PDcontainer" vs "pdcontainer") and a few libraries that i believe should not be made available at all: "arraysize", "extra", "vanilla", "oscx"
gfmadsr IOhannes
on telegram community, neuerbor is updating bassemu, but i don't know if this counts as "maintained"
his/her fork https://github.com/nioelumijkee/bassemu2
Em Ter, 2 de mar de 2021 10:19, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
On 3/2/21 10:31 AM, Lucas Cordiviola wrote:
On 3/2/2021 4:26 AM, IOhannes m zmoelnig wrote:
so I would need a list of libraries to import.
There might be more but these are not maintained AFAIK:
adaptive arraysize bassemu~ boids chaos ekext hexloader log markex mediasettings motex PDContainer pddp pmpd cxc ext13 windowing pmpd moocow
"hexloader" and "mediasettings" are maintained.
"arraysize" has been superseded by "array size" (and it was a test-project in the first place, let's not resurrect it).
but more interestingly: how did you come up with this list?
i tried:
import requests import json data=json.loads( \ requests.get("https://deken.puredata.info/search.json").text \ )["result"]["libraries"] xlibs=[] for lib in data: if not [_ for _ in data[lib] \ if _ not in ('0.0.extended', '0-0extended')]: xlibs.append(lib) # remove libs hosted (and maintained) at the iem: xlibs = [_ for _ in xlibs if not _.startswith("iem")] xlibs = [_ for _ in xlibs if not _.startswith("pix_")] # and some more libs that are known to be maintained xlibs = [_ for _ in xlibs if _ not in ("hexloader", "pmpd")] for lib in sorted(set(xlibs)): print(lib)which gives me: PDContainer adaptive apple arraysize bassemu bassemu~ boids chaos earplug earplug~ extra flatgui gem2pdp hcs hidin jasch_lib la-kitchen libdir log mapping markex motex nsend oscx pan pd-wavelet pdcontainer pddp pdlua pdogg pdp plugin~ purepd rtc search-plugin sfruit syslog tclpd testtools timestretch unauthorized vanilla vbap
there's a few duplicates ("bassemu~" vs "bassemu", "earplug~" vs "earplug", "PDcontainer" vs "pdcontainer") and a few libraries that i believe should not be made available at all: "arraysize", "extra", "vanilla", "oscx"
gfmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
how would you see such a change?
I'm all ok with it!
Le ven. 26 févr. 2021 à 11:12, IOhannes m zmoelnig zmoelnig@iem.at a écrit :
hi all,
i would like to change the way the "find externals" search currently works.
right now, whenever you enter a simple search term (e.g. "foo"), the search will return all libraries and objects that have the string "foo" somewhere in their name. i think this is wrong, as it makes it extra hard to search for an exact name that happens to also be used as a part of library/object names.
the problem is somewhat enlarged, as by default both libraries and objects are searched, and the object-results are kind of opaque (e.g. looking for "lim" will return 10 hits. among them is "bandLIMited", zexy and iemlib.
to the user it's a bit mysterious why they get these results (they probably don't know that there's a [limiter~] in zexy, or a [speedlim] in iemlib).
i think it would help a lot if a search term like "lim" would only return exact matches.
it's probably little known, but you can already use wildcards in your search term. so if you do want to search for any string containg 'lim', you can (already) use "*lim*". you can also use "lim*" (to match any strings that start with 'lim') resp "*lim" (for strings that end with 'lim').
right now, the logic is: if there is no wildcard in the searchstring, the server will automatically add '*' around the term (so 'lim' really becomes '*lim*')
i'd like to require the user to add wildcards explicitely.
the thing is: the implicit wildcards are added on the server-side. if i change it there, suddenly all searches are going to behave different than how they do now. regardless of the Pd-veresion (or deken-plugin version) you are using.
how would you see such a change? would the disruption be acceptable? or not? (in which case i need to find some other solution; however, if the current behaviour is annoying to most people anyhow, i'd rather change it for good)
gfmadrs IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex., 26 de fev. de 2021 às 07:14, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
i think it would help a lot if a search term like "lim" would only return exact matches.
+1
i'd like to require the user to add wildcards explicitely.
+1
i like the idea of requiring the user to add wildcards explicitly, but if you favor about backward compatibility, one suggestion would be to add " " when you want exact matches, so a search for lim would be (*lim*) but a search for "lim" would be (lim).. what do you think?
in this case: lim and *lim* are the same "lim" are exact matches lim* are beginning with lim *lim are ending with lim
we keep backwards compatibility and add the option to exact matches, in newer versions of deken you could put a hint "put quotes if you want exact matches! see the docs for more examples on wildcards usage"
Em dom., 28 de fev. de 2021 às 16:23, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex., 26 de fev. de 2021 às 07:14, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
i think it would help a lot if a search term like "lim" would only return exact matches.
+1
i'd like to require the user to add wildcards explicitely.
+1 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Antoine Rousseau -
Christof Ressi -
cyrille henry -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
José de Abreu -
Lucas Cordiviola -
Max -
Roman Haefeli