Re: [wxhaskell-devel] wxHaskell vs GHCi

2013-10-08 Thread Jeremy O'Donoghue
When I last looked at the problem, the issue was that wxWidgets libraries
use static constructors and destructors in some places.

Problem with static constructors is that they typically run before main() -
or its equivalent - is called. This means that once you quit an
application, there is no way to restart without relaunching executable.

Similarly, static destructors only run after app has called exit().

There were a couple of approaches I considered:
* Implement a wrapper which forces dynamic load and unload of the wxWidgets
libraries from inside wxc. This would work because when reloading the
libraries (as you would when restarting app at GHCi), the static
constructors run (e.g. in Windows they usually run just before DllMain() is
called). This is easy, but very tedious to do in practice, and would only
really make sense if the wxWidgets bindings are auto-generated.

* Fake application exit when running in GHCi so that when app starts again
the same event loop is used, and the static destructors are never called.
This would be a very neat solution, but state management is very tricky.

Regards
Jeremy

On 7 October 2013 06:53, Eric Kow eric@gmail.com wrote:

 I couldn't find a relevant bug on the wxHaskell tracker (all were closed)
 Perhaps it'd be worthwhile creating a new ticket for the problems
 Conal was facing? (they are very old problems, if I remember
 correctly).

 Do we even know what the issue is about?

 On 6 October 2013 20:54, Henk-Jan van Tuyl hjgt...@chello.nl wrote:
  On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow eric@gmail.com wrote:
 
  Just thought I might call your attention to this thread:
 
 http://www.haskell.org/pipermail/haskell-cafe/2013-September/109022.html
 
  GHCi support seems like something that might be worth bubbling up the
  agenda?
 
 
  Shouldn't GHCi support be all right with the next GHC release? Did
 someone
  try a nightly build of GHC to test this? There are no nightly builds for
  Windows, and I can't get GHC compiled, so I cannot test this.
 
  Regards,
  Henk-Jan van Tuyl
 
 
  --
  Folding@home
  What if you could share your unused computer power to help find a cure?
 In
  just 5 minutes you can join the world's biggest networked computer and
 get
  us closer sooner. Watch the video.
  http://folding.stanford.edu/
 
 
  http://Van.Tuyl.eu/
  http://members.chello.nl/hjgtuyl/tourdemonad.html
  Haskell programming
  --



 --
 Eric Kow http://erickow.com


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Compile problems

2013-06-17 Thread Jeremy O'Donoghue
wxdirect does not support conditional compilation, I'm afraid. It's a large
part of the reason why there are separate branches for wxWidgets 2.8 and
2.9.

Adding a real C preprocessor to wxdirect is a pretty large task.

The usual approach we have used in the past is:
* Define function in the header read by wxdirect
* Define a 'NULL' implementation as well as the correct one, e.g.

In wxc_glue.h
int wxSomeClass_GetSomeParam( TSelf(wxSomeClass), int param1, int param2);

in SomeClass.cpp
EWXWEXPORT(int,wxSomeClass_GetSomeParam)(wxSomeClass* self, int param1, int
param2)
{
#if (wxVERSION_NUMBER  2900)
return 0;
#else
// Do the real wrapping
#endif
}

This is far from ideal, but it is the simplest workaround to get things
compiling. You can use wxCHECK_VERSION above as well - I think the logic is
inverted, but the code is otherwise similar.

Jeremy


On 9 June 2013 21:52, Charles the Hawk charlestheh...@yahoo.com wrote:

 At first I installed the 90.0.1 from the older site.  I had to modify
 wxdirect to do an import Foreign.C.Types to get rid of the arg type
 errors and change the pointer assignment in eljpen.cpp that others have
 mentioned.  It was working fine so I installed the 90.1 from Atze's repo
 into a sandbox as described in the wiki.  I thought I changed the path
 to use the 90.1 wxdirect but it's possible the older modified wxdirect
 was running.  I'll try to play around with it some tomorrow and make
 sure my modified wxdirect isn't being run.  But I definitely had to
 change all the CHECK_VERSIONs to 2,9,4 or they could be commented out as
 Blair suggested.

 I think we need to decide what to do on conditional compiles. Either 1)
 modify wxdirect to handle them (way over my head), 2) no conditionals in
 the headers wxdirect processes which also means to leave out any new
 function not in a specific lower version, or 3) require a specific
 higher version.  It seems to me that #2 is probably the simplest and
 thus best way to go as that should work on more installs without
 requiring modifications unless it turns out that SetDeviceClippingRegion
 is actually required in 2.9.4 installs.

 On 06/09/2013 07:31 PM, harry wrote:
  Blair Archibald mrblairarchibald@... writes:
 
  I used this repo: https://github.com/atzedijkstra/wxHaskell
  Using wxWidgets 2.9.4, and GHC 7.6.3 the only change needed is in
  wxc/src/cpp/eljdc.cpp line 214 (the #if wxCHECK_VERSION(2,9,5) should be
  commented out - or at least had to be on my setup.
  Then a simple: cabal install ./wxdirect ./wxc ./wxcore ./wx
  Should hopefully get you up and running, let me know how it goes.
  I used that one as well, and got a ton of Unacceptable argument type in
  foreign declaration errors, perhaps related to
  http://hackage.haskell.org/trac/ghc/ticket/5610.
 
 
 
 --
  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
  wxhaskell-devel@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel



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

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Project ownership and Hackage upload

2013-06-14 Thread Jeremy O'Donoghue
Hi all,

My sincere apologies for lack of availability and presence over the past
few months - due almost entirely for being the software technology lead for

http://www.tomshardware.com/news/Qualcomm-Atheros-NFC-Near-Field-QCA1990-Snapdragon,19607.html.
Not much Haskell there, unfortunately.

Atze, Henk-Jan, Harry  Eric, my thanks for making the efforts you have.
Atze, you have my blessing to take over as lead maintainer and I wish you
the best of luck. I am happy to make the announcement myself if you prefer
- otherwise please go ahead.

When I have the time, I will be happy to continue to contribute - this is
unlikely to be the case for a few months yet, unfortunately. I am also
happy to offer up control of the current wxhaskell repo that I own, if it
saves the complication of editing wiki entries etc. Please let me know.

Very best regards
Jeremy




On 13 June 2013 22:59, Henk-Jan van Tuyl hjgt...@chello.nl wrote:

 On Thu, 13 Jun 2013 23:24:31 +0200, Eric Kow eric@gmail.com wrote:

  So it's been a week since Atze has agreed to take on maintainership of
  wxHaskell.  Shall we perhaps make it official with an announcement

 That's fine with me.

 Regards,
 Henk-Jan van Tuyl


 --
 Folding@home
 What if you could share your unused computer power to help find a cure? In
 just 5 minutes you can join the world's biggest networked computer and get
 us closer sooner. Watch the video.
 http://folding.stanford.edu/


 http://Van.Tuyl.eu/
 http://members.chello.nl/hjgtuyl/tourdemonad.html
 Haskell programming
 --


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] wxc/ore? linking problem

2012-06-27 Thread Jeremy O'Donoghue
There are a couple of possibilities:

