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

[Alexandre Torres Porres]

>
> 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/93cd538a/attachment.html>