<div dir="ltr">
<p class="gmail-p1"><span class="gmail-s1">> 2017-06-15 4:59 GMT-03:00 Derek Kwan <<a href="mailto:derek.x.kwan@gmail.com">derek.x.kwan@gmail.com</a>>: <span class="gmail-Apple-converted-space"> <br></span></span>> I think my preferred solution, in agreement with Alex, is fixing the<br>> loader to add the greater flexibility needed for Cyclone to work as-is.<br>> (...) This would allow for more flexibility in future Purr Data library<br>> development and if perhaps separable from Purr Data and usable<br>> as a utility for Pd vanilla</p>
<p class="gmail-p1"><span class="gmail-s1">Not sure it is usable in Vanilla, though I can also only see benefits in sorting this out too.</span></p>
<p class="gmail-p1"><span class="gmail-s1">> fixing the behaviour of the loader (...) could potentially be not-so-trivial <br></span>> (...) If it's only a problem with Cyclone (...) I understand it being not such<br>> a high priority fix<span class="gmail-Apple-converted-space"> <br><br></span></p>
<p class="gmail-p1"><span class="gmail-s1">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.</span></p>
<p class="gmail-p2"><span class="gmail-s1"></span>> changing the name of the cyclone binop binary would be the path of<br>> least-resistance and be the most feasible, esp for getting a new stable<br>> purr-data release out in a reasonable amount of time.</p>
<p class="gmail-p1"><span class="gmail-s1">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".</span></p>
<p class="gmail-p2"><span class="gmail-s1"></span><br>> 2017-06-15 13:18 GMT-03:00 Matt Barber <<a href="mailto:brbrofsvl@gmail.com">brbrofsvl@gmail.com</a>>:<br>> The cyclone binops are by now quite stable and unlikely to change, yes?<br><br>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... <span class="gmail-Apple-converted-space"> </span><br><br>> If this is the case, one solution would be to keep the library name cyclone<br>> for vanilla distribution<br><br>with the goal of making it as only such a library, huh? <br><br>> but for compiling cyclone for purr data, a simple script to split the source<br>> file into its constituent hex-named objects might work. It's a kludge and <br>> could cause maintenance problems, but it would avoid all of these naming<br>> issues. Otherwise I feel ambivalent about the whole thing.</p>
<p class="gmail-p1">yeah, it's a quick deal, are we ok with this one?</p><p class="gmail-p1"><br></p><p class="gmail-p1">cheers</p></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-18 12:24 GMT-03:00 Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">
<p class="m_2265834868438564149gmail-p1">> 2017-06-15 4:59 GMT-03:00 Derek Kwan <<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>>: <br>> As far as I understand, hexloader is a utility that allows Pd to load <br>> non-alphanumerically named binary files by their hex-encoded name <br>> equivalents and it doesn't exist for Pd vanilla</p><p class="m_2265834868438564149gmail-p1"><br></p>
</span><p class="m_2265834868438564149gmail-p1"><span class="m_2265834868438564149gmail-s1">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 :( -<span class="m_2265834868438564149gmail-Apple-converted-space"> </span>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.</span></p><span class="">
<p class="m_2265834868438564149gmail-p2"><span class="m_2265834868438564149gmail-s1"></span><br></p>
<p class="m_2265834868438564149gmail-p1"><span class="m_2265834868438564149gmail-s1">> 2017-06-15 4:59 GMT-03:00 Derek Kwan <<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>>:<span class="m_2265834868438564149gmail-Apple-converted-space"> <br></span></span>> On an additional note, we could add the "namespacing" cyclone/myobject<br>> functionality to the binops by the way of class_addcreator and then<br>> passing it gensym("cyclone/==~") for instance.</p>
</span><p class="m_2265834868438564149gmail-p1"><span class="m_2265834868438564149gmail-s1">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!</span></p><p class="m_2265834868438564149gmail-p1"><span class="m_2265834868438564149gmail-s1">cheers</span></p></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-06-18 12:20 GMT-03:00 Alexandre Torres Porres <span dir="ltr"><<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_2265834868438564149m_-5540721872143013723gmail-m_3350280842165929829m_-3150570580975404532gmail-m_1854598796975741050gmail-"><span>Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>> writes:<br></span><span>> 3- make cyclone into a single library named cyclone<br></span></span></blockquote><div><br></div><div>Damn, we got issues with this one I wasn't aware.</div><div><br></div><div>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. </div><div><br></div><div>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.</div></div><div><br></div><div>At least this gives us motivation to turn the current abstractions into objects, what you think derek/matt?</div><span><div><br></div><div><div class="gmail_quote">2017-06-14 17:41 GMT-03:00 Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="color:rgb(0,0,0);font-family:"Helvetica Neue",Helvetica,Arial,"Lucida Grande",sans-serif;font-size:13px"><div id="m_2265834868438564149m_-5540721872143013723gmail-m_3350280842165929829m_-3150570580975404532gmail-m_1854598796975741050gmail-m_-5742559883601406539yui_3_16_0_1_1497470918342_3426"><br></div><div dir="ltr" id="m_2265834868438564149m_-5540721872143013723gmail-m_3350280842165929829m_-3150570580975404532gmail-m_1854598796975741050gmail-m_-5742559883601406539yui_3_16_0_1_1497470918342_6379">It turns out that fixing the libdir loader (or even specifying how it actually works, including edge cases) is a long term project.</div></div></blockquote><div><br></div></div></div></span><div>So, an update:</div><div><br></div><div>1- fix the loader <b>(long term project)</b></div><div>2- get rid of the library binary for purr data</div><div>3- make cyclone into a single binary library <b>(long term project)</b></div><div>4- rename the library</div><div><br></div></div><div class="m_2265834868438564149HOEnZb"><div class="m_2265834868438564149h5"><div class="gmail_extra"><br><div class="gmail_quote">2017-06-15 13:18 GMT-03:00 Matt Barber <span dir="ltr"><<a href="mailto:brbrofsvl@gmail.com" target="_blank">brbrofsvl@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div></div><div class="m_2265834868438564149m_-5540721872143013723HOEnZb"><div class="m_2265834868438564149m_-5540721872143013723h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 3:59 AM, Derek Kwan <span dir="ltr"><<a href="mailto:derek.x.kwan@gmail.com" target="_blank">derek.x.kwan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>> writes:<br>
<br>
> When trying to merge cyclone, the libloader failed, cause we had<br>
> both a path and a library with the same name to load. As I see it,<br>
> the options here are:<br>
> 1- fix the loader<br>
> 2- get rid of the library for purr data (we can have a workaround<br>
> with hexloader, and this would also mean a separate branch)<br>
> 3- make cyclone into a single library named cyclone<br>
> 4- rename the library<br>
<br>
</span>Hello all,<br>
<br>
We've actually been talking about the issues surrounding this in our own<br>
little chat (Alex, Matt, and I).<br>
<br>
If there has to be a renaming, I'm fine with "cyclone_ops" over<br>
"cyclops". It's as bit more transparent as to what it is and what it<br>
does than "cyclops" (because there's "cyclone" right out in front) and<br>
it does potentially eat up less of the possible names available for<br>
library development (although I'd say "cyclops" as a future library name<br>
might not be the best idea due to its similarity to "cyclone" and the<br>
apparently now-extinct Max object cyclops). I can also see the point of<br>
not calling it "cyclops" because of that old object and although I don't<br>
really see it being cloned anymore (although I'm not quite sure what it<br>
did in the first place, admittedly I'm newer to the computer<br>
music/creative coding game than whenever it existed) since the visual<br>
side of things tend to get encompassed by GEM.<br>
<br>
As far as I understand, hexloader is a utility that allows Pd to load<br>
non-alphanumerically named binary files by their hex-encoded name<br>
equivalents and it doesn't exist for Pd vanilla (at least in the default<br>
distribution?). I guess we could potentially package it with Cyclone in<br>
Deken for Pd vanilla use? But then there's the issue with hexloader<br>
coming with every single download of Cyclone (which would be also<br>
unnecessary if a person already had it for some other library). Or if we<br>
don't package it with Cyclone and tell people to download it to use the<br>
binops, that adds an extra, confusing step. Anyways, I don't think this<br>
seems like a good solution. I'd say for a hexloader solution to be<br>
feasible, it should be part of the Pd distribution it's trying to work with.<br>
<br>
I think my preferred solution, in agreement with Alex, is fixing the<br>
loader to add the greater flexibility needed for Cyclone to work as-is.<br>
In my understanding, it basically automates the adding of paths<br>
and loading of binaries and it breaks when we have cyclone the binary<br>
for the binops and cyclone the directory for everything else. Doing<br>
these things manually, at least for Pd vanilla, works and so I think, at<br>
least ideally, that the loader should be able to do the same sorts of<br>
things. This would allow for more flexibility in future Purr Data<br>
library development and if perhaps separable from Purr Data and usable<br>
as a utility for Pd vanilla, maybe it could be a good way to<br>
"Pd-extendize" the Pd vanilla experience, which I think a lot of users<br>
would appreciate.<br>
<br>
I could, however, see that fixing the behiavor of the loader with this<br>
greater flexibility could potentially be not-so-trivial (esp getting it<br>
to work cross-platform) and take a quite a bit of work. If it's only a<br>
problem with Cyclone and a few other libraries (or even just Cyclone),<br>
I understand it being not such a high priority fix and not worth the effort<br>
in the short term. Thus, changing the name of the cyclone binop binary<br>
would be the path of least-resistance and be the most feasible, esp for<br>
getting a new stable purr-data release out in a reasonable amount of<br>
time.<br>
<br>
On an additional note, we could add the "namespacing" cyclone/myobject<br>
functionality to the binops by the way of class_addcreator and then<br>
passing it gensym("cyclone/==~") for instance. I think I remember<br>
reading that in the issue discussion on the repo somewhere?<br>
<span class="m_2265834868438564149m_-5540721872143013723m_-6596953898780480236HOEnZb"><font color="#888888"><br>
Derek<br>
<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>