Re: [wxhaskell-users] [wxhaskell-devel] [Haskell] ANN: wxHaskell 0.92

[Conal Elliott]

Sounds consistent. I'd expect that the compiled BouncingBalls.exe can be
run twice because you get two separate processes, each opening a top-level
window only once. Sadly, this limitation stops wxHaskell from being useful
for exploratory programming, which is why I stopped using it several years
ago.

On Sat, Sep 5, 2015 at 6:07 AM, Henk-Jan van Tuyl <hjgt...@chello.nl> wrote:

>
> I tried running BouncingBalls.hs in the samples\wxcore directory; inside
> GHCi, it runs the second time only for a short while, then crashes. The
> Windows application log shows exception code 0xc005, which means
> "Access violation". The standalone BouncingBalls.exe can be run multiple
> times without a problem.
>
> Henk-Jan
>
>
>
> On Fri, 04 Sep 2015 23:56:47 +0200, Conal Elliott <co...@conal.net> wrote:
>
> The original bug report (perhaps 7 years ago) was at
>> http://sourceforge.net/p/wxhaskell/bugs/84/ . Seems to be gone now. The
>> symptom was a reliable crash whenever a second top-level window was
>> displayed from a given process, whether in ghci or standalone compiled.
>> Especially inconvenient with ghci, as I typically wanted to open more than
>> one top-level window in that context (exploratory programming).
>>
>> -- Conal
>>
>> On Fri, Sep 4, 2015 at 1:13 AM, Henk-Jan van Tuyl <hjgt...@chello.nl>
>> wrote:
>>
>> On Thu, 03 Sep 2015 16:57:13 +0200, Henk-Jan van Tuyl <hjgt...@chello.nl>
>>> wrote:
>>>
>>> :
>>> > Currently, I am not able to run wxHaskell inside GHCi (on Windows).
>>> :
>>>
>>> I discovered that wxHaskell runs inside GHCi, when I install it locally,
>>> i.o. in a sandbox.
>>>
>>> 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
>>> --
>>>
>>>
>>>
>>> --
>>> ___
>>> wxhaskell-devel mailing list
>>> wxhaskell-de...@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>>>
>>>
>
>
>
>
> --
> 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
> --
>
--
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] [wxhaskell-devel] [Haskell] ANN: wxHaskell 0.92

[Conal Elliott]

The original bug report (perhaps 7 years ago) was at
http://sourceforge.net/p/wxhaskell/bugs/84/ . Seems to be gone now. The
symptom was a reliable crash whenever a second top-level window was
displayed from a given process, whether in ghci or standalone compiled.
Especially inconvenient with ghci, as I typically wanted to open more than
one top-level window in that context (exploratory programming).

-- Conal

On Fri, Sep 4, 2015 at 1:13 AM, Henk-Jan van Tuyl  wrote:

> On Thu, 03 Sep 2015 16:57:13 +0200, Henk-Jan van Tuyl 
> wrote:
>
> :
> > Currently, I am not able to run wxHaskell inside GHCi (on Windows).
> :
>
> I discovered that wxHaskell runs inside GHCi, when I install it locally,
> i.o. in a sandbox.
>
> 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
> --
>
>
> --
> ___
> wxhaskell-devel mailing list
> wxhaskell-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
--
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] [Haskell] ANN: wxHaskell 0.92

[Conal Elliott]

Thanks for the update. What's the status of the old problem of crashing the
host process if one opens more than one top-level window (as typical in
GHCi)?  - Conal

On Fri, Aug 28, 2015 at 1:16 AM, Henk-Jan van Tuyl 
wrote:

>
> L.S.,
>
> I am happy to announce a new version of wxHaskell (0.92).
>
> What is it?
> ---
> wxHaskell[1] is a portable and native GUI library for Haskell. The goal of
> the project is to provide an industrial strength GUI library for Haskell,
> but without the burden of developing (and maintaining) one ourselves.
>
> wxHaskell is therefore built on top of wxWidgets – a comprehensive C++
> library that is portable across all major GUI platforms; including GTK,
> Windows, X11, and MacOS X. Furthermore, it is a mature library (in
> development since 1992) that supports a wide range of widgets with the
> native look-and-feel.
>
>
> What's new?
> ---
>- wxc/setup.hs now stops searching for wxWidgets when a
>  compatible version is found (this solves bug ticket 96)
>- Support for simple Wizards added
>- Calendar support added
>- GCC > 4.5 can now be used on Windows, which is a big
>  improvement, as wxWidgets and wxHaskell must use the
>  exact same GCC, to prevent compatibility problems
>- wxAui is added to wxc, wxAuiNotebook events are added
>  to wxcore and wx
>- Missing GLAttributes added
>- Packet version limits adapted to the newest Haskell
>  Platform
>- Bitness check on Windows no longer uses an external
>  executable
>- wxHaskell can now be installed with MSYS2
>- wxc/Setup.hs is modified to also link to the wx OpenGL
>  libraries for wxGLCanvas
>- The "warning: Adding duplicate image handler for
>  '... file'" messages are removed
>- Created a new class Updating with corresponding event
>  "update". Provided instances for TextCtrl and ComboBox:
>  update gets called when the text changes.
>- Support for wxSplashScreen in wxc and wxcore is added
>- Many warnings are solved
>
> Links
> -
> See the homepage of wxHaskell for more information:
> https://wiki.haskell.org/WxHaskell
>
> The packages are:
>- wxc   https://hackage.haskell.org/package/wxc
>- wxdirect  https://hackage.haskell.org/package/wxdirect
>- wxcorehttps://hackage.haskell.org/package/wxcore
>- wxhttps://hackage.haskell.org/package/wx
>
> Regards,
> Henk-Jan van Tuyl
>
>
> [0] https://www.wxwidgets.org
> [1] https://wiki.haskell.org/WxHaskell
>
>
>
> --
> 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
> --
> ___
> Haskell mailing list
> hask...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
>
--
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] Notes on installing wxHaskell on Mac OS Snow Leopard

