wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

[Henning T. <le...@he...>]

On Sun, 30 Sep 2012, mac...@gm... wrote:

> I have now updated the module to use event-based notifications instead
> of polling: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs.
> The original question still stands: is it worth exposing this sort of
> abstraction as a part of wxHaskell?


Since no other one seems to answer ... I would like to see this 
functionality in a package, either a separate package or integrated in wx. 
In any case I think that the wx/wxcore package bundle must contain a 
function for providing us with free(!) event ids. This cannot be done 
reliably in a third party package.

Re: [wxhaskell-users] WxHaskell on Debian Wheezy with wxWidgets 2.9.4

[Kaan S. <kaa...@gm...>]

Mads Lindstrøm <mads.lindstroem@...> writes:

> 
> 
> HiI think I fixed the problem. In wxc/src/cpp/eljpen.cpp line 159 I 
changed:    * _ref = NULL;
> To:    _ref = NULL;
> After that wxHaskell compiled just fine. I tried a test-program and that also 
worked just fine.Kind regards,Mads 
> 
> 



Hello Mads,
thank you so much for fixing this. I tried to install wxwidget some months 
before and failed on that step... .

Kaan

Re: [wxhaskell-users] WxHaskell on Debian Wheezy with wxWidgets 2.9.4

[Mads L. <mad...@gm...>]

Hi

I think I fixed the problem. In wxc/src/cpp/eljpen.cpp line 159 I changed:

    * _ref = NULL;

To:

    _ref = NULL;

After that wxHaskell compiled just fine. I tried a test-program and that
also worked just fine.


Kind regards,

Mads Lindstrøm


2012/12/2 Mads Lindstrøm <mad...@gm...>

> Hi
>
> I am trying to install wxHaskell 0.90.0.1 on Debian Wheezy.
>
> First, I installed wxWidgets 2.9.4:
>
> ./configure --enable-mediactrl
> make
> make install
>
> Then:
>
> cabal install wx
>
> Which results in the following failure:
>
> /usr/bin/gcc -Wl,--hash-size=31 -Wl,--reduce-memory-overheads
> -Isrc/include -I/usr/local/include/wx-2.9
> -I/usr/local/lib/wx/include/gtk3-unicode-2.9 -D__WXGTK__ -DWXUSINGDLL
> -D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC -c src/cpp/eljpen.cpp -o
> dist/build/src/cpp/eljpen.o
> src/cpp/eljpen.cpp: In function ‘void wxPen_GetStipple(void*, wxBitmap*)’:
> src/cpp/eljpen.cpp:159:13: error: conversion from ‘long int’ to ‘const
> wxBitmap’ is ambiguous
> src/cpp/eljpen.cpp:159:13: note: candidates are:
> In file included from /usr/local/include/wx-2.9/wx/bitmap.h:251:0,
>                  from /usr/local/include/wx-2.9/wx/generic/panelg.h:15,
>                  from /usr/local/include/wx-2.9/wx/panel.h:70,
>                  from /usr/local/include/wx-2.9/wx/wx.h:41,
>                  from src/include/wrapper.h:20,
>                  from src/cpp/eljpen.cpp:1:
> /usr/local/include/wx-2.9/wx/gtk/bitmap.h:83:5: note:
> wxBitmap::wxBitmap(GdkPixbuf*)
> /usr/local/include/wx-2.9/wx/gtk/bitmap.h:73:5: note:
> wxBitmap::wxBitmap(const char* const*)
> /usr/local/include/wx-2.9/wx/gtk/bitmap.h:64:24: error:   initializing
> argument 1 of ‘wxBitmap& wxBitmap::operator=(const wxBitmap&)’
> cabal: Error: some packages failed to install:
> wx-0.90.0.1 depends on wxc-0.90.0.4 which failed to install.
> wxc-0.90.0.4 failed during the building phase. The exception was:
> ExitFailure 1
> wxcore-0.90.0.3 depends on wxc-0.90.0.4 which failed to install.
>
>
> Any suggestions to how I can fix this?
>
>
> Greetings,
>
> Mads Lindstrøm
>
>

[wxhaskell-users] WxHaskell on Debian Wheezy with wxWidgets 2.9.4

[Mads L. <mad...@gm...>]

Hi

I am trying to install wxHaskell 0.90.0.1 on Debian Wheezy.

First, I installed wxWidgets 2.9.4:

./configure --enable-mediactrl
make
make install

Then:

cabal install wx

Which results in the following failure:

/usr/bin/gcc -Wl,--hash-size=31 -Wl,--reduce-memory-overheads -Isrc/include
-I/usr/local/include/wx-2.9 -I/usr/local/lib/wx/include/gtk3-unicode-2.9
-D__WXGTK__ -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -DwxcREFUSE_MEDIACTRL -fPIC
-c src/cpp/eljpen.cpp -o dist/build/src/cpp/eljpen.o
src/cpp/eljpen.cpp: In function ‘void wxPen_GetStipple(void*, wxBitmap*)’:
src/cpp/eljpen.cpp:159:13: error: conversion from ‘long int’ to ‘const
wxBitmap’ is ambiguous
src/cpp/eljpen.cpp:159:13: note: candidates are:
In file included from /usr/local/include/wx-2.9/wx/bitmap.h:251:0,
                 from /usr/local/include/wx-2.9/wx/generic/panelg.h:15,
                 from /usr/local/include/wx-2.9/wx/panel.h:70,
                 from /usr/local/include/wx-2.9/wx/wx.h:41,
                 from src/include/wrapper.h:20,
                 from src/cpp/eljpen.cpp:1:
/usr/local/include/wx-2.9/wx/gtk/bitmap.h:83:5: note:
wxBitmap::wxBitmap(GdkPixbuf*)
/usr/local/include/wx-2.9/wx/gtk/bitmap.h:73:5: note:
wxBitmap::wxBitmap(const char* const*)
/usr/local/include/wx-2.9/wx/gtk/bitmap.h:64:24: error:   initializing
argument 1 of ‘wxBitmap& wxBitmap::operator=(const wxBitmap&)’
cabal: Error: some packages failed to install:
wx-0.90.0.1 depends on wxc-0.90.0.4 which failed to install.
wxc-0.90.0.4 failed during the building phase. The exception was:
ExitFailure 1
wxcore-0.90.0.3 depends on wxc-0.90.0.4 which failed to install.


Any suggestions to how I can fix this?


Greetings,

Mads Lindstrøm

Re: [wxhaskell-users] monospace font in TextCtrl

[Henning T. <le...@he...>]

On Sat, 29 Sep 2012, Heinrich Apfelmus wrote:

> Henning Thielemann wrote:
>
>> It may be related to my observation that the textCtrl sometimes chooses a
>> variable-space font if I enter text at the end of a text Ctrl in an
>> otherwise mono-spaced text. That is, it seems to be important _how_ a text
>> is inserted.
>>
>> Maybe this is even a Wx bug?
>
> Most likely.
>
> It seems that in order to support monospace font, the text entry control
> is converted to Rich Text Formatting, and then you have font control
> commands as part of the input data.

I have added a 'case' that chooses the old code for GTK and apfelmus' one 
for other systems:
    http://code.haskell.org/~thielema/wxhaskell/

Can someone check my change on Windows and eventually add the patch to the 
main repo? Shall this patch be added to the wxwidgets-2.9 branch, too?

Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

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

I have now updated the module to use event-based notifications instead
of polling: https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs.
The original question still stands: is it worth exposing this sort of
abstraction as a part of wxHaskell?

Regards,
Maciek

On Wed, Sep 26, 2012 at 9:43 PM,  <mac...@gm...> wrote:
> Thanks for this, and for responding to the SO question. I'll see if I
> can rewrite the run async abstraction using your solution.
>
> Cheers,
> Maciek
>
> On Wed, Sep 26, 2012 at 8:30 AM, Henning Thielemann
> <le...@he...> wrote:
>>
>> On Wed, 26 Sep 2012, Henning Thielemann wrote:
>>
>>> However, it seems to be essential what eventId you use. The value in the
>>> above example (wxID_HIGHEST+1) was already used in my system and this lead
>>> to strange behavior. I think wxhaskell should provide support for finding
>>> free event ids.
>>
>>
>>
>> If you want to see this technique in action:
>>    http://code.haskell.org/alsa/gui/src/controller.hs
>>    http://code.haskell.org/alsa/gui/src/Common.hs
>>
>> I have implemented both the busy wait (reactOnEventTimer) and the
>> event-driven method (reactOnEvent).

Re: [wxhaskell-users] monospace font in TextCtrl

[Heinrich A. <apf...@qu...>]

Henning Thielemann wrote:
> Heinrich Apfelmus wrote:
> 
>> You can use the  textCtrlEx  function and pass additional style flags to
>> it to create text controls with the old behavior. I think the previous
>> source code was
>>
>>   textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props
> 
> I see. It sounds reasonable, too. Unfortunately switching back to this 
> line does not work. Even if it would, it would bypass the improvement that 
> was introduced with the last patch.

The idea would be to keep the source as it is, but use the  textCtrlEx 
function instead of the ordinary  textCtrl  function in the cases where 
you desire a text entry field with a monospace font.

> There were not many lines that changed, so I tried to revert them one by 
> one and found that this change caused the problem:
> 
> -            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; textCtrlWriteText tc s)) $
> +            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlChangeValue tc s)) $

I made this change because the old version actually crashes on MacOS X 
in some circumstances...

> It may be related to my observation that the textCtrl sometimes chooses a 
> variable-space font if I enter text at the end of a text Ctrl in an 
> otherwise mono-spaced text. That is, it seems to be important _how_ a text 
> is inserted.
> 
> Maybe this is even a Wx bug?

Most likely.

It seems that in order to support monospace font, the text entry control 
is converted to Rich Text Formatting, and then you have font control 
commands as part of the input data.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

[wxhaskell-users] Wxhaskell install woes on reddit

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

Thought folks here might be interested
http://www.reddit.com/r/haskell/comments/10lyaw/oh_the_fun_of_trying_to_install_wxhaskell/


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

Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

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

Thanks for this, and for responding to the SO question. I'll see if I
can rewrite the run async abstraction using your solution.

Cheers,
Maciek

On Wed, Sep 26, 2012 at 8:30 AM, Henning Thielemann
<le...@he...> wrote:
>
> On Wed, 26 Sep 2012, Henning Thielemann wrote:
>
>> However, it seems to be essential what eventId you use. The value in the
>> above example (wxID_HIGHEST+1) was already used in my system and this lead
>> to strange behavior. I think wxhaskell should provide support for finding
>> free event ids.
>
>
>
> If you want to see this technique in action:
>    http://code.haskell.org/alsa/gui/src/controller.hs
>    http://code.haskell.org/alsa/gui/src/Common.hs
>
> I have implemented both the busy wait (reactOnEventTimer) and the
> event-driven method (reactOnEvent).

Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

[Henning T. <le...@he...>]

On Wed, 26 Sep 2012, Henning Thielemann wrote:

> However, it seems to be essential what eventId you use. The value in the
> above example (wxID_HIGHEST+1) was already used in my system and this lead
> to strange behavior. I think wxhaskell should provide support for finding
> free event ids.


If you want to see this technique in action:
    http://code.haskell.org/alsa/gui/src/controller.hs
    http://code.haskell.org/alsa/gui/src/Common.hs

I have implemented both the busy wait (reactOnEventTimer) and the 
event-driven method (reactOnEvent).

Re: [wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

[Henning T. <le...@he...>]

On Wed, 26 Sep 2012, mac...@gm... wrote:

> Including wxhaskell-users. Anyone interested in async UI update functionality?

Am I right that the solution on StackOverflow uses a busy-wait using the 
Wx Timer? I think this is a bad idea and I found a better solution at:
    http://snipplr.com/view/17538/

However, it seems to be essential what eventId you use. The value in the 
above example (wxID_HIGHEST+1) was already used in my system and this lead 
to strange behavior. I think wxhaskell should provide support for finding 
free event ids.

[wxhaskell-users] Fwd: UI updates from non-UI threads: an addition to wx?

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

Including wxhaskell-users. Anyone interested in async UI update functionality?

Cheers,
Maciek

---------- Forwarded message ----------
From:  <mac...@gm...>
Date: Fri, Aug 24, 2012 at 10:41 PM
Subject: UI updates from non-UI threads: an addition to wx?
To: wxhaskell-devel <wxh...@li...>


Getting wxHaskell to handle UI updates from non-UI threads was a
frustrating experience; it's embarassing how long it took me to
realise that the solution presented in this StackOverflow answer:
http://stackoverflow.com/a/3182588/424978 is probably the only viable
one. I've packaged it into a tiny module that provides Gtk2hs-style
`postGUIAsync` function:
https://github.com/mmakowski/habaz/blob/master/src/Graphics/UI/WX/Async.hs.
Is there any interest in incorporating this into wxHaskell proper? It
might save other users some head scratching.

Regards,
Maciek

Re: [wxhaskell-users] monospace font in TextCtrl

[Henning T. <le...@he...>]

On Tue, 25 Sep 2012, Heinrich Apfelmus wrote:

> Henning Thielemann wrote:
>> When switching from wxcore-0.13.2 to GIT HEAD from
>> https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a
>> monospaced font. This may be caused by the recent patch commented with
>>
>>    "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent
>> of patch f225d0c on master."
>>
>> I create the text field this way:
>>     WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ]
>>
>> In the past TextCtrl always used a monospaced font, but when I entered
>> text at the end of a text field it happened sometimes that the font had no
>> longer fixed width characters. This might be a wxwidgets bug or even a gtk
>> bug. However, now the TextCtrl does not use the monospace font anymore.
>
> You can use the  textCtrlEx  function and pass additional style flags to
> it to create text controls with the old behavior. I think the previous
> source code was
>
>   textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props

I see. It sounds reasonable, too. Unfortunately switching back to this 
line does not work. Even if it would, it would bypass the improvement that 
was introduced with the last patch.

There were not many lines that changed, so I tried to revert them one by 
one and found that this change caused the problem:

-            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlClear tc; textCtrlWriteText tc s)) $
+            (\tc -> (textCtrlGetValue tc, \s -> do textCtrlChangeValue tc s)) $


It may be related to my observation that the textCtrl sometimes chooses a 
variable-space font if I enter text at the end of a text Ctrl in an 
otherwise mono-spaced text. That is, it seems to be important _how_ a text 
is inserted.

Maybe this is even a Wx bug?

[wxhaskell-users] type safe handling of flags

[Henning T. <le...@he...>]

I don't know whether I proposed it already ...

I wrote a package called enumset. It provides low-level bitsets like they 
are used by wxWidget. The definition is essentially:

newtype EnumSet storage index = EnumSet storage

E.g. with

data Style = Bold | Italic | Underlined  deriving (Enum)

the type (EnumSet Word32 Style) represents a subset of {Bold, Italic, 
Underlined} stored as a bitfield in a Word32.

http://hackage.haskell.org/packages/archive/enumset/0.0.4/doc/html/Data-EnumSet.html


The other modules can be used to manage bitfields where not individual 
bits must be processed, but there are groups of bits, where each group 
represents a value.

Re: [wxhaskell-users] monospace in TextCtrl

[Heinrich A. <apf...@qu...>]

Henning Thielemann wrote:
> When switching from wxcore-0.13.2 to GIT HEAD from 
> https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a
> monospaced font. This may be caused by the recent patch commented with
> 
>    "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent 
> of patch f225d0c on master."
> 
> I create the text field this way:
>     WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ]
> 
> In the past TextCtrl always used a monospaced font, but when I entered 
> text at the end of a text field it happened sometimes that the font had no 
> longer fixed width characters. This might be a wxwidgets bug or even a gtk 
> bug. However, now the TextCtrl does not use the monospace font anymore.

You can use the  textCtrlEx  function and pass additional style flags to 
it to create text controls with the old behavior. I think the previous 
source code was

   textCtrlEx parent (wxTE_MULTILINE .+. wxTE_RICH2) props


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

[wxhaskell-users] monospace in TextCtrl

[Henning T. <le...@he...>]

When switching from wxcore-0.13.2 to GIT HEAD from 
https://github.com/jodonoghue/wxHaskell the TextCtrl does no longer use a
monospaced font. This may be caused by the recent patch commented with

   "Fix for unexpected TextCtrl behaviour on OS X. This is the equivalent 
of patch f225d0c on master."

I create the text field this way:
    WX.textCtrl panel [ font := fontFixed, wrap := WrapNone ]

In the past TextCtrl always used a monospaced font, but when I entered 
text at the end of a text field it happened sometimes that the font had no 
longer fixed width characters. This might be a wxwidgets bug or even a gtk 
bug. However, now the TextCtrl does not use the monospace font anymore.

Re: [wxhaskell-users] Reducing linking and startup times (on Windows 7)

[Simon P. N. <si...@mi...>]

OK, I now have a fix for this craziness:

http://forums.wxwidgets.org/viewtopic.php?f=19&t=35542&start=30#p145812

For those just starting out, it would be best to grab TDM's
tdm-gcc-4.6.1 compiler here:

http://tdm-gcc.tdragon.net/download

You'll want a development MinGW distro that's compatible with the
Haskell platform's included GCC 4.5.2 version.

Hack your WxWidgets include\wx\dlimpexp.h file, line 37, resulting in:

# elif defined(__GNUC__)
/*
__declspec could be used here too but let's use the native
__attribute__ instead for clarity.
*/
# define WXEXPORT __attribute__((dllexport))
# define WXIMPORT __attribute__((dllimport))
# endif

and build WxWidgets with:

CPPFLAGS="-fno-keep-inline-dllexport"
SHARED=1
BUILD=release

You'll get quick starting, lower memory use Haskell binaries, after
your WxHaskell install from cabal.

Unregister any previous versions where needed:

ghc-pkg unregister wx
ghc-pkg unregister wxcore
ghc-pkg unregister wxc
ghc-pkg unregister wxdirect

Install based on fresh WxWidgets build:

cabal install wxdirect wxc wxcore wx

Compile HelloWorld, run, then break for pizza and beer!

On Sat, Jul 28, 2012 at 8:28 PM, Simon Peter Nicholls
<si...@mi...> wrote:
> I'm seeing the slow startup issue for the c++ sample apps anyway, so I
> think the issue is in the base wxwidgets 2.9(.4) gcc build. No
> problems with Linux 2.9 or Windows wxPack 2.8.12.

[wxhaskell-users] BitmapButton as default button

[Henk-Jan v. T. <hj...@ch...>]

L.S.,

I am trying to make a bitmap button the default button, but using the  
function defaultButton results in an error message ('ok' is a  
BitmapButton):
     Couldn't match expected type `()'
                 with actual type `WXCore.CBitmapButton ()'
     Expected type: Button ()
       Actual type: BitmapButton ()
     In the second argument of `(:=)', namely `ok'
     In the expression: defaultButton := ok

Isn't BitmapButton supposed to inherit from Button?

I used the following as a workaround:
    unsafeDefaultItem := objectCast ok

Regards,
Henk-Jan van Tuyl


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

Re: [wxhaskell-users] Reducing linking and startup times (on Windows 7)

[Simon P. N. <si...@mi...>]

I'm seeing the slow startup issue for the c++ sample apps anyway, so I
think the issue is in the base wxwidgets 2.9(.4) gcc build. No
problems with Linux 2.9 or Windows wxPack 2.8.12.

Re: [wxhaskell-users] Problems getting wxcore installed

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

I'll try compiling Windows from Hackage this weekend.

Best regards
Jeremy

Sent from my Windows Phone
From: Henk-Jan van Tuyl
Sent: 06/07/2012 10:16
To: wxh...@li...
Subject: [wxhaskell-users] Problems getting wxcore installed

L.S.,

Did anyone get wxHaskell compiled on Windows?

I am having several problems getting it compiled;
  - The wxcore setup calls wxdirect without quotes around the filepaths,
these filepaths contain spaces and therefore wxdirect uses only the first
part of the filepath. I patched wxcore to solve this.

  - The header files are not parsed correctly, I get, amongst others, the
following messages (still trying to install wxcore):

parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc.h
parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc_gen.h
ignore: parse error : "C:\Program
Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h" (line 1, column 1):
unexpected '/'
expecting function declaration or end of input, on : //int
expEVT_DIALUP_CONNECTED();
ignore: parse error : "C:\Program
Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h" (line 1, column 1):
unexpected '/'
expecting function declaration or end of input, on : //int
expEVT_DIALUP_DISCONNECTED();
generating: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1/WxcClassesAL.hs

The parser seems unable to handle lines that are commented out with two
slashes. Note, that these lines are not in wxc.h and do not have line
number 1, in file stc_gen.h, line numbers 78 and 79.

  - I have deleted the contents of these lines and tried again to install
wxcore; the message now generated is:
src\haskell\Graphics\UI\WXCore\WxcClassTypes.hs:1:1:
     File name does not match module name:
     Saw: `Main'
     Expected: `Graphics.UI.WXCore.WxcClassTypes'

The text is a bit cryptic, as file WxcClassTypes.hs is empty.

Does anybody know how to solve this?

Some version info:
Windows XP
Haskell Platform 2012.2.0.0
wxdirect-0.90.0.1
wxcore-0.90.0.3
wxc-0.90.0.4
wxWidgets-2.9.3

Regards,
Henk-Jan van Tuyl


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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
wxhaskell-users mailing list
wxh...@li...
https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Problems getting wxcore installed

[Henk-Jan v. T. <hj...@ch...>]

L.S.,

Did anyone get wxHaskell compiled on Windows?

I am having several problems getting it compiled;
  - The wxcore setup calls wxdirect without quotes around the filepaths,  
these filepaths contain spaces and therefore wxdirect uses only the first  
part of the filepath. I patched wxcore to solve this.

  - The header files are not parsed correctly, I get, amongst others, the  
following messages (still trying to install wxcore):

parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc.h
parsing: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/stc_gen.h
ignore: parse error : "C:\Program  
Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h" (line 1, column 1):
unexpected '/'
expecting function declaration or end of input, on : //int  
expEVT_DIALUP_CONNECTED();
ignore: parse error : "C:\Program  
Files\Haskell\wxc-0.90.0.4\ghc-7.4.1\include/wxc.h" (line 1, column 1):
unexpected '/'
expecting function declaration or end of input, on : //int  
expEVT_DIALUP_DISCONNECTED();
generating: C:\Program Files\Haskell\wxc-0.90.0.4\ghc-7.4.1/WxcClassesAL.hs

The parser seems unable to handle lines that are commented out with two  
slashes. Note, that these lines are not in wxc.h and do not have line  
number 1, in file stc_gen.h, line numbers 78 and 79.

  - I have deleted the contents of these lines and tried again to install  
wxcore; the message now generated is:
src\haskell\Graphics\UI\WXCore\WxcClassTypes.hs:1:1:
     File name does not match module name:
     Saw: `Main'
     Expected: `Graphics.UI.WXCore.WxcClassTypes'

The text is a bit cryptic, as file WxcClassTypes.hs is empty.

Does anybody know how to solve this?

Some version info:
Windows XP
Haskell Platform 2012.2.0.0
wxdirect-0.90.0.1
wxcore-0.90.0.3
wxc-0.90.0.4
wxWidgets-2.9.3

Regards,
Henk-Jan van Tuyl


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

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

[Henry L. <hen...@nt...>]

On 4 Jul 2012, at 11:42, Jeremy O'Donoghue wrote:

> I have been very busy on the day job, and far less responsive than I would have wished.
I've been there..

> If it's OK with you Henry, I'll copy the instructions you used to the wxHaskell wiki page.

Yes of course, no problem.

Regards/ Henry

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

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

Hi all,

Many thanks Henry for putting this together, and on debugging quite a
number of issues. I have been very busy on the day job, and far less
responsive than I would have wished.

On 3 July 2012 02:31, Henry Lockyer <hen...@nt...> wrote:

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

I have uploaded the working code for wxc and wxcore from Github to Hackage.
This means that you should now be able to cabal install all of the
wxHaskell components.

Many apologies for the undue delay in getting this done.

If it's OK with you Henry, I'll copy the instructions you used to the
wxHaskell wiki page.

Best regards
Jeremy

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

[Henry L. <hen...@nt...>]

Glad it hit the spot..  Rgds/ Henry 
 
On 3 Jul 2012, at 17:47, Conal Elliott wrote:

> Worked for me. Thanks very much, Henry!  -- Conal
> 
> On Mon, Jul 2, 2012 at 6:31 PM, Henry Lockyer <hen...@nt...> wrote:
> 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'  (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 following configure parameters are based on http://www.haskell.org/haskellwiki/Mac_OS_X_Common_Installation_Paths
> but with an amendment to docdir to bring it in line with my local cabal config.
> 
> 
> $ runhaskell Setup configure --user --prefix=/Users/<YOURSELF>/Library/Haskell/ghc-7.0.4/lib/wxc-0.90.0.4 --libsubdir= --datasubdir= --docdir=/Users/<YOURSELF>/Library/Haskell/ghc-7.0.4/lib/wxc-0.90.0.4/doc
> +
> $ runhaskell configure build
> +
> $ runhaskell configure install
> 
> wxcore
> --------
> 
> $ runhaskell Setup configure --user --prefix=/Users/<YOURSELF>/Library/Haskell/ghc-7.0.4/lib/wxcore-0.90.0.3 --libsubdir= --datasubdir= --docdir=/Users/<YOURSELF>/Library/Haskell/ghc-7.0.4/lib/wxcore-0.90.0.3/doc
> +
> $ runhaskell configure build
> +
> $ runhaskell configure install
> 
> 
> checks
> --------
> Build wxcore "HelloWorld.hs" from https://github.com/kowey/debug-wx
> Wrap it with the macosx-app command.
> Enjoy.
> 
> Note: It may start with the window positioned out of sight below left hand corner of the screen, don't miss it!
> 
> wx
> ---
> This should have been a simple "cabal install wx" but for some strange reason I got:
> 
>               src/Graphics/UI/WX/Draw.hs:33:8:
>                     Could not find module `Graphics.UI.WXCore':
>                           Perhaps you haven't installed the profiling libraries for package `wxcore-0.90.0.3'?
>                           Use -v to see a list of the files searched for.
>               cabal: Error: some packages failed to install:
>               wx-0.90.0.1 failed during the building phase. The exception was:
>               ExitFailure 1
> 
> 
> $ cabal install wx --disable-library-profiling
> 
> ...seems to solve it.
> 
> checks
> --------
> Build wx "HelloWorld.hs" from https://github.com/kowey/debug-wx
> 
> 
> Final Caveat
> =========
> I have so far only compiled and run simple 'helloworld' type programs using wxcore and wx, so not more widely tested yet.
> 
> 
> YMMV/ Henry
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] wxHaskell + OpenGL demos?

[Conal E. <co...@co...>]

By following Henry Lockyer's directions, I was able to get wxHaskell going
on Mac OS X (10.6.8). Now I want to see whether OpenGL works with it. Are
there any demos of wxHaskell + OpenGL?

-- Conal