[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MERGE-REQUEST] More robust implementation of `aggregated'
From: |
Ludovic Courtès |
Subject: |
Re: [MERGE-REQUEST] More robust implementation of `aggregated' |
Date: |
Mon, 09 Jan 2006 16:59:20 +0100 |
User-agent: |
Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) |
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.