Date: Fri, 22 Dec 2000 07:48:07 +0100 To: Jacques Garrigue Cc: lablgtk at kaba.or.jp Subject: Re: file_selection_complete patch. Message-ID: <20001222074807.A3727 at lambda.u-strasbg.fr> References: <20001218132340.A29055 at lambda.u-strasbg.fr> <20001220125012A.garrigue at kurims.kyoto-u.ac.jp> <20001220091319.B2330 at lambda.u-strasbg.fr> <20001221123306D.garrigue at kurims.kyoto-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20001221123306D.garrigue at kurims.kyoto-u.ac.jp>; from garrigue at kurims.kyoto-u.ac.jp on Thu, Dec 21, 2000 at 12:33:06PM +0900 From: Sven LUTHER Sender: Sven LUTHER On Thu, Dec 21, 2000 at 12:33:06PM +0900, Jacques Garrigue wrote: > From: Sven LUTHER > > > > I often realize that this is not so much a pain to have to write the stub > > > by hand (anyway you need to read the docs to do something nice), but > > > that checking that you forgot nothing is really hard. Particularly > > > when the library itself is also evoluting... > > > > > I understand that, we had the same problem with mlgtk. Automatic or > > semi-automatic translation (or at least stub skeleton writing) is > > the way to go for this. Also gtk+ 2.0 seems to be coming, altough i > > don't know the release date previsions for it. > > I don't see immediately how automatic translation can help here. > My point was that being exhaustive is very difficult, but hard to > automatize. There are several reasons to that. > * since part of the work is done by hand, you can always forget some > function appearing in the C API. Note that automating the stub > generation is not enough to solve it, since you can still forget to > add the method to the class layer. > * in fact there are some choices to be done about which functions and > field to interface to. There are some C functions that are not > needed at the ML level, and you need to access directly some fields > in widgets when no method is available. Only experience can tell > you what is needed and what is not. > * providing access to everything does not seem to be a solution > either, since some C API may be badly unsafe, or require to much > work to wrap. Well, yes, but you could get things like a diagnostic of the interface, with a list all function that are implemented and all function that are not, and have some kind of mechanism for flagging functions as not used, or needing handwork or something such, so as not to have to recheck them later. About adding methods to the class layer, maybe the problem is because your class layer is very high level and not organized in a gtk+ similarity, and also you change method names sometimes. > This doesn't mean that I think that automatic stub generation is > useless. Indeed, this might simplify work, and avoid some bugs due to > inconsistencies between C and ML declarations. But this would not > solve the worst problem, which is that you still have to study the > interface in detail, and follow additions. > > For an interesting example of semi-automatic stub generation you can > see > Manuel Chakravarty, "C -> Haskell or Yet Another Interfacing Tool", > IFL'99, LNCS 1868 > This is the way the Haskell binding for GTK+ was done. > However, while I think this much more safe, it still requires a lot of > manual work. Also, it uses the Haskell FFI, which allows direct access > to C data structures. This is impossible in Caml, and Xavier Leroy > does not seem very keen on adding such a feature. mmm, ... normally gtk+ is made to be easily accessible from all kind of languages, that is why they provide get and set functions for almost any value of the record, or said they would at least. Sometime, they forget them. > > i don't understand you here, when i pass "*.ml" to complete, then > > only the .ml files of the given directory are shown ? Is this not > > how a filter does behave ? > > First it does not show only the .ml files, but actually *.ml*. What about giving it *.ml$ or something such, will be testing ... > Also, it filters directories, which is not what you would > expect from set_filter. And calling set_filename cancels the filter, > so that you cannot use ?filter and ?filename simultaneously. > My conclusion is that it is really not intended to set a filter, but > as its name shows to complete user input. Nice, but different. Ok, now i understand, ... > > I still don't understand the difference, but then if there trully is one, > > maybe be we should send a request for it to the gtk+ guys ? > > Well, yes. > I just didn't do it because I felt lazy about having to discuss the > matter, an hoped that they would realize it for themselves, but since it > is not in 1.3 either, this might be a good idea to tell them. I have no time right now, but if you want, in january i will do it. Friendly, Sven Luther