[L2Ork-dev] cyclone merge resolution (Re: updating cyclone)

[Matt Barber]

The cyclone binops are by now ​quite stable and unlikely to change, yes? If
this is the case, one solution would be to keep the library name cyclone
for vanilla distribution, but for compiling cyclone for purr data, a simple
script to split the source file into its constituent hex-named objects
might work. It's a kludge and could cause maintenance problems, but it
would avoid all of these naming issues. Otherwise I feel ambivalent about
the whole thing.

On Thu, Jun 15, 2017 at 3:59 AM, Derek Kwan <derek.x.kwan at gmail.com> wrote:

>
> Alexandre Torres Porres <porres at gmail.com> writes:
>
> >     When trying to merge cyclone, the libloader failed, cause we had
> >     both a path and a library with the same name to load. As I see it,
> >     the options here are:
> >     1- fix the loader
> >     2- get rid of the library for purr data (we can have a workaround
> >     with hexloader, and this would also mean a separate branch)
> >     3- make cyclone into a single library named cyclone
> >     4- rename the library
>
> Hello all,
>
> We've actually been talking about the issues surrounding this in our own
> little chat (Alex, Matt, and I).
>
> If there has to be a renaming, I'm fine with "cyclone_ops" over
> "cyclops". It's as bit more transparent as to what it is and what it
> does than "cyclops" (because there's "cyclone" right out in front) and
> it does potentially eat up less of the possible names available for
> library development (although I'd say "cyclops" as a future library name
> might not be the best idea due to its similarity to "cyclone" and the
> apparently now-extinct Max object cyclops). I can also see the point of
> not calling it "cyclops" because of that old object and although I don't
> really see it being cloned anymore (although I'm not quite sure what it
> did in the first place, admittedly I'm newer to the computer
> music/creative coding game than whenever it existed) since the visual
> side of things tend to get encompassed by GEM.
>
> As far as I understand, hexloader is a utility that allows Pd to load
> non-alphanumerically named binary files by their hex-encoded name
> equivalents and it doesn't exist for Pd vanilla (at least in the default
> distribution?). I guess we could potentially package it with Cyclone in
> Deken for Pd vanilla use? But then there's the issue with hexloader
> coming with every single download of Cyclone (which would be also
> unnecessary if a person already had it for some other library). Or if we
> don't package it with Cyclone and tell people to download it to use the
> binops, that adds an extra, confusing step. Anyways, I don't think this
> seems like a good solution. I'd say for a hexloader solution to be
> feasible, it should be part of the Pd distribution it's trying to work
> with.
>
> I think my preferred solution, in agreement with Alex, is fixing the
> loader to add the greater flexibility needed for Cyclone to work as-is.
> In my understanding, it basically automates the adding of paths
> and loading of binaries and it breaks when we have cyclone the binary
> for the binops and cyclone the directory for everything else. Doing
> these things manually, at least for Pd vanilla, works and so I think, at
> least ideally, that the loader should be able to do the same sorts of
> things. This would allow for more flexibility in future Purr Data
> library development and if perhaps separable from Purr Data and usable
> as a utility for Pd vanilla, maybe it could be a good way to
> "Pd-extendize" the Pd vanilla experience, which I think a lot of users
> would appreciate.
>
> I could, however, see that fixing the behiavor of the loader with this
> greater flexibility could potentially be not-so-trivial (esp getting it
> to work cross-platform) and take a quite a bit of work. If it's only a
> problem with Cyclone and a few other libraries (or even just Cyclone),
> I understand it being not such a high priority fix and not worth the effort
> in the short term. Thus, changing the name of the cyclone binop binary
> would be the path of least-resistance and be the most feasible, esp for
> getting a new stable purr-data release out in a reasonable amount of
> time.
>
> On an additional note, we could add the "namespacing" cyclone/myobject
> functionality to the binops by the way of class_addcreator and then
> passing it gensym("cyclone/==~") for instance. I think I remember
> reading that in the issue discussion on the repo somewhere?
>
> Derek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/l2ork-dev/attachments/20170615/f3155b16/attachment.html>