[PD] lib nilwind: continuation of cyclone 0.2x as fallback provision

[Alexandre Torres Porres]

Em ter., 17 de dez. de 2019 às 17:26, katja <katjavetter at gmail.com>
escreveu:

> Some weeks ago Fred Jan Kraan has reissued cyclone 0.2.1 as 'nilwind'
> on github and deken. It happened upon my request, to enable
> coinstallation of 0.2x with newer versions. Alexandre does a great job
> in preserving backward compatibility (much appreciated!). But the
> library has also been subject to major refactoring which happened
> without publicly visible discussion or documentation of the approach.
> Regressions resulting from this appear hard to solve.
>

Hi, thanks for the compliment, but I need to remind we're a team and Derek
and Matt have done the hardest coding work ;)

I understand the concern and I wanna start by saying I can't see a problem
with this branch/fork. Nonetheless, the main motivation seems to be
"*regressions
that are hard to solve*", and I don't know which cases you mean. The issue
I see is if the description of this project makes such statements when no
examples are given. If there are them, and I won't say it's impossible,
it'd be good to know, so you can present what you're offering, and we could
try and fix them, because we clearly don't have the intention to provide
unstable releases with regression bugs - they should all be reported and
fixed! For the moment, I don't know of any existing regression bug.

I think some unintended regression bugs are common in software development
but we had just two of them I can remember, both have been fixed by the
way. The first one was really silly (just an annoying error in
[mousestate]) and fixed in cyclone 0.4. The last one was actually reported
by you and I had just fixed it right before this email came up. It'll be
part of the next release I'm planing to make as soon as pd 0.51 is out. As
I discussed with IOhannes these days on this list, I said I'm also willing
to support back the capital letters for backwards compatibility.

For this reason it is useful to have old cyclone still at hand as a
> fallback. With nilwind around I could finally release an update of a
> cyclone-dependent project without worrying about stability. Fred Jan
> declared his intention to maintain nilwind for this sort of purpose.
> Serious bugs and issues arising from external conditions may be fixed,
> but behaviour of objects won't be changed otherwise. The lib name says
> it all.
>

Again, no problem with this, but I'd really like to stress I don't see
stability concerns in the current cyclone. As for "serious bugs", we did
take care of countless of them which affected existing 65 objects, not to
mention a newly written documentation that took care of many issues as
well. I could argue this has actually improved stability and not the
contrary. Yesterday I also just fixed an old bug with [active] that was not
a regression of ours and we still have a list of known issues and bugs
(none of which are regressions) to take care of posted in our repository.
Roadmap and planing stuff is also available there. Our project has clearly
lost steam, but it's still alive and I'm planing to try and put a new
release out at least at every Pd Vanilla update.

Renaming a library doesn't automatically resolve name clash of
> individual classes. It is therefore recommended to instantiate objects
> with the library prefix, as [nilwind/<classname>]. This is also how
> cyclone and nilwind help patches instantiate objects.


I think if you do [declare -path libraryname], it will force to load the
object from that library as a priority.

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20191217/eea67406/attachment.html>