On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:

>äh?
> you really don't want to autocomplete *that*.

I don't even know what that does, i was just looking for stuff with long names haha




On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:
> these examples puzzle me a bit, as they are quite the reverse of what i  consider "monolithic libraries".
> when loading zexy as a multi-object library (aka "monolithic library"),
> then there will be *no* [zexy/demultiplex] object, just [demultiplex].

On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote:
> You can find them separately using a special "monolithic search mode" that displays the library name on the completions list but only auto completes the object name (since you can't use namespaces with those).


That's why the auto complete shows the library name in the suggestion windows but doesn't type it.

For example, you will search for ",demu" ant it will display "zexy/demux" so you know you should load zexy, but when you press enter it will only type demux :)


The gif on the readme.md in the repository shows the three search modes in action.






On 06/11/2018 15:47 PM, IOhannes m zmölnig wrote:

> not sure whether this is directed at me (i don't remember saying anything about performance)


Oh, sorry, i forgot to Ctrl+V the text quoting Dan. It should be

On 06/10/2018 15:58 PM, Dan Wilcox wrote:

> The other aspect is more organizational: how/when do we integrate new things into the pd "core" and keep it maintainable. There is a conscious decision not to put *everything* into to core but some things may > make sense. However I'd suggest *lots* of testing and built-in extensibility before making a formal proposal for it to be adopted. For instance, does this plugin impact GUI performance when patching on slow > machines ie. RPI? I don't know, but it would be good to find out before adding something that would then be *expected* to work well.

"About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory?"


I read on the Netiquette that "Never ever reply to a digested email if you do not refer to exactly one email in the digest."

Does that apply to standard emails too? Sorry if that's the case. This mailing list thing is completely new to me.

Cheers,
Henri.

De: Pd-dev <pd-dev-bounces@lists.iem.at> em nome de IOhannes m zmölnig <zmoelnig@iem.at>
Enviado: segunda-feira, 11 de junho de 2018 15:47
Para: pd-dev@lists.iem.at
Assunto: Re: [PD-dev] PD AutoComplete Plugin
 
On 06/11/2018 07:11 PM, Henri Augusto Bisognini wrote:
> zexy/0x3d0x3d0x7e

äh?
you really don't want to autocomplete *that*.

> The only thing it can't do is to read inside those sys dependent files to know what objects are there inside monolithic libraries, like zexy. For that reason it reads a .txt file that the user can set that contains that information. Something like:
>
> [...]
> zexy/atoi
> zexy/demultiplex
> zexy/demux
>

these examples puzzle me a bit, as they are quite the reverse of what i
consider "monolithic libraries".
when loading zexy as a multi-object library (aka "monolithic library"),
then there will be *no* [zexy/demultiplex] object, just [demultiplex].

so: are we really talking about the same thing here?
> It would definitely be better to communicate with pd directly to query those objects. Is that possible for a GUI plugin?

not for a gui-plugin alone.
however, you can write "mixed-mode plugins" that consist of a both a
gui-plugin and an external (https://git.iem.at/pd-gui/punish/ uses this
quite a lot; it's basically a gui-plugin that tells Pd-core to load an
external to add the necessary C-parts).

> About it running on slow computers like Raspberry Pis. What exactly would be the the problem? Processing or memory?

not sure whether this is directed at me (i don't remember saying
anything about performance)

> Right know the plugin only increases 424kb in RAM usage on my windows computer and i have a reasonable amounts of externals.

however, i think that the number of autocompletable objects will only
have very little impact on the total RAM used by Pd(gui).
i wouldn't worry about the memory foot-print at all :-)


gfmdsar
IOhannes