Re: [wxhaskell-devel] The future of wxC

2012-01-25 Thread Dave Tapley
On 16 January 2012 00:46, Eric Kow eric@gmail.com wrote:


 I was going to post on your blog, but you beat me to mentioning it. So
 better hear it from me, you should totally use GitHub for wxC. Plus it
 would be a chance to work with darcs-bridge maybe.


1. Eric will probably kill me for saying this, but I think GitHub is
   probably the right place, possibly keeping Sourceforge as the project
   website and distribution point (I personally don't much like git, but it
   has mindshare, and probably makes more sense than Darcs for a 
 non-Haskell
   project - plus my experience with patch-tag and darcsden has been that
   'getting going' on a Windows machine is far from trivial). I could be
   persuaded to change my mind on this one, but probably only if one of the
   Darcs hosts can get the experience 'right' on Windows clients.
   2. Keep the Cabal-based build system to start with, until there is
   clear evidence of non-Haskell contributions.
1. If wxC turns out to have legs, the main areas to attack should be:
   1. Move to bakefile based build.
   2. Automated generation of the binding.



If I may weight in..

I like the idea of moving wxC to a separate project, to at least open it up
to other communities, and I'd be happy to have it on GitHub, if that's the
consensus.
What ever decision we make, do we want to hold off the move on to
code.haskell.org until we've made a decision?
Actually, it might be easier to get moved across in our current state, and
then move out wxC afterwards?


R.e. Point 1.2. In the list above, I've been keeping half an eye on this
-cafe thread, which seems to be getting more attention than I had
anticipated:
http://www.mail-archive.com/haskell-cafe@haskell.org/msg96678.html
I may be getting ahead of myself..




 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] The 'making wxC build on all platforms thread

2012-01-25 Thread Dave Tapley
Hi all,

Sorry I've been a little quiet the last week or two, rest assured I have
lurking all along.

On 22 January 2012 00:37, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 I now have wxC building on Windows. Details below and patches attached.


Excellent!
I'll take a look.



 Jeremy

  On 18 January 2012 23:34, Jeremy O'Donoghue 
 jeremy.odonog...@gmail.comwrote:

 On 17 January 2012 22:40, Jeremy O'Donoghue 
 jeremy.odonog...@gmail.comwrote:

 On 17 January 2012 21:38, Jeremy O'Donoghue 
 jeremy.odonog...@gmail.comwrote:

 Hi all,

 I have collected together all of the people who I know are making the
 effort to build Dave's latest code on different platforms. I'd also like to
 introduce Andrej, who is testing wxC in the context of D (so could we go
 easy on the Zygohistomorphic Premorphisms and other deep Haskell-ism in
 this thread :-)

 I'd suggest that we try to pull together all of the experiences into a
 single thread - makes it easier for people to keep up.

 For the moment, I'd like to bring up my experience with wxC on Windows:

 First, you need at least a patch to wx-config-win32 which sorts out
 library names (msys libraries are incorrectly named due to a 2.8/2.9
 change)

 At line 948 of wx-config-win.cpp, you need:
 if (cfg[BUILD] == “debug”  cfg[DEBUG_FLAG] == “default”)
 po[WXDEBUGFLAG] = “”;

 if (cfg[DEBUG_FLAG] == “1″)
 po[WXDEBUGFLAG] = “”;


 Second, in wxc/Setup.hs you need to change line 82 (just after output
 readProcess “wx-config” [--libs, std,gl,stc,xrc,richtext,aui,media,
 --cppflags] “”

 This is needed because wx-config-win does not support the new ‘all’
 flag, and I haven’t had time to fix wx-config-win properly.

 Third, the library then builds for me, but fails to link (link errors
 in StyledTextCtrl). I hope to work out why tonight or tomorrow.




 I've worked out why, but haven't fixed it.

 wx-config-win doesn't know about some of the new libraries, and is
 giving incorrect results in other cases. I don't have time to fix this
 tonight, but:

 C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxcwx-config
 --libs base,gl,xrc,richtext,aui,media returns
  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_richtext
 -lwxmsw29u_gl -lopengl32 -lglu32 -lwxmsw29u_media -lwxbase29u -lwxtiff
 -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat -lkernel32 -luser32
 -lgdi32 -lcomdlg32 -lwxregexu -lwinspool -lwinmm -lshell32 -lcomctl32
 -lole32
 -loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32

 C:\usr\local\src\haskell\wxhaskell-dev\wxhaskell-2.9\wxcwx-config
 --libs returns
  -mthreads -LD:\Builds\wxWidgets-2.9.3\lib\gcc_dll -lwxmsw29u_html 
 -lwxmsw29u_adv
 -lwxmsw29u_core -lwxbase29u_xml -lwxbase29u_net
 -lwxbase29u -lwxtiff -lwxjpeg -lwxpng -lwxzlib -lwxregexu -lwxexpat
 -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lw xregexu -lwinspool -lwinmm
 -lshell32 -lcomctl32 -lole32 -loleaut32 -luuid -lrpcrt4 -ladvapi32
 -lwsock32

 Missing base libraries in red.

 I'll try to fix this tomorrow.



 I have managed to make wx-config-win work, at least for my configuration.
 There is a known bug which I lack the will to fix right now - the command
 line parser in wx-config-win is very rudimentary and thinks that wx-config
 --libs all --cppflags is looking for the additional library --cppflags.

 The work-around is to call wx-config --cppflags --libs all - I have
 changed wxc\Setup.hs to call wx-config this way.

 Changes to wx-config-win are quite numerous. The most notable is that the
 Unix wx-config has the set of libraries available (e.g. for all)
 hard-coded into it (when wx-config.in is turned into wx-config by
 configure). On Windows this is not possible, so I have written a function
 which goes to the library directory of the selected wxWidgets install and
 enumerates all of the wx-related libraries. This is a bit fragile really,
 since it assumes that future wxWidgets libraries follow the current naming
 convention, but it works for now.

 I don't have access to the wx-config-win svn repo, so the updated file is
 attached. Oh, and it also builds under VS2010 now (I wanted a decent
 debugger!).

 A couple of minor patches were needed to wxc to make it build. These are:

- Reversed the order of libraries, to correctly permit static linking
(because MinGW GCC actually statically links the implibs).
- Don't specify wxWidgets version for Windows (wx-config-win doesn't
support). We do show the detected version, however.
- Work-around for the wx-config-win --cppflags bug noted above.
- Add the -Wl,enable-auto-import link flag on Windows, which gets rid
of a lot of spurious link warnings.
- Made wxc.a and wxc.dll build in the dist\build directory, so install
succeeds.
- Added undef cases for wxAUI event wrappers


 I am now failing to build wxcore. This is faling to find the wxc header
 files on Windows (it is looking for them in ./include/wxc). I notice that
 Dave has already marked the wxcInstallDir function as dubious, so I'll
 

Re: [wxhaskell-devel] I declare the wxHaskell repo open for merging of wxWidgets 2.9.x support

2012-01-16 Thread Dave Tapley
On 15 January 2012 22:38, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:
 Hi developers,

 Think the subject says it all :-)

Bwahahahaa.

So, this is code.haskell.org?
How does one go about obtaining access?


 Jeremy

 --
 RSA(R) Conference 2012
 Mar 27 - Feb 2
 Save $400 by Jan. 27
 Register now!
 http://p.sf.net/sfu/rsa-sfdev2dev2
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2012-01-12 Thread Dave Tapley
On 12 January 2012 15:09, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:
 Thank you Kenneth,

 That's an extremely detailed and complete set of notes. It is very much
 appreciated.

I'd also like to offer my thanks, this is extremely useful to us.


 Best regards
 Jeremy

 On 12 January 2012 14:52, Frodo Kenny frodoken...@gmail.com wrote:

 Nice work. I was still on GHC 6.10 to be able to use wxhaskell with ghci.

 Here are some notes and patches for OS X. I'm running Lion (10.7.2) and
 getting wxwidgets running actually took the most time.


 1) wxwidgets


 First of all, Haskell and wxwidgets must use the same architecture, i.e.
 both 32-bit or both 64-bit.

