On Tuesday 23 April 2013 23:47:49 William S Fulton wrote:

> On 20/04/13 08:35, Geert Janssens wrote:

> > On Friday 19 April 2013 19:28:29 William S Fulton wrote:

> > > On 23/03/13 13:15, Geert Janssens wrote:

> > > > A meta question...

> > > >

> > > >

> > > >

> > > > I have cloned the master repository and have been playing on a

> > > > private

> > > >

> > > > branch for my guile updates.

> > > >

> > > >

> > > >

> > > > I don't think my work is ready yet to be merged into the main repo.

> > > > But

> > > >

> > > > I'd like to publish what I have so far to gather feedback.

> > > >

> > > >

> > > >

> > > > Since I have been working on a private branch so far, it was easy to

> > > >

> > > > rebase my branch to the latest master HEAD. But I read here and there

> > > >

> > > > that rebasing published branches is not really recommended.

> > > >

> > > >

> > > >

> > > > So I wonder what swig's public branch policy is ?

> > >

> > > In the official swig repo, it will be frowned upon to rebase.

> >

> > Understood

> >

> > > > I can push my branch to a cloned git repo, so others can look into it

> > > >

> > > > there or pull it into their own local repos. Can I still rebase it

> > > >

> > > > afterwards without causing too much frustration for other developers

> > > > ?

> > >

> > > For your own clone, you can do what you like. If other people are

> > >

> > > collaborating with you in your repo, then rebasing would be a bad idea.

> > >

> > > How about a private guile dev branch that you merge to a public guile

> > >

> > > dev branch which you advertise for general use?

> > >

> > > > Or should I start merging the master branch into my personal branch

> > > >

> > > > regularly from there on ?

> > >

> > > Yup. Eventually I'd like one patch to apply to master for your initial

> > >

> > > guile update. We could do it via a merge from your repo/branch, but it

> > >

> > > seems that git bisect doesn't like branches, so I'm wondering if we

> > >

> > > should avoid branches and keep the development linear. It seems there

> > >

> > > are two schools of thought on best development practices for git, but

> > > we

> > >

> > > are still learning our way.

> >

> > From some quick search on the internet, it seems that bisect can work

> >

> > perfectly fine with branches (1). But I haven't had real life experience

> > with bisection across branches myself so I'm in no position to actually

> > make statements about best practice. If you like to keep development

> > linear, how about cherry-picking the individual commits on my branch ?

> >

> > I'm currently at 6 commits. Two for the actual introduction of guile 2.0

> > support, one cleanup commit before, one for dropping guile 1.6 support,

> > one for dropping the guile gh interface and the last one to fix the

> > deprecation warnings.

> >

> > Theoretically I could reduce this into one big patch, but that would

> > make it much harder to understand what I actually did and why. So I

> > prefer to keep them in separate commits.

>

> No, that is a nice manageable number of commits for what is a fairly big

> impact change. Perfect!

>

> You update your repo to the HEAD of master as with the latest fixes

> applied, you will probably have a full pass of the test-suite. There are

> a couple of silly warnings which would be nice to fix. If you don't, I

> will fix them as I try keep the number of warnings right down to

> suppress the noise they make.

>

> The nspace feature is missing in all the scripting languages, so don't

> worry about that. One day I'd like this feature finished off for all the

> languages.

>

> Before merging to master, I'd like you to have the Travis builds showing

> green in your github repo. First you should set up Travis on your repo

> which is dead easy, see

> http://about.travis-ci.org/docs/user/getting-started/ Then commit the

> attached .travis.yml patch. Instead of using 'git am', you can simply

> use 'git apply' and use 'git commit --author ...', although I wouldn't

> bother with putting me as the author. It should be clear that the patch

> uses guile-2.0.

>

> The examples probably still need some work though. The 'check' target in

> each needs fixing to run the tests properly... I'm not sure how to run

> guile for the examples which have no runtest in the 'check' target.

>

I can look at those and see what I can improve. But I will have to postphone it a bit. Can this wait until after the integration of guile2 into master ?

 

I'd say that even without runtime tests for all cases, we already have improved quite a lot: all cases compile.

 

> Lastly I have a question about guile scm and gh. What is the difference?

gh is a simplified command set, where scm is the full guile api. Both work with the same data structures though.

 

> Does scm supercede gh and is gh going away? If both are important we

> need to configure Travis to test both.

 

gh is going away. The guile project has deprecated it since guile 1.6 and dropped it completely for guile 2.0.

 

My branch will drop gh support in swig as well. swig will only generate scm code on my branch.

 

This is not a problem because as I understand it you can mix scm and gh code. So even if the user writes code using the gh interface it will work with swig files generated using the scm interface.

 

Geert