wxhaskell-devel — wxhaskell developers

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

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

On 14 December 2011 07:16, Dave Tapley <duk...@gm...> wrote:
> Well, after a couple of days' frantic hacking I've made more progress,
> and I'd invite anyone to comment on my decisions:
>
> The compilation of the C++ 'wrapper' code has now been moved to a
> separate project which I've called wxc.
> This will now do the compilation and linking as per Jeremy's gist, and
> then install the headers and the shared library (that is, install in
> the cabal sense of the word).
>
> Here's the clever part (well, I'm quite pleased with it):
> Now wxcore depends on wxc, and during the wxcore configuration hook it
> uses cabal to get the install information for wxc, from this it can
> obtain the location of the aforementioned headers and shared library,
> which can then link against.
>
> The upshot:
> 1. All the C++ code is now in wxc.
> 2. Only wxc has to link against the wxWidgets libraries.
> 3. wxcore only uses the installed headers (to generate Haskell code
> using wxdirect) and shared library from wxc (to link against).
>
> 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
>
> In any case, I've pushed the changes to my darcden branch, and I
> invite you to take a look:
> http://darcsden.com/DukeDave/wxhaskell-dev

I've just pushed a bunch of bug fixes to this repo, so if you were
having trouble before then hopefully everything will be better now.

>
> (Please accept my apologies for the record fail, needless to say the
> change is split across two patches; I'm not happy either..)
>
> Dave,

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

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

Well, after a couple of days' frantic hacking I've made more progress,
and I'd invite anyone to comment on my decisions:

The compilation of the C++ 'wrapper' code has now been moved to a
separate project which I've called wxc.
This will now do the compilation and linking as per Jeremy's gist, and
then install the headers and the shared library (that is, install in
the cabal sense of the word).

Here's the clever part (well, I'm quite pleased with it):
Now wxcore depends on wxc, and during the wxcore configuration hook it
uses cabal to get the install information for wxc, from this it can
obtain the location of the aforementioned headers and shared library,
which can then link against.

The upshot:
1. All the C++ code is now in wxc.
2. Only wxc has to link against the wxWidgets libraries.
3. wxcore only uses the installed headers (to generate Haskell code
using wxdirect) and shared library from wxc (to link against).

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

In any case, I've pushed the changes to my darcden branch, and I
invite you to take a look:
http://darcsden.com/DukeDave/wxhaskell-dev

(Please accept my apologies for the record fail, needless to say the
change is split across two patches; I'm not happy either..)

Dave,

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

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

On 12 December 2011 17:18, Jeremy O'Donoghue <jer...@gm...> wrote:
> Hi Dave, all,
>
> This is fantastic news - especially the bit about GHCi. I have put a couple
> of general comments inline, but it looks like you have found most of the
> issues, at least on Linux.
>
> I think that at least some of the issues would go away if, as you say,
>
> "we could have an entirely separate cabal project (perhaps "wxc") for this
> shared library, and then have wxcore depend on it?"
>
> In this case, we would be able to ensure that libwxc.so.x.y.z (or wxc.dll or
> libwxc.dylib or whatever) was in a 'normal' place before wxcore gets built.
>
> On 9 December 2011 14:13, Dave Tapley <duk...@gm...> wrote:
>>
>> On 8 December 2011 22:34, Dave Tapley <duk...@gm...> wrote:
>> > Hello everyone,
>> >
>> > I wrote a story, and I invite you all to comment and help me make it
>> > better.
>> > As an experiment I've decided to put it on hpaste instead of having
>> > the mail thread get out of hand (I'm also cross posting it to the
>> > cabal list and have mentioned it in #haskell, and I want to keep all
>> > correspondence in one place):
>> > http://hpaste.org/55027
>>
>> Ha, well that was good timing for hpaste to go down!
>> Here's it is:
>>
>> I've been trying to resurrect the idea of building a shared library
>> for the C++ component of the wxhaskell library.
>>
>> Jeremy (to my knowledge) first put this forward, here:
>>
>> http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/
>>
>> In addition to the advantages he lists there, I have the following reason:
>> When building wx-core (in its current incarnation) cabal will *always*
>> rebuild all the C++ code, which takes a majority of the build time.
>> This becomes very frustrating when you change one line of Haskell and
>> have to wait seven minutes to rebuild.
>> I complained about it here:
>> http://sourceforge.net/mailarchive/message.php?msg_id=28099997
>>
>> So, I decided to try and stop this complete C++ rebuild, I partially
>> succeed, but I eventually got stuck for reasons I complained here:
>> http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html
>>
>> Side note: I did eventually discover why (or, where) the c-sources
>> (cSources) list is used to compile and link, and it is here:
>>
>> http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib
>> You can see:
>> "| filename <- cSources libBi]" under "-- build any C sources", and
>> you can see:
>> "cSharedObjs = map (`replaceExtension` ("dyn_" ++ objExtension))
>> (cSources libBi)"
>> under "-- link:".
>> Is this assumption correct?
>
>
> This is correct - it's the standard way Cabal builds C/C++ code. To be
> honest, this is really a consequence of the fact that Cabal is more of a
> tool for simple distribution than a Make replacement, and the developers
> probably didn't expect Cabal would be used to build large bodies of C++
> code.
>
> My approach is far from perfect, too - in fact it is incorrect because I
> don't do dependency tracking on header files, so if you edit a header, it
> (incorrectly) fails to rebuild. This is because I wasn't keen on rewriting
> 'make' in the wxHaskell build system - it seems to me like something Cabal
> could usefully support. I did play with some very hacky code which
> automatically rebuilt all of the C++ code if any header is newer than any
> C++ source. This is aesthetically dreadful, but it somewhat captures the
> reality, since in practice, pretty much all of the C++ files depend on all
> of the headers (and it's easy to write).
>
> On reflection, we should probably do this as what exists at present could
> lead to unexpectedly incorrect code being generated if someone is in full
> flow of development. I'll see if I can dig up some code - I think I have it
> somewhere.

You know, I'm surprised this didn't occur to me until now:
Does the C++ code actually need to use cabal at all?
If it's a separate project, perhaps it would be more sensible to use a
C++ oriented build system?
Then, unless I'm missing something, it can install the headers
somewhere, and wxcore can run wxdirect on the headers are currently.

The big disadvantage I can see with moving the C++ out of the wxcore
project is lots of pain for users when they 'cabal update' and
suddenly wxcore fails because they need to update the C++ headers /
library.

Another disadvantage is that this will make development a little more
painful (although the time saved not having to rebuild all the C++ is
a huge bonus) because you wouldn't (without some hackery) be able to
use cabal-dev as described here:
http://haskell.org/haskellwiki/WxHaskell/Development/Environment#Building_and_testing_wxHaskell

I happened upon this (dead) project, which I seems to have the goal I
am outlining:
http://wxc.sourceforge.net/

>
>> At this point I thought about either:
>> 1. Getting the cabal source and starting to write code to give
>> BuildInfo a "cObjs" in addition to "cSources".
>> 2. Picking up Jeremy's shared library code, so wxhaskell would have
>> its own code to build the library, in which I could do sensible
>> re-compilation.
>>
>> Given that there were other advantages to 2, I went with that.
>>
>> Jeremy had written one blog post on building a such a shared library,
>> here:
>>
>> http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
>> In response to an email on the wxhaskell-devel list he also kindly put
>> up this gist, with the code he'd been working on:
>> https://gist.github.com/1301115
>>
>> I dutifully took this gist, and have now attempted to integrate in to
>> my wxhaskell-dev branch, which you can find here:
>> http://darcsden.com/DukeDave/wxhaskell-dev
>> (note: I haven't pushed any of the shared library code to darcsden
>> yet, for reasons I'm about to explain)
>>
>> This is where things got interesting, after a few hours of hacking I
>> have built a shared library, but in this very back-handed way:
>>
>> Firstly, in Jeremy's code the to-be-compiled shared library is added
>> to the wxcore BuildInfo through a custom hook.
>> We can see this because:
>> > let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"]
>> > custom_bi
>> (the modified wxcore.cabal contains the line: "x-dll-name: wxc")
>>
>> However on a clean build of wxcore we get the following error:
>>
>> setup: Missing dependency on a foreign library:
>> * Missing C library: wxc
>> This problem can usually be solved by installing the system package that
>> provides this library (you may need the "-dev" version). If the library is
>> already installed but in a non-standard location then you can use the
>> flags
>> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>
>
> My code worked for Windows - but this is a better cross-platform solution.

Interesting.
I found this fixed feature on cabal:
http://hackage.haskell.org/trac/hackage/ticket/262
It suggests that cabal uses Autoconf to resolve dependencies,
specifically the AC_CHECK_LIB macro.
I have zero knowledge of build systems in Windows, but is it
reasonable to suggest that Autoconf could be more relaxed?

I really should get a Windows build environment set up..

>
>>
>> The error is dumped *before* cabal calls myBuildHook, and since this
>> actually builds the library the error makes sense; cabal is looking
>> for the shared library before we've built it.
>>
>> To get around this I modified the offending line, thus:
>> > let all_dlls   = parseDLLs ["x-dll-extra-libraries"] custom_bi
>>
>> With that modification cabal would now get to myBuildHook, but then
>> another curious error arose:
>> We see that the actual linking is called here:
>> > runProgram verbose gcc (opts' ++ objs' ++ lib_dirs' ++ libs')
>>
>> But on hitting that line the following error is spat out:
>> /usr/bin/ld: cannot open output file  dist/build/libwxc.so.0.13.1: No
>> such file or directory
>
>
> Windows doesn't behave this way - this part worked for me as well.
>
>>
>> I checked all my permissions and couldn't see anything wrong, I could
>> touch the file.
>> Conveniently I noticed that, if the verbosity is set high enough,
>> runProgram will call printRawCommandAndArgs:
>>
>> http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-Utils.html#printRawCommandAndArgs
>>
>> The output (i.e. the linker invocation) looks like this:
>> /usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o
>> dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o
>> dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o
>> [snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9
>> [snip-rest-of-wx-libs]
>>
>> Now if I cd into the wxcore and paste the command *verbatim* then gcc
>> works and generates libwxc.so.0.13.1 as expected.
>> You can see in Jeremy's code the linkShareLib function contains:
>> > cwd <- getCurrentDirectory
>>
>> I used this to confirm that the we were in ./wxcore and we are, even
>> making the path for -o absolute didn't sovle the issue.
>> I ended up replacing runProgram line with this, less satisfactory line:
>> > system $ (unwords ([show . locationPath . programLocation $ gcc] ++
>> > opts' ++ objs' ++ lib_dirs' ++ libs'))
>>
>> Which works, but still doesn't explain why runProgram doesn't.
>> Any suggestions?
>
>
> I've tried this on Linux. You're absolutely right and I'm stumped as to why.
> I think we should pull this specific part of the thread out and post to the
> Haskell list. Maybe someone who knows Cabal and/or GHC would have an idea
> why this is the case.

Ah, good to know it works on Windows.
I'll try and replicate it in isolation and send a mail to the cabal list.

>
>>
>> So with that complete I was able to link a shared library to:
>> wxcore/dist/build/libwxc.so.0.13.1
>>
>> Of course, at this point we've generated the shared library, but
>> wxcore still isn't aware of it, so the build completes successfully,
>> but any attempt to compile against it results (understandably) in
>> hundreds of linker errors.
>> To resolve this I had to add "x-dll-name" (read in from wxcore.cabal
>> as "wxc") back to parseDLLs:
>> > let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"]
>> > custom_bi
>>
>> Well, not quite, attempt to build wxcore again and we're back to this
>> error:
>> * Missing C library: wxc
>>
>> Of course, the .so isn't in a 'normal' place, so add its location as
>> an extra lib directory:
>> > { extraLibDirs = extraLibDirs libbi ++ extraLibDirs wx ++
>> > ["/full/path/to/wxcore/dist/build"]
>> (note: I tried using just "dist/build", but cabal said: "library-dirs:
>> dist/build is a relative path")
>
>
> I think we need a more robust solution in the longer run, as
> <wxhaskell>/wcore/dirt/build is really a temporary location.

I guess the 'correct' solution would be to 'install' the library to
somewhere like LD_LIBRARY_PATH in Linux.
Again I don't know how this fits in with Windows.

It's also a pain for people developing wxhaskell, because as I
mentioned before, you'd have to 'install' a potentially unstable,
development version of the shared library in order to be able to
reference it.

>
>>
>> This still isn't quite enough, it took one more kludge:
>> /full/path/to/wxcore/dist/build/$ ln -s
>> /full/path/to/wxcore/dist/build/libwxc.so.0.13.1 libwxc.so
>
>
> Earlier you mentioned that, at least on Linux, the build command is:
>
>
> /usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o
> dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o
> dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o
> [snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9
> [snip-rest-of-wx-libs]
>
> I know GCC generated this and not you, but it looks like the root of the
> issue. I am slightly confused though. ld.so is supposed to *know* that
> libwxc.so.0.13.1 is a valid instance of libwxc.so.0

Firstly, I'm a little confused by your statement "GCC generated this
and not you", that build command is generated by linkCxxOpts, not GCC?

This is curious: The name of the symlink has to be "libwxc.so", not
even "libwxc.so.0".
I think this makes sense though, the only "information" the simple
build system gets about the dependency is the parsing of this line in
wxcore.cabal by parseDLLs:
  x-dll-name: wxc

I assume that the "wxc" is some how turned in to "libwxc.so", I'd like
to know how, and if it is possible to specify the major revision of a
shared library passed; this would have to be some convention in the
naming, because extraLibs is just [String]:
http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/Distribution-PackageDescription.html#v:extraLibs

>
> In normal Linux-land, you run /sbin/ldconfig after installing a new library,
> and it creates these symlinks automatically You could do this by executing
> something like (not tested)
>
> /sbin/ldconfig -n <path-to-directory>

Thanks for the tip, that makes more sense.
I can now see that the symlink which "ldconfig -n" generates is
extracted from the -soname given at link time.
So, by modifying the -soname to *not* specify the major revision, i.e:
This:
>    "-Wl,-soname,lib" ++ basename ++ ".so",
Instead of this:
>    "-Wl,-soname,lib" ++ basename ++ ".so" ++ maj_ver,

I can now use "ldconfig -n" in dist/build/ to create the symlink (to
libwxc.so), instead of doing it by hand, I suppose this is a little
less broken.

>
>> I'd like to think there's a more elegant solution than this and I'm
>> open to suggestions.
>> I should note that at this point I became aware that we could have an
>> entirely separate cabal project (perhaps "wxc") for this shared
>> library, and then have wxcore depend on it?
>>
>> Running one more time I *thought* I was finally there, until I noticed
>> this line, hidden in cabal's output:
>> /full/path/to/wxcore/dist/build/libwxc.so: file not recognized: File
>> truncated
>>
>> As far as I can tell, this occurs because we now load(?)
>> "libwxc.so.0.13.1" in myConfHook, but then in myBuildHook we want to
>> use it as the destination for the linker. Worse still it seems that
>> 'truncated' actually means 'deleted'. To get around this I had to one
>> again remove "x-dll-name" from the parseDLLs call (so I could get to
>> myBuildHook and create "libwxc.so.0.13.1" again), build wxcore, then
>> add "x-dll-name" back again, but this time also comment out the call
>> to linkSharedLib (and so stop cabal attempting to open
>> "libwxc.so.0.13.1") before building wxcore one last time.
>>
>> Finally everything seemed to work.
>>
>> Now, I should note that I have been using cabal-dev, and so I now have
>> a package-conf I need to reference when building with my new shared
>> library wxhaskell. To test it I built the wxhaskell HelloWorld sample
>> thus:
>> /full/path/to/samples/wxcore$ ghc --make -package-conf
>> ../../cabal-dev/packages-7.0.3.conf HelloWorld.hs
>>
>> It worked, but then when I try to run HelloWorld I get:
>> ./HelloWorld: error while loading shared libraries: libwxc.so.0:
>> cannot open shared object file: No such file or directory
>>
>> Okay, again, libwxc.so.0 isn't in a 'normal' place, so I kludged it
>> with another symlink:
>> /full/path/to/samples/wxcore$ ln -s
>> /full/path/to/wxcore/dist/build/libwxc.so libwxc.so.0
>>
>> And now, I can report that HelloWorld runs.
>> [imagine a screen shot of the HelloWorld sample application running here]
>> Rejoice.
>>
>> But wait, there's more:
>> One of the promises of the shared library approach is that we'd all be
>> able to use wxhaskell with ghci again, and to my utter disbelief, it's
>> true:
>> /full/path/to/samples/wxcore$ ghci -package-conf
>> ../../cabal-dev/packages-7.0.3.conf HelloWorld.hs
>> Ok, modules loaded: Main.
>> Prelude Main> main
>>
>> [imagine a screen shot of the HelloWorld sample application running here]
>> Double rejoice.
>>
>>
>>
>> >
>> > Dave,
>>
>>
>> ------------------------------------------------------------------------------
>> Cloud Services Checklist: Pricing and Packaging Optimization
>> This white paper is intended to serve as a reference, checklist and point
>> of
>> discussion for anyone considering optimizing the pricing and packaging
>> model
>> of a cloud services business. Read Now!
>> http://www.accelacomm.com/jaw/sfnl/114/51491232/
>> _______________________________________________
>> 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

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

Hi Dave, all,

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

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

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

On 9 December 2011 14:13, Dave Tapley <duk...@gm...> wrote:

> On 8 December 2011 22:34, Dave Tapley <duk...@gm...> wrote:
> > Hello everyone,
> >
> > I wrote a story, and I invite you all to comment and help me make it
> better.
> > As an experiment I've decided to put it on hpaste instead of having
> > the mail thread get out of hand (I'm also cross posting it to the
> > cabal list and have mentioned it in #haskell, and I want to keep all
> > correspondence in one place):
> > http://hpaste.org/55027
>
> Ha, well that was good timing for hpaste to go down!
> Here's it is:
>
> I've been trying to resurrect the idea of building a shared library
> for the C++ component of the wxhaskell library.
>
> Jeremy (to my knowledge) first put this forward, here:
>
> http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/
>
> In addition to the advantages he lists there, I have the following reason:
> When building wx-core (in its current incarnation) cabal will *always*
> rebuild all the C++ code, which takes a majority of the build time.
> This becomes very frustrating when you change one line of Haskell and
> have to wait seven minutes to rebuild.
> I complained about it here:
> http://sourceforge.net/mailarchive/message.php?msg_id=28099997
>
> So, I decided to try and stop this complete C++ rebuild, I partially
> succeed, but I eventually got stuck for reasons I complained here:
> http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html
>
> Side note: I did eventually discover why (or, where) the c-sources
> (cSources) list is used to compile and link, and it is here:
>
> http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib
> You can see:
> "| filename <- cSources libBi]" under "-- build any C sources", and
> you can see:
> "cSharedObjs = map (`replaceExtension` ("dyn_" ++ objExtension))
> (cSources libBi)"
> under "-- link:".
> Is this assumption correct?
>

This is correct - it's the standard way Cabal builds C/C++ code. To be
honest, this is really a consequence of the fact that Cabal is more of a
tool for simple distribution than a Make replacement, and the developers
probably didn't expect Cabal would be used to build large bodies of C++
code.

My approach is far from perfect, too - in fact it is incorrect because I
don't do dependency tracking on header files, so if you edit a header, it
(incorrectly) fails to rebuild. This is because I wasn't keen on rewriting
'make' in the wxHaskell build system - it seems to me like something Cabal
could usefully support. I did play with some very hacky code which
automatically rebuilt all of the C++ code if any header is newer than any
C++ source. This is aesthetically dreadful, but it somewhat captures the
reality, since in practice, pretty much all of the C++ files depend on all
of the headers (and it's easy to write).

On reflection, we should probably do this as what exists at present could
lead to unexpectedly incorrect code being generated if someone is in full
flow of development. I'll see if I can dig up some code - I think I have it
somewhere.

At this point I thought about either:
> 1. Getting the cabal source and starting to write code to give
> BuildInfo a "cObjs" in addition to "cSources".
> 2. Picking up Jeremy's shared library code, so wxhaskell would have
> its own code to build the library, in which I could do sensible
> re-compilation.
>
> Given that there were other advantages to 2, I went with that.
>
> Jeremy had written one blog post on building a such a shared library, here:
>
> http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
> In response to an email on the wxhaskell-devel list he also kindly put
> up this gist, with the code he'd been working on:
> https://gist.github.com/1301115
>
> I dutifully took this gist, and have now attempted to integrate in to
> my wxhaskell-dev branch, which you can find here:
> http://darcsden.com/DukeDave/wxhaskell-dev
> (note: I haven't pushed any of the shared library code to darcsden
> yet, for reasons I'm about to explain)
>
> This is where things got interesting, after a few hours of hacking I
> have built a shared library, but in this very back-handed way:
>
> Firstly, in Jeremy's code the to-be-compiled shared library is added
> to the wxcore BuildInfo through a custom hook.
> We can see this because:
> > let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"]
> custom_bi
> (the modified wxcore.cabal contains the line: "x-dll-name: wxc")
>
> However on a clean build of wxcore we get the following error:
>
> setup: Missing dependency on a foreign library:
> * Missing C library: wxc
> This problem can usually be solved by installing the system package that
> provides this library (you may need the "-dev" version). If the library is
> already installed but in a non-standard location then you can use the flags
> --extra-include-dirs= and --extra-lib-dirs= to specify where it is.
>

My code worked for Windows - but this is a better cross-platform solution.


> The error is dumped *before* cabal calls myBuildHook, and since this
> actually builds the library the error makes sense; cabal is looking
> for the shared library before we've built it.
>
> To get around this I modified the offending line, thus:
> > let all_dlls   = parseDLLs ["x-dll-extra-libraries"] custom_bi
>
> With that modification cabal would now get to myBuildHook, but then
> another curious error arose:
> We see that the actual linking is called here:
> > runProgram verbose gcc (opts' ++ objs' ++ lib_dirs' ++ libs')
>
> But on hitting that line the following error is spat out:
> /usr/bin/ld: cannot open output file  dist/build/libwxc.so.0.13.1: No
> such file or directory
>

Windows doesn't behave this way - this part worked for me as well.


> I checked all my permissions and couldn't see anything wrong, I could
> touch the file.
> Conveniently I noticed that, if the verbosity is set high enough,
> runProgram will call printRawCommandAndArgs:
>
> http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-Utils.html#printRawCommandAndArgs
>
> The output (i.e. the linker invocation) looks like this:
> /usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o
> dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o
> dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o
> [snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9
> [snip-rest-of-wx-libs]
>
> Now if I cd into the wxcore and paste the command *verbatim* then gcc
> works and generates libwxc.so.0.13.1 as expected.
> You can see in Jeremy's code the linkShareLib function contains:
> > cwd <- getCurrentDirectory
>
> I used this to confirm that the we were in ./wxcore and we are, even
> making the path for -o absolute didn't sovle the issue.
> I ended up replacing runProgram line with this, less satisfactory line:
> > system $ (unwords ([show . locationPath . programLocation $ gcc] ++
> opts' ++ objs' ++ lib_dirs' ++ libs'))
>
> Which works, but still doesn't explain why runProgram doesn't.
> Any suggestions?
>

I've tried this on Linux. You're absolutely right and I'm stumped as to
why. I think we should pull this specific part of the thread out and post
to the Haskell list. Maybe someone who knows Cabal and/or GHC would have an
idea why this is the case.


> So with that complete I was able to link a shared library to:
> wxcore/dist/build/libwxc.so.0.13.1
>
> Of course, at this point we've generated the shared library, but
> wxcore still isn't aware of it, so the build completes successfully,
> but any attempt to compile against it results (understandably) in
> hundreds of linker errors.
> To resolve this I had to add "x-dll-name" (read in from wxcore.cabal
> as "wxc") back to parseDLLs:
> > let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"]
> custom_bi
>
> Well, not quite, attempt to build wxcore again and we're back to this
> error:
> * Missing C library: wxc
>
> Of course, the .so isn't in a 'normal' place, so add its location as
> an extra lib directory:
> > { extraLibDirs = extraLibDirs libbi ++ extraLibDirs wx ++
> ["/full/path/to/wxcore/dist/build"]
> (note: I tried using just "dist/build", but cabal said: "library-dirs:
> dist/build is a relative path")
>

I think we need a more robust solution in the longer run, as
<wxhaskell>/wcore/dirt/build is really a temporary location.


> This still isn't quite enough, it took one more kludge:
> /full/path/to/wxcore/dist/build/$ ln -s
> /full/path/to/wxcore/dist/build/libwxc.so.0.13.1 libwxc.so
>

Earlier you mentioned that, at least on Linux, the build command is:

/usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o
 dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o
dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o
[snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9
[snip-rest-of-wx-libs]

I know GCC generated this and not you, but it looks like the root of the
issue. I am slightly confused though. ld.so is supposed to *know* that
libwxc.so.0.13.1 is a valid instance of libwxc.so.0

In normal Linux-land, you run /sbin/ldconfig after installing a new
library, and it creates these symlinks automatically You could do this by
executing something like (not tested)

/sbin/ldconfig -n <path-to-directory>

I'd like to think there's a more elegant solution than this and I'm
> open to suggestions.
> I should note that at this point I became aware that we could have an
> entirely separate cabal project (perhaps "wxc") for this shared
> library, and then have wxcore depend on it?
>
> Running one more time I *thought* I was finally there, until I noticed
> this line, hidden in cabal's output:
> /full/path/to/wxcore/dist/build/libwxc.so: file not recognized: File
> truncated
>
> As far as I can tell, this occurs because we now load(?)
> "libwxc.so.0.13.1" in myConfHook, but then in myBuildHook we want to
> use it as the destination for the linker. Worse still it seems that
> 'truncated' actually means 'deleted'. To get around this I had to one
> again remove "x-dll-name" from the parseDLLs call (so I could get to
> myBuildHook and create "libwxc.so.0.13.1" again), build wxcore, then
> add "x-dll-name" back again, but this time also comment out the call
> to linkSharedLib (and so stop cabal attempting to open
> "libwxc.so.0.13.1") before building wxcore one last time.
>
> Finally everything seemed to work.
>
> Now, I should note that I have been using cabal-dev, and so I now have
> a package-conf I need to reference when building with my new shared
> library wxhaskell. To test it I built the wxhaskell HelloWorld sample
> thus:
> /full/path/to/samples/wxcore$ ghc --make -package-conf
> ../../cabal-dev/packages-7.0.3.conf HelloWorld.hs
>
> It worked, but then when I try to run HelloWorld I get:
> ./HelloWorld: error while loading shared libraries: libwxc.so.0:
> cannot open shared object file: No such file or directory
>
> Okay, again, libwxc.so.0 isn't in a 'normal' place, so I kludged it
> with another symlink:
> /full/path/to/samples/wxcore$ ln -s
> /full/path/to/wxcore/dist/build/libwxc.so libwxc.so.0
>
> And now, I can report that HelloWorld runs.
> [imagine a screen shot of the HelloWorld sample application running here]
> Rejoice.
>
> But wait, there's more:
> One of the promises of the shared library approach is that we'd all be
> able to use wxhaskell with ghci again, and to my utter disbelief, it's
> true:
> /full/path/to/samples/wxcore$ ghci -package-conf
> ../../cabal-dev/packages-7.0.3.conf HelloWorld.hs
> Ok, modules loaded: Main.
> Prelude Main> main
>
> [imagine a screen shot of the HelloWorld sample application running here]
> Double rejoice.
>
>
>
> >
> > Dave,
>
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point
> of
> discussion for anyone considering optimizing the pricing and packaging
> model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> 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 8 December 2011 22:34, Dave Tapley <duk...@gm...> wrote:
> Hello everyone,
>
> I wrote a story, and I invite you all to comment and help me make it better.
> As an experiment I've decided to put it on hpaste instead of having
> the mail thread get out of hand (I'm also cross posting it to the
> cabal list and have mentioned it in #haskell, and I want to keep all
> correspondence in one place):
> http://hpaste.org/55027

Ha, well that was good timing for hpaste to go down!
Here's it is:

I've been trying to resurrect the idea of building a shared library
for the C++ component of the wxhaskell library.

Jeremy (to my knowledge) first put this forward, here:
http://wewantarock.wordpress.com/2010/11/01/working-around-the-static-libstdc-restriction/

In addition to the advantages he lists there, I have the following reason:
When building wx-core (in its current incarnation) cabal will *always*
rebuild all the C++ code, which takes a majority of the build time.
This becomes very frustrating when you change one line of Haskell and
have to wait seven minutes to rebuild.
I complained about it here:
http://sourceforge.net/mailarchive/message.php?msg_id=28099997

So, I decided to try and stop this complete C++ rebuild, I partially
succeed, but I eventually got stuck for reasons I complained here:
http://www.haskell.org/pipermail/cabal-devel/2011-October/007816.html

Side note: I did eventually discover why (or, where) the c-sources
(cSources) list is used to compile and link, and it is here:
http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-GHC.html#buildLib
You can see:
"| filename <- cSources libBi]" under "-- build any C sources", and
you can see:
"cSharedObjs = map (`replaceExtension` ("dyn_" ++ objExtension))
(cSources libBi)"
under "-- link:".
Is this assumption correct?

At this point I thought about either:
1. Getting the cabal source and starting to write code to give
BuildInfo a "cObjs" in addition to "cSources".
2. Picking up Jeremy's shared library code, so wxhaskell would have
its own code to build the library, in which I could do sensible
re-compilation.

Given that there were other advantages to 2, I went with that.

Jeremy had written one blog post on building a such a shared library, here:
http://wewantarock.wordpress.com/2010/11/03/building-a-shared-library-in-cabal/
In response to an email on the wxhaskell-devel list he also kindly put
up this gist, with the code he'd been working on:
https://gist.github.com/1301115

I dutifully took this gist, and have now attempted to integrate in to
my wxhaskell-dev branch, which you can find here:
http://darcsden.com/DukeDave/wxhaskell-dev
(note: I haven't pushed any of the shared library code to darcsden
yet, for reasons I'm about to explain)

This is where things got interesting, after a few hours of hacking I
have built a shared library, but in this very back-handed way:

Firstly, in Jeremy's code the to-be-compiled shared library is added
to the wxcore BuildInfo through a custom hook.
We can see this because:
> let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"] custom_bi
(the modified wxcore.cabal contains the line: "x-dll-name: wxc")

However on a clean build of wxcore we get the following error:

setup: Missing dependency on a foreign library:
* Missing C library: wxc
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.

The error is dumped *before* cabal calls myBuildHook, and since this
actually builds the library the error makes sense; cabal is looking
for the shared library before we've built it.

To get around this I modified the offending line, thus:
> let all_dlls   = parseDLLs ["x-dll-extra-libraries"] custom_bi

With that modification cabal would now get to myBuildHook, but then
another curious error arose:
We see that the actual linking is called here:
> runProgram verbose gcc (opts' ++ objs' ++ lib_dirs' ++ libs')

But on hitting that line the following error is spat out:
/usr/bin/ld: cannot open output file  dist/build/libwxc.so.0.13.1: No
such file or directory

I checked all my permissions and couldn't see anything wrong, I could
touch the file.
Conveniently I noticed that, if the verbosity is set high enough,
runProgram will call printRawCommandAndArgs:
http://hackage.haskell.org/packages/archive/Cabal/latest/doc/html/src/Distribution-Simple-Utils.html#printRawCommandAndArgs

The output (i.e. the linker invocation) looks like this:
/usr/bin/gcc -fno-stack-protector -shared -Wl,-soname,libwxc.so.0 -o
dist/build/libwxc.so.0.13.1 dist/build/src/cpp/apppath.o
dist/build/src/cpp/dragimage.o dist/build/src/cpp/eljaccelerator.o
[snip-rest-of-.o-files] -L/usr/local/lib -lstdc++ -lwx_baseu-2.9
[snip-rest-of-wx-libs]

Now if I cd into the wxcore and paste the command *verbatim* then gcc
works and generates libwxc.so.0.13.1 as expected.
You can see in Jeremy's code the linkShareLib function contains:
> cwd <- getCurrentDirectory

I used this to confirm that the we were in ./wxcore and we are, even
making the path for -o absolute didn't sovle the issue.
I ended up replacing runProgram line with this, less satisfactory line:
> system $ (unwords ([show . locationPath . programLocation $ gcc] ++ opts' ++ objs' ++ lib_dirs' ++ libs'))

Which works, but still doesn't explain why runProgram doesn't.
Any suggestions?

So with that complete I was able to link a shared library to:
wxcore/dist/build/libwxc.so.0.13.1

Of course, at this point we've generated the shared library, but
wxcore still isn't aware of it, so the build completes successfully,
but any attempt to compile against it results (understandably) in
hundreds of linker errors.
To resolve this I had to add "x-dll-name" (read in from wxcore.cabal
as "wxc") back to parseDLLs:
> let all_dlls   = parseDLLs ["x-dll-name", "x-dll-extra-libraries"] custom_bi

Well, not quite, attempt to build wxcore again and we're back to this error:
* Missing C library: wxc

Of course, the .so isn't in a 'normal' place, so add its location as
an extra lib directory:
> { extraLibDirs = extraLibDirs libbi ++ extraLibDirs wx ++ ["/full/path/to/wxcore/dist/build"]
(note: I tried using just "dist/build", but cabal said: "library-dirs:
dist/build is a relative path")

This still isn't quite enough, it took one more kludge:
/full/path/to/wxcore/dist/build/$ ln -s
/full/path/to/wxcore/dist/build/libwxc.so.0.13.1 libwxc.so

I'd like to think there's a more elegant solution than this and I'm
open to suggestions.
I should note that at this point I became aware that we could have an
entirely separate cabal project (perhaps "wxc") for this shared
library, and then have wxcore depend on it?

Running one more time I *thought* I was finally there, until I noticed
this line, hidden in cabal's output:
/full/path/to/wxcore/dist/build/libwxc.so: file not recognized: File truncated

As far as I can tell, this occurs because we now load(?)
"libwxc.so.0.13.1" in myConfHook, but then in myBuildHook we want to
use it as the destination for the linker. Worse still it seems that
'truncated' actually means 'deleted'. To get around this I had to one
again remove "x-dll-name" from the parseDLLs call (so I could get to
myBuildHook and create "libwxc.so.0.13.1" again), build wxcore, then
add "x-dll-name" back again, but this time also comment out the call
to linkSharedLib (and so stop cabal attempting to open
"libwxc.so.0.13.1") before building wxcore one last time.

Finally everything seemed to work.

Now, I should note that I have been using cabal-dev, and so I now have
a package-conf I need to reference when building with my new shared
library wxhaskell. To test it I built the wxhaskell HelloWorld sample
thus:
/full/path/to/samples/wxcore$ ghc --make -package-conf
../../cabal-dev/packages-7.0.3.conf HelloWorld.hs

It worked, but then when I try to run HelloWorld I get:
./HelloWorld: error while loading shared libraries: libwxc.so.0:
cannot open shared object file: No such file or directory

Okay, again, libwxc.so.0 isn't in a 'normal' place, so I kludged it
with another symlink:
/full/path/to/samples/wxcore$ ln -s
/full/path/to/wxcore/dist/build/libwxc.so libwxc.so.0

And now, I can report that HelloWorld runs.
[imagine a screen shot of the HelloWorld sample application running here]
Rejoice.

But wait, there's more:
One of the promises of the shared library approach is that we'd all be
able to use wxhaskell with ghci again, and to my utter disbelief, it's
true:
/full/path/to/samples/wxcore$ ghci -package-conf
../../cabal-dev/packages-7.0.3.conf HelloWorld.hs
Ok, modules loaded: Main.
Prelude Main> main

[imagine a screen shot of the HelloWorld sample application running here]
Double rejoice.



>
> Dave,

Re: [wxhaskell-devel] [wxhaskell-users] adapt layout after changing 'visible' state

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

I'd go ahead and record/send that.

Thanks! This sort of distributed doc effort helps :-)

On 8 Dec 2011, at 18:49, Henning Thielemann wrote:
> Here is my proposed patch:
> 
> wxhaskell/wx$ darcs2 diff --unified src/Graphics/UI/WX/Classes.hs
> --- old-wxhaskell/wx/src/Graphics/UI/WX/Classes.hs      2011-12-08 19:45:56.000000000 +0100
> +++ new-wxhaskell/wx/src/Graphics/UI/WX/Classes.hs      2011-12-08 19:45:56.000000000 +0100
> @@ -173,6 +173,19 @@
>  -- | Visible widgets.
>  class Visible w where
>    -- | Is the widget visible?
> +  --
> +  -- If you hide a widget, its space will not immediately
> +  -- be filled by other widgets.
> +  -- Vice versa if you make a widget visible
> +  -- it will not have space to be rendered into.
> +  -- That is, when changing the visibility state
> +  -- it is advised to update the layout
> +  -- using 'Graphics.UI.WX.Layout.windowReFit'.
> +  --
> +  -- Example:
> +  --
> +  -- > do set w [ visible := False ]
> +  -- >    windowReFit w



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

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

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

Hello everyone,

I wrote a story, and I invite you all to comment and help me make it better.
As an experiment I've decided to put it on hpaste instead of having
the mail thread get out of hand (I'm also cross posting it to the
cabal list and have mentioned it in #haskell, and I want to keep all
correspondence in one place):
http://hpaste.org/55027

Dave,

Re: [wxhaskell-devel] [wxhaskell-users] adapt layout after changing 'visible' state

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

On Thu, 8 Dec 2011, Henning Thielemann wrote:

> I think the best place for documenting the solution is not the FAQ but the 
> documentation of the Visible class.

Here is my proposed patch:

wxhaskell/wx$ darcs2 diff --unified src/Graphics/UI/WX/Classes.hs
--- old-wxhaskell/wx/src/Graphics/UI/WX/Classes.hs      2011-12-08 19:45:56.000000000 +0100
+++ new-wxhaskell/wx/src/Graphics/UI/WX/Classes.hs      2011-12-08 19:45:56.000000000 +0100
@@ -173,6 +173,19 @@
  -- | Visible widgets.
  class Visible w where
    -- | Is the widget visible?
+  --
+  -- If you hide a widget, its space will not immediately
+  -- be filled by other widgets.
+  -- Vice versa if you make a widget visible
+  -- it will not have space to be rendered into.
+  -- That is, when changing the visibility state
+  -- it is advised to update the layout
+  -- using 'Graphics.UI.WX.Layout.windowReFit'.
+  --
+  -- Example:
+  --
+  -- > do set w [ visible := False ]
+  -- >    windowReFit w
    visible    :: Attr w Bool
    -- | Refresh the widget explicitly.
    refresh    :: w -> IO ()

Re: [wxhaskell-devel] liberal commit access?

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

Maciek, Alessandro, and anyone worried about the future.

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

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

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

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

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

Best regards
Jeremy

On 28 November 2011 21:41, <mac...@gm...> wrote:

> Last time I tried I wasn't able to get wx 2.8 to build on Windows.
> After spending a day trying to sort out gcc running out of memory and
> issues with Unicode support I resorted to wxPack. If not for wxPack I
> would have probably given up on using wxHaskell altogether. I'm sure
> it was possible to build it somehow, but I was not prepared to invest
> massive amount of time just to be able to use a GUI library.
>
> Maciek
>
> On Mon, Nov 28, 2011 at 6:24 PM, Alessandro Vermeulen
> <a.v...@st...> wrote:
> >>  I fear that the majority of Windows
> >> users will be stuck with wxHaskell versions that work with 2.8.
> > Well, you can always bundle the wx libraries with your application in
> that
> > case and create your own wxPack. :-)
> >
> > - Alessandro
> > On 28 nov. 2011, at 19:09, Maciek Makowski wrote:
> >
> >> I don't have a strong opinion on which version of wx should be
> >> supported by wxHaskell, as long as there is at least one that works on
> >> Windows without the need to compile wxWidgets from source. Until there
> >> is a wxPack available for 2.9 I fear that the majority of Windows
> >> users will be stuck with wxHaskell versions that work with 2.8.
> >>
> >> That aside, focusing on supporting a single version of wxWidgets
> >> sounds like a reasonable thing to do.
> >>
> >> Maciek
> >>
> >> On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley <duk...@gm...>
> wrote:
> >>> On 28 November 2011 11:37, Jeremy O'Donoghue <
> jer...@gm...> wrote:
> >>>> On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:
> >>>>>
> >>>>> Not surprisingly, I am in favour of this :)
> >>>>
> >>>> I have spent a while thinking about this, as it has considerable
> >>>> ramifications.
> >>>>
> >>>> I don't think we have ever seen a case of an irresponsible committer
> (could
> >>>> such a thing even exist in the Haskell community?), so I'm in favour.
> >>>>
> >>>>>
> >>>>> Given that there aren't going to be any more 2.8.x releases of
> >>>>> wxWidgets, I'm happy to say:
> >>>>> If you want a stable(ish) wxHaskell, then use the current hackage
> >>>>> release along with the last stable wxWidgets release (2.8.12).
> >>>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
> >>>>> along with the latest dev wxWidgets release (currently 2.9.2).
> >>>>>
> >>>>> I should note one more time that I'm quite happy to stop supporting
> >>>>> pre 2.9.x support now, I don't know if anyone has any objection to
> >>>>> this?
> >>>>
> >>>> The caveat is that I would like to do one more release on Hackage
> >>>> supporting  2.8.x, as we have a number of valuable bugfixes in the
> devel
> >>>> branches which would benefit users of 2.8.x. I will try to do this
> over then
> >>>> next two weeks, so my proposal is...
> >>>>
> >>>> Patches committed until the end of 2011 should be verified on a
> wxWidgets
> >>>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
> >>>> version number from 0.13.x to 0.14.x.
> >>>>
> >>>> How does this sound?
> >>>
> >>> Well it's the most sensible new year's resolution I've heard thus far
> :)
> >>>
> >>> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
> >>> which I'm aiming to get all the patches which are sent out on the
> >>> mailing list as well.
> >>>
> >>> Dave,
> >>>
> >>>>
> >>>> Jeremy
> >>>>
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> All the data continuously generated in your IT infrastructure
> >>> contains a definitive record of customers, application performance,
> >>> security threats, fraudulent activity, and more. Splunk takes this
> >>> data and makes sense of it. IT sense. And common sense.
> >>> http://p.sf.net/sfu/splunk-novd2d
> >>> _______________________________________________
> >>> wxhaskell-devel mailing list
> >>> wxh...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure
> >> contains a definitive record of customers, application performance,
> >> security threats, fraudulent activity, and more. Splunk takes this
> >> data and makes sense of it. IT sense. And common sense.
> >> http://p.sf.net/sfu/splunk-novd2d
> >> _______________________________________________
> >> wxhaskell-devel mailing list
> >> wxh...@li...
> >> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
> >
> >
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

Re: [wxhaskell-devel] liberal commit access?

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

Last time I tried I wasn't able to get wx 2.8 to build on Windows.
After spending a day trying to sort out gcc running out of memory and
issues with Unicode support I resorted to wxPack. If not for wxPack I
would have probably given up on using wxHaskell altogether. I'm sure
it was possible to build it somehow, but I was not prepared to invest
massive amount of time just to be able to use a GUI library.

Maciek

On Mon, Nov 28, 2011 at 6:24 PM, Alessandro Vermeulen
<a.v...@st...> wrote:
>>  I fear that the majority of Windows
>> users will be stuck with wxHaskell versions that work with 2.8.
> Well, you can always bundle the wx libraries with your application in that
> case and create your own wxPack. :-)
>
> - Alessandro
> On 28 nov. 2011, at 19:09, Maciek Makowski wrote:
>
>> I don't have a strong opinion on which version of wx should be
>> supported by wxHaskell, as long as there is at least one that works on
>> Windows without the need to compile wxWidgets from source. Until there
>> is a wxPack available for 2.9 I fear that the majority of Windows
>> users will be stuck with wxHaskell versions that work with 2.8.
>>
>> That aside, focusing on supporting a single version of wxWidgets
>> sounds like a reasonable thing to do.
>>
>> Maciek
>>
>> On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley <duk...@gm...> wrote:
>>> On 28 November 2011 11:37, Jeremy O'Donoghue <jer...@gm...> wrote:
>>>> On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:
>>>>>
>>>>> Not surprisingly, I am in favour of this :)
>>>>
>>>> I have spent a while thinking about this, as it has considerable
>>>> ramifications.
>>>>
>>>> I don't think we have ever seen a case of an irresponsible committer (could
>>>> such a thing even exist in the Haskell community?), so I'm in favour.
>>>>
>>>>>
>>>>> Given that there aren't going to be any more 2.8.x releases of
>>>>> wxWidgets, I'm happy to say:
>>>>> If you want a stable(ish) wxHaskell, then use the current hackage
>>>>> release along with the last stable wxWidgets release (2.8.12).
>>>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>>>>> along with the latest dev wxWidgets release (currently 2.9.2).
>>>>>
>>>>> I should note one more time that I'm quite happy to stop supporting
>>>>> pre 2.9.x support now, I don't know if anyone has any objection to
>>>>> this?
>>>>
>>>> The caveat is that I would like to do one more release on Hackage
>>>> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
>>>> branches which would benefit users of 2.8.x. I will try to do this over then
>>>> next two weeks, so my proposal is...
>>>>
>>>> Patches committed until the end of 2011 should be verified on a wxWidgets
>>>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
>>>> version number from 0.13.x to 0.14.x.
>>>>
>>>> How does this sound?
>>>
>>> Well it's the most sensible new year's resolution I've heard thus far :)
>>>
>>> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
>>> which I'm aiming to get all the patches which are sent out on the
>>> mailing list as well.
>>>
>>> Dave,
>>>
>>>>
>>>> Jeremy
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>> _______________________________________________
>>> wxhaskell-devel mailing list
>>> wxh...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

[wxhaskell-devel] targeting wxWidgets 3.0

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

On 28 Nov 2011, at 18:09, Maciek Makowski wrote:

> I don't have a strong opinion on which version of wx should be
> supported by wxHaskell, as long as there is at least one that works on
> Windows without the need to compile wxWidgets from source. Until there
> is a wxPack available for 2.9 I fear that the majority of Windows
> users will be stuck with wxHaskell versions that work with 2.8.


Probably not an issue as the proposal would only affect devel versions of wxHaskell
(as I understand it)

As a general principle, I guess hackage versions should always support the stable
versions of the underlying wxWidgets.  This means making sure we've got 2.8 support
until 3.0 comes out, and also making sure we can cope with the 3.0 release

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

Re: [wxhaskell-devel] liberal commit access?

[Alessandro V. <a.v...@st...>]

>  I fear that the majority of Windows
> users will be stuck with wxHaskell versions that work with 2.8.
Well, you can always bundle the wx libraries with your application in that
case and create your own wxPack. :-)

- Alessandro
On 28 nov. 2011, at 19:09, Maciek Makowski wrote:

> I don't have a strong opinion on which version of wx should be
> supported by wxHaskell, as long as there is at least one that works on
> Windows without the need to compile wxWidgets from source. Until there
> is a wxPack available for 2.9 I fear that the majority of Windows
> users will be stuck with wxHaskell versions that work with 2.8.
> 
> That aside, focusing on supporting a single version of wxWidgets
> sounds like a reasonable thing to do.
> 
> Maciek
> 
> On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley <duk...@gm...> wrote:
>> On 28 November 2011 11:37, Jeremy O'Donoghue <jer...@gm...> wrote:
>>> On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:
>>>> 
>>>> Not surprisingly, I am in favour of this :)
>>> 
>>> I have spent a while thinking about this, as it has considerable
>>> ramifications.
>>> 
>>> I don't think we have ever seen a case of an irresponsible committer (could
>>> such a thing even exist in the Haskell community?), so I'm in favour.
>>> 
>>>> 
>>>> Given that there aren't going to be any more 2.8.x releases of
>>>> wxWidgets, I'm happy to say:
>>>> If you want a stable(ish) wxHaskell, then use the current hackage
>>>> release along with the last stable wxWidgets release (2.8.12).
>>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>>>> along with the latest dev wxWidgets release (currently 2.9.2).
>>>> 
>>>> I should note one more time that I'm quite happy to stop supporting
>>>> pre 2.9.x support now, I don't know if anyone has any objection to
>>>> this?
>>> 
>>> The caveat is that I would like to do one more release on Hackage
>>> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
>>> branches which would benefit users of 2.8.x. I will try to do this over then
>>> next two weeks, so my proposal is...
>>> 
>>> Patches committed until the end of 2011 should be verified on a wxWidgets
>>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
>>> version number from 0.13.x to 0.14.x.
>>> 
>>> How does this sound?
>> 
>> Well it's the most sensible new year's resolution I've heard thus far :)
>> 
>> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
>> which I'm aiming to get all the patches which are sent out on the
>> mailing list as well.
>> 
>> Dave,
>> 
>>> 
>>> Jeremy
>>> 
>> 
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] liberal commit access?

[Maciek M. <ma...@mm...>]

I don't have a strong opinion on which version of wx should be
supported by wxHaskell, as long as there is at least one that works on
Windows without the need to compile wxWidgets from source. Until there
is a wxPack available for 2.9 I fear that the majority of Windows
users will be stuck with wxHaskell versions that work with 2.8.

That aside, focusing on supporting a single version of wxWidgets
sounds like a reasonable thing to do.

Maciek

On Mon, Nov 28, 2011 at 5:56 PM, Dave Tapley <duk...@gm...> wrote:
> On 28 November 2011 11:37, Jeremy O'Donoghue <jer...@gm...> wrote:
>> On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:
>>>
>>> Not surprisingly, I am in favour of this :)
>>
>> I have spent a while thinking about this, as it has considerable
>> ramifications.
>>
>> I don't think we have ever seen a case of an irresponsible committer (could
>> such a thing even exist in the Haskell community?), so I'm in favour.
>>
>>>
>>> Given that there aren't going to be any more 2.8.x releases of
>>> wxWidgets, I'm happy to say:
>>> If you want a stable(ish) wxHaskell, then use the current hackage
>>> release along with the last stable wxWidgets release (2.8.12).
>>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>>> along with the latest dev wxWidgets release (currently 2.9.2).
>>>
>>> I should note one more time that I'm quite happy to stop supporting
>>> pre 2.9.x support now, I don't know if anyone has any objection to
>>> this?
>>
>> The caveat is that I would like to do one more release on Hackage
>> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
>> branches which would benefit users of 2.8.x. I will try to do this over then
>> next two weeks, so my proposal is...
>>
>> Patches committed until the end of 2011 should be verified on a wxWidgets
>> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
>> version number from 0.13.x to 0.14.x.
>>
>> How does this sound?
>
> Well it's the most sensible new year's resolution I've heard thus far :)
>
> I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
> which I'm aiming to get all the patches which are sent out on the
> mailing list as well.
>
> Dave,
>
>>
>> Jeremy
>>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

Re: [wxhaskell-devel] liberal commit access?

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

On 28 November 2011 11:37, Jeremy O'Donoghue <jer...@gm...> wrote:
> On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:
>>
>> Not surprisingly, I am in favour of this :)
>
> I have spent a while thinking about this, as it has considerable
> ramifications.
>
> I don't think we have ever seen a case of an irresponsible committer (could
> such a thing even exist in the Haskell community?), so I'm in favour.
>
>>
>> Given that there aren't going to be any more 2.8.x releases of
>> wxWidgets, I'm happy to say:
>> If you want a stable(ish) wxHaskell, then use the current hackage
>> release along with the last stable wxWidgets release (2.8.12).
>> If you want bleeding edge wxHaskell, then pull from code.haskell.org
>> along with the latest dev wxWidgets release (currently 2.9.2).
>>
>> I should note one more time that I'm quite happy to stop supporting
>> pre 2.9.x support now, I don't know if anyone has any objection to
>> this?
>
> The caveat is that I would like to do one more release on Hackage
> supporting  2.8.x, as we have a number of valuable bugfixes in the devel
> branches which would benefit users of 2.8.x. I will try to do this over then
> next two weeks, so my proposal is...
>
> Patches committed until the end of 2011 should be verified on a wxWidgets
> 2.8.x release. From 1st Jan 2012, 2.8.x is dropped, and we'll bump the
> version number from 0.13.x to 0.14.x.
>
> How does this sound?

Well it's the most sensible new year's resolution I've heard thus far :)

I shall continue pushing to my >= wx-2.9 repo on darcs den, in to
which I'm aiming to get all the patches which are sent out on the
mailing list as well.

Dave,

>
> Jeremy
>

Re: [wxhaskell-devel] liberal commit access?

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

On 21 November 2011 18:31, Dave Tapley <duk...@gm...> wrote:

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

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

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


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

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

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

How does this sound?

Jeremy

Re: [wxhaskell-devel] liberal commit access?

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

Not surprisingly, I am in favour of this :)

Given that there aren't going to be any more 2.8.x releases of
wxWidgets, I'm happy to say:
If you want a stable(ish) wxHaskell, then use the current hackage
release along with the last stable wxWidgets release (2.8.12).
If you want bleeding edge wxHaskell, then pull from code.haskell.org
along with the latest dev wxWidgets release (currently 2.9.2).

I should note one more time that I'm quite happy to stop supporting
pre 2.9.x support now, I don't know if anyone has any objection to
this?

Dave,


On 21 November 2011 08:59, Eric Kow <eri...@gm...> wrote:
> Any comments?
>
> On 12 Nov 2011, at 16:21, Eric Kow wrote:
>
>> I suggest a trusting-by-default policy for gaining push access to main repo on cho:
>>
>> - anybody who has contributed accepted patches to wxhaskell
>> - and who requests it (or says yes to a "would you like commit access")
>
> --
> Eric Kow <http://erickow.com>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>

Re: [wxhaskell-devel] liberal commit access?

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

Any comments?

On 12 Nov 2011, at 16:21, Eric Kow wrote:

> I suggest a trusting-by-default policy for gaining push access to main repo on cho:
> 
> - anybody who has contributed accepted patches to wxhaskell
> - and who requests it (or says yes to a "would you like commit access")

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

Re: [wxhaskell-devel] wx-config changes

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

On 18 Nov 2011, at 03:26, Dave Tapley wrote:
> "wx-config --libs now only gives the standard libs. For e.g. aui you
> need to do: wx-config --libs std,aui. Alternatively, wx-config --libs
> all returns all available libraries.
> The naming of libraries has changed (see above): there are no longer
> 'debug' libraries, so the 'd' suffix is no longer used (so
> libwx_baseud-2.8 becomes libwx_baseu-2.9). wx-config has been changed
> to cope with this, which is another good reason always to use it!"[1].

That's worth knowing about.  One of my WIP patches uses thes wx-config --basename
flag (or whatever it's called) so you don't have to worry about the prefix.  

But it hasn't been tested with wx 2.8

Maciek's buildbot work could be handy there


> So there you go..
> Although, I believe there was at least one alternate implementation of
> wx-config being written? Can anyone comment?

There's a Window's only one in the repo.  It doesn't do the same job as
wx-config; much more hard-coding

There's also a C++ one out there which our Haskell version is a much slimmer, dumber version of,
also intended for Windows

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

Re: [wxhaskell-devel] "wxcore: No more Eiffel" patch and wxSTC_MASK_FOLDERS

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

Overflow?

Cold be related to 32 bit vs 64 bit


On 18 Nov 2011, at 06:42, Dave Tapley <duk...@gm...> wrote:

> Everything looked good until I noticed this:
> In yours, you have:
> wxSTC_MASK_FOLDERS = 4261412864
> 
> But in mine, I have:
> wxSTC_MASK_FOLDERS = (-33554432)
> 
> Curious, no?
> If you Google "wxSTC_MASK_FOLDERS" it seems that other people
> (primarily those wrapping wxWidgets in other languages) are reporting
> a similar 'issue'.
> 
> Dave

[wxhaskell-devel] "wxcore: No more Eiffel" patch and wxSTC_MASK_FOLDERS

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

This concerns Eric's patch, but may be of interest to the list as a whole..

I'm just merging in your "wxcore: No more Eiffel" patch (thanks
again!) and I've spotted an anomaly.

I see that you:
    addfile ./wxcore/src/haskell/Graphics/UI/WXCore/WxcDefs.hs

Which makes perfect sense as this file was previously generated by
wxcore, and so didn't need to be in version control, and now it isn't
being generated:
    hunk ./wxcore/Setup.hs 43
    -    system $ "wxdirect -d --wxc " ++ sourceDirectory ++ " -o " ++
wxcoreDirectory ++ " " ++ intercalate " " eiffelFiles


Just for the lols (and because I have some extra defs I needed to
merge in because I've wrapped wxPropertyGrid in my branch) I decided
to diff the WxcDefs.hs in your patch, against the one my wxdirect was
generating (before I merged in your patches, obviously).

Everything looked good until I noticed this:
In yours, you have:
wxSTC_MASK_FOLDERS = 4261412864

But in mine, I have:
wxSTC_MASK_FOLDERS = (-33554432)

Curious, no?
If you Google "wxSTC_MASK_FOLDERS" it seems that other people
(primarily those wrapping wxWidgets in other languages) are reporting
a similar 'issue'.

Dave

Re: [wxhaskell-devel] OpenGL support

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

On 16 November 2011 16:42, Jeremy O'Donoghue <jer...@gm...> wrote:
> Hi Dave,
>
> On 21 October 2011 18:43, Dave Tapley <duk...@gm...> wrote:
>>
>> On 21 October 2011 11:28, Jeremy O'Donoghue <jer...@gm...>
>> wrote:
>>
>> >> Did the work on OpenGL, or the branch you mention on darcsden[1] ever
>> >> get anywhere? I'd like to nominate myself to work on it :)
>
> [snip]
>> I am in the process of digging out the old OpenGL support for wxHaskell -
>> it
>> was removed a while back due to build problems on some targets. You will
>> probably need to add support for wxGLContext, which was never wrapped, but
>> the wxGLCanvas code should work provided you link with the correct
>> libraries.
>>
>> I've suggested to Joel that I send a patch with wxGLCanvas support which
>> you
>> can put on your Darcsden repo as a starting point. I'll make it compile
>> and
>> link for Ubuntu, but I won't have time to check whether it is very
>> complete
>> or functional, so you will likely have some work to do before it is
>> usable.
>
>> That sounds great, I'm on Ubuntu as well. Don't worry about stability,
>> it is most definitely a -dev branch!
>> If you want to throw it in to my repo that would be great, I've added
>> you to the members list so hopefully you can push.
>
> Attached is a patch reinstating OpenGL for your wxWidgets 2.9 branch. It has
> been tested against a home-built wxWidgets 2.9.2 on a 32 bit install of the
> latest Ubuntu (boy, was it a pain getting wxWidgets OpenGL support to
> compile, but that's another story).

Yikes, I don't want to know :|

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

Hmm, not sure, I don't see anything mentioned here:
http://trac.wxwidgets.org/wiki/Roadmap

But that's not to say some magic hasn't happened..

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

Cool :)

>
> Best regards
> Jeremy
>

[wxhaskell-devel] wx-config changes

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

I just found this which may be of interest to those of you who (like
me) have been hacking with the call to wx-config in wxcore's Setup.hs,
specifically to get the correct libraries returned for your platform:

"wx-config --libs now only gives the standard libs. For e.g. aui you
need to do: wx-config --libs std,aui. Alternatively, wx-config --libs
all returns all available libraries.
The naming of libraries has changed (see above): there are no longer
'debug' libraries, so the 'd' suffix is no longer used (so
libwx_baseud-2.8 becomes libwx_baseu-2.9). wx-config has been changed
to cope with this, which is another good reason always to use it!"[1].

So there you go..
Although, I believe there was at least one alternate implementation of
wx-config being written? Can anyone comment?

Dave,

[1] http://wiki.wxwidgets.org/Updating_to_the_Latest_Version_of_wxWidgets#The_wx-config_script

Re: [wxhaskell-devel] No more Eiffel

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

Thanks for the responses guys, just to let you know I'm currently
going through the backlog here and merging relevant patches in to my
wx-2.9-only-wxhaskell-devel branch[1].

I'll send further periodic updates to the list when I reach milestones
/ get stuck.

It's worth noting that the wxWidgets people "hope to make 3.0 in the
spring of 2012"[2], and that 2.9 is the development release for 3.0.
I'd like to cautiously suggest that we could aim to do a major version
bump and release to Hackage in tandem with them.

Dave,

[1] http://darcsden.com/DukeDave/wxhaskell-dev
[2] http://trac.wxwidgets.org/wiki/Roadmap

On 12 November 2011 17:38, Alessandro Vermeulen
<a.v...@st...> wrote:
> Hi Dave,
>
> I would like to fall in line with Eric here.
>
> It is WIP in the sense that it works on my (our) machines but is far from
> finished yet.
>
> For example, with the patches and the wp-config library you are now able to
> build wxHaskell against 2.9 on Lion but not on Snow Leopard. Other platforms are
> completely untested.
>
> Another problem seems to be with painting on canvases. The Asteroids program [1]
> from Utrecht University, kind of works. But the game elements aren't drawn.
>
> This might have something to do with mistakes/errors/changes in the API to
> wxWidgets. Maybe the types of some functions didn't change but the meaning of
> the parameters did. I'm not familiar enough with the both versions to check what
> is the case.
>
> So probably the best way to continue is to build programs that used to work and
> that you have a working wxHaskell 2.8 off to compare. If you want them to send
> in or to send in patches, please!
>
> Regards,
> Alessandro
>
> [1] http://dl.dropbox.com/u/3031364/asteroids.zip
> On 12 nov. 2011, at 17:42, Eric Kow wrote:
>
>> Thanks, Dave,
>>
>> Unfortunately, I'm going to have to switch back to hunker-down mode for wxHaskell.  But here's what I can add:
>>
>>> I just have a few requests/questions for you Eric:
>>> 1. Could you indicate exactly which patches are required (I've never
>>> applied a darcs patch from an email, so I'm curious to try), or:
>>
>> Not really, but I can guess from the patch titles
>>
>> Minimal Dependencies
>> --------------------
>> Some semantic dependencies may be missing:
>>
>>  * wxEventType is an extern type in wxWidgets 2.9.2
>>  * Rudimentary replacement for wx-config.
>>  * Don't forget parent dir in wx-config prefix search.
>>  * Fix oversight: include the wxWidgets libs in wx-config output.
>>  * use Haskell WxConfig library instead of wx-config on Windows
>>
>> Minimal wxWidgets 2.9
>> ---------------------
>>  * Only install the wx-config executable on Windows
>>  * WIP: do a better job grabbing extra lib arguments
>>  * Disable webkit and power events that were causing compile errors.
>>  * wxDrag+varia,
>>  * wxcore: remove wxPostScriptDC::{Set,Get}Resolution
>>  * PolygonFillModeFix
>>  * wxcore: Convert wxString to wchar_t* not char*
>>  * WIP: Remove references to wxPendingEvents
>>  * WIP: Remove more missing stuff
>>
>> Minimal GHC 7.2
>> ---------------
>>  * Fix build on GHC 7.2.
>>  * wx: FlexibleInstances for GHC 7.2
>>
>> Minimal No More Eiffel
>> ----------------------
>>  * wxcore: No more Eiffel (can probably stand alone)
>>  * wxcore: Remove elj prefix from cpp files.
>>  * wxcore: No more Eiffel followup
>>
>> Probably not needed
>> -------------------
>>  * Fix inconsistent newline terminator
>>  * wxdirect: Strip away ability to deal with Eiffel files.
>>  * wxdirect: Modernise exception handling.
>>  * wxdirect: Bump to 0.14
>>  * Update Graphics.UI.WXCore.WxcDefs haddock to reflect manual maintenance.
>>  * Trailing newlines on EOF.
>>  * Modernise examples not to require haskell98 package
>>
>>> 2. Are the patches available on a darcs repo somewhere?
>>> Either way I'd like to get the de-eiffel-ification in to my darcsden
>>> wxhaskell-devel branch[1]
>>
>> I'd like to push them to a fork but I need to sort out some technical issues with Alex first.
>>
>> Meanwhile, know that you can cherry pick from emailed patches with darcs apply -i
>>
>>> 3. I see that you've removed all the "wxACCEL_ALT    : INTEGER is 1"
>>> style constant exports; with them removed how to do the constants get
>>> exposed in Haskell?
>>
>> Before the patch, wxdirect parses the Eiffel files and spits out equivalent Haskell code.  The patch simply adds the results of this process to the repo and drops the bit of Setup.hs that does this parsing.
>>
>> Careful: it may actually be worthwhile to retain the *functionality* in wxdirect  that does this parsing.  Not sure, but maybe this would be helpful in cases where people for some reason want to install an old wxcore, without us having to ask them to downgrade wxdirect.
>>
>>> 4. How "WIP" do you mean by "WIP"? :)
>>
>> I think it means two things
>>
>> (A) I don't know if this is a good idea, but it's otherwise complete
>> (B) This works for me but I'm pretty sure it won't work for you
>>
>> In the case of the "do a better job" patch, updating this may actually be quite easy.  You just need to ignore the basename stuff on Windows, and append a "-2.8" (or whatever as the case may be in case we're not using wxWidgets 2.8)
>>
>> The other patches probably belong in the B category.  De-WIPping them probably just consists in thinking about whether or not this would actually be a good idea in practice and darcs amend --edit'ing the name.  Unfortunately, having the two patches in a repo at a same time would be conflict, so one would have to uvpull  the wippy versions first before pulling the rename.
>>
>> Regards,
>>
>> --
>> Eric Kow <http://erickow.com>
>>
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> wxhaskell-devel mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel
>
>

Re: [wxhaskell-devel] No more Eiffel

[Alessandro V. <a.v...@st...>]

Hi Dave,

I would like to fall in line with Eric here.

It is WIP in the sense that it works on my (our) machines but is far from
finished yet.

For example, with the patches and the wp-config library you are now able to
build wxHaskell against 2.9 on Lion but not on Snow Leopard. Other platforms are
completely untested.

Another problem seems to be with painting on canvases. The Asteroids program [1]
from Utrecht University, kind of works. But the game elements aren't drawn.

This might have something to do with mistakes/errors/changes in the API to
wxWidgets. Maybe the types of some functions didn't change but the meaning of
the parameters did. I'm not familiar enough with the both versions to check what
is the case.

So probably the best way to continue is to build programs that used to work and
that you have a working wxHaskell 2.8 off to compare. If you want them to send
in or to send in patches, please!

Regards,
Alessandro

[1] http://dl.dropbox.com/u/3031364/asteroids.zip
On 12 nov. 2011, at 17:42, Eric Kow wrote:

> Thanks, Dave,
> 
> Unfortunately, I'm going to have to switch back to hunker-down mode for wxHaskell.  But here's what I can add:
> 
>> I just have a few requests/questions for you Eric:
>> 1. Could you indicate exactly which patches are required (I've never
>> applied a darcs patch from an email, so I'm curious to try), or:
> 
> Not really, but I can guess from the patch titles
> 
> Minimal Dependencies
> --------------------
> Some semantic dependencies may be missing:
> 
>  * wxEventType is an extern type in wxWidgets 2.9.2
>  * Rudimentary replacement for wx-config.
>  * Don't forget parent dir in wx-config prefix search.
>  * Fix oversight: include the wxWidgets libs in wx-config output.
>  * use Haskell WxConfig library instead of wx-config on Windows
> 
> Minimal wxWidgets 2.9
> ---------------------
>  * Only install the wx-config executable on Windows
>  * WIP: do a better job grabbing extra lib arguments
>  * Disable webkit and power events that were causing compile errors.
>  * wxDrag+varia,
>  * wxcore: remove wxPostScriptDC::{Set,Get}Resolution
>  * PolygonFillModeFix
>  * wxcore: Convert wxString to wchar_t* not char*
>  * WIP: Remove references to wxPendingEvents
>  * WIP: Remove more missing stuff
> 
> Minimal GHC 7.2
> ---------------
>  * Fix build on GHC 7.2.
>  * wx: FlexibleInstances for GHC 7.2
> 
> Minimal No More Eiffel
> ----------------------
>  * wxcore: No more Eiffel (can probably stand alone)
>  * wxcore: Remove elj prefix from cpp files.
>  * wxcore: No more Eiffel followup
> 
> Probably not needed
> -------------------
>  * Fix inconsistent newline terminator
>  * wxdirect: Strip away ability to deal with Eiffel files.
>  * wxdirect: Modernise exception handling.
>  * wxdirect: Bump to 0.14
>  * Update Graphics.UI.WXCore.WxcDefs haddock to reflect manual maintenance.
>  * Trailing newlines on EOF.
>  * Modernise examples not to require haskell98 package
> 
>> 2. Are the patches available on a darcs repo somewhere?
>> Either way I'd like to get the de-eiffel-ification in to my darcsden
>> wxhaskell-devel branch[1]
> 
> I'd like to push them to a fork but I need to sort out some technical issues with Alex first.
> 
> Meanwhile, know that you can cherry pick from emailed patches with darcs apply -i
> 
>> 3. I see that you've removed all the "wxACCEL_ALT    : INTEGER is 1"
>> style constant exports; with them removed how to do the constants get
>> exposed in Haskell?
> 
> Before the patch, wxdirect parses the Eiffel files and spits out equivalent Haskell code.  The patch simply adds the results of this process to the repo and drops the bit of Setup.hs that does this parsing.
> 
> Careful: it may actually be worthwhile to retain the *functionality* in wxdirect  that does this parsing.  Not sure, but maybe this would be helpful in cases where people for some reason want to install an old wxcore, without us having to ask them to downgrade wxdirect.
> 
>> 4. How "WIP" do you mean by "WIP"? :)
> 
> I think it means two things
> 
> (A) I don't know if this is a good idea, but it's otherwise complete
> (B) This works for me but I'm pretty sure it won't work for you
> 
> In the case of the "do a better job" patch, updating this may actually be quite easy.  You just need to ignore the basename stuff on Windows, and append a "-2.8" (or whatever as the case may be in case we're not using wxWidgets 2.8)
> 
> The other patches probably belong in the B category.  De-WIPping them probably just consists in thinking about whether or not this would actually be a good idea in practice and darcs amend --edit'ing the name.  Unfortunately, having the two patches in a repo at a same time would be conflict, so one would have to uvpull  the wippy versions first before pulling the rename.
> 
> Regards,
> 
> -- 
> Eric Kow <http://erickow.com>
> 
> 
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> wxhaskell-devel mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-devel

Re: [wxhaskell-devel] No more Eiffel

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

Thanks, Dave,

Unfortunately, I'm going to have to switch back to hunker-down mode for wxHaskell.  But here's what I can add:

> I just have a few requests/questions for you Eric:
> 1. Could you indicate exactly which patches are required (I've never
> applied a darcs patch from an email, so I'm curious to try), or:

Not really, but I can guess from the patch titles

Minimal Dependencies
--------------------
Some semantic dependencies may be missing:

  * wxEventType is an extern type in wxWidgets 2.9.2
  * Rudimentary replacement for wx-config.
  * Don't forget parent dir in wx-config prefix search.
  * Fix oversight: include the wxWidgets libs in wx-config output.
  * use Haskell WxConfig library instead of wx-config on Windows

Minimal wxWidgets 2.9
---------------------
  * Only install the wx-config executable on Windows
  * WIP: do a better job grabbing extra lib arguments
  * Disable webkit and power events that were causing compile errors.
  * wxDrag+varia,
  * wxcore: remove wxPostScriptDC::{Set,Get}Resolution
  * PolygonFillModeFix
  * wxcore: Convert wxString to wchar_t* not char*
  * WIP: Remove references to wxPendingEvents
  * WIP: Remove more missing stuff

Minimal GHC 7.2
---------------
  * Fix build on GHC 7.2.
  * wx: FlexibleInstances for GHC 7.2

Minimal No More Eiffel
----------------------
  * wxcore: No more Eiffel (can probably stand alone)
  * wxcore: Remove elj prefix from cpp files.
  * wxcore: No more Eiffel followup

Probably not needed
-------------------
  * Fix inconsistent newline terminator
  * wxdirect: Strip away ability to deal with Eiffel files.
  * wxdirect: Modernise exception handling.
  * wxdirect: Bump to 0.14
  * Update Graphics.UI.WXCore.WxcDefs haddock to reflect manual maintenance.
  * Trailing newlines on EOF.
  * Modernise examples not to require haskell98 package

> 2. Are the patches available on a darcs repo somewhere?
> Either way I'd like to get the de-eiffel-ification in to my darcsden
> wxhaskell-devel branch[1]

I'd like to push them to a fork but I need to sort out some technical issues with Alex first.

Meanwhile, know that you can cherry pick from emailed patches with darcs apply -i

> 3. I see that you've removed all the "wxACCEL_ALT    : INTEGER is 1"
> style constant exports; with them removed how to do the constants get
> exposed in Haskell?

Before the patch, wxdirect parses the Eiffel files and spits out equivalent Haskell code.  The patch simply adds the results of this process to the repo and drops the bit of Setup.hs that does this parsing.

Careful: it may actually be worthwhile to retain the *functionality* in wxdirect  that does this parsing.  Not sure, but maybe this would be helpful in cases where people for some reason want to install an old wxcore, without us having to ask them to downgrade wxdirect.

> 4. How "WIP" do you mean by "WIP"? :)

I think it means two things

(A) I don't know if this is a good idea, but it's otherwise complete
(B) This works for me but I'm pretty sure it won't work for you

In the case of the "do a better job" patch, updating this may actually be quite easy.  You just need to ignore the basename stuff on Windows, and append a "-2.8" (or whatever as the case may be in case we're not using wxWidgets 2.8)

The other patches probably belong in the B category.  De-WIPping them probably just consists in thinking about whether or not this would actually be a good idea in practice and darcs amend --edit'ing the name.  Unfortunately, having the two patches in a repo at a same time would be conflict, so one would have to uvpull  the wippy versions first before pulling the rename.

Regards,

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