Menu
▾
▴
wxhaskell-devel — wxhaskell developers
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(53) |
Mar
(145) |
Apr
(22) |
May
(7) |
Jun
(14) |
Jul
(14) |
Aug
(9) |
Sep
(10) |
Oct
(48) |
Nov
(59) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(36) |
Feb
(5) |
Mar
(33) |
Apr
(28) |
May
(5) |
Jun
(6) |
Jul
(1) |
Aug
(7) |
Sep
(11) |
Oct
(3) |
Nov
(31) |
Dec
|
| 2010 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
(2) |
May
(9) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2011 |
Jan
(1) |
Feb
(3) |
Mar
(4) |
Apr
(1) |
May
(2) |
Jun
(12) |
Jul
(36) |
Aug
(7) |
Sep
(40) |
Oct
(6) |
Nov
(40) |
Dec
(8) |
| 2012 |
Jan
(54) |
Feb
(8) |
Mar
(1) |
Apr
(16) |
May
(2) |
Jun
(12) |
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
(7) |
| 2013 |
Jan
(8) |
Feb
|
Mar
(13) |
Apr
(2) |
May
(13) |
Jun
(44) |
Jul
|
Aug
(13) |
Sep
(12) |
Oct
(11) |
Nov
(7) |
Dec
(6) |
| 2014 |
Jan
(3) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Eric K. <eri...@gm...> - 2013-06-06 07:04:27
|
If Atze agrees to this, I suggest we wait a little over a week for either some sort of blessing or maybe Jeremy's return and then make it official with some sort of announcement On 6 June 2013 07:38, harry <vol...@ho...> wrote: > harry <voldermort@...> writes: > > See https://github.com/jodonoghue/wxHaskell/network for an example of the > problem - 4 fixes waiting on pull requests to the abandoned official branch. > > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-06-06 06:38:41
|
harry <voldermort@...> writes: See https://github.com/jodonoghue/wxHaskell/network for an example of the problem - 4 fixes waiting on pull requests to the abandoned official branch. |
|
From: harry <vol...@ho...> - 2013-06-05 10:35:51
|
There are now several forks of wxhaskell on github, with different fixes in each, some of which are essential to compile on the current version of HP. Jeremy O'Donoghue appears to have been AWOL for several months now, and the project will die if a new leader doesn't step up. The essential tasks of the project leader (at least the short-term ones) are to maintain the "official" repository into which all accepted fixes will be merged, and to publish new versions to Hackage. Would Atze Dijkstra be willing to take this on? |
|
From: harry <vol...@ho...> - 2013-06-02 09:41:40
|
Eric Kow <eric.kow@...> writes: > > PATH: (add these) > > %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% > So by rights, as far as building wxHaskell and wxHaskell apps is concerned (sandbox or no), we need > “only” really set the WXWIN and WXCFG environment variables. I forget what exactly for, partly to > grab the complicated set of compiler flags needed to import and link against the wxWidgets libraries. OK, so the last component which gets added to the path: %CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% That looks like something which really shouldn't be there, what exactly is it used for? Also, is WXWIN used during the build process, as well as when updating the path? |
|
From: Eric K. <eri...@gm...> - 2013-06-02 08:03:28
|
On 2 Jun 2013, at 08:44, harry wrote: > Referring to the installation instructions, we have the following > environment variables: > > CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents > and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal) > GHC_VERSION: 7.0.3 (for our convenience) > WXC_VERSION: 0.90.0.2 > WXWIN: C:\wxWidgets-2.9.3 > WXCFG: gcc_dll\mswu > PATH: (add these) > %WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% > > It may be worth considering how all these are used. In particular, are > GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path? I think that these indeed are only used for convenience, so we're down to three environment variables: • WXWIN (used by wxc on compile time • WXCFG: (used by wxc on compile time) • PATH: (add these) (needed on runtime so we can find wxWidgets and wxC respectively) So by rights, as far as building wxHaskell and wxHaskell apps is concerned (sandbox or no), we need “only” really set the WXWIN and WXCFG environment variables. I forget what exactly for, partly to grab the complicated set of compiler flags needed to import and link against the wxWidgets libraries. -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-06-02 07:44:56
|
Referring to the installation instructions, we have the following
environment variables:
CABAL_DIR: C:\Users\XXX\AppData\Roaming\cabal (Windows XP: C:\Documents
and Settings\XXX\Application Data\cabal, or: %APPDATA%\cabal)
GHC_VERSION: 7.0.3 (for our convenience)
WXC_VERSION: 0.90.0.2
WXWIN: C:\wxWidgets-2.9.3
WXCFG: gcc_dll\mswu
PATH: (add these)
%WXWIN%\lib\gcc_dll;%WXWIN%;%CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION%
It may be worth considering how all these are used. In particular, are
GHC_VERSION, WXC_VERSION, WXWIN and CABAL_DIR only used for setting the path?
|
|
From: Eric K. <eri...@gm...> - 2013-06-02 07:03:33
|
On 2 Jun 2013, at 07:56, harry wrote: > The next hurdle is wxcore, which expects to find various bits of wxc in > places that it should really be keeping its nose out of. I suspect that if > everything has been set up correctly outsides of the sandbox, this too will > succeed by following the environment variables (as long as there aren't any > spaces on the path), but I can't actually test this hypothesis because I've > upgraded my HP, and wxc/ore won't compile on GHC 7.6. OK, so I think maybe we should pick this back up when the wxHaskell team have had a chance to catch up with GHC 7.6, because I used wxHaskell in a sandbox (albeit on MacOS X), and have reason to believe that having wxdirect be available on the PATH addresses this pain point. If Blair is still interested in wxHaskell jobs, this is another great one that needs help. Thanks, -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-06-02 06:57:17
|
Eric Kow <eric.kow@...> writes: > OK let me get this straight. Is the user-facing problem here that installing wxHaskell for use in a sandbox > environment is impossible or just very inconvenient/difficult? The problem is that cabal-dev tries to install all the dependencies automatically. So if I have a dependency on wx, cabal-dev goes all the way back to wxdirect and tries to install it. This succeeds, but is useless, because the executable won't be found later. It then installs wxc, which I think will succeed if wxdirect has already been installed outside of the sandbox, and can therefore be found on the path. The next hurdle is wxcore, which expects to find various bits of wxc in places that it should really be keeping its nose out of. I suspect that if everything has been set up correctly outsides of the sandbox, this too will succeed by following the environment variables (as long as there aren't any spaces on the path), but I can't actually test this hypothesis because I've upgraded my HP, and wxc/ore won't compile on GHC 7.6. |
|
From: Howard B. G. <how...@ya...> - 2013-06-01 21:25:35
|
On 06/01/2013 01:34 PM, Eric Kow wrote: > I had some longer comments on the technical issues. I think we may > be need to step back a bit and peel apart the fundamental issues > first (C++, shared libraries, other?) but first let's make sure we > understand what the user-facing problem really is. Is it > impossibility or is it hoops? While you are thinking about this, I hope you will also expand your discussion to the Haskell Platform use case: what would it take to develop a binary add-on that would install wxhaskell on top of a binary HP installation? Extra credit for doing this on Linux, Windows and OS X. In the earlier discussion you mentioned wxc and how it was hand generated. I wonder if the swig tool could be adapted to work with Haskell. This has been discussed for many years. Recently there was a GSoC project to make swig generate a C interface from C++. If this addition to swig is usable, it may be worth trying it to autogenerate wxc or a major part of it. While I use Linux at home and am comfortable building software from source, I think it would be a big win for the Haskell community to have wxhaskell (and gtk2hs) binary packages that run on Windows and OS X since these platforms are used more. Howard |
|
From: Eric K. <eri...@gm...> - 2013-06-01 20:30:06
|
OK, so let's step back a bit. I think Luc's right in two senses, first that we need to understand what the user-facing problem is, and second what is technical problem lying at the heart of user-facing problem. In your first message you said: > OTOH, cabal install wxdirect installs both the helper executable and a > library. 3 other packages then have to be installed, at least one of which > requires environment variables pointing to bits of earlier packages. One > upshot of all this is that it's well nigh impossible to use wxhaskell with > cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools > outside the sandbox, then gtk will use it in the sandbox). OK let me get this straight. Is the user-facing problem here that installing wxHaskell for use in a sandbox environment is impossible or just very inconvenient/difficult? My understanding is that it's the latter: namely because you have to jump through three extra hoops: w0. install wxWidgets w1. update PATH to point to wxWidgets? w2. install wx-config w3. set up WXWIN, WXWIN, PATH environment variables w4. install wxdirect w5. then cabal install wx (which grabs wxcore and wxc automatically) Contrast with four steps in gtk2hs g0. install gtk g1. update PATH to point to gtk? g2. install gtk2hs-buildtool g3. cabal install gtk Do I have this right, first of all? I had some longer comments on the technical issues. I think we may be need to step back a bit and peel apart the fundamental issues first (C++, shared libraries, other?) but first let's make sure we understand what the user-facing problem really is. Is it impossibility or is it hoops? -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-06-01 18:29:33
|
Eric Kow <eric.kow@...> writes: > May I ask which environment variables in particular you're referring to? All of them, particularly those used to find the location of wxc. cabal-dev installs all dependencies blindly, and doesn't know to set environment variables. > (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use > wxdirect as a library of some sort. There's a bit of a complication > here in that we're actually faking the dependency on wxdirect: we're > claiming that wxcore depends on wxdirect when the case is more that > the Setup.hs script used by wxcore uses wxdirect. Removing this fake dependency would certainly help (also from wxc and wxcore), because it messes up cabal-dev. > - wxc (the C interface) If I've understood you correctly, wxc doesn't install any Haskell libraries. In which case, could it just create an executable that knows how to generate the C wrapper? wxcore could then run it during setup, and finding it wouldn't be a problem - cabal's bin directory is already on the path. This might also make things easier for users of other languages wanting to share wxc, as only template maniacs expect programs to do their work at compile time :-) My "vision", which may be fatally flawed for not understanding C, C++, WxWidgets, or the WxHaskell build process, is: - cabal install wx-buildtools will install wxdirect (is this really needed as a standalone executable?), and wxc, a program which knows how to create the C wrappers. It will not install any libraries. - cabal install wxcore will run wxc to create the C wrappers, and put them wherever it wants. It will not declare a dependency on wx-buildtools. - cabal install wx at it exist now. |
|
From: Eric K. <eri...@gm...> - 2013-05-31 16:16:21
|
OK, I'm studying http://www.haskell.org/haskellwiki/WxHaskell/Windows to update my understanding of the build infrastructure a bit May I ask which environment variables in particular you're referring to? So for the matter of executables not being on the path, two approaches might be (A1) [the frustrated sandboxer] cabal-dev install wxdirect before cabal-dev install your-package. Whilst this would install wxdirect into your sandbox, with at least some versions of cabal-install, it also creates symlinks pointing from ~/.cabal/bin into said sandbox [fact-check?] (A2) [the frustrated sandboxer] like with gtk2hs, install wxdirect universally [I think this is what I do?] (B) [an aspiring wxHaskell hacker] modify wxcore's Setup.hs to use wxdirect as a library of some sort. There's a bit of a complication here in that we're actually faking the dependency on wxdirect: we're claiming that wxcore depends on wxdirect when the case is more that the Setup.hs script used by wxcore uses wxdirect. There might be some unpredictable cabalisation problems that arise due to the current limitation I pointed to earlier https://github.com/haskell/cabal/issues/948 --- So we have: - wxWidgets C++ - wxc (the C interface) - wxcore (autogenerated Haskell [FFI stuff] + low-ish level Haskell calling the FFI stuff) - wx (nicer Haskell) In the case of wxc what we have are a bunch of C++ files that expose a C interface to wxWidgets. No fancy code generation, no Haskell. Sure there are folks who would love for wxc to be completely automatically generated (as would I), but nobody has gotten around to it. The wxc build script needs to know where WxWidgets lives so that it knows what libraries to link against (it calls the wx-config program for this, which alas doesn't really exist on Windows and you have to very painfully fetch a stand-in for), hence WXWIN The autogenerated parts of wxcore are I think Haskell wrappers around wxc [created by wxdirect]. The input to this process is just the handwritten wxc header files, which wxcore Setup finds by asking Cabal: https://github.com/atzedijkstra/wxHaskell/blob/master/wxcore/Setup.hs#L37 I notice that the wiki mentions WXC_VERSION and putting something like %CABAL_DIR%\wxc-%WXC_VERSION%\%GHC_VERSION% in the PATH. Yuck. This should “only” be needed when we actually want to run something, so that the Windows runtime linking stuff can do its magic with wxc.dll Once upon a time wxc/wxcore were a single package. And we relatively recently split them apart (I think to some rejoicing?) which made the wxcore build process a lot simpler (?). I'm afraid I'm going to have to put this down now so I can't research our decision to make the split, but I'd encourage anybody who wants to work on wxHaskell to study the evolution of this. Sorry for the mess folks! I think the build situation has improved a lot over the years. But we still have a way to go. I agree that fewer hoops and a one-shot install are important. Phew, hope this was useful. Hopefully I didn't get things wrong in my depiction above. I think my ideal situation would be for something like wxc to be shipped by default with wxWidgets and for a bunch of exotic languages to use the same layer. If you can make *that* happen by coordinating with various language teams like wxOCaml and with the wxWidgets folks, that'd be super. But it's a sort of long-term thing… (and may get bogged down by people hating the fact that wxc is handwritten when it can so clearly be autogenerated, but then nobody doing anything about it so it just gets stuck). So maybe the right thing to work on there is autogenerated wxc ;-) Eric On 31 May 2013 16:31, harry <vol...@ho...> wrote: > Eric Kow <eric.kow@...> writes: > >> Is the issue something related to the wxdirect executable not being >> available in the sandbox environment? > > Yes - executables built in cabal-dev aren't on the path (which is different > for each sandbox). If wxdirect only built an executable, I could install it > outside of the sandboxes, and it would be available in the path for later use. > > A similar issue arises with wxc - what exactly is it building, and why is an > environment variable needed to find it later? Is it creating a Haskell > library, or just creating come C files for use by wxcore? > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-05-31 15:31:49
|
Eric Kow <eric.kow@...> writes: > Is the issue something related to the wxdirect executable not being > available in the sandbox environment? Yes - executables built in cabal-dev aren't on the path (which is different for each sandbox). If wxdirect only built an executable, I could install it outside of the sandboxes, and it would be available in the path for later use. A similar issue arises with wxc - what exactly is it building, and why is an environment variable needed to find it later? Is it creating a Haskell library, or just creating come C files for use by wxcore? |
|
From: Luc T. <luc...@gm...> - 2013-05-31 13:28:26
|
btw, we are already at the solution stage, what is the problem in fact ? what are the typical difficulties that a raise when installing wx ? is it on the C side or on the haskell side ? is it because they have to be fetched separately ? do we have a shared view on where lies the problems ? -- Luc Taesch Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le vendredi 31 mai 2013 à 15:24, Eric Kow a écrit : > On 31 May 2013 06:34, harry <vol...@ho... (mailto:vol...@ho...)> wrote: > > The first problem is that wxdirect installs both executables and a library - > > why is that necessary, and is there another way to do it? > > > > > Could you elaborate on this? I'm not 100% sure I follow. > > Is the issue something related to the wxdirect executable not being > available in the sandbox environment? > > One issue is that wxdirect is used in the build process of the wxcore Setup.hs > > One thing which I think might help matters is if we had a way for the > custom Setup.hs in wxcore to depend on wxdirect. Now one option would > be for us to just swallow wxdirect directly into wxcore, making it > part of the setup script. There's no particular reason it has to be > run as an executable. > > If not feasible, then we may need something like > https://github.com/haskell/cabal/issues/948 > > -- > Eric Kow <http://erickow.com> > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite > It's a free troubleshooting tool designed for production > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap2 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... (mailto:wxh...@li...) > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: Eric K. <eri...@gm...> - 2013-05-31 13:24:08
|
On 31 May 2013 06:34, harry <vol...@ho...> wrote: > The first problem is that wxdirect installs both executables and a library - > why is that necessary, and is there another way to do it? Could you elaborate on this? I'm not 100% sure I follow. Is the issue something related to the wxdirect executable not being available in the sandbox environment? One issue is that wxdirect is used in the build process of the wxcore Setup.hs One thing which I think might help matters is if we had a way for the custom Setup.hs in wxcore to depend on wxdirect. Now one option would be for us to just swallow wxdirect directly into wxcore, making it part of the setup script. There's no particular reason it has to be run as an executable. If not feasible, then we may need something like https://github.com/haskell/cabal/issues/948 -- Eric Kow <http://erickow.com> |
|
From: harry <vol...@ho...> - 2013-05-31 05:35:23
|
Blair Archibald <mrblairarchibald@...> writes: > The logical first step seems to be to combine the 3 packages (wxcore, wx, wxc) into some form of singly installed package. I'm a novice when it comes to cabal so not sure how what the effects of such a change could be. > I appreciate that cabal is a great system for installing Haskell packages but perhaps we should provide additional install methods that also come pro-bundled with wxWidgets, this way we can control the version that we ship with - again the issue comes with how to install them on different platforms and in a controlled manner. The first problem is that wxdirect installs both executables and a library - why is that necessary, and is there another way to do it? |
|
From: Eric K. <eri...@gm...> - 2013-05-30 20:30:35
|
Simpler would be fantastic, but there are technical reasons for the current setup. If you can meet the same goals whilst delivering an easier install experience (or boldly cut off goals that can be better understood as wrongheaded), more power to ya! * wxc - C++ to C wrapper. Uses make (or can be easily persuaded to do so?) to enable collaboration with non Haskell projects. I may be wrong here, wasn't involved in recent round of simplifications * wxdirect - generates code from header files? * wxcore - C to Haskell. partly auto generated by wxdirect. This is what makes it vaguely possible to run the wxWidgets treadmill * wxc - the easy part. Nice mid level completely static Haskell. Nice to have a part people can hack on that without low level concerns With this sort if layering in mind, each layer providing some goals, can we do anything to improve the situation? On 30 May 2013, at 21:16, Blair Archibald <mrb...@gm...> wrote: > I agree that the current deployment system for wxHaskell is not ideal and we should probably look into changing it. Does anyone have any ideas as to how we could go about this? > > The logical first step seems to be to combine the 3 packages (wxcore, wx, wxc) into some form of singly installed package. I'm a novice when it comes to cabal so not sure how what the effects of such a change could be. > > I appreciate that cabal is a great system for installing Haskell packages but perhaps we should provide additional install methods that also come pro-bundled with wxWidgets, this way we can control the version that we ship with - again the issue comes with how to install them on different platforms and in a controlled manner. > > These are just a few ideas. I'd be willing to work on additional deployment methods if anyone wants to take this on and needs help (as I say I'm possibly too novice at wxHaskell and Cabal to get this right on my own). > > Many thanks, > Blair > > > On 30 May 2013 19:04, harry <vol...@ho...> wrote: >> Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included >> in the path, cabal install gtk2hs-buildtools will install all the >> executables needed for building the bindings, but no libraries. cabal >> install gtk will then install the library. >> >> OTOH, cabal install wxdirect installs both the helper executable and a >> library. 3 other packages then have to be installed, at least one of which >> requires environment variables pointing to bits of earlier packages. One >> upshot of all this is that it's well nigh impossible to use wxhaskell with >> cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools >> outside the sandbox, then gtk will use it in the sandbox). >> >> >> ------------------------------------------------------------------------------ >> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET >> Get 100% visibility into your production application - at no cost. >> Code-level diagnostics for performance bottlenecks with <2% overhead >> Download for free and get started troubleshooting in minutes. >> http://p.sf.net/sfu/appdyn_d2d_ap1 >> _______________________________________________ >> wxhaskell-devel mailing list >> wxh...@li... >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel |
|
From: Blair A. <mrb...@gm...> - 2013-05-30 20:16:51
|
I agree that the current deployment system for wxHaskell is not ideal and we should probably look into changing it. Does anyone have any ideas as to how we could go about this? The logical first step seems to be to combine the 3 packages (wxcore, wx, wxc) into some form of singly installed package. I'm a novice when it comes to cabal so not sure how what the effects of such a change could be. I appreciate that cabal is a great system for installing Haskell packages but perhaps we should provide additional install methods that also come pro-bundled with wxWidgets, this way we can control the version that we ship with - again the issue comes with how to install them on different platforms and in a controlled manner. These are just a few ideas. I'd be willing to work on additional deployment methods if anyone wants to take this on and needs help (as I say I'm possibly too novice at wxHaskell and Cabal to get this right on my own). Many thanks, Blair On 30 May 2013 19:04, harry <vol...@ho...> wrote: > Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included > in the path, cabal install gtk2hs-buildtools will install all the > executables needed for building the bindings, but no libraries. cabal > install gtk will then install the library. > > OTOH, cabal install wxdirect installs both the helper executable and a > library. 3 other packages then have to be installed, at least one of which > requires environment variables pointing to bits of earlier packages. One > upshot of all this is that it's well nigh impossible to use wxhaskell with > cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools > outside the sandbox, then gtk will use it in the sandbox). > > > > ------------------------------------------------------------------------------ > Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET > Get 100% visibility into your production application - at no cost. > Code-level diagnostics for performance bottlenecks with <2% overhead > Download for free and get started troubleshooting in minutes. > http://p.sf.net/sfu/appdyn_d2d_ap1 > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > |
|
From: harry <vol...@ho...> - 2013-05-30 18:20:12
|
Building Gtk2Hs on Windows is very straightforward. After Gtk+ is included in the path, cabal install gtk2hs-buildtools will install all the executables needed for building the bindings, but no libraries. cabal install gtk will then install the library. OTOH, cabal install wxdirect installs both the helper executable and a library. 3 other packages then have to be installed, at least one of which requires environment variables pointing to bits of earlier packages. One upshot of all this is that it's well nigh impossible to use wxhaskell with cabal-dev, whereas with gtk2hs it's really easy (install gtk2hs-buildtools outside the sandbox, then gtk will use it in the sandbox). |
|
From: Eric K. <eri...@gm...> - 2013-05-27 15:20:58
|
OK, That's great to see somebody picking it up and running with it. Sorry for the noise, Blair Some sort of informal roadmap might be nice. Good to see the wiki page has been updated accordingly http://www.haskell.org/haskellwiki/Wxhaskell Some things that may need deciding: how much of the sourceforge infrastructure do we still want to keep? Bugs for example, where should they go? I think we still have some SF bugs around. If somebody needs to be added to something, let me know… On 27 May 2013 16:07, Luc Taesch <luc...@gm...> wrote: > for the status , I could say , from a not so old mail (16/4) > > "Atze Dijkstra and I (Henk-Jan van Tuyl ) are currently doing maintenance on > wxHaskell, using > the GitHub repository you mentioned …" > > https://github.com/atzedijkstra/wxHaskell > > > -- > Luc Taesch > Envoyé avec Sparrow > > Le lundi 27 mai 2013 à 16:56, Eric Kow a écrit : > > Maybe you could review the current pull requests? > https://github.com/jodonoghue/wxHaskell/pulls > > It might not feel very entry level, but it could be a way to get > sucked into the infrastructure. > > As for maintenance, I think the current maintainer is Jeremy > O'Donoghue, who we haven't heard from in a while (but I see he's > merged a pull request). Apologies if I'm mistaken; have been out of > the loop for some years. There are jobs that folks might usually leave > to a dev team or maintainer, but I think the community may want to > pick up and try to do. Anybody available to step in a sort of interim > maintainer? > > wxHaskell did see a nice uptick of activity in 2012 with a good > cleanup of the infrastructure and layering of the packages. It'd be > great to see this progress built upon. > > > On 27 May 2013 09:07, Blair Archibald <mrb...@gm...> wrote: > > Hi, > > It was mentioned on the Haskell beginners mailing list that wxHaskell was > looking for volunteers. > > I was wondering if anyone knew of any "entry" level tasks which need > performed so I can get a feel for the codebase etc. > > I have an intermediate knowledge of Haskell (less than a year but still > learning). I also don't mind working in C/C++ which makes this project good > fit in my mind. > > I realise there was a mailing list post a while ago debating the maintenance > of wxHaskell but I couldn't figure out who the lead maintainer currently is? > > Many thanks, > Blair > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > > > > -- > Eric Kow <http://erickow.com> > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > -- Eric Kow <http://erickow.com> |
|
From: Luc T. <luc...@gm...> - 2013-05-27 15:07:35
|
for the status , I could say , from a not so old mail (16/4) "Atze Dijkstra and I (Henk-Jan van Tuyl ) are currently doing maintenance on wxHaskell, using the GitHub repository you mentioned …" https://github.com/atzedijkstra/wxHaskell -- Luc Taesch Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le lundi 27 mai 2013 à 16:56, Eric Kow a écrit : > Maybe you could review the current pull requests? > https://github.com/jodonoghue/wxHaskell/pulls > > It might not feel very entry level, but it could be a way to get > sucked into the infrastructure. > > As for maintenance, I think the current maintainer is Jeremy > O'Donoghue, who we haven't heard from in a while (but I see he's > merged a pull request). Apologies if I'm mistaken; have been out of > the loop for some years. There are jobs that folks might usually leave > to a dev team or maintainer, but I think the community may want to > pick up and try to do. Anybody available to step in a sort of interim > maintainer? > > wxHaskell did see a nice uptick of activity in 2012 with a good > cleanup of the infrastructure and layering of the packages. It'd be > great to see this progress built upon. > > > On 27 May 2013 09:07, Blair Archibald <mrb...@gm... (mailto:mrb...@gm...)> wrote: > > Hi, > > > > It was mentioned on the Haskell beginners mailing list that wxHaskell was > > looking for volunteers. > > > > I was wondering if anyone knew of any "entry" level tasks which need > > performed so I can get a feel for the codebase etc. > > > > I have an intermediate knowledge of Haskell (less than a year but still > > learning). I also don't mind working in C/C++ which makes this project good > > fit in my mind. > > > > I realise there was a mailing list post a while ago debating the maintenance > > of wxHaskell but I couldn't figure out who the lead maintainer currently is? > > > > Many thanks, > > Blair > > > > ------------------------------------------------------------------------------ > > Try New Relic Now & We'll Send You this Cool Shirt > > New Relic is the only SaaS-based application performance monitoring service > > that delivers powerful full stack analytics. Optimize and monitor your > > browser, app, & servers with just a few lines of code. Try New Relic > > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > _______________________________________________ > > wxhaskell-devel mailing list > > wxh...@li... (mailto:wxh...@li...) > > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > > > > > > -- > Eric Kow <http://erickow.com> > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... (mailto:wxh...@li...) > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > > |
|
From: Eric K. <eri...@gm...> - 2013-05-27 14:56:58
|
Maybe you could review the current pull requests? https://github.com/jodonoghue/wxHaskell/pulls It might not feel very entry level, but it could be a way to get sucked into the infrastructure. As for maintenance, I think the current maintainer is Jeremy O'Donoghue, who we haven't heard from in a while (but I see he's merged a pull request). Apologies if I'm mistaken; have been out of the loop for some years. There are jobs that folks might usually leave to a dev team or maintainer, but I think the community may want to pick up and try to do. Anybody available to step in a sort of interim maintainer? wxHaskell did see a nice uptick of activity in 2012 with a good cleanup of the infrastructure and layering of the packages. It'd be great to see this progress built upon. On 27 May 2013 09:07, Blair Archibald <mrb...@gm...> wrote: > Hi, > > It was mentioned on the Haskell beginners mailing list that wxHaskell was > looking for volunteers. > > I was wondering if anyone knew of any "entry" level tasks which need > performed so I can get a feel for the codebase etc. > > I have an intermediate knowledge of Haskell (less than a year but still > learning). I also don't mind working in C/C++ which makes this project good > fit in my mind. > > I realise there was a mailing list post a while ago debating the maintenance > of wxHaskell but I couldn't figure out who the lead maintainer currently is? > > Many thanks, > Blair > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > -- Eric Kow <http://erickow.com> |
|
From: Luc T. <luc...@gm...> - 2013-05-27 08:22:21
|
well, I have a personal need, which is to get drag and drop working. and you definitively got a feel of the code base , as I did when investigating. however, this is not the most generic useful task, so lets wait until any other say something. otherwise Ill start transferring what I learned Luc -- Luc Taesch Envoyé avec Sparrow (http://www.sparrowmailapp.com/?sig) Le lundi 27 mai 2013 à 10:07, Blair Archibald a écrit : > Hi, > > It was mentioned on the Haskell beginners mailing list that wxHaskell was looking for volunteers. > > I was wondering if anyone knew of any "entry" level tasks which need performed so I can get a feel for the codebase etc. > > I have an intermediate knowledge of Haskell (less than a year but still learning). I also don't mind working in C/C++ which makes this project good fit in my mind. > > I realise there was a mailing list post a while ago debating the maintenance of wxHaskell but I couldn't figure out who the lead maintainer currently is? > > Many thanks, > Blair > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > > _______________________________________________ > wxhaskell-devel mailing list > wxh...@li... (mailto:wxh...@li...) > https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel > > |
|
From: Blair A. <mrb...@gm...> - 2013-05-27 08:07:31
|
Hi, It was mentioned on the Haskell beginners mailing list that wxHaskell was looking for volunteers. I was wondering if anyone knew of any "entry" level tasks which need performed so I can get a feel for the codebase etc. I have an intermediate knowledge of Haskell (less than a year but still learning). I also don't mind working in C/C++ which makes this project good fit in my mind. I realise there was a mailing list post a while ago debating the maintenance of wxHaskell but I couldn't figure out who the lead maintainer currently is? Many thanks, Blair |
|
From: Henk-Jan v. T. <hj...@ch...> - 2013-04-11 21:31:56
|
On Tue, 09 Apr 2013 21:54:15 +0200, Luc TAESCH <luc...@gm...>
wrote:
>
> WxHaskell and DragAndDrop
>
> I would like to know how to use the following events handlers :
> dropTargetOnData, dropTargetOnDrop, dropTargetOnEnter,
> dropTargetOnDragOver….[1]
>
>
> Could you check if my current believes are corrects :
>
> From wx Widgets/ wxPython [2] / [3] / [4] it looks like they need to be
> used to manage DragAndDrog for non trivial examples.
> they are not actionable via an existing event like "on drag", etc..
> I tried and create my own event. but it does not get "activated". [7]
> besides, from the signatures [1], these look like being activated on
> DropTarget, unlike other events on Reactive/ Windows/Controls . Is It
> Correct ?
>
> Heinrich created its own events "onText", (in reactive-Banana) but this
> is on a Control. [6]
>
>
>
> Could someone confirm these events effectively worked for them in
> WxHaskell, and maybe hint how to do that
>
I have tried you attached program and it gave the following tracing:
>Drag.exe
showMeDropDnD handler called: DragMove
on Drag activated:
on Enter:Point {pointX = 24, pointY = 6}
Build info:
- Windows XP
- GHC version 7.4.2
- wxWidgets-2.9.3
- wxHaskell from https://github.com/atzedijkstra/wxHaskell
As no one else has responded so far, I think you are in uncharted
territory; wxHaskell is huge and there are not many applications using it.
If you have figured it all out, I hope you want to write a HaskellWiki
page about it.
Regards,
Henk-Jan van Tuyl
--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--
|
15 messages has been excluded from this view by a project administrator.