This never occurred to me, well spotted.
We should check this, so I've created a ticket:
https://sourceforge.net/tracker/?func=detailaid=3472972group_id=73133atid=536848


 The standard build is 64-bit, but wxwidgets includes the QuickTime
 framework which is only available in 32-bit. It builds and ghc only gives a
 warning, but ghci will give an error
 (/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong
 architecture).

 To build 32-bit you can use --enable-macosx_arch=i386.

 It looks like quicktime is only used for PICT support, which is disabled
 in 64-bit builds anyway, so I made a patch that disables quicktime for both
 32 and 64 bit cocoa builds.

 By further disabling the ppc architecture, we can make a universal
 32/64-bit binary with:

 =remove -arch ppc in configure

 =remove -framework QuickTime in configure

 =remove PICT by __LP64__ - __WXOSX_COCOA__ in bitmap.c, fontenum.c,
 metafile.cpp


  ./configure --disable-debug --disable-dependency-tracking
  --with-osx_cocoa --disable-webkit
  --with-macosx-sdk=/Developer/SDKs/MacOSX10.6.sdk
  --with-macosx-version-min=10.6 --enable-universal_binary

  make install


 Note that on lion with the latest Xcode, 10.6 is the lowest sdk version.


 I use Homebrew so I attached a formula for it. To install homebrew:


  /usr/bin/ruby -e $(curl -fsSL https://raw.github.com/gist/323731)


 Then put wxosx.rb in /usr/local/Library/Formula and run:


  brew install wxosx

I'm not an OS X person, so this doesn't really mean anything to me; is
it something which should be on the wiki?




 2) wxhaskell


 installing wxc gives:

  cd wxc

  cabal install

 - error wxEVT_WEBKIT_ was not declared…

 so I disabled webkit in wxwidgets above.


 -ld: file not found: undefined

 =change -Wl,undefined to -Wl,-undefined in linkCxxOpts in Setup.hs


 installing wxcore

 -* Missing C library: wxc

 name is wxc.so instead of libwxc.dylib

 =change for sharedLibName: OSX - lib ++ addExtension basename .dylib
 in Setup.hs


  ghc --make HelloWorld.hs

 Undefined symbols for architecture x86_64:

   _expEVT_DIALUP_DISCONNECTED

 I don't know where this is coming from (dialupman is enabled in wxwidgets)
 so I commented out the DIALUP lines in wxc_glue.h


  ./HelloWorld

 - dlopen(dist/build/libwxc.dylib) failed

 The final problem is that a dylib contains an absolute paths used for
 linking, and the library is expected to be found at that locations. To set
 this path we must pass the -install_name argument when linking
 libwxc.dylib

 =      OSX - [-dynamiclib,

                   -o  ++ out_dir / sharedLibName ver basename,

                   -install_name  ++ basepath / sharedLibName ver
 basename,

                   -Wl,-undefined,dynamic_lookup]

 in linkCxxOpts, thus needing an extra basepath argument

 this is found by adding

 =        inst_lib_dir = libdir $ absoluteInstallDirs pkg_descr
 local_bld_info NoCopyDest

 to myBuildHook and also using an extra argument for linkSharedLib.

Thank you very much for the patch, but I have one tiny request:
I can't apply wxhaskell-osx.patch because the structure doesn't match
the one on my system.

Could you record it with darcs and send the patch bundle as an
attachment (darcs send -o mypatch.dpatch)
http://darcs.net/manual/Darcs_commands.html#SECTION00661000
http://darcs.net/manual/Darcs_commands.html#SECTION00664000

Also, if you record the patches your name will forever be attached to
them and you will received the karma you deserve :)



 3) using wxhaskell


 ghc --make seems to work with the limited testing that I did


 ghci error: +[NSUndoManager(NSInternal) _endTopLevelGroupings] is only
 safe to invoke on the main thread.


 ghci creates a new thread for each computation and under os x the gui
 apparently must run on the main (first) thread.

 This is solved by:

  ghci -fno-ghci-sandbox

Another good tip for the wiki perhaps?
I wonder if there is a way to indicate at a package level that this is required?


 However, keyboard input is not directed to the gui but to the ghci
 terminal…

 There used to be an EnableGUI module to fix this
 (http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X), but that does not
 seem to work anymore.

 The window can be closed and restarted from ghci though. However, the
 

Re: [wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect

2012-01-11 Thread Dave Tapley
On 11 January 2012 00:56, Dave Tapley duked...@gmail.com wrote:
 Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such that:
 1. It returns a null pointer on non-Windows platforms.
 2. It disregards the returned value and returns GetRect().

 It came in with: wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen.

 Dave,

 [1] http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535

Well, I've 'fixed' it, and it appears to work just fine in Ubuntu:
http://darcsden.com/DukeDave/wxhaskell-dev/patch/2012050758-a1f0b

I'm still curious if anyone can answer my original two questions.

--
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
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2

2012-01-10 Thread Dave Tapley
On 9 January 2012 22:19, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 On 9 January 2012 18:09, Dave Tapley dave.a.tap...@gmail.com wrote:

 On 9 January 2012 17:04, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 On 6 January 2012 16:02, Dave Tapley dave.a.tap...@gmail.com wrote:

 2012/1/6 shelarcy shela...@gmail.com


 Needless to say, I have immediately hit the wx-config roadblock, since I
 have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
 knows about debug builds.


 Welcome to the party :)
 Just for the sake of clarity, I feel obliged to question your use of the
 words release and debug; are you aware of the Debug Build Changes in
 wx3?
 Here's the news:
 http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
 (seeing the date of the post made me realise just how far behind we are,
 and also how slow the wxWidgets release cycles are!)


 I wasn't aware of the blog posting, but I did realise that there were
 changes in this area - some of this is covered in the install instructions.
 Strictly I built with:

 BUILD=release
 DEBUG_INFO=default
 DEBUG_FLAG=1


Yikes, these flags are very (imho) counter-intuitive.

Referencing a thread I have going:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/JYd4ydh6v-IJ
Vadim states that: DEBUG_FLAG is correctly set to 1 indicating that debug
code is not disabled (which is the default).
So I'm substituting  not disable with enabled and reading it as: a
release build with debugging enabled, or as you put it:

This means I keep the asserts, which seemed like an appropriate
 configuration for wxHaskell development.


What I'm not sure about here is whether the BUILD flag is superfluous
under any GCC build, or just non-Windows GCC builds. A question which I'm
asking about here:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/nfUuz_cg-HUJ

If the answer to my question there is under Windows using MSVC, and if we
accept that wxHaskell isn't going to support an MSVC build of wxWidgets
(which I get the impression is the case); then I suppose that wxC can be
completely agnostic to all the (non-libs) wxWidgets build type information
(namely: release/debug, debugging flag on/off).

Thoughts?




 That has manifested itself in this known issue with wx-config-win:
 http://code.google.com/p/wx-config-win/issues/detail?id=21

 Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
 I dutifully downloaded the free version of Visual C++ 2010 express,
 loaded the wxWidgets 2.9.3 project, built, and ran some sample code.
 However when I tried to use wx-config-win I realised that it required a
 build.cfg file, which isn't generated when you build with VC++ (I suppose
 because VC++ manages all the build settings itself, and so doesn't need to
 export anything). Without this one is unable to install wxHaskell.


 I built with gcc. I have played with VC++ in the past, because the build
 'just works' but it was really too painful to sort out the configuration.


Hazaa, I'm going to say it again:
*wxHaskell doesn't support an MSVC build of wxWidgets*

Is that the sort of message we can put out?



 I turned to the wiki and discovered this:
 http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)

 Using it as a guide (note that one can't use wxPack because there are no
 wxPack releases for the development (2.9.x) releases of wxWidgets) I was
 (almost) able to cabal install wxHaskell from my darcsden branch (it failed
 because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
 of time).


 I am leaning towards doing something with Eric's wx-config. There are a
 couple of reasons for this:

- It keeps us in control of our own destiny;
- Haskell is a *much* more pleasant implementation language for a
utility which mainly does text processing than C++.

 Does the group have an opinion on this? My feeling is that since the
 last commit to wx-config-win was in 2006, it may be a while before fixes
 come along, and even then, we will probably need to write the patches.

 Ah, well, yes..
 Firstly the pro-(wx-config-win) items:
 * I contacted the owner of wx-config-win and he made me an owner of the
 Google code project, so we're 'in charge' now.
 * I got a small discussion going on its existence in #wxwidgets on
 freenode. The consensus is that, because /most/ people use Visual Studio
 (in some flavour) to develop with wxWidgets in Windows, there simply wasn't
 the need to maintain wx-config-win. As a result it was never stable enough
 to merit merging in to the wxWidgets code base. By comparison the wx-config
 we know and love on Linux systems (and, I presume, OS X?) is essential and
 so well maintained:

 http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
 (I didn't realise until recently that it is just a shell script, copied
 in to your install dir and symlinked into your PATH).


 I did know that wx-config is just a shell script. I'm not so surprised
 that most wxWidgets

Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2

2012-01-09 Thread Dave Tapley
2012/1/8 shelarcy shela...@gmail.com

 Hi,

 I think that we can remove old-time dependency from wxcore now. Because
 wxcore uses old-time's System.Time modules in only Graphics.UI.WXCore.Db
 module, and that module is removed this version.

 I attached a patch for removing old-time dependency in Dave's wxhaskell-dev
 branch. (This patch also includes one more change that removing unused
 wxhaskell/src/eiffel directory.)


Thanks again, I've applied these to my branch also.
It's funny you should spot that unnecessary old-time dependency now,
because I spotted and removed the .Db sample code at at almost exactly the
same time (I was trying to build all the samples..):
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120107182358-a1f0b



 Best Regards,



 On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue 
 jeremy.odonog...@gmail.com wrote:

  Hi Lists,

 I am please to announce that wxHaskell 0.13.2 has just been uploaded to
 Hackage.

 This is mainly a bugfix release, although it brings a few useful changes:

   - Changes to support build under Haskell Platform 2011.4.0.0
   - OpenGL support if your wxWidgets build is configured with it
   (reinstated functionality)
   - StyledTextControl support if your wxWidgets build is configured with

   it (reinstated functionality)

 This is intended to be the final wxHaskell release supporting wxWidgets
 2.8.x.

 (snip)


 The source repository at code.haskell.org has not yet been updated with
 the
 patches. This will happen in the next day or so.


 --
 shelarcy shelarcyhotmail.co.jp
 http://page.freett.com/**shelarcy/ http://page.freett.com/shelarcy/

--
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
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2

2012-01-09 Thread Dave Tapley
On 9 January 2012 17:04, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 Hi Dave, all
 On 6 January 2012 16:02, Dave Tapley dave.a.tap...@gmail.com wrote:

 2012/1/6 shelarcy shela...@gmail.com

 2. It seems that wxcore depends on Eric's wx-config implicitly at least
 Windows environment. cabal install fail with wx-config-win binary,


 Can you remember how this failed, or send some output from the failure,
 and also let us know what version of wxWidgets you have?
 I'm hoping you say you have wx-2.9.x, in which case it could be this
 issue:
 http://code.google.com/p/wx-config-win/issues/detail?id=21

  and cabal install success with Eric's one. If wxcore depends on
 wx-config package in only Windows environment, I think we should upload
 Eric's wx-config package, and modify wxcore to denped on wx-config
 package
 on  Windows environment for workaround.

 if os(windows)
   Build-Depends: wx-config

 wx-config package isn't uploaded yet. So, I don't upload newer version,
 nor attach patch for fixing this problem.


 We're still making a decision on whether to continue using
 wx-config(-win), or to adopt Eric's one.
 I'm going to see if I can get a conversation going with the wxWidgets
 people and then I'll send out another mail.


 Now that the 0.13 branch looks like it is finished, I have pulled your
 development repo (so as to be up to date), and started to look at Windows
 support.


Excellent, I hope it's not too much of a nightmare, I played around a
little with my branch in Windows, but I'm primarily in Ubuntu.



 Needless to say, I have immediately hit the wx-config roadblock, since I
 have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
 knows about debug builds.


Welcome to the party :)
Just for the sake of clarity, I feel obliged to question your use of the
words release and debug; are you aware of the Debug Build Changes in
wx3?
Here's the news:
http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
(seeing the date of the post made me realise just how far behind we are,
and also how slow the wxWidgets release cycles are!)

That has manifested itself in this known issue with wx-config-win:
http://code.google.com/p/wx-config-win/issues/detail?id=21

Finally, just out of curiosity: Did you build wxWidgets with VC++ or gcc?
I dutifully downloaded the free version of Visual C++ 2010 express, loaded
the wxWidgets 2.9.3 project, built, and ran some sample code. However when
I tried to use wx-config-win I realised that it required a build.cfg
file, which isn't generated when you build with VC++ (I suppose because
VC++ manages all the build settings itself, and so doesn't need to export
anything). Without this one is unable to install wxHaskell.

I turned to the wiki and discovered this:
http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)

Using it as a guide (note that one can't use wxPack because there are no
wxPack releases for the development (2.9.x) releases of wxWidgets) I was
(almost) able to cabal install wxHaskell from my darcsden branch (it failed
because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
of time).


 I am leaning towards doing something with Eric's wx-config. There are a
 couple of reasons for this:

- It keeps us in control of our own destiny;
- Haskell is a *much* more pleasant implementation language for a
utility which mainly does text processing than C++.

 Does the group have an opinion on this? My feeling is that since the last
 commit to wx-config-win was in 2006, it may be a while before fixes come
 along, and even then, we will probably need to write the patches.

Ah, well, yes..
Firstly the pro-(wx-config-win) items:
* I contacted the owner of wx-config-win and he made me an owner of the
Google code project, so we're 'in charge' now.
* I got a small discussion going on its existence in #wxwidgets on
freenode. The consensus is that, because /most/ people use Visual Studio
(in some flavour) to develop with wxWidgets in Windows, there simply wasn't
the need to maintain wx-config-win. As a result it was never stable enough
to merit merging in to the wxWidgets code base. By comparison the wx-config
we know and love on Linux systems (and, I presume, OS X?) is essential and
so well maintained:

http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
(I didn't realise until recently that it is just a shell script, copied in
to your install dir and symlinked into your PATH).

And now the cons:
* It is woefully out of date. There are 18 open issues (
http://code.google.com/p/wx-config-win/issues/list) and who knows how many
undiscovered bugs.
* As mentioned, the wxWidgets community doesn't seem desperately fussed
about its existence, so long as Visual Studio is around
* It's implementation is in need of an overhaul, as identified by the
previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6)

So, in summary, I'm not sure.
My optimist, open-source heart says we should

Re: [wxhaskell-devel] [wxhaskell-users] ANN: wxHaskell 0.13.2

2012-01-06 Thread Dave Tapley
2012/1/6 shelarcy shela...@gmail.com

 Hello,

 This version has two installing problem.

 1. wxdirect's sdist dropped IOExtra module, so I can't install this
 version.
 I uploaded newer version for fixing this problem, and attached a patch
 for fixing same problem in Dave's wxhaskell-dev branch.


Good catch, thanks, I've pushed to the -dev branch.



 2. It seems that wxcore depends on Eric's wx-config implicitly at least
 Windows environment. cabal install fail with wx-config-win binary,


Can you remember how this failed, or send some output from the failure, and
also let us know what version of wxWidgets you have?
I'm hoping you say you have wx-2.9.x, in which case it could be this issue:
http://code.google.com/p/wx-config-win/issues/detail?id=21

 and cabal install success with Eric's one. If wxcore depends on
 wx-config package in only Windows environment, I think we should upload
 Eric's wx-config package, and modify wxcore to denped on wx-config package
 on  Windows environment for workaround.

 if os(windows)
   Build-Depends: wx-config

 wx-config package isn't uploaded yet. So, I don't upload newer version,
 nor attach patch for fixing this problem.


We're still making a decision on whether to continue using wx-config(-win),
or to adopt Eric's one.
I'm going to see if I can get a conversation going with the wxWidgets
people and then I'll send out another mail.

Cheers,




 Best Regards,



 On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue 
 jeremy.odonog...@gmail.com wrote:

 Hi Lists,

 I am please to announce that wxHaskell 0.13.2 has just been uploaded to
 Hackage.

 This is mainly a bugfix release, although it brings a few useful changes:

   - Changes to support build under Haskell Platform 2011.4.0.0
   - OpenGL support if your wxWidgets build is configured with it
   (reinstated functionality)
   - StyledTextControl support if your wxWidgets build is configured with

   it (reinstated functionality)

 This is intended to be the final wxHaskell release supporting wxWidgets
 2.8.x.

 Provided that you have a suitable Unicode wxWidgets 2.8 install configured
 on your machine, you should be able to install with. cabal install wx

 In the near future, we will be committing an updated wxHaskell release
 supporting wxWidgets 2.9, but this implies a number of breaking API
 changes, and the size of team supporting wxHaskell is not large enough to
 cover both. As such, this release is recommended to those who will not be
 able to move to wxWidgets 2.9 and later.

 The next release has more significant improvements planned, including
 wrapping several additional wxWIdgets libraries and restoring correct
 operation in GHCi. We do not have a formal timeline as yet, but the code
 is
 working in test repositories, and mainly needs work to make it
 cross-platform clean.

 This release has been tested on the following platforms:

   - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode,
   Release)
  - OpenGL is not enabled on the test platform, so OpenGL samples do
  not work.
  - StyledTextControl is not enabled on the test platform, so STC
  samples do not work.
  - All other sample code compiles, links and runs, but has only been

  tested for Unicode wxWidgets builds.
   - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10
  - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev,

  libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa,
 libglu1-mesa-dev,
  mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6
  - Cabal packages: strict, stm, OpenGL, cabal-install
  - OpenGL is enabled on the test platform, and the samples compile and
  run.
  - StyledTextControl is not enabled on the test platform, so STC
  samples do not work.
  - All other sample code compiles, links and runs, but has only been

  tested for Unicode wxWidgets.

 I do not have access to an OS X platform for test, so would appreciate
 feedback on any issues found by OS X users. There are known to be issues
 on
 64 bit OS X builds, which will be addressed in the next release.

 The source repository at code.haskell.org has not yet been updated with
 the
 patches. This will happen in the next day or so.


 --
 shelarcy shelarcyhotmail.co.jp
 http://page.freett.com/**shelarcy/ http://page.freett.com/shelarcy/

 --
 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
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



Re: [wxhaskell-devel] Happy New Year, wxHaskellers

2012-01-05 Thread Dave Tapley
On 4 January 2012 18:23, Eric Kow eric@gmail.com 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=detailaid=1610984group_id=7the3133atid=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-


--
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
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Happy New Year, wxHaskellers

2012-01-04 Thread Dave Tapley
On 2 January 2012 08:48, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 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
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


--
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
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Happy New Year, wxHaskellers

2012-01-04 Thread Dave Tapley
On 2 January 2012 09:22, Eric Kow eric@gmail.com 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=detailaid=1610984group_id=7the3133atid=536845https://sourceforge.net/tracker/?func=detailaid=1610984group_id=73133atid=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
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


--
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
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2012-01-03 Thread Dave Tapley
On 19 December 2011 22:02, Dave Tapley duked...@gmail.com wrote:

 On 14 December 2011 07:16, Dave Tapley duked...@gmail.com wrote:
  The only major problem remaining (aside from the woeful lack of
  testing, and support for non-Linux platforms) is you have to pass an
  rpath to the linker when compiling; so you get something like this:
 
  samples/wxcore$ ghc --make -package-conf
  ../../cabal-dev/packages-7.0.3.conf/
  -optl-Wl,-rpath,../../cabal-dev/lib/wxc-0.1/ghc-7.0.3 HelloWorld.hs


I believe I have fixed the requirement to pass an rpath with this patch:
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120103181105-a1f0b

Dave,
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2011-12-13 Thread Dave Tapley
Well, after a couple of days' frantic hacking I've made more progress,
and I'd invite anyone to comment on my decisions:

The compilation of the C++ 'wrapper' code has now been moved to a
separate project which I've called wxc.
This will now do the compilation and linking as per Jeremy's gist, and
then install the headers and the shared library (that is, install in
the cabal sense of the word).

Here's the clever part (well, I'm quite pleased with it):
Now wxcore depends on wxc, and during the wxcore configuration hook it
uses cabal to get the install information for wxc, from this it can
obtain the location of the aforementioned headers and shared library,
which can then link against.

The upshot:
1. All the C++ code is now in wxc.
2. Only wxc has to link against the wxWidgets libraries.
3. wxcore only uses the installed headers (to generate Haskell code
using wxdirect) and shared library from wxc (to link against).

The only major problem remaining (aside from the woeful lack of
testing, and support for non-Linux platforms) is you have to pass an
rpath to the linker when compiling; so you get something like this:

samples/wxcore$ ghc --make -package-conf
../../cabal-dev/packages-7.0.3.conf/
-optl-Wl,-rpath,../../cabal-dev/lib/wxc-0.1/ghc-7.0.3 HelloWorld.hs

In any case, I've pushed the changes to my darcden branch, and I
invite you to take a look:
http://darcsden.com/DukeDave/wxhaskell-dev

(Please accept my apologies for the record fail, needless to say the
change is split across two patches; I'm not happy either..)

Dave,

--
Cloud Computing - Latest Buzzword or a Glimpse of the Future?
This paper surveys cloud computing today: What are the benefits? 
Why are businesses embracing it? What are its payoffs and pitfalls?
http://www.accelacomm.com/jaw/sdnl/114/51425149/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Using a shared library for the C++ in wxhaskell

2011-12-12 Thread Dave Tapley
On 12 December 2011 17:18, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:
 Hi Dave, all,

 This is fantastic news - especially the bit about GHCi. I have put a couple
 of general comments inline, but it looks like you have found most of the
 issues, at least on Linux.

 I think that at least some of the issues would go away if, as you say,

 we could have an entirely separate cabal project (perhaps wxc) for this
 shared library, and then have wxcore depend on it?

 In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll or
 libwxc.dylib or whatever) was in a 'normal' place before wxcore gets built.

 On 9 December 2011 14:13, Dave Tapley duked...@gmail.com wrote:

 On 8 December 2011 22:34, Dave Tapley duked...@gmail.com wrote:
  Hello everyone,
 
  I wrote a story, and I invite you all to comment and help me make it
  better.
  As an experiment I've decided to put it on hpaste instead of having
  the mail thread get out of hand (I'm also cross posting it to the
  cabal list and have mentioned it in #haskell, and I want to keep all
  correspondence in one place):
  http://hpaste.org/55027

 Ha, well that was good timing for hpaste to go down!
 Here's it is:

 I've been trying to resurrect the idea of building a shared library
 for the C++ component of the wxhaskell library.

 Jeremy (to my knowledge) first put this forward, here:

 http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/

 In addition to the advantages he lists there, I have the following reason:
 When building wx-core (in its current incarnation) cabal will *always*
 rebuild all the C++ code, which takes a majority of the build time.
 This becomes very frustrating when you change one line of Haskell and
 have to wait seven minutes to rebuild.
 I complained about it here:
 http://sourceforge.net/mailarchive/message.php?msg_id=2807

 So, I decided to try and stop this complete C++ rebuild, I partially
 succeed, but I eventually got stuck for reasons I complained here:
 http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html

 Side note: I did eventually discover why (or, where) the c-sources
 (cSources) list is used to compile and link, and it is here:

 http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib
 You can see:
 | filename - cSources libBi] under -- build any C sources, and
 you can see:
 cSharedObjs = map (`replaceExtension` (dyn_ ++ objExtension))
 (cSources libBi)
 under -- link:.
 Is this assumption correct?


 This is correct - it's the standard way Cabal builds C/C++ code. To be
 honest, this is really a consequence of the fact that Cabal is more of a
 tool for simple distribution than a Make replacement, and the developers
 probably didn't expect Cabal would be used to build large bodies of C++
 code.

 My approach is far from perfect, too - in fact it is incorrect because I
 don't do dependency tracking on header files, so if you edit a header, it
 (incorrectly) fails to rebuild. This is because I wasn't keen on rewriting
 'make' in the wxHaskell build system - it seems to me like something Cabal
 could usefully support. I did play with some very hacky code which
 automatically rebuilt all of the C++ code if any header is newer than any
 C++ source. This is aesthetically dreadful, but it somewhat captures the
 reality, since in practice, pretty much all of the C++ files depend on all
 of the headers (and it's easy to write).

 On reflection, we should probably do this as what exists at present could
 lead to unexpectedly incorrect code being generated if someone is in full
 flow of development. I'll see if I can dig up some code - I think I have it
 somewhere.

You know, I'm surprised this didn't occur to me until now:
Does the C++ code actually need to use cabal at all?
If it's a separate project, perhaps it would be more sensible to use a
C++ oriented build system?
Then, unless I'm missing something, it can install the headers
somewhere, and wxcore can run wxdirect on the headers are currently.

The big disadvantage I can see with moving the C++ out of the wxcore
project is lots of pain for users when they 'cabal update' and
suddenly wxcore fails because they need to update the C++ headers /
library.

Another disadvantage is that this will make development a little more
painful (although the time saved not having to rebuild all the C++ is
a huge bonus) because you wouldn't (without some hackery) be able to
use cabal-dev as described here:
http://haskell.org/haskellwiki/WxHaskell/Development/Environment#Building_and_testing_wxHaskell

I happened upon this (dead) project, which I seems to have the goal I
am outlining:
http://wxc.sourceforge.net/


 At this point I thought about either:
 1. Getting the cabal source and starting to write code to give
 BuildInfo a cObjs in addition to cSources.
 2. Picking up Jeremy's shared library code, so wxhaskell would have
 its own code to build the library

[wxhaskell-devel] No more Eiffel

2011-11-11 Thread Dave Tapley
Firstly I'd like to say thanks to Eric for offering up these patches,
I've only been working with wxHaskell for a few months, but I must say
I wholeheartedly welcome the work; I for one don't want to see
wxHaskell go the same way as ewxw!

I just have a few requests/questions for you Eric:
1. Could you indicate exactly which patches are required (I've never
applied a darcs patch from an email, so I'm curious to try), or:
2. Are the patches available on a darcs repo somewhere?
Either way I'd like to get the de-eiffel-ification in to my darcsden
wxhaskell-devel branch[1]

3. I see that you've removed all the wxACCEL_ALT: INTEGER is 1
style constant exports; with them removed how to do the constants get
exposed in Haskell?
4. How WIP do you mean by WIP? :)


Cheers!
Dave,

[1] http://darcsden.com/DukeDave/wxhaskell-dev

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] OpenGL support

2011-10-04 Thread Dave Tapley
Hi again Jeremy,

Did the work on OpenGL, or the branch you mention on darcsden[1] ever
get anywhere?
I'd like to nominate myself to work on it :)

I've created my own wxhaskell branch on darcsden[2], to which I'm
committing all the wx-2.9 dev build / GTK2 / I don't care about
supporting wx  2.9 patches I've been accumulating over the past few
months.

[1] 
http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00925.html
[2] http://darcsden.com/DukeDave/wxhaskell-dev

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] SourceForge project

2011-10-03 Thread Dave Tapley
Hi all, would someone like to add me (davetapley) to the
SourceForge.net project.
It doesn't look like there has been much activity on it, I assume this
is just through lack of interest/development, and not because we've
moved somewhere else?

I'd like to start looking at getting OpenGL support back in, and I
thought I might as well pick up this[1] ticket if I'm going to do so.

Thanks,
Dave

[1] 
https://sourceforge.net/tracker/?func=detailatid=536848aid=2992082group_id=73133

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Wrapping wxAny

2011-09-27 Thread Dave Tapley
Hi all, I've spent a few hours now trying to wrap the wxAny class, I
just wondered if anyone had given any thought to this (or it's 2.8
predecessor: wxVariant) already?

It's needed because I'm wrapping this functionality:
http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db
(wxVariant is automatically promoted to the preferred wxAny in 2.9)

Dave,

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Wrapping wxAny

2011-09-27 Thread Dave Tapley
Hi all, I'm still struggling along with this.
I've summarised my current problem here: http://hpaste.org/51854

If any of you would be kind enough to take a look.

Dave,


On 27 September 2011 21:05, Dave Tapley duked...@gmail.com wrote:
 Hi all, I've spent a few hours now trying to wrap the wxAny class, I
 just wondered if anyone had given any thought to this (or it's 2.8
 predecessor: wxVariant) already?

 It's needed because I'm wrapping this functionality:
 http://docs.wxwidgets.org/2.9.2/classwx_property_grid_event.html#577d7fb277be169e295726878dcbb7db
 (wxVariant is automatically promoted to the preferred wxAny in 2.9)

 Dave,


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] wxString handling broken when using wx 2.9

2011-09-22 Thread Dave Tapley
On 20 September 2011 20:57, Dave Tapley duked...@gmail.com wrote:
 Hi Eric,

 Am I correct in recalling that you did some of the work to get wxHaskell
 supporting unicode?

 I've using wxHaskell with wxWidgets 2.9.2 (the latest development release)
 and it seems that any attempt to get back a wxString in Haskell code will
 result in a Prelude.chr: bad argument: crash at run time; I've verified
 that the same code works correctly with wxWidgets 2.8.

 A good example is ./samples/wx/ListCtrl.hs, you will get the crash when you
 click on an item in the list.

 Now the good news is that this is almost certainly related to the changes to
 unicode handling in wxWidgets:
 http://docs.wxwidgets.org/2.9/overview_changes_since28.html

 But I thought I'd send out a message asking for a sanity check before I get
 too busy working on fixing it.

 Dave,


Good news everyone!
This is fixed, at least for GTK2 with wx-2.9, I don't know if it
breaks building against previous versions, perhaps someone would like
to find out?

Dave,
Patch attached.


fix_for_prelude_chr_error
Description: Binary data
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Compile time for wxcore

2011-09-21 Thread Dave Tapley
On 21 September 2011 17:33, Jeremy O'Donoghue
jeremy.odonog...@gmail.com wrote:
 Hi Dave,

 On 20 September 2011 17:58, Dave Tapley duked...@gmail.com wrote:

 On 16 September 2011 23:30, Dave Tapley duked...@gmail.com wrote:

 I presume everyone has a very long compile time when building wxcore?
 Specifically rebuilding everything under src/cpp/ every time..

 Has anyone ever looked into avoiding this complete rebuild?

 I've just spent a few hours looking deeper in to this and come across two
 issues:

 1. There is a very informative blog post[1] written by Jeremy, which deals
 with the subject of Compiling C or C++ code from within Cabal.
 Unfortunately I can't find any of the code mentioned in the post in the
 project, specifically I tried to find a myBuildHook in ./wxcore/Setup.hs
 (I also looked in previous revisions using a trackdown grep[2]) but I didn't
 find anything. Perhaps someone with better knowledge of the project can
 comment on if/where/when the code in the post was used?

 The code sits on my development machine. It works, but with a fairly serious
 limitation.

 The limitation is that I do not do any dependency tracking. It works by
 checking if an object file is older than its corresponding source file. This
 works fine for .cpp files but breaks if you change a header. Short of
 writing a complete dependency tracker, this is hard to fix, and in truth I
 think it belongs in Cabal.

 If Cabal wants to say that it can compile C/C++ code, it should be the one
 to do so correctly, especially as dependency tracking for C/C++ is vile and
 compiler dependent(*).

Firstly welcome back, and thanks for taking the time to reply :)

Ah, this all makes more sense now.
Do you know if there is any documentation on cabal's C/C++ compiling abilities?
I still have no idea how the confHook stuff actually results in code
being built, because I don't see any reference to the C++ code (i.e.
wxcore/src/cpp/) in Setup.hs, only the calling of 'wxdirect' to
generate them, and use of 'libBuildInfo' to set up GCC.


 I would be very happy to put the code out there as a GitHub gist or similar
 - it's only in one or two files, and quite easy to follow, but I don't feel
 it is ready for prime time due to the limitations noted above.

Well, for me, the compile time of the C++ component is around four
minutes, which proves to be a real pain when you miss one semi-colon.
I'd certainly like to give your code a go, and I shall do so whilst
heeding your warning :)


 (*) one option might be to do this only for GCC, as in practice we only
 really support GCC anyway.

 2. Inspecting the wxdirect code you can see that System.IO.writeFile is
 used to write all the generated code[3], but no test is performed to see if
 the output file has actually changed. Thus the file is always opened for
 write, and so its modification time is changed, and so everything is
 recompiled every time wxcore is built. I have have written a local patch
 which replaces the writeFile function with one which first checks whether
 the string to be written differs (aside from date/time stamp) to the current
 one; it only performs the writeFile if there has been a change.
 Using this patch none of the Haskell code is re-built, but unfortunately
 all the C++ code is.

 This is a nice patch - I think we should apply it.

Excellent, well at the moment it's a rather 'quick' implementation,
comprising of the following function:
writeFileIfRequired :: FilePath - String - IO ()
writeFileIfRequired f str = readFile f = evaluate = \str' - when
(not $ and $ zipWith isSame (lines str) (lines str')) (writeFile f
str)
where isSame l1 l2 = (UTC `isInfixOf` l1) || (UTC `isInfixOf`
l2) || (l1 == l2)

You'll note the the use of (UTC `isInfixOf`), this is my nasty hack
to get around the fact that the time of generation is written in to
the file, and this obviously changes every time. Unless anyone has a
good reason not to, I'd like to suggest we remove this generated
on... lines (but leave in the don't edit this blurb), if someone
really wants to know they can always check the file modification time?

Dave,


 Jeremy


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Patches to build wxHaskell with wxWidgets 2.9.2 GTK on Linux

2011-07-29 Thread Dave Tapley
On 29 July 2011 08:54, Heinrich Apfelmus apfel...@quantentunnel.de wrote:

 Dave Tapley wrote:
  Hmm, further to this:
 
  $ darcs pull
  Pulling from http://code.haskell.org/wxhaskell;...
  Official wxHaskell darcs repository
  **
  No remote changes to pull in!
  $ cd wx
  $ cabal configure
  Resolving dependencies...
  Configuring wx-0.13.1...
  Warning: This package indirectly depends on multiple versions of the same
  package. This is highly likely to cause a compile failure.
  package wxcore-0.13.1 requires containers-0.3.0.0
  package wxdirect-0.13.1 requires containers-0.4.0.0
  package wxcore-0.13.1 requires parsec-2.1.0.1
  package wxdirect-0.13.1 requires parsec-3.1.1

 You may need to bump dependency version. Are you using GHC 7.0? The
 easiest way to proceed is probably to copy the version constraints from
 the *latest* packages on hackage:

   http://hackage.haskell.org/package/wx
   http://hackage.haskell.org/package/wxcore
   http://hackage.haskell.org/package/wxdirect

 and then reconfigure, rebuild and reinstall these packages.



Thank you for your response.
I actually resolved the problem in a different way, I found my don't worry,
I have fixed it email to the list sat in my drafts folder; sorry about that
:|

After some discussion on #haskell it transpired that it was a problem local
to my machine probably caused by this 'issue':
http://www.vex.net/~trebla/haskell/sicp.xhtml#pigeon

Some how I had ended up with ghc-pkg having both containers-0.3.0.0 and
containers-0.4.0.0 registered, with wxcore and wxdirect compiled again each
one respectively. By removing everything which depended on
containers-0.4.0.0 and then containers-0.4.0.0 itself I was able to rebuild
and reinstall wxdirect (only after running 'cabal clean') pinned to
containers-0.3.0.0, this allowed wx to configure without issue.

Dave,





 Best regards,
 Heinrich Apfelmus

 --
 http://apfelmus.nfshost.com



 --
 Got Input?   Slashdot Needs You.
 Take our quick survey online.  Come on, we don't ask for help often.
 Plus, you'll get a chance to win $100 to spend on ThinkGeek.
 http://p.sf.net/sfu/slashdot-survey
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Patches for wxWidgets 2.9.2 GTK2 Linux

2011-07-29 Thread Dave Tapley
On 29 July 2011 21:40, Dave Tapley duked...@gmail.com wrote:

 Hi all,

 So I can now build the latest from the wxHaskell darcs repo, but only after
 applying the attached patches.
 Quite a lot of them are very hack it to make it work patches, but I
 thought I'd offer them to the list for review before cleaning them up.

 Comments are welcome.

 Dave,


Forgot to attach.


patches_for_2.9.2_gtk2_linux
Description: Binary data
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Property sheet

2011-07-29 Thread Dave Tapley
On 29 July 2011 21:49, Dave Tapley duked...@gmail.com wrote:

 Hi Jeremy,

 Did you ever make a start wrapping wxPropertyGrid?
 http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1016

 I'm going to have a go now.

 Dave,


In my quest to understand how a class from wxWidgets is wrapped I took at
look at wxSlider as it shares the same class hierarchy as wxPropertyGrid and
'slider' is a fairly distinct term.

Searching for 'slider' in the wxHaskell code I extracted the following
references to it.
Does this look complete? If anyone could comment further on what function
each part provides I'd be very grateful.


# HAND-WRITTEN FILES #

./wx/src/Graphics/UI/WX/Controls.hs:
Haskell impl

./wxcore/src/eiffel/wx_defs.e:
Eiffel alias for wxEVT_COMMAND_SLIDER_UPDATED as
expEVT_COMMAND_SLIDER_UPDATED

./wxcore/src/include/wxc.h:
TClassDefExtend saying wxSlider95 and wxSliderMSW are wxSlider

./wxcore/src/include/wxc_glue.h:
Decl of int expEVT_COMMAND_SLIDER_UPDATED();
TClassDefExtend saying wxSlider is a wxControl
Decl of many wxSlider_ methods such as wxSlider_ClearSel
Decl of wxXmlResource_GetSlider method

./wxcore/src/haskell/Graphics/UI/WXCore/Layout.hs:
This code is commented out

./wxcore/src/haskell/Graphics/UI/WXCore/Events.hs:
Exports sliderOnCommand, sliderGetOnCommand
Def for sliderOnCommand which sends wxEVT_COMMAND_SLIDER_UPDATED and take an
eventHandler
Def for sliderGetOnCommand which returns the event handler

./wxcore/src/cpp/extra.cpp:
ifdef wxUSE_SLIDER  wxT(SLIDER)

./wxcore/src/cpp/eljslider.cpp:
EWXWEXPORT calls for all the wxSlider_ methods decl'd in wxc_glue.h

./wxcore/src/cpp/eljrc.cpp:
BUILD_XRCGETCTRL_FN(Slider) (constructs functions for geting control
pointers out of window hierarchies created from XRC files. The functions
themselves)

./wxcore/src/cpp/defs.cpp:EWXWCONSTANTINT(wxEVT_COMMAND_SLIDER_UPDATED,wxEVT_COMMAND_SLIDER_UPDATED)

./wxcore/src/cpp/eljevent.cpp:
MAKE_EVENT_WRAPPER(EVT_COMMAND_SLIDER_UPDATED)


# MISC FILES #

./wxcore/wxcore.cabal:
add src/cpp/eljslider.cpp to c-sources

./samples/test/XRCControls/XRCControls_Wx.hs:
test code for xrc


# GENERATED FILES #

./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:
File generated by wxDirect from ./wxcore/src/include/wxc.h:
Export of (wxEVT_COMMAND_SLIDER_UPDATED :: EventId)
Export of many slider functions such as sliderClearSel, these match the
wxSlider_ methods decl'd in wxc_glue.h
Export of xmlResourceGetSlider function decl'd in wxc_glue.h
Definition for slider functions using FFI foreign import ccall
Definition of wxEVT_COMMAND_SLIDER_UPDATED which imports the enum value
Definition of xmlResourceGetSlider using FFI foreign import ccall

./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs:
File generated by wxDirect
Export of classSlider, classSlider95, classSliderMSW
Export of downcastSlider, downcastSlider95, downcastSliderMSW
Definition classSlider functions which bind them to the their C++ class
names using a classInfoFindClass function
Definition of downcast functions using an objectCast function

./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs:
File generated by wxDirect from ./wxcore/src/include/wxc.h:
Exports Slider, TSlider, CSlider, and 95 and MSW variants
Definitions of these as data types, encapsulating the class hierarchy from
C++ classes. TSlider is the inheritance type, CSlider is the abstract type.
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Conflicting exports in wxcore

2011-07-28 Thread Dave Tapley
Yep, I see this¹ as well, I'll take a look now.

Dave,


¹ http://sourceforge.net/mailarchive/message.php?msg_id=27810904
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Patches to build wxHaskell with wxWidgets 2.9.2 GTK on Linux

2011-07-27 Thread Dave Tapley
Please find attached a darcs patch file with the changes I had to make to
build wxcore.
Feel free to have a look and comment, they are all very much make it
compile changes and I suspect I may have introduced badness (returning a
null pointer).

Unfortunately having made these changes and following these steps¹ I am now
getting this error, which is a little confusing:

wxhaskell-dev/wx$ sudo cabal install --global
Resolving dependencies...
cabal: dependencies conflict: wxcore-0.13.1 requires containers ==0.4.0.0
however
containers-0.4.0.0 was excluded because wxcore-0.13.1 requires containers
==0.3.0.0

Its other dependencies have installed correctly:
wxhaskell-dev/wx$ ghc-pkg list wxdirect
/var/lib/ghc-6.12.1/package.conf.d
   wxdirect-0.13.1

wxhaskell-dev/wx$ ghc-pkg list wxcore
/var/lib/ghc-6.12.1/package.conf.d
   wxcore-0.13.1


Any idea what this could mean?

Dave,

¹ http://haskell.org/haskellwiki/WxHaskell/Building#Source_Release


patches_for_2.9.2_gtk_linux
Description: Binary data
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with

2011-07-26 Thread Dave Tapley
On 26 July 2011 06:59, Eric Y. Kow eric@gmail.com wrote:

 On Tue, Jul 26, 2011 at 00:28:01 +0100, Dave Tapley wrote:
  I'm getting the impression that most people are using wxWidgets 2.9 with
  wxHaskell, is that a fair assumption?

 I was surprised by your impression, but now I see why you may feel that
 way.

 It turns out wxWidgets 2.9 was released early this month, on 2011-07-05.
 This makes it a bit more urgent for wxhaskell to support both (good
 thing Jeremy was working so furiously on that)


This impression came primarily from the fact that I couldn't build wxhaskell
again wxWidgets 2.8 (for the reasons I've sent other messages to the list).
Unfortunately it seems it also won't build against the 2.9.2 dev release,
but I'll post a separate message about that.



  I've just grabbed the latest dev release (2.9.2) of wxWidgets because I'm
  still getting errors trying to compile against the 2.8.10 version I got
 from
  the Ubuntu repositories (I'm going to post about those errors separately)
  and I'd just like to get something working.

 If you just want something that works, use wxWidgets 2.8 and the
 stable version of wxHaskell.


Well, there are some features in wxWidgets which aren't supported by
wxHaskell, so I was rather hoping to get it building so I can contribute to
the project :)



 --
 Eric Kow http://erickow.com

--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with

2011-07-26 Thread Dave Tapley
On 26 July 2011 09:15, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:

 On 26 July 2011 06:59, Eric Y. Kow eric@gmail.com wrote:

 On Tue, Jul 26, 2011 at 00:28:01 +0100, Dave Tapley wrote:
  I'm getting the impression that most people are using wxWidgets 2.9 with
  wxHaskell, is that a fair assumption?

 I was surprised by your impression, but now I see why you may feel that
 way.


 I think there's something of a mix. There are probably more wxWidgets 2.8
 users out there, but most people don't install unless something has broken -
 say a new HP version comes out. I started to look at support for 2.9 when
 people started asking for 2.9 features. In particular, I believe that 2.9
 can be compiled as a 64 bit library on newer Macs.


 It turns out wxWidgets 2.9 was released early this month, on 2011-07-05.
 This makes it a bit more urgent for wxhaskell to support both (good
 thing Jeremy was working so furiously on that)


 Hmmm. Nice to hear you say it, but truth be told, I rarely have the time to
 work 'furiously' on wxHaskell :-( Most work happens on intercontinental
 flights (good news: I have another one coming up in a couple of weeks).

 We have never had a good story for support of multiple versions, in part
 because wxdirect doesn't support conditional compilation, which means that
 we can't put #ifdefs around version/platform dependent parts of wxC headers.
 In the past we've sort of fudged the issue by officially supporting only one
 version, but I don't think that's a tenable position any longer.

 Eric's Haskell version of wx-config will help the 'library' aspect -
 especially if we start to use wxPack on Windows, so we can rely on having
 the libraries built in a specific way. We will need to make it work for 2.9
 and 2.8 though - I think these will need to coexist for a while yet. I
 looked at fixing the existing wx-config source for 2.9 (ISTR it's in C++),
 but looking at the code I lost the will to live. It's rather, err, verbose.
 Haskell would be much better.

 I did sort-of warn the list that 2.9 work would likely destabilize the tip
 for a while. Perhaps we should do this work in a branch (I've never tried
 this in Darcs - how easy is it Eric?)

 Jeremy


Let me know if there's any way I can help.
I'm going to be relying on wxHaskell in the immediate future so I'm keen to
familiarise myself with it because I suspect there are some 2.9 features I
need which aren't implemented in wxHaskell presently.
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04

2011-07-26 Thread Dave Tapley
On 26 July 2011 00:41, Dave Tapley duked...@gmail.com wrote:

 On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.comwrote:

 Hi all,

 On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:

 On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
  A very good suggestion.
  I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
 
  Do we know why this fix is in the release, but not in darcs?

 I suspect the answer lies somewhere in here:

  darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
  --match 'hunk 45999'


 The answer is that it comes from my clean-up for wxWidgets 2.9, and is
 probably a case of being over-zealous. The problem wasn't caught because
 (most likely) no-one built tip for Gtk. It's not an environment I have
 readily available to me.

 I'm not sure that there is a straightforward way to get similar behaviour
 on Gtk, so I think the only clean solution is to revert the old 'NULL'
 implementation. What do you think?

 EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
 width,int height)
 {
 #if (wxVERSION_NUMBER = 2900)
 wxBitmapType bm_type = (wxBitmapType) type;
 #else
 long bm_type = type;
 #endif

 #ifdef __WXGTK__
  // See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
 return NULL;
 #else
 return new wxCursor(*name, bm_type, width, height);
 #endif
 }

 Regards
 Jeremy


 Having made these modifications I now get passed that error, but stumble on
 this: http://hpaste.org/49525
 Does anyone have any intuition why these files could be missing?



Hmm, I've switched to the 2.9.2 dev release of wxWidgets and I'm getting a
similar failures with:
Both with the latest wxHaskell in hackage: http://hpaste.org/49563
And with the latest from darcs: http://hpaste.org/49564

Does anyone have any suggestions as to a fix, or a more reliable build set
up?

Thanks,
Dave
--
Got Input?   Slashdot Needs You.
Take our quick survey online.  Come on, we don't ask for help often.
Plus, you'll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04

2011-07-25 Thread Dave Tapley
On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:

 Hi all,

 On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:

 On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
  A very good suggestion.
  I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
 
  Do we know why this fix is in the release, but not in darcs?

 I suspect the answer lies somewhere in here:

  darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
  --match 'hunk 45999'


 The answer is that it comes from my clean-up for wxWidgets 2.9, and is
 probably a case of being over-zealous. The problem wasn't caught because
 (most likely) no-one built tip for Gtk. It's not an environment I have
 readily available to me.

 I'm not sure that there is a straightforward way to get similar behaviour
 on Gtk, so I think the only clean solution is to revert the old 'NULL'
 implementation. What do you think?

 EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
 width,int height)
 {
 #if (wxVERSION_NUMBER = 2900)
 wxBitmapType bm_type = (wxBitmapType) type;
 #else
 long bm_type = type;
 #endif

 #ifdef __WXGTK__
  // See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
 return NULL;
 #else
 return new wxCursor(*name, bm_type, width, height);
 #endif
 }

 Regards
 Jeremy


Well, the 2.9.2 dev release¹ appears to include that constructor (in
include/wx/gtk/cursor.h) if wxUSE_IMAGE is set.
So perhaps we should check that?


¹ http://www.wxwidgets.org/downloads/#latest_dev
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Specifying wxWidgets version to build wxHaskell with

2011-07-25 Thread Dave Tapley
I'm getting the impression that most people are using wxWidgets 2.9 with
wxHaskell, is that a fair assumption?

I've just grabbed the latest dev release (2.9.2) of wxWidgets because I'm
still getting errors trying to compile against the 2.8.10 version I got from
the Ubuntu repositories (I'm going to post about those errors separately)
and I'd just like to get something working.

I have configure'd and make'd 2.9.2, I didn't want to make install because I
don't want it to conflict with the 2.8.10 version.

I see that the wxHaskell's Setup.hs uses wx-config, but I don't see any way
to specify a prefix to wx-config, so I was just wondering how you guys get
wxHaskell to build using a specific version of wxHaskell? The only approach
I can see is to make sure the wx-config in your path in a symlink and that
it points to the wxWidgets library you want to use.

Thanks, Dave
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04

2011-07-25 Thread Dave Tapley
On 25 July 2011 15:49, Jeremy O'Donoghue jeremy.odonog...@gmail.com wrote:

 Hi all,

 On 25 July 2011 07:45, Eric Y. Kow eric@gmail.com wrote:

 On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
  A very good suggestion.
  I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
 
  Do we know why this fix is in the release, but not in darcs?

 I suspect the answer lies somewhere in here:

  darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
  --match 'hunk 45999'


 The answer is that it comes from my clean-up for wxWidgets 2.9, and is
 probably a case of being over-zealous. The problem wasn't caught because
 (most likely) no-one built tip for Gtk. It's not an environment I have
 readily available to me.

 I'm not sure that there is a straightforward way to get similar behaviour
 on Gtk, so I think the only clean solution is to revert the old 'NULL'
 implementation. What do you think?

 EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
 width,int height)
 {
 #if (wxVERSION_NUMBER = 2900)
 wxBitmapType bm_type = (wxBitmapType) type;
 #else
 long bm_type = type;
 #endif

 #ifdef __WXGTK__
  // See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
 return NULL;
 #else
 return new wxCursor(*name, bm_type, width, height);
 #endif
 }

 Regards
 Jeremy


Having made these modifications I now get passed that error, but stumble on
this: http://hpaste.org/49525
Does anyone have any intuition why these files could be missing?
--
Storage Efficiency Calculator
This modeling tool is based on patent-pending intellectual property that
has been used successfully in hundreds of IBM storage optimization engage-
ments, worldwide.  Store less, Store more with what you own, Move data to 
the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Building wxcore on Ubuntu 10.04

2011-07-22 Thread Dave Tapley
Hmm, unfortunately whilst cabal configure now completes successfully, I am
having a problem when doing cabal build, see output below. Could it be
related to this:
http://comments.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/298  ?

src/cpp/eljcursor.cpp:23:0:
 error: no matching function for call to ‘wxCursor::wxCursor(wxString,
long int, int, int)’

/usr/include/wx-2.8/wx/gtk/cursor.h:31:0:
 note: candidates are: wxCursor::wxCursor(const char*, int, int, int,
int, const char*, const wxColour*, const wxColour*)

/usr/include/wx-2.8/wx/gtk/cursor.h:29:0:
 note: wxCursor::wxCursor(const wxImage)

/usr/include/wx-2.8/wx/gtk/cursor.h:27:0:
 note: wxCursor::wxCursor(int)

/usr/include/wx-2.8/wx/gtk/cursor.h:26:0:
 note: wxCursor::wxCursor()

/usr/include/wx-2.8/wx/gtk/cursor.h:23:0:
 note: wxCursor::wxCursor(const wxCursor)





On 21 July 2011 23:00, Dave Tapley dave.a.tap...@gmail.com wrote:

 That was exactly the problem!

 Thank you very much Eric :)

 Dave,




 On 21 July 2011 22:44, Eric Y. Kow eric@gmail.com wrote:

 Hi Dave,

 On Thu, Jul 21, 2011 at 21:54:11 +0100, Dave Tapley wrote:
  I am having trouble compiling wxcore on Ubuntu 10.04.
  The source I am using I pulled with a darcs get from hackage, I then
  descended into the wxcore directory and did a cabal configure.

 I suspect that recent minor changes to our Setup.hs file have
 broken compatibility with wxWidgets 2.8.

 Could you try

  darcs obliterate -p Additional libraries required by wxWidgets 2.9

 and see if it has any result?

 Alternatively, if you just want a working wxHaskell and aren't
 particularly interested in debugging this sort of thing, I'd
 suggest just doing cabal install wx and fetching the one on
 hackage for now.

 Thanks!

 --
 Eric Kow http://erickow.com



--
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks  Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Building wxcore on Ubuntu 10.04

2011-07-21 Thread Dave Tapley
Hi all,

I am having trouble compiling wxcore on Ubuntu 10.04.
The source I am using I pulled with a darcs get from hackage, I then
descended into the wxcore directory and did a cabal configure.

It gives me a * Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8,
wx_baseu_xml-2.8... error,
I have the .so files for libwx_baseu-2.8.so in my /usr/lib, but I don't
have any headers in /usr/include, could this be a problem?
If so then does anyone know where I can obtain these headers? I have already
installed the libwxbase2.8-dev and libwxgtk2.8-dev packages.

Running cabal configure -v3 I can see the first problem is this:
/usr/bin/ld: cannot find -lwxmsw28ud_media
Is it safe to assume that msw refers to MS Windows? If so should I be
trying to link against this when building in Linux?

I have pasted the full output from cabal configure -v3 here:
http://hpaste.org/49326

Thanks,
Dave
--
5 Ways to Improve  Secure Unified Communications
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways
to interact with customers and streamline customer service. Learn more!
http://www.accelacomm.com/jaw/sfnl/114/51426253/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel