Re: [wxhaskell-devel] postponing wxWidgets 2.8 support and releasing earlier?

[Jeremy O'Donoghue]

Hi all,

On 25/02/2008, Eric Kow <[EMAIL PROTECTED]> wrote:
>
>  Or do you think that wxWidgets 2.8 support is actually right around the 
> corner?

I can give you what I have for wxWidgets 2.8 support (I would merge
latest patches and ensure it compiles, but have too many work
commitments to do any more), if people feel it's essential and/or
useful. There are some rough edges, but it works OK(*) on Windows at
least.

A thing to bear in mind is that wxWidgets 2.8 support definitively
breaks support for the 2.4 line. This may be a deal-breaker for those
who like to work in ghci.

(*) OK == about as well as wxWidgets 2.6.2

>  If not, I'd say that wxhaskell 0.10 should aim for a 'it just works'
>  installation on the default case (vanilla wxWidgets without any
>  special flags; for example, what ships with the system) for Windows,
>  Linux and Mac.  I'd especially like for wxhaskell to be easy for
>  Windows users to install and use.
>
>  The things I'd like to see in wxhaskell 0.11 are
>  - wxWidgets 2.8 support
>  - a better way of dealing with contribs/ (see Jeremy's mail on modularity)
>  - wxc separation (maybe)

I actually more or less have wxc separation, in a makefile (I have a
single makefile for Microsoft and GNU compilers). It's virtually
finished, but not tested on all platforms. Again, happy to provide,
but this one isn't for the faint-hearted.

Let me know if you'd like the 2.8 support - it is in a slightly rough
form, but I've only managed to spend a couple of hours on it in the
last 3 months, so may be better to 'get it out there'.

-
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

Re: [wxhaskell-devel] postponing wxWidgets 2.8 support and releasing earlier?

[Jeremy O'Donoghue]

On 25/02/2008, Eric Kow <[EMAIL PROTECTED]> wrote:
>
> Please do give us what you have (in any form).  Given the rough edges,
>  I'd vote we sit on it until 0.10 is out the door [for example, I can
>  fix conflicts and put in a private darcs repo] and hope for a 0.11 not
>  too long after.  Likewise for the wxc stuff.  A little dose of
>  conservatism here in the interests of shipping.

OK - I'll package up what I have, attach some explanation and push it
to you. I'll ensure that it at least compiles and does the basics on
Windows. Agree that leaving it out to enable early shipping is
probably a good move, as there are quite a few changes.

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

Re: [wxhaskell-devel] darcs patch: Remove support for GHC prior to 6.4. (and 3 more)

[Jeremy O'Donoghue]

On Tue, 26 Feb 2008 13:55:48 -0800 (PST), "Eric Kow"
<[EMAIL PROTECTED]> said:
> -  I'm not particularly bothered if our implementation of this is ugly. 
>I figure that 0.11 is going to have wxc separated anyway, so maybe 
>we'll be able to switch to Simple buildtype for wxcore and all this 
>will be moot.

I'm not sure. large parts of wxcore are generated by running wxdirect
over the wxc headers. I couldn't find a way to make cabal handle this
dependency without moving to the Makefile buildtype.

I actually got somewhat disillusioned with Cabal while trying to move
everything to using it because it really only knows about Haskell
dependencies and very simple C/C++ (i.e. which can be compiled via the
Haskell compiler). I haven't kept up well with the further development
of Cabal recently, but I suspect that the limitation probably remains.

The wxc separation should be OK - it's already (as noted previously)
essentially working for me.

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

Re: [wxhaskell-devel] xrc support

[Jeremy O'Donoghue]

On 06/03/2008, Eric Kow <[EMAIL PROTECTED]> wrote:
> >  Eric, are you already receive his patch? If so, we want to see it for
>  >  thinking about that.
>
>
> No, not yet.
>

I've been looking at many things, but never XRC. I'd like to look at
it (or have someone look at it) one day, but I have not done so to
date.

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

Re: [wxhaskell-devel] darcs patch: Require --enable-unicode in wxWidgets. (and 1 more)

[Jeremy O'Donoghue]

On Thu, 20 Mar 2008 17:50:06 +0900, "shelarcy" <[EMAIL PROTECTED]>
said:
> Hi Eric,
> 
> On Thu, 20 Mar 2008 08:28:11 +0900, Eric Kow <[EMAIL PROTECTED]> wrote:
> > [Require --enable-unicode in wxWidgets.
> > Eric Kow <[EMAIL PROTECTED]>**20080318084054] hunk ./configure 759
> >  # wxWidgets
> >  #
> >  =
> >
> > +# confirm that we have unicode enabled
> > +`$wxconfig --unicode=3Dyes`
> > +if test "$?" =3D 0; then
> > +  echo " wxWidgets Unicode support found"
> > +else
> > +  echo ""
> > +  echo " I can't find the Unicode version of wxWidgets!"
> > +  echo ""
> > +  echo " Did you configure configure wxWidgets with --enable-unicode?"
> > +  echo " If you have more than one copy, are you passing in the right"
> > +  echo " version via --wx-config?"
> > +  exit 1
> > +fi
> 
> This cause the problem to use Visual Studio on Windows platform.
> If we build wxWidgets (wxMSW) by Visual Studio, there is no wxconfig
> command.
> And Windows binary's wxc dll links wxWidgets library statically. So,
> almost
> Windows users don't meet unicode problem.
> 

The suggested patch is OK as a temporary solution, but it certainly is
possible to build wxWidgets without Unicode on Windows, so it could
break in some cases.

It's true that there is no wx-config for Windows, but I think the right
approach will probably be to detect what is actually available on a
Windows host - much as wxconfig allows on Unix hosts.

It's not too hard as you can generally determine what is available given
the DLLs available and their names (e.g. wxmsw26ud.dll would represent a
Unicode debug build). 

We can certainly hold off on this for now. Given that Windows (since at
least Windows 98 if not earlier) has been primarily Unicode based

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

Re: [wxhaskell-devel] wxWidgets 2.8 support

[Jeremy O'Donoghue]

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

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

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

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

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

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

Main (possibly compatibility breaking) differences from 0.10.3:

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

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

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

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

Regards
Jeremy

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

[wxhaskell-devel] ANN: wxHaskell 0.10.3

[Jeremy O'Donoghue]

The wxHaskell development team is pleased to announce the release of
wxHaskell 0.10.3, 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 feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a
number of
additional bugfixes.

This is the first full release since June 2005, and is the result of a
great deal of work by a new team of contributors.

Highlights of 0.10.3 include:

- Support for Unicode builds of wxWidgets
- Support for additional widgets including calendar, toolbar divider,
  styled text control (wxScintilla), media control
- Support for clipboard, drag and drop
- Support for 64bit (Linux) targets
- Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if 
  you compile from source). wxWidgets 2.8 is not yet supported
- Support for building with GHC 6.6.x and 6.8.x
- Parts of wxHaskell are now built with Cabal
- New test cases
- Removed support GHC version < 6.4
- Profiling support
- Smaller generated binary sizes (using --split-objs)

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

- Debian
- Windows
- OS X (Intel and PPC platforms)
- 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
([EMAIL PROTECTED]) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

wxHaskell was originally created by Daan Leijen. The contributors to
this new release include:

- Eric Kow
- shelarcy
- Arie Middelkoop
- Mads Lindstroem
- Jeremy O'Donoghue
- Lennart Augustson

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

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] ANN: wxHaskell 0.10.3

[Jeremy O'Donoghue]

The wxHaskell development team is pleased to announce the release of
wxHaskell 0.10.3, 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 feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a
number of
additional bugfixes.

This is the first full release since June 2005, and is the result of a
great deal of work by a new team of contributors.

Highlights of 0.10.3 include:

- Support for Unicode builds of wxWidgets
- Support for additional widgets including calendar, toolbar divider,
  styled text control (wxScintilla), media control
- Support for clipboard, drag and drop
- Support for 64bit (Linux) targets
- Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if
  you compile from source). wxWidgets 2.8 is not yet supported
- Support for building with GHC 6.6.x and 6.8.x
- Parts of wxHaskell are now built with Cabal
- New test cases
- Removed support GHC version < 6.4
- Profiling support
- Smaller generated binary sizes (using --split-objs)

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

- Debian
- Windows
- OS X (Intel and PPC platforms)
- 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
([EMAIL PROTECTED]) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

wxHaskell was originally created by Daan Leijen. The contributors to
this new release include:

- Eric Kow
- shelarcy
- Arie Middelkoop
- Mads Lindstroem
- Jeremy O'Donoghue
- Lennart Augustson

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).
-- 
  Jeremy O'Donoghue
  [EMAIL PROTECTED]


-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] wxWidgets 2.8.7 support

[Jeremy O'Donoghue]

Hi all,

Attached is a (zipped) preliminary set of patches for wxWidgets 2.8.7
support. Some notes to help.

- wxWidgets 2.8.7 was compiled from source using Visual Studio 2008
(i.e. on Windows)
  with the following options:
  - WXWIN_COMPATIBILITY_2_4 0
  - WXWIN_COMPATIBILITY_2_6 0
  - wxUSE_UNICODE 1
  - wxUSE_MEDIACTRL 1
  - wxUSE_XML 1
  - wxUSE_GLCANVAS 1
  - wxUSE_ODBC 1
  Styled text control was also built. I think this means that I've
  enabled all of the 
  current things we support in wxHaskell. The whole thing was built as a
  static library.
- Compiled on top of both 0.10.3 rc1 (tagged) and the released version
(head). Tested 
  against most of the samples/wx directory using rc1 (Windows only).

- Main changes are:
  - (wxc) Changes in managed.cpp for some of the const objects. Previous
  code does not compile
on VS2008.
  - (wxc) Factored some functions into wxTopLevelWindow
  - (wx) Added TopLevelWindow.hs, which mainly removes some
  functionality from Frame.hs.

The general approach I've taken, as agreed with Eric when I discussed
this patch, is to shoot for wxcore API which is as close as possible to
wxWidgets 2.8. This breaks source compatibility in places, but has some
advantages:
- Possible to refer to wxWidgets documentation for wxcore functions.
- Not always clear what is the 'best' way to maintain compatibility with
more complex
  changes e.g. wxTopLevelWindow introduction.

I'm sure that not all will agree with the approach, but the attached is
a start for wxWidgets 2.8 support.

Best regards
Jeremy


wxwidgets2.8.7.patch.gz
Description: GNU Zip compressed data
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] wxWidgets 2.8.7 support

[Jeremy O'Donoghue]

On Fri, 11 Apr 2008 09:29:48 +0100, "Eric Y. Kow" <[EMAIL PROTECTED]>
said:
> On Thu, Apr 10, 2008 at 15:12:50 +0100, Jeremy O'Donoghue wrote:
> > - wxWidgets 2.8.7 was compiled from source using Visual Studio 2008
> > (i.e. on Windows)
> 
> Great! Thanks!
> 
> ... but I get this compile error on MacIntel
> 
> g++ -c wxc/src/eljvalidator.cpp -o dist/wxc/eljvalidator.o -MD
> -DwxcREFUSE_MEDIACTRL -DwxcREFUSE_OPENGL
> -I/usr/local/lib/wx/include/mac-unicode-release-2.8
> -I/usr/local/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES
> -D__WXMAC__   -fPIC -Iwxc/include 
> wxc/src/eljvalidator.cpp: In function ‘void*
> wxTextValidator_GetIncludes(void*, int*)’: wxc/src/eljvalidator.cpp:159:
> error: ‘_wcsdup’ was not declared in this scope
> wxc/src/eljvalidator.cpp: In function ‘void*
> wxTextValidator_GetExcludes(void*, int*)’: wxc/src/eljvalidator.cpp:192:
> error: ‘_wcsdup’ was not declared in this scope
> make: *** [dist/wxc/eljvalidator.o] Error 1

Shelarcy got this one for me... we need to replace _wcsdup with
wxStrdup(). _wcsdup() is Microsoft specific.

> >   with the following options:
> >   - WXWIN_COMPATIBILITY_2_4 0
> >   - WXWIN_COMPATIBILITY_2_6 0
> >   - wxUSE_UNICODE 1
> >   - wxUSE_MEDIACTRL 1
> >   - wxUSE_XML 1
> >   - wxUSE_GLCANVAS 1
> >   - wxUSE_ODBC 1
> 
> How do I get the same listing?

I'm afraid this one was manual copy and paste. It would be very easy to
create a script to do it, though, and we should probably consider (as we
could then do autoconfig of wxHaskell build for Windows). All you need
to do is search wx/setup.h for the wxWidgets install in path.

The most important of the features above that we should consider further
is WXWIN_COMPATIBILITY_2_6 (which I disabled) - I could see (given
packaging time for e.g. Debian) a benefit in trying to support the
current and previous releases of wxWidgets. At the same time, I think
it's very important to maintain a close link between wxcore and
wxWidgets library itself - otherwise we would need to fully document
wxcore (at present the wxWidgets docs are quite useable as documentation
for wxcore, but if we don't keep up, they become less so over time.

Regards
Jeremy

-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] WxHaskell at DEFUN

[Jeremy O'Donoghue]

Mads Lindstrøm wrote:
> Hi,
>
> Eric Y. Kow wrote:
>   
>> On Tue, Apr 22, 2008 at 09:05:09 +0100, Simon Peyton-Jones wrote:
>> 
>>>  Call for Talks and Tutorials
>>>  ACM SIGPLAN 2008 Developer Tracks on Functional Programming
>>> http://www.deinprogramm.de/defun-2008/
>>>  Victoria, BC, Canada, 25, 27 September, 2008
>>>The workshop will be held in conjunction with ICFP 2008.
>>>http://www.icfpconference.org/icfp2008/
>>>   
>>> How-to talks: 45-minute "how-to" talks that provide specific
>>>   information on how to solve specific problems using functional
>>>   programming. These talks focus on concrete examples, but provide
>>>   useful information for developers working on different projects or in
>>>   different contexts.
>>>   
>> Will anyone be able to give this a talk in September?  It would be
>> really great for wxHaskell.
>>
>> If one of us is available to go (for example, will be at ICFP), we
>> can help you prepare...
>>
>> Jeremy, perhaps?  Anyone else?  Mads?
>> 
>
> I am unable to attend.
>   
I'm not in academia, and I don't think I could ever persuade my employer 
to pay up for this sort of thing, so I can't go either.

Sorry.

Jeremy

-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
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

[Jeremy O'Donoghue]

Hi all,

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

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

Best regards
Jeremy

On Sat, 11 Oct 2008 14:26:25 +0900, "shelarcy" <[EMAIL PROTECTED]>
said:
> Hi all,
> 
> We already fixed two critical build problem in the darcs repository:
> - wxWidgets 2.8.x build problem
> - GHC 6.10.x build problem
> 
> But current our official wxHaskell release version 0.10.3 is not.
> This is bad for people who want to use wxHaskell.
> 
> So, I think we should postpone some feature that we want adding 0.11
> to 0.12, and release new version 0.11 (or 0.10.6?) soonly.
> 
> I uploaeded un-official release what are the previous mail's one to
> HackageDB . But it's only a stopgap release, we must replace official
> one.
> 
> 
> Best Regard,
> 
> On Sat, 11 Oct 2008 13:46:01 +0900, shelarcy <[EMAIL PROTECTED]> wrote:
> >> configuration:
> >>  library: wxhaskell-0.10.4  (release 0)
> >>  (snip)
> >>
> >> *** config/config.mk:22: *** missing separator.  Stop.
> >> cabal: Error: some packages failed to install:
> >> wxcore-0.10.4 failed during the building phase. The exception was:
> >> exit: ExitFailure 2
> >>
> >> Typo in config.mk
> >>
> >> # Packages
> >> PKG-CONTAINERS=-package containers-0.2.0.0
> >> PKG-PARSEC=-package parsec-2.1.0.1
> >> 2.1.0.2
> >> PKG-TIME=-package time-1.1.2.1
> >> PKG-STM=-package stm-2.1.1.1
> >
> > I fixed this bug in the new HackageDB releace 0.10.5.
> > Please test again with 0.10.5.
> 
> -- 
> shelarcy 
> 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=100&url=/
> ___
> 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=100&url=/
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] GHCi crashed by bouncing balls

[Jeremy O'Donoghue]

Hi Henk-Jan,

You have come across a known, and (I'm afraid) difficult issue to fix.

While I can give an explanation below, I don't think we will be able to
fix the issue.

I will update the wiki to reflect the fact that this is a known problem,
as this information has somehow been lost in the move from the
Sourceforge.net site to the Haskell.org wiki.

Best regards
Jeremy

On Sun, 19 Oct 2008 18:46:12 +0200, "Henk-Jan van Tuyl"
<[EMAIL PROTECTED]> said:
> 
> L.S.,
> 
> The bouncing balls demo crashes GHCi when run for the second time; to  
> reproduce this:
> 1. Start GHCi
> 2. Load BouncingBalls.hs
> 3. Run main
> 4. Close the BouncingBalls window
> 5. Run main
> 
> 
> The most minimal program that reproduces this error is:
> 
> > module Main where
> 
> > import Graphics.UI.WX
> 
> > main :: IO ()
> > main = start myFrame
> >myFrame :: IO ()
> > myFrame =
> >   do
> >f <- frameFixed [text := "Crash test"]
> >return ()

The problem is that versions of wxWidgets after 2.4.x make use of static
C++ destructors which execute only when the executable is unloaded. This
means that when main terminates in GHCI, the wxWidgets library is not
left in a sane state (because the DLL is still loaded, and the
destructors have not run). For this reason, it is not very practical to
use recent versions of wxHaskell with GHCi.

I took a quick look, a year or so back, at continuing to support
wxWidgets 2.4.2 in wxHaskell, and I'm afraid the conclusion was that the
wxHaskell team just don't have the time available to do this (many
wxWidgets APIs have changed enough in the last three years that we would
really be maintaining two separate branches).

The alternative approach (of making this functionality work with recent
versions of the wxWidgets library) is a substantial amount of work (and
the work would be mainly in C, rather than Haskell!), as it would
require dynamically unloading wxWidgets DLLs when main terminates and
reloading them when it is run again. I'd love someone with a spare
couple of months to do this!

If it is absolutely essential for you to support incremental development
using GHCi, the only real option is to use 0.9.4-1 (see
http://sourceforge.net/project/showfiles.php?group_id=73133&package_id=73173).
I fear that this may require a little work before it will build on the
most recent versions of GHC.
 
> Software used:
> GHC 6.8.3 / wxWindows 0.10.3 / Windows XP

The same behaviour is likely to be observed on all platforms.
-- 
  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=100&url=/
___
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

[Jeremy O'Donoghue]

Hi Shelarcy,

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

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

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

Where _typ is BoxSizer
EWXWEXPORT(wxBoxSizer*, wxXmlResource_GetBoxSizer)(wxWindow* _win,
wxString* _str_id)
{
  return
  
reinterpret_cast(_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_cast(_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 
> 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=100&url=/
___
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

[Jeremy O'Donoghue]

Hi,

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

Regards
Jeremy

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

> Hi, I think we're ready for wxHaskell 0.11.0 release.
>
> Now, I uploaded source distribution and binary distribution that  
> doesn't
> include  Linux and PowerPC Mac OS X's binary. Because I don't have  
> these
> machine and Debian's wxWidgets 2.8.x is not stable now.
>
> I updated more part of HaskellWiki's wxHaskell document, and I  
> uploaded
> wxcore 0.11.0 and wx 0.11.0 to HackageDB, too.
>
> Jeremy, how about announce wxHaskell 0.11.0 release?
>
>
> Best Regards,
>
> On Tue, 23 Dec 2008 23:13:59 +0900, shelarcy   
> 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   
>> 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.com&forum_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 
> http://page.freett.com/shelarcy/


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

[wxhaskell-devel] ANN: wxHaskell 0.11.1

[Jeremy O'Donoghue]

The wxHaskell development team is pleased to announce the release of
wxHaskell 0.11.1, a Haskell binding for the wxWidgets GUI library.

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

The main highlights of wxHaskell 0.11.1 are: 

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

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

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

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

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

About wxHaskell
---

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

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

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

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

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

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

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


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

Re: [wxhaskell-devel] Windows

[Jeremy O'Donoghue]

Hi Brian,

I've confirmed that your procedure works for me, too.

I've merged your code into a local copy of the latest Darcs repo, but
there's a problem I want to track down before releasing to the Darcs
repo.

The issue is that I'm seeing exceptions from the Debug build variants
(Release is fine). While everything works if I click the 'Ignore
Exception' option, this really ought to be fixed. I'm not sure if it's
an MSys gcc issue, as this is the first time I've used gcc to build wxc,
which is what, in effect, I think Cabal is doing - it doesn't happen for
the same code under VS2008.

There are a couple of things to consider as they have wider impact - I
wanted to put them before the group for consensus before committing
code:

* The changes as presently implemented remove OpenGL support (and
StyledTextControl,
  I think). While it can be argued that these belong in separate
  packages (e.g.
  wx-gl and wx-stc), this only really works for code which compiles to a
  separate
  DLL (I think this can be true of everything in the contrib directory).

* In this case, wxc is basically subsumed into wxcore as they are built
together.

On reflection, I think that pulling wxc into wxcore is a good idea, and
has benefits compared to the alternative we have been considering (which
is to spin wxc off into a separate project).

The reason for liking this approach is that Windows developers have been
consistently complaining that cabal libraries which depend on external C
libraries usually don't work on Windows (I've seen this issue a number
of times myself). While I am in complete agreement with the view that
it's up to Windows developers to fix the problem, this offers us a way
to simply avoid the problem for wxHaskell. Pulling wxc into wxcore makes
life very much simpler for all new wxHaskell developers, and I think
that lowering the entry barrier is important. It may also help in
justifying wxHaskell as a candidate for the Haskell Platform.

One other thing to consider - the wxc build system has always been
pretty fragile, mainly because of the support for Visual Studio, which
complicates everything. Brian's approach lets us get rid of the wxc
build system completely, since cabal does the heavy lifting.

I'm not really comfortable with removing support for stc, OpenGL and
some of the other features - I suspect the right approach is to get the
Windows build working using multiple DLLs. At this point, wxCore can
depend on the 'standard' set of DLLs, and packages can be added for the
optional features (these obviously dependent on having said features
available in your wxWidgets installation.

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.

I'd prefer a consensus on what we should do, and will check-in or hold
off on code commit as people believe best. I'll give it at least a week
before committing to Darcs, for comment (should also give me time to fix
the exceptions I'm seeing).

Regards
Jeremy

On Thu, 05 Nov 2009 13:48 -0600, "Brian Lewis"  wrote:
> Jeremy, thanks very much for writing back. That helped a lot.
> 
> Here's a procedure that seems to work:
> 
> Install
>   MinGW 5.1.6
> [x] g++ compiler
> [x] MinGW Make
>   MSYS-1.0.11
>   wxMSW-2.8.10
>   wx-config Windows port
> 
> In MSYS
>   cd /c/wxWidgets-2.8.10/build/msw
>   mingw32-make -f makefile.gcc BUILD=release MONOLITHIC=1 SHARED=1
>   UNICODE=1
> 
>   cd ~/wxcore
>   WXWIN=/c/wxWidgets-2.8.10 WXCFG=gcc_dll/mswu cabal install
> 
>   or just
>   WXWIN=/c/wxWidgets-2.8.10 WXCFG=gcc_dll/mswu cabal install wxcore
> once the new stuff is on Hackage.
> 
> Can someone verify that it works? This seems tolerable to me.
-- 
  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): Cabalize wxcore per Brian Lewis

[Jeremy O'Donoghue]

Mon Nov  9 11:44:09 EST 2009  jeremy.odonog...@gmail.com
  * Cabalize wxcore per Brian Lewis

 ./wxc/eiffel -> ./wxcore/src/eiffel
 ./wxc/include -> ./wxcore/src/include
 ./wxc/src -> ./wxcore/src/cpp
 ./wxcore/src/Graphics -> ./wxcore/src/haskell/Graphics
 ./wxcore/src/cpp/eljgrid.h -> ./wxcore/src/include/eljgrid.h
A ./wxcore/LICENSE
A ./wxcore/Setup.hs
R ./wxcore/Setup.lhs
R ./wxcore/license.txt
M ./wxcore/src/cpp/eljfindrepldlg.cpp -1 +1
R ./wxcore/src/cpp/eljfl.cpp
M ./wxcore/src/cpp/eljgizmos.cpp -5 +9
M ./wxcore/src/cpp/eljjoystick.cpp -1 +1
R ./wxcore/src/cpp/glcanvas.cpp
R ./wxcore/src/cpp/wxc.rc
A ./wxcore/src/haskell/
M ./wxcore/src/haskell/Graphics/UI/WXCore.hs -7
R ./wxcore/src/haskell/Graphics/UI/WXCore/OpenGL.hs
R ./wxcore/src/include/glcanvas.h
M ./wxcore/src/include/wrapper.h +2
M ./wxcore/src/include/wxc.h -1
M ./wxcore/wxcore.cabal -46 +186

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20091109164409-75908-559538d88b1d9b28093d5ed5bdd4833ed784b319.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

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

[Jeremy O'Donoghue]

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

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

View patch online:

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

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

Re: [wxhaskell-devel] Windows

[Jeremy O'Donoghue]

Hi all,

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

2009/11/10 Brian Lewis :
> 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

[Jeremy O'Donoghue]

Hi all,

A couple more things:

Cabal upload is not happy with putting 'build-depends:' in a
conditional. I get the following error:

"400 Error in upload
The dependency 'build-depends: base' does not specify an upper bound
on the version number. Each major release of the 'base' package
changes the API in various ways and most packages will need some
changes to compile with it. The recommended practise is to specify an
upper bound on the version of the 'base' package. This ensures your
package will continue to build when a new major version of the 'base'
package is released. If you are not sure what upper bound to use then
use the next  major version. For example if you have tested your
package with 'base' version 2 and 3 then use 'build-depends: base >= 2
&& < 4'."

This sounds like a bug to me (I'll ask haskell-cafe separately), but
in the meantime, does it make sense to remove support for the
'non-split' base. This means (IIRC) removing support for anything
older than ghc-6.10.x.

Second thing. Brian, you've done all of the hard work - would you like
to make the announcement to the Haskell Universe? (didn't want to
imply that I insist on making announcements...)

Jeremy

2009/11/12 Jeremy O'Donoghue :
> Hi all,
>
> [Eric - note question aimed your way, buried near the bottom]
>
> 2009/11/10 Brian Lewis :
>> 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

[Jeremy O'Donoghue]

Hi Eric,

2009/11/12 Eric Y. Kow :
>
> 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

Re: [wxhaskell-devel] Windows

[Jeremy O'Donoghue]

Hi Brian,

On Thu, 12 Nov 2009 11:54 -0600, "Brian Lewis"  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.

[Jeremy O'Donoghue]

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

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

View patch online:

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

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

Re: [wxhaskell-devel] Windows

[Jeremy O'Donoghue]

Hi Brian,

2009/11/13 Brian Lewis :
> 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

[Jeremy O'Donoghue]

The problem, of course, being that stc.cpp includes stc_gen.cpp. For
now I'm going to put it into extra-source-files.

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

Jeremy

2009/11/13 Jeremy O'Donoghue :
> Hi Brian,
>
> 2009/11/13 Brian Lewis :
>> 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

[Jeremy O'Donoghue]

Hi all,

It works - after a bump to version 0.12.1.2.

I'll update darcs shortly, but in the meantime, you should be able to
do the following (assuming you have wxWidgets installed - must be
compiled with MSys if you are on Windows)

cabal update
cabal install wxdirect
WXWIN= WXCFG=gcc_dll/mswu cabal install wxcore
cabal install wx

Someone brave should probably try:

cabal update
WXWIN= WXCFG=gcc_dll/mswu cabal install wx

I guess we should announce to the world :-)

Regards
Jeremy

2009/11/13 Jeremy O'Donoghue :
> The problem, of course, being that stc.cpp includes stc_gen.cpp. For
> now I'm going to put it into extra-source-files.
>
> Didn't spot that before upload, and the cabal verifier obviously
> couldn't. We should try to find a better way to do this, but for now
> this should be OK.
>
> Jeremy
>
> 2009/11/13 Jeremy O'Donoghue :
>> Hi Brian,
>>
>> 2009/11/13 Brian Lewis :
>>> 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.2 (Cabal requires new version no), add stc_gen.cpp to extra-source-files and remove old build files.

[Jeremy O'Donoghue]

Fri Nov 13 17:58:56 EST 2009  jeremy.odonog...@gmail.com
  * Bump version to 0.12.1.2 (Cabal requires new version no), add stc_gen.cpp 
to extra-source-files and remove old build files.
  Ignore-this: a3475df1f76b2ddeaff99a4864bf092d

R ./Setup.lhs
R ./makefile
R ./makefile.lib
M ./wx/wx.cabal -3 +3
M ./wxcore/wxcore.cabal -1 +2

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20091113225856-75908-d4f712224a9a0e2bf458e49df000d9e81a6b17aa.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

[wxhaskell-devel] Debugging wxHaskell with ghci - Windows issue

[Jeremy O'Donoghue]

Hi Brian,

I'm trying to track down the wxHaskell in ghci bug on my Windows
platform, and I'm running into an issue which is stopping me from
getting anywhere before I even start.

The problem probably stems from the way wxHaskell is compiled under
MinGW, which doesn't seem to behave quite as I would expect. Output for
your minimal 'test'hs' program (per the post a couple of days back):

C:\jodonoghue\haskell>ghci test.hs
GHCi, version 6.10.4: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package syb ... linking ... done.
Loading package base-3.0.3.1 ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package containers-0.2.0.1 ... linking ... done.
Loading package bytestring-0.9.1.4 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.2 ... linking ... done.
Loading package filepath-1.1.0.2 ... linking ... done.
Loading package Win32-2.2.0.0 ... linking ... done.
Loading package directory-1.0.0.3 ... linking ... done.
Loading package stm-2.1.1.2 ... linking ... done.
Loading package parsec-2.1.0.1 ... linking ... done.
Loading package time-1.1.2.4 ... linking ... done.
Loading package wxdirect-0.12.1.1 ... linking ... done.
Loading package wxcore-0.12.1.2 ... : stdc++: The specified
module could not be found.
can't load .so/.DLL for: stdc++ (addDLL: could not load DLL)

I notice that in the wxcore Setup.hs build file, you manually append
stdc++ to the list of libraries reported by wx-config.

One consequence of this seems to be that ghci thinks it needs to load
libstdc++, and this does not exist as a DLL on Windows. Actually, it is
not needed as the wxWidgets DLL is statically linked with libstdc++ on
Windows (I've run a dependency checker on the wxWidgets DLL, and it
depends only on mingwm10.dll and the usual standard set of Microsoft
system DLLs).

I don't think wxcore actually depends on libstdc++. wxWidgets does
(unless you explicitly compile without it) for sure, and I assume that
on Linux you therefore need the libstdc++ to make everything link. Is
this correct?

I'm going to experiment with removing the libstdc++ dependency for
Windows platforms, to see if this makes the problem go away. I'll keep
you posted.

Regards
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

Re: [wxhaskell-devel] [wxhaskell-users] problems with cabal-installed wxHaskell and ghci (WinXP)

[Jeremy O'Donoghue]

Hi Guenther,

[x-posting to wxhaskell-devel, in case any of the other committers has a
clue...]

On Wed, 27 Jan 2010 17:04 +0100, "Günther Schmidt" 
wrote:
>
> I managed to cabal-install wxWidgets on WinXP last night.
> 
> Now something strange happens when I test via ghci or runghc:
> 
>   could not find stdc++ dll
> 
> Now I did copy the wxmsu ... dll into the path ie. C:\windows\system32
> and when I run the compiled program it works.

This is a problem which has had me stumped for several weeks now. I'll
explain as best I can.

The root cause of the problem is related to the MinGW gcc installation
which is part of GHC, and which does C/C++ compilation and *all* linking
for both GHC and GHCi. The basic problem is this: for some reason,
almost all libraries in MinGW are dynamically linked *except* libstdc++,
which is *always* statically linked(*).

When compiling for GHC, this is no problem. the linker notices that
there is only a static version of libstdc++ available and uses it.
However, GHCi assumes (I think) that any libraries given to it on the
command line need to be loaded dynamically.

The incantation for which libraries to load when a package is loaded
comes from the package definition (in this case from the cabal
installation of wxcore). The problem is that I'm not sure of the best
way forward on this, and I've tried quite a few things.

What I really need is a coherent explanation of exactly how linking,
compilation and package loading is implemented by GHC and GHCi - I
understand the underlying gcc and gnu ld implementations well enough.

I'll eventually get around to a more complete description of the problem
and post to one of the GHC lists - but haven't done so as yet.

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


--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] patch applied (wxhaskell): Add sample code to show that bug 2901741 is not valid, and demonstrate how to use this.

[Jeremy O'Donoghue]

Thu May 20 09:56:05 EDT 2010  jeremy.odonog...@gmail.com
  * Add sample code to show that bug 2901741 is not valid, and demonstrate how 
to use this.
  Ignore-this: c9de36f18c539ef2903928dac7fce86d

A ./samples/wx/TestTaskBarIcon.hs
M ./samples/wx/makefile +1

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520135605-75908-a7bafda71e28649874ad544d0d621945ce9a5d97.gz

--

___
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.6 for wxcore and wx

[Jeremy O'Donoghue]

Fri May 21 08:34:29 EDT 2010  jeremy.odonog...@gmail.com
  * Bump version to 0.12.6 for wxcore and wx
  Ignore-this: 38671a0c7e38fb746e57604ef5503c6c

M ./wx/wx.cabal -3 +3
M ./wxcore/wxcore.cabal -1 +1

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100521123429-75908-bc0c41da60499e4eb00b5f50a4b27d97c34e0162.gz

--

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

[wxhaskell-devel] patch applied (wxhaskell): Test case for bug 2810904 (cannot duplicate)

[Jeremy O'Donoghue]

Fri May 21 07:55:49 EDT 2010  jeremy.odonog...@gmail.com
  * Test case for bug 2810904 (cannot duplicate)
  Ignore-this: 3df0c34595983b46c5c7648b3fc11188

A ./bugs/comctl32_fail.hs

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100521115549-75908-0b228a837681f9a68e24f6f64baf4844d60ac24c.gz

--

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

[wxhaskell-devel] patch applied (wxhaskell): Bugfix 1224727: textColor attribute does not appear to work correctly.

[Jeremy O'Donoghue]

Fri May 21 07:32:27 EDT 2010  jeremy.odonog...@gmail.com
  * Bugfix 1224727: textColor attribute does not appear to work correctly.
  Ignore-this: cecaa0a6cb8e6cefb685aeefb279e85f

M ./bugs/TextColor.hs -6 +11
M ./wx/src/Graphics/UI/WX/Controls.hs -5 +4

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100521113227-75908-89ddbb45ebe4c8e528a819a3b25400c5dafa18e4.gz

--

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

[wxhaskell-devel] patch applied (wxhaskell): Eliminate warnings when compiling mediactrl.cpp

[Jeremy O'Donoghue]

Thu May 20 08:49:38 EDT 2010  jeremy.odonog...@gmail.com
  * Eliminate warnings when compiling mediactrl.cpp
  Ignore-this: 7315eaf56d72f6db1ee782d0ea7ee339

M ./wxcore/src/cpp/mediactrl.cpp -13 +13

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520124938-75908-2e95bf938f154f0c7f0bdb662115dc0996c11d0f.gz

--

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

[wxhaskell-devel] patch applied (wxhaskell): Update wxdirect to support GHC 6.12.x

[Jeremy O'Donoghue]

Thu May 20 08:02:33 EDT 2010  jeremy.odonog...@gmail.com
  * Update wxdirect to support GHC 6.12.x
  Ignore-this: ce19175da97555cf5330b0ae1f5635ae

M ./wxdirect/wxdirect.cabal -11 +17

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520120233-75908-c566bb790903c7eb669760c1d8ef03ca59daa699.gz

--

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

[wxhaskell-devel] patch applied (wxhaskell): Fix bug 2851194

[Jeremy O'Donoghue]

Thu May 20 07:40:11 EDT 2010  jeremy.odonog...@gmail.com
  * Fix bug 2851194
  Ignore-this: 764a70d16b06e49dfac2cbb6105969c

M ./wxcore/src/cpp/eljfindrepldlg.cpp -1 +1

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520114011-75908-bdc33de3c1e2a5eff378d399adfd73c1474a1769.gz

--

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

[Jeremy O'Donoghue]

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

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

View patch online:

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

--

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

[wxhaskell-devel] patch applied (wxhaskell): Changes for Cabal API 1.7 and GHC 6.12.x (GHC 6.10.x still supported)

[Jeremy O'Donoghue]

Thu May 20 06:25:38 EDT 2010  jeremy.odonog...@gmail.com
  * Changes for Cabal API 1.7 and GHC 6.12.x (GHC 6.10.x still supported)
  Ignore-this: f25e08a43d6b6b7f0c7457feb03bf77d

M ./wx/wx.cabal -4 +12
M ./wxcore/Setup.hs -1 +1
M ./wxcore/wxcore.cabal -12 +14

View patch online:

  
http://code.haskell.org/wxhaskell/_darcs/patches/20100520102538-75908-06a3977f7138272a308b0e22e0be6af794319785.gz

--

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

Re: [wxhaskell-devel] GHC & GHCi and wxcore

[Jeremy O'Donoghue]

Unfortunately this is a known issue. It is the result of mixing static and
dynamic libraries, which is something GHCi can't do.

I'm working on a solution, but am very short of free time, so it's taking
longer than I would hope. It's also quite a major change and needs a lot of
validation.

There are quite a few people waiting for this, so I hope get to it as
quickly as possible.
Regards
Jeremy

On 21 Jul 2010 16:13, "eros olmi"  wrote:

 Hi
i am using the latest haskell platform for windows 2010.1.0.0
and i have installed the wxhaskell using the cabal
i can compile a wxhaskell program such as hello.hs successfully using:
ghc -package wx -o hello hello.hs
but i can't using ghci like this:
ghci -package wx hello.hs
GHCi, version 6.12.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
.done.
Loading package wxdirect-0.12.1.3 ... linking ... done.
: stdc++: The specified module could not be found.
Loading package wxcore-0.12.1.6 ... : can't load .so/.DLL for:
std
c++ (addDLL: could not load DLL)

how can i solve this contradiction between GHC and GHCi since the first
succeeded and the second failed.
thanks
eros

--
Hotmail: Trusted email with Microsoft’s powerful SPAM protection. Sign up
now. 

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Source code?

[Jeremy O'Donoghue]

It is the correct location...

Unfortunately, code.haskell.org was attacked recently, and the server needed
rebuilding. I need to upload wxHaskell again, and I haven't gotten around to
it (to be honest, I hadn't thought about this as a consequence of the
attack).

Will be fixed in the next day or so.

Regards
Jeremy

On 7 March 2011 22:14,  wrote:

> Where is the official source code repository for wxHaskell? The
> details in http://www.haskell.org/haskellwiki/WxHaskell/Development
> are incorrect.
>
> Thanks,
> Maciek
>
>
> --
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] wxHaskell repo restored to code.haskell.org

[Jeremy O'Donoghue]

Hi all,

I'm pleased to announce that as of last night UK time, and with the help of
a Google Talk mini-hackathon from Eric (thanks Eric :-), wxHaskell has been
restored to code.haskell.org.

Compared to the released version on cabal, this contains the following
changes:

   - Change to hasked darcs repo, whcih should make complete repo pulls much
   quicker.
   - Patches from Eric to enable wxHaskell to build against Haskell Platform
   2011.2.0.1
   - Removal of quite a few deprecated and removed functions, particularly
   ODBC bindings.
   - Support build with both wxWidgets 2.8.x and 2.9.x (see below)
   - Remove a number of warnings
   - Change Cabal license type from LGPL to 'Other'. This is *not* a license
   change: wxHaskell has always been licensed under the wxWidgets license.
   While this is very similar to LGPL, it differs in one absolutely vital area,
   which is that it explicitly allows for binary distribution of closed source
   programs which simply use wxHaskell, and I wanted our cabal stanzas to
   reflect this..
   - Version bump to 0.13 to reflect support for wxWidgets 2.9
   - Bugfix for assert error in SearchDynamicEventTable which was found in
   debug builds. I believe that this is a proper fix for an issue Eric noted a
   couple of months back.

I would like to make a new wxHaskell release fairly shortly, but there are a
few issues which *may* need changes before I can do so - I'd appreciate
testers to check whether there is a problem.

The main issue is that wxWidgets 2.9 is impossible to build on my Windows
machine in Monolithic mode (runs out of memory). This, of course, led to a
cascade of problems which are related to the fact that the external
wx-config program we use to determine what libraries are used on Windows has
many bugs and doesn't properly support wxWidgets 2.9 (or 2.8 when compiled
non-monolithic). Because of this there are some nasty hacks in the wxcore
Setup.hs to pull in the correct libraries, and these may cause problems with
the pre-compiled wxWidgets provided on non-Windows platforms. Please let me
know if this is the case.

I built wxWidgets (2.8.11 and 2.9.1) as follows:
Ensure that USE_HTML=1 and USE_XRC=1 are set in setup.h
> make -f makefile.gcc USE_OPENGL=1 UNICODE=1 SHARED=1 BUILD=debug

As a reminder, here's how to build wxHaskell from source, assuming that you
have wxWidgets installed with the WXWIN and WXCFG environment variables set
to point to the wxWidgets root directory and configuration respectively:

cd 
darcs get http://code.haskell.org/wxhaskell/
cd wxhaskell/wxdirect
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wxcore
runhaskell Setup.hs configure
runhaskell Setup.hs build
runhaskell Setup.hs install
cd ../wx
runhaskell Setup.lhs configure
runhaskell Setup.lhs build
runhaskell Setup.lhs install

Windows users will need to run the install stanzas from within a command
windows with administrative priviledge. Note also that on Windows, your PATH
needs to have the wxWidgets DLLs present if you want to actually run
anything.

Just for information, I have (non-tested) patches on my machine for the
following:

   - Wrapper for wxDisplay (requested by Brian Victor)
   - {H|V}Slider which supports swapped order - code graciously provided by
   Henning Thielmann
   - Wrapper OpenGL contexts

These will be added to the repo as soon as I have convinced myself that they
work on more than one machine ;-)

Thanks to all for your patience.

Best regards
Jeremy
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] wxHaskell repo restored to code.haskell.org

[Jeremy O'Donoghue]

On 3 June 2011 12:44,  wrote:

> On Fri, Jun 03, 2011 at 12:14:58 +0100, Jeremy O'Donoghue wrote:
> >- Bugfix for assert error in SearchDynamicEventTable which was found
> in
> >debug builds. I believe that this is a proper fix for an issue Eric
> noted a
> >couple of months back.
>
> It's not just debug builds (of what?),


Of wxWidgets itself. I don't see the assertion for retail builds. I *do* see
the assertion on debug builds for Windows, so I don't think it's a Mac
issue.

but basically the scenario where
> you naively type "cabal install wx" on MacOS after having installed the
> Haskell Platform and nothing else.   Macs ship with wxWidgets, albeit
> with this crucial bit of missing functionality.
>
> I'm a bit concerned that this may result in silently-does-the-wrong-thing
> errors
>
> +  if (evtHandler->GetDynamicEventTable() != NULL)
> +found = evtHandler->SearchDynamicEventTable( event );
>
> As I'd discovered to my dismay, without this trawl through the non-existent
> dynamic event table, things like scrolled list boxes stop responding to
> events.
>
> http://www.mail-archive.com/wxhaskell-devel@lists.sourceforge.net/msg00580.html
>

This is a bit more worrying - it's likely to be seen on other platforms as
well. I didn't see the problem on any of the (few) test cases I ran, but it
sounds more like a failure of what might laughably be called my test regime
than a Mac specific issue.


> If I understand the patch correctly, the result of this is that (A)
> users would be able to happily install wxHaskell on Mac without any
> prerequisites, but (B) if they were to use such a widget, it would just
> silently not-work.
>

No - I think it would silently not work everywhere :-(


> The even better solution would be for somebody to go understand how the
> event
> handling code works and propose a solution that works without the missing
> dynamic event table
>

That's probably a better bet. I have the impression that you're not really
supposed to call wxEvent::SearchDynamicEventTable() from outside anyway.
They seem to have gone to some lengths to not document it in wxWidgets.

I will have a go at understanding the event handling code. Wish me luck,
I'll probably need it...

Jeremy
--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 ___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Haskell Platform roadmap?

[Jeremy O'Donoghue]

Hi all,

This is a call for help. There's been some discussion both on this list and
on the cafe about getting a GUI into Haskell Platform.

The formal requirement is that inclusion needs to be supported by at least
one library maintainer, and from a practical perspective it should be
something which builds and works well on all supported platforms, i.e.
Linux, Windows and Mac, and should have a team of maintainers who are able
to maintain the code over a long term basis.

While there have been some fantastic contributions to wxHaskell over the
past years from any people, the reality is that most of the work gets done
by me, and some may have noticed that I don't have a lot of time - certainly
nothing like enough to commit to inclusion in Haskell Platform.

The call for help is this: can we get together a team which would be able to
field enough effort to make a submission for Haskell Platform realistic? I
believe that such a team would look something like the following:


   - Project lead, release co-ordinator and mentor to others. That will be
   me then.
   - Target leads for Linux, Mac and Windows. Responsible for building tip
   code for their platforms and providing fixes when it breaks. In the case of
   Mac and Linux, extra points if you can make things work using the platform
   built-in wxWidgets.
   - A number of specific functional areas to be addressed:
  - Fix the long-standing bug preventing GHCi use of wxHaskell. In my
  opinion, this is best addressed by factoring the C wrapper for
wxHaskell (we
  call it wxC) into a separate library which is built as a dynamically
  loadable library. I know, in principle, how to do this for Windows and
  Linux, but would need help for Mac. Anyone who wants to help should know
  that this involves lots of revolting work with linkers, and is especially
  suitable for masochists. That's probably me as well.
  - Make it easier to wrap some of the optional wxWidgets libraries.
  This requires work on wxDirect. This is probably the easiest
area to work on
  as wxDirect is a self-contained executable, and is small and
fairly simple
  to understand.
  - Using the above, wrap some of the optional libraries. STC should be
  reinstated in wxHaskell now (it's part of the core in wxWidgets 2.9), but
  there are many others. OpenGL canvas, AUI and the media framework look
  particularly interesting.
  - Consider a pure Haskell replacement for wx-config, at least on
  Windows, but potentially on all targets. We currently bundle a 3rd party
  wx-config replacement for Windows, but it doesn't work very well on
  wxWidgets 2.9.
  - Extend Graphics.UI.WX so that more of the core functionality has
  high-level wrappers, e.g. for Grid, List boxes etc. I would love
to see an
  FRP wrapper around parts of wxHaskell, and think we could
reinstate one or
  more of the FRP libraries, for example. Making GUI programming
less like C
  programming would do a lot to promote Haskell GUI development, but it
  requires much better Haskell-fu than I have to offer.
   - Go back through the list of bugs and feature requests and fix as many
   as possible. This is an easy starting point for a new wxHaskell contributor.
   - Improve documentation. While wxHaskell is pretty good, it could
   definitely be improved. In particular, I think we should consider finding a
   way to generate better documentation for the wxC wrapper functions, which
   currently only include type information.

There's probably a lot more to do, and I welcome comments and suggestions. I
welcome offers of help even more, and estimate that getting into HP requires
a core team of 6-8 people who can commit to a few hours per week for at
least a year. This is a huge ask, but the outcome would be that wxHaskell
could become part of the Haskell Platform, and would likely be much more
widely used.

What do you think?

Best regards
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

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

[Jeremy O'Donoghue]

On 19 June 2011 22:03,  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

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

[Jeremy O'Donoghue]

Hi all,

On 25 July 2011 07:45, Eric Y. Kow  wrote:

> On Mon, Jul 25, 2011 at 01:10:15 +0100, Dave Tapley wrote:
> > A very good suggestion.
> > I cabal unpacked wxcore-0.12.1.7 and it appears to have a fix in it¹.
> >
> > Do we know why this fix is in the release, but not in darcs?
>
> I suspect the answer lies somewhere in here:
>
>  darcs changes --repo http://code.haskell.org/wxhaskell --from-tag .
>  --match 'hunk 45999'
>

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

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

EWXWEXPORT(wxCursor*,Cursor_CreateLoad)(wxString* name,long type,int
width,int height)
{
#if (wxVERSION_NUMBER >= 2900)
wxBitmapType bm_type = (wxBitmapType) type;
#else
long bm_type = type;
#endif
#ifdef __WXGTK__
 // See http://thread.gmane.org/gmane.comp.lib.wxwidgets.general/45999
return NULL;
#else
return new wxCursor(*name, bm_type, width, height);
#endif
}

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

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

[Jeremy O'Donoghue]

On 26 July 2011 06:59, Eric Y. Kow  wrote:

> On Tue, Jul 26, 2011 at 00:28:01 +0100, Dave Tapley wrote:
> > I'm getting the impression that most people are using wxWidgets 2.9 with
> > wxHaskell, is that a fair assumption?
>
> I was surprised by your impression, but now I see why you may feel that
> way.
>

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


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

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

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

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

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

Jeremy
--
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] Property sheet

[Jeremy O'Donoghue]

Hi Dave,

Playing catch-up after the weekend...

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

On 30 July 2011 00:56, Dave Tapley  wrote:

> On 29 July 2011 21:49, Dave Tapley  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 function

Re: [wxhaskell-devel] Fix for 3019730

[Jeremy O'Donoghue]

I'll be unable to review and commit until after I return from holiday,
which will be 7th Sept. Realistically, by the time I have caught up on
my backlog, it will probably bea few days later.

Eric, since this is a pretty long time to wait, if it looks OK I'm happy
for you to commit.

Jeremy

On Sat, 13 Aug 2011 16:09 +0100, "Eric Y. Kow" 
wrote:
> On Sat, Aug 13, 2011 at 16:01:27 +0100, maciek.makow...@gmail.com wrote:
> > Attached is a patch for the colorDialog return value bug:
> > https://sourceforge.net/tracker/?func=detail&aid=3019730&group_id=73133&atid=536845.
> > 
> > Can someone please review it and, if there are no issues with it, apply?
> 
> Seemed convincing to me, for what it's worth
> 
> -- 
> Eric Kow <http://erickow.com>
> 
> --
> FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
> Subversion made easy with a complete admin console. Easy 
> to use, easy to manage, easy to install, easy to extend. 
> Get a Free download of the new open ALM Subversion platform now.
> http://p.sf.net/sfu/wandisco-dev2dev
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
> 
> Email had 1 attachment:
> + Attachment1.2
>   1k (application/pgp-signature)
-- 
  Jeremy O'Donoghue
  jeremy.odonog...@gmail.com


--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system, 
user administration capabilities and model configuration. Take 
the hassle out of deploying and managing Subversion and the 
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
___
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

[Jeremy O'Donoghue]

I wanted to add one thing to this very useful thread, if only to have a
record of it somewhere:

On 17 September 2011 18:33, Dave Tapley  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

[Jeremy O'Donoghue]

Hi David,

On 21 September 2011 16:49, David Virebayre wrote:

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

[Jeremy O'Donoghue]

Hi Dave,

On 20 September 2011 17:58, Dave Tapley  wrote:

> On 16 September 2011 23:30, Dave Tapley  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] Patch review, testing, and submission

[Jeremy O'Donoghue]

Hi list,

On 21 September 2011 21:58, Dave Tapley  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] SourceForge project

[Jeremy O'Donoghue]

Hi list

On 4 October 2011 01:55, Dave Tapley  wrote:

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

I have added Dave to the SF project, so no need for anyone else to worry.

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] OpenGL support

[Jeremy O'Donoghue]

Hi Dave

Sorry for taking so long to respond.

On 5 October 2011 00:13, Dave Tapley  wrote:

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

I never successfully managed to persuade my Windows machine to do a push to
darcsden. Because there is almost no documentation, this has been hard to
debug!

I am in the process of digging out the old OpenGL support for wxHaskell - it
was removed a while back due to build problems on some targets. You will
probably need to add support for wxGLContext, which was never wrapped, but
the wxGLCanvas code should work provided you link with the correct
libraries.

I've suggested to Joel that I send a patch with wxGLCanvas support which you
can put on your Darcsden repo as a starting point. I'll make it compile and
link for Ubuntu, but I won't have time to check whether it is very complete
or functional, so you will likely have some work to do before it is usable.


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

I've taken a look - very good work, and I'd like to complement you for
taking time to do things properly in every case.

I have put a lot of my 'work in progress' out there, in case it is of
interest/use to anyone.

The code for building a DLL using the C++ compiler (i.e. which went with the
blog post on the subject) is now a Gist at git://gist.github.com/1301115.git

The work in progress for 2.9 support is at
https://patch-tag.com/r/jodonoghue/wxhaskell-branch/home - please note that
this code is not very clean at all - I will gradually merge cleaned up
versions of anything you haven't yet done into your 2.9 branch.

Regards
Jeremy

>
> [1]
> http://www.mail-archive.com/wxhaskell-users@lists.sourceforge.net/msg00925.html
> [2] http://darcsden.com/DukeDave/wxhaskell-dev
>
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] OpenGL support

[Jeremy O'Donoghue]

Hi Dave,

On 21 October 2011 18:43, Dave Tapley  wrote:

> On 21 October 2011 11:28, Jeremy O'Donoghue 
> wrote:
>
>> Did the work on OpenGL, or the branch you mention on darcsden[1] ever
> >> get anywhere? I'd like to nominate myself to work on it :)
>
[snip]
> I am in the process of digging out the old OpenGL support for wxHaskell -
it
> was removed a while back due to build problems on some targets. You will
> probably need to add support for wxGLContext, which was never wrapped, but
> the wxGLCanvas code should work provided you link with the correct
> libraries.
>
> I've suggested to Joel that I send a patch with wxGLCanvas support which
you
> can put on your Darcsden repo as a starting point. I'll make it compile
and
> link for Ubuntu, but I won't have time to check whether it is very
complete
> or functional, so you will likely have some work to do before it is
usable.

That sounds great, I'm on Ubuntu as well. Don't worry about stability,
> it is most definitely a -dev branch!
> If you want to throw it in to my repo that would be great, I've added
> you to the members list so hopefully you can push.
>

Attached is a patch reinstating OpenGL for your wxWidgets 2.9 branch. It
has been tested against a home-built wxWidgets 2.9.2 on a 32 bit install of
the latest Ubuntu (boy, was it a pain getting wxWidgets OpenGL support to
compile, but that's another story).

I should warn that the sample code doesn't work properly yet (it does
compile, link and 'run', but there's nothing in the window). I suspect that
this is because the wxWidgets API in OpenGL has changed, and there needs to
be a bit more event handling in place, but until I have confirmed, you
should consider this only a partial patch.

I'll try to get around to committing to Darcsden if I can manage a
successful push, and will be continuing to look at the sample code to try
to work out why it doesn't work.

Best regards
Jeremy


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

Re: [wxhaskell-devel] OpenGL support

[Jeremy O'Donoghue]

Hi Dave,

On 11 November 2011 18:26, Dave Tapley  wrote:

> On 21 October 2011 11:28, Jeremy O'Donoghue 
> wrote:
> > The code for building a DLL using the C++ compiler (i.e. which went with
> the
> > blog post on the subject) is now a Gist at git://
> gist.github.com/1301115.git
>
> Could you re-post this Gist? It appears to have gone away :(
>

 Works for me, but I have attached the files just in case.

Jeremy


gist1301115-32763969be7c36f609fa9b37d979aca92fd5827f.tar.gz
Description: GNU Zip compressed data
--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] liberal commit access?

[Jeremy O'Donoghue]

On 21 November 2011 18:31, Dave Tapley  wrote:

> Not surprisingly, I am in favour of this :)
>

I have spent a while thinking about this, as it has considerable
ramifications.

I don't think we have ever seen a case of an irresponsible committer (could
such a thing even exist in the Haskell community?), so I'm in favour.


> Given that there aren't going to be any more 2.8.x releases of
> wxWidgets, I'm happy to say:
> If you want a stable(ish) wxHaskell, then use the current hackage
> release along with the last stable wxWidgets release (2.8.12).
> If you want bleeding edge wxHaskell, then pull from code.haskell.org
> along with the latest dev wxWidgets release (currently 2.9.2).
>
> I should note one more time that I'm quite happy to stop supporting
> pre 2.9.x support now, I don't know if anyone has any objection to
> this?
>

The caveat is that I would like to do one more release on Hackage
supporting  2.8.x, as we have a number of valuable bugfixes in the devel
branches which would benefit users of 2.8.x. I will try to do this over
then next two weeks, so my proposal is...

Patches committed until the end of 2011 should be verified on a wxWidgets
2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
version number from 0.13.x to 0.14.x.

How does this sound?

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. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] liberal commit access?

[Jeremy O'Donoghue]

Maciek, Alessandro, and anyone worried about the future.

We will not stop supporting wxWidgets 2.8 until 2.9/3.0 builds are standard
or readily available on all of the supported platforms. The only difference
is that primary development will be on 2.9.x instead of 2.8.x as is the
case right now, so wxHaskell *developers* will need to have wxWidgets 2.9.x
builds (wxWidgets isn't *that* bad to build, although you need to follow
the instructions very carefully)

Basically (using non-DVCS terminology - sorry Eric) the old development
branch will become a maintenance branch and the current feature development
branch becomes the mainline.

What this means is that 2.8.x will see only bugfixes from Jan 2012, and
these will be backported from the 2.9.x branch as needed. This is tedious,
but not hard (we manage more than 30 branches of the same code where I work
in some cases) - and is the only realistic option given the limited
development and test effort available to us.

The bad news is that I volunteer for job of merge monkey(*), which means
that it will get done eventually (sadly for fairly lengthy values of
eventually, unless anyone can invent a 36 hour day :-) That said, if anyone
has a high boredom threshold, they are welcome to take it off of my hands.

(*) actually, we used to have a rubber chicken at work, given to the person
currently merging - had much the same function as a critical section - so
maybe that should be 'merge chicken'.

Best regards
Jeremy

On 28 November 2011 21:41,  wrote:

> Last time I tried I wasn't able to get wx 2.8 to build on Windows.
> After spending a day trying to sort out gcc running out of memory and
> issues with Unicode support I resorted to wxPack. If not for wxPack I
> would have probably given up on using wxHaskell altogether. I'm sure
> it was possible to build it somehow, but I was not prepared to invest
> massive amount of time just to be able to use a GUI library.
>
> Maciek
>
> On Mon, Nov 28, 2011 at 6:24 PM, Alessandro Vermeulen
>  wrote:
> >>  I fear that the majority of Windows
> >> users will be stuck with wxHaskell versions that work with 2.8.
> > Well, you can always bundle the wx libraries with your application in
> that
> > case and create your own wxPack. :-)
> >
> > - Alessandro
> > On 28 nov. 2011, at 19:09, Maciek Makowski wrote:
> >
> >> I don't have a strong opinion on which version of wx should be
> >> supported by wxHaskell, as long as there is at least one that works on
> >> Windows without the need to compile wxWidgets from source. Until there
> >> is a wxPack available for 2.9 I fear that the majority of Windows
> >> users will be stuck with wxHaskell versions that work with 2.8.
> >>
> >> That aside, focusing on supporting a single version of wxWidgets
> >> sounds like a reasonable thing to do.
> >>
> >> Maciek
> >>
> >> On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley 
> wrote:
> >>> On 28 November 2011 11:37, Jeremy O'Donoghue <
> jeremy.odonog...@gmail.com> wrote:
> >>>> On 21 November 2011 18:31, Dave Tapley  wrote:
> >>>>>
> >>>>> Not surprisingly, I am in favour of this :)
> >>>>
> >>>> I have spent a while thinking about this, as it has considerable
> >>>> ramifications.
> >>>>
> >>>> I don't think we have ever seen a case of an irresponsible committer
> (could
> >>>> such a thing even exist in the Haskell community?), so I'm in favour.
> >>>>
> >>>>>
> >>>>> Given that there aren't going to be any more 2.8.x releases of
> >>>>> wxWidgets, I'm happy to say:
> >>>>> If you want a stable(ish) wxHaskell, then use the current hackage
> >>>>> release along with the last stable wxWidgets release (2.8.12).
> >>>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
> >>>>> along with the latest dev wxWidgets release (currently 2.9.2).
> >>>>>
> >>>>> I should note one more time that I'm quite happy to stop supporting
> >>>>> pre 2.9.x support now, I don't know if anyone has any objection to
> >>>>> this?
> >>>>
> >>>> The caveat is that I would like to do one more release on Hackage
> >>>> supporting  2.8.x, as we have a number of valuable bugfixes in the
> devel
> >>>> branches which would benefit users of 2.8.x. I will try to do this
> over then
> >>>> next two weeks, so my proposal is...
> >>>>
> &

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

[Jeremy O'Donoghue]

Hi Dave, all,

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

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

*"we could have an entirely separate cabal project (perhaps "wxc") for this
shared library, and then have wxcore depend on it?"
*
In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll
or libwxc.dylib or whatever) was in a 'normal' place before wxcore gets
built.

On 9 December 2011 14:13, Dave Tapley  wrote:

> On 8 December 2011 22:34, Dave Tapley  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"

[wxhaskell-devel] Happy New Year, wxHaskellers

[Jeremy O'Donoghue]

Hi lists,

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

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

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

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

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

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

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

Best regards

Jeremy
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

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

[Jeremy O'Donoghue]

On 5 January 2012 12:15, Eric Kow  wrote:

>
> On 4 Jan 2012, at 16:59, Dave Tapley wrote:
>
> > I do like the idea that wxc is a separate project, upon which wxHaskell
> depends, however..
> > When configuring wxcore I use wxc's package info, and so require wxc to
> be installed by cabal, and I assume it is the intention of the wxC project
> to be language independent?
>
> I think that would help.  One hope is that if we had a separate project
> that tried harder to be language agnostic, and which had none of the
> trappings of a Haskell project, we might be able to get more help from the
> wxWidgets team.  Make it look like any other project written in C, the
> basic autotools (or more likely Bakefile as wxWidgets use it), the
> pkgconfig stuff, etc.


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

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

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

I accept that Cabal is not an ideal build system, but it does 'just work'
when it comes to cross-platform builds.
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

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

[Jeremy O'Donoghue]

Hi Shelarcy,

It's great to see you back...
2012/1/6 shelarcy 

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


I have just applied this to my local repo, and it will be uploaded tonight.
Thanks.


>
> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
> Windows environment. "cabal install" fail with wx-config-win binary,
> and "cabal install" success with Eric's one. If wxcore depends on
> wx-config package in only Windows environment, I think we should upload
> Eric's wx-config package, and modify wxcore to denped on wx-config package
> on  Windows environment for workaround.
>
> if os(windows)
>   Build-Depends: wx-config


This is surprising. I am using wx-config-win on my Windows environment
(when I run wx-config -v, I get "wx-config revision 26 2006-12-21"). I
deliberately did not choose to use Eric's version as he had noted some
issues with it.

We should investigate your problem further (I am also using wPack 2.8.12)

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] [wxhaskell-users] ANN: wxHaskell 0.13.2

[Jeremy O'Donoghue]

Hi Dave, all
On 6 January 2012 16:02, Dave Tapley  wrote:

> 2012/1/6 shelarcy 
>
>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
>> Windows environment. "cabal install" fail with wx-config-win binary,
>>
>
> Can you remember how this failed, or send some output from the failure,
> and also let us know what version of wxWidgets you have?
> I'm hoping you say you have wx-2.9.x, in which case it could be this issue:
> http://code.google.com/p/wx-config-win/issues/detail?id=21
>
>  and "cabal install" success with Eric's one. If wxcore depends on
>> wx-config package in only Windows environment, I think we should upload
>> Eric's wx-config package, and modify wxcore to denped on wx-config package
>> on  Windows environment for workaround.
>>
>> if os(windows)
>>   Build-Depends: wx-config
>>
>> wx-config package isn't uploaded yet. So, I don't upload newer version,
>> nor attach patch for fixing this problem.
>>
>
> We're still making a decision on whether to continue using
> wx-config(-win), or to adopt Eric's one.
> I'm going to see if I can get a conversation going with the wxWidgets
> people and then I'll send out another mail.
>

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

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

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

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

Does the group have an opinion on this? My feeling is that since the last
commit to wx-config-win was in 2006, it may be a while before fixes come
along, and even then, we will probably need to write the patches.
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] [wxhaskell-users] ANN: wxHaskell 0.13.2

[Jeremy O'Donoghue]

On 9 January 2012 18:09, Dave Tapley  wrote:

> On 9 January 2012 17:04, Jeremy O'Donoghue wrote:
>
>> On 6 January 2012 16:02, Dave Tapley  wrote:
>>
>>> 2012/1/6 shelarcy 
>>>
>>
>> Needless to say, I have immediately hit the wx-config roadblock, since I
>> have compiled a release build of wxWidgets 2.9.3, and wx-config-win only
>> knows about debug builds.
>>
>
> Welcome to the party :)
> Just for the sake of clarity, I feel obliged to question your use of the
> words "release" and "debug"; are you aware of the "Debug Build Changes in
> wx3"?
> Here's the news:
> http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
> (seeing the date of the post made me realise just how far behind we are,
> and also how slow the wxWidgets release cycles are!)
>
>
I wasn't aware of the blog posting, but I did realise that there were
changes in this area - some of this is covered in the install instructions.
Strictly I built with:

BUILD=release
DEBUG_INFO=default
DEBUG_FLAG=1

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


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

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

>
> I turned to the wiki and discovered this:
> http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)
>
> Using it as a guide (note that one can't use wxPack because there are no
> wxPack releases for the development (2.9.x) releases of wxWidgets) I was
> (almost) able to cabal install wxHaskell from my darcsden branch (it failed
> because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
> of time).
>
>
>> I am leaning towards doing something with Eric's wx-config. There are a
>> couple of reasons for this:
>>
>>- It keeps us in control of our own destiny;
>>- Haskell is a *much* more pleasant implementation language for a
>>utility which mainly does text processing than C++.
>>
>> Does the group have an opinion on this? My feeling is that since the last
>> commit to wx-config-win was in 2006, it may be a while before fixes come
>> along, and even then, we will probably need to write the patches.
>>
> Ah, well, yes..
> Firstly the pro-(wx-config-win) items:
> * I contacted the owner of wx-config-win and he made me an owner of the
> Google code project, so we're 'in charge' now.
> * I got a small discussion going on its existence in #wxwidgets on
> freenode. The consensus is that, because /most/ people use Visual Studio
> (in some flavour) to develop with wxWidgets in Windows, there simply wasn't
> the need to maintain wx-config-win. As a result it was never stable enough
> to merit merging in to the wxWidgets code base. By comparison the wx-config
> we know and love on Linux systems (and, I presume, OS X?) is essential and
> so well maintained:
>
> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
> (I didn't realise until recently that it is just a shell script, copied in
> to your install dir and symlinked into your PATH).
>

I did know that wx-config is just a shell script. I'm not so surprised that
most wxWidgets developers on Windows use VS. It's a really nce development
environment. I actually think they advertise support for too many build
options when in reality only a few of them get any serious use.

I was actually planning on looking carefully at wx-config while updating
Eric's Haskell wx-config :-)


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

Re: [wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect

[Jeremy O'Donoghue]

On 11 January 2012 15:55, Dave Tapley  wrote:

> On 11 January 2012 00:56, Dave Tapley  wrote:
> > Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such
> that:
> > 1. It returns a null pointer on non-Windows platforms.
> > 2. It disregards the returned value and returns GetRect().
> >
> > It came in with: "wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen".
> >
> > Dave,
> >
> > [1]
> http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535
>
> Well, I've 'fixed' it, and it appears to work just fine in Ubuntu:
> http://darcsden.com/DukeDave/wxhaskell-dev/patch/2012050758-a1f0b
>
> I'm still curious if anyone can answer my original two questions.
>

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

(2) baffles me completely.

Jeremy
--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

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

[Jeremy O'Donoghue]

Thank you Kenneth,

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

Best regards
Jeremy

On 12 January 2012 14:52, Frodo Kenny  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

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

[Jeremy O'Donoghue]

Hi developers,

Think the subject says it all :-)

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

[wxhaskell-devel] The future of wxC

[Jeremy O'Donoghue]

Hi lists,

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

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

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

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

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

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


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

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

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

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

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

[Jeremy O'Donoghue]

Hi all,

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

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

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

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

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

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

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

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

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

Best regards

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

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

[Jeremy O'Donoghue]

On 17 January 2012 21:38, Jeremy O'Donoghue wrote:

> 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\wxc>wx-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\wxc>wx-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

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

[Jeremy O'Donoghue]

On 17 January 2012 22:40, Jeremy O'Donoghue wrote:

> On 17 January 2012 21:38, Jeremy O'Donoghue wrote:
>
>> 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\wxc>wx-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\wxc>wx-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

Re: [wxhaskell-devel] The future of wxC

[Jeremy O'Donoghue]

On 25 January 2012 15:19, Dave Tapley  wrote:

> On 16 January 2012 00:46, Eric Kow  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 &msg);

  
wxPropertyGrid
wxControl
wxPropertyGridInterface
wx/propgrid/propgrid.h
  
  wxPropertyGrid customization
  Reimplement these member functions in derived
class for better control over wxPropertyGrid behaviour. 
  
void
virtual void
wxPropertyGrid::DoShowPropertyError
(wxPGProperty *property, const wxString
&msg)
DoShowPropertyError

  wxPGProperty *
  property


  const wxString &
  msg


Override in derived class to display error messages in custom manner
(these message usually only result from validation failure). 


If you implement this, then you also
need to implement DoHidePropertyError() - possibly to do nothing, if
error does not need hiding (e.g. it was logged or shown in a message
box).
DoHidePropertyError() 




  
Notice that all of the documentation is retained (which would be very nice
for documenting wxcore), and that function signature is quite easy to
extract.

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

[Jeremy O'Donoghue]

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  wrote:

> On 22 January 2012 00:37, Jeremy O'Donoghue 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: the working code for
Linux was using System.Directory.Posix, when System.Directory will get you
the same thing, but internally select between System.Directory.Posix and
System.Directory.Windows. No prizes for guessing which you need on Windows
:-)


>
> Whilst I did mark wxcInstallDir as dubious, I do quite like the idea of
> having cabal work out which version of wxC it is using to satisfy wxcore's
> dependency, and then linking against exactly that version's header files.
> The only alternatives I can think of are:
>
> 1. Enforce that wxC is installed as a system or user shared library and
> find/version it up as we would any other external library (this would be
> required if we stopped using cabal).
>
> 2. Provide some other (auto-guesswork-or-specify-on-command-line)
> mechanism to tell wxcore: "can you configure yourself with the wxC headers
> here, and link against this shared library".
>

Actually, after some reflection, I don't think wxcInstallDir is dubious at
all. It is, I think, using a documented Cabal API, and it works on all
Cabal platforms.

One area where we do have an issue is that wxc.dll gets installed somewhere
no sane human being would evenr look to find it. I think the solution will
be to do a skeleton wxHaskell project Cabal file which pulls all of the
dlls from their install directory and copies them to dist/build, or
something similar.

Regards
Jeremy


changes-to-make-wxc-build-for-windows_.dpatch
Description: Binary data
--
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

[Jeremy O'Donoghue]

Hi Paulo

[Replying to all]
First, apologies that it has taken so long for you to fail to get going. I
am going to try to cover both wxWidgets 2.8.12 and 2.9.x approaches in the
same mail. Please feel free to choose whichever you prefer. I assume that
you are working on Windows, based on the output you have pasted.
On 1 February 2012 16:03, Paulo Pocinho  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\wxcore>cabal
> 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\wxcore>cd ..\wxc
>
> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wxc>cabal 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\wxc>cd ..\wx
>
> E:\Dev\Repo\wxhaskell-dev-darcs\wxhaskell-dev-v14patch\wx>cabal 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 
> 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  wrote:
> >>
> >> On 22 January 2012 00:37, Jeremy O'Donoghue  >
> >> 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,

[wxhaskell-devel] Darcs repo versions

[Jeremy O'Donoghue]

Hi Eric,

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

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

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

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

Thanks
Jeremy
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

[wxhaskell-devel] Major changes to repo at code.haskell.org

[Jeremy O'Donoghue]

Hi wxHaskellers,

I am about to apply a fairly significant set of changes to the wxHaskell
master repository at code.haskell.org. This is in order that I can apply
the changes needed to support wxWidgets versions from 2.9 onwards, and the
major architectural changes this entails.

The changes will be as follows:

   - The current mainline tip will be branched into a wxhaskell-0.13
   codeline, which will receive only minor updates going forward. This
   codeline will be appropriate for users of wxWidgets 2.8.x. In practice,
   this means that users who pull the darcs repo will see the following new
   directories:
  - wxdirect-0.13: The branch of wxDirect supporting wxWidgets 2.8.x
  - wxcore-0.13: The branch of wxcore supporting wxWidgets 2.8.x
  - wx-0.13: The branch of wx supporting wxWidgets 2.8.x
   - The mainline tip will be tagged WXHASKELL-0-13-BRANCH to show the
   historical relationship between the two branches.
   - The mainline will have the patches needed to update to support
   wxWidgets 2.9.x, based on the work by Dave Tapley and others, and sourced
   from the development repositories on Darcsden, Readers of the
   wxhaskell-devel list will be familiar with these.
  - Because Dave's codebase was branched late last summer, it has not
  been possible to simply push his patches to the wxHaskell mainline, since
  darcs never manages to resolve the differences. For this reason, I have
  developed a smaller, equivalent set of patches on whcih I have tried to
  maintain as much history as possible. This is regrettable, but I
don't see
  an easy way around the problem.
  - There are a number of changes, but the most significant is that
  there is a new module, wxc, which contains the wxWidgets C language
  wrapper. Wxcore is now a pure Haskell module. In addition, we
have removed
  the vestiges of Eiffel support from wxc.
  - The new codeline starts as version 0.15. Users will find that this
  is contained in the directories:
 - wxdirect: wxDirect version supporting wxWidgets 2.9.x and later.
 Because Eiffel support is removed, this version cannot be used with
 wxhaskell 0.13.
 - wxc: The C language wrapper for wxWidgets. On our supported
 platforms (Windows, Linux, OS X), this always generates a
shared library.
 As such it is theoretically possible for wxc to be used as
the basis for a
 wxWidgets binding for another language. There are members of the D
 community playing with this idea.
 - wxcore: A pure Haskell wrapper over wxc.
 - wx: This is basically unchanged from wx in revision 0.13.

When the new versions are committed, they will be accompanied by uploads to
Haskage from both branches, along with build instructions for both versions.

Shortly after the formal release of 0.15, I will be producing a cabal
wrapper for wx-config on Windows. This will simplify the Windows build
significantly, as it currently depends on my privately updated version of
wx-config-win on Google code.

Please shout loudly and soon if you have any problem with what I am
planning to do, as I am planning to make these changes within the next
week. The wxWidgets 2.9 support has been waiting in limbo for too long now
(my fault, I accept).

Best 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

Re: [wxhaskell-devel] [wxhaskell-users] Major changes to repo at code.haskell.org

[Jeremy O'Donoghue]

On 4 April 2012 08:14, Henning Thielemann wrote:

>
> on a second thought ...
>
>
> On Tue, 3 Apr 2012, Jeremy O'Donoghue wrote:
>
>   *  The mainline will have the patches needed to update to support
>> wxWidgets 2.9.x, based on the work
>>
>>by Dave Tapley and others, and sourced from the development
>> repositories on Darcsden, Readers of
>>the wxhaskell-devel list will be familiar with these.
>>
> ...
>
>> +  The new codeline starts as version 0.15. Users will find that this
>> is contained in the
>>directories:
>>
>
> If the new version is such a big change, how about calling it version 1.0?
>
> This would also give us a larger range of versions for the wxWidgets-2.8
> compatibility branch. You know, sometimes even small changes require a
> major version bump, such as adding an instance to Selection, etc.
>

I'm not quite comfortable moving to 1.0 - sounds a bit 'finished' to me.
How about a compromise: I'll bump the new version to 0.20.

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] GitHub repo?

[Jeremy O'Donoghue]

Hi developers,

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

Potential advantages:

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

Downsides:

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

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

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

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

Regards

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

Re: [wxhaskell-devel] Installing wxhaskell for wxwidgets 2.8 on ubuntu

[Jeremy O'Donoghue]

Thanks David.

On 23 April 2012 10:07, David Virebayre  wrote:

> Sorry, I posted that before I actually checked the packages names.. It's
>
> Le 23 avril 2012 11:04, David Virebayre  a
> écrit :
>
> sudo apt-get install wxwidgets2.8-deaders libwxgtk2.8-dev
>>
>
> sudo apt-get install wx2.8-headers libwxgtk2.8-dev
>
>
>
> --
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
> ___
> wxhaskell-devel mailing list
> wxhaskell-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

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

[Jeremy O'Donoghue]

There are a couple of possibilities:

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

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

Best regards
Jeremy

On 27 June 2012 13:38, Henry Lockyer  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_HasBackgroun

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

[Jeremy O'Donoghue]

I think you did the right thing. We'll debug further if the Cabal update
doesn't work for you.

Regards
Jeremy

On 27 June 2012 16:46, Henry Lockyer  wrote:

> ok + thanks. I guess I'll wait for updated cabal if it is imminent .
> Re (1) I could double-check this in the meantime perhaps, but what to look
> for exactly?
> (I relied on "cabal install wx cabal-macosx" on an empty local user pkg
> lib to get it right.)
> Regards/ Henry
>
> On 27 Jun 2012, at 15:28, Jeremy O'Donoghue wrote:
>
> There are a couple of possibilities:
>
> 1) (which I think can be discounted, given your description of 'removed
> everything and started again') is that you didn't do a clean build. The
> dependency checking for wxc is rather fragile (bacause Cabal does not know
> about C dependencies).
> 2) More likely: the latest version of wxcore on Github is 0.90.0.3 - this
> was bumped when I messed up some dependencies in one of the releases (I
> didn't notice because *I* hadn't cleaned up properly before testing. Have
> you tried pulling from the tip of the master branch on Github in the past
> few days (I commited the updates to Github on June 10th - haven't updated
> cabal yet as I have been too busy - will try to do so this evening (UK
> time).
>
> In other words, I think this may be my fault, for which my sincere
> apologies.
>
> Best regards
> Jeremy
>
> On 27 June 2012 13:38, Henry Lockyer  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)
>>   "_

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

[Jeremy O'Donoghue]

Hi all,

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

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

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

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

Very best regards
Jeremy




On 13 June 2013 22:59, Henk-Jan van Tuyl  wrote:

> On Thu, 13 Jun 2013 23:24:31 +0200, Eric Kow  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] CPP to FFI

[Jeremy O'Donoghue]

>From the website...

"To use fficxx, you write a Haskell model of the C++ public interfaces and
fficxx generates both a C wrapper and associated haskell functions and type
classes which reflect specified model of the C++ interfaces. It is
currently the user’s responsibility to specify a correct model of the C++
interfaces, because fficxx does not presently check for model correctness."

This is the opposite of what you need for wxHaskell - the ideal scenario is
to parse the C++ headers and use them to generate Haskell bindings
automatically. Writing correct Haskell representations of the complete
wxWidgets API will be very painful and is likely to be error-prone (it is
quite a large API).

There are a few key things that any automated binding generator needs to
handle:
* Callback functions - these are used extensively in wxWidgets;
* Memory management - the approach in wxHaskell today is not completely
satisfactory and there are quite a few memory leaks.

I believe that the only game in town which is really sufficiently mature is
SWIG - wxPython bindings are already generated by SWIG, so it is known to
be fit for purpose. If the Haskell Qt binding generator goes in this
direction, it may well be what is needed.

Regards
Jeremy


On 14 June 2013 10:27, Eric Kow  wrote:

> Seems like something the author would be very interested in testing on.
> I think the wxHaskell paper talks about how it's done here
> http://research.microsoft.com/pubs/66810/wxhaskell.pdf
>
> On 13 June 2013 20:43, Blair Archibald  wrote:
> > Hi guys,
> >
> > Did anyone see this new C++ foreign function generator mentioned in the
> > haskell weekly news.
> >
> > http://ianwookim.org/fficxx/
> >
> > At the moment the lack of documentation puts me off, but something like
> this
> > could be the end of some of our generation problems. In my mind it's
> great
> > that people are working on this sorta thing!
> >
> > I might look into this deeper at the weekend and see if I could use it to
> > generate wx bindings.
> >
> > Many thanks,
> > Blair
> >
> >
> >
> >
> >
> --
> > 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
> >
>
>
>
> --
> Eric Kow 
>
>
> --
> 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] Compile problems

[Jeremy O'Donoghue]

wxdirect does not support conditional compilation, I'm afraid. It's a large
part of the reason why there are separate branches for wxWidgets 2.8 and
2.9.

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

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

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

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

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

Jeremy


On 9 June 2013 21:52, Charles the Hawk  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  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

[Jeremy O'Donoghue]

That's fine with me. I'll probably continue to contribute when work allows,
so more than happy to be listed.

Please go ahead and make announcements and changes whenever you want to.

Best regards
Jeremy
On 2 Aug 2013 00:59, "Atze Dijkstra"  wrote:

> Thanks!
>
> I created an organisation 'wxHaskell' (
> https://github.com/organizations/wxHaskell) and will soon move my own
> wxHaskell fork into that organisation (and edit the appropriate wiki
> pages). For now I have made Henk-Jan, Jeremy, you and myself owner and
> member of a github 'wxHaskell devel & maintenance' team. Let me know if you
> are ok with that (or want to be removed/added).
>
> Atze
>
> On  2 Aug, 2013, at 09:24 , Eric Kow  wrote:
>
> > On 2 August 2013 07:56, Atze Dijkstra  wrote:
> > I'd prefer to have a maintainer independent project repo, but github
> does not seem to have such a thing,
> >
> > It's well possible.
> > You have to create an organisation somehow
> >
> > GitHub users can be added to orgs
> >
> > I don't know how to go about it exactly, but I'm in a couple of orgs
> myself, so I know it's possible
> >
> > --
> > Eric Kow 
>
>
> - Atze -
>
> Atze Dijkstra, Department of Information and Computing Sciences. /|\
> Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \
> Tel.: +31-30-2534118/1454 | WWW  : http://www.cs.uu.nl/~atze . /--|  \
> Fax : +31-30-2513971  | Email: a...@uu.nl ... /   |___\
>
>
>
>
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] wxHaskell vs GHCi

[Jeremy O'Donoghue]

When I last looked at the problem, the issue was that wxWidgets libraries
use static constructors and destructors in some places.

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

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

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

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

Regards
Jeremy

On 7 October 2013 06:53, Eric Kow  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  wrote:
> > On Sun, 06 Oct 2013 20:08:16 +0200, Eric Kow  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 
>
>
> --
> 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=60134791&iu=/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=60134071&iu=/4140/ostg.clktrk___
wxhaskell-devel mailing list
wxhaskell-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel