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

Sun Jun 18 15:28:54 UTC 2017

> 2017-06-15 4:59 GMT-03:00 Derek Kwan <derek.x.kwan at gmail.com>:
> 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.
> (...) 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

Not sure it is usable in Vanilla, though I can also only see benefits in
sorting this out too.

> fixing the behaviour of the loader (...) could potentially be
not-so-trivial
> (...) If it's only a problem with Cyclone (...) I understand it being not
such
> a high priority fix

I know nothing, so I keep thinking it must be easy (I always do that,
sorry), but I also see it could be harsh to impose this one. Yeah, it's
just cyclone for now. Well, this is up to them. There are other options.

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

Not the only quick solution. Since Purr Data has hexloader preloaded, we
could have a branch that doesn't requite any library, which is in fact
something jonathan said he preferred early in this discussion. It has its
issues, but it's an option if the bigger issue is having it out of the way
quickly at any cost, and in the case Purr Data developers do not want to
touch the lib loader for now. This is something I could manage in such a
case. With the benefit of keeping cyclone "as is".

> 2017-06-15 13:18 GMT-03:00 Matt Barber <brbrofsvl at gmail.com>:
> The cyclone binops are by now quite stable and unlikely to change, yes?

Yes, they are quite stable! And, as long as we're at it, most of these
should be part of Vanilla for crying out loud...

> If this is the case, one solution would be to keep the library name
cyclone
> for vanilla distribution

with the goal of making it as only such a library, huh?

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

yeah, it's a quick deal, are we ok with this one?

cheers

2017-06-18 12:24 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> > 2017-06-15 4:59 GMT-03:00 Derek Kwan <derek.x.kwan at gmail.com>:
> > 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
>
>
> yup, not in the vanilla distribution, we wouldn't be having this
> conversation otherwise :) - cause I really had tried everything to get rid
> of this library, just to learn I couldn't! It'd be so nice to have it in
> Vanilla, but no one should dream that high :( -  It is made available in
> Purr Data and you can get it via deken, though. If only deken did handle
> dependencies, but it doesn't yet, so having the user download an extra
> external is far more complicated. Thus, I didn't even count for that option.
>
>
> > 2017-06-15 4:59 GMT-03:00 Derek Kwan <derek.x.kwan at gmail.com>:
> > 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.
>
> yes, that's doable, and I've been doing things like that in a few objects,
> to avoid collisions with vanilla objects, or provide backwards
> compatibility behavirou (such as instantiating as "Scope~") - though an
> "additional" discussion, I like that idea and I think we should do it. I
> may work on it today!
>
> cheers
>
> 2017-06-18 12:20 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:
>
>> Alexandre Torres Porres <porres at gmail.com> writes:
>>> >     3- make cyclone into a single library named cyclone
>>>
>>
>> Damn, we got issues with this one I wasn't aware.
>>
>> I really liked this idea, I was actually considering it now as my
>> preferred one. Since vanilla has no hexloader, it was the only clean option
>> for one step install, and would fix this other issue with Purr Data.
>>
>> I still think this is the ultimate goal in order to deal with this, but
>> here's the thing. It is also a long term project cause Cyclone has a few
>> abstractions in it nowadays. Those are all prototypes, not fully
>> functional, and the idea is to make them as externals in the future. But
>> for now they need the path declaration as well.
>>
>> At least this gives us motivation to turn the current abstractions into
>> objects, what you think derek/matt?
>>
>> 2017-06-14 17:41 GMT-03:00 Jonathan Wilkes <jancsika at yahoo.com>:
>>
>>>
>>> It turns out that fixing the libdir loader (or even specifying how it
>>> actually works, including edge cases) is a long term project.
>>>
>>
>> So, an update:
>>
>> 1- fix the loader *(long term project)*
>> 2- get rid of the library binary for purr data
>> 3- make cyclone into a single binary library *(long term project)*
>> 4- rename the library
>>
>>
>> 2017-06-15 13:18 GMT-03:00 Matt Barber <brbrofsvl at gmail.com>:
>>
>>> 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://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170618/2e3926d2/attachment-0001.html>