Is jamomalib.rb doing too much?

[nwolek]

@theod and I had a brief Skype call this morning. It seems that difficulties merging the various branches center around this file:

https://github.com/jamoma/JamomaCore/blob/master/Shared/jamomalib.rb

Changes made by one person inevitably create problems for others. At 2000 lines, this file is doing a lot.

I wanted to start a discussion about how we might better organize the functionality found here. Is cleaning it up enough? Or is the answer to break it up into smaller scripts?

[tap]

Please break it up!

best, | : ||

On Wed, Nov 13, 2013 at 8:33 AM, nwolek notifications@github.com wrote:

@theod https://github.com/theod and I had a brief Skype call this morning. It seems that difficulties merging the various branches center around this file:

https://github.com/jamoma/JamomaCore/blob/master/Shared/jamomalib.rb

Changes made by one person inevitably create problems for others. At 2000 lines, this file is doing a lot.

I wanted to start a discussion about how we might better organize the functionality found here. Is cleaning it up enough? Or is the answer to break it up into smaller scripts?

— Reply to this email directly or view it on GitHubhttps://github.com/jamoma/JamomaCore/issues/181 .

[theod]

please do not forget to introduce @laugre into this discussion because he have worked on the window part.

Best, TO

Le 13 nov. 2013 à 15:37, Timothy Place notifications@github.com a écrit :

Please break it up!

best, | : ||

On Wed, Nov 13, 2013 at 8:33 AM, nwolek notifications@github.com wrote:

@theod https://github.com/theod and I had a brief Skype call this morning. It seems that difficulties merging the various branches center around this file:

https://github.com/jamoma/JamomaCore/blob/master/Shared/jamomalib.rb

Changes made by one person inevitably create problems for others. At 2000 lines, this file is doing a lot.

I wanted to start a discussion about how we might better organize the functionality found here. Is cleaning it up enough? Or is the answer to break it up into smaller scripts?

— Reply to this email directly or view it on GitHubhttps://github.com/jamoma/JamomaCore/issues/181 .

— Reply to this email directly or view it on GitHub.

[blueyeti]

yes thx Théo ! To have worked on windows part I can say that it takes a lot of lines (~700) for itself. Windows doesn't use makefiles as mac and linux, and generate a vcxproj xml file looks heavier than a makefile because visual project requires many properties to work. Windows also differs concerning install paths, / and \ etc... So without want to seem sectarian, should we extract windows part in another ruby script ?

Best, Laurent

[lossius]

I also agree that we could benefit from some major refactoring here. We should probably separate across several files. All subroutines should be documented with some comments at the start, and we have one subroutine (generate_makefile) that is close to 1500 lines. This code should be broken down to a series of subroutines.

I believe all of this would help making it easier for us to understand what's going on in this file, and make it easier to maintain and alter as needed, and it would definitively make it easier to merge the file between different branches.

[nwolek]

@jcelerier - another issue that may be stale now that we are using Cmake?

[tap]

Thanks for raising this topic, Nathan.

I have a many areas of confusion with the current state of Jamoma. I think it would be valuable to clean up as much as possible prior to the workshop next week.

If we have converted to CMake, then I think we need to cut the old system(s). Can we do that?

Also, I have seen things referencing the dev branch in the notifications today. I was under the impression that we were to use the master branch for mainline work now. Perhaps I misunderstood?

Tim

On Wed, Jul 15, 2015 at 3:17 PM, Nathan Wolek notifications@github.com wrote:

@jcelerier https://github.com/jcelerier - another issue that may be stale now that we are using Cmake?

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaCore/issues/181#issuecomment-121751299.

[lossius]

Changing branch procedures requires server work that I have not yet had the time to do, so we are still using dev for all repos except PureData and Ruby implementations. We should not spend time next week towards changing this. Also, ruby build scripts still work and I recommend that we do not change this next week either. We should avoid ending up using all of the workshop on this kind of sysadmin tedious work and rather focus on the topics that really matters when we have the time to meet - Dsp, Graph, Audiograph, SpatDIF and using Jamoma Core with other C++ implementations such as Wdl or Juce for plugins, iOS and OpenFrameworks.

Let's have fun next week - routine work we can do later on remotely!

Best, Trond

Pardon the typos, blame my iPad

On 15 Jul 2015, at 23:31, Timothy Place notifications@github.com wrote:

Thanks for raising this topic, Nathan.

I have a many areas of confusion with the current state of Jamoma. I think it would be valuable to clean up as much as possible prior to the workshop next week.

If we have converted to CMake, then I think we need to cut the old system(s). Can we do that?

Also, I have seen things referencing the dev branch in the notifications today. I was under the impression that we were to use the master branch for mainline work now. Perhaps I misunderstood?

Tim

On Wed, Jul 15, 2015 at 3:17 PM, Nathan Wolek notifications@github.com wrote:

@jcelerier https://github.com/jcelerier - another issue that may be stale now that we are using Cmake?

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaCore/issues/181#issuecomment-121751299.

— Reply to this email directly or view it on GitHub.

[nwolek]

I agree with Trond that we don't want to get bogged down and spend the week on workflow issues. BUT we need to ensure we have a minimum "working workflow" in order to accomplish anything. I have listed a few workflow and testing items on the wiki page (including the branching issue that Tim raises), but I want the bulk of our time and energy to be on the topics Trond lists.

For my part: I am simply sweeping through the list of GitHub issues to see if anything:

• can be easily closed before the workshop
• needs to be on our discussion list for the week
• needs input from some one who will not be attending

That was my reason for adding a quick bump directed at @jcelerier

[tap]

I also agree! This is why I wanted to sort it out now instead of next week. In particular, I wasn't sure how to build Jamoma.

Sounds like I know what to do (hopefully), so that's good enough for me!

Tim

On Wed, Jul 15, 2015 at 8:08 PM, Nathan Wolek notifications@github.com wrote:

I agree with Trond that we don't want to get bogged down and spend the week on workflow issues. BUT we need to ensure we have a minimum "working workflow" in order to accomplish anything. I have listed a few workflow and testing items on the wiki page https://github.com/jamoma/Jamoma/wiki/Workshop-2015-Florida (including the branching issue that Tim raises), but I want the bulk of our time and energy to be on the topics Trond lists.

For my part: I am simply sweeping through the list of GitHub issues to see if anything:

• can be easily closed before the workshop
• needs to be on our discussion list for the week
• needs input from some one who will not be attending

That was my reason for adding a quick bump directed at @jcelerier https://github.com/jcelerier

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaCore/issues/181#issuecomment-121800540.

[jcelerier]

Also, I have seen things referencing the dev branch in the notifications today. I was under the impression that we were to use the master branch for mainline work now. Perhaps I misunderstood?

Sorry, I was not aware ! Is the new workflow outlined in detail somewhere (apart from the workshop page?)

Also, ruby build scripts still work

The commits removing boost haven't updated them, doing this asap so that it still works (for a last commit on dev :) ).

[jcelerier]

Can confirm that with the latest commit ./build.rb passes on dev.

[lossius]

Hi @jcelerier - we agreed on a new workflow at a Jamoma BOD a while back, but it has not been implemented yet. It depends on me and Henrique changes how automatic building happens at the BEK servers, and this we have not had the time to do yet. So please do not alter anything yet, and we'll need Cmake and Ruby to co-exist for a little while longer. Next week some of us meet in Florida for a mostly DSP-related developer workshop. It might be useful to be able to get in touch with you via Skype while we are there, but this we can discuss further on the mailing list.

[nwolek]

The notes from our BOD discussion on branches are here: https://docs.google.com/document/d/1EuCpPJ3L8IdF4mh09JXo2tslNLav3Rt7wplS1Kd9P8w/edit

[tap]

Are we essentially duplicating ourselves with the BEK server automatic builds and Travis CI? Is Travis CI set up for Mac builds? Can our multiple automated build systems be more DRY?

Tim

On Thu, Jul 16, 2015 at 6:49 AM, Nathan Wolek notifications@github.com wrote:

The notes from our BOD discussion on branches are here: https://docs.google.com/document/d/1EuCpPJ3L8IdF4mh09JXo2tslNLav3Rt7wplS1Kd9P8w/edit

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaCore/issues/181#issuecomment-121947441.

[lossius]

Currently, no. It might make sense to move Max builds to travis, but this can be a sprint between me, @hems and Antoine.

Sorry for the typing errors, blame my iPhone

On 16. jul. 2015, at 14.55, Timothy Place notifications@github.com wrote:

Are we essentially duplicating ourselves with the BEK server automatic builds and Travis CI? Is Travis CI set up for Mac builds? Can our multiple automated build systems be more DRY?

Tim

On Thu, Jul 16, 2015 at 6:49 AM, Nathan Wolek notifications@github.com wrote:

The notes from our BOD discussion on branches are here: https://docs.google.com/document/d/1EuCpPJ3L8IdF4mh09JXo2tslNLav3Rt7wplS1Kd9P8w/edit

— Reply to this email directly or view it on GitHub https://github.com/jamoma/JamomaCore/issues/181#issuecomment-121947441.

— Reply to this email directly or view it on GitHub.

[nwolek]

Before we get to far off on this tangent, the original issue is wether to refactor the jamomalib.rb script. If we are moving toward Cmake and Travis CI AND away from Ruby, this seems like a stale issue that should be closed. It's OK to have the two systems exist in parallel for the time being, but we should not put time into refactoring a Ruby build system that we will be phasing out.

Is that assessment right? Or am I misunderstanding the relationship between these two systems?

[lossius]

I agree.

Cheers, Trond

On 16 Jul 2015, at 15:17, Nathan Wolek notifications@github.com wrote:

Before we get to far off on this tangent, the original issue is wether to refactor the jamomalib.rb script. If we are moving toward Cmake and Travis CI AND away from Ruby, this seems like a stale issue that should be closed. It's OK to have the two systems exist in parallel for the time being, but we should not put time into refactoring a Ruby build system that we will be phasing out.

Is that assessment right? Or am I misunderstanding the relationship between these two systems?

— Reply to this email directly or view it on GitHub.

[nwolek]

Closing then.