1) (which I think can be discounted, given your description of 'removed
everything and started again') is that you didn't do a clean build. The
dependency checking for wxc is rather fragile (bacause Cabal does not know
about C dependencies).
2) More likely: the latest version of wxcore on Github is 0.90.0.3 - this
was bumped when I messed up some dependencies in one of the releases (I
didn't notice because *I* hadn't cleaned up properly before testing. Have
you tried pulling from the tip of the master branch on Github in the past
few days (I commited the updates to Github on June 10th - haven't updated
cabal yet as I have been too busy - will try to do so this evening (UK
time).

In other words, I think this may be my fault, for which my sincere
apologies.

Best regards
Jeremy

On 27 June 2012 13:38, Henry Lockyer henry.lock...@ntlworld.com wrote:

 Hello - is this a fault with wxc (or associates) ?

 Cannot build Eric's wxcore 'HelloWorld' (from
 https://raw.github.com/jodonoghue/wxHaskell/master/samples/wxcore/HelloWorld.hs
  )
 due to Undefined symbols.

 This is based on an i86_64-only wxWidgets 2.9.3 build on mac os 10.6.8
 snow leopard with xcode 3.2.6 and with ghc 7.0.4  (HP 2011.4.0.0 64).

 I discovered some legacy mess in the local pkg installations so removed
 everything from --user pkgs and rebuilt it all again
 cleanly with cabal install, with no apparent errors at this stage. The
 install looks fine now but I still get the same error and am now stuck..

 Henrys-iMac:wxcore henrylockyer$ ghc HelloWorld
 [1 of 1] Compiling Main ( HelloWorld.hs, HelloWorld.o )
 Linking HelloWorld ...
 Undefined symbols:
   _wxListItemAttr_SetTextColour, referenced from:
   _s15xV_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_Create, referenced from:
   _sWbY_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sWcg_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetBackgroundColor, referenced from:
   _s1Bis_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2Jgb_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_RefreshItem, referenced from:
   _s1C5g_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2HVB_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemAttrCallback, referenced from:
   _s1BFE_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IEM_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_Create, referenced from:

 _wxcorezm0zi90zi0zi1_GraphicsziUIziWXCoreziWxcClassesAL_listItemAttrCreate1_info
 in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemColumnImageCallback, referenced from:
   _s1BE8_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IGA_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_CreateEx, referenced from:
   _sUn6_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sUng_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_CreateWithCb, referenced from:
   _sW0i_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sW0E_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_IsVirtual, referenced from:
   _s1C6N_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2HTp_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_GetItemFont, referenced from:
   _s1Cz0_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2H2z_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_SetFont, referenced from:
   _s15BK_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s15BO_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemImageCallback, referenced from:
   _s1BCC_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IIo_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetTextColor, referenced from:
   _s1BfQ_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2JjR_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetFont, referenced from:
   _s1Bh9_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2Ji1_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_HasFont, referenced from:
   _s1Bdd_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2JnT_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_SetBackgroundColour, referenced from:
   _s15Gu_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemTextCallback, referenced from:
   _s1BB6_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IKc_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_HasTextColour, referenced from:
   _s1BbT_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2Jq5_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_HasBackgroundColour, referenced from:
   _s1Bex_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)

Re: [wxhaskell-devel] wxc/ore? linking problem

2012-06-27 Thread Jeremy O'Donoghue
I think you did the right thing. We'll debug further if the Cabal update
doesn't work for you.

Regards
Jeremy

On 27 June 2012 16:46, Henry Lockyer henry.lock...@ntlworld.com wrote:

 ok + thanks. I guess I'll wait for updated cabal if it is imminent .
 Re (1) I could double-check this in the meantime perhaps, but what to look
 for exactly?
 (I relied on cabal install wx cabal-macosx on an empty local user pkg
 lib to get it right.)
 Regards/ Henry

 On 27 Jun 2012, at 15:28, Jeremy O'Donoghue wrote:

 There are a couple of possibilities:

 1) (which I think can be discounted, given your description of 'removed
 everything and started again') is that you didn't do a clean build. The
 dependency checking for wxc is rather fragile (bacause Cabal does not know
 about C dependencies).
 2) More likely: the latest version of wxcore on Github is 0.90.0.3 - this
 was bumped when I messed up some dependencies in one of the releases (I
 didn't notice because *I* hadn't cleaned up properly before testing. Have
 you tried pulling from the tip of the master branch on Github in the past
 few days (I commited the updates to Github on June 10th - haven't updated
 cabal yet as I have been too busy - will try to do so this evening (UK
 time).

 In other words, I think this may be my fault, for which my sincere
 apologies.

 Best regards
 Jeremy

 On 27 June 2012 13:38, Henry Lockyer henry.lock...@ntlworld.com wrote:

 Hello - is this a fault with wxc (or associates) ?

 Cannot build Eric's wxcore 'HelloWorld' (from
 https://raw.github.com/jodonoghue/wxHaskell/master/samples/wxcore/HelloWorld.hs
  )
 due to Undefined symbols.

 This is based on an i86_64-only wxWidgets 2.9.3 build on mac os 10.6.8
 snow leopard with xcode 3.2.6 and with ghc 7.0.4  (HP 2011.4.0.0 64).

 I discovered some legacy mess in the local pkg installations so removed
 everything from --user pkgs and rebuilt it all again
 cleanly with cabal install, with no apparent errors at this stage. The
 install looks fine now but I still get the same error and am now stuck..

 Henrys-iMac:wxcore henrylockyer$ ghc HelloWorld
 [1 of 1] Compiling Main ( HelloWorld.hs, HelloWorld.o )
 Linking HelloWorld ...
 Undefined symbols:
   _wxListItemAttr_SetTextColour, referenced from:
   _s15xV_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_Create, referenced from:
   _sWbY_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sWcg_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetBackgroundColor, referenced from:
   _s1Bis_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2Jgb_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_RefreshItem, referenced from:
   _s1C5g_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2HVB_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemAttrCallback, referenced from:
   _s1BFE_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IEM_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_Create, referenced from:

 _wxcorezm0zi90zi0zi1_GraphicsziUIziWXCoreziWxcClassesAL_listItemAttrCreate1_info
 in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemColumnImageCallback, referenced from:
   _s1BE8_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IGA_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_CreateEx, referenced from:
   _sUn6_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sUng_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_CreateWithCb, referenced from:
   _sW0i_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _sW0E_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_IsVirtual, referenced from:
   _s1C6N_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2HTp_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrl_GetItemFont, referenced from:
   _s1Cz0_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2H2z_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_SetFont, referenced from:
   _s15BK_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s15BO_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListCtrlVirtual_SetOnGetItemImageCallback, referenced from:
   _s1BCC_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2IIo_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetTextColor, referenced from:
   _s1BfQ_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2JjR_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_GetFont, referenced from:
   _s1Bh9_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2Ji1_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_HasFont, referenced from:
   _s1Bdd_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _s2JnT_info in libHSwxcore-0.90.0.1.a(WxcClassesAL.o)
   _wxListItemAttr_SetBackgroundColour, referenced from

[wxhaskell-devel] GitHub repo?

2012-04-17 Thread Jeremy O'Donoghue
Hi developers,

I wanted to canvas opinion about moving wxHaskell development from darcs on
code.haskell.org to (git, obviously) on GitHub.

Potential advantages:

   - Easier for new committers to commit code
   - GitHub provides some pretty decent tools (integrated issue tracker,
   particularly)
   - Easier handling of the wxWidgets 2.8/2.9 branches. I'm pretty
   impressed at the way git does this (and was not impressed by merging Dave
   Tapley's darcsden branch back into the code.haskell.org mainline using
   darcs - this turned out to be a completely manual operation which was no
   fun at all).

Downsides:

   - I personally find darcs easier than git, and as Haskellers we should
   promote darcs if possible
   - Possibly a new tool for old hands to learn

I would say that a move is probably only worthwhile if we think that it
would help to attract new developer to the project.

I have put up an experimental project at
https://github.com/jodonoghue/wxHaskell which gives an idea how the two
branches would look.

One option might be to use wxHaskell as a test case for darcs-bridge, in
which case we could allow commits to darcs or Github, but I'll leave it to
Eric to decide whether darcs bridge is ready for such a use case.

Regards

Jeremy
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] Darcs repo versions

2012-02-12 Thread Jeremy O'Donoghue
Hi Eric,

I was going to start merging the current state of wxHaskell support for
wxWidget 2.9 back into the mainline at c.h.o... then I discovered a problem.

Becuse Darcsden uses the darcs 2.0 repo format (not the hashed format), I
cannot push patches from my local copy of Dave's Darcsden to my local c.h.o
(which is using the hashed repo format).

Recreating the patches and their comments by hand would be inexpressibly
tedious, so I wanted to know if there is any reason not to upgrade the
c.h.o repo to the 2.0 format. If I understand things correctly, this has
been the Darcs default since 2008, and it would let us

Any suggestions, advice or warnings before I start along this path?

Thanks
Jeremy
--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
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-02-01 Thread Jeremy O'Donoghue
Hi Paulo

[Replying to all]
First, apologies that it has taken so long for you to fail to get going. I
am going to try to cover both wxWidgets 2.8.12 and 2.9.x approaches in the
same mail. Please feel free to choose whichever you prefer. I assume that
you are working on Windows, based on the output you have pasted.
On 1 February 2012 16:03, Paulo Pocinho poci...@gmail.com wrote:

 Trying to follow up with the latest stable version of wxHaskell 0.13.2
 (based on wxWidgets 2.8.12). I run straight into trouble using the
 wx-config tool, preventing me to update the package - it does not
 work.


On Windows there is no wx-config supplied with wxWidgets. There is a
workaround, which is to use wx-config-win (found at
http://code.google.com/p/wx-config-win/). This is a C++ implementation of
wx-config for Windows targets. The version on Google Code is OK for use
with wxHaskell 0.13.2, but does not work for the latest code.

You need to make sure that the WXWIN environment variable is pointing to
your wxWidgets install and that WXCFG points to the directory containing
your build.cfg. In my case (i.e. what I have tested) this is gcc_dll\mswu.

If you have the above configuration with wx-config.exe from the Google code
site, cabal install wx should work.


 Then I found out about the latest development. Pulled the sources from
 http://darcsden.com/kowey/wxhaskell - packed and installed that
 wx-config with cabal and still no luck.


This one won't work - it has only been tested for wxWidgets 2.9.x - and we
probably won't use it moving forward, as it needs quite a bit of work to
make it function completely correctly.


 As last resort, I checked out from Dave Tapley. Patched it with
 Jeremy's diff and tried to build that version against wxWidgets 2.9
 (compiled from svn sources). Now, I am lost in a circular dependency:




 E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcorecabal
 configure
 Resolving dependencies...
 Configuring wxcore-0.14...
 setup.exe: At least the following dependencies are missing:
 wxc -any

 E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcorecd ..\wxc

 E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxccabal configure
 Resolving dependencies...
 Configuring wxc-0.1...
 setup.exe: This version of wxcore requires wx 2.9 to be available


This is the root of your problem.

A couple of possibilities:

   1. You may have WXWIN and WXCFG environment variables pointing to your
   wxWidgets 2.8.x install (or not pointing anywhere at all)
   2. You need the updated version of wx-config-win I put together to get
   all of the correct configuration data for a wxWidgets 2.9 configuration.If
   you don't have it, it was attached to the following message:
   http://article.gmane.org/gmane.comp.lang.haskell.wxhaskell.devel/807 .
   You will need to compile(*) the CPP file. If you don't have a C++ compiler,
   I can also send you an executable - assuming that none of the mail tools
   block it, that is.



(*) Nothing very difficult. I think gcc -o wx-config.exe wx-config-win.cpp
should do it.



 E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxccd ..\wx

 E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxcabal configure
 Resolving dependencies...
 Configuring wx-0.14...
 cabal: At least the following dependencies are missing:
 wxcore =0.14

 It's been a great adventure though. Thanks for everyone working on this!


 On 31 January 2012 16:32, Jeremy O'Donoghue jeremy.odonog...@gmail.com
 wrote:
  Hi all,
 
  Attached are patches which enable me to build and Dave's repo on
 Windows. I
  have built and run most of the samples and test cases (including OpenGL,
 STC
  and PropertyGrid)
  I also included Nicholas Tung's patch from a couple of days back to
 support
  GHC 7.2.2 by adding some FlexibleInstances pragmas.
 
  The remaining issue on Windows is that GHCi is not working as it should.
 I
  will look at this next.
  On 25 January 2012 15:33, Dave Tapley duked...@gmail.com wrote:
 
  On 22 January 2012 00:37, Jeremy O'Donoghue jeremy.odonog...@gmail.com
 
  wrote:
 
  I now have wxC building on Windows. Details below and patches attached.
 
 
  Excellent!
  I'll take a look.
 
 
  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
 start
  looking there when it isn't past midnight (a bad time to start
 anything,
  IME).
 
 
  Mmm, I'm sorry about that.
  I actually went for this solution because I'm using cabal-dev to work on
  wxHaskell (so I can keep the hackage wxHaskell in my system cabal pkg
 conf):
  I needed a way to find the wxC headers (which obviously should be part
 of
  the wxC package) during the wxcore configure (because wxdirect (called
 by
  wxcore) needs them to generate some Haskell source (the FFI bindings)).
 
 
  The solution turned out to be simpler than I expected

Re: [wxhaskell-devel] The future of wxC

2012-01-25 Thread Jeremy O'Donoghue
On 25 January 2012 15:19, Dave Tapley duked...@gmail.com wrote:

 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?


I tend to favour moving to code.haskell.org first so that it remains easy
for Haskellers to work on wxHaskell using only Cabal.

I have been thinking along the lines of the cabal version of wxC becoming a
stub which contains pre-compiled wxC libraries and headers and installs
them for you. I think it's important that 'cabal install wx' continues to
work for Haskell users.

For that reasson, I'd rather move everything to c.h.o ASAP.


 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..


Me too :-)

However, I also  generated Doxygen XML output for wxWidgets (which the
wxWidgets people seem to favour), and it looks quite nice. Here's a sample
- it's the XML generated for the start of class wxPropertyGrid and the
method virtual void wxPropertyGrid::DoShowPropertyError(wxPGProperty
*property, const wxString amp;msg);

  compounddef id=classwx_property_grid kind=class prot=public
compoundnamewxPropertyGrid/compoundname
basecompoundref refid=classwx_control prot=public
virt=non-virtualwxControl/basecompoundref
basecompoundref refid=classwx_property_grid_interface prot=public
virt=non-virtualwxPropertyGridInterface/basecompoundref
includes local=nowx/propgrid/propgrid.h/includes
  sectiondef kind=user-defined
  headerwxPropertyGrid customization/header
  descriptionparaReimplement these member functions in derived
class for better control over ref refid=classwx_property_grid
kindref=compoundwxPropertyGrid/ref behaviour. /para/description
  memberdef kind=function
id=classwx_property_grid_1a6eff1187beba43109be7a12194b0bf2b prot=public
static=no const=no explicit=no inline=no virt=virtual
typevoid/type
definitionvirtual void
wxPropertyGrid::DoShowPropertyError/definition
argsstring(wxPGProperty *property, const wxString
amp;msg)/argsstring
nameDoShowPropertyError/name
param
  typeref refid=classwx_p_g_property
kindref=compoundwxPGProperty/ref */type
  declnameproperty/declname
/param
param
  typeconst ref refid=classwx_string
kindref=compoundwxString/ref amp;/type
  declnamemsg/declname
/param
briefdescription
paraOverride in derived class to display error messages in custom manner
(these message usually only result from validation failure). /para
/briefdescription
detaileddescription
parasimplesect kind=remarkparaIf you implement this, then you also
need to implement ref
refid=classwx_property_grid_1af170d02811ab8eed906963de693b79aa
kindref=memberDoHidePropertyError()/ref - possibly to do nothing, if
error does not need hiding (e.g. it was logged or shown in a message
box)./para/simplesect
simplesect kind=seepararef
refid=classwx_property_grid_1af170d02811ab8eed906963de693b79aa
kindref=memberDoHidePropertyError()/ref /para/simplesect
/para/detaileddescription
inbodydescription
/inbodydescription
location
file=D:/Builds/wxWidgets-2.9.3/interface/wx/propgrid/propgrid.h
line=1108/
  /memberdef
Notice that all of the documentation is retained (which would be very nice
for documenting wxcore), and that function 

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

2012-01-18 Thread Jeremy O'Donoghue
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.



Quick status update - it's a bit more involved than I thought. I have coded
most of the changes needed to wx-config-win, but need to get them working.
C++ isn't like Haskell where things work first time once they compile, you
know :-)

ETA for wx-config-win update is now Friday night (GMT) - I have several
commitments tomorrow, so I won't do very much, I suspect.

Jeremy
--
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


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

2012-01-17 Thread Jeremy O'Donoghue
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.

Best regards

Jeremy
--
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-17 Thread Jeremy O'Donoghue
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.

Regards
Jeremy
--
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


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

2012-01-15 Thread Jeremy O'Donoghue
Hi developers,

Think the subject says it all :-)

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


[wxhaskell-devel] The future of wxC

2012-01-15 Thread Jeremy O'Donoghue
Hi lists,

There have been a number of discussions over the past week or so on the
future of wxC. I'm not as good as Dave at cross-referencing everything, but
at the very least we have:

http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg01050.html
http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00735.html
http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00736.html
http://wewantarock.wordpress.com/2012/01/12/who-is-my-community/
http://www.reddit.com/r/programming/comments/oek2t/any_interest_in_a_c_binding_to_wxwidgets_from/

What I have tried to do is to raise the option of making wxC a separate
project to other groups (Dave and Eric have reached out to a couple of
other comunities as well), and see whether there is much interest out there.

The most concrete interest has come from the D community, which lacks a
good GUI binding, and which (it seems to me, based entirely on blog noise)
is growing pretty rapidly, with some more vague interest coming from the
wxWidgets community more generally (and granted that I have not done much
to reach out in that direction).

I must say that I am at least somewhat convinced that there is demand for
wxC 'out there', and it is therefore worth making an initial effort to make
wxC a viable option for other language communities.

With this in mind, I would like to suggest a staged approach - comments and
opinions are very welcome.


   1. The first stage is to simply get wxHaskell with 2.9.x support out of
   the door. I don't think we should change anything at this stage, other than
   that it definitely makes more sense to use wx-config-win on Windows
   platforms if we are going to work with others.
   2. The second stage is to spin wxC off as a separate project.
  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.
   3. 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.

I must say that comments to the blog posting in particular were really
quite encouraging, but I don't waht to put the cart before the horse. In
particular, Gour (an ex-Haskeller) and Andrej seem keen to try out what we
have already with D, which would make an excellent proof of concept.

Once we've had some discussion (say around the middle of the week), I'd
like to blog on what we propose to do, and start to reach out a bit further
to other groups.

Regards
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


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

2012-01-12 Thread Jeremy O'Donoghue
Thank you Kenneth,

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

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.

 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



 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.


 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

 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
 window does not actually disappear until ghci is exited.

 Does anybody know how this was working/can be fixed?


 Hope this is useful.


 Regards,

 Kenneth




 --
 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] Weird implementation of wxTreeCtrl_GetBoundingRect

2012-01-11 Thread Jeremy O'Donoghue
On 11 January 2012 15:55, Dave Tapley duked...@gmail.com wrote:

 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.


With respect to (1), I suspect that it is code dating back to wxWidgets 2.2
support (the 2.2. docs are no longer on line, so I can't confirm). At that
time, wxGTK was much less capable than wxMSW (it was based on GTK 1.x).

(2) baffles me completely.

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


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

2012-01-05 Thread Jeremy O'Donoghue
On 5 January 2012 12:15, Eric Kow eric@gmail.com wrote:


 On 4 Jan 2012, at 16:59, Dave Tapley wrote:

  I do like the idea that wxc is a separate project, upon which wxHaskell
 depends, however..
  When configuring wxcore I use wxc's package info, and so require wxc to
 be installed by cabal, and I assume it is the intention of the wxC project
 to be language independent?

 I think that would help.  One hope is that if we had a separate project
 that tried harder to be language agnostic, and which had none of the
 trappings of a Haskell project, we might be able to get more help from the
 wxWidgets team.  Make it look like any other project written in C, the
 basic autotools (or more likely Bakefile as wxWidgets use it), the
 pkgconfig stuff, etc.


I am not so keen on this approach. It seems like ever since I have had
anything to do with wxHaskell, far more time has been spent on build system
issues than on Haskell code or getting new wxWidgets components wrapped.

Don't forget that we started with an autotools-based build system which
never really worked properly for Windows. This meant that the bar for
becoming a wxHaskell developer was unreasonably high.

Now that we have everything in Cabal, it is actually pretty easy for people
to get going, and I would be loathe to loose that advantage.

I accept that Cabal is not an ideal build system, but it does 'just work'
when it comes to cross-platform builds.
--
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


[wxhaskell-devel] Happy New Year, wxHaskellers

2012-01-02 Thread Jeremy O'Donoghue
Hi lists,

A Happy New Year to all, and with it a chance to talk about some imminent
changes in wxHaskell. There is nothing new in this mail for those who
follow the wxhaskell-devel list, but for users who are interested in the
evolution of the project, I thought this would be a good time to summarise.

First, there will be a new release of wxHaskell in the next few days. This
is mainly a bugfix edition, but also reinstates some features which were
lost with Cabalization. Specifically:

   - Styled Text Control support
   - OpenGL support
   - Support for building on Haskell Platform 2011.4

This will be the last update of wxHaskell to support the wxWidgets 2.8.x
releases.

Following shortly afterwards, the very exciting news is that a number of
people (Dave Tapley in particular) have been putting a lot of work over the
last few months towards support of the wxWidgets 2.9 releases. This does
introduce a small number of breaking changes as the wxWidgets API has
changed in places, but brings with it quite a number of improvements:

   - wxC is built as a shared library. This means that wxHaskell works in
   GHCi again, which has been one of the most requested bugfixes over the past
   18 months or so.
   - Support for wxPropertyGrid and associated classes.
   - Support for the wxWidgets AUI classes.
   - Support for wxMediaControl.
   - Removal of legacy use of Eiffel files to generate constant
   definitions. This is only of interest to developers, but is far cleaner.
   - Build system improvements to reduce 'unnecessary' rebuilding of source
   files - again, one for developers.
   - Support for 64bit OS X platforms.

We will make a release of wxHaskell with all of the new features soon after
the changes have been merged into the main repository, and have been more
fully tested on all of our supported platforms.

Best regards

Jeremy
--
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

2011-12-12 Thread Jeremy O'Donoghue
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.

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, in which I could do sensible
 re-compilation.

 Given that there were other advantages to 2, I went with that.

 Jeremy had written one blog post on building a such a shared library, here:

 http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
 In response to an email on the wxhaskell-devel list he also kindly put
 up this gist, with the code he'd been working on:
 https://gist.github.com/1301115

 I dutifully took this gist, and have now attempted to integrate in to
 my wxhaskell-dev branch, which you can find here:
 http://darcsden.com/DukeDave/wxhaskell-dev
 (note: I haven't pushed any of the shared library code to darcsden
 yet, for reasons I'm about to explain)

 This is where things got interesting, after a few hours of hacking I
 have built a shared library, but in this very back-handed way:

 Firstly, in Jeremy's code the to-be-compiled shared library is added
 to the wxcore BuildInfo through a custom hook.
 We can see this because:
  let all_dlls   = parseDLLs [x-dll-name, x-dll-extra-libraries]
 custom_bi
 (the modified wxcore.cabal contains the line: 

Re: [wxhaskell-devel] Patch review, testing, and submission

2011-09-22 Thread Jeremy O'Donoghue
Hi list,

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

 Hi -devel,

 As I've alluded to before I have a fairly large number of local
 patches (mostly gtk/2.9 fixes) in my local darcs repo.
 I think it makes sense to get these on to code.haskell.org at some point.
 The good news is I've been fairly meticulous in ensuring each patch is
 encapsulated and has a reasonable commit message, the bad news is that
 I've only been testing with wx-2.9.2 and GTK, so my patches will
 probably break other configurations.



 Firstly, is it worth us setting up an approval queue of some form,
 ideally with people on a few different configurations?
 Secondly, who has write access for http://code.haskell.org/wxhaskell/ ?


At least Eric, Shelarcy and I, probably a few others. If you have an account
on code.haskell.org it is trivial to add you as a committer.

I would suggest that we perhaps set up a wxWidgets  2.9 repo on darcsden or
patch-tag (with caveat that I had a lot of trouble getting my Windows box to
talk to darcsden - perhaps I should revisit this).

The new patches go into the development repo with a lightweight review
process (the bar for submission should be that one of the group of
committers has compiled and tested on at least one target). We could perhaps
have occasional (e.g. bi-weekly) freezes where we stabilize existing code on
all platforms before moving on.

For the new codebase we explicitly disallow support for older wxWidgets, to
get rid of non target-related conditional compilation. We also allow API
changes, since a few places we have retained older APIs calling the
replacement functions. This is tricky for users of wxcore as they can't look
up the function in the wxWidgets documentation, and most wxcore
documentation is very sparse (just type info).

We should have another person (I suggest me for this one) who looks at the
patches on the new version and back-ports those which are relevant to older
wxHaskell versions to the code.haskell.org repo - in other words, older
wxHaskell goes into a pure maintenance mode with no new features.

How does this approach sound? We currently suffer because development
essentially takes place on the mainline, so large changes destabilize code
which we depend on to make releases. I would like to address this.

Best regards
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] I need help setting up

2011-09-21 Thread Jeremy O'Donoghue
I wanted to add one thing to this very useful thread, if only to have a
record of it somewhere:

On 17 September 2011 18:33, Dave Tapley duked...@gmail.com wrote:

 For the curious:
 Wondering how the library can still compile with some includes missing?
 (I believe, perhaps someone can confirm...)
 If you inspect some of the .cpps under wxcore/src/cpp/ you'll find they do
 a bunch of ifdefs (for example ifdef wxUSE_MEDIACTRL).
 Where do these defines come from?
 Well in Setup.hs you'll find this:
   (readProcess wx-config [--libs, --cppflags] )
 And that cppflags flag will print out (or in our case, on Linux, not
 print out) things like (wxUSE_MEDIACTRL), these are passed to ccOptions
 (from Distribution.InstalledPackageInfo), and the build system then passes
 these to the CPP linker.


There is a horrible hack in the way this is implemented, which is that
wxhaskell actually compiles stub code for all of the APIs for which you
don't have the required library, and has the functions return 'benign'
(usually NULL) values.

I have never liked this - it is down to the fact that wxdirect doesn't
handle the preprocessor, so you cannot put conditional compilation in the
core wxC headers. Yet another item for the TODO list.

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] Strings reduced to 1 letter on windows, on a program that otherwise works well on linux

2011-09-21 Thread Jeremy O'Donoghue
Hi David,

On 21 September 2011 16:49, David Virebayre dav.vire+hask...@gmail.comwrote:

 Bonjour,

 I'm posting this hoping that someone has seen the same problem; if
 nobody has, I'll make an example program, post the source and give
 screenshots.

 I have a program that works fine on linux.

 I followed the instructions to install wxhaskell on windows, all went
 fine. it's with wxWidgets 2.8.10.

 I compiled the source on windows, and when I run the program, all the
 strings are reduced to the first character: Labels in buttons, text
 fields, name of the app's icon (which fire an error because the icon
 doesn't exist) etc...

 Anyone has seen this before ?


This sounds like a Unicode problem.

On Windows, strings are natively encoded in UTF16, which uses two bytes to
represent a character. In the common case (for Western European languages),
most characters have the upper byte set to zero (as the codes used are
backwards compatible with ASCII).

Now, older wxWidgets (anything  wxWidgets 2.9) can be built as Unicode
(where Strings are represented as wchar_t *) or ASCII (where strings are a C
char*) - a feature to enable wxWidgets to wrap older code which believes
that only Western European languages should be able to be expressed ;-)

I would start by checking the wxWidgets libraries you are linking. If you
have wxmswusomething then it's Unicode - otherwise it is ASCII.

Because of the coding, the ASCII wxWidgets libraries see the '0' as the
upper byte of a Unicode string as a string terminator.

Regards
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] Compile time for wxcore

2011-09-21 Thread Jeremy O'Donoghue
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(*).

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.

(*) 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.

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] Property sheet

2011-08-01 Thread Jeremy O'Donoghue
Hi Dave,

Playing catch-up after the weekend...

Short answer - I think you have the correct places to put code.

On 30 July 2011 00:56, Dave Tapley duked...@gmail.com wrote:

 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


'High' level Haskell wrapper. You place constructors which are
property-aware here. In most respects this is straightforward except that
you need to work out what instances are appropriate to a PropertyGrid. You
may want to look at
http://wewantarock.wordpress.com/2010/01/11/custom-controls-in-wxhaskell-part-3/for
some more information about implementing Attribute instances.

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


An ugly piece of legacy from the days when wxcore was derived from an Eiffel
wrapping of wxWidgets. Event identifiers need to be defined here.
I *really* want to get rid of this file one day - it serves no purpose to
have an Eiffel file these days.


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


This creates the correct type witnesses to map the class Hierarchy.


 ./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


This is basically where you need to put the declarations for C++ method
wrappers.

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


I don't think you would need to do anything here


 ./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


Your Haskell event handler code goes here. You need one function which
reacts to events, which accepts an event handler as a parameter and a
function which will fetch your event handler (you need this mostly in case
you want to hook a further event handler which doesn't kill the one already
present).


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


I'm not completely sure why this is required. I suspect it's not used any
more.


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


Implementations of the wrappers. The old eljXXX naming convention for these
files really isn't necessary any more. I'd suggest calling the
implementation 'propertysheet.cpp' or something like that.


 ./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)


Correct.



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


I'd forgotten about these. Another way of wrapping up event values as
functions. I don't tend to do this, and I don't think anyone has for
years...

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


I tend to do this instead. It does exactly the same thing as the code in
defs.cppp.

# MISC FILES #

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


Obvious...

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


You should probably write one or more pieces of test code for your wrapped
control.

# 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 

Re: [wxhaskell-devel] Building wxcore on Windows: problem with wx-config

