Re: [wxhaskell-devel] wxHaskell vs GHCi
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
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
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
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)
[wxhaskell-devel] GitHub repo?
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
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
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
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
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
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
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
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
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
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
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
[wxhaskell-devel] Happy New Year, wxHaskellers
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
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
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
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
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
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
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
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.
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
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.
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
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
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
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
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
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
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
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
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
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
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