[Conal Elliott]

Worked for me. Thanks very much, Henry!  -- Conal

On Mon, Jul 2, 2012 at 6:31 PM, Henry Lockyer henry.lock...@ntlworld.comwrote:

 Dear wxHaskell users / aspiring users,

 These are a few notes from getting a working 64bit installation of
 wxHaskell on Mac OS in case they are of any use to anyone.

 - This is for a 64-bit configuration starting from having 64-bit ghc 7.0.4
  (HP 2011.4.0.0 64)

 - Mac os 10.6.8 snow leopard (with xcode 3.2.6)

 (This is not currently listed as a known working configuration at
 http://www.haskell.org/haskellwiki/WxHaskell/MacOS_X )

 wxHaskell version issue:
 There is a linking problem with using the current wxc-0.90.0.3 and
 wxcore-0.90.0.1 from Hackage.
 They install ok but ghci throws a load of 'undefined symbols' when
 compiling from haskell using wxcore or wx .
 Thanks to Jeremy O'D. for identifying that the problem should disappear
 again in the latest development versions,
 which I got from:https://github.com/jodonoghue/wxHaskell

 So the following installation was completed:

 1. wxWidgets 2.9.3
 - installed globally (as dylib) in /usr/local...

 2.  cabal-macosx-0.2.2  (cabal install from Hackage)
 3.  wxdirect-0.90.0.1(cabal install from Hackage)
 4.  wxc-0.90.0.4   === Development version from Github
 5.  wxcore-0.90.0.3   === Development version from Github
 6.  wx-0.90.0.1(cabal install from Hackage)
 (plus some additional dependency packages pulled in by cabal not shown)


 wxWidgets
 
 Stayed with wxWidgets 2.9.3 as being the current advertised 'stable'
 development release.

 2.9 needed with wxHaskell 0.90 for 64bit.

 homebrew/macports may offer a convenient alternative approach to getting
 wxWidgets.
 I'm not familiar with these and don't have either installed so I just
 built wxWidgets myself as follows:

 Downloaded direct from http://wxWidgets.org/downloads/#latest_dev   page
 (tar.bz2) to a local
 user directory.

 Configure to avoid any potential problems that may arise from
 https://github.com/jodonoghue/wxHaskell/issues/2
 by temporarily editing out all inclusions of the QuickTime framework in
 the configure script file in the top level wxWidgets
 directory (only two places, simplest just to remove in both cases).

 - A response to a wxWidgets forum post suggested that the mac-related
 stuff is developing all the time and
   advocated pulling the latest widgets development build, but I stuck to
 2.9.3 in the interests of stability.
 - Another small potential advantage to taking the latest widgets
 development build may be getting changeset 71086
which aims to stop the inclusion of the QuickTime framework for
 i86_64-ONLY widgets builds.

 Mac Snow-Leopard evidently (usually) comes with wxWidgets 2.8
 pre-installed.
 I didn't want to alter the default Mac pre-installed stuff as far as
 possible, so adopted a configuration which left the
 2.8 libraries installed and only disabled the 2.8 wxrc and wx-config
 executables in the path.

 If you want to check in advance for unlikely clashes with pre-existing
 stuff, then check /usr/local/lib where the dylib files
 libwx_osx_cocoau_*  and a wx directory will be placed.
 /usr/local/bin will get new wx-config and wxrc*

 Assuming my setup is standard,  wx-config for 2.8 should be found in the
 path at /usr/bin/wx-config and is a symlink to
 the main 2.8 stuff which is in /usr/lib so simply remove this link:
  $ sudo rm -iv /usr/bin/wx-config

 There is also wxrc which is a link to wxrc-2.8 in the same directory, so
 remove the link but leave wxrc-2.8 there:
 $ sudo rm -iv /usr/bin/wxrc

 (These links can then simply re-created to re-instate path access to the
 2.8 executables if wanted again in the future.)

 Create and cd to suitably named wxWidgets build subdirectory, then:

 $ ../configure --enable-macosx_arch=x86_64 --enable-unicode
 --disable-debug --with-osx_cocoa --enable-stc --enable-aui
 --enable-propgrid --enable-xrc --enable-ribbon --enable-richtext
 --enable-webkit --with-opengl
 +
 $ make
 +
 $ sudo make install

 (/usr/local is the default prefix in configure)

 Check with command:

 $ wx-config --list

 Default config is osx_cocoa-unicode-2.9
 ...

 $ wx-config --version
 2.9.3


 Further checks:

 1. cd to the wxWidgets samples and demos folders and $ make in each to
 check the samples and demos are working plausibly
 (I found a couple of odd things but generally were working).

 2. Build minimal.cpp from https://github.com/kowey/debug-wx


 wxHaskell
 

 Dependency chain wx - wxcore - wxc - wxdirect

 Note: this is for a local user install.

 get master commit  Merge branch 
 'GHCI_FIX_BRANCH'https://github.com/jodonoghue/wxHaskell/commit/1d6cff7be5b36032d85f068ea0266ec9da910298
   (at time of writing) eg. via CloneInMac
 at https://github.com/jodonoghue/wxHaskell

 wxdirect  cabal-macosx
 -

 $ cabal install wxdirect cabal-macosx

 wxc
 -

 cd to wxc folder of local copy from github

 The 

Re: [wxhaskell-users] [Announce] wxHaskell 0.90

[Conal Elliott]

I'm excited to see progress in ghci-friendliness! I installed
wxWidgets-devel-2.9.3 via macports and then wxHaskell, and I get the
following when trying to run a simple wxHaskell program in ghci:

Loading package wxc-0.90.0.2 ... can't load framework: QuickTime
 (dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 9): no
 suitable image found.  Did find:
 /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching
 architecture in universal wrapper
 /System/Library/Frameworks/QuickTime.framework/QuickTime: no matching
 architecture in universal wrapper)


