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

Sun Jun 18 16:18:19 UTC 2017

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

If you wanna know, here are some notes then; "cyclops" was an external for
max from Cycling 74, sold separately, in the very early 2000s. It was a
video tracker, and has been replaced by jitter objects, that already come
as part of Max nowadays. So it is been discontinued, not sold anymore, and
the latest version people have out there does not work in Max 7!

Not a video guy myself either, but I bet there are video tracking
alternatives for Pd out there, not exactly in the same design or with the
same collection of features. And, well, cyclops was for Max, so as we
usually see when it comes to cloning max stuff, it probably has got some
max oriented things and goodies. The thing is that no one bothered to clone
this thing when it was alive, and when we had a boom of Pd external
libraries. By the way, most of Pd stuff is not active at all (GEM, for one,
has been dormant for like 5 years now... it has issues building for MacOS,
hence we don't have it in Purr Data yet). And yeah, Cyclone has no plans
whatsoever to include video stuff, let alone a discontinued video external.
So it'd never be an issue within cyclone. Cyclops.

So the fact that there was once such an object for max it's as relevant to
me as the fact that one of the x-men characters is called cyclops... not
that much of a concern that could potentially cause future name collisions.

And in any event someone decides to call an abstraction "cyclops"or
something, for a totally unrelated deal, just cause it's such a cool name,
well, you can still manage paths as the regular Pd user normally should.
It's not like there is no alternatives...

It would come down to the event of having someday a new library (as in a
single binary pack with many objects) named like that. But that wouldn't
happen if the name was taken...

Yeah, I know renaming is a dirty quick move to finally get this on the way.
That's why I sacrificed one night of sleep, went ahead and did it. But
unfortunately, people weren't happy with it. And it's cool... I think it's
nonsense, but I respect it. And, as it turns out, I wasn't happy doing this
in the first place either...

You can all see how hard it is to find a simple solution that makes
everyone happy, and it is "easy". There are all these technical details for
meeting both Pd Vanilla's and Purr Data's conditions. I just don't think
the first options should be an imposition from Purr Data's weakness to
force a change and compromise to the library, and we even ended up doing
that. When even that wasn't good enough, I'm sorry, there is where I drew
the line.

I really hope that Purr Data's development tries to accommodate third party
developments without interfering that much. Renaming the library to a name
that Purr Data's developers consider better, for technical issues there's
just no mutual agreement on, seems like too much of an interference.

It's not like I'm trying to impose otherwise, not respecting the concern,
it's just that, if this is the case, I wanted to find another solution. But
we got to a point where Purr Data was basically forking cyclone to
accommodate the solution they thought was more convenient to them, and
still asking for us to consider going in that direction to make their
development easier to maintain...

I mean, calm down, and take it easy :)

Then we got to this phase now, where it seems some votes on the pd-l2ork
list would define what cyclone developers should do... if we should accept
the pull request that was made to rename the library as they wished...

Well, I'm just now officially and finally rejecting that pull request
merge. Let's just get this over with, it went out of proportion, and now it
seems the only solution that will make everyone happy is "number 2", so
let's just go on with that.

And please, really, try to be more open and respect developers without
interfering this much here on. I really think that if Purr Data's
development goes in that direction, people will be more and more
discouraged to collaborate, really.

thanks

2017-06-18 12:28 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>:
> > 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
>>>>>
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> http://disis.music.vt.edu/listinfo/l2ork-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170618/910fdb30/attachment-0001.html>