Re: [PD] some notes for cyclone devs / maintainers

[Jonathan Wilkes via Pd-list]

Just to add a bit on why build complexity is important:I probably wasted 20% of 
my time building the GUI port on OSX due to the complexity of the flext build 
system.  
And apparently I am not the only one who views it as voodoo, because the 
externals/Makefile calls 
the flext "build.sh" one more time than the documentation says is necessary.  
(Which, btw, is officially a 
total of 3 calls.)

I say "waste" because I still don't have a working version of flext in the app 
bundle.  Of course if I can 
actually get it to work, I'll just leave it there and probably never touch it 
again like the rest of the Pd-extended 
build monstrosity. :)

So a simple build process is worth its weight in gold.  More than that, a 
non-standard build system is a good 
filter for keeping new code out of the ecosystem-- both because it's too 
tedious to use, and too complex for the 
community to maintain.  (Where non-standard is anything other than autotools or 
make with the usual 
targets.)

-Jonathan

On Wednesday, February 24, 2016 2:08 PM, katja  
wrote:
 

 On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
 wrote:
> 2016-02-24 14:17 GMT-03:00 katja :
>>
>> the code was embedded in the programming structure of miXed, together with
>> other libraries and the shared framework (...) Since other libraries in
>> miXed were essentially unmaintained (...) I figured that cyclone's chances
>> for future maintenance would be best if it could be compiled with a build
>> system not relying on Pd-X or miXed as a set of libraries.
>
>
> Makes sense to me.
>
> Well, first, thanks for all the detailed information on how cyclone grew
> into a giant kludge and current issues Katjia. So, It was brought to github
> conserving as many pieces of the original puzzle as possible. But well,
> yeah, seems like depending on old ways and days might be counterproductive
> on the long run as you mentioned.  and it kinda relates to what Miller and
> others were telling about how cyclone should maybe be left alone as it was
> attached to "old ways of doing things", a new rebuild might be a good idea,
> though quite ambitious.

Alexandre, your summary of my notes about cyclone's build systems (old
and new) make a totally different story than I was telling. Cyclone
didn't grow into a kludge, only the build system did. That is now
solved as far as I am concerned.

For the rest: cyclone and it's underlying framework form a
well-structured but never completed body of code. I don't think anyone
suggested to rewrite it, if that is what you mean with 'rebuild'.
Rewriting is ambitious indeed, possibly beyond your imagination. And a
waste of time. Better focus on new functionality, and leave or
delegate maintenance of the existing code base to people who are able
and willing to understand it's structure.

Katja

>
>>
>> Of course it is technically possible to add new classes which don't
>> use the framework functions (...) You can have independent repositories,
>> test / release cycles, and support (...) if the outcome of the discussion is
>> that all must go in one cyclone lib, you could at least organize source tree
>> and build system in such a way that dependencies between categories of
>> classes and underlying framework remain transparent. The build system could
>> be split according to categories of classes so devs can work in relative
>> isolation in between releases.
>
>
> For now, I'm revising all the documentation and painstakingly correcting it
> and testing objects looking for current issues. I've covered one third of
> the audio objects to this moment (26), only 8 have no remarks. This is a
> very time consuming task. I might take a month to recheck all current state
> of objects.
>
> I can propose a new beta release with minor bug fixes right away just for a
> test, keeping things basically the way they already were. There's time to
> think about everything else when this new report of the current state is
> complete.
>
>> here's my recommendation: make use of the new build
>> approach, because dealing with the old kludge of build scripts in
>> miXed won't make you happy in the long run.
>
>
> Agreed, thanks for the notes again.
>
> Cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] some notes for cyclone devs / maintainers

[Samuel Burt]

I just wanted to take a moment to thank the past, present, and future
developers of cyclone (and all the other great libraries I use). I tried
out MaxMSP back around 2000 and was lucky to find a collaborator who was
working with Pure Data. I have never really tried to make compatible
patches between the two and rarely worked with Max since. However, I have
used cyclone quite frequently because some of the objects have been
crucially important to my work over the years. (svf~ ftw!)

Whatever the future of cyclone is, your work has been and will be important.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] some notes for cyclone devs / maintainers

[katja]

On Wed, Feb 24, 2016 at 7:06 PM, Alexandre Torres Porres
 wrote:
> 2016-02-24 14:17 GMT-03:00 katja :
>>
>> the code was embedded in the programming structure of miXed, together with
>> other libraries and the shared framework (...) Since other libraries in
>> miXed were essentially unmaintained (...) I figured that cyclone's chances
>> for future maintenance would be best if it could be compiled with a build
>> system not relying on Pd-X or miXed as a set of libraries.
>
>
> Makes sense to me.
>
> Well, first, thanks for all the detailed information on how cyclone grew
> into a giant kludge and current issues Katjia. So, It was brought to github
> conserving as many pieces of the original puzzle as possible. But well,
> yeah, seems like depending on old ways and days might be counterproductive
> on the long run as you mentioned.  and it kinda relates to what Miller and
> others were telling about how cyclone should maybe be left alone as it was
> attached to "old ways of doing things", a new rebuild might be a good idea,
> though quite ambitious.

