Menu
▾
▴
wxhaskell-devel
|
From: Eric K. <eri...@gm...> - 2008-02-25 14:18:12
|
Folks, What do you think about postponing official 2.8 support until the next version of wxhaskell? We could release 0.10.x soonish, and document that it only works for wxWidgets 2.4 and 2.6. Or do you think that wxWidgets 2.8 support is actually right around the corner? If not, I'd say that wxhaskell 0.10 should aim for a 'it just works' installation on the default case (vanilla wxWidgets without any special flags; for example, what ships with the system) for Windows, Linux and Mac. I'd especially like for wxhaskell to be easy for Windows users to install and use. The things I'd like to see in wxhaskell 0.11 are - wxWidgets 2.8 support - a better way of dealing with contribs/ (see Jeremy's mail on modularity) - wxc separation (maybe) -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: shelarcy <she...@gm...> - 2008-02-25 15:20:09
|
On Mon, 25 Feb 2008 23:17:50 +0900, Eric Kow <eri...@gm...> wrote: > What do you think about postponing official 2.8 support until the next > version of wxhaskell? We could release 0.10.x soonish, and document > that it only works for wxWidgets 2.4 and 2.6. I think we have a few tasks for releasing new version without supporting 2.8. I know we have 2 important tasks. 1. Add profiling option wxHaskell doesn't support any profiling option, but Cabal does. http://www.haskell.org/ghc/docs/latest/html/Cabal/builders.html#setup-configure-misc This is important for turning performance. So, Anthony Chaumas-Pellet (and I think some people) want to find how to do that. http://www.haskell.org/pipermail/haskell-cafe/2007-May/025681.html And Gtk2Ha supports that. http://www.haskell.org/pipermail/haskell-cafe/2007-May/025727.html 2. Add --enable-split-objs option wxHaskell doesn't support GHC's -split-objs option any profiling option, but Cabal does. Current wxHaskell generates big binary. So I think this is important task, too. Eric, could you add these features? Or we also postpone these tasks to 0.11? Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
|
From: Eric K. <eri...@gm...> - 2008-02-25 15:43:18
|
> wxHaskell doesn't support any profiling option, but Cabal does. You're right. That does sound pretty important. > 2. Add --enable-split-objs option I'm guessing this is relatively easy. I think we should try to do this if it really is just an issue of makefile hacking. Anything more substantial should probably wait for 0.11 -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: shelarcy <she...@gm...> - 2008-02-25 15:36:31
|
On Mon, 25 Feb 2008 23:17:50 +0900, Eric Kow <eri...@gm...> wrote: > If not, I'd say that wxhaskell 0.10 should aim for a 'it just works' > installation on the default case (vanilla wxWidgets without any > special flags; for example, what ships with the system) for Windows, > Linux and Mac. I'd especially like for wxhaskell to be easy for > Windows users to install and use. I can provide Windows binary installer for wxWidgets 2.6.x. I already provide unofficial Windows binary. http://sourceforge.net/project/showfiles.php?group_id=168626&package_id=192360 So I can upload Windows binary when releasing new version of wxHaskell. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
|
From: Jeremy O'D. <jer...@gm...> - 2008-02-25 16:10:48
|
Hi all, On 25/02/2008, Eric Kow <eri...@gm...> wrote: > > Or do you think that wxWidgets 2.8 support is actually right around the corner? I can give you what I have for wxWidgets 2.8 support (I would merge latest patches and ensure it compiles, but have too many work commitments to do any more), if people feel it's essential and/or useful. There are some rough edges, but it works OK(*) on Windows at least. A thing to bear in mind is that wxWidgets 2.8 support definitively breaks support for the 2.4 line. This may be a deal-breaker for those who like to work in ghci. (*) OK == about as well as wxWidgets 2.6.2 > If not, I'd say that wxhaskell 0.10 should aim for a 'it just works' > installation on the default case (vanilla wxWidgets without any > special flags; for example, what ships with the system) for Windows, > Linux and Mac. I'd especially like for wxhaskell to be easy for > Windows users to install and use. > > The things I'd like to see in wxhaskell 0.11 are > - wxWidgets 2.8 support > - a better way of dealing with contribs/ (see Jeremy's mail on modularity) > - wxc separation (maybe) I actually more or less have wxc separation, in a makefile (I have a single makefile for Microsoft and GNU compilers). It's virtually finished, but not tested on all platforms. Again, happy to provide, but this one isn't for the faint-hearted. Let me know if you'd like the 2.8 support - it is in a slightly rough form, but I've only managed to spend a couple of hours on it in the last 3 months, so may be better to 'get it out there'. |
|
From: Eric K. <eri...@gm...> - 2008-02-25 16:48:48
|
Hi Jeremy, (glad to see you're still somewhat around) > I can give you what I have for wxWidgets 2.8 support (I would merge > latest patches and ensure it compiles, but have too many work > commitments to do any more), if people feel it's essential and/or > useful. There are some rough edges, but it works OK(*) on Windows at > least. Please do give us what you have (in any form). Given the rough edges, I'd vote we sit on it until 0.10 is out the door [for example, I can fix conflicts and put in a private darcs repo] and hope for a 0.11 not too long after. Likewise for the wxc stuff. A little dose of conservatism here in the interests of shipping. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: Jeremy O'D. <jer...@gm...> - 2008-02-25 17:07:27
|
On 25/02/2008, Eric Kow <eri...@gm...> wrote: > > Please do give us what you have (in any form). Given the rough edges, > I'd vote we sit on it until 0.10 is out the door [for example, I can > fix conflicts and put in a private darcs repo] and hope for a 0.11 not > too long after. Likewise for the wxc stuff. A little dose of > conservatism here in the interests of shipping. OK - I'll package up what I have, attach some explanation and push it to you. I'll ensure that it at least compiles and does the basics on Windows. Agree that leaving it out to enable early shipping is probably a good move, as there are quite a few changes. Regards Jeremy |
|
From: Eric Y. K. <eri...@gm...> - 2008-02-27 22:34:26
|
> wxHaskell doesn't support GHC's -split-objs option any profiling option, > but Cabal does. I'm sending a quick little patch to let the user pass in flags to GHC. We call the linker ourselves, though, so I guess my patch isn't actually going to help matters? > Current wxHaskell generates big binary. So I think this is important task, too. wxhaskell has a --enable-upx flag. Would that be good enough? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: shelarcy <she...@gm...> - 2008-02-28 06:50:04
|
Hi Eric, On Thu, 28 Feb 2008 07:34:14 +0900, Eric Y. Kow <eri...@gm...> wrote: >> wxHaskell doesn't support GHC's -split-objs option any profiling option, >> but Cabal does. > > I'm sending a quick little patch to let the user pass in flags to GHC. > We call the linker ourselves, though, so I guess my patch isn't actually > going to help matters? No, It isn't. We must tell the linker to link splited objects. -split-objs option generates it in (OutputDir)/(ModuleName)_split directory per moudles. You can see that your own directory or below cabal code. http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/src/Distribution-Simple-GHC.html#getHaskellObjects (OutputDir)/(ModuleName)_split directory has ld.script that describe just INPUT(...). So, I think we must pass that per modules. >> Current wxHaskell generates big binary. So I think this is important task, too. > > wxhaskell has a --enable-upx flag. Would that be good enough? No, that wouldn't. I want to say about executable file, not about library file. This flag and --enable-strip flag mean that using upx to compress wxc library. But I doesn't affect to generate Haskell program size. If we want to do it, to use -split-objs for spliting the single object file, to use -f* options (I don't know this is good for wxHaskell or not), or to use strip for Haskell program. http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-linker http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.html#options-f http://www.haskell.org/ghc/docs/latest/html/users_guide/smaller.html -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
|
From: Eric Y. K. <eri...@gm...> - 2008-03-02 23:43:09
|
On Thu, Feb 28, 2008 at 15:49:45 +0900, shelarcy wrote: > We must tell the linker to link splited objects. > -split-objs option generates it in (OutputDir)/(ModuleName)_split directory per moudles. > You can see that your own directory or below cabal code. > > http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/src/Distribution-Simple-GHC.html#getHaskellObjects > > (OutputDir)/(ModuleName)_split directory has ld.script that describe just INPUT(...). > So, I think we must pass that per modules. I've had a look at this, and I confess that I'm pretty lost. I see that passing -split-objs to GHC causes it to create many tiny .o files per module (one per top-level function, says the manual), in addition to the one .o file for that module. The problem is that I don't really know what we do with them. The one difference I noticed (and that I pounced on) is that it is these files that get put into the libfoo.a archive files. I'm guessing that this is enough because when you pass in a whole bunch of object files as arguments to a linker, the linker is smart enough to ignore any files that are not used at all? Also, I'm guessing that the ld.script stuff is GNU-specific (we don't get them on MacOS X), and that it isn't even neccessary for GNU (it's just an alternative to having a very long list of command line arguments). Anyway, my latest patch shows how I currently understand things. I hope it's progress! > If we want to do it, to use -split-objs for spliting the single object file, > to use -f* options (I don't know this is good for wxHaskell or not), or to > use strip for Haskell program. Well, it seems like using strip is pretty simple advice, and quite helpful in that it shrank the UTF8Sampler from 8M to 4M. But I suppose -split-objs would really make the biggest difference? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
|
From: shelarcy <she...@gm...> - 2008-03-05 03:16:51
|
Hi Eric, On Mon, 03 Mar 2008 08:42:46 +0900, Eric Y. Kow <eri...@gm...> wrote: >> If we want to do it, to use -split-objs for spliting the single object file, >> to use -f* options (I don't know this is good for wxHaskell or not), or to >> use strip for Haskell program. > > Well, it seems like using strip is pretty simple advice, and quite > helpful in that it shrank the UTF8Sampler from 8M to 4M. But I suppose > -split-objs would really make the biggest difference? Windows doesn't have strip in defalt. He must install MinGW or installing strip by hand for to use strip. On the other hand, ghc always has -split-obj option in any platform. Of cource, that can use Windows platfrom too. So I think -split-obj is better than strip. On Mon, 03 Mar 2008 08:42:46 +0900, Eric Y. Kow <eri...@gm...> wrote: >> (OutputDir)/(ModuleName)_split directory has ld.script that describe just INPUT(...). >> So, I think we must pass that per modules. > > (snip) > > The problem is that I don't really know what we do with them. The one > difference I noticed (and that I pounced on) is that it is these files > that get put into the libfoo.a archive files. I'm guessing that this is > enough because when you pass in a whole bunch of object files as > arguments to a linker, the linker is smart enough to ignore any files > that are not used at all? > > Also, I'm guessing that the ld.script stuff is GNU-specific (we don't > get them on MacOS X), and that it isn't even neccessary for GNU (it's > just an alternative to having a very long list of command line > arguments). I see. I don't know why ghc generate ld.script. But I find an problem by linking whole object by ar on Windows platform. I report that in next mail. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X