Hi Andy, (let's move this to the -devel list.)
On 18.04.2010, at 17:53, Andy Stewart wrote: >> >> I will do these changes over the weekend and will send out another >> mail with the exact locations of the repositories. If you feel that >> this all is a really bad idea (it certainly is a bad), then please >> shout and maybe there is a better alternative. So, I'm on my way and your new bindings are already obliterated in code.haskell.darcs. For anyone having a copy of the repo, it should be possible to say 'darcs push' and, by answering 'no' to all patches, one should get a list of all patches that need to be obliterated in the local repository. > Axel, below is my plan: > > (1) Waiting you release cabal repository without my new patches. > (2) Convert all sub-directory to cabaling format. > (3) Review my new patches, and filter *simple* correct functions and > push to main repository. > (4) Build incorrect functions *fix list*, and correct those functions. > (5) Update Gtk+ to 2.20 (Spinner widget is very useful...) > > Yes, some complicated functions is incorrect, but not mean all patches > is incorrect, i think most functions is correct, because them generate > by ApiGen, i just did diff work. > > And it's easier to fix my patches than build new patches. > > If you haven't time to fix incorrect functions, i do. > > Of course, i will let you check before i push to main repository. I > will > ask you if i don't know how to binding some complicated fucntions. I am still working on it since there has been a patch in October (!) where you add functions to Notebook. I can't obliterate that since there are too many other patches depending on it. Thus, I'm now working on checking these functions. > BTW, for my *large* patches problem, you can use some TODO tool track > all details in those large patches. > I use Emacs Org-Mode track those details (http://orgmode.org/) > Org-Mode make your life easier, you can try to use it. > Yes, you first patches were very large which makes it quite difficult to start (since you have to fix so much at once). I've re-recorded some of the later patches. > And *Index of new symbols* in Gtk+ Reference Manual will help us judge > which functions is new. My biggest worry is that you have changed the names of some existing functions. I know that I argued that signal names that clash between different modules should be prefixed, but renaming should only be done to signals that are newly bound or that have already clashed before. In this way no user programs can be broken. However, you changed the destroy signal of Object to objectDestroy which will definitely break programs. This is one example. The problem is that it is very hard to tell what other functions have been renamed that way without meticulously looking at each line of a patch. Another problem I've seen is that you've replaced (I think) the Attributes in Pango to the code generated by apiGen. The Attributes in Pango were carefully hand-written and purposely made more friendly to a Haskell programmer. I've also seen similar things happening in GC (graphics contexts). apiGen is only there to help, it's not right in all cases. > I have some spare time on next month. > But i don't know what's your status exactly, then i can adjust my > time on gtk2hs. > > Can you finish all cabal job in this month? Yes, I think I can finish the cabalized version of glib, cairo, pango and gtk (possibly gio since that belongs to the core packages as well). I would like to move all other bindings to their own repositories (except for the Gtk specific demos). I'm sure we can work it out. Since your early patches are very big, I suggest you try to apply my small re-recorded patches that correspond to your last patches. Anything with newForeignPtr_ is bound to be wrong, so feel free to ask how to do the memory management in cases where it's not clear. Cheers, Axel. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