Alexandre, your summary of my notes about cyclone's build systems (old
and new) make a totally different story than I was telling. Cyclone
didn't grow into a kludge, only the build system did. That is now
solved as far as I am concerned.

For the rest: cyclone and it's underlying framework form a
well-structured but never completed body of code. I don't think anyone
suggested to rewrite it, if that is what you mean with 'rebuild'.
Rewriting is ambitious indeed, possibly beyond your imagination. And a
waste of time. Better focus on new functionality, and leave or
delegate maintenance of the existing code base to people who are able
and willing to understand it's structure.

Katja

>
>>
>> Of course it is technically possible to add new classes which don't
>> use the framework functions (...) You can have independent repositories,
>> test / release cycles, and support (...) if the outcome of the discussion is
>> that all must go in one cyclone lib, you could at least organize source tree
>> and build system in such a way that dependencies between categories of
>> classes and underlying framework remain transparent. The build system could
>> be split according to categories of classes so devs can work in relative
>> isolation in between releases.
>
>
> For now, I'm revising all the documentation and painstakingly correcting it
> and testing objects looking for current issues. I've covered one third of
> the audio objects to this moment (26), only 8 have no remarks. This is a
> very time consuming task. I might take a month to recheck all current state
> of objects.
>
> I can propose a new beta release with minor bug fixes right away just for a
> test, keeping things basically the way they already were. There's time to
> think about everything else when this new report of the current state is
> complete.
>
>> here's my recommendation: make use of the new build
>> approach, because dealing with the old kludge of build scripts in
>> miXed won't make you happy in the long run.
>
>
> Agreed, thanks for the notes again.
>
> Cheers

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

[PD] some notes for cyclone devs / maintainers

[katja]

Independent from the question who will contribute to cyclone in the
future and whose repository will be considered upstream I'd like to
share a few practical remarks on the build systems. In the old days I
would have sent this to pd-dev list but that may not be seen by
everyone involved now. A conversation can be redirected later.

Just like a library of books is more than a shelf with someone's
favorites, cyclone is more than a collection of Pd classes. For the
user it serves as a bridge between Pd and MaxMSP, but under the hood
it has consistency too, in the form of a specific framework. Pd users
don't need to know about hammer, sickle etc. as an interface to Pd,
but cyclone maintainers can't ignore it.

When Fred Jan started fixing bugs in cyclone, the code was embedded in
the programming structure of miXed, together with other libraries and
the shared framework. I got involved a bit later, with the
self-imposed task to develop a generalized build method for Pd
libraries that could support a complex source tree layout like
cyclone's. Since other libraries in miXed were essentially
unmaintained, with the exception of pddp which was forked inside
Pd-X's source tree earlier, I figured that cyclone's chances for
future maintenance would be best if it could be compiled with a build
system not relying on Pd-X or miXed as a set of libraries.

Cyclone's build system had over the years grown into an impenetrable
web of makefiles in miXed and Pd-X's library root dir. In the time
when Krzysztof Czaja started miXed, gnu make wasn't so '''advanced'''
as nowadays and he used some nifty tricks to design an expandable
build system, which in the end wasn't so expandable because no one
else could understand the tricks.

Today we have slightly more options for meta programming in gnu make,
notably the 'eval' function. The newly developed build method for
cyclone uses Makefile.pdlibbuilder, a generalized helper makefile for
Pd libraries big or small. Of course this helper makefile uses nifty
tricks too which aren't understood by everyone. But the calling
library makefile is transparent. And easily expandable.

An early version of the new build method was committed to SVN. When
IOhannes facilitated decentralization of Pd-extended with svn>git
conversion for all libraries, Fred Jan took cyclone to github for
continued maintenance. Technically speaking it is a fork, and
effectively it got split off from miXed. We've been considerate with
the structure and underlying framework though, conserving as many
pieces of the puzzle as could be put  together. Fred Jan reanimated a
part of cyclone that was lost to oblivion for a some years (nettles).
The makefile gives insight how class files per category relate to
dependencies in hammer, sickle etc.

Of course it is technically possible to add new classes which don't
use the framework functions. There are suggestions to start a new
library for new classes which follow a different code structure.
Indeed a split between classes using the framework and classes not
using it could simplify development. You can have independent
repositories, test / release cycles, and support. Cloning MaxMSP is
ambitious enough to justify division into sub projects. However if the
outcome of the discussion is that all must go in one cyclone lib, you
could at least organize source tree and build system in such a way
that dependencies between categories of classes and underlying
framework remain transparent. The build system could be split
according to categories of classes so devs can work in relative
isolation inbetween releases.

I'm not planning to participate in cyclone development myself, since
Makefile.pdlibbuilder is a big enough project for me to maintain,
apart from my personal Pd work. It is now unknown if cyclone will be
maintained as an individual library in its own repository or in a
larger context like Pd-L2Ork where it is still embedded in miXed. In
any case, here's my recommendation: make use of the new build
approach, because dealing with the old kludge of build scripts in
miXed won't make you happy in the long run.

Katja

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list