Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Axel Simon <Axel.Simon@in...> - 2010-03-13 17:31:29
|
Dear all, this is a first announcement of cabal packages for Gtk2Hs. This is meant for all those who can spare five minutes to check the packages and to improve them. You need to download the following: gtk2hs-buildtools-0.9.tar.gz cairo-0.10.5.tar.gz glib-0.10.5.tar.gz pango-0.10.5.tar.gz gtk-0.10.5.tar.gz from http://www2.in.tum.de/~simona/ . Then install the packages in the given order. The first package will install some executables that are needed for the other packages. Make sure that they land somewhere in your PATH. I'm particularly interested in comments regarding what I need to do to make these cabal files work with other versions of ghc. I've tested the files with 6.10.4. It seems that one has to give a big tree of base-version variants which I clearly have not done yet. Any comments welcome, Axel. P.S.: My effort to cabalize Gtk2Hs has the following motivation: - easier setup for users, fewer complaints, less hassle - building on Windows: I don't have Windows around and hope that a .cabal file will make this "just work" - integration into the Haskell Platform - separation of other packages: I don't have time to maintain all those additional libraries that are already in the Gtk2Hs darcs |
|
From: Matt Arsenault <arsenm2@rp...> - 2010-03-14 02:22:02
|
On Sat, 2010-03-13 at 18:31 +0100, Axel Simon wrote: > Dear all, > > this is a first announcement of cabal packages for Gtk2Hs. This is > meant for all those who can spare five minutes to check the packages > and to improve them. You need to download the following: > > gtk2hs-buildtools-0.9.tar.gz > cairo-0.10.5.tar.gz > glib-0.10.5.tar.gz > pango-0.10.5.tar.gz > gtk-0.10.5.tar.gz > > from http://www2.in.tum.de/~simona/ . Then install the packages in the > given order. The first package will install some executables that are > needed for the other packages. Make sure that they land somewhere in > your PATH. When I try to download any of them, I get errors such as: "You don't have permission to access /~simona/cairo-0.10.5.tar.gz on this server." |
|
From: Andy Stewart <lazycat.manatee@gm...> - 2010-03-14 08:08:34
|
That's will be good, eaiser to install and maintain.
I got error when i download those file:
You don't have permission to access
Perhaps you need change permission to download.
Can you write the detail step that how to convert from darcs to cabal
package?
Then we can help you finish rest libraries.
So we need *split* current darcs repository after convert all libraries?
BTW, i still can't compile pass current darcs version, can you?
-- Andy
Axel Simon <Axel.Simon@...> writes:
> Dear all,
>
> this is a first announcement of cabal packages for Gtk2Hs. This is
> meant for all those who can spare five minutes to check the packages
> and to improve them. You need to download the following:
>
> gtk2hs-buildtools-0.9.tar.gz
> cairo-0.10.5.tar.gz
> glib-0.10.5.tar.gz
> pango-0.10.5.tar.gz
> gtk-0.10.5.tar.gz
>
> from http://www2.in.tum.de/~simona/ . Then install the packages in the
> given order. The first package will install some executables that are
> needed for the other packages. Make sure that they land somewhere in
> your PATH.
>
> I'm particularly interested in comments regarding what I need to do to
> make these cabal files work with other versions of ghc. I've tested
> the files with 6.10.4. It seems that one has to give a big tree of
> base-version variants which I clearly have not done yet.
>
> Any comments welcome,
> Axel.
>
> P.S.: My effort to cabalize Gtk2Hs has the following motivation:
>
> - easier setup for users, fewer complaints, less hassle
> - building on Windows: I don't have Windows around and hope that
> a .cabal file will make this "just work"
> - integration into the Haskell Platform
> - separation of other packages: I don't have time to maintain all
> those additional libraries that are already in the Gtk2Hs darcs
>
>
> ------------------------------------------------------------------------------
> 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
|
|
From: Axel Simon <Axel.Simon@in...> - 2010-03-14 10:29:19
|
On 14.03.2010, at 08:41, Andy Stewart wrote: > That's will be good, eaiser to install and maintain. > > I got error when i download those file: > You don't have permission to access > Perhaps you need change permission to download. Yes, sorry, I've fixed that now. > Can you write the detail step that how to convert from darcs to cabal > package? > Then we can help you finish rest libraries. I will do that. The only problem at the moment is gio for which two type hierarchies need to be generated which my current Setup.hs program can't do. Once I've fixed that, I'll write a demo Cabal file that explains how the other modules can be bound. > So we need *split* current darcs repository after convert all > libraries? Yes, I will probably make sense to split Gtk2Hs in many smaller darcs repositories. I might keep the just published packages in one repository, though. > BTW, i still can't compile pass current darcs version, can you? Yes, but without webkit. The error in Makefile.am might be somewhere in webkit. Axel. > -- Andy > > Axel Simon <Axel.Simon@...> writes: > >> Dear all, >> >> this is a first announcement of cabal packages for Gtk2Hs. This is >> meant for all those who can spare five minutes to check the packages >> and to improve them. You need to download the following: >> >> gtk2hs-buildtools-0.9.tar.gz >> cairo-0.10.5.tar.gz >> glib-0.10.5.tar.gz >> pango-0.10.5.tar.gz >> gtk-0.10.5.tar.gz >> >> from http://www2.in.tum.de/~simona/ . Then install the packages in >> the >> given order. The first package will install some executables that are >> needed for the other packages. Make sure that they land somewhere in >> your PATH. >> >> I'm particularly interested in comments regarding what I need to do >> to >> make these cabal files work with other versions of ghc. I've tested >> the files with 6.10.4. It seems that one has to give a big tree of >> base-version variants which I clearly have not done yet. >> >> Any comments welcome, >> Axel. >> >> P.S.: My effort to cabalize Gtk2Hs has the following motivation: >> >> - easier setup for users, fewer complaints, less hassle >> - building on Windows: I don't have Windows around and hope that >> a .cabal file will make this "just work" >> - integration into the Haskell Platform >> - separation of other packages: I don't have time to maintain all >> those additional libraries that are already in the Gtk2Hs darcs >> >> >> ------------------------------------------------------------------------------ >> 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 > > > ------------------------------------------------------------------------------ > 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@... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
|
From: Andy Stewart <lazycat.manatee@gm...> - 2010-03-14 10:37:11
|
Axel Simon <Axel.Simon@...> writes: > On 14.03.2010, at 08:41, Andy Stewart wrote: > >> That's will be good, eaiser to install and maintain. >> >> I got error when i download those file: >> You don't have permission to access >> Perhaps you need change permission to download. > Yes, sorry, I've fixed that now. Thanks, i will look it. > >> Can you write the detail step that how to convert from darcs to cabal >> package? >> Then we can help you finish rest libraries. > > I will do that. The only problem at the moment is gio for which two type hierarchies need to be > generated which my current Setup.hs program can't do. Once I've fixed that, I'll write a demo Cabal > file that explains how the other modules can be bound. That's be good. Then i can help you binding rest libraries. > >> So we need *split* current darcs repository after convert all libraries? > > Yes, I will probably make sense to split Gtk2Hs in many smaller darcs repositories. I might keep the > just published packages in one repository, though. It's a good idea that split to smaller darcs repository. Then will have more people help to improve gtk2hs. > >> BTW, i still can't compile pass current darcs version, can you? > > Yes, but without webkit. The error in Makefile.am might be somewhere in webkit. Me too, i can compile it before webkit patch. -- Andy > > Axel. > >> -- Andy >> >> Axel Simon <Axel.Simon@...> writes: >> >>> Dear all, >>> >>> this is a first announcement of cabal packages for Gtk2Hs. This is >>> meant for all those who can spare five minutes to check the packages >>> and to improve them. You need to download the following: >>> >>> gtk2hs-buildtools-0.9.tar.gz >>> cairo-0.10.5.tar.gz >>> glib-0.10.5.tar.gz >>> pango-0.10.5.tar.gz >>> gtk-0.10.5.tar.gz >>> >>> from http://www2.in.tum.de/~simona/ . Then install the packages in the >>> given order. The first package will install some executables that are >>> needed for the other packages. Make sure that they land somewhere in >>> your PATH. >>> >>> I'm particularly interested in comments regarding what I need to do to >>> make these cabal files work with other versions of ghc. I've tested >>> the files with 6.10.4. It seems that one has to give a big tree of >>> base-version variants which I clearly have not done yet. >>> >>> Any comments welcome, >>> Axel. >>> >>> P.S.: My effort to cabalize Gtk2Hs has the following motivation: >>> >>> - easier setup for users, fewer complaints, less hassle >>> - building on Windows: I don't have Windows around and hope that >>> a .cabal file will make this "just work" >>> - integration into the Haskell Platform >>> - separation of other packages: I don't have time to maintain all >>> those additional libraries that are already in the Gtk2Hs darcs >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> >> >> ------------------------------------------------------------------------------ >> 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@... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
|
From: Duncan Coutts <duncan.coutts@go...> - 2010-04-01 10:06:12
|
On Sun, 2010-03-14 at 11:29 +0100, Axel Simon wrote: > > So we need *split* current darcs repository after convert all > > libraries? > > Yes, I will probably make sense to split Gtk2Hs in many smaller darcs > repositories. I might keep the just published packages in one > repository, though. Axel, I would suggest not fully splitting the main gtk2hs repository. For the core bits that have the same maintainers and release cycles there is probably very little advantage to splitting. The disadvantage would be that you could not do cross-cutting patches/changes. If you still want to build them all together then you'd need extra management scripts to get all the repositories (see for example the complexity the ghc tree has to deal with by having independent libraries). That said, it may make perfect sense for some of the non-core parts that have obvious maintainers and could have separate releases. Similarly probably it makes sense not to aggregate even more components into the main repo. Duncan |
|
From: Duncan Coutts <duncan.coutts@go...> - 2010-03-26 20:28:57
|
On Sat, 2010-03-13 at 18:31 +0100, Axel Simon wrote: > Dear all, > > this is a first announcement of cabal packages for Gtk2Hs. This is > meant for all those who can spare five minutes to check the packages > and to improve them. This is great Axel. I'm glad you've taken this on (and a bit sorry I never got round to it). Can you let us know what annoyances you've hit in Cabal, so we can make sure they are all filed properly in the Cabal trac and so we can prioritise them appropriately. I expect your main problems are with .chs and .chi files. Both the fact that there is no proper dependency tracking, and the fact that .chi files from one package are not installed, yet needed when processing other packages (how do you get around that btw?). Another thing that I bet is annoying is that cabal-install isn't great for building local collections of interdependent packages. One wants a feature to be able to tell cabal that there are several locally unpacked packages (ie the gtk2hs source tree, one package per subdir) and have cabal build them in order. Similarly, once you've generated tarballs for each package, cabal isn't yet able to easily be told to install a bunch of tarballs and do dep-tracking. I have plans to make cabal-install accept more notions of package, not just the local dir and package names from hackage but also specific dir(s) or specific tarballs. On the "gtk2hs-buildtools" front, that seems like a reasonably way to go. I hope we can pull the c2hs fork out of that at some point however and use the mainline c2hs (even if initially that involves putting some of the gtk2hs syntax quirks into mainline c2hs while gtk2hs migrates to the standard syntax -- or new agreed syntax). Duncan |
|
From: Andy Stewart <lazycat.manatee@gm...> - 2010-04-01 11:08:28
|
Duncan Coutts <duncan.coutts@...> writes: > On Sun, 2010-03-14 at 11:29 +0100, Axel Simon wrote: > >> > So we need *split* current darcs repository after convert all >> > libraries? >> >> Yes, I will probably make sense to split Gtk2Hs in many smaller darcs >> repositories. I might keep the just published packages in one >> repository, though. > > Axel, I would suggest not fully splitting the main gtk2hs repository. > For the core bits that have the same maintainers and release cycles > there is probably very little advantage to splitting. The disadvantage > would be that you could not do cross-cutting patches/changes. If you > still want to build them all together then you'd need extra management > scripts to get all the repositories (see for example the complexity the > ghc tree has to deal with by having independent libraries). I agree with Duncan. Like Duncan said, it's hard to do cross-cutting patches/changes after split repository, speical when upstream Gtk+ do a big change. > > That said, it may make perfect sense for some of the non-core parts that > have obvious maintainers and could have separate releases. Similarly > probably it makes sense not to aggregate even more components into the > main repo. IMO, don't split any component from main repo, because we don't know *split* component will failed when we break code in main repo, until we test it again. It's easier to debugging just *single* repository. Gtk2hs user just need cabal package to install easily. So my point is: "One darcs repository for developer, many smaller cabal package for user". We can add script that rebuild cabal package automatically. Example, have four subdir under repository: gtk, cairo, webkit, vte And it's cabal package is: gtk-0.1, cairo-0.1, webkit-0.1, vte-0.1 If developer change code of `gtk` and `webkit`, the script will rebuild cabal package: gtk-0.2, webkit-0.2 -- Andy |
|
From: Axel Simon <Axel.Simon@in...> - 2010-04-02 09:08:07
|
Hi Duncan, Andy, On Apr 1, 2010, at 12:35, Andy Stewart wrote: > Duncan Coutts <duncan.coutts@...> writes: > >> On Sun, 2010-03-14 at 11:29 +0100, Axel Simon wrote: >> >>>> So we need *split* current darcs repository after convert all >>>> libraries? >>> >>> Yes, I will probably make sense to split Gtk2Hs in many smaller >>> darcs >>> repositories. I might keep the just published packages in one >>> repository, though. >> >> Axel, I would suggest not fully splitting the main gtk2hs repository. >> For the core bits that have the same maintainers and release cycles >> there is probably very little advantage to splitting. The >> disadvantage >> would be that you could not do cross-cutting patches/changes. If you >> still want to build them all together then you'd need extra >> management >> scripts to get all the repositories (see for example the >> complexity the >> ghc tree has to deal with by having independent libraries). > I agree with Duncan. > > Like Duncan said, it's hard to do cross-cutting patches/changes after > split repository, speical when upstream Gtk+ do a big change. Well, I would like to split off as many parts as possible and only keep cairo, pango, glib and gtk together in one repro. The reason is mainly that I want other people to take over ownership of these packages. There are many packages that I have never touched after people have contributed them to Gtk2Hs and I think that splitting these packages off makes more sense. >> >> That said, it may make perfect sense for some of the non-core >> parts that >> have obvious maintainers and could have separate releases. Similarly >> probably it makes sense not to aggregate even more components into >> the >> main repo. > IMO, don't split any component from main repo, because we don't > know *split* > component will failed when we break code in main repo, until we > test it again. I don't see a relationship of packages being in the same repo and packages breaking because of interdependencies. Even if all packages stay in the same repro, I don't normally work on a machine that has all the required libraries installed, so I wouldn't see these packages breaking. > > We can add script that rebuild cabal package automatically. > Example, have four subdir under repository: > gtk, cairo, webkit, vte > > And it's cabal package is: > gtk-0.1, cairo-0.1, webkit-0.1, vte-0.1 > > If developer change code of `gtk` and `webkit`, the script will > rebuild > cabal package: > gtk-0.2, webkit-0.2 I think a script like that would be as easy as for i in gtk cairo; do cabal install; done If you think there should be something more elaborate, then you could add something to the repo. Cheers Axel |
|
From: Andy Stewart <lazycat.manatee@gm...> - 2010-04-02 09:47:09
|
Hi Axel, Axel Simon <Axel.Simon@...> writes: > Hi Duncan, Andy, > > On Apr 1, 2010, at 12:35, Andy Stewart wrote: > >> Duncan Coutts <duncan.coutts@...> writes: >> >>> On Sun, 2010-03-14 at 11:29 +0100, Axel Simon wrote: >>> >>>>> So we need *split* current darcs repository after convert all >>>>> libraries? >>>> >>>> Yes, I will probably make sense to split Gtk2Hs in many smaller darcs >>>> repositories. I might keep the just published packages in one >>>> repository, though. >>> >>> Axel, I would suggest not fully splitting the main gtk2hs repository. >>> For the core bits that have the same maintainers and release cycles >>> there is probably very little advantage to splitting. The disadvantage >>> would be that you could not do cross-cutting patches/changes. If you >>> still want to build them all together then you'd need extra management >>> scripts to get all the repositories (see for example the complexity the >>> ghc tree has to deal with by having independent libraries). >> I agree with Duncan. >> >> Like Duncan said, it's hard to do cross-cutting patches/changes after >> split repository, speical when upstream Gtk+ do a big change. > > Well, I would like to split off as many parts as possible and only keep cairo, pango, glib and gtk > together in one repro. The reason is mainly that I want other people to take over ownership of > these packages. There are many packages that I have never touched after people have contributed > them to Gtk2Hs and I think that splitting these packages off makes more sense. gtk, cairo, pango, glib, gio, those package must be in *one* repository. Otherwise, hard to debugging, because those pacakge reference each other. My worry is, current just *few* activate developer still on maintaining. If split to *many* smaller repository, perhaps author haven't time to maintain. And so many repositories is trouble to refactory code. More repositories need more time to test. >>> >>> That said, it may make perfect sense for some of the non-core parts that >>> have obvious maintainers and could have separate releases. Similarly >>> probably it makes sense not to aggregate even more components into the >>> main repo. >> IMO, don't split any component from main repo, because we don't know *split* >> component will failed when we break code in main repo, until we test it again. > > I don't see a relationship of packages being in the same repo and packages breaking because of > interdependencies. > Even if all packages stay in the same repro, I don't normally work on a machine that has all the > required libraries installed, so I wouldn't see these packages breaking. I always install all packages to avoid user compile failed. :) My mean is just keep *one* repository, we still can split gtk2hs repository with many smaller cabal packages. Author have ownership with his cabal package. One repository make all gtk2hs developers working together, if some package break, other developer can help to fix, even author haven't time. And permission is also a trouble, current, if anyone want to maintain gtk2hs, just need join `gtk2hs`, otherwise, we need join so many repository. Gtk2hs haven't so many developers like Gtk+ Team, maybe split repository not a good idea for current situation. What do you think? Cheers -- Andy |