From: Gour <gtk...@at...> - 2005-03-06 18:58:25
|
Hi! I'm forwarding this web-stuff discussion to the list ;) > How about we start with simply one album for the ordinary screenshots > and one for the tutorial. (Perhaps all the variations on the HRay > screenshots should go in a sub-album) So, shall we go 1st installing Gallery on the site? Then, we can proceed as you propose: two albums. If you like, I can install Gallery and then you can create albums? > > Well, if we only display Announcement posts on the 'News' page, then > > e.g. 'customizable-post-listings' from above can help visitors to orient > > better what's going on. (see the link under 1) > > You mean only announcements in the news page but the sidebar shows other > recent posts in other categories (like FAQ and screenshots)? No, I meant that only 'Announcement' posts are displayed as posts, while the rest - screenshots posts, FAQ... are showed as a categories on the sidebar. > So I was assuming that 'Screenshots' will be like 'News' but just > display posts from the screenshots category, and 'News' would be kept > how it is now - just showing announcements. Then, we hav eto modify WP a bit. > So we could have something in between and have a static screenshots page > that links to the gallery and the screenshots category archive. That's > the same as the documentation page that links to the FAQ archive. Under > that scheme the Screenshots page should probably also have thumbnails to > two or three "best of" pictures just for the quick initial impression. > > So how about that as a solution? Let me summarise: Sounds good. I think I recently discovered some plugin for handling archives... > > Screenshots page looks like: > > <h2>Screenshots</h2> > > [foo1.png] Best of pic 1 > > [foo2.png] Best of pic 2 > > More recent screenshots are here [linking to Screenshots > category archive]. > > You can browse the full collection of screenshots including > those from the tutorial in our gallery [linking to the gallery]. > > This should fit all on one screen without scrolling. That should be easy, i.e. no need for any WP tweaking. > If we split the screenshots into application screenshots vs. screenshots > of demos that are included in the source tarball, then we could have two > categories or a demos subcategory. In that case we'd have two sentances > and two links eg: > > More recent screenshots are here [linking to Screenshots > category archive]. > > There are also screenshots of the demo programs that are > included in the source download [linking to Screenshots/Demos > sub-category archive] That is also nice and does not add any complexity in the present setup :-) > > Then we should tweak the "Screenshots" to present "the best of" ? > > > Or it can be just a static page which needs some modificaiton from time > > to time? > > Yes, or the blogroll format. You mean just a blog format, no real blog? > > As I wrote above, 'News' can contain posts in 'Screenshots' category (we > > need a new category) which can be browsed, while 'Screenshots' can have > > 'best of' with the link to the gallery. > > I think it would be better to keep the news page to be just > announcements like releases, distro packages and other news-like stuff. > I think the screenshots posts should go under the Screenshots page. I thought only about displaying 'Screenshot' category on the sidebar. Visitors first come to the 'News' page and there they can see 'Screenshots' menu as well as 'Screenshots' category on the sidebar, although we can easily disable it on the sidebar. > > We can see what Axel thinks. Sure. > If the screenshots don't go in the news section then between the two > options of a screenshots blogroll (with a sticky post linking to the > full gallery) or a static page with just the "best of" I think I'd go > for the blogroll format. OK. I'll also investigate the possibility to have two separate blogs - one for 'News' and another for 'Screenshots' - it's definitely possible, the only question is 'how' ;) > It allows the <!--more--> thing so that you can present a thumbnail or > two and have the dscription in the full post. Also it means it follows a > recent to older screenshots order which is familiar. Right. > For example see the wxHaskell screenshots page: > > http://wxhaskell.sourceforge.net/applications.html > Ohh...I didn't visited the site for quite some time :-) > It's structured like a blog post format (though each post is in full > so it's harder to see many screenshots at a glance). Interestingly > they split their demo screenshots into a seperate page which is > probably a good idea. Yes, although I think that logical is to have just application (there are probably candidates for 'best of' section) and tutorial's pics. However, if there is some tutorial pic good enough for 'best of', let us give it a credit :-) > Can one modify a WP post from a command line tool I wonder. It's possible to post via email. See: Options --> Writing --> Writing by e-mail > So we could provide a seperate tutorial for download as well as the > verson on the site. That would be a bonus. Sure. > Yes, writing straight docbook is not nice. I've had to read docbook > xml since that is the format that my code generator reads to produce > the Haddock format markup. > > The txt2tags certainly looks better. Much simpler. I like simplicity :-) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-13 18:22:40
|
On Sun, 2005-03-06 at 19:58 +0100, Gour wrote: > I'm forwarding this web-stuff discussion to the list ;) > > > How about we start with simply one album for the ordinary screenshots > > and one for the tutorial. (Perhaps all the variations on the HRay > > screenshots should go in a sub-album) > > So, shall we go 1st installing Gallery on the site? Yes. I think so. > Then, we can proceed as you propose: two albums. > > If you like, I can install Gallery and then you can create albums? Whichever. > > > Well, if we only display Announcement posts on the 'News' page, then > > > e.g. 'customizable-post-listings' from above can help visitors to orient > > > better what's going on. (see the link under 1) > > > > You mean only announcements in the news page but the sidebar shows other > > recent posts in other categories (like FAQ and screenshots)? > > No, I meant that only 'Announcement' posts are displayed as posts, while > the rest - screenshots posts, FAQ... are showed as a categories on the > sidebar. Right so that's no change from the current setup. (which is nice) > > So I was assuming that 'Screenshots' will be like 'News' but just > > display posts from the screenshots category, and 'News' would be kept > > how it is now - just showing announcements. > > Then, we hav eto modify WP a bit. Let's not do that then. > > So we could have something in between and have a static screenshots page > > that links to the gallery and the screenshots category archive. That's > > the same as the documentation page that links to the FAQ archive. Under > > that scheme the Screenshots page should probably also have thumbnails to > > two or three "best of" pictures just for the quick initial impression. > > > > So how about that as a solution? Let me summarise: > > Sounds good. I think I recently discovered some plugin for handling > archives... How does that change / improve on the existing archive style? > > > > Screenshots page looks like: > > > > <h2>Screenshots</h2> > > > > [foo1.png] Best of pic 1 > > > > [foo2.png] Best of pic 2 > > > > More recent screenshots are here [linking to Screenshots > > category archive]. > > > > You can browse the full collection of screenshots including > > those from the tutorial in our gallery [linking to the gallery]. > > > > This should fit all on one screen without scrolling. > > That should be easy, i.e. no need for any WP tweaking. :-) > > If we split the screenshots into application screenshots vs. screenshots > > of demos that are included in the source tarball, then we could have two > > categories or a demos subcategory. In that case we'd have two sentances > > and two links eg: > > > > More recent screenshots are here [linking to Screenshots > > category archive]. > > > > There are also screenshots of the demo programs that are > > included in the source download [linking to Screenshots/Demos > > sub-category archive] > > That is also nice and does not add any complexity in the present > setup :-) Yep. > > > Then we should tweak the "Screenshots" to present "the best of" ? > > > > > Or it can be just a static page which needs some modificaiton from time > > > to time? > > > > Yes, or the blogroll format. > > You mean just a blog format, no real blog? I wasn't quite sure what I wanted when I wrote that bit. Ignore it. > > > As I wrote above, 'News' can contain posts in 'Screenshots' category (we > > > need a new category) which can be browsed, while 'Screenshots' can have > > > 'best of' with the link to the gallery. > > > > I think it would be better to keep the news page to be just > > announcements like releases, distro packages and other news-like stuff. > > I think the screenshots posts should go under the Screenshots page. > > I thought only about displaying 'Screenshot' category on the sidebar. Right, just as now the FAQ category appears on the sidebar. So no changes necessary. > > If the screenshots don't go in the news section then between the two > > options of a screenshots blogroll (with a sticky post linking to the > > full gallery) or a static page with just the "best of" I think I'd go > > for the blogroll format. > > OK. I'll also investigate the possibility to have two separate blogs - > one for 'News' and another for 'Screenshots' - it's definitely possible, > the only question is 'how' ;) As we've discussed, I don't thik it'll be necessary. > > For example see the wxHaskell screenshots page: > > > > http://wxhaskell.sourceforge.net/applications.html > > > > Ohh...I didn't visited the site for quite some time :-) > > > It's structured like a blog post format (though each post is in full > > so it's harder to see many screenshots at a glance). Interestingly > > they split their demo screenshots into a seperate page which is > > probably a good idea. > > Yes, although I think that logical is to have just application (there > are probably candidates for 'best of' section) and tutorial's pics. What about screenshots of demos that do not appear in the tutorial? > However, if there is some tutorial pic good enough for 'best of', let us > give it a credit :-) Yes, for the 'best of' appearing directly on the Screenshots page (or rather their thumbnail links appearing directly on the Screenshots page) we can pick whatever we like without worrying about any app/demo split. > > Can one modify a WP post from a command line tool I wonder. > > It's possible to post via email. > > See: Options --> Writing --> Writing by e-mail Ok, that allows posts to be sumbitted by email, but what we would want for (semi-)automatically syncing would be the ability to modify an existing page by email/xml-rpc or some automatable tool. Maybe we just have to have someone do it manually. Duncan |
From: Gour <gtk...@at...> - 2005-03-14 06:19:33
|
Duncan Coutts (dun...@wo...) wrote: > > So, shall we go 1st installing Gallery on the site? > > Yes. I think so. OK. > > > Then, we can proceed as you propose: two albums. > > > > If you like, I can install Gallery and then you can create albums? > > Whichever. I'll install Gallery and then you can create albums according to your prefs. > > No, I meant that only 'Announcement' posts are displayed as posts, while > > the rest - screenshots posts, FAQ... are showed as a categories on the > > sidebar. > > Right so that's no change from the current setup. (which is nice) Fine. > > Sounds good. I think I recently discovered some plugin for handling > > archives... > > How does that change / improve on the existing archive style? They are more user-friendly to the user, i.e. it should be easier to browse/search... > Right, just as now the FAQ category appears on the sidebar. So no > changes necessary. True. > > Yes, although I think that logical is to have just application (there > > are probably candidates for 'best of' section) and tutorial's pics. > > What about screenshots of demos that do not appear in the tutorial? Well, when I say 'application' I actually mean 'demo' since it demonstrates gtk2hs features :-) > Yes, for the 'best of' appearing directly on the Screenshots page (or > rather their thumbnail links appearing directly on the Screenshots page) > we can pick whatever we like without worrying about any app/demo split. We can also have a 'best of' album in the Gallery :-) > Ok, that allows posts to be sumbitted by email, but what we would want > for (semi-)automatically syncing would be the ability to modify an > existing page by email/xml-rpc or some automatable tool. Maybe we just > have to have someone do it manually. Hmm..I'm not sure about this one, automatic syncing, but will investigate a bit... Last days I was busy trying to become somewhat familiar with the GNU autoconf tools...probably I'll need them (later :-) 'cause I'd like to make a few bindings for 'my' ephemeris library (it's pretty small) to get some experience before tackling remaining gtk modules. It looks like ghc-6.4 got some speed improvements? Do you know if Gentoo devs plan to make some test-ebuild for ghc-6.4.1 'cause Simon provided support for FFI? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-14 12:51:05
|
On Mon, 2005-03-14 at 07:19 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > I'll install Gallery and then you can create albums according to your > prefs. Ok, give us a shout when it's up and running. No rush though - we're not trying to work you too hard! > > > Sounds good. I think I recently discovered some plugin for handling > > > archives... > > > > How does that change / improve on the existing archive style? > > They are more user-friendly to the user, i.e. it should be easier to > browse/search... Are there any sites which demo that? > > > Yes, although I think that logical is to have just application (there > > > are probably candidates for 'best of' section) and tutorial's pics. > > > > What about screenshots of demos that do not appear in the tutorial? > > Well, when I say 'application' I actually mean 'demo' since it > demonstrates gtk2hs features :-) Ok. :-) > > Yes, for the 'best of' appearing directly on the Screenshots page (or > > rather their thumbnail links appearing directly on the Screenshots page) > > we can pick whatever we like without worrying about any app/demo split. > > We can also have a 'best of' album in the Gallery :-) Could do. At a minimum we'd want > > Ok, that allows posts to be sumbitted by email, but what we would want > > for (semi-)automatically syncing would be the ability to modify an > > existing page by email/xml-rpc or some automatable tool. Maybe we just > > have to have someone do it manually. > > Hmm..I'm not sure about this one, automatic syncing, but will > investigate a bit... I guess it's not so important. We can just do it manually. > Last days I was busy trying to become somewhat familiar with the GNU > autoconf tools... Do you hate them as much as me yet? :-) > probably I'll need them (later :-) Sadly true. > 'cause I'd like to > make a few bindings for 'my' ephemeris library (it's pretty small) to > get some experience before tackling remaining gtk modules. > It looks like ghc-6.4 got some speed improvements? Did it? You mean a registerd port for amd64? > Do you know if Gentoo devs plan to make some test-ebuild for ghc-6.4.1 'cause > Simon provided support for FFI? I would like to do this yes. In fact he's already done the FFI bits if you want to test it. Duncan |
From: Gour <gtk...@at...> - 2005-03-14 13:40:31
|
Duncan Coutts (dun...@wo...) wrote: > Ok, give us a shout when it's up and running. No rush though - we're not > trying to work you too hard! No problem ;) At the moment there is Gallery 1.5RC2 out, so maybe soon there will be a stable release, so I'll wait a bit. > > They are more user-friendly to the user, i.e. it should be easier to > > browse/search... > > Are there any sites which demo that? http://mindfulmusings.net/weblog/narchives.php http://justinblanton.com/archives/ See post at: http://tinyurl.com/49rvk > > Hmm..I'm not sure about this one, automatic syncing, but will > > investigate a bit... > > I guess it's not so important. We can just do it manually. All right. > > Last days I was busy trying to become somewhat familiar with the GNU > > autoconf tools... > > Do you hate them as much as me yet? :-) Not ( yet :-) > > > probably I'll need them (later :-) > > Sadly true. I put my ephemeris library under Gentoo ebuild and would like to bind few functions to test it from Haskell. Can you recommend some 'configure.ac' script for Haskell usage (besides the one in gtk2hs) or better to just strip out unused stuff? > > It looks like ghc-6.4 got some speed improvements? > > Did it? You mean a registerd port for amd64? No, general x86 in comparison with 6.2.2 ? > > Do you know if Gentoo devs plan to make some test-ebuild for ghc-6.4.1 'cause > > Simon provided support for FFI? > > I would like to do this yes. In fact he's already done the FFI bits if > you want to test it. I'd like. Should I checkout from CVS or one can download some nightbuild from somewhere? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-14 15:50:52
|
On Mon, 2005-03-14 at 14:38 +0100, Gour wrote: > At the moment there is Gallery 1.5RC2 out, so maybe soon there will be a > stable release, so I'll wait a bit. Ok. > Can you recommend some 'configure.ac' script for Haskell usage (besides > the one in gtk2hs) or better to just strip out unused stuff? A simpler one is in buddha (is uses automake too). If you're trying to learn the autotools then fair enough, but you might find it easier to try the new cabal build/dist framework that comes with ghc 6.4. As for stuff to remove from the gtk2hs configure.ac. For a simple package you can probably remove most stuff. You probably only need the few bits at the beginning: AC_INIT, AC_INIT_AUTOMAKE, AC_CANONICAL_HOST the "dnl Checks for programs." section and then the bit that detects the version of ghc. > > > It looks like ghc-6.4 got some speed improvements? > > > > Did it? You mean a registerd port for amd64? > > No, general x86 in comparison with 6.2.2 ? Really? I didn't see that mentioned anywhere. What did you see? > > I would like to do this yes. In fact he's already done the FFI bits if > > you want to test it. > > I'd like. Should I checkout from CVS or one can download some nightbuild from > somewhere? Simon had a binary snapshot but the sources will be in CVS. You can probably just copy the ghc/rts/Adjustor.c file into your source tree. Duncan |
From: Gour <gtk...@at...> - 2005-03-14 18:00:35
|
Duncan Coutts (dun...@wo...) wrote: > > Can you recommend some 'configure.ac' script for Haskell usage (besides > > the one in gtk2hs) or better to just strip out unused stuff? > > A simpler one is in buddha (is uses automake too). Thanks. It looks more human :-) > If you're trying to learn the autotools then fair enough, but you might > find it easier to try the new cabal build/dist framework that comes with > ghc 6.4. Well, my aspirations for autotools are just to be 'literate' enough to put together a simple stuff (like I did for ephemeris library :-) And probably I'd need them when making Haskell bindings for it, true? More than that - rather no. The m4 was one of the reasons I escaped into qmail territory :-) How do you like Cabal? I'm sure it's more human than autotools ;) > As for stuff to remove from the gtk2hs configure.ac. For a simple > package you can probably remove most stuff. You probably only need the > few bits at the beginning: AC_INIT, AC_INIT_AUTOMAKE, > AC_CANONICAL_HOST the "dnl Checks for programs." section and then the > bit that detects the version of ghc. Fow writing gtk2hs apps, I'll definitely (try to) use Cabal, but for those bindings for C-libs.. > > No, general x86 in comparison with 6.2.2 ? > > Really? I didn't see that mentioned anywhere. What did you see? It was in some thread (Which FPL) in comp.lang.functional. > Simon had a binary snapshot but the sources will be in CVS. You can > probably just copy the ghc/rts/Adjustor.c file into your source tree. I did and it compiles now. I tried your patch for ghc-6.4 but it didn't apply, so I checkout code from CVS, but it looks it is not compilable? Now, I patched the original 0.9.7-tarball by hand and will try to compile it after ghc finishes. Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-14 18:24:29
|
On Mon, 2005-03-14 at 19:00 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > If you're trying to learn the autotools then fair enough, but you might > > find it easier to try the new cabal build/dist framework that comes with > > ghc 6.4. > > Well, my aspirations for autotools are just to be 'literate' enough to > put together a simple stuff (like I did for ephemeris library :-) > > And probably I'd need them when making Haskell bindings for it, true? When adding stuff to gtk2hs there are some autoconf/automake bits that need to be changed. Mostly they're pretty small and one can follow the existing pattern. > How do you like Cabal? > > I'm sure it's more human than autotools ;) I've not actually tried it yet but it seems to be "the future". It's not up to doing something as complex as gtk2hs yet. > Fow writing gtk2hs apps, I'll definitely (try to) use Cabal, but for > those bindings for C-libs.. I'm not sure how good the cabal support for libs that do FFI stuff is. > > Simon had a binary snapshot but the sources will be in CVS. You can > > probably just copy the ghc/rts/Adjustor.c file into your source tree. > > I did and it compiles now. > > I tried your patch for ghc-6.4 but it didn't apply, It should apply against the released 0.9.7. What goes wrong? > so I checkout code from CVS, but it looks it is not compilable? Really? We try to keep the cvs version buildable at all times. What goes wrong? Is it autoreconf that complains or something else? > Now, I patched the original 0.9.7-tarball by hand and will try to > compile it after ghc finishes. Did I mess up the preperation of the patch perhaps? Duncan |
From: Gour <gtk...@at...> - 2005-03-14 19:39:14
|
Duncan Coutts (dun...@wo...) wrote: > > And probably I'd need them when making Haskell bindings for it, true? > > When adding stuff to gtk2hs there are some autoconf/automake bits that > need to be changed. Mostly they're pretty small and one can follow the > existing pattern. I was also thinking about bindings for ephemeris library. > > How do you like Cabal? > > > > I'm sure it's more human than autotools ;) > > I've not actually tried it yet but it seems to be "the future". It's not > up to doing something as complex as gtk2hs yet. Is it planned to enhance it? > > Fow writing gtk2hs apps, I'll definitely (try to) use Cabal, but for > > those bindings for C-libs.. > > I'm not sure how good the cabal support for libs that do FFI stuff is. It looks natural to enhance support 'cause FFI is here to stay :-) > It should apply against the released 0.9.7. What goes wrong? 1st change in the patch did not apply cleanly. > Really? We try to keep the cvs version buildable at all times. What goes > wrong? Is it autoreconf that complains or something else? Yes, it could be something with the autotools. > > > Now, I patched the original 0.9.7-tarball by hand and will try to > > compile it after ghc finishes. > > Did I mess up the preperation of the patch perhaps? After emerging of ghc-6.4 finished, I get the following error (reported to ghc-bugs): [...] make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' if test -f glib/glib.precomp; then :; else make glib/glib.precomp; fi; make[2]: Entering directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' /var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7/tools/c2hs/c2hsLocal +RTS -H300m -M350m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' --precomp=glib/glib.precomp glib-object.h elapsed time: 0.00 (start) elapsed time: 0.00 (about to parse headder) elapsed time: 3.11 (about to serialise header) c2hsLocal: internal error: scavenge_mark_stack: unimplemented/strange closure type -1780819864 @ 0x2a95dad118 Please report this as a bug to gla...@ha..., or http://www.sourceforge.net/projects/ghc/ make[2]: *** [glib/glib.precomp] Error 254 make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' make[1]: *** [glib/System/Glib/Types.hs] Error 2 make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' ghc-6.4: can't find file `glib/System/Glib/Types.hs' make: *** [glib/libHSglib_a.deps] Error 1 make: *** Deleting file `glib/libHSglib_a.deps' Now, I recall that I got this error: 'can't find file `glib/System/Glib/Types.hs'. Do you have any idea? My delight to get amd64 support was a short-lasting one :-( Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-15 15:59:30
|
On Mon, 2005-03-14 at 20:38 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > > And probably I'd need them when making Haskell bindings for it, true? > > > > When adding stuff to gtk2hs there are some autoconf/automake bits that > > need to be changed. Mostly they're pretty small and one can follow the > > existing pattern. > > I was also thinking about bindings for ephemeris library. > > > > How do you like Cabal? > > > > > > I'm sure it's more human than autotools ;) > > > > I've not actually tried it yet but it seems to be "the future". It's not > > up to doing something as complex as gtk2hs yet. > > Is it planned to enhance it? They're starting with the simple stuff. I beleive it is possible to wrap an existing configure+Makefile based build system as a Cabal package. > > Really? We try to keep the cvs version buildable at all times. What goes > > wrong? Is it autoreconf that complains or something else? > > Yes, it could be something with the autotools. If it's the error you give below then it's the ghc rts problem. You could try using the overlay that people use when building on machines with low memory. The hope is that since the ghc rts only seems to go wrong on amd64 with longer running programs or ones that use lots of heap, if we can get past the .precomp generation phase all the other invocations of c2hs are pretty short running and don't use much memory. However you would need to make the following change: tools/c2hs/base/general/Binary.hs, line 84 change #define SIZEOF_HSINT SIZEOF_VOID_P to #define SIZEOF_HSINT 4 Then rebuild c2hsLocal. This will unsure that it is compatible with the binary format of the .precomp files in those overlay tarballs. > Now, I recall that I got this error: > > 'can't find file `glib/System/Glib/Types.hs'. > > > Do you have any idea? Not sure, if you can get past the c2hs problem, post the tail of the build log showing the error message. Duncan |
From: Gour <gtk...@at...> - 2005-03-15 18:18:35
|
Duncan Coutts (dun...@wo...) wrote: > They're starting with the simple stuff. I beleive it is possible to wrap > an existing configure+Makefile based build system as a Cabal package. Yes, I read about it. There is some support for autools-ed packages. > If it's the error you give below then it's the ghc rts problem. > > You could try using the overlay that people use when building on > machines with low memory. > The hope is that since the ghc rts only seems to go wrong on amd64 with > longer running programs or ones that use lots of heap, if we can get > past the .precomp generation phase all the other invocations of c2hs are > pretty short running and don't use much memory. Are you kidding? 1GB is not enough? > > However you would need to make the following change: > > tools/c2hs/base/general/Binary.hs, line 84 > > change > #define SIZEOF_HSINT SIZEOF_VOID_P > to > #define SIZEOF_HSINT 4 > > Then rebuild c2hsLocal. This will unsure that it is compatible with the > binary format of the .precomp files in those overlay tarballs. OK. I'll try that (after finishing some other stuff). Will report back. > Not sure, if you can get past the c2hs problem, post the tail of the > build log showing the error message. OK. Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Gour <gtk...@at...> - 2005-03-16 12:43:56
|
Duncan Coutts (dun...@wo...) wrote: > You could try using the overlay that people use when building on > machines with low memory. I did try with: ./configure --disable-gnome --disable-mozilla make HSTOOLFLAGS="-H50m -M100m" > The hope is that since the ghc rts only seems to go wrong on amd64 with > longer running programs or ones that use lots of heap, if we can get > past the .precomp generation phase all the other invocations of c2hs are > pretty short running and don't use much memory. > > However you would need to make the following change: > > tools/c2hs/base/general/Binary.hs, line 84 > > change > #define SIZEOF_HSINT SIZEOF_VOID_P > to > #define SIZEOF_HSINT 4 ...and did this change. There is defnite proress with this step(s), but it fails with: [...] make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' if test -f glib/glib.precomp; then :; else make glib/glib.precomp; fi; make[2]: Entering directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' ./tools/c2hs/c2hsLocal +RTS -H50m -M100m -RTS -C-I/usr/include/glib-2.0 -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' --precomp=glib/glib.precomp glib-object.h elapsed time: 0.00 (start) elapsed time: 0.00 (about to parse headder) c2hsLocal: internal error: update_fwd: unknown/strange object -1780888016 Please report this as a bug to gla...@ha..., or http://www.sourceforge.net/projects/ghc/ make[2]: *** [glib/glib.precomp] Error 254 make[2]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' make[1]: *** [glib/System/Glib/Types.hs] Error 2 make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' ghc-6.4: can't find file `glib/System/Glib/Types.hs' make: *** [glib/libHSglib_a.deps] Error 1 make: *** Deleting file `glib/libHSglib_a.deps' Again, this could be (maybe) interesting for Simon. Do you think it's worth to report a bug to ghc devs? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-16 13:40:33
|
On Wed, 2005-03-16 at 13:41 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > ...and did this change. > > There is defnite proress with this step(s), but it fails with: > ./tools/c2hs/c2hsLocal +RTS -H50m -M100m -RTS -C-I/usr/include/glib-2.0 > -C-I/usr/lib/glib-2.0/include --cppopts='-include "config.h"' > --precomp=glib/glib.precomp glib-object.h This looks like it's still trying to build the glib/glib.precomp file which should have been in the overlay tarball you unpacked. Just check that the glib/glib.precomp is present and if it is, to get make to treat it as built you could say: $ touch glib/glib.precomp The same applies for the gtk/gtk.precomp file too. > Again, this could be (maybe) interesting for Simon. > > Do you think it's worth to report a bug to ghc devs? Probably not yet. I think Simon is investigating this as we speak (at least he's been trying to build gtk2hs with ghc 6.4). Duncan |
From: Gour <gtk...@at...> - 2005-03-16 14:13:42
|
Duncan Coutts (dun...@wo...) wrote: > This looks like it's still trying to build the glib/glib.precomp file > which should have been in the overlay tarball you unpacked. Just check > that the glib/glib.precomp is present and if it is, to get make to treat > it as built you could say: Ahh...I just modified regular tarball - not the overlay :-( Now I see there is no overlay for 2.6.x and I have 2.6.4 emerged. Any advice for 2.6? (Let me take good rest first, I had some extra work tonight with one web site.) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-16 14:31:21
|
On Wed, 2005-03-16 at 15:13 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > This looks like it's still trying to build the glib/glib.precomp file > > which should have been in the overlay tarball you unpacked. Just check > > that the glib/glib.precomp is present and if it is, to get make to treat > > it as built you could say: > > Ahh...I just modified regular tarball - not the overlay :-( > > Now I see there is no overlay for 2.6.x and I have 2.6.4 emerged. > > Any advice for 2.6? The 2.4 ones should work for 2.6. It's binary compatible after all. I will do some 2.6 ones some time though, it's a good point. Since once we start adding 2.6 widgets you'd have to edit other bits by had to keep it working with the 2.4 overlay files. > (Let me take good rest first, I had some extra work tonight with one web > site.) No Probs. Duncan |
From: Gour <gtk...@at...> - 2005-03-16 18:27:06
|
Duncan Coutts (dun...@wo...) wrote: > The 2.4 ones should work for 2.6. It's binary compatible after all. > > I will do some 2.6 ones some time though, it's a good point. Since > once > we start adding 2.6 widgets you'd have to edit other bits by had to > keep > it working with the 2.4 overlay files. OK. I tried with 2.4. Here is the result: [...] /usr/bin/hsc2hs +RTS -H50m -M100m -RTS -L-optl-lgobject-2.0 -L-optl-lglib-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include --include config.h --include glib-object.h --cc=/usr/bin/ghc --lflag=-no-hs-main glib/System/Glib/GParameter.hsc In file included from glib/System/Glib/GParameter_hsc_make.c:2: /usr/lib/ghc-6.4/include/config.h:4:2: warning: #warning config.h is deprecated; please use ghcconfig.h instead /usr/bin/hsc2hs +RTS -H50m -M100m -RTS -L-optl-lgobject-2.0 -L-optl-lglib-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include --include config.h --include glib-object.h --cc=/usr/bin/ghc --lflag=-no-hs-main glib/System/Glib/StoreValue.hsc In file included from glib/System/Glib/StoreValue_hsc_make.c:2: /usr/lib/ghc-6.4/include/config.h:4:2: warning: #warning config.h is deprecated; please use ghcconfig.h instead make[1]: Nothing to be done for `glib/System/Glib.hs'. make[1]: Nothing to be done for `glib/System/Glib/FFI.hs'. make[1]: Nothing to be done for `glib/System/Glib/UTFString.hs'. make[1]: Leaving directory `/var/tmp/portage/gtk2hs-0.9.7/work/gtk2hs-0.9.7' glib/System/Glib/Types.chs:37:29: parse error on input `#' make: *** [glib/libHSglib_a.deps] Error 1 make: *** Deleting file `glib/libHSglib_a.deps' glib/System/Glib/Types.chs:37:29: parse error on input `#' gives: import GHC.Base (unsafeCoerce#) I'm not familiar enough with ghc and changes from 6.2.x --> 6.4 Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-16 19:52:43
|
On Wed, 2005-03-16 at 19:26 +0100, Gour wrote: > OK. I tried with 2.4. > > Here is the result: > glib/System/Glib/Types.chs:37:29: parse error on input `#' > make: *** [glib/libHSglib_a.deps] Error 1 > make: *** Deleting file `glib/libHSglib_a.deps' > > > glib/System/Glib/Types.chs:37:29: parse error on input `#' gives: > > import GHC.Base (unsafeCoerce#) > I'm not familiar enough with ghc and changes from 6.2.x --> 6.4 You need this: *** gtk2hs-0.9.7/mk/common.mk Mon Jan 24 14:02:09 2005 --- gtk2hs-0.9.7-for-ghc-6.4/mk/common.mk Fri Mar 4 00:16:19 2005 *************** *** 66,70 **** $(if $(word 2,$($(PKG)_HSFILES)),\ $(MAKE) $(AM_MAKEFLAGS) $($(PKG)_HSFILES); \ ! $(HC) -M $(addprefix -optdep,-f $@) \ $(HCFLAGS) $($(PKG)_HCFLAGS) -i$(pkgVPATH) \ $(AM_CPPFLAGS) $($(PKG)_CPPFLAGS) $($(PKG)_HSFILES);) \ --- 66,70 ---- $(if $(word 2,$($(PKG)_HSFILES)),\ $(MAKE) $(AM_MAKEFLAGS) $($(PKG)_HSFILES); \ ! $(HC) -M $(addprefix -optdep,-f $@) -fglasgow-exts \ $(HCFLAGS) $($(PKG)_HCFLAGS) -i$(pkgVPATH) \ $(AM_CPPFLAGS) $($(PKG)_CPPFLAGS) $($(PKG)_HSFILES);) \ I've not committed this since we're working on a better fix. Duncan |
From: Gour <gtk...@at...> - 2005-03-17 18:58:35
|
Duncan Coutts (dun...@wo...) wrote: > You need this: > > *** gtk2hs-0.9.7/mk/common.mk Mon Jan 24 14:02:09 2005 > --- gtk2hs-0.9.7-for-ghc-6.4/mk/common.mk Fri Mar 4 00:16:19 [...] > I've not committed this since we're working on a better fix. The error is WITH this patch applied :-( Any new idea? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-17 23:49:08
|
On Thu, 2005-03-17 at 19:58 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > You need this: > > > > *** gtk2hs-0.9.7/mk/common.mk Mon Jan 24 14:02:09 2005 > > --- gtk2hs-0.9.7-for-ghc-6.4/mk/common.mk Fri Mar 4 00:16:19 > > [...] > > > I've not committed this since we're working on a better fix. > > The error is WITH this patch applied :-( > > Any new idea? After applying the patch you run make again. However for some reason this does not update the Makefile before running it again. So it still fails on the first run. If you run make again however it works (at least for me). Duncan |
From: Axel S. <A....@ke...> - 2005-03-18 09:29:30
|
On Thu, 2005-03-17 at 23:50 +0000, Duncan Coutts wrote: > On Thu, 2005-03-17 at 19:58 +0100, Gour wrote: > > Duncan Coutts (dun...@wo...) wrote: > > > > > You need this: > > > > > > *** gtk2hs-0.9.7/mk/common.mk Mon Jan 24 14:02:09 2005 > > > --- gtk2hs-0.9.7-for-ghc-6.4/mk/common.mk Fri Mar 4 00:16:19 > > > > [...] > > > > > I've not committed this since we're working on a better fix. > > > > The error is WITH this patch applied :-( > > > > Any new idea? > > After applying the patch you run make again. However for some reason > this does not update the Makefile before running it again. So it still > fails on the first run. If you run make again however it works (at least > for me). We have quite a lot of rules that update dependency files which are executed before updating the Makefiles. It's inconvenient if the build doesn't go through, but I guess there is no way we can convince automake (or even GNU make) to behave differently. Axel. |
From: Gour <gtk...@at...> - 2005-03-18 12:56:46
|
Duncan Coutts (dun...@wo...) wrote: > After applying the patch you run make again. However for some reason > this does not update the Makefile before running it again. So it still > fails on the first run. If you run make again however it works (at least > for me). OK. I'll try again, although I put patched version in my portage tree, expanded it and tried. Let me see...it doesn't work here :-( Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-22 15:33:49
|
On Tue, 2005-03-22 at 09:05 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > Yes, just this weekend. :-) All working. > > Huh..now I'm really interested. > > Does c2hs (0.13.4) also works? No. I get the same problems as you. Or do you mean the ebuild for Manuels original version (as opposed to gtk2hs's c2hs fork)? I've not tried the c2hs ebuild yet. > > I've managed to get gtk2hs to build (but not yet install) with ghc 6.4 > > (SimonM's binary snapshot) > > Is it a newer one? Nope. I get the same rts issues. I have to use the binary .precomp files. > > I'll try this again with the current cvs version (as opposed to my own > > tree with its various modifications) and provide details. > > Thanks a lot. I'm really eager to move forward :-) I've added the last bit of the 6.4 patch (temporarily untill we fix c2hs) so there's no patching required Right, here's the detailed instructions: $ cvs -d:pserver:ano...@cv...:/cvsroot/gtk2hs login (no password just press enter) $ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/gtk2hs co -P gtk2hs (the following few commands are required as a workaround for ghc's amd64 issues) $ wget http://gtk2hs.sourceforge.net/gtk2hs-0.9.7-lowmem-overlay-gtk-2.4.tar.gz $ tar -xzf gtk2hs-0.9.7-lowmem-overlay-gtk-2.4.tar.gz $ for dir in gtk2hs-0.9.7/*; do mv $dir/$(basename $dir).precomp gtk2hs/$(basename $dir)/; done $ sed -i 's:SIZEOF_VOID_P:4:' gtk2hs/tools/c2hs/base/general/Binary.hs (resume here for non-amd64) $ cd gtk2hs $ autoreconf -i $ ./configure --with-hc=ghc-6.4 --disable-mozilla $ make note that make install will not yet work. We need to add .cabal files since ghc 6.4 no longer supports it's previous package format. > btw, Gallery is on RC3-b13 so I hope soon there will be a release. Cool. Duncan |
From: Gour <gtk...@at...> - 2005-03-23 14:21:59
|
Duncan Coutts (dun...@wo...) wrote: > Or do you mean the ebuild for Manuels original version (as opposed to > gtk2hs's c2hs fork)? I've not tried the c2hs ebuild yet. I mean this one 'cause I'd like to bind some functions for that ephemeris library - it is small & relatively simple, so I consider it is a good exercise in Haskell ffi adventure - before jumping to some of the remaining gtk modules :-) > I've added the last bit of the 6.4 patch (temporarily untill we fix > c2hs) so there's no patching required Will the c2hs fix include the official c2hs as well? > Right, here's the detailed instructions: [...] Great. It works :-)) > note that make install will not yet work. We need to add .cabal files > since ghc 6.4 no longer supports it's previous package format. How do you like Cabal so far? Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |
From: Duncan C. <dun...@wo...> - 2005-03-23 15:16:08
|
On Wed, 2005-03-23 at 15:21 +0100, Gour wrote: > Duncan Coutts (dun...@wo...) wrote: > > > Or do you mean the ebuild for Manuels original version (as opposed to > > gtk2hs's c2hs fork)? I've not tried the c2hs ebuild yet. > > I mean this one 'cause I'd like to bind some functions for that > ephemeris library - it is small & relatively simple, so I consider it is > a good exercise in Haskell ffi adventure - before jumping to some of > the remaining gtk modules :-) > > > I've added the last bit of the 6.4 patch (temporarily untill we fix > > c2hs) so there's no patching required > > Will the c2hs fix include the official c2hs as well? It's not a fix to make c2hs work on amd64 or anything like that. It's to make it preserve pragmas at the top of .chs files in the resulting .hs file. > > Right, here's the detailed instructions: > > [...] > > Great. It works :-)) Finally! :-) However it still will not install and run yet... > > note that make install will not yet work. We need to add .cabal files > > since ghc 6.4 no longer supports it's previous package format. > > How do you like Cabal so far? At the moment I'm just annoyed that the older package format has been abruptly dropped with no deprecation period. We're not using the cabal build infrastructure at all yet. That may be a while. We're just using the new cabal package description format. I'm about to commit the first version of cabal support so you should be able to get it to install (after a cvs update; autoreconf; ./configure --with-all-the-normal-options; make) However the demos still will not work on amd64, at least not if your using SimonM's snapshot which although it is a regesterised build doesn't support the dynamic ffi export. I really want to put together an amd64 ghc ebuild with all the necessary patches. I have been thinking about re-doing the callback implementation so that it does not require the ffi dynamic export. One can do it by writing GClosure support for Haskell which is like the technique used by pygtk and other bindings. See http://www.gnome.org/~jamesh/language-bindings/gclosure.html I've got it workign so far for zero arg and one arg closurers that return void, but the marshaling function is totally generic so it should work for all. It uses ghc's RtsAPI.h interface to construct and evaluate the callback IO action. I expect it should be a tad quicker but mainly it uses much less code (since it uses a single marshaling function for all calback types rather than many specialised ones) and it should work on platforms that do not support ffi dynamic export fully (like sparc which can only have 4 arguments in callback functions). Duncan |
From: Gour <gtk...@at...> - 2005-03-23 15:52:03
|
Duncan Coutts (dun...@wo...) wrote: > > Will the c2hs fix include the official c2hs as well? > > It's not a fix to make c2hs work on amd64 or anything like that. It's to > make it preserve pragmas at the top of .chs files in the resulting .hs > file. I understand it's not amd64 fix, but I'm interested if the fix is only in forked version of c2hs (used by gtk2hs project), or will be included in the official c2hs as well? > Finally! :-) > > However it still will not install and run yet... I consider it less challenging task. > > How do you like Cabal so far? > > At the moment I'm just annoyed that the older package format has been > abruptly dropped with no deprecation period. I agree on that - it's a still young project, while the old method was proven in the practice. > We're not using the cabal build infrastructure at all yet. That may be > a while. We're just using the new cabal package description format. It just give package maintainers sone extra work. > I'm about to commit the first version of cabal support so you should be > able to get it to install (after a cvs update; autoreconf; ./configure > --with-all-the-normal-options; make) OK. Thanks. > However the demos still will not work on amd64, at least not if your > using SimonM's snapshot which although it is a regesterised build > doesn't support the dynamic ffi export. I really want to put together an > amd64 ghc ebuild with all the necessary patches. That would be really great. Haskelli-amd64 dept on Gentoo is really starving at the moment ;) > I have been thinking about re-doing the callback implementation so that > it does not require the ffi dynamic export. One can do it by writing > GClosure support for Haskell which is like the technique used by pygtk > and other bindings. See > http://www.gnome.org/~jamesh/language-bindings/gclosure.html I'll take a look, but can you tell me what are the immediate consequences it will have on the whole bindings? > I've got it workign so far for zero arg and one arg closurers that > return void, but the marshaling function is totally generic so it should > work for all. It uses ghc's RtsAPI.h interface to construct and evaluate > the callback IO action. I expect it should be a tad quicker but mainly > it uses much less code (since it uses a single marshaling function for > all calback types rather than many specialised ones) and it should work > on platforms that do not support ffi dynamic export fully (like sparc > which can only have 4 arguments in callback functions). How much time it would require to re-do the current implementation, i.e. do you plan it as pre or post 1.0 taks? (btw, thank you for the above link. It is very useful.) My friend (where I have atmarama.org domain) uses sparc server, so it will be nice to put darcs there :-) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD |