Re: [MERGE-REQUEST] More robust implementation of `aggregated'

[Ludovic Courtès]

Hi Andreas,

Thanks for your reply!

Andreas Rottmann <address@hidden> writes:

> I've yet to look at these patches; I did not have the time yet to give
> them a serious review; however, since I have now more time on my hands,
> I will finally come around to do so.

Ok, let me know then.

> I've now done a merge of the "easy" patches (i.e. the ones I see no
> potential problems with):

Cool, thanks.

> * patch-3: Restored `typespec-options' in module `(g-wrap)'.
>
> AFAICS, typespec-options has never been exported from (g-wrap); is this
> patch really needed?

I forgot exactly what my motivation was, but you're right: it was never
exported by `(g-wrap)'.  I'll have to look at what made me think so.

> * patch-12: Added an INLINED? arg to the wrap/unwrap CGs; augmented the doc.
>
> This breaks the API;

I don't think so.  If you look at `g-wrap.scm', it defines a variant of
the `wrap-value-cg', `unwrap-value-cg', and `destroy-value-cg' methods
that takes this INLINED? arguments and falls back to the three-argument
method:

  (define-method (wrap-value-cg (type <gw-type>) (value <gw-value>) error-var
                                (inlined? <boolean>))
    ;; This method allows to support `wrap-value-cg' methods that do _not_
    ;; support the INLINED? argument.
    (wrap-value-cg type value error-var))

So it should be ok to call those methods with only 3 args, or to
overload them with only 3 args.

> * Don't break Scheme API
> * Don't break C source compatibility (ABI doesn't matter)
>
> This release 1.10, will serve as the starting point for the 1.10.x
> series, where C and Scheme source compatibility as well as ABI
> compatibility will be guaranteed.

Right.  I believe none of my patches modify the Scheme and C APIs.  The
INLINED? thing as well as the `aggregated' typespec both "augment" the
API, i.e., they modify it in a backward-compatible way.  Does that count
as an acceptable change for the stable branch?

> * patch-14: g-wrap--devo--1.9.6--patch-14
>
> I get conflicts when trying to "replay" this on my --dev--0 branch. This
> is probably due to it depending on earlier patches that touch
> g-wrap.texi.

Yeah, I'm afraid this is the case.  Committing documentation changes in
the same changesets as actual code changes was indeed a bad idea...

> AFAICS, this documentation is perfectly suitable in the
> next release, however (in the sense that it only describes features that
> are already present). I see you are still working on a single branch,
> which makes things like this awkward. It would be really awesome if you
> could sort out (refactor) your patches onto two branches, e.g.:
>
> --dev--1.10: Stable branch: only documentation improvements, bugfixes,
> unintrusive tweaks, ...
>
> --dev--0: On this branch, do the potentially disruptive work (API breaks
> and the like). Merge from --dev--1.10 to get the bugfixes.

I thought we were heading towards 2.0, which would have been the first
stable G-Wrap that uses GOOPS.

Anyway, I'll try to set up those branches soon.

Thanks,
Ludovic.