Any suggestions? I'm using Mac OS 10.6.8 and GHC-7.0.4 from the Haskell
Platform.

-- Conal

On Fri, Apr 13, 2012 at 3:50 PM, Jeremy O'Donoghue 
jeremy.odonog...@gmail.com wrote:

 Hi Haskellers,

 I am delighted to announce the release of wxHaskell 0.90. This release
 represents a significant milestone for us as it includes support for
 wxWidgets 2.9.x.

 The release is avalable from Hackage and as a darcs repo from
 http://code.haskell.org/wxhaskell. Build and installation instructions
 have been updated on the Haskell wiki at
 http://www.haskell.org/haskellwiki/Wxhaskell.

 Highlights of the new release:

- Builds and runs cleanly on 64 bit platforms (particularly MacOS X
Lion).
- The wxWidgets C wrapper is now built as a DLL on all platforms.
   - This is reported to enable meaningful use of wxHaskell in GHCi,
   at least on OS X and Windows.
   - It also theoretically allows wxc to be used independently of
   wxHaskell as the basis of a wxWidgets wrapper for other programming
   languages. Some D language hackers have expressed an interest in this.
   - New controls:
   - Styled Text Control (actually, this is reinstated as it was
   'lost' a while back during cabalization)
   - OpenGL support
   - PropertyGrid control
- Many events added in anticipation of wrapping more controls in the
near future.

 There were many contributors to this release, the most notable being Dave
 Tapley (with the generous support of Mentics Inc.). Dave was responsible
 for the refactoring of wxc and PropertyGrid support. Eric Kow put in quite
 a bit of work with Kenny Frodo, Doaitse Swierstra and Alessandro Vermeulen
 on MacOS support. There were a couple of contributions from long-time
 wxHaskell contributor shelarcy, and bug reports, fixes and support from a
 larger community than I ever realised we had.

 Support for wxWidgets 2.8.x will continue in a 'maintenance mode'
 continuing from the wxHaskell 0.13 codeline. If you continue to use the old
 codeline, please take note of the changes to the procedure to get the
 correct version for your needs. This is also documented at
 http://www.haskell.org/haskellwiki/Wxhaskell.

 Thanks to everyone involved.

 Best regards

 Jeremy


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


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

Re: [wxhaskell-users] wxHaskell and 1 usable level up?

[Conal Elliott]

My wxhaskell GUI libs (Phooey  GuiTV) as well as Eros are on hold until
wxhaskell gets fixed to not kill its parent process (e.g. ghci) on GUI
restart. I don't know what's going on with that problem.  This problem is a
long-standing one.  I'm wondering what alternatives there might be to
wxhaskell  gtk2hs (which has problems of its own, especially on mac os x).

  - Conal

On Sat, Feb 6, 2010 at 1:48 PM, Henk-Jan van Tuyl hjgt...@chello.nl wrote:


 Hallo Günther,

 I haven't tried GuiTV; it depends on Phooey, which needs some updates to
 be compilable. Phooey depends on the old package reactive-0.5 (I had to
 change the Phooey.cabal file for that), but that version of reactive
 doesn't compile with GHC 6.10

 Met vriendelijke groet,
 Henk-Jan van Tuyl


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



 On Sat, 06 Feb 2010 02:44:02 +0100, Günther Schmidt gue.schm...@web.de
 wrote:

  Hallo Henk-Jan,
 
  bedankt. Is die ook al gebruikbar?
 
  Groetjes
  Günther
 
  Am 01.02.10 17:59, schrieb Henk-Jan van Tuyl:
  On Sun, 31 Jan 2010 23:37:33 +0100, Günther
  Schmidtgue.schmidt-S0/gaf8t...@public.gmane.org
  wrote:
 
  Hi all,
 
  I just played around with FunctionalForms until I hit a nit, as did the
  author apparently, which he fixed with a hack and entirely fails to
  mention.
 
  Quite disappointing I must admit as it was one of the nicest libs for
  wxHaskell I've seen so-far. Up to the nit of course.
 
  Is there an alternative to using wxHaskell or is there a the moment no
  other way around using tons of boilerplate code with IORefs of MVars?
 
  Günther
 
  Maybe GuiTV:
http://www.haskell.org/haskellwiki/GuiTV
 
  Met vriendelijke groet,
  Henk-Jan van Tuyl
 
 
  --
  http://Van.Tuyl.eu/
  http://members.chello.nl/hjgtuyl/tourdemonad.html
  --
 


 --


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

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

Re: [wxhaskell-users] wxhaskell vs. gtk2hs

[Conal Elliott]

On Fri, Jan 22, 2010 at 11:23 PM, Gour g...@gour-nitai.com wrote:

 On Fri, 22 Jan 2010 17:15:00 -0800
  Conal == Conal Elliott wrote:

 Hello Conal,

 Conal I've worked with both wxhaskell and gtk2hs.  I prefer wxhaskell
 Conal for elegant design.  And I like that it gives me a native Mac OS
 Conal X look.  There is a partially working native Gtk for Mac, but I
 Conal don't think it works with 3D, which was a requirement for me.

 This is nice to hear about wxhaskell.

 Conal In spite of these reasons, I'm using gtk2hs for the time being,
 Conal because wxhaskell has a problem that makes it very unfriendly to
 Conal ghci.  The second attempt to display a GUI kills its host
 Conal process.  This behavior is okay for many (but not all) compiled
 Conal programs, but is a killer for interactive/exploratory
 Conal development.  As soon as I hear that this problem is fixed, I'll
 Conal very happily return to wxhaskell.

 Isn't it that, at one point of time, gtk2hs has similar problem when
 working within ghci?


I don't know gtk2hs's history.


 Conal Longer term, I want Haskell GUI programming to move away from
 Conal these massively complex OO imperative frameworks to something
 Conal much more elegant and harmonious with the spirit and benefits of
 Conal pure functional/denotative programming.

 I must say that I'm looking/reading your FRP stuff from the distance
 thinking it's way above the head of this Haskell noob, but I tend to
 agree that it should be possible to do GUI in Haskell in a different
 way.


And not just a *different* way, but specifically a *denotative* way, i.e. in
which our programs are built entirely out of pieces that have tractably
precise meanings.

I'm adopting this term denotative from Peter Landin's seminal paper The
Next 700 Programming Languages.  See
http://conal.net/blog/posts/is-haskell-a-purely-functional-language/#comment-35882.
  Previously I've been using the alternative denotational.


 Do you consider it can be achieved on the top of present libs like
 wx/gtk+ or it would require writing new stuff?


I expect that even libraries like wx/gtk+ *can* be used as part of a
faithful implementation of denotative GUI programming, if we take great care
to insulate our denotation from the complex semantics of those libraries.
However, this insulation may be so difficult to establish and maintain that
it's easier to start from scratch.

   - Conal
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Investigating wxHaskell's die-on-restart problem

[Conal Elliott]

I spent some time today tracking down the die-on-restart problem with
wxHaskell.


Here's a simple demo of the problem:

import Graphics.UI.WX
main = io  io where io = start (frame []  return ())

(See
http://sourceforge.net/tracker/?func=detailatid=536845aid=1610984group_id=73133.)

In practice, the die-on-restart problem happens commonly when using
wxHaskell in ghci.  This behavior is why I stopped using wxHaskell and
switched to gtk2hs, though I'd love to change back, since wxHaskell is a
more elegant library, and gtk2hs and open don't work together under native
os x (and the X-based macports version generates ugly GUIs).

I didn't get the the heart of the problem, though I may have gotten close.
This note records my journey, in the hope that together we can get further.



In Graphics.UI.WX (in the wx package):

-- | 'start' runs the GUI.
start :: IO a - IO ()
start io
  = run (unitIO io)

In Graphics.UI.WXCore.Types (wxcore):

-- | Ignore the result of an 'IO' action.
unitIO :: IO a - IO ()
unitIO io
  = do io; return ()

In Graphics.UI.WXCore (wxcore):

-- | Start the event loop. Takes an initialisation action as argument.
-- Except for 'run', the functions in the WXH library can only be called
-- from this intialisation action or from event handlers, or otherwise
bad
-- things will happen :-)
run :: IO a - IO ()
run init
  = do appOnInit (do wxcAppInitAllImageHandlers
 init
 return ())
   performGC
   performGC

I guess the unitIO in start is unnecessary, and start == run.

Appartently, the fatal re-initialization happens in appOnInit or
wxcAppInitAllImageHandlers, or maybe both.

In Graphics.UI.WXCore.Events:


--
-- Application startup

--
-- | Installs an init handler and starts the event loop.
-- Note: the closure is deleted when initialization is complete, and
than the Haskell init function
-- is started.
appOnInit :: IO () - IO ()
appOnInit init
  = do closure  - createClosure (return () :: IO ()) onDelete (\ev -
return ())   -- run init on destroy !
   progName - getProgName
   args - getArgs
   argv - mapM newCWString (progName:args)
   let argc = length argv
   withArray (argv ++ [nullPtr]) $ \cargv - wxcAppInitializeC
closure argc cargv
   mapM_ free argv
  where
onDelete ownerDeleted
  = init

What's going on here?

wxcAppInitializeC sounds pretty hard core.  In
Graphics.UI.WXCore.WxcClassesMZ:

-- | usage: (@wxcAppInitAllImageHandlers@).
wxcAppInitAllImageHandlers ::  IO ()
wxcAppInitAllImageHandlers
  = wx_ELJApp_InitAllImageHandlers
foreign import ccall ELJApp_InitAllImageHandlers
wx_ELJApp_InitAllImageHandlers :: IO ()

-- | usage: (@wxcAppInitializeC closure argc argv@).
wxcAppInitializeC :: Closure  a - Int - Ptr (Ptr CWchar) -  IO ()
wxcAppInitializeC closure _argc _argv
  = withObjectPtr closure $ \cobj_closure -
wx_ELJApp_InitializeC cobj_closure  (toCInt _argc)  _argv
foreign import ccall ELJApp_InitializeC wx_ELJApp_InitializeC :: Ptr
(TClosure a) - CInt - Ptr (Ptr CWchar) - IO ()

In wxcore-0.11.1.2/wxc/src/ewxw_main.cpp:

EWXWEXPORT(void, ELJApp_InitializeC) (wxClosure* closure, int _argc,
char** _argv)
{
  char* args[] = { wxc, NULL };

  initClosure = closure;
  if (_argv == NULL) {
/* note: wxGTK crashes when argv == NULL */
_argv = args;
_argc = 1;
  }
  APPTerminating = 0;
  wxEntry(_argc,_argv);
  APPTerminating = 1;
  /* wxPendingEvents is deleted but not set to NULL - disaster when
restarted from an interpreter */
#if !defined(WXMAKINGDLL)  !defined(WXUSINGDLL)
  wxPendingEvents = NULL;
#endif
#if defined(wxUSE_ODBC)  (wxUSE_ODBC != 0)
  wxDbCloseConnections();
#endif
}

(There is also a version for Win32.)

That disaster warning sounds relevant.  I didn't know whether the
wxPendingEvents NULLing was in active code, so I added some non-compilable
code in a new #else branch.  Recompilation succeeded, so I gather that the
NULLing is happening.

Next, I added printfs before  after the wxEntry call in
ELJApp_InitializeC.  Sure enough, on the second start, wxEntry is called but
not returned from.

What's initClosure?  The only use I could found is in
wxcore-0.11.1.2/wxc/src/wrapper.cpp:


/*-
The main application

-*/
wxClosure* initClosure = NULL;

bool ELJApp::OnInit (void)
{
  wxInitAllImageHandlers();
  initIdleTimer();
  if (initClosure) {
  

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[Conal Elliott]

As long as there's a single binary (per release per platform) I'm for opengl
being part of it.

On Sat, Mar 29, 2008 at 6:56 AM, Eric Y. Kow [EMAIL PROTECTED] wrote:

 Hi,

 Answering the one question I know an answer to.

  In the meanwhile, I also found that the 0.10.3 binaries loose the
  opengl support compared with 0.9.4 as pointed in
  http://wxhaskell.sourceforge.net/download.html.
  Is there some reason for this?

 There used to be a flag bug in wxWidgets/wxHaskell, where (1)
 wxWidgets/wxHaskell would include opengl support even if you did not
 ask for it and (2) you still needed to pass --with-opengl in order
 for the appropriate right set of linker flags to be used when building
 applications.  Otherwise, people got strange GL-related errors when
 compiling their apps, even if they weren't using OpenGL in any way.

 We have now fixed that error so that you can now compile it without that
 flag and still link your applications succesfully.

 That said, we have not established a policy on what extra batteries
 should be included with the default binaries.  I guess a good thing to
 aim for is the most extras we can get that also come with a vanilla
 wxWidgets on all platforms.  If you're willing to do research on that,
 we can go re-think what flags to use.  I'm guessing that since prior
 versions of wxHaskell had opengl support, this kind of thing is OK.

 I'm personally hoping that a future wxhaskell will allow to install
 extras separately (e.g., that you could download just a binary for
 opengl support), but we haven't really worked out the right way to
 do this right.

 So what does this mean for you?  Well, if you're willing to do so, you
 could recompile it yourself with flags.  Otherwise, we could think about
 making yet another release (0.10.3-1) with opengl and some minor fixes
 in the makefile/configure script.

 --
 Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow
 PGP Key ID: 08AC04F9

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


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

Re: [wxhaskell-users] wxhaskell 0.10.2 on hackage (experimental)

[Conal Elliott]

Hi Eric,

Thanks for the progress update.  Your remark about 2.6 only raises a
question for me: What's the deal on wxhaskell and ghci-friendliness?  Do we
still have to use wxWindows/wxWidgets 2.4.2 in order to run more than one
GUI per ghci session?  Will it be possible at all any more?

  - Conal

On Feb 16, 2008 5:24 AM, Eric Y. Kow [EMAIL PROTECTED] wrote:

 Hi everyone,

 I have uploaded an unofficial pre-release of wxhaskell on hackage.  It is
 available as two packages, wxcore and wx.

  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wxcore-0.10.2
  http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wx-0.10.2

 Let me stress that this is only experimental; it is NOT an official
 release.

 Summary
 ---
 I think this works under Linux and MacOS X, but not under Windows.

 It seems to work best under MacOS X (10.4 on Intel).  If you have any
 trouble,
 you are likely going to have to install wxcore by hand (passing in
 configure
 flags, etc) and then install wx automatically:

  cabal install wx

 General notes
 -
 This only works with wxWidgets 2.6.

 Windows and maybe MacOS X
 --
 The wxcore cabal script is merely a wrapper around the makefile and the
 configure script.  So you'll still need to have make and the ability to
 run
 shell scripts.  As shelarcy pointed out, this probably does not work for
 Windows, and you'll have to go the old-fashioned route (using the darcs
 repository as well).

 MacOS X
 ---
 The configure options that worked for me (wxWidgets) are
  ./configure --enable-display --enable-unicode --with-opengl --with-mac
 --without-odbc --enable-mediactrl --disable-monolithic

 Note that I also had to do
  sudo mkdir -p /usr/local/wxhaskell/bin
  sudo ln -s /usr/local/bin/wx-config /usr/local/wxhaskell/bin

 This makes the wxcore package use your version of wxWidgets and not the
 one that came with the
 system.

 Linux
 -
 On Linux, I had to supply --with-opengl to the configure script:

  runhaskell Setup --configure-opt=--with-opengl

 I noticed also that on Ubuntu Gutsy Gibbon, I had some trouble
 running sample applications with wxGTK 2.8, so I aptitude installed
 libwxgtk2.6-dev and specified to wxhaskell to use it instead of the
 newer version:

  mkdir -p /usr/local/wxhaskell/bin
  ln -s 
 /usr/lib/wx/config/gtk2-unicode-release-2.6/usr/local/wxhaskell/bin/wx-config
  runhaskell Setup --configure-opt=--with-opengl

 Where to next?
 --
 I hope that this makes life a little easier, and that the being
 on hackage either attracts more users/contributors to wxhaskell.

 Here are some key questions we need to answer for 0.10.3:
 * Can we make it possible to run wxhaskell programs under Linux
  without the --with-opengl flag? Seems to be fine under MacOS X.

 * Why are people having build trouble lately?
  * You have to obliterate a patch for wxhaskell on PowerPC, why?
  * What about the issue that Malcolm pointed out with not linking to
   the -gl version of wxWidgets [odd; doesn't wx-config tell the right
 thing?]
  * What about Gwern's too many symbolic links problem?

 * Why doesn't wxhaskell work with wxGTK 2.8?  I thought we had
  worked out some compatibility fixes?

 * What do we need for Windows users to be able to cabal install wx?

 ... and many more.  Please help!

 --
 Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow
 PGP Key ID: 08AC04F9

 --
 Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow
 PGP Key ID: 08AC04F9

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


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

[wxhaskell-users] wxhaskell, cabal, and linux

[Conal Elliott]

I have several libraries on hackage that depend on wxhaskell.   Because
wxhaskell is not itself on hackage, my libraries won't compile and won't
haddock there.  I'd really like to have cross-library haddocks all working.

Is Cabal for wxhaskell in the works?  Are there roadblocks?

If Ross could build wxhaskell (both libs and docs) on the Linux machine that
hosts hackage, then he could hack around lack of Cabal building.  But he's
having trouble.

What version of wxhaskell is recommended for Linux?  Does it build
successfully?  Is there anyone who would help Ross through the process?

Thanks,  - Conal


-- Forwarded message --
From: Conal Elliott [EMAIL PROTECTED]
Date: Thu, Feb 14, 2008 at 10:12 AM
Subject: Re: off-world libs  docs
To: Ross Paterson [EMAIL PROTECTED]


Thanks.  I'll ask around.  - Conal


On Thu, Feb 14, 2008 at 10:07 AM, Ross Paterson [EMAIL PROTECTED] wrote:

 On Wed, Feb 13, 2008 at 10:25:30AM -0800, Conal Elliott wrote:
  Some of my packages use wxhaskell, which is not on hackage.  That means
  those libs fail to compile *and* to produce haddock docs on hackage.
  I love the idea of people browsing through lib docs, following links
  from one lib to another to another.  And I don't know how to get there.
  Any ideas?  Perhaps one improvement would be to run haddock even when
  compiling fails -- assuming there's a place on hackage to deposit the
  .haddock files or a way to find them off of hackage.  Or, maybe rely on
  folks to make sure all of their dependencies get moved onto hackage.
  I don't know why wxhaskell is not there.   I don't see gtk2hs there
  either.

 It seems from the sourceforge page that someone is moving on wxhaskell
 with the aim of turning it into a Cabal package, which could then join
 the party, but I don't know what the timescale is.

 In the meantime, I could hack around it (as I did with base), but I
 need to be able to build wxhaskell and its documentation with ghc 6.8.2
 and haddock2 on Linux, which I've not managed in my initial attempts.
 Which version of wxhaskell is preferred, and do know of anyone who has
 done this?

 Ross

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

Re: [wxhaskell-users] wxhaskell and ghci - runs once only

[Conal Elliott]

I think the key here is to use wxWindows version 2.4.2 (later renamed to
wxWidgets).  I think the issue is static initializers in later versions. -
Conal

On Feb 9, 2008 1:46 PM, Andrew U. Frank [EMAIL PROTECTED] wrote:

 why does wxhaskell with ghci run only once and then dies?

 is this an error in my code or a general 'feature'?
 could it be fixed?

 thank you!

 andrew



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

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

Re: [wxhaskell-users] wxHaskell for linux (ubuntu)?

[Conal Elliott]

Hm.  The static initializers are problematic on Windows as well, which is
why I stayed with wxWindows-2.4.2.  Perhaps the same solution works on
Linux?

Does *anyone* have wxHaskell and ghci working together on Linux, without
having to restart ghci after each GUI?

  - Conal

On Dec 30, 2007 4:35 PM, Mads Lindstrøm [EMAIL PROTECTED] wrote:

 Hi Conal

  I'm setting up a linux dev machine (ubuntu 7.10).  What do folks
  recommend for wxWidgets and wxHaskell?  I like using wxHaskell in
  ghci, in case that's a consideration on Linux as it is on Windows.

 I am afraid you will have to forget about wxhaskell, linux, and GHCi
 working together. When you have started a Wxhaskell app in GHCi once,
 you will have to restart GHCi before starting another Wxhaskell app. It
 is late and might remember wrongly, but I do believe it has something to
 do with GHCi not reinitializing C-libraries.

 I am running Debian, which is closely related to Ubuntu, and I am using
 the WxWidgets based on gtk2.6.3-0.10. But any Gtk2.6 will properly do.

 As far as I remember, you must also enable (not disable) opengl when
 compiling wxwidgets. Also this page
 http://wxhaskell.sourceforge.net/building.html says the same.


 Greetings,

 Mads

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


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

[wxhaskell-users] wxHaskell for linux (ubuntu)?

[Conal Elliott]

I'm setting up a linux dev machine (ubuntu 7.10).  What do folks recommend
for wxWidgets and wxHaskell?  I like using wxHaskell in ghci, in case that's
a consideration on Linux as it is on Windows.  Thanks,  - Conal
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] [Haskell-cafe] GUI

[Conal Elliott]

Can anyone help Miguel with wxhaskell on Mac?  - Conal

On Dec 12, 2007 12:30 PM, Miguel Mitrofanov [EMAIL PROTECTED] wrote:

 I was unable to make wxhaskell really work. The most helpful resource
 I've found is http://riftor.g615.co.uk/wxhaskell/wxhchanges.txt, but
 after applying this changes wxhaskell programs complain about
 undeclared _wxEVT_COMMAND_LIST_GET_INFO and I was unable to fix
 this; also, I don't think it's right when sources don't compile
 without changes. There is a binary distribution for Mac, but it's
 installation failed without any evident reason.

 12.12.2007, в 22:52, Conal Elliott писал(а):

  I prefer the elegant high-level style of wxhaskell over the current
  state of gtk2hs.  duncan has said he's interested in making a
  gtk2hs more elegant, and daan has said he'll start supporting
  wxhaskell again.  i don't know which will happen first.  - Conal
 
  On Dec 12, 2007 11:47 AM, Neil Mitchell [EMAIL PROTECTED] wrote:
  Hi
 
   Is there any really cross-platform GUI library for Haskell?
  
   Gtk2Hs is good (I suppose), but it requires X. OK, I have X, but
  it's
   not native on my Mac; some Mac users don't install it and almost
   all Mac users don't always run it.
 
  On Windows, Gtk2hs is not as native as wxHaskell, but is the best GUI
  toolkit available. On Windows, there is no requirement to have X
  installed. The Gtk2hs developers (or more specifically Duncan) have
  shown a continuing desire to make Gtk2hs more Windows friendly, even
  to the point of filing Gtk bugs and tracking their progress. I'm sure
  having made Mac friendly noises, they will come rushing to your aid
  :-)
 
  Thanks
 
  Neil
  ___
  Haskell-Cafe mailing list
  [EMAIL PROTECTED]
  http://www.haskell.org/mailman/listinfo/haskell-cafe
 
  ___
  Haskell-Cafe mailing list
  [EMAIL PROTECTED]
  http://www.haskell.org/mailman/listinfo/haskell-cafe


-
SF.Net email is sponsored by:
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-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] shifting text in a TextCtrl

[Conal Elliott]

I'm using an TextCtrl for output, and I want the beginning of the text to
show rather than the end, when the text won't fit.  The default seems to be
the other way.  Does anyone know how I can get the beginning showing after
changing the text attribute?  Thanks,  - Conal
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] keyboard events for MDI child frames