2011-06-19 Thread Jeremy O'Donoghue
On 19 June 2011 22:03, maciek.makow...@gmail.com wrote:

 wx-config-win (from https://sites.google.com/site/wxconfig/) does not
 support --version flag used by latest wxcore/Setup.hs. How should I go
 about building on Windows?


Haven't seen this - I'll look into it (there are other problems with
wx-config, but this is a new one on me).

Assume you're trying to build either darcs tip or current hackage version
with latest Haskell Platform. Please let me know if it isn't one of these.

Jeremy
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] patch applied (wxhaskell): Fix incorrect values of wxID_xxx (should fix bug workarounds in wxHnotepad, blog series.

2010-05-21 Thread Jeremy O'Donoghue
Thu May 20 07:24:28 EDT 2010  jeremy.odonog...@gmail.com
  * Fix incorrect values of wxID_xxx (should fix bug workarounds in wxHnotepad, 
blog series.
  Ignore-this: f0b3a1522d1fac4cc7f5a6e9f82198b7

M ./wxcore/src/eiffel/wx_defs.e -7 +22

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520112428-75908-f4cb7f04cd66016c18d032290c74b3b515d0f831.gz

--

___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Windows

2009-11-13 Thread Jeremy O'Donoghue
Hi Brian,

On Thu, 12 Nov 2009 11:54 -0600, Brian Lewis br...@lorf.org wrote:
 WxcClassInfo is in the exported modules list, but its source is
 generated by wxdirect into dist/build/autogen. I added
 dist/build/autogen to hs-source-dirs and I think it's working.
 
 Please add that line or pull my repo and try again.

This fails as well.

The error message this time is:

ERROR: wxcore-0.12.1.1.tar.gz: 400 Error in upload
400 Error in upload
'hs-source-dirs: dist/build/autogen' points inside the 'dist' directory.
This
is not reliable because the location of this directory is configurable
by the
user (or package manager). In addition the layout of the 'dist'
directory is
subject to change in future versions of Cabal.

I think I'll try putting the autogens in src. This should make things
work while we try to find a better way of approaching this.

Jeremy
-- 
  Jeremy O'Donoghue
  jeremy.odonog...@gmail.com


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] patch applied (wxhaskell): Enable cabal upload to complete successfully.

2009-11-13 Thread Jeremy O'Donoghue
Fri Nov 13 12:39:00 EST 2009  jeremy.odonog...@gmail.com
  * Enable cabal upload to complete successfully.
  Ignore-this: 6d6c1450099889787f06582e77fae6f5

M ./wx/wx.cabal -2 +6
M ./wxcore/Setup.hs -4 +3
M ./wxcore/wxcore.cabal -2 +24

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20091113173900-75908-65a1432f77d8bf076bfe8f5f3ff6d02e48c9bb37.gz

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Windows

2009-11-13 Thread Jeremy O'Donoghue
Hi Brian,

2009/11/13 Brian Lewis br...@lorf.org:
 For me, wxcore 0.12.1.1 on hackage fails to build for lack of
 stc_gen.cpp. It seems to be in darcs, though.


Working on the problem now. Will let you all know when I have
something which works - believe I am fairly close now, although it's
late here :-(

Jeremy

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Windows

2009-11-13 Thread Jeremy O'Donoghue
The problem, of course, being that stc.cpp includes stc_gen.cpp. For
now I'm going to put it into extra-source-files.

Didn't spot that before upload, and the cabal verifier obviously
couldn't. We should try to find a better way to do this, but for now
this should be OK.

Jeremy

2009/11/13 Jeremy O'Donoghue jeremy.odonog...@gmail.com:
 Hi Brian,

 2009/11/13 Brian Lewis br...@lorf.org:
 For me, wxcore 0.12.1.1 on hackage fails to build for lack of
 stc_gen.cpp. It seems to be in darcs, though.


 Working on the problem now. Will let you all know when I have
 something which works - believe I am fairly close now, although it's
 late here :-(

 Jeremy


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] patch applied (wxhaskell): Bump version to 0.12.1.1, remove unused wxc directory

2009-11-12 Thread Jeremy O'Donoghue
Wed Nov 11 12:25:33 EST 2009  jeremy.odonog...@gmail.com
  * Bump version to 0.12.1.1, remove unused wxc directory

M ./wx/wx.cabal -3 +3
R ./wxc/
R ./wxc/util/
R ./wxc/util/gconst.cc
R ./wxc/util/gfunc.cc
R ./wxc/util/reimp.exe
R ./wxc/wxc-2.8.dsp
R ./wxc/wxc-2.8.dsw
M ./wxcore/wxcore.cabal -1 +1
M ./wxdirect/wxdirect.cabal -1 +1

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/2009172533-75908-b0c530dee0743f34282d0ee0044c5c3961b51c1e.gz

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Windows

2009-11-12 Thread Jeremy O'Donoghue
Hi all,

[Eric - note question aimed your way, buried near the bottom]

2009/11/10 Brian Lewis br...@lorf.org:
 On Tuesday, 10.11.09 at 12:42, Jeremy O'Donoghue wrote:
 One good option may be to commit the code 'as-is' to enable simple
 cabal install of wxHaskell, and work on putting back the features we
 have (temporarily) lost.

 If basic functionality is still there, I really favor doing it this way,
 because projects that are hard to install are in the danger zone.

I agree with Brian and Eric on this and no-one else has commented, so
I have committed the updates to the darcs repo. I've pulled a clean
build and it functions just as expected, but...

 I'd like to get official wxdirect, wxcore, wx repos in order, maybe
 bumping version numbers as appropriate, and post something to -cafe
 about wxhaskell being truly installable via cabal. I hope this will spur
 interest. I would really like to see this library in good shape. I think
 the most important thing right now is to lower the barrier to using and
 developing on the project.

While the darcs repo is now in order (with a version bump to 0.12.1.1
to signify that we are fully cabalized), I'm failing to create a cabal
sdist package for wxcore.

The error is:

$ WXWIN=/c/utils/wxWidgets-2.8.10 WXCFG=gcc_dll/mswu runhaskell Setup.hs sdist
Building source dist for wxcore-0.12.1.1...
Setup.hs: Error: Could not find module: Graphics.UI.WXCore.WxcClassInfo with
any suffix: [gc,chs,hsc,x,y,ly,cpphs,hs,lhs]

I remember that we had some trouble with this last time. I thought the
'extra-tmp-files' stanza indicated that we don't need these files in
the sdist. Eric, you fixed this for me last time. What did you do?

Happy to upload once I have fixed this - wxdirect is already uploaded,
and I'll do wx in a few moments. Once I've verified the whole chain
using 'cabal install wx' on a clean computer, I'll make the
announcements and update the wiki. It will be a pleasure to simplify
the install instructions :-)

Regards
Jeremy

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Windows

2009-11-12 Thread Jeremy O'Donoghue
Hi Eric,

2009/11/12 Eric Y. Kow eric@gmail.com:

 I think I replied too soon.  The problem looks like an interaction
 between the fact that we expose our autogenerated modules and the fact
 that we generate them in a non-src directory (which is nice to do).

Yup - discovered that when I tried it :-(

It's neat, but to be honest the old flex/bison user in me doesn't find
it very offensive to generate code in src, provided that the clean
target is implemented nicely. It has the advantage, for anyone working
on the source code, of keeping everything nicely together.

 One thing which makes the cabal sdist go is to change Setup.hs so that
 we no longer use autogen, but the source directory (slash haskell).
 I wonder if there is a better way though, for example, having a module
 that imports these autogen'ed modules and re-exports them.  This would
 avoid dumping stuff into src

Does it solve the problem? I couldn't find any documentation on the
extra-tmp-files: stanza, so I'm not really sure what it does. I
suspect that the root cause of the problem is that we are trying to
export modules which do not exist in a clean directory structure.

Is it worth asking the cabal guys what they would suggest in this case?

Jeremy

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


[wxhaskell-devel] ANN: wxHaskell 0.11.1

2009-01-04 Thread Jeremy O'Donoghue
The wxHaskell development team is pleased to announce the release of
wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library.

The Haskell support is built on a reasonably complete C language
binding, which could be used as the basis for wxWidgets support on other
languages/platforms which do not have easy mechanisms for linking with
C++ code.

The main highlights of wxHaskell 0.11.1 are: 

- Support for XRC resource files, allowing GUI design using a visual
tool. Note that this
   is currently not type safe, and programs will crash if a widget is
   not cast to the correct
   type on loading.
- Support for wxWidgets 2.8.x. Support for wxWidgets 2.4.2 is now
dropped and wxHaskell
   will not compile against versions of wxWidgets prior to 2.6. This
   means that exploratory
   development using GHCi is no longer possible. Workaround is to
   continue to use older
   wxHaskell versions.
- Support for GHC 6.10
- Preliminary support for Cabal / Hackage

The full list of changes is provided at the end of this mail.

Binary packages are available from the wxHaskell download site at
http://sourceforge.net/project/showfiles.php?group_id=73133, for the
following platforms:

- Windows
- OS X (Intel platform only)
- Source code .tar.gz and .zip
- Documentation (cross-platform)

The wxHaskell libraries (wxcore and wx) are also available from Hackage
(http://hackage.haskell.org).

About wxHaskell
---

wxHaskell is a Haskell binding to the wxWidgets GUI library for recent
versions
of the Glasgow Haskell Compiler. It provides a native look and feel on
Windows,
OS X and Linux, and a medium level programming interface.

The main project page for wxHaskell is at
http://wxhaskell.sourceforge.net.
The latest source code for wxHaskell can always be obtained from
http://darcs.haskell.org/wxhaskell.
There are developer (wxhaskell-devel@lists.sourceforge.net and user
(wxhaskell-us...@lists.sourceforge.net) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

The C language binding for wxHaskell was derived from an original C
language binding created for the Eiffel programming language by the
ELJ project (http://elj.sourceforge.net).

Non backward compatible changes:
- Preliminary Cabal / Hackage support
- Added --global argument to configure script
- Added --user argument to configure script
- Changed wxhaskell official web page to Haskell wiki at
http://haskell.org/haskellwiki/WxHaskell
- Changed official darcs repository to code.haskell.org
- Adapted the wxHaskell C-layer to work with wxWidgets 2.8
- Adapted some part of wxcore API to be able to refer to wxWidgets 2.8
documentation for wxcore functions
- Added TopLevelWindow, which mainly removes some functionality from
Frame
- Changed --with-stc argument to --with-contrib
- Removed Wave type synonym

Backward compatible additions:
- Added support for using XRC resource files to load most controls and
menus attached to frames.
- Added sample file showing how to use XRC support to attach command
handlers to menu items
- Added sample file showing how to use properties with many controls.
- Added --enable-optimization argument to configure script
- Added --O* argument to configure script
- Added --enable-library-profiling argument to configure script
- Added --p argument to configure script
- Added -fvia-C argument to configure script. And moved this 
compilation flag to configure script
- Added Image / ByteString conversion functions
- Adapted the configuration  to work with GHC 6.10.
- Changed Var type synonym from IORef to stm's TVar for thread
safety
- Changed imageGetPixelArray and imageCreateFromPixelArray to be
more flexible.
- Changed Point, Size, Vector and Rect to be type synonym. 
- Added wxcMilliSleep. Now, wxcAppUSleep is deprecated. Use
wxcMilliSleep instead
- Added very experimental wxGraphicsContext support
- Added wxSVGFileDC functions

Bugfixes:
- Applied DEPRECATED pragma to old deprecated functions. Just documented
in Haddock before.
- Fixed processExecAsync hangs Windows GUI-only program
- Fixed Windows binary install problem when path with spaces (bug
1400488)
- Probably fixed the applicattion failed to initialize properly when 
  using Windows binary.

-- 
  Jeremy O'Donoghue
  jeremy.odonog...@gmail.com
-- 
  Jeremy O'Donoghue
  jeremy.odonog...@gmail.com


--
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] 0.11.0 Release Schedule

2009-01-02 Thread Jeremy O'Donoghue
Hi,

I'll do an announcement tomorrow morning (UK time).

Regards
Jeremy

On 2 Jan 2009, at 22:57, shelarcy wrote:

 Hi, I think we're ready for wxHaskell 0.11.0 release.

 Now, I uploaded source distribution and binary distribution that  
 doesn't
 include  Linux and PowerPC Mac OS X's binary. Because I don't have  
 these
 machine and Debian's wxWidgets 2.8.x is not stable now.

 I updated more part of HaskellWiki's wxHaskell document, and I  
 uploaded
 wxcore 0.11.0 and wx 0.11.0 to HackageDB, too.

 Jeremy, how about announce wxHaskell 0.11.0 release?


 Best Regards,

 On Tue, 23 Dec 2008 23:13:59 +0900, shelarcy shela...@gmail.com  
 wrote:
 Hi, I updated and added a few documentation now.

 I uploaded current darcs version as 0.10.6 to HackageDB for  
 describing
 cabal command's build instruction. Because current darcs version is
 changed some part since I uploaded wx and wxcore 0.10.5.

   http://www.haskell.org/haskellwiki/WxHaskell/Building
   http://www.haskell.org/haskellwiki/WxHaskell/ 
 Building#Building_wxHaskell

   and a few documentations.

 If anyone want to add more information to wxHaskell's page, please
 modify documentation yourself.

 On Mon, 22 Dec 2008 20:46:47 +0900, Eric Kow eric@gmail.com  
 wrote:
 I know we have a few problems. But we can't solve their problems
 soonly.

 Any problems we can't resolve we should document clearly and propose
 workarounds for.

 I can't write one note that is describing about XRC and type safety.

 http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/ 
 msg00346.html

 Because Jeremy has some text about using XRC support. I'm afraid  
 my text
 is conflict or contradicting to his change.

 http://sourceforge.net/mailarchive/forum.php? 
 thread_name=1224586792.27106.1280412245% 
 40webmail.messagingengine.comforum_name=wxhaskell-devel

 Best Regards,

 Note: I'm quite pleased that I can now install wxcore in the user
 directory (although I forget how I did this; was it ./configure -- 
 user ;
 make; make install I did?).  It might be nice if we mentioned that
 LD_LIBRARY_PATH must be set (for Linux users at least), as the
 ~/.cabal/... path is not likely to be in people's LD_LIBRARY_PATH

 In general, it would be nice to see the wiki updated with the latest
 instructions for how to install wxhaskell, especially for people  
 who use
 hackage packages that depend on wx.

 I think a nice way would be something like

   1. whatever is needed to install wxcore
   2. cabal install wx

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


--
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] Darcs patch: support for XRC based resources in wxHaskell

2008-10-23 Thread Jeremy O'Donoghue
Hi Shelarcy,

I'll try it on my Mac when I get home - could prove to be a
pre-processor difference between Visual Studio and GCC.

In the two cases given, I'd expect the BUILD_XRCGETCTRL_FN macro to
expand as follows:

Where _typ is Sizer
EWXWEXPORT(wxSizer*, wxXmlResource_GetSizer)(wxWindow* _win, wxString*
_str_id)
{
  return
  
reinterpret_castwxSizer*(_win-FindWindow(wxXmlResource::GetXRCID(*_str_id));
}

Where _typ is BoxSizer
EWXWEXPORT(wxBoxSizer*, wxXmlResource_GetBoxSizer)(wxWindow* _win,
wxString* _str_id)
{
  return
  
reinterpret_castwxBoxSizer*(_win-FindWindow(wxXmlResource::GetXRCID(*_str_id));
}

One thing to try: does adding a space after the paste tokens and before
the '*' tokens help? (i.e.

#define BUILD_XRCGETCTRL_FN(_typ)   
 \
  EWXWEXPORT(wx##_typ## *, wxXmlResource_Get##_typ)(wxWindow* _win,
  wxString* _str_id)\
  { 
   \
  return reinterpret_castwx##_typ##
  *(_win-FindWindow(wxXmlResource::GetXRCID(*_str_id))); \
  }

Alternatively, it's pretty easy to replace the auto-generated functions
with the manually created versions. If you find that the extra space
suggestion above does not work, I'll do a patch tomorrow with each of
the functions implemented in full.

Regards
Jeremy

On Thu, 23 Oct 2008 21:59:36 +0900, shelarcy [EMAIL PROTECTED]
said:
 Hi,
 
 On Tue, 21 Oct 2008 19:59:52 +0900, Jeremy O'Donoghue
 [EMAIL PROTECTED] wrote:
  Attached is a set of patches to enable XRC support in wxHaskell Darcs
  head, along with a couple of samples (in the samples/test/XRCControls
  directory) showing how to use the new functionality. They have only
  really been tested on Windows, so it would help if people can look for
  bugs on other platforms.
 
 I got error when building wxc with xrc.patch on Mac OS X platform.
 
 g++ -c wxc/src/eljrc.cpp -o dist/wxc/eljrc.o -MD -DwxcREFUSE_MEDIACTRL
 -I/usr/lib/wx/include/mac-unicode-debug-2.8 -I/usr/include/wx-2.8
 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXDEBUG__ -D__WXMAC__ 
 -DwxUSE_STC=1 -DwxUSE_SVG=1 -fPIC -Iwxc/include
 wxc/src/eljrc.cpp:437:1: error: pasting wxSizer and * does not give a
 valid preprocessing token
 wxc/src/eljrc.cpp:437:1: error: pasting wxSizer and * does not give a
 valid preprocessing token
 wxc/src/eljrc.cpp:438:1: error: pasting wxBoxSizer and * does not
 give a valid preprocessing token
 (snip)
 make: *** [dist/wxc/eljrc.o] Error 1
 Build Failed.
 
 It seems that BUILD_XRCGETCTRL_FN macro causes problem. Does anyone knows
 how to solve this problem?
 
 My Mac's gcc version is 4.0.1.
 
 shelarcy$ gcc -v
 Using built-in specs.
 Target: i686-apple-darwin9
 Configured with: /var/tmp/gcc/gcc-5484~1/src/configure --disable-checking
 -enable-werror --prefix=/usr --mandir=/share/man
 --enable-languages=c,objc,c++,obj-c++
 --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
 --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
 --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
 --host=i686-apple-darwin9 --target=i686-apple-darwin9
 Thread model: posix
 gcc version 4.0.1 (Apple Inc. build 5484)
 
 
 Best Regards,
 
 -- 
 shelarcy shelarcyhotmail.co.jp
 http://page.freett.com/shelarcy/
-- 
  Jeremy O'Donoghue
  [EMAIL PROTECTED]


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] How about release wxHaskell 0.11? (Was: build failure in new release

2008-10-11 Thread Jeremy O'Donoghue
Hi all,

I am about two weeks away from committing XRC support. It's working
about 70% at the moment and I need to write test cases to cover most
widgets and make sure the most important functions are working, as well
as writing a wiki tutorial to show how to do the Real World Haskell GUI
chapter in  wxHaskell.

If we are OK with two releases close together, then we could release  a
bugfix update now. Otherwise, can we wait about two weeks to put out
release candidate with XRC support (which I think would be an
interesting feature for many people).

Best regards
Jeremy

On Sat, 11 Oct 2008 14:26:25 +0900, shelarcy [EMAIL PROTECTED]
said:
 Hi all,
 
 We already fixed two critical build problem in the darcs repository:
 - wxWidgets 2.8.x build problem
 - GHC 6.10.x build problem
 
 But current our official wxHaskell release version 0.10.3 is not.
 This is bad for people who want to use wxHaskell.
 
 So, I think we should postpone some feature that we want adding 0.11
 to 0.12, and release new version 0.11 (or 0.10.6?) soonly.
 
 I uploaeded un-official release what are the previous mail's one to
 HackageDB . But it's only a stopgap release, we must replace official
 one.
 
 
 Best Regard,
 
 On Sat, 11 Oct 2008 13:46:01 +0900, shelarcy [EMAIL PROTECTED] wrote:
  configuration:
   library: wxhaskell-0.10.4  (release 0)
   (snip)
 
  *** config/config.mk:22: *** missing separator.  Stop.
  cabal: Error: some packages failed to install:
  wxcore-0.10.4 failed during the building phase. The exception was:
  exit: ExitFailure 2
 
  Typo in config.mk
 
  # Packages
  PKG-CONTAINERS=-package containers-0.2.0.0
  PKG-PARSEC=-package parsec-2.1.0.1
  2.1.0.2
  PKG-TIME=-package time-1.1.2.1
  PKG-STM=-package stm-2.1.1.1
 
  I fixed this bug in the new HackageDB releace 0.10.5.
  Please test again with 0.10.5.
 
 -- 
 shelarcy shelarcyhotmail.co.jp
 http://page.freett.com/shelarcy/
 
 -
 This SF.Net email is sponsored by the Moblin Your Move Developer's
 challenge
 Build the coolest Linux based applications with Moblin SDK  win great
 prizes
 Grand prize is a trip for two to an Open Source event anywhere in the
 world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 wxhaskell-devel mailing list
 wxhaskell-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel


Re: [wxhaskell-devel] wxWidgets 2.8 support

2008-03-25 Thread Jeremy O'Donoghue

On Mon, 24 Mar 2008 16:02:43 +, Eric Y. Kow [EMAIL PROTECTED]
said:
 So, now that 0.10.3 is out, what is the fastest way for us to get
 wxWidgets 2.8 support so that MacOS X Leopard users can run it?

I need to port my wxWidgets 2.8 changes on top of 0.10.3. I started this
last week, and it won't take too long.

There are a few caveats, however, and (at least as I've implemented)
these break compatibility. Note that it seems like the 2.4 compatibility
mode which we have been using with wxWidgets 2.6 seems to be broken (not
unreasonably) in a few places in 2.8 (it's officially unsupported now).

What I have is based on 'raw' wxWidgets 2.8 (I couldn't make 2.4
compatibility work, and it's cleaner to just work to the latest base).

Bottom line is that the update will not compile against wxWidgets 2.4 or
2.6. Don't think the loss of 2.6 compatibility is too much of an issue.
Loss of 2.4 compatibility means that we no longer play nicely with GHCi,
however. 

I have some ideas on how to fix this, but it's far from trivial (do
'true' dynamic loading and unloading of wxWidgets DLL/.so/.dylib, which
will be very platform specific, but will ensure that C++ static
constructors and destructors work correctly, and can be called
programmatically). 

Main (possibly compatibility breaking) differences from 0.10.3:

   * In WX
 o Instances of 'framed' (currently in WX.Frame) move to
   TopLevelWindow
 o Changed behaviour of bestSize attribute (in WX.Window) -
   this is very minor, I think, and probably doesn't break
   existing code.
   * In WXCore
 o topLevelWindowSetIconFromFile replaces frameSetIconFromFile
   * In wxc
 o wxGenericDragImage methods now require a wxPoint
 o static wxBrush instances have changed to const type
 o static wxColour instances have changed to const type
 o static wxCursor instances have changed to const type
 o static wxFont instances have changed to const type
 o static wxPen instances have changed to const type
 o wxTreeItemId_CreateFromValue() should be deprecated

The good news is that it looks as though much of what is needed in wxc
has been implemented (although I'll have to merge my changes as they
are, in some cases, different to what I had done (in unimportant ways).
In general, I'll keep what is already there if it works.

I can try to get this merge done in a week or so, if that's OK. I'll
have time to verify on one platform only (probably Windows), but better
to get the changes in.

I think we need to have a general discussion on whether it's acceptable
to break wxWidgets 2.4 compatibility. I think it is, and that we should
just direct those needing this feature to the 0.10.3 release.

Regards
Jeremy

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel