wxhaskell-devel — wxhaskell developers

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

[eric.kow <eri...@gm...>]

On Tue, Sep 20, 2011 at 20:57:37 +0100, Dave Tapley wrote:
> Am I correct in recalling that you did some of the work to get wxHaskell
> supporting unicode?

That's right.  Mostly swapping char with w_char

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

Ouch, seems to make sense.

Was dimly aware that wxWidgets 3.0 would be changing the string type but
I guess I let wishful thinking fool me into thinking it didn't affect
wxWidgets 2.9 (not really paying enough attention to the numbering)

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] I need help setting up

[Dave T. <duk...@gm...>]

On 20 September 2011 18:45, David Virebayre <dav...@gm...>wrote:

> 2011/9/18 D.V. <dav...@gm...>:
> > 2011/9/17 Dave Tapley <duk...@gm...>:
>
> Bonjour Dave, bonjour list !
>
> >> You'll need to edit wxcore/Setup.hs thus:
> > [...]
> >> Hopefully you can adjust this for your needs, and it would be great if
> you
> >> could send your list back so I can include it in my patch.
>
> > I will try that as soon as I can, which is, unfortunately, not today.
> > If that works, I will send the list back.
>
> Ok here's how I modified the list:
>
>  else [ "-lwx_gtk2u_richtext-2.8", "-lwx_gtk2u_aui-2.8"
>      , "-lwx_gtk2u_xrc-2.8", "-lstdc++" ]
>
> That and the new wiki page helped me go further, but I'm stuck on another
> error:
>
> src/haskell/Graphics/UI/WXCore.hs:25:11:
>    Conflicting exports for `wxEVT_FIRST':
>      `module Graphics.UI.WXCore.WxcClasses' exports
> `Graphics.UI.WXCore.WxcClasses.wxEVT_FIRST' imported from
> Graphics.UI.WXCore.WxcClasses at
> src/haskell/Graphics/UI/WXCore.hs:47:1-36
>
>                            (defined at
> src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:17134:1)
>      `module Graphics.UI.WXCore.WxcDefs' exports
> `Graphics.UI.WXCore.WxcDefs.wxEVT_FIRST' imported from
> Graphics.UI.WXCore.WxcDefs at
> src/haskell/Graphics/UI/WXCore.hs:46:1-33
>
>                      (defined at
> src/haskell/Graphics/UI/WXCore/WxcDefs.hs:2969:1)
>
> src/haskell/Graphics/UI/WXCore.hs:25:11:
>    Conflicting exports for `wxEVT_NULL':
>      `module Graphics.UI.WXCore.WxcClasses' exports
> `Graphics.UI.WXCore.WxcClasses.wxEVT_NULL' imported from
> Graphics.UI.WXCore.WxcClasses at
> src/haskell/Graphics/UI/WXCore.hs:47:1-36
>
>                           (defined at
> src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:17701:1)
>      `module Graphics.UI.WXCore.WxcDefs' exports
> `Graphics.UI.WXCore.WxcDefs.wxEVT_NULL' imported from
> Graphics.UI.WXCore.WxcDefs at
> src/haskell/Graphics/UI/WXCore.hs:46:1-33
>
>                     (defined at
> src/haskell/Graphics/UI/WXCore/WxcDefs.hs:2966:1)
>
> David.
>

Ah! Yes! I had error too, but I can't remember how I resolved it, which
makes me think I might have just cleaned everything up and started afresh
(just with the modified library list);  have you tried that?

Dave,

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

[Dave T. <duk...@gm...>]

Hi Eric,

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

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

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

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

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

Dave,

Re: [wxhaskell-devel] I need help setting up

[David V. <dav...@gm...>]

2011/9/18 D.V. <dav...@gm...>:
> 2011/9/17 Dave Tapley <duk...@gm...>:

Bonjour Dave, bonjour list !

>> You'll need to edit wxcore/Setup.hs thus:
> [...]
>> Hopefully you can adjust this for your needs, and it would be great if you
>> could send your list back so I can include it in my patch.

> I will try that as soon as I can, which is, unfortunately, not today.
> If that works, I will send the list back.

Ok here's how I modified the list:

 else [ "-lwx_gtk2u_richtext-2.8", "-lwx_gtk2u_aui-2.8"
      , "-lwx_gtk2u_xrc-2.8", "-lstdc++" ]

That and the new wiki page helped me go further, but I'm stuck on another error:

src/haskell/Graphics/UI/WXCore.hs:25:11:
    Conflicting exports for `wxEVT_FIRST':
      `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcClasses at
src/haskell/Graphics/UI/WXCore.hs:47:1-36

                            (defined at
src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:17134:1)
      `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_FIRST' imported from
Graphics.UI.WXCore.WxcDefs at
src/haskell/Graphics/UI/WXCore.hs:46:1-33

                      (defined at
src/haskell/Graphics/UI/WXCore/WxcDefs.hs:2969:1)

src/haskell/Graphics/UI/WXCore.hs:25:11:
    Conflicting exports for `wxEVT_NULL':
      `module Graphics.UI.WXCore.WxcClasses' exports
`Graphics.UI.WXCore.WxcClasses.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcClasses at
src/haskell/Graphics/UI/WXCore.hs:47:1-36

                           (defined at
src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:17701:1)
      `module Graphics.UI.WXCore.WxcDefs' exports
`Graphics.UI.WXCore.WxcDefs.wxEVT_NULL' imported from
Graphics.UI.WXCore.WxcDefs at
src/haskell/Graphics/UI/WXCore.hs:46:1-33

                     (defined at
src/haskell/Graphics/UI/WXCore/WxcDefs.hs:2966:1)

David.

[wxhaskell-devel] cabal-dev-install wxcore but not wx, and receive "Ambiguous occurrence" error

[Dave T. <duk...@gm...>]

Hi all, here's a curious problem:

I've found that if I already have issued (from a fresh darcs pull):
$ cabal-dev install ./wx ./wxcore ./wxdirect
I can compile (with "ghc -package-conf ..") and run some test code
successfully.

But then, if I do:
$ cabal-dev install ./wxcore
When I try to compile the same test code (still with "ghc -package-conf ..")
I get a bunch of "Ambiguous occurrence" errors[1].

Sure enough, you can:
$ cabal-dev install ./wx
And you'll see that the test code compile now works again.

As a workaround I now always use:
$ cabal-dev install ./wx ./wxcore

But I wondered if this points to an underlying problem, or if someone can
explain why it happens?

Dave,

[1] For example:
PropertyGrid.hs:35:29:
    Ambiguous occurrence `container'
    It could refer to either `Graphics.UI.WX.container',
                             imported from Graphics.UI.WX at
PropertyGrid.hs:6:1-21
                          or `Graphics.UI.WXCore.container',
                             imported from Graphics.UI.WXCore at
PropertyGrid.hs:7:1-25

PropertyGrid.hs:35:43:
    Ambiguous occurrence `margin'
    It could refer to either `Graphics.UI.WX.margin',
                             imported from Graphics.UI.WX at
PropertyGrid.hs:6:1-21
                          or `Graphics.UI.WXCore.margin',
                             imported from Graphics.UI.WXCore at
PropertyGrid.hs:7:1-25

PropertyGrid.hs:36:29:
    Ambiguous occurrence `column'
    It could refer to either `Graphics.UI.WX.column',
                             imported from Graphics.UI.WX at
PropertyGrid.hs:6:1-21
                          or `Graphics.UI.WXCore.column',
                             imported from Graphics.UI.WXCore at
PropertyGrid.hs:7:1-25

Re: [wxhaskell-devel] Compile time for wxcore

[Dave T. <duk...@gm...>]

On 16 September 2011 23:30, Dave Tapley <duk...@gm...> 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?

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.

Dave,


[1]
http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
[2] http://darcs.net/manual/Darcs_commands.html#SECTION006112100000000000000
[3] All files are under ./wxdirect/src/:
./CompileDefs.hs:
       writeFile outputFile (unlines (prologue ++ export ++ haskellDefs))
./CompileSTC.hs:
  writeFile h_target $ (glue "\n\n" $ map headerfunc f) ++ "\n"
./CompileSTC.hs:
  writeFile cpp_target $ (glue "\n" $ map cppfunc f) ++ "\n"
./CompileClasses.hs:
       writeFile (outputFile ++ ".hs") output
./CompileClasses.hs:
       writeFile (outputFile ++ ".hs") output
./CompileClassTypes.hs:
       writeFile outputFile output
./CompileHeader.hs:
       writeFile outputFile output
./ParseEiffel.hs:
       writeFile "../../wxh/Graphics/UI/WXH/WxcDefs.hs" (unlines
haskellDefs)
./CompileClassInfo.hs:
       writeFile outputFile (unlines (prologue ++ export ++ classDefs ++
downcDefs))

Re: [wxhaskell-devel] New wiki page

[Dave T. <duk...@gm...>]

On 15 September 2011 01:40, Dave Tapley <duk...@gm...> wrote:

> Hi all,
>
> Having been hacking around with wrapping new functionality in wxHaskell I
> decided to write a wiki page detailing my findings:
> http://haskell.org/haskellwiki/WxHaskell/Development/Environment
>
> Please feel free to edit/comment.
>

There was a fairly substantial error on this page, as a result of my
misunderstanding of cabal-dev
( see here:
http://stackoverflow.com/questions/7451296/using-the-reinstall-flag-with-cabal-dev)

So you might want to revisit the "Building and testing wxHaskell" section.

Dave,

Re: [wxhaskell-devel] I need help setting up

[D.V. <dav...@gm...>]

2011/9/17 Dave Tapley <duk...@gm...>:

Bonjour Dave, bonjour list !

> I see from this you're on wx 2.8 for GTK, and that's okay, we just need to
> remove those non-Linux libraries, and I'm afraid that involves some hacking
> (I'm working on a patch to clean this up, I need to get it to the list):

wx2.9 isn't available yet in kubuntu 11.04.

> You'll need to edit wxcore/Setup.hs thus:
[...]
> Hopefully you can adjust this for your needs, and it would be great if you
> could send your list back so I can include it in my patch.

I will try that as soon as I can, which is, unfortunately, not today.
If that works, I will send the list back.

> Hope this helps,

Well thanks a *lot* for giving me something to try, I hope it helps too.

David

Re: [wxhaskell-devel] I need help setting up

[Dave T. <duk...@gm...>]

On 16 September 2011 22:40, D.V. <dav...@gm...> wrote:

> Bonsoir List,
>
> I'm trying to follow the instructions from
> http://www.haskell.org/haskellwiki/WxHaskell/Development/Environment
> however it's not working.
>
> - cabal-dev add-source wxdirect  works fine
> - cabal-dev add-source wxcore    has an error
> - cabal-dev add-source wx        works fine
>
> wxcore error:
> [...]
> Configuring wxcore-0.13.1...
> setup: Missing dependencies on foreign libraries:
> * Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8, wx_baseu_xml-2.8,
> wx_gtk2u_core-2.8, wx_gtk2u_adv-2.8, wx_gtk2u_html-2.8, wx_gtk2u_qa-2.8,
> wx_gtk2u_xrc-2.8, wx_gtk2u_aui-2.8, wx_gtk2u_richtext-2.8
> This problem can usually be solved by installing the system packages that
> provide these libraries (you may need the "-dev" versions). If the
> libraries
> are already installed but in a non-standard location then you can use the
> flags --extra-include-dirs= and --extra-lib-dirs= to specify where they
> are.
> Building source dist for wxcore-0.13.1...
> Preprocessing library wxcore-0.13.1...
> Source tarball created: dist/wxcore-0.13.1.tar.gz
>
> I'm on kubuntu 11.04.
> I have a fresh ghc7.0.1 install.
> cabal install wx worked fine; I am able to compile and run wxHaskell
> programs.
>
> running with verbose=3 tells me a bunch of
> /usr/bin/gcc returned ExitFailure 1 with error message:
> /usr/bin/ld: cannot find -lwxmsw28ud_media
> /usr/bin/ld: cannot find -lwxmsw28ud_richtext
> /usr/bin/ld: cannot find -lwxmsw28ud_aui
> /usr/bin/ld: cannot find -lwxmsw28ud_xrc
>

Thanks for posting so much information, this is very similar to a problem I
had with the latest from code.haskell.org.
You'll note that those missing libraries contain "msw", i.e. "Microsoft
Windows", which us Linux users certainly shouldn't be trying to link
against.


collect2: ld returned 1 exit status
>
> a search on google brings a few pages, however I still can't figure
> out how to make it work.
>
> Here's what libraries I have that contain 'wx', I've no idea how to
> get the missing ones.
>
> $ find /usr -name '*wx*so'
> /usr/lib/libwxsvg.so
> /usr/lib/libwx_gtk2u_ogl-2.8.so
> /usr/lib/libwx_gtk2u_xrc-2.8.so
> /usr/lib/libwx_gtk2u_richtext-2.8.so
> /usr/lib/libwx_gtk2u_gizmos-2.8.so
> /usr/lib/libwx_gtk2u_fl-2.8.so
> /usr/lib/libwx_gtk2u_html-2.8.so
> /usr/lib/libwx_baseu_net-2.8.so
> /usr/lib/libwx_gtk2u_aui-2.8.so
> /usr/lib/libwx_gtk2u_stc-2.8.so
> /usr/lib/libwx_baseu_xml-2.8.so
> /usr/lib/libwx_gtk2u_core-2.8.so
> /usr/lib/libwx_gtk2u_gizmos_xrc-2.8.so
> /usr/lib/libwx_gtk2u_qa-2.8.so
> /usr/lib/libwx_gtk2u_adv-2.8.so
> /usr/lib/libwx_baseu-2.8.so
> /usr/lib/libwx_gtk2u_svg-2.8.so
> /usr/lib/libwx_gtk2u_gl-2.8.so
> /usr/lib/libwx_gtk2u_plot-2.8.so
>
> Please help !
>
> David.
>

I see from this you're on wx 2.8 for GTK, and that's okay, we just need to
remove those non-Linux libraries, and I'm afraid that involves some hacking
(I'm working on a patch to clean this up, I need to get it to the list):

You'll need to edit wxcore/Setup.hs thus:
On or around line 51 you'll see:

>  let extra_wx_libs = if ver == "9"
[BUNCH OF LIBRARY INCLUDES]

Now I use wx 2.9 for GTK, and I've replaced the include list with these:

>                        [ "-lwx_gtk2u_xrc-2.9", "-lwx_gtk2u_stc-2.9",
"-lwx_gtk2u_aui-2.9"
>                        , "-lwx_gtk2u_ribbon-2.9",
"-lwx_gtk2u_propgrid-2.9", "-lwx_gtk2u_richtext-2.9"
>                        , "-lwx_gtk2u_gl-2.9", "-lstdc++"]

Hopefully you can adjust this for your needs, and it would be great if you
could send your list back so I can include it in my patch.


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.

Hope this helps,
Dave


>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

[wxhaskell-devel] Compile time for wxcore

[Dave T. <duk...@gm...>]

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?

Dave,

[wxhaskell-devel] I need help setting up

[D.V. <dav...@gm...>]

Bonsoir List,

I'm trying to follow the instructions from
http://www.haskell.org/haskellwiki/WxHaskell/Development/Environment
however it's not working.

- cabal-dev add-source wxdirect  works fine
- cabal-dev add-source wxcore    has an error
- cabal-dev add-source wx        works fine

wxcore error:
[...]
Configuring wxcore-0.13.1...
setup: Missing dependencies on foreign libraries:
* Missing C libraries: wx_baseu-2.8, wx_baseu_net-2.8, wx_baseu_xml-2.8,
wx_gtk2u_core-2.8, wx_gtk2u_adv-2.8, wx_gtk2u_html-2.8, wx_gtk2u_qa-2.8,
wx_gtk2u_xrc-2.8, wx_gtk2u_aui-2.8, wx_gtk2u_richtext-2.8
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
Building source dist for wxcore-0.13.1...
Preprocessing library wxcore-0.13.1...
Source tarball created: dist/wxcore-0.13.1.tar.gz

I'm on kubuntu 11.04.
I have a fresh ghc7.0.1 install.
cabal install wx worked fine; I am able to compile and run wxHaskell programs.

running with verbose=3 tells me a bunch of
/usr/bin/gcc returned ExitFailure 1 with error message:
/usr/bin/ld: cannot find -lwxmsw28ud_media
/usr/bin/ld: cannot find -lwxmsw28ud_richtext
/usr/bin/ld: cannot find -lwxmsw28ud_aui
/usr/bin/ld: cannot find -lwxmsw28ud_xrc
collect2: ld returned 1 exit status

a search on google brings a few pages, however I still can't figure
out how to make it work.

Here's what libraries I have that contain 'wx', I've no idea how to
get the missing ones.

$ find /usr -name '*wx*so'
/usr/lib/libwxsvg.so
/usr/lib/libwx_gtk2u_ogl-2.8.so
/usr/lib/libwx_gtk2u_xrc-2.8.so
/usr/lib/libwx_gtk2u_richtext-2.8.so
/usr/lib/libwx_gtk2u_gizmos-2.8.so
/usr/lib/libwx_gtk2u_fl-2.8.so
/usr/lib/libwx_gtk2u_html-2.8.so
/usr/lib/libwx_baseu_net-2.8.so
/usr/lib/libwx_gtk2u_aui-2.8.so
/usr/lib/libwx_gtk2u_stc-2.8.so
/usr/lib/libwx_baseu_xml-2.8.so
/usr/lib/libwx_gtk2u_core-2.8.so
/usr/lib/libwx_gtk2u_gizmos_xrc-2.8.so
/usr/lib/libwx_gtk2u_qa-2.8.so
/usr/lib/libwx_gtk2u_adv-2.8.so
/usr/lib/libwx_baseu-2.8.so
/usr/lib/libwx_gtk2u_svg-2.8.so
/usr/lib/libwx_gtk2u_gl-2.8.so
/usr/lib/libwx_gtk2u_plot-2.8.so

Please help !

David.

[wxhaskell-devel] Modified example ImageViewer.hs

[D.V. <dav...@gm...>]

Bonjour List,

A few weeks ago I needed help to find out how to scale an image.
Once I managed to make it work, I was suggested to modify the example
to show how it can be done.

So here's a quickly modified ImageViewer.hs. It's not a big change !

I'd like someone to review the changes before I send a patch, please.

Thanks,

David.

[wxhaskell-devel] New wiki page

[Dave T. <duk...@gm...>]

Hi all,

Having been hacking around with wrapping new functionality in wxHaskell I
decided to write a wiki page detailing my findings:
http://haskell.org/haskellwiki/WxHaskell/Development/Environment

Please feel free to edit/comment.

Dave,

Re: [wxhaskell-devel] assert "m_dynamicEvents" failed in SearchDynamicEventTable()

[Eric Y. K. <eri...@gm...>]

On Thu, Sep 01, 2011 at 20:26:47 +0100, Dave Tapley wrote:
> I also so happen to be using a wxWidget-2.8 I compiled locally with debug
> on:
> $ wx-config --list
>     Default config is gtk2-unicode-debug-2.8
> 
> I've noticed when running some code I've inherited that I get this (debug
> only) assertion from wxWidgets:
> [Debug] 20:17:32: ./src/common/event.cpp(1397): assert "m_dynamicEvents"
> failed in SearchDynamicEventTable(): caller should check that we have
> dynamic events

OK, good (in the sense that you said something which seems new but
coherent with current facts/hypotheses about how the world fit
together).

Short answer:

You can make this go away by building wxWidgets without debug mode

Long answer:

See, the symptom I mostly experience is "using the stock wxWidgets
that comes with MacOS X results in annoying dialogue boxes" (and
with the message you pasted.  Do you get annoying dialogue boxes as
well?  It turns out that the Mac platform is irrelevant here. The
environment where we get this failure is a wxWidgets with debug mode
enabled, and that so happens to be what MacOS X ships with.

We tried just disabling this in the underlying C bits, but turned
out to be unwise because, well... you kind of need an event handler
to handle events. Back to the drawing board.

I don't really understand the issue at hand, but I know Jeremy has
done some more investigating...

http://wewantarock.wordpress.com/2011/06/17/how-does-wxhaskell-event-handling-work-part-1/

Me, I'm motivated to see the outcome of this so that (A) we have a
better idea what we're dealing with and (B) so that Mac users can
have wxHaskell "just work" :-)

Let us know how you get on!

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] WX eating stderr output

[Dave T. <duk...@gm...>]

On 1 September 2011 21:18, Dave Tapley <duk...@gm...> wrote:

> I don't know if this is a known issue which I've stumbled across using the
> Debug.Trace library:
> If you run this sample code¹ you'll see that six lines of output are
> generated.
> Now uncomment the WX import and try again, you should see only four lines
> of output.
>
> It appears anything written to stderr is being eaten up in any module which
> imports WX, which is fairly inconvenient.
> Can anyone think why this could be?
>
> Notably the Debug.Trace module states:
> "Usually the output stream is System.IO.stderr but if the function is
> called from Windows GUI application then the output will be directed to the
> Windows debug console".
> So I'd be interested to have a Windows user try this out.
>
>
>
> ¹ wx_stderr_test.hs:
> module Main where
>
> -- import Graphics.UI.WX
>
> import Debug.Trace
> import System.IO.Unsafe
>
> main :: IO ()
> main = do
>    print (trace "DEBUG_TRACE" "APPLE")
>    print (unsafePerformIO (putTraceMsg "UNSAFE_TRACE_MSG" >> return
> "BANANA"))
>    print (unsafePerformIO (putStrLn "UNSAFE_PUT_STR" >> return "CUCUMBER"))
>
>
Further to this I can reveal that it only occurs when wxWidgets is built
with --enable-debug, ironically.

[wxhaskell-devel] WX eating stderr output

[Dave T. <duk...@gm...>]

I don't know if this is a known issue which I've stumbled across using the
Debug.Trace library:
If you run this sample code¹ you'll see that six lines of output are
generated.
Now uncomment the WX import and try again, you should see only four lines of
output.

It appears anything written to stderr is being eaten up in any module which
imports WX, which is fairly inconvenient.
Can anyone think why this could be?

Notably the Debug.Trace module states:
"Usually the output stream is System.IO.stderr but if the function is called
from Windows GUI application then the output will be directed to the Windows
debug console".
So I'd be interested to have a Windows user try this out.



¹ wx_stderr_test.hs:
module Main where

-- import Graphics.UI.WX

import Debug.Trace
import System.IO.Unsafe

main :: IO ()
main = do
   print (trace "DEBUG_TRACE" "APPLE")
   print (unsafePerformIO (putTraceMsg "UNSAFE_TRACE_MSG" >> return
"BANANA"))
   print (unsafePerformIO (putStrLn "UNSAFE_PUT_STR" >> return "CUCUMBER"))

[wxhaskell-devel] assert "m_dynamicEvents" failed in SearchDynamicEventTable()

[Dave T. <duk...@gm...>]

Hi all,

First of all I'm using wxHaskell from hackage:
$ ghc-pkg list wx*
   wx-0.12.1.6
   wxcore-0.12.1.7
   wxdirect-0.12.1.4

I also so happen to be using a wxWidget-2.8 I compiled locally with debug
on:
$ wx-config --list
    Default config is gtk2-unicode-debug-2.8

I've noticed when running some code I've inherited that I get this (debug
only) assertion from wxWidgets:
[Debug] 20:17:32: ./src/common/event.cpp(1397): assert "m_dynamicEvents"
failed in SearchDynamicEventTable(): caller should check that we have
dynamic events

I see from the list archive that it has come up before, but I couldn't
really distil what happened; should I be worried about this?

Dave,

Re: [wxhaskell-devel] Fix for 3019730

[Eric Y. K. <eri...@gm...>]

On Sun, Aug 21, 2011 at 14:32:49 +0100, Jeremy O'Donoghue wrote:
> 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.

Done.

PS. I'll comment out the commit message posthook until we find a
replacement, if we really decide it's helpful. I think there's a
darcs-monitor package out there now, for example.

-- 
Eric Kow <http://erickow.com>

Re: [wxhaskell-devel] Fix for 3019730

[Jeremy O'D. <jer...@gm...>]

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" <eri...@gm...>
wrote:
> On Sat, Aug 13, 2011 at 16:01:27 +0100, mac...@gm... 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
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
> 
> Email had 1 attachment:
> + Attachment1.2
>   1k (application/pgp-signature)
-- 
  Jeremy O'Donoghue
  jer...@gm...

Re: [wxhaskell-devel] Fix for 3019730

[Eric Y. K. <eri...@gm...>]

On Sat, Aug 13, 2011 at 16:01:27 +0100, mac...@gm... 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>

[wxhaskell-devel] Fix for 3019730

[<mac...@gm...>]

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?

Thanks,
Maciek

[wxhaskell-devel] Fix for Windows build

[<mac...@gm...>]

Attached is my attempt to fix the Windows build. It should not have
any impact on the builds on other platforms.

The patch contains:
- Dave's fix to conflicting wxEVT definitions
- Eric's wx-config replacement
- my changes to WxConfig and wxcore Setup.hs

Any chance this can be applied to the official repo?

Regards,
Maciek

Re: [wxhaskell-devel] [wxhaskell-users] Haskell Platform roadmap?

[<mac...@gm...>]

I set up a BuildBot instance for wxHaskell darcs tip:
http://build.bimbr.com/wxhaskell/waterfall. At the moment it is
configured to run nightly, at 1 AM CET (numerous builds at other times
are a result of me testing the setup). The only slave I configured so
far is Windows with wxWidgets 2.8, but if anyone would like to
contribute a differently configured slave to build on, that would be
most welcome. Please let me know if you have a machine that is
regularly online at this time or if you are willing to configure an
EC2 AMI (I can host it).

As you can see, the Windows build currently fails due to unsupported
wx-config --version flag, which has been discussed on wxhaskell-devel
before. A reasonable next step seems to be to to actually fix the
Windows build, which I hope to have a stab at next weekend.

Also, this is the first time I had anything to do with BuildBot, so
any suggestions on how to improve the setup are welcome.

Maciek

On Wed, Jun 15, 2011 at 1:12 PM, Eric Kow <eri...@gm...> wrote:
> On Tue, Jun 14, 2011 at 23:36:37 +0100, Jeremy O'Donoghue wrote:
>>    - 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.
>
> So it sounds like what could be handy is to partially automate our way
> out of this with something like buildbot.  We would need somebody to
> manage the master, and also volunteers to provide always-on Mac, Linux
> and Windows machines to do the builds for us.
>
> You can get an idea of what buildbot would buy us at
>  http://buildbot.darcs.net/waterfall
>
> I'm a big fan of replacing scarce humans with robots wherever possible.
> ... but we do need somebody to help with said robots!
>
> --
> Eric Kow <http://erickow.com>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk34oZUACgkQBUrOwgisBPnl+wCeN4gLoWD9hlokzS/xugr7WpNS
> exAAoL3bzR5V7qBqjDt20u051oMC1bST
> =8jSq
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> 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-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-devel] Property sheet

[Jeremy O'D. <jer...@gm...>]

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 <duk...@gm...> wrote:

> On 29 July 2011 21:49, Dave Tapley <duk...@gm...> wrote:
>
>> Hi Jeremy,
>>
>> Did you ever make a start wrapping wxPropertyGrid?
>> http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1016
>>
>> I'm going to have a go now.
>>
>> Dave,
>>
>
> In my quest to understand how a class from wxWidgets is wrapped I took at
> look at wxSlider as it shares the same class hierarchy as wxPropertyGrid and
> 'slider' is a fairly distinct term.
>
> Searching for 'slider' in the wxHaskell code I extracted the following
> references to it.
> Does this look complete? If anyone could comment further on what function
> each part provides I'd be very grateful.
>
>
> # HAND-WRITTEN FILES #
>
> ./wx/src/Graphics/UI/WX/Controls.hs:
> Haskell impl
>

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

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

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


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

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


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

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

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

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


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

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


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

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


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

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


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

Correct.


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

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

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

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

# MISC FILES #
>
> ./wxcore/wxcore.cabal:
>     add src/cpp/eljslider.cpp to c-sources
>

Obvious...

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

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

# GENERATED FILES #
>
> ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs:
> File generated by wxDirect from ./wxcore/src/include/wxc.h:
> Export of (wxEVT_COMMAND_SLIDER_UPDATED :: EventId)
> Export of many slider functions such as sliderClearSel, these match the
> wxSlider_ methods decl'd in wxc_glue.h
> Export of xmlResourceGetSlider function decl'd in wxc_glue.h
> Definition for slider functions using FFI foreign import ccall
> Definition of wxEVT_COMMAND_SLIDER_UPDATED which imports the enum value
> Definition of xmlResourceGetSlider using FFI foreign import ccall
>
> ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs:
> File generated by wxDirect
> Export of classSlider, classSlider95, classSliderMSW
> Export of downcastSlider, downcastSlider95, downcastSliderMSW
> Definition classSlider functions which bind them to the their C++ class
> names using a classInfoFindClass function
> Definition of downcast functions using an objectCast function
>
> ./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs:
> File generated by wxDirect from ./wxcore/src/include/wxc.h:
> Exports Slider, TSlider, CSlider, and 95 and MSW variants
> Definitions of these as data types, encapsulating the class hierarchy from
> C++ classes. TSlider is the inheritance type, CSlider is the abstract type.
>

All correct.

Hope this helps.

Jeremy

Re: [wxhaskell-devel] Property sheet

[Dave T. <duk...@gm...>]

On 29 July 2011 21:49, Dave Tapley <duk...@gm...> wrote:

> Hi Jeremy,
>
> Did you ever make a start wrapping wxPropertyGrid?
> http://permalink.gmane.org/gmane.comp.lang.haskell.wxhaskell.general/1016
>
> I'm going to have a go now.
>
> Dave,
>

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

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


# HAND-WRITTEN FILES #

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

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

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

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

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

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

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

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

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

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

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


# MISC FILES #

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

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


# GENERATED FILES #

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

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

./wxcore/src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs:
File generated by wxDirect from ./wxcore/src/include/wxc.h:
Exports Slider, TSlider, CSlider, and 95 and MSW variants
Definitions of these as data types, encapsulating the class hierarchy from
C++ classes. TSlider is the inheritance type, CSlider is the abstract type.