[Conal Elliott]

Is there a way to get keyboard events for MDI child frames?  My on
keyboard handlers never respond, though they work for widgets.   - Conal
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] setting button size

[Conal Elliott]

I want to resize my button control to be square.  I tried set ctl [ size :=
Size 100 100] with no visible effect.  Same with clientSize  outerSize.
Does anyone know the required magic?   Thanks.  - Conal
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now   http://get.splunk.com/___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] building problems

[Conal Elliott]

Wolfgang,

In case you don't know (as I didn't), be aware that wxWidgets 2.6 and later
are not ghci-friendly, so for ghci use, you'll probably prefer 2.4.2.   More
info at http://darcs.haskell.org/packages/phooey/README .  Cheers,  - Conal

On 2/17/07, Wolfgang Jeltsch [EMAIL PROTECTED] wrote:


Am Samstag, 17. Februar 2007 20:59 schrieb Eric Y. Kow:
 […]

 It seems the official release does not compile against wxWidgets 2.8(which
 came out long after the release).

Hmm, this could be the explaination.  I tried wxWidgets 2.8 because
http://wxhaskell.sourceforge.net/building.html says that one should
install
the latest stable version of wxWidgets.  I will try building against
wxWidgets 2.6 now.

 […]

Best wishes,
Wolfgang

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] horizontal stretch bug??

[Conal Elliott]

I'm stumped on a problem with horizontal stretching, and I don't know
whether I've hit a bug or my own ignorance.  I want to place two sliders
horizontally and have them both stretch with the frame.  Instead, the left
one stretches, and the right one doesn't.  (I'm not sure I have stretch
and expand clear in my mind.  The right slider gets more space but doesn't
fill it up.)  One example of this behavior is at
http://conal.net/phooey/images/ui3.png.  I've also included below a simple,
self-contained example.  I'd like to get this behavior fixed in two
wxhaskell-powered libraries I'm about to release.

I'm using row to get the horizontal juxtaposition, and hfill.widget for
the slider layouts.  I'd sure appreciate help from someone who knows about
wxHaskell layout.

Thanks, - Conal



import Graphics.UI.WX

main = runWio ssBeside

type Wio = Panel () - IO Layout

-- Simple slider
sslider :: Wio
sslider w = do ctl - hslider w True 0 10 []
  return (hfill (widget ctl))

ssBeside :: Wio
ssBeside w = do la - sslider w
   lb - sslider w
   return (row 0 [la,lb])


-- Run a 'Wio': handle frame  widget creation, and apply layout.
runWio :: Wio - IO ()
runWio wio = start $
 do  f- frame [visible := False]
 pan  - panel f []
 l- wio pan
 set pan  [ layout := l ]
 set f[ layout := hfill (widget pan), visible := True ]
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] process crashes on second 'start'

[Conal Elliott]

I did get wxHaskell-0.10.1 and wxWidgets-2.4.2 working together.  Multiple
'start's (hence ghci-friendly), and no string truncation, so I'm content.
And I prefer the more vertically compact visual style of sliders in 2.4.2over
2.6.3.  I was fooled at first in recompiling wxWidgets with
--enable-unicode.  I had to completely empty out my mybuild directory, not
just make clean to fix string truncation (unicode glitch).   - Conal

On 12/8/06, Jeremy O'Donoghue [EMAIL PROTECTED] wrote:


Hi Conal,

On 07/12/06, Conal Elliott [EMAIL PROTECTED] wrote:
 Hi Jeremy,

 Thanks for the detailed pointers about wxWidgets, GUIs, and
multi-threading.
  My use is actually very simple.  The only reason I wanted multiple
 (sequential, not concurrent) invocations of 'start' is for convenience
of
 use in ghci.

 I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that
this
 problem was worked around in 2.4.2 for use with ghci.  Is there really
no
 way to fix the situation with 2.6.3?

This is what Daan said (in passing, in the context of another message
about the new wxHaskell maintenance team):

Finally, I am not convinced that we should always use the latest
wxWidgets version: In particular, the 2.4.2 version is the only one
that lets you start and restart wxhaskell apps under GHCI under
window. The newer versions use static c++ classes and the destructors
are not called once the dll is loaded under GHCI (fixing this requires
fixing wxWidgets or letting GHCI reload DLL's too).

 Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
 including unicode issues?

I believe so (translation: I managed to get it to work on my PC under
WinXP). I understand that Unicode support in 2.4.2 is not so thorough
as for 2.6.3, although my Unicode requirements are minimal, so I
wouldn't expect to have seen any significant issues. Eric is working
on ways to test Unicode support more thoroughly. He's already
published one darcs patch.

In a couple of days (i.e. when it works...) I will be recompiling my
wx 2.4.2 based installation to test the new NMAKE makefile for wxc
(intention is to avoid the messy editing of Visual Studio project
files and create something easier to maintain). I'll let you know how
that goes.

 Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?

Yes, although it's not my primary platform by a long way.

Jeremy

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
wxhaskell-users mailing list
wxhaskell-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users