Menu
▾
▴
wxhaskell-devel
|
From: Jeremy O'D. <jer...@gm...> - 2012-01-02 08:48:26
|
Hi lists, A Happy New Year to all, and with it a chance to talk about some imminent changes in wxHaskell. There is nothing new in this mail for those who follow the wxhaskell-devel list, but for users who are interested in the evolution of the project, I thought this would be a good time to summarise. First, there will be a new release of wxHaskell in the next few days. This is mainly a bugfix edition, but also reinstates some features which were lost with Cabalization. Specifically: - Styled Text Control support - OpenGL support - Support for building on Haskell Platform 2011.4 This will be the last update of wxHaskell to support the wxWidgets 2.8.x releases. Following shortly afterwards, the very exciting news is that a number of people (Dave Tapley in particular) have been putting a lot of work over the last few months towards support of the wxWidgets 2.9 releases. This does introduce a small number of breaking changes as the wxWidgets API has changed in places, but brings with it quite a number of improvements: - wxC is built as a shared library. This means that wxHaskell works in GHCi again, which has been one of the most requested bugfixes over the past 18 months or so. - Support for wxPropertyGrid and associated classes. - Support for the wxWidgets AUI classes. - Support for wxMediaControl. - Removal of legacy use of Eiffel files to generate constant definitions. This is only of interest to developers, but is far cleaner. - Build system improvements to reduce 'unnecessary' rebuilding of source files - again, one for developers. - Support for 64bit OS X platforms. We will make a release of wxHaskell with all of the new features soon after the changes have been merged into the main repository, and have been more fully tested on all of our supported platforms. Best regards Jeremy |
|
From: Eric K. <eri...@gm...> - 2012-01-02 09:22:49
Attachments:
signature.asc
|
On 2 Jan 2012, at 08:48, Jeremy O'Donoghue wrote: > • wxC is built as a shared library. This means that wxHaskell works in GHCi again, which has been one of the most requested bugfixes over the past 18 months or so. Sweet! I've made you and Dave admins to the wxC SF project, just in case you felt it would help to dissociate it from wxHaskell (thereby attracting people from other language bindings, or people who just want to write wxWidgets GUIs in C). The idea could be that wxC would be developed to track wxWidgets, whereas wxHaskell would be trying to keep up with wxC. But maybe this would just be a big distraction. Up to you :-) Also, I imagine that while this brings us closer to wxHaskell in GHCi, we would still need to solve the second start crash? https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=73133&atid=536845 > • Build system improvements to reduce 'unnecessary' rebuilding of source files - again, one for developers. Yay! -- Eric Kow <http://erickow.com> |
|
From: Heinrich A. <apf...@qu...> - 2012-01-02 12:26:24
|
Jeremy O'Donoghue wrote: > Following shortly afterwards, the very exciting news is that a number of > people (Dave Tapley in particular) have been putting a lot of work over the > last few months towards support of the wxWidgets 2.9 releases. This does > introduce a small number of breaking changes as the wxWidgets API has > changed in places, but brings with it quite a number of improvements: > > - wxC is built as a shared library. This means that wxHaskell works in > GHCi again, which has been one of the most requested bugfixes over the past > 18 months or so. Hurray, that promises to be a really happy new year! The bananas will *dance*! Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com |
|
From: Dave T. <dav...@gm...> - 2012-01-04 16:26:22
|
On 2 January 2012 08:48, Jeremy O'Donoghue <jer...@gm...>wrote: > Hi lists, > > A Happy New Year to all, and with it a chance to talk about some imminent > changes in wxHaskell. There is nothing new in this mail for those who > follow the wxhaskell-devel list, but for users who are interested in the > evolution of the project, I thought this would be a good time to summarise. > > First, there will be a new release of wxHaskell in the next few days. This > is mainly a bugfix edition, but also reinstates some features which were > lost with Cabalization. Specifically: > > - Styled Text Control support > - OpenGL support > - Support for building on Haskell Platform 2011.4 > > This will be the last update of wxHaskell to support the wxWidgets 2.8.x > releases. > Thanks for taking care of this last release Jeremy :) > Following shortly afterwards, the very exciting news is that a number of > people (Dave Tapley in particular) have been putting a lot of work over the > last few months towards support of the wxWidgets 2.9 releases. This does > introduce a small number of breaking changes as the wxWidgets API has > changed in places, but brings with it quite a number of improvements: > Just to note again, I've been pushing all my 2.9 dev work here: http://darcsden.com/DukeDave/wxhaskell-dev That branch's wxC configure will fail if wx-config reports a version other than 2.9.x, see readWxConfig in: http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs > > - wxC is built as a shared library. This means that wxHaskell works in > GHCi again, which has been one of the most requested bugfixes over the past > 18 months or so. > - Support for wxPropertyGrid and associated classes. > - Support for the wxWidgets AUI classes. > - Support for wxMediaControl. > - Removal of legacy use of Eiffel files to generate constant > definitions. This is only of interest to developers, but is far cleaner. > - Build system improvements to reduce 'unnecessary' rebuilding of > source files - again, one for developers. > - Support for 64bit OS X platforms. > > We will make a release of wxHaskell with all of the new features soon > after the changes have been merged into the main repository, and have been > more fully tested on all of our supported platforms. > Yes the testing on more platforms is where the emphasis needs to be here. I'm primarily working in Ubuntu, but I did do a small amount of work trying to ensure Windows is supported in my branch. One hurdle I ran in to is that wx-config-win is unmaintained and no longer works with wxWidgets 2.9.x: http://code.google.com/p/wx-config-win/ The good news is that I emailed the old maintainer and he both responded and made me an owner of that project. I just need to make some small changes there, and then we should be able to get wxHaskell building in Windows against 2.9.x, see here: http://code.google.com/p/wx-config-win/issues/detail?id=21 Best regards > > Jeremy > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: Dave T. <dav...@gm...> - 2012-01-04 17:00:18
|
On 2 January 2012 09:22, Eric Kow <eri...@gm...> wrote: > > On 2 Jan 2012, at 08:48, Jeremy O'Donoghue wrote: > > > • wxC is built as a shared library. This means that wxHaskell > works in GHCi again, which has been one of the most requested bugfixes over > the past 18 months or so. > > Sweet! > > I've made you and Dave admins to the wxC SF project, just in case you felt > it would help to dissociate it from wxHaskell (thereby attracting people > from other language bindings, or people who just want to write wxWidgets > GUIs in C). The idea could be that wxC would be developed to track > wxWidgets, whereas wxHaskell would be trying to keep up with wxC. But > maybe this would just be a big distraction. Up to you :-) > Ah, I saw wxC before and assumed the project was dead. As such, in my branch wxc lives entirely under within wxHaskell, here: http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc I do like the idea that wxc is a separate project, upon which wxHaskell depends, however.. When configuring wxcore I use wxc's package info, and so require wxc to be installed by cabal, and I assume it is the intention of the wxC project to be language independent? You can see (and I invite you to comment on) my use of wxc's package info in wxcInstallDir, here: http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxcore/Setup.hs > > Also, I imagine that while this brings us closer to wxHaskell in GHCi, we > would still need to solve the second start crash? > > > https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845<https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=73133&atid=536845> > Well, I just had a look, and that issue seems to have gone away in my darcsden branch! I've added a comment to the tracker. > > > • Build system improvements to reduce 'unnecessary' rebuilding of > source files - again, one for developers. > > Yay! > Oh, one note here: At the moment I'm using Jeremy's getModificationTime on src and obj approach to dependency checking, which he put his hand up to not really being robust enough: https://sourceforge.net/mailarchive/message.php?msg_id=28121303 You can see where this turns up under needsCompiling here in my repo: http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs Now I do actually have a patch sat on my machine which adds better dependency tracking, I alluded to it here: http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html However as I note there it does make wxc dependent on gcc, and now I'm thinking that the perhaps it's better to move to the language independent wxC approach (i.e. away from cabal), and use a make system which does 'real' C++ dependency tracking. Dave, > -- > Eric Kow <http://erickow.com> > > > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAk8Bd14ACgkQBUrOwgisBPkGAwCfdZYMF2brAwOH2rM660Bh1pXN > QHgAn2LdNVkXGIRMGJ0xGAmlDWnQXfej > =2c1B > -----END PGP SIGNATURE----- > > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: Eric K. <eri...@gm...> - 2012-01-04 18:24:08
Attachments:
signature.asc
|
On 4 Jan 2012, at 16:59, Dave Tapley wrote: > Also, I imagine that while this brings us closer to wxHaskell in GHCi, we would still need to solve the second start crash? > > https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845 > > Well, I just had a look, and that issue seems to have gone away in my darcsden branch! > I've added a comment to the tracker. > Wow! If this works, Conal might be pleased. By the way, you mentioned wx-config (I get the feeling you'd asked me a direct question and I forgot to answer). Did you have a look at the Haskell code in our repo which provides a wx-config replacement? The replacement is very very stupid and needs generalising, but it might be easier to bring it closer to the kind of completeness we need than to maintain the C++ one. -- Eric Kow <http://erickow.com> |
|
From: Eric K. <eri...@gm...> - 2012-01-05 12:15:20
Attachments:
signature.asc
|
On 4 Jan 2012, at 16:59, Dave Tapley wrote: > I do like the idea that wxc is a separate project, upon which wxHaskell depends, however.. > When configuring wxcore I use wxc's package info, and so require wxc to be installed by cabal, and I assume it is the intention of the wxC project to be language independent? I think that would help. One hope is that if we had a separate project that tried harder to be language agnostic, and which had none of the trappings of a Haskell project, we might be able to get more help from the wxWidgets team. Make it look like any other project written in C, the basic autotools (or more likely Bakefile as wxWidgets use it), the pkgconfig stuff, etc. Then you can imagine wxc getting into your favourite package manager, like Homebrew. > However as I note there it does make wxc dependent on gcc, and now I'm thinking that the perhaps it's better to move to the language independent wxC approach (i.e. away from cabal), and use a make system which does 'real' C++ dependency tracking. Yup. I'd suggest using whatever wxWidgets use. Note also that the wxWidgets people have in the past brought up Swig and the idea of abusing doxygen to generate the wxC layer. -- Eric Kow <http://erickow.com> |
|
From: Dave T. <dav...@gm...> - 2012-01-05 15:36:37
|
On 4 January 2012 18:23, Eric Kow <eri...@gm...> wrote: > > On 4 Jan 2012, at 16:59, Dave Tapley wrote: > > Also, I imagine that while this brings us closer to wxHaskell in GHCi, > we would still need to solve the second start crash? > > > > > https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845 > > > > Well, I just had a look, and that issue seems to have gone away in my > darcsden branch! > > I've added a comment to the tracker. > > > > Wow! If this works, Conal might be pleased. > It certainly seems to, insomuch as the given test code no longer causes a crash :) > > By the way, you mentioned wx-config (I get the feeling you'd asked me a > direct question and I forgot to answer). Did you have a look at the > Haskell code in our repo which provides a wx-config replacement? The > replacement is very very stupid and needs generalising, but it might be > easier to bring it closer to the kind of completeness we need than to > maintain the C++ one. > Ah, yes, I suspected this would need some debate. I was on the cusp of merging in your wx-config implementation, namely: http://darcsden.com/kowey/wxhaskell/browse/wx-config/ But then I got a reply from the previous project leader wx-config-win: http://code.google.com/p/wx-config-win/ He had hoped that one day wx-config-win might be merged in to wxWidgets, but noted that it had fallen behind the project and had several known issues: http://code.google.com/p/wx-config-win/issues/list Personally I feel that (for similar arguments to those for maintaining wxC as a language-agnostic project) we should pursue wx-config-win. Thoughts? > > -- > Eric Kow <http://erickow.com> > > > -----BEGIN PGP SIGNATURE----- > > iEYEARECAAYFAk8EmT4ACgkQBUrOwgisBPnz/wCdEapNshQh+ZqEh2SyyXi/uXO9 > 5lcAnRymzM7qQnzru6cdKpoTqZZ3kQM4 > =hcbP > -----END PGP SIGNATURE----- > > |
|
From: Eric K. <eri...@gm...> - 2012-01-05 15:48:34
Attachments:
signature.asc
|
On 5 Jan 2012, at 15:36, Dave Tapley wrote: > Personally I feel that (for similar arguments to those for maintaining wxC as a language-agnostic project) we should pursue wx-config-win. Thoughts? I think we should get in touch with the wxWidgets guys and see if it really is a patches welcome situation, or if they feel that supporting wx-config-win would lead them to be overstretched. You'll also want to have a look at wxPack, I think. -- Eric Kow <http://erickow.com> |
|
From: Conal E. <co...@co...> - 2012-01-05 18:00:49
|
> > Wow! If this works, Conal might be pleased. > Yes, indeed! I've been blocked in my high-level GUIs & graphics work for a few years, while waiting for a low-level (imperative) Haskell library to show up that combines GUIs & graphics, works cross-platform (including native graphics on Mac), and supports incremental development. gtk2hs almost got there recently, but not quite, and I've always preferred wxHaskell's API. - Conal On Thu, Jan 5, 2012 at 7:36 AM, Dave Tapley <dav...@gm...> wrote: > On 4 January 2012 18:23, Eric Kow <eri...@gm...> wrote: > >> >> On 4 Jan 2012, at 16:59, Dave Tapley wrote: >> > Also, I imagine that while this brings us closer to wxHaskell in GHCi, >> we would still need to solve the second start crash? >> > >> > >> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845 >> > >> > Well, I just had a look, and that issue seems to have gone away in my >> darcsden branch! >> > I've added a comment to the tracker. >> > >> >> Wow! If this works, Conal might be pleased. >> > > It certainly seems to, insomuch as the given test code no longer causes a > crash :) > > >> >> By the way, you mentioned wx-config (I get the feeling you'd asked me a >> direct question and I forgot to answer). Did you have a look at the >> Haskell code in our repo which provides a wx-config replacement? The >> replacement is very very stupid and needs generalising, but it might be >> easier to bring it closer to the kind of completeness we need than to >> maintain the C++ one. >> > > Ah, yes, I suspected this would need some debate. > I was on the cusp of merging in your wx-config implementation, namely: > http://darcsden.com/kowey/wxhaskell/browse/wx-config/ > > But then I got a reply from the previous project leader wx-config-win: > http://code.google.com/p/wx-config-win/ > > He had hoped that one day wx-config-win might be merged in to wxWidgets, > but noted that it had fallen behind the project and had several known > issues: > http://code.google.com/p/wx-config-win/issues/list > > Personally I feel that (for similar arguments to those for maintaining wxC > as a language-agnostic project) we should pursue wx-config-win. Thoughts? > > > >> >> -- >> Eric Kow <http://erickow.com> >> >> >> -----BEGIN PGP SIGNATURE----- >> >> iEYEARECAAYFAk8EmT4ACgkQBUrOwgisBPnz/wCdEapNshQh+ZqEh2SyyXi/uXO9 >> 5lcAnRymzM7qQnzru6cdKpoTqZZ3kQM4 >> =hcbP >> -----END PGP SIGNATURE----- >> >> > |
|
From: Jeremy O'D. <jer...@gm...> - 2012-01-05 18:14:26
|
On 5 January 2012 12:15, Eric Kow <eri...@gm...> wrote: > > On 4 Jan 2012, at 16:59, Dave Tapley wrote: > > > I do like the idea that wxc is a separate project, upon which wxHaskell > depends, however.. > > When configuring wxcore I use wxc's package info, and so require wxc to > be installed by cabal, and I assume it is the intention of the wxC project > to be language independent? > > I think that would help. One hope is that if we had a separate project > that tried harder to be language agnostic, and which had none of the > trappings of a Haskell project, we might be able to get more help from the > wxWidgets team. Make it look like any other project written in C, the > basic autotools (or more likely Bakefile as wxWidgets use it), the > pkgconfig stuff, etc. I am not so keen on this approach. It seems like ever since I have had anything to do with wxHaskell, far more time has been spent on build system issues than on Haskell code or getting new wxWidgets components wrapped. Don't forget that we started with an autotools-based build system which never really worked properly for Windows. This meant that the bar for becoming a wxHaskell developer was unreasonably high. Now that we have everything in Cabal, it is actually pretty easy for people to get going, and I would be loathe to loose that advantage. I accept that Cabal is not an ideal build system, but it does 'just work' when it comes to cross-platform builds. |
|
From: Eric K. <eri...@gm...> - 2012-01-05 22:15:21
Attachments:
signature.asc
|
On 5 Jan 2012, at 18:14, Jeremy O'Donoghue wrote: > I am not so keen on this approach. It seems like ever since I have had anything to do with wxHaskell, far more time has been spent on build system issues than on Haskell code or getting new wxWidgets components wrapped. Yup. Churn churn churn. > Don't forget that we started with an autotools-based build system which never really worked properly for Windows. This meant that the bar for becoming a wxHaskell developer was unreasonably high. Well, hang on. Believe me, I am so not doing build system advocacy here. There will be no discussion on the technical merits of one system over another coming from me. All I was talking about is the social calculation: would wxHaskell benefit from a wxc that is maintained outside the Haskell community? Does such a community even exist in the first place, or is a pipe dream? I imagine it *won't* be wxPython/wxRuby etc as they have their own mechanism for getting their bindings. But it might be handy for other small languages, eg. Mercury? Even if such other bindings exist that would use a wxc, would it still be worthwhile, or would the coordination overhead bog us down (being able to just change wxc do what we want makes us pretty nimble). If the social calculation points to "kick wxc out", then the kicked-out wxc should be language-agnostic (well, beyond C and C++ of course). That's all I'm saying. Eric PS: Hmm, I don't think we were using autotools so much as a hand-written Makefile and configure script with a bunch of shell scripts that nobody really understood. Also, I'm not suggesting autotools specifically; if anything, Bakefile instead since it's the same as what wxWidgets use. -- Eric Kow <http://erickow.com> |
Thanks for helping keep SourceForge clean.
X