g-wrap-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andreas Rottmann
Subject: Re: [MERGE-REQUEST] More robust implementation of `aggregated'
Date: Mon, 09 Jan 2006 15:30:36 +0100
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ludovic Courtès wrote:
> Hello, and happy new year G-Wrappers!  ;-)
> 
> As you might have seen on `guile-devel'[0], relying on object properties
> to implement `gw_wcp_set_dependencies ()' (used for the `aggregated'
> typespec[1]) was not a good idea, given the sloppiness of the GC
> semantics in that area (at least, in the absence of a patch similar to
> the one I proposed).
> 
> So I re-implemented it, in `guile-wct.c', in (i) a more straightforward
> manner and (ii) in a way that doesn't rely on source properties and is
> consequently more robust.  This works by adding a `dependencies' field
> (containing a list of Scheme objects) to the `wrapped_c_pointer_data'
> structure.
> 
> Afterwards, it occurred to me that the `scm_data' field was intended to
> be used for the very same purpose.  Hence the second patch.  The third
> patch adds a little bit of documentation on that topic.
> 
>   patch-16
>       Re-implemented `gw_wcp_set_dependencies ()' in a more robust way.
>   patch-17
>       Removed the `scm_data' field from `wrapped_c_pointer_data' in 
> `guile-wct.c'.
>   patch-18
>       Documentation: added a discussion of the `aggregated' type qualifier.
> 
> To summarize, the `aggregated' typespec functionality is now spread over
> patches 7, 13, 16, 17, 18.
> 
> Andreas: can you please either merge this or speak out if you don't have
> time to do that or if you think that this feature sucks and that you
> don't want to merge it anyway?  :-)
> 
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.

> More generally, there is a number of patches from me that you do not
> have merged yet and I have no idea whether this is due to lack of time
> or disapproval.  I would *really* appreciate if you could merge them, or
> say something, or even both.  ;-)
> 
I've now done a merge of the "easy" patches (i.e. the ones I see no
potential problems with):


Summary: Merged address@hidden/g-wrap--devo--1.9.6 (patch
6,10,11)
Keywords:

Patches applied:

 * address@hidden/g-wrap--devo--1.9.6--patch-6
   Added support for `mark' and `free' in <gw-wct>.

 * address@hidden/g-wrap--devo--1.9.6--patch-10
   Fixed a bug in strings unwrapping on Guile; augmented the doc.

 * address@hidden/g-wrap--devo--1.9.6--patch-11
   Have WCPs honor the `null-ok' typespec; augmented the doc.


In the following there are some comments on the things I eyeballed already:


* patch-3: Restored `typespec-options' in module `(g-wrap)'.

AFAICS, typespec-options has never been exported from (g-wrap); is this
patch really needed?

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

This breaks the API; as currently the main client of G-Wrap is
guile-gnome (besides gnucash, but that uses a compatibility layer, and
is hence not affected). AFAIK, Andy Wingo is planning a guile-gnome
"stable" release soon; I'd say this should definitly go in after the
guile-gnome release (we might want to do a "stable" G-Wrap release at
the same time or shortly before the guile-gnome release). I still have
to check wether the --dev--0 branch is suitable for a stable release or
if there are any major disruptions; at this point the rules for getting
stuff into the next release of G-Wrap are roughly the following:

* 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.

* 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. 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.


> In fact, once we've made some progress on those patches, I think it
> would make sense to release something.  I believe that even
> documentation alone would justify a release.  What do you think?
> 
Indeed; altough only part of your patches can be included in 1.10.x,
there can/should be a parallel unstable/development tree, see above.

Cheers, Rotty
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDwnOM+S/PxQH9W2IRAvRCAJ95UQaXdZDnnsJqkVHZHP8vvHUnfgCeP3yq
4foSCNSDkSiZbAs9WaflwPE=
=InTf
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]