Message-ID: <4500FFC2.8000502 at rftp.com>
Date: Thu, 07 Sep 2006 22:29:38 -0700
From: Robert Roessler <robertr at rftp.com>
Organization: Robert's High-performance Software
MIME-Version: 1.0
To: Jacques Garrigue <garrigue at math.nagoya-u.ac.jp>
CC: LablGTK List <lablgtk at math.nagoya-u.ac.jp>
Subject: Re: CVS vs "2.6.0" snapshot
References: <4500E708.2090704 at rftp.com> <20060908.140735.88448321.garrigue at math.nagoya-u.ac.jp>
In-Reply-To: <20060908.140735.88448321.garrigue at math.nagoya-u.ac.jp>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Length: 1987

Jacques Garrigue wrote:
> From: Robert Roessler <robertr at rftp.com>
> 
>> I have a few questions vis the current CVS version:
>>
>> 1) is a new snapshot/release imminent?
> 
> No new release immediately, but a snapshot is easy.
> Since there are no planned modifications, yours could be made
> official.
> (Or rather, I will checkout a snapshot for the same date.)

A new snapshot would be welcome, and I assume not just by myself! :)

However, if I understand properly your comments below on the 
"absvalue" checkins, it would seem like everything *but* those changes 
should be included for those who are looking for the latest "stable" 
version?  And this would require some care, since there is a bit of 
overlap in the two checkins.

>> 2) are there known stability (or other) issues with the current CVS?
> 
> Nothing I know.

This is good news, I should think.

>> 3) not to offend by mangling the French language, but could someone 
>> comment on the "raison de etre" for each of the recent checkins 
>> identified by "delay finalization" and "absvalue"? :)
> 
> The first one corrects a bad bug in lablgtk up to 2.6.0, which could
> call some callback during finalization. This is clearly prohibited by
> the GC specification, so this is no surprise that it can cause
> segfaults. Now callbacks are put into a timeout, so they will be called
> by the gtk mainloop sometime later.

This *does* sound like a good idea to have in the copy of LablGTK one 
is using... ;)

> The second change is mostly esthetical. Since I had reports that in
> the past lablgtk bindings contained bugs where Val_int or Int_val were
> forgotten/interverted, I tried to see how the ocaml headers could be
> made a bit more abstract, to prevent this kind of errors. These are
> non-standard headers, and they are intended only for debugging lablgtk
> itself. I didn't find any new bug yet...

Thanks for the quick (and detailed) response, Jacques.

Robert Roessler
robertr@rftp.com
http://www.rftp.com