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

[Alexandre Torres Porres]

I have to admit I'm really confused and undecided with all the options, and
I'm sorry if this gets in the way... please cope with me, it is from a good
interest in making the usage of cyclone the best user experience possible,
but there are just too many things in the way, such as issues with vanilla,
now issues with Purr Data, and it's all just hard...

2017-06-14 16:48 GMT-03:00 Alexandre Torres Porres <porres at gmail.com>:

> Hi, thanks for doing this, I appreciate it.
>
> For those not aware, this has been a long discussion, with many turns and
> lots of new information to me. Let me summarize.
>
> 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
>
> But why do we have now both a path and a library? The library is for
> loading operators with non-alphanumeric characters, an issue that is only
> solvable in vanilla with a library, or a third party external dependency
> (hexloader). The reason we have both it and a set of single binaries is
> that we inherited the single binaries from the last maintenance phase.
>
> If I'm not mistaken, cyclone used to come as a single library binary, but
> got chopped off into separate binaries in Pd Extended because of some
> Pd-Extended issue I don't know about.
>
> So, on to my opinion on the solutions. I've listed them in order of
> personal preference, kinda...
>
> Fixing the loader is option number 1, it would introduce the least change,
> and would bring benefits of improving the loader system.
>
> A second option would be to create a branch in Purr Data that just loads
> files with hexloader (like it is doing with zexy). This is actually
> something jonathan proposed first. This forces the creation of a separate
> branch for the Purr Data help files and all, but I don't think it is that
> much of a hassle and I could work on that, no problem.
>
> The most complicated issue, on my opinion, is thinking about what to do
> with the "operators library". This just opens a can of worms in my head...
> and I'm sorry if it is hard for me to take a decision about it, I'm just
> not sure which is the best one.
>
> One issue is that I already forced a name change. In cyclone 0.2 it was
> called 'nettles', I hated that name to the guts (I never knew what it
> meant, it was never part of cyclone before, I felt it was hard to relate
> that name to cyclone), so I thought it was best to revert back to the
> original "cyclone" library (which used to call these objects).
>
> I actually also have an issue on the need of these two part deal, loading
> cyclone both as a set of separate binaries, where you need to include
> cyclone's path, but also a library only for a subset of objects. That was
> never a good design decision. It would be preferable if it'd be just one
> thing, either all separate binaries, or just a single binary pack.
>
> Again, vanilla can't load non-alphanumeric, so that's out. I'm dreaming we
> could try and make this into vanilla, but I should get real...
>
> and well, I never discarded the idea of making cyclone into a single
> binary pack. That would make it simpler, cleaner, and would also fix the
> loading issue in Purr Data. So it feels like a good option.
>
> Renaming the library yet once again is something that would be a last
> resource kind of thing for me. In an outburst of impulse and anxiety, I did
> propose and changed the library name to 'cyclops' (standing for 'cyclone
> operators'), but jonathan felt this could potentially cause name clashes
> with user defined abstractions and proposes "cyclone_ops" - one can also
> consider going back to 'nettles' (yikes). One way or another, again,
> touching the cyclone name is the most delicate issue to me, and it's what
> gives me more headaches.
>
> So, yeah, I'd love to hear more opinions, please Derek and Matt, share
> your cents, and anybody else on this list. I'll keep thinking about this in
> the meantime.
>
> cheers
>
> 2017-06-14 15:56 GMT-03:00 Jonathan Wilkes <jancsika at yahoo.com>:
>
>> Actually, let me clarify to avoid a digression--
>>
>> This vote isn't about whether pd-cyclone should accept the pull request.
>>
>> This vote is about whether Purr Data should merge pd-cyclone with the
>> "cyclops" binary name, or
>> the one from the revision with the "cyclone_ops" name.
>>
>> Thanks,
>> Jonathan
>>
>>
>> ------------------------------
>> *From:* Jonathan Wilkes <jancsika at yahoo.com>
>> *To:* Alexandre Torres Porres <porres at gmail.com>
>> *Cc:* Derek Kwan <derek.x.kwan at gmail.com>; "l2ork-dev at disis.music.vt.edu"
>> <l2ork-dev at disis.music.vt.edu>; "brbrofsvl at gmail.com" <
>> brbrofsvl at gmail.com>
>> *Sent:* Wednesday, June 14, 2017 2:51 PM
>> *Subject:* cyclone merge resolution (Re: [L2Ork-dev] updating cyclone)
>>
>> Hi everyone,
>> I've got a pull request open on pd-cyclone to change the name of the
>> binary for loading the ops.
>>
>> You can read about it here:
>> https://github.com/porres/pd-cyclone/pulls
>>
>> I want to know if it should be accepted before I merge pd-cyclone into
>> Purr Data and make the next release.
>>
>> Albert, Ico, Alexandre, Matt, Derek? How do you vote?
>>
>> I abstain.
>>
>> -Jonathan
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20170614/13a9d7f3/attachment.html>