On Friday 19 April 2013 18:43:45 William S Fulton wrote:

> On 19/04/13 16:29, Geert Janssens wrote:

> > Hi,

> >

> > It took me a while, but I now have a first implementation of guile 2.0

> > support ready for review. It comes in a set of patches which build on

> > one another:

> >

> > 1. make guile scm the primary target ("guile") and guile gh ("guilegh")

> > the secondary one. This is just a precursor to later work.

> >

> > 2. make swig generated code work with guile 2.0

> >

> > 3. drop support for guile 1.6 (as discussed on the mailing list)

> >

> > 4. drop support for the gh interface altogether (as discussed on the

> > mailing list)

> >

> > A few remarks:

> >

> > - not all tests run, but there is no regression. The tests that worked

> > before my guile 2.0 work, still run fine.


> Hi Geert


> Sounds good. If there are no regressions in the test-suite, then that is

> only just a minimal acceptable level as far as I'm concerned. I think if

> we are taking support away for some users using 1.6, we need something

> more as incentive to upgrade.


How about the newly added support for guile 2.0 ;) ?


> Guile is very close to becoming a first

> rate target language - are you willing and able to get it to a stable

> point where it can be classified as such? As far as I'm concerned, this

> is when the test-suite works 100%, even if it is doesn't have many

> runtime tests as long as it passes all C/C++ compilations it is good.

> Once it has got to this state, it is relatively easy to keep it at this

> state. If the test-suite does not work 100%, we can't add it to the

> Travis builds and I'll ignore it and it will just bit rot from neglect

> as it has been.


I'm actually closer to a 100% working test-suite than I thought. I have rebased my work on the current master and together with my own work, the failing test cases are down to 2.


In more detail:

- li_std_map fails to compile. The error is a pure c++/stl related problem, not in the guile interaction. I have sent another mail for this issue yesterday. My c++/stl knowledge is too weak to fix this myself. But if someone can show what the fix should be in pure c++/stl, I do know how to fix the guile module's .i file to get there.

- There is one guile-only test (guile_ext_test). This one fails as well. Again the failure is not in the guile interaction. For this test the build scripts are failing. I have basic autotools knowledge, but apparently insufficient to solve this one. So here as well, I'll need input from people more experienced than me. I'll post a separate message with more details.


Other than these two real failures, two tests generate some compile warnings that may need some attention and nspace support is missing.


> > - When running the tests with guile 2.0, a lot of deprecated warnings

> > will be spewed. I think I can fix most of them, but I'd first like to

> > know if what I have so far is already acceptable for inclusion.


> Fixing test problems should be higher priority, followed shortly by the

> deprecated api updates.


The deprecations turned out to be easy, so these are done already. For the failing tests, I need help. As stated above, the failures are not related to guile interaction at all, but rather to c++/stl and autotools.


> > - I had to rewrite the configure section for guile. The old section

> > depended on guile-config, but this is badly broken for guile 2.0.

> > Instead I now depend on pkg-config to get the necessary information

> > (only required when guile support is requested). I figured this is not

> > really a problem because guile-devel (or guile-dev on some systems)

> > depends on pkg-config already. To run the guile test suite,

> > guile-dev(el) has to be installed anyway.


> As you are doing a wholesale change to Guile and dropping old support,

> feel free to adopt the pkg-config if that is the modern way.


> > Lastly: how do you want me to present the patchset ? A pull request on

> > github ? Attached to mails ?


> I would very much prefer you to develop this on a fork on github, or at

> least use this infrastructure to commit your changes. Once it is ready,

> it can be easily reviewed and merged into master.


I have now published my work on github. You can review or merge from here: