wxhaskell-devel — wxhaskell developers

[wxhaskell-devel] Weird implementation of wxTreeCtrl_GetBoundingRect

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

Does anyone know why wxTreeCtrl_GetBoundingRect is implemented [1] such that:
1. It returns a null pointer on non-Windows platforms.
2. It disregards the returned value and returns GetRect().

It came in with: "wxhaskell-from-cvs @ 2004-09-14 10:27:48 by dleijen".

Dave,

[1] http://darcsden.com/DukeDave/wxhaskell-dev/wxc/cpp/treectrl.cpp#L-535

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

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

On 9 January 2012 22:19, Jeremy O'Donoghue <jer...@gm...>wrote:

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

Yikes, these flags are very (imho) counter-intuitive.

Referencing a thread I have going:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/JYd4ydh6v-IJ
Vadim states that: "DEBUG_FLAG is correctly set to 1 indicating that debug
code is not disabled (which is the default)".
So I'm substituting  "not disable" with "enabled" and reading it as: a
release build with debugging enabled, or as you put it:

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

What I'm not sure about here is whether the "BUILD" flag is superfluous
under any GCC build, or just non-Windows GCC builds. A question which I'm
asking about here:
https://groups.google.com/d/msg/wx-dev/4PuKS-xQX3k/nfUuz_cg-HUJ

If the answer to my question there is "under Windows using MSVC", and if we
accept that wxHaskell isn't going to support an MSVC build of wxWidgets
(which I get the impression is the case); then I suppose that wxC can be
completely agnostic to all the (non-libs) wxWidgets build type information
(namely: release/debug, debugging flag on/off).

Thoughts?


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

Hazaa, I'm going to say it again:
*wxHaskell doesn't support an MSVC build of wxWidgets*

Is that the sort of message we can put out?


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

I did actually miss another 'pro' here:
I think it's fair to say that wx-config-win is more 'complete' than Eric's
Haskell implementation, insomuch as all that's required to fix the
"wx-config roadblock" is (I think) changing this line as per Vadim's
suggestion :
http://code.google.com/p/wx-config-win/source/browse/trunk/wx-config-win.cpp#952


>
>
>>
>> And now the cons:
>> * It is woefully out of date. There are 18 open issues (
>> http://code.google.com/p/wx-config-win/issues/list) and who knows how
>> many undiscovered bugs.
>> * As mentioned, the wxWidgets community doesn't seem desperately fussed
>> about its existence, so long as Visual Studio is around
>> * It's implementation is in need of an overhaul, as identified by the
>> previous owner (http://code.google.com/p/wx-config-win/issues/detail?id=6
>> )
>>
>
> I tend to think that you've hit on the problem with this approach. The
> wxWidgets community doesn't really care. Therefore we would be left
> maintaining a piece of C++ to support what is basically our own need.
>
>>
>> So, in summary, I'm not sure.
>> My optimist, open-source heart says we should resurrect the wx-win-config
>> project.
>> My do-it-the-right-way heart says we ditch the existing C++ source and
>> replicate the shell script (Windows PowerShell anyone?)
>> My everything-is-wonderful-with-Haskell heart says let's just roll our
>> own, no one uses wx-config-win anyway, and all it does it find a few
>> headers and libs.
>>
>>
>
> I think a port of wx-config (shell) to Haskell is probably easier than
> doing a port into PowerShell (which I've never touched...), but I take your
> point about the 'right way'.
>
> I'll nail my colours to the mast and leave things open for debate after
> that.
>
>    - My day job is C++. Thus I tend to tolerate doing it for my 'fun'
>    projects where it is needed (e.g. wrapping a C++ library), but I kind-of
>    prefer to spend my spare time writing Haskell rather than C++ ;-)
>    - While the 'community' aspect of having a wxC is superficially
>    attractive, I think history is against the idea that it is something the
>    world really needs:
>       - wxC has been moribund for years. I don't think it's been touched
>       for over 5 years. This suggests that there is not so much demand out there.
>       - wxHaskell has struggled for contributons for as long as I
>       remember. I basically became involved because I didn't want to see it
>       bit-rot.
>
>
> What I *do* believe is that there is a real demand in the Haskell
> community for a GUI with native look and feel, commercial-friendly
> licensing and ease of installation. My preference, therefore, is to move
> wxHaskell in that direction as far as possible, and to make the bar for
> becoming a developer as low as possible for Haskell developers. Basically,
> I want to enable the Haskell ecosystem, and that's why I'm a big fan of
> cabal install, despite its limitations as a generalised build system.
>
> Having said my piece, I fully understand why others may have a different
> view, and I think if there was I strong indication that other language
> communities had a serious interest in using and helping to maintain wxC, I
> would be easily persuaded in that direction. What I don't really believe is
> in 'if you build it, they will come'.
>
> I'll leave things for a couple of days to let others have their say, and
> then follow the community preference.
>

I don't know either, needs more input I think :(


>
> Best regards
> Jeremy
>

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

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

On 9 January 2012 18:09, Dave Tapley <dav...@gm...> wrote:

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

BUILD=release
DEBUG_INFO=default
DEBUG_FLAG=1

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


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

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

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

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

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


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

I tend to think that you've hit on the problem with this approach. The
wxWidgets community doesn't really care. Therefore we would be left
maintaining a piece of C++ to support what is basically our own need.

>
> So, in summary, I'm not sure.
> My optimist, open-source heart says we should resurrect the wx-win-config
> project.
> My do-it-the-right-way heart says we ditch the existing C++ source and
> replicate the shell script (Windows PowerShell anyone?)
> My everything-is-wonderful-with-Haskell heart says let's just roll our
> own, no one uses wx-config-win anyway, and all it does it find a few
> headers and libs.
>
>

I think a port of wx-config (shell) to Haskell is probably easier than
doing a port into PowerShell (which I've never touched...), but I take your
point about the 'right way'.

I'll nail my colours to the mast and leave things open for debate after
that.

   - My day job is C++. Thus I tend to tolerate doing it for my 'fun'
   projects where it is needed (e.g. wrapping a C++ library), but I kind-of
   prefer to spend my spare time writing Haskell rather than C++ ;-)
   - While the 'community' aspect of having a wxC is superficially
   attractive, I think history is against the idea that it is something the
   world really needs:
      - wxC has been moribund for years. I don't think it's been touched
      for over 5 years. This suggests that there is not so much demand
out there.
      - wxHaskell has struggled for contributons for as long as I remember.
      I basically became involved because I didn't want to see it bit-rot.


What I *do* believe is that there is a real demand in the Haskell community
for a GUI with native look and feel, commercial-friendly licensing and ease
of installation. My preference, therefore, is to move wxHaskell in that
direction as far as possible, and to make the bar for becoming a developer
as low as possible for Haskell developers. Basically, I want to enable the
Haskell ecosystem, and that's why I'm a big fan of cabal install, despite
its limitations as a generalised build system.

Having said my piece, I fully understand why others may have a different
view, and I think if there was I strong indication that other language
communities had a serious interest in using and helping to maintain wxC, I
would be easily persuaded in that direction. What I don't really believe is
in 'if you build it, they will come'.

I'll leave things for a couple of days to let others have their say, and
then follow the community preference.

Best regards
Jeremy

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

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

On 9 January 2012 17:04, Jeremy O'Donoghue <jer...@gm...>wrote:

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

Excellent, I hope it's not too much of a nightmare, I played around a
little with my branch in Windows, but I'm primarily in Ubuntu.


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

Welcome to the party :)
Just for the sake of clarity, I feel obliged to question your use of the
words "release" and "debug"; are you aware of the "Debug Build Changes in
wx3"?
Here's the news:
http://wxwidgets.blogspot.com/2009/09/debug-build-changes-in-wx3.html
(seeing the date of the post made me realise just how far behind we are,
and also how slow the wxWidgets release cycles are!)

That has manifested itself in this known issue with wx-config-win:
http://code.google.com/p/wx-config-win/issues/detail?id=21

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

I turned to the wiki and discovered this:
http://www.scribd.com/doc/38034374/20100923-WxHaskell-Setup)

Using it as a guide (note that one can't use wxPack because there are no
wxPack releases for the development (2.9.x) releases of wxWidgets) I was
(almost) able to cabal install wxHaskell from my darcsden branch (it failed
because I didn't --with-OpenGL the wxWidgets configure, and then I ran out
of time).


> I am leaning towards doing something with Eric's wx-config. There are a
> couple of reasons for this:
>
>    - It keeps us in control of our own destiny;
>    - Haskell is a *much* more pleasant implementation language for a
>    utility which mainly does text processing than C++.
>
> Does the group have an opinion on this? My feeling is that since the last
> commit to wx-config-win was in 2006, it may be a while before fixes come
> along, and even then, we will probably need to write the patches.
>
Ah, well, yes..
Firstly the pro-(wx-config-win) items:
* I contacted the owner of wx-config-win and he made me an owner of the
Google code project, so we're 'in charge' now.
* I got a small discussion going on its existence in #wxwidgets on
freenode. The consensus is that, because /most/ people use Visual Studio
(in some flavour) to develop with wxWidgets in Windows, there simply wasn't
the need to maintain wx-config-win. As a result it was never stable enough
to merit merging in to the wxWidgets code base. By comparison the wx-config
we know and love on Linux systems (and, I presume, OS X?) is essential and
so well maintained:

http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/wx-config.in
(I didn't realise until recently that it is just a shell script, copied in
to your install dir and symlinked into your PATH).

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

So, in summary, I'm not sure.
My optimist, open-source heart says we should resurrect the wx-win-config
project.
My do-it-the-right-way heart says we ditch the existing C++ source and
replicate the shell script (Windows PowerShell anyone?)
My everything-is-wonderful-with-Haskell heart says let's just roll our own,
no one uses wx-config-win anyway, and all it does it find a few headers and
libs.



> Regards
> Jeremy
>

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

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

2012/1/8 shelarcy <she...@gm...>

> Hi,
>
> I think that we can remove old-time dependency from wxcore now. Because
> wxcore uses old-time's System.Time modules in only Graphics.UI.WXCore.Db
> module, and that module is removed this version.
>
> I attached a patch for removing old-time dependency in Dave's wxhaskell-dev
> branch. (This patch also includes one more change that removing unused
> wxhaskell/src/eiffel directory.)
>

Thanks again, I've applied these to my branch also.
It's funny you should spot that unnecessary old-time dependency now,
because I spotted and removed the .Db sample code at at almost exactly the
same time (I was trying to build all the samples..):
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120107182358-a1f0b


>
> Best Regards,
>
>
>
> On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue <
> jer...@gm...> wrote:
>
>  Hi Lists,
>>
>> I am please to announce that wxHaskell 0.13.2 has just been uploaded to
>> Hackage.
>>
>> This is mainly a bugfix release, although it brings a few useful changes:
>>
>>   - Changes to support build under Haskell Platform 2011.4.0.0
>>   - OpenGL support if your wxWidgets build is configured with it
>>   (reinstated functionality)
>>   - StyledTextControl support if your wxWidgets build is configured with
>>
>>   it (reinstated functionality)
>>
>> This is intended to be the final wxHaskell release supporting wxWidgets
>> 2.8.x.
>>
>> (snip)
>>
>>
>> The source repository at code.haskell.org has not yet been updated with
>> the
>> patches. This will happen in the next day or so.
>>
>
> --
> shelarcy <shelarcy    hotmail.co.jp>
> http://page.freett.com/**shelarcy/ <http://page.freett.com/shelarcy/>
>

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

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

Hi Dave, all
On 6 January 2012 16:02, Dave Tapley <dav...@gm...> wrote:

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

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

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

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

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

Does the group have an opinion on this? My feeling is that since the last
commit to wx-config-win was in 2006, it may be a while before fixes come
along, and even then, we will probably need to write the patches.
Regards
Jeremy

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

[shelarcy <she...@gm...>]

Hi Jeremy,

I found where causes installation problem. My wx-config-win can't recognise
--version option.

$ wx-config --version
wx-config Error: Unrecognised option: '--version'

Usage: wx-config [options]
Options:
(snip)
   -v                          Outputs the revision of wx-config.

   Note that using --prefix is not needed if you have defined the
   environmental variable WXWIN.

   Also note that using --wxcfg is not needed if you have defined the
   environmental variable WXCFG.


So, wxcore/Setup.hs' below line causes problem.

>    ver <- fmap (head . drop 1 . splitBy (== '.')) (readProcess "wx-config" ["--version"] "")

I can install wxcore with wx-config-win when commenting out that line, or
using -v option instead of --version option .

Best Regards,


On Mon, 09 Jan 2012 07:54:28 +0900, Jeremy O'Donoghue <jer...@gm...> wrote:
>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
>> Windows environment. "cabal install" fail with wx-config-win binary,
>> and "cabal install" success with Eric's one. If wxcore depends on
>> wx-config package in only Windows environment, I think we should upload
>> Eric's wx-config package, and modify wxcore to denped on wx-config package
>> on  Windows environment for workaround.
>>
>> if os(windows)
>>   Build-Depends: wx-config
>
>
> This is surprising. I am using wx-config-win on my Windows environment
> (when I run wx-config -v, I get "wx-config revision 26 2006-12-21"). I
> deliberately did not choose to use Eric's version as he had noted some
> issues with it.
>
> We should investigate your problem further (I am also using wPack 2.8.12)

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

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

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

Hi Shelarcy,

It's great to see you back...
2012/1/6 shelarcy <she...@gm...>

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


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


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


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

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

Best regards
Jeremy

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

[shelarcy <she...@gm...>]

Hi,

I think that we can remove old-time dependency from wxcore now. Because
wxcore uses old-time's System.Time modules in only Graphics.UI.WXCore.Db
module, and that module is removed this version.

I attached a patch for removing old-time dependency in Dave's wxhaskell-dev
branch. (This patch also includes one more change that removing unused
wxhaskell/src/eiffel directory.)

Best Regards,


On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue <jer...@gm...> wrote:

> Hi Lists,
>
> I am please to announce that wxHaskell 0.13.2 has just been uploaded to
> Hackage.
>
> This is mainly a bugfix release, although it brings a few useful changes:
>
>    - Changes to support build under Haskell Platform 2011.4.0.0
>    - OpenGL support if your wxWidgets build is configured with it
>    (reinstated functionality)
>    - StyledTextControl support if your wxWidgets build is configured with
>    it (reinstated functionality)
>
> This is intended to be the final wxHaskell release supporting wxWidgets
> 2.8.x.
>
> (snip)
>
> The source repository at code.haskell.org has not yet been updated with the
> patches. This will happen in the next day or so.

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

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

[shelarcy <she...@gm...>]

On Sat, 07 Jan 2012 01:02:44 +0900, Dave Tapley <dav...@gm...> wrote:
>
>> This version has two installing problem.
>>
>> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
>> Windows environment. "cabal install" fail with wx-config-win binary,
>>
>
> Can you remember how this failed, or send some output from the failure, and
> also let us know what version of wxWidgets you have?
> I'm hoping you say you have wx-2.9.x, in which case it could be this issue:
> http://code.google.com/p/wx-config-win/issues/detail?id=21

I used wxWidgets 2.8.12 (wxPack v2.8.12.01) to install wxcore. I can install
previous version with wx-config(-win).


C:\home\working> cabal install wx-0.12.1.6 wxcore-0.12.1.7
(snip)
Registering wxcore-0.12.1.7...
Installing library in
C:\Users\shelarcy\AppData\Roaming\cabal\wxcore-0.12.1.7\ghc-7.0.4
Registering wxcore-0.12.1.7...
Configuring wx-0.12.1.6...
Preprocessing library wx-0.12.1.6...
Building wx-0.12.1.6...
(snip)
Registering wx-0.12.1.6...
Installing library in
C:\Users\shelarcy\AppData\Roaming\cabal\wx-0.12.1.6\ghc-7.0.4
Registering wx-0.12.1.6...


But ... I can't install current version with wx-config(-win).

Here's the output.


C:\home\working>wx-config -v
wx-config revision 21 2006-10-19

C:\home\working>cabal install wxcore
Resolving dependencies...
[1 of 1] Compiling Main             ( C:\Users\shelarcy\AppData\Local\Temp\wxcor
e-0.13.27884\wxcore-0.13.2\Setup.hs, C:\Users\shelarcy\AppData\Local\Temp\wxcore
-0.13.27884\wxcore-0.13.2\dist\setup\Main.o )
Linking C:\Users\shelarcy\AppData\Local\Temp\wxcore-0.13.27884\wxcore-0.13.2\dis
t\setup\setup.exe ...
generating: src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs
reading class definitions:
parsing: src/include/wxc.h
parsing: src/include/wxc_types.h
parsing: src/include/wxc_glue.h
parsing: src/include/dragimage.h
parsing: src/include/graphicscontext.h
parsing: src/include/glcanvas.h
parsing: src/include/sound.h
parsing: src/include/managed.h
parsing: src/include/mediactrl.h
parsing: src/include/previewframe.h
parsing: src/include/printout.h
parsing: src/include/textstream.h
parsing: src/include/stc.h
parsing: src/include/stc_gen.h
generated 535 class definitions.
ok.
generating: src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs
reading class definitions:
parsing: src/include/wxc.h
parsing: src/include/wxc_types.h
parsing: src/include/wxc_glue.h
parsing: src/include/dragimage.h
parsing: src/include/graphicscontext.h
parsing: src/include/glcanvas.h
parsing: src/include/sound.h
parsing: src/include/managed.h
parsing: src/include/mediactrl.h
parsing: src/include/previewframe.h
parsing: src/include/printout.h
parsing: src/include/textstream.h
parsing: src/include/stc.h
parsing: src/include/stc_gen.h
generated 382 class info definitions
ok.
parsing: src/include/wxc.h
parsing: src/include/wxc_types.h
parsing: src/include/wxc_glue.h
parsing: src/include/dragimage.h
parsing: src/include/graphicscontext.h
parsing: src/include/glcanvas.h
parsing: src/include/sound.h
parsing: src/include/managed.h
parsing: src/include/mediactrl.h
parsing: src/include/previewframe.h
parsing: src/include/printout.h
parsing: src/include/textstream.h
parsing: src/include/stc.h
parsing: src/include/stc_gen.h
generating: src/haskell/Graphics/UI/WXCore/WxcClassesAL.hs
reading class definitions:
parsing: src/include/wxc.h
parsing: src/include/wxc_types.h
parsing: src/include/wxc_glue.h
parsing: src/include/dragimage.h
parsing: src/include/graphicscontext.h
parsing: src/include/glcanvas.h
parsing: src/include/sound.h
parsing: src/include/managed.h
parsing: src/include/mediactrl.h
parsing: src/include/previewframe.h
parsing: src/include/printout.h
parsing: src/include/textstream.h
parsing: src/include/stc.h
parsing: src/include/stc_gen.h
generated 1468 methods for 116 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClassesMZ.hs
generated 2320 methods for 123 classes.
generating: src/haskell/Graphics/UI/WXCore/WxcClasses.hs
generated 3788 total methods for 239 total classes.
ok.
parsing: src/eiffel/wxc_defs.e
parsing: src/eiffel/wx_defs.e
parsing: src/eiffel/stc.e
generating: src/haskell/Graphics/UI/WXCore/WxcDefs.hs
generated 2454 constant definitions
ok.
Usage: wx-config [options]
Options:
   --prefix[=DIR]              Path of the wxWidgets installation (ie. C:\wxWidge
ts2.6.3)
   --wxcfg[=DIR]               Relative path of the build.cfg file (ie. gcc_dll\m
swud)
   --cflags                    Outputs all pre-processor and compiler flags.
   --cxxflags                  Same as --cflags but for C++.
   --rcflags                   Outputs all resource compiler flags. [UNTESTED]
   --libs                      Outputs all linker flags.

   --debug[=yes|no]            Uses a debug configuration if found.
   --unicode[=yes|no]          Uses an unicode configuration if found.
   --static[=yes|no]           Uses a static configuration if found.
   --universal[=yes|no]        Uses an universal configuration if found.
   --easymode[=yes|no]         Outputs warnings, and optimize flags.
   --compiler[=gcc,dmc,vc]     Selects the compiler.
   --release                   Outputs the wxWidgets release number.
   --cc                        Outputs the name of the C compiler.
   --cxx                       Outputs the name of the C++ compiler.
   --ld                        Outputs the linker command.
   -v                          Outputs the revision of wx-config.

   Note that using --prefix is not needed if you have defined the
   environmental variable WXWIN.

   Also note that using --wxcfg is not needed if you have defined the
   environmental variable WXCFG.

setup.exe: failed
cabal: Error: some packages failed to install:
wxcore-0.13.2 failed during the configure step. The exception was:
ExitFailure 1



Best Regards,


>  and "cabal install" success with Eric's one. If wxcore depends on
>> wx-config package in only Windows environment, I think we should upload
>> Eric's wx-config package, and modify wxcore to denped on wx-config package
>> on  Windows environment for workaround.
>>
>> if os(windows)
>>   Build-Depends: wx-config
>>
>> wx-config package isn't uploaded yet. So, I don't upload newer version,
>> nor attach patch for fixing this problem.
>>
>
> We're still making a decision on whether to continue using wx-config(-win),
> or to adopt Eric's one.
> I'm going to see if I can get a conversation going with the wxWidgets
> people and then I'll send out another mail.

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

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

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

2012/1/6 shelarcy <she...@gm...>

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

Good catch, thanks, I've pushed to the -dev branch.


>
> 2. It seems that wxcore depends on Eric's wx-config implicitly at least
> Windows environment. "cabal install" fail with wx-config-win binary,
>

Can you remember how this failed, or send some output from the failure, and
also let us know what version of wxWidgets you have?
I'm hoping you say you have wx-2.9.x, in which case it could be this issue:
http://code.google.com/p/wx-config-win/issues/detail?id=21

 and "cabal install" success with Eric's one. If wxcore depends on
> wx-config package in only Windows environment, I think we should upload
> Eric's wx-config package, and modify wxcore to denped on wx-config package
> on  Windows environment for workaround.
>
> if os(windows)
>   Build-Depends: wx-config
>
> wx-config package isn't uploaded yet. So, I don't upload newer version,
> nor attach patch for fixing this problem.
>

We're still making a decision on whether to continue using wx-config(-win),
or to adopt Eric's one.
I'm going to see if I can get a conversation going with the wxWidgets
people and then I'll send out another mail.

Cheers,


>
>
> Best Regards,
>
>
>
> On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue <
> jer...@gm...> wrote:
>
>> Hi Lists,
>>
>> I am please to announce that wxHaskell 0.13.2 has just been uploaded to
>> Hackage.
>>
>> This is mainly a bugfix release, although it brings a few useful changes:
>>
>>   - Changes to support build under Haskell Platform 2011.4.0.0
>>   - OpenGL support if your wxWidgets build is configured with it
>>   (reinstated functionality)
>>   - StyledTextControl support if your wxWidgets build is configured with
>>
>>   it (reinstated functionality)
>>
>> This is intended to be the final wxHaskell release supporting wxWidgets
>> 2.8.x.
>>
>> Provided that you have a suitable Unicode wxWidgets 2.8 install configured
>> on your machine, you should be able to install with. cabal install wx
>>
>> In the near future, we will be committing an updated wxHaskell release
>> supporting wxWidgets 2.9, but this implies a number of breaking API
>> changes, and the size of team supporting wxHaskell is not large enough to
>> cover both. As such, this release is recommended to those who will not be
>> able to move to wxWidgets 2.9 and later.
>>
>> The next release has more significant improvements planned, including
>> wrapping several additional wxWIdgets libraries and restoring correct
>> operation in GHCi. We do not have a formal timeline as yet, but the code
>> is
>> working in test repositories, and mainly needs work to make it
>> cross-platform clean.
>>
>> This release has been tested on the following platforms:
>>
>>   - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode,
>>   Release)
>>      - OpenGL is not enabled on the test platform, so OpenGL samples do
>>      not work.
>>      - StyledTextControl is not enabled on the test platform, so STC
>>      samples do not work.
>>      - All other sample code compiles, links and runs, but has only been
>>
>>      tested for Unicode wxWidgets builds.
>>   - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10
>>      - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev,
>>
>>      libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa,
>> libglu1-mesa-dev,
>>      mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6
>>      - Cabal packages: strict, stm, OpenGL, cabal-install
>>      - OpenGL is enabled on the test platform, and the samples compile and
>>      run.
>>      - StyledTextControl is not enabled on the test platform, so STC
>>      samples do not work.
>>      - All other sample code compiles, links and runs, but has only been
>>
>>      tested for Unicode wxWidgets.
>>
>> I do not have access to an OS X platform for test, so would appreciate
>> feedback on any issues found by OS X users. There are known to be issues
>> on
>> 64 bit OS X builds, which will be addressed in the next release.
>>
>> The source repository at code.haskell.org has not yet been updated with
>> the
>> patches. This will happen in the next day or so.
>>
>
> --
> shelarcy <shelarcy    hotmail.co.jp>
> http://page.freett.com/**shelarcy/ <http://page.freett.com/shelarcy/>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

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

[shelarcy <she...@gm...>]

Hello,

This version has two installing problem.

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

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

if os(windows)
    Build-Depends: wx-config

wx-config package isn't uploaded yet. So, I don't upload newer version,
nor attach patch for fixing this problem.


Best Regards,


On Fri, 06 Jan 2012 02:44:24 +0900, Jeremy O'Donoghue <jer...@gm...> wrote:
> Hi Lists,
>
> I am please to announce that wxHaskell 0.13.2 has just been uploaded to
> Hackage.
>
> This is mainly a bugfix release, although it brings a few useful changes:
>
>    - Changes to support build under Haskell Platform 2011.4.0.0
>    - OpenGL support if your wxWidgets build is configured with it
>    (reinstated functionality)
>    - StyledTextControl support if your wxWidgets build is configured with
>    it (reinstated functionality)
>
> This is intended to be the final wxHaskell release supporting wxWidgets
> 2.8.x.
>
> Provided that you have a suitable Unicode wxWidgets 2.8 install configured
> on your machine, you should be able to install with. cabal install wx
>
> In the near future, we will be committing an updated wxHaskell release
> supporting wxWidgets 2.9, but this implies a number of breaking API
> changes, and the size of team supporting wxHaskell is not large enough to
> cover both. As such, this release is recommended to those who will not be
> able to move to wxWidgets 2.9 and later.
>
> The next release has more significant improvements planned, including
> wrapping several additional wxWIdgets libraries and restoring correct
> operation in GHCi. We do not have a formal timeline as yet, but the code is
> working in test repositories, and mainly needs work to make it
> cross-platform clean.
>
> This release has been tested on the following platforms:
>
>    - Windows 7 / Haskell Platform 2011.4.0.0 / wxPack 2.8.12 (Unicode,
>    Release)
>       - OpenGL is not enabled on the test platform, so OpenGL samples do
>       not work.
>       - StyledTextControl is not enabled on the test platform, so STC
>       samples do not work.
>       - All other sample code compiles, links and runs, but has only been
>       tested for Unicode wxWidgets builds.
>    - Ubuntu 10.0.4 LTS (32 bit) / GHC 6.12 / wxWidgets 2.8.10
>       - Repo packages: wx2.8-headers, libwxgtk2.8-0, libwxgtk2.8-dev,
>       libglitz1, libglitz-gl1, libgl1-mesa-dri, libglu1-mesa, libglu1-mesa-dev,
>       mesa-common-dev, libgl1-mesa-dev, libgl1-mesa-glx, ghc6
>       - Cabal packages: strict, stm, OpenGL, cabal-install
>       - OpenGL is enabled on the test platform, and the samples compile and
>       run.
>       - StyledTextControl is not enabled on the test platform, so STC
>       samples do not work.
>       - All other sample code compiles, links and runs, but has only been
>       tested for Unicode wxWidgets.
>
> I do not have access to an OS X platform for test, so would appreciate
> feedback on any issues found by OS X users. There are known to be issues on
> 64 bit OS X builds, which will be addressed in the next release.
>
> The source repository at code.haskell.org has not yet been updated with the
> patches. This will happen in the next day or so.

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

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

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

On 5 Jan 2012, at 18:14, Jeremy O'Donoghue wrote:
> I am not so keen on this approach. It seems like ever since I have had anything to do with wxHaskell, far more time has been spent on build system issues than on Haskell code or getting new wxWidgets components wrapped.

Yup.

Churn churn churn.

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

Well, hang on.  Believe me, I am so not doing build system advocacy here.  There will be no discussion on the technical merits of one system over another coming from me.

All I was talking about is the social calculation: would wxHaskell benefit from a wxc that is maintained outside the Haskell community? Does such a community even exist in the first place, or is a pipe dream? I imagine it *won't* be wxPython/wxRuby etc as they have their own mechanism for getting their bindings. But it might be handy for other small languages, eg. Mercury?  Even if such other bindings exist that would use a wxc, would it still be worthwhile, or would the coordination overhead bog us down (being able to just change wxc do what we want makes us pretty nimble).

If the social calculation points to "kick wxc out", then the kicked-out wxc should be language-agnostic (well, beyond C and C++ of course).

That's all I'm saying.

Eric

PS:  Hmm, I don't think we were using autotools so much as a hand-written Makefile and configure script with a bunch of shell scripts that nobody really understood.  Also, I'm not suggesting autotools specifically; if anything, Bakefile instead since it's the same as what wxWidgets use.  

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

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

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

On 5 January 2012 12:15, Eric Kow <eri...@gm...> wrote:

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


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

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

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

I accept that Cabal is not an ideal build system, but it does 'just work'
when it comes to cross-platform builds.

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

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

>
> Wow! If this works, Conal might be pleased.
>

Yes, indeed! I've been blocked in my high-level GUIs & graphics work for a
few years, while waiting for a low-level (imperative) Haskell library to
show up that combines GUIs & graphics, works cross-platform (including
native graphics on Mac), and supports incremental development. gtk2hs
almost got there recently, but not quite, and I've always preferred
wxHaskell's API.

  - Conal

On Thu, Jan 5, 2012 at 7:36 AM, Dave Tapley <dav...@gm...> wrote:

> On 4 January 2012 18:23, Eric Kow <eri...@gm...> wrote:
>
>>
>> On 4 Jan 2012, at 16:59, Dave Tapley wrote:
>> > Also, I imagine that while this brings us closer to wxHaskell in GHCi,
>> we would still need to solve the second start crash?
>> >
>> >
>> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845
>> >
>> > Well, I just had a look, and that issue seems to have gone away in my
>> darcsden branch!
>> > I've added a comment to the tracker.
>> >
>>
>> Wow! If this works, Conal might be pleased.
>>
>
> It certainly seems to, insomuch as the given test code no longer causes a
> crash :)
>
>
>>
>> By the way, you mentioned wx-config (I get the feeling you'd asked me a
>> direct question and I forgot to answer).  Did you have a look at the
>> Haskell code in our repo which provides a wx-config replacement?  The
>> replacement is very very stupid and needs generalising, but it might be
>> easier to bring it closer to the kind of completeness we need than to
>> maintain the C++ one.
>>
>
> Ah, yes, I suspected this would need some debate.
> I was on the cusp of merging in your wx-config implementation, namely:
> http://darcsden.com/kowey/wxhaskell/browse/wx-config/
>
> But then I got a reply from the previous project leader wx-config-win:
> http://code.google.com/p/wx-config-win/
>
> He had hoped that one day wx-config-win might be merged in to wxWidgets,
> but noted that it had fallen behind the project and had several known
> issues:
> http://code.google.com/p/wx-config-win/issues/list
>
> Personally I feel that (for similar arguments to those for maintaining wxC
> as a language-agnostic project) we should pursue wx-config-win. Thoughts?
>
>
>
>>
>> --
>> Eric Kow <http://erickow.com>
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iEYEARECAAYFAk8EmT4ACgkQBUrOwgisBPnz/wCdEapNshQh+ZqEh2SyyXi/uXO9
>> 5lcAnRymzM7qQnzru6cdKpoTqZZ3kQM4
>> =hcbP
>> -----END PGP SIGNATURE-----
>>
>>
>

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

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

On 5 Jan 2012, at 15:36, Dave Tapley wrote:
> Personally I feel that (for similar arguments to those for maintaining wxC as a language-agnostic project) we should pursue wx-config-win. Thoughts?

I think we should get in touch with the wxWidgets guys and see if it really is a patches welcome situation, or if they feel that supporting wx-config-win would lead them to be overstretched.

You'll also want to have a look at wxPack, I think.

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

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

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

On 4 January 2012 18:23, Eric Kow <eri...@gm...> wrote:

>
> On 4 Jan 2012, at 16:59, Dave Tapley wrote:
> > Also, I imagine that while this brings us closer to wxHaskell in GHCi,
> we would still need to solve the second start crash?
> >
> >
> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845
> >
> > Well, I just had a look, and that issue seems to have gone away in my
> darcsden branch!
> > I've added a comment to the tracker.
> >
>
> Wow! If this works, Conal might be pleased.
>

It certainly seems to, insomuch as the given test code no longer causes a
crash :)


>
> By the way, you mentioned wx-config (I get the feeling you'd asked me a
> direct question and I forgot to answer).  Did you have a look at the
> Haskell code in our repo which provides a wx-config replacement?  The
> replacement is very very stupid and needs generalising, but it might be
> easier to bring it closer to the kind of completeness we need than to
> maintain the C++ one.
>

Ah, yes, I suspected this would need some debate.
I was on the cusp of merging in your wx-config implementation, namely:
http://darcsden.com/kowey/wxhaskell/browse/wx-config/

But then I got a reply from the previous project leader wx-config-win:
http://code.google.com/p/wx-config-win/

He had hoped that one day wx-config-win might be merged in to wxWidgets,
but noted that it had fallen behind the project and had several known
issues:
http://code.google.com/p/wx-config-win/issues/list

Personally I feel that (for similar arguments to those for maintaining wxC
as a language-agnostic project) we should pursue wx-config-win. Thoughts?



>
> --
> Eric Kow <http://erickow.com>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk8EmT4ACgkQBUrOwgisBPnz/wCdEapNshQh+ZqEh2SyyXi/uXO9
> 5lcAnRymzM7qQnzru6cdKpoTqZZ3kQM4
> =hcbP
> -----END PGP SIGNATURE-----
>
>

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

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

On 4 Jan 2012, at 16:59, Dave Tapley wrote:

> I do like the idea that wxc is a separate project, upon which wxHaskell depends, however..
> When configuring wxcore I use wxc's package info, and so require wxc to be installed by cabal, and I assume it is the intention of the wxC project to be language independent?

I think that would help.  One hope is that if we had a separate project that tried harder to be language agnostic, and which had none of the trappings of a Haskell project, we might be able to get more help from the wxWidgets team.  Make it look like any other project written in C, the basic autotools (or more likely Bakefile as wxWidgets use it), the pkgconfig stuff, etc.

Then you can imagine wxc getting into your favourite package manager, like Homebrew. 

> However as I note there it does make wxc dependent on gcc, and now I'm thinking that the perhaps it's better to move to the language independent wxC approach (i.e. away from cabal), and use a make system which does 'real' C++ dependency tracking.

Yup.  I'd suggest using whatever wxWidgets use.

Note also that the wxWidgets people have in the past brought up Swig and the idea of abusing doxygen to generate the wxC layer.

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

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

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

On 4 Jan 2012, at 16:59, Dave Tapley wrote:
> Also, I imagine that while this brings us closer to wxHaskell in GHCi, we would still need to solve the second start crash?
> 
> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845
> 
> Well, I just had a look, and that issue seems to have gone away in my darcsden branch!
> I've added a comment to the tracker.
>  

Wow! If this works, Conal might be pleased.

By the way, you mentioned wx-config (I get the feeling you'd asked me a direct question and I forgot to answer).  Did you have a look at the Haskell code in our repo which provides a wx-config replacement?  The replacement is very very stupid and needs generalising, but it might be easier to bring it closer to the kind of completeness we need than to maintain the C++ one.

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

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

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

On 2 January 2012 09:22, Eric Kow <eri...@gm...> wrote:

>
> On 2 Jan 2012, at 08:48, Jeremy O'Donoghue wrote:
>
> >       • wxC is built as a shared library. This means that wxHaskell
> works in GHCi again, which has been one of the most requested bugfixes over
> the past 18 months or so.
>
> Sweet!
>
> I've made you and Dave admins to the wxC SF project, just in case you felt
> it would help to dissociate it from wxHaskell (thereby attracting people
> from other language bindings, or people who just want to write wxWidgets
> GUIs in C).  The idea could be that wxC would be developed to track
> wxWidgets, whereas wxHaskell would be trying to keep up with wxC.  But
> maybe this would just be a big distraction.  Up to you :-)
>

Ah, I saw wxC before and assumed the project was dead.
As such, in my branch wxc lives entirely under within wxHaskell, here:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc

I do like the idea that wxc is a separate project, upon which wxHaskell
depends, however..
When configuring wxcore I use wxc's package info, and so require wxc to be
installed by cabal, and I assume it is the intention of the wxC project to
be language independent?
You can see (and I invite you to comment on) my use of wxc's package info
in wxcInstallDir, here:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxcore/Setup.hs


>
> Also, I imagine that while this brings us closer to wxHaskell in GHCi, we
> would still need to solve the second start crash?
>
>
> https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=7the3133&atid=536845<https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=73133&atid=536845>
>

Well, I just had a look, and that issue seems to have gone away in my
darcsden branch!
I've added a comment to the tracker.


>
> >       • Build system improvements to reduce 'unnecessary' rebuilding of
> source files - again, one for developers.
>
> Yay!
>

Oh, one note here:
At the moment I'm using Jeremy's getModificationTime on src and obj
approach to dependency checking, which he put his hand up to not really
being robust enough:
https://sourceforge.net/mailarchive/message.php?msg_id=28121303

You can see where this turns up under needsCompiling here in my repo:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs

Now I do actually have a patch sat on my machine which adds better
dependency tracking, I alluded to it here:
http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html

However as I note there it does make wxc dependent on gcc, and now I'm
thinking that the perhaps it's better to move to the language independent
wxC approach (i.e. away from cabal), and use a make system which does
'real' C++ dependency tracking.

Dave,


> --
> Eric Kow <http://erickow.com>
>
>
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk8Bd14ACgkQBUrOwgisBPkGAwCfdZYMF2brAwOH2rM660Bh1pXN
> QHgAn2LdNVkXGIRMGJ0xGAmlDWnQXfej
> =2c1B
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

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

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

On 2 January 2012 08:48, Jeremy O'Donoghue <jer...@gm...>wrote:

> Hi lists,
>
> A Happy New Year to all, and with it a chance to talk about some imminent
> changes in wxHaskell. There is nothing new in this mail for those who
> follow the wxhaskell-devel list, but for users who are interested in the
> evolution of the project, I thought this would be a good time to summarise.
>
> First, there will be a new release of wxHaskell in the next few days. This
> is mainly a bugfix edition, but also reinstates some features which were
> lost with Cabalization. Specifically:
>
>    - Styled Text Control support
>    - OpenGL support
>    - Support for building on Haskell Platform 2011.4
>
> This will be the last update of wxHaskell to support the wxWidgets 2.8.x
> releases.
>
Thanks for taking care of this last release Jeremy :)

> Following shortly afterwards, the very exciting news is that a number of
> people (Dave Tapley in particular) have been putting a lot of work over the
> last few months towards support of the wxWidgets 2.9 releases. This does
> introduce a small number of breaking changes as the wxWidgets API has
> changed in places, but brings with it quite a number of improvements:
>
Just to note again, I've been pushing all my 2.9 dev work here:
http://darcsden.com/DukeDave/wxhaskell-dev

That branch's wxC configure will fail if wx-config reports a version other
than 2.9.x, see readWxConfig in:
http://darcsden.com/DukeDave/wxhaskell-dev/browse/wxc/Setup.hs

>
>    - wxC is built as a shared library. This means that wxHaskell works in
>    GHCi again, which has been one of the most requested bugfixes over the past
>    18 months or so.
>    - Support for wxPropertyGrid and associated classes.
>    - Support for the wxWidgets AUI classes.
>    - Support for wxMediaControl.
>    - Removal of legacy use of Eiffel files to generate constant
>    definitions. This is only of interest to developers, but is far cleaner.
>    - Build system improvements to reduce 'unnecessary' rebuilding of
>    source files - again, one for developers.
>    - Support for 64bit OS X platforms.
>
> We will make a release of wxHaskell with all of the new features soon
> after the changes have been merged into the main repository, and have been
> more fully tested on all of our supported platforms.
>
Yes the testing on more platforms is where the emphasis needs to be here.
I'm primarily working in Ubuntu, but I did do a small amount of work trying
to ensure Windows is supported in my branch.
One hurdle I ran in to is that wx-config-win is unmaintained and no longer
works with wxWidgets 2.9.x:
http://code.google.com/p/wx-config-win/

The good news is that I emailed the old maintainer and he both responded
and made me an owner of that project.
I just need to make some small changes there, and then we should be able to
get wxHaskell building in Windows against 2.9.x, see here:
http://code.google.com/p/wx-config-win/issues/detail?id=21

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

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

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

On 19 December 2011 22:02, Dave Tapley <duk...@gm...> wrote:

> On 14 December 2011 07:16, Dave Tapley <duk...@gm...> wrote:
> > The only major problem remaining (aside from the woeful lack of
> > testing, and support for non-Linux platforms) is you have to pass an
> > rpath to the linker when compiling; so you get something like this:
> >
> > samples/wxcore$ ghc --make -package-conf
> > ../../cabal-dev/packages-7.0.3.conf/
> > -optl-Wl,-rpath,../../cabal-dev/lib/wxc-0.1/ghc-7.0.3 HelloWorld.hs
>

I believe I have fixed the requirement to pass an rpath with this patch:
http://darcsden.com/DukeDave/wxhaskell-dev/patch/20120103181105-a1f0b

Dave,

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

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

Jeremy O'Donoghue wrote:
> Following shortly afterwards, the very exciting news is that a number of
> people (Dave Tapley in particular) have been putting a lot of work over the
> last few months towards support of the wxWidgets 2.9 releases. This does
> introduce a small number of breaking changes as the wxWidgets API has
> changed in places, but brings with it quite a number of improvements:
> 
>    - wxC is built as a shared library. This means that wxHaskell works in
>    GHCi again, which has been one of the most requested bugfixes over the past
>    18 months or so.

Hurray, that promises to be a really happy new year! The bananas will 
*dance*!


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com

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

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

On 2 Jan 2012, at 08:48, Jeremy O'Donoghue wrote:

> 	• wxC is built as a shared library. This means that wxHaskell works in GHCi again, which has been one of the most requested bugfixes over the past 18 months or so.

Sweet!

I've made you and Dave admins to the wxC SF project, just in case you felt it would help to dissociate it from wxHaskell (thereby attracting people from other language bindings, or people who just want to write wxWidgets GUIs in C).  The idea could be that wxC would be developed to track wxWidgets, whereas wxHaskell would be trying to keep up with wxC.  But maybe this would just be a big distraction.  Up to you :-)

Also, I imagine that while this brings us closer to wxHaskell in GHCi, we would still need to solve the second start crash?

https://sourceforge.net/tracker/?func=detail&aid=1610984&group_id=73133&atid=536845

> 	• Build system improvements to reduce 'unnecessary' rebuilding of source files - again, one for developers.

Yay!

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

[wxhaskell-devel] Happy New Year, wxHaskellers

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

Hi lists,

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

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

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

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

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

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

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

Best regards

Jeremy