wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Proposal: Adding composability to WxHaskell

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

Hi

I have made a proposal for how we could add composability of widgets to
wxHaskell. It can be found here: http://lindstroem.wordpress.com/ .

I would very much like peoples view of the proposal.


Greetings,

Mads Lindstrøm

[wxhaskell-users] XTC 1.0 now on hackage

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

haddock description
-------------------
XTC: eXtended & Typed Controls for wxHaskell

The XTC library provides a typed interface to several wxHaskell controls.

    * radio view (typed radio box)
    * single-selection list view (typed single-selection list box)
    * muliple-selection list view (typed multiple-selection list box)
    * choice view (typed choice box)
    * value entry (typed text entry) 

XTC controls keep track of typed values and items, rather than being string
based. Selections in XTC controls consist of actual values instead of indices. 

my comments
-----------
The XTC library was developed in Utrecht University, and has been used
in a large wxhaskell appplication called Dazzle.  You can read more
about XTC and Dazzle in their Haskell Workshop paper from 2005
   http://www.cs.uu.nl/dazzle/f08-schrage.pdf

I attach a small screenshot and sample code (the sample code is
slightly updated from the hackage version to better convey the
possible usefulness of XTC)

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

On Fri, 14 Mar 2008 20:00:54 +0900, Jules Bean <ju...@je...> wrote:
>> "a seq b" doesn't guarantee that evaluate a before b.
>
> True, but that is not relevant here. It does guarantee that both get
> evaluated.

Okay, I see. I confused that.

>> return $! x
>> return $! image
>> return x
>
> that just uses seq.
>
> return $! x is just x `seq` return x
>
> that would add nothign to this code.

Ah ... it's my mistake. It just reduce x and image to WHNF.


Best Regards,

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

shelarcy wrote:
> Hi,
> 
> On Fri, 14 Mar 2008 19:24:12 +0900, Eric Y. Kow <eri...@gm...> wrote:
>> Here's my implementation of it.  Does it look sane to you?  Any comments
>> from wxhaskell developers?
>>
>> withImageData :: Image a -> (Ptr () -> IO b) -> IO b
>> withImageData image f = do
>>     pixels <- imageGetData image
>>     x <- f pixels
>>     x `seq` image `seq` return x
>>
>> The seqs are there out of pure superstition (i.e. Eric doesn't know how
>> Haskell works); basically, I want to make sure we're holding on to image
>> as long as we need to, so at least until we know what 'x' is.
> 
> "a seq b" doesn't guarantee that evaluate a before b.

True, but that is not relevant here. It does guarantee that both get 
evaluated.

In fact, all we need to do here is keep image alive. Evaluating it is 
not the point.

> If we want to do that, we must use Control.Parallel's pseq.
> 
> http://www.haskell.org/ghc/docs/6.8.2/html/libraries/parallel/Control-Parallel.html#v%3Apseq
> 
> Or to use $! operator in monad, like this.
> 
> return $! x
> return $! image
> return x

that just uses seq.

return $! x is just x `seq` return x

that would add nothign to this code.

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

Hi,

On Fri, 14 Mar 2008 19:24:12 +0900, Eric Y. Kow <eri...@gm...> wrote:
> Here's my implementation of it.  Does it look sane to you?  Any comments
> from wxhaskell developers?
>
> withImageData :: Image a -> (Ptr () -> IO b) -> IO b
> withImageData image f = do
>     pixels <- imageGetData image
>     x <- f pixels
>     x `seq` image `seq` return x
>
> The seqs are there out of pure superstition (i.e. Eric doesn't know how
> Haskell works); basically, I want to make sure we're holding on to image
> as long as we need to, so at least until we know what 'x' is.

"a seq b" doesn't guarantee that evaluate a before b.
If we want to do that, we must use Control.Parallel's pseq.

http://www.haskell.org/ghc/docs/6.8.2/html/libraries/parallel/Control-Parallel.html#v%3Apseq

Or to use $! operator in monad, like this.

return $! x
return $! image
return x


Best Regards,

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Y. Kow wrote:
> Here's my implementation of it.  Does it look sane to you?  Any comments
> from wxhaskell developers?
> 
> withImageData :: Image a -> (Ptr () -> IO b) -> IO b
> withImageData image f = do
>     pixels <- imageGetData image
>     x <- f pixels
>     x `seq` image `seq` return x
> 
> The seqs are there out of pure superstition (i.e. Eric doesn't know how
> Haskell works); basically, I want to make sure we're holding on to image
> as long as we need to, so at least until we know what 'x' is.

The x `seq` is likely pointless. "x" is a pure value and unless 
someone's cheating with unsafePerformIO, merely forcing a pure value 
can't cause any Ptr access to happen.

the image `seq` looks like a reasonable hack to keep image alive.

The canonical way would be "touchForeignPtr image" or to use 
"withForeignPtr image", except that image isn't a ForeignPtr exactly. I 
don't know if there is a good way to access the ForeignPtr inside image 
because I haven't grokked enough of wx yet.

See 
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html 
for these and related issues.

> 
> If this is indeed sane, we could stick it in wxcore and put a big
> warning on the Haddocks for imageGetData (without removing it just
> yet).

And fix imageGetPixels to use the new safe withImageData. Which would 
have made my bug go away.

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

> > Ultimately, this seems like the right thing to do, for all functions
> > that return pointers to underlying bits of data (I am slightly scared
> > that there may be loads of these lurking around).

> For most purposes the (Ptr () -> IO b) approach is probably neater, 
> though. After all if you do need direct access to a Ptr, it's probably 
> because you're calling another FFI funciton on it (in my case, 
> texImage2d), which will itself "take a copy" of the memory, and then 
> it's safe to destroy.

Here's my implementation of it.  Does it look sane to you?  Any comments
from wxhaskell developers?

withImageData :: Image a -> (Ptr () -> IO b) -> IO b
withImageData image f = do
    pixels <- imageGetData image
    x <- f pixels
    x `seq` image `seq` return x

The seqs are there out of pure superstition (i.e. Eric doesn't know how
Haskell works); basically, I want to make sure we're holding on to image
as long as we need to, so at least until we know what 'x' is.

If this is indeed sane, we could stick it in wxcore and put a big
warning on the Haddocks for imageGetData (without removing it just
yet).

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Y. Kow wrote:
>> Should imageGetData be turned into a 'with-style' function
>>
>> Image a -> (Ptr () -> IO b) -> IO b
>>
>> which protects the image?
> 
> Ultimately, this seems like the right thing to do, for all functions
> that return pointers to underlying bits of data (I am slightly scared
> that there may be loads of these lurking around).

The alternative is to use mallocForeignPtr or one of its friends, and 
return a ForeignPtr to a copy of the buffer. Clearly both alternatives 
could be supported.

For most purposes the (Ptr () -> IO b) approach is probably neater, 
though. After all if you do need direct access to a Ptr, it's probably 
because you're calling another FFI funciton on it (in my case, 
texImage2d), which will itself "take a copy" of the memory, and then 
it's safe to destroy.

So in my example withImageData (\d -> texImage2d d ...) would seem like 
a pretty elegant answer.

> 
>> Is there a workaround I can use in my code like touchPtr? A version of 
>> touchPtr which works on WXObjects?
> 
> Well, I added image `seq` return () to your demonstrator.  Not sure if
> that really does what we want.  I suppose we could augment the
> PixelBuffer type to include a pointer to the original image.

I think that makes it safe as long as PixelBuffer is considered opaque.

But as soon as you provide a way of extracting the Ptr () from the Pixel 
Buffer, then the same problem comes back to bite you.

As it happens, in my particular program, I don't use the Ptr directly 
because I need to pad to even width anyway, in general. So I was using 
imageGetPixels and thus would be safe under that scheme.

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

On Fri, Mar 14, 2008 at 10:05:55 +0000, Eric Y. Kow wrote:
> I suppose we could augment the
> PixelBuffer type to include a pointer to the original image.

Arrrr, imprecise thinking.  That's not what I meant to say.

Anyway, I think you get my idea of trying to keep the image
reference/thingy alive within the Haskelley bits (wxcore).

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

> I've worked it out. With a little help from malcolmw on #ghc.

Excellent!  Thanks very much.  I learned something new.

> Should imageGetData be turned into a 'with-style' function
> 
> Image a -> (Ptr () -> IO b) -> IO b
> 
> which protects the image?

Ultimately, this seems like the right thing to do, for all functions
that return pointers to underlying bits of data (I am slightly scared
that there may be loads of these lurking around).

> Is there a workaround I can use in my code like touchPtr? A version of 
> touchPtr which works on WXObjects?

Well, I added image `seq` return () to your demonstrator.  Not sure if
that really does what we want.  I suppose we could augment the
PixelBuffer type to include a pointer to the original image.

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Y. Kow wrote:
> I have honestly no idea what's going on here.

I've worked it out. With a little help from malcolmw on #ghc.

1    image <- imageCreateSized (WX.Size 256 256)
2    pixels <- imageGetData image
3    bytes <- peekArray (256*256*3) (castPtr pixels)


After line 2 is executed, there is no remaining reference to 'image' in 
the program. 'image' is dead, and can be garbage collected. (Although it 
may not be at any particular time). If 'image' gets GC'ed, because there 
is a ForeignPtr inside, that calls the C++ destructor. The wxImage C++ 
destructor believes it owns the data block, so it free()s it, and 
'pixels' is left pointing to a free()ed block.

This is why it is inconsistent. It depends if image happens to get GC'ed 
before the peekArray completes running.

As to how we fix it? Well as a proof of concept, adding:

     putStrLn $ "Keep image alive with this reference " ++ (show image)

as the last line of createAndGetPixels will prevent the GC and stop the 
segfault.

The right fix tho? I'm not sure. It seems like 'imageGetData' is 
fundamentally broken (and thus anything that depends on it, like 
getPixels). Is there some way imageGetData could return a Ptr and 
simultaneously keep the 'image' alive for as long as the Ptr is alive?

Should imageGetData be turned into a 'with-style' function

Image a -> (Ptr () -> IO b) -> IO b

which protects the image?

Is there a workaround I can use in my code like touchPtr? A version of 
touchPtr which works on WXObjects?

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

On Fri, Mar 14, 2008 at 08:34:48 +0000, Jules Bean wrote:
> But it doesn't segfault :(

:-/ Well, at least this means it might be something we can fix.

> void createAndGetPixels() {
>   wxImage *im = new wxImage(256,256);
>   unsigned char* pixels = im->GetData();
>   std::cout << "pixels : " << ((void*)pixels) << std::endl;
>   void *bytes = malloc(256*256*3);
>   memcpy(bytes,pixels,256*256*3);
>   //free(bytes);
>   //delete im;

I modified the wxc wrapper so that it copies the contents of the array into a
whole new one... and that stops the segfaulting.  It doesn't explain very much
(to me), though, and the whole introducing a memory leak thing may not be so
much fun.

EWXWEXPORT(void*, wxImage_GetData)(void* _obj)
{
        int w = ((wxImage*)_obj)->GetWidth();
        int h = ((wxImage*)_obj)->GetHeight();
        void *bytes = malloc(h*w*3);
        void *pixels = ((wxImage*)_obj)->GetData();
        memcpy(bytes,pixels,h*w*3);
        return (void*)bytes;
}

I have honestly no idea what's going on here.

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Kow wrote:
>>  So somehow, sometimes, we're getting an invalid pointer. Whether it's a
>>  pointer to a buffer which is too short, or a buffer which has been
>>  moved, or....
> 
> Another observation is that this fails much more easily with bigger buffers.
> 
> A sort of silly question: do you think you could cook up an equivalent
> demonstrator in C++ just using wxWidgets?

Yes.

But it doesn't segfault :(

I have reduced the haskell code to the following simplified version:

import qualified Graphics.UI.WX as WX
import Graphics.UI.WXCore.Image
import Graphics.UI.WXCore.Draw
import Graphics.UI.WXCore.WxcClassesAL
import Graphics.UI.WXCore.WxcClassesMZ

import Foreign
import Data.Word

import Control.Monad

main = do
   forM_ [0..500]
     (\i -> putStrLn ("Iteration : " ++ show i) >> createAndGetPixels)

createAndGetPixels = do
     image <- imageCreateSized (WX.Size 256 256)
     pixels <- imageGetData image
     putStrLn $ "pixels : " ++ show pixels
--    putStr $ "Reading byte.."
--     forM_ [0..256*256*3] $ \b -> do
--       byte  <- peekByteOff (castPtr pixels) b :: IO Word8
--       putStr (show b ++ "..")
     bytes <- peekArray (256*256*3) (castPtr pixels)
     putStrLn $ "bytes : " ++ show (length (bytes :: [Word8]))


(The commented out code was me experimenting to see if there was a 
pattern in "which" byte causes the segfault. There isn't, that I can see)

And here is my attempt to replicate this exact set of calls from C++:

#include <iostream>

#include "wx/wx.h"
#include "wx/image.h"

void createAndGetPixels();

int main() {
   for (int i=0; i<500; i++) {
     std::cout << "Iteration " << i << std::endl;
     createAndGetPixels();
   }
}

void createAndGetPixels() {
   wxImage *im = new wxImage(256,256);
   unsigned char* pixels = im->GetData();
   std::cout << "pixels : " << ((void*)pixels) << std::endl;
   void *bytes = malloc(256*256*3);
   memcpy(bytes,pixels,256*256*3);
   //free(bytes);
   //delete im;
}


And it doesn't seem to segfault, ever.

If you leave the "free" and "delete" in then the nice deterministic C 
malloc gives you back the same block of memory each time! that's why I 
commented them out.

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

>  So somehow, sometimes, we're getting an invalid pointer. Whether it's a
>  pointer to a buffer which is too short, or a buffer which has been
>  moved, or....

Another observation is that this fails much more easily with bigger buffers.

A sort of silly question: do you think you could cook up an equivalent
demonstrator in C++ just using wxWidgets?

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Kow wrote:
> Hi Jules,
> 
> Thanks for the test case.
> 
> It segfaults right away for me on Linux (iteration 0).  I don't even
> need the bitmap to make it do this; just
>    image <- imageCreateSized (WX.Size 256 256)
> 
> Also, I notice that it seems to happen Graphics.UI.WXCore.pixelBufferGetPixels
> 
> (This is via the old fashioned putStrLn style of debugging)
> 
> Do you confirm these?


Yes.

And what pixelBufferGetPixels does is peekCStringLen, which is 
essentially reading the entire buffer that image owns.

Whereas the other bug report you pointed me to read the image's buffer 
more gradually, but still hit the same error.

So somehow, sometimes, we're getting an invalid pointer. Whether it's a 
pointer to a buffer which is too short, or a buffer which has been 
moved, or....

Jules

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

Hi Jules,

Thanks for the test case.

It segfaults right away for me on Linux (iteration 0).  I don't even
need the bitmap to make it do this; just
   image <- imageCreateSized (WX.Size 256 256)

Also, I notice that it seems to happen Graphics.UI.WXCore.pixelBufferGetPixels

(This is via the old fashioned putStrLn style of debugging)

Do you confirm these?

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

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Eric Kow wrote:
> Hi Jules,
> 
> Is this the same bug as this one from the Tracker?
>   http://sourceforge.net/tracker/index.php?func=detail&aid=1003006&group_id=73133&atid=536845
> 
> (was submitted by Paul Johnson, I think)
> 
> Also, if you are so inclined, it would be extra-helpful if you could
> submit your demonstrator as a test case in the bugs/ directory (darcs
> send).  It would be extra-extra-helpful if you could work out a way to
> reproduce this bug very consistently (for example, by repeatedly
> loading the image in or something)

Hi Eric,

It does look like it could well be the same bug. Although seems 
surprising for there to be a hole in the memory? Perhaps it is being 
moved by GC... but GC doesn't move memory which was allocated by a C(++) 
library does it?

I can reproduce the bug simply by creating images over and over and over 
again.

Here is a fairly minimal testcase, at the bottom of this mail. It always 
seems to segfault for me, normally after about 5 iterations, sometimes 
as many as 22.

It's interesting that there is a very long pause before the segfault. 
That is, one iteration of creating an image is normally a tiny tiny 
fraction of a second, but if it's going to segfault, there is a long pause.

I tried running with -Sstderr to see if I could see an obvious link 
between garbage collections and crashes, but if there is one it isn't 
obvious to me!

Happy to try more stuff to pin this down, let me know what I can do.

Jules

import qualified Graphics.UI.WX as WX
import Graphics.UI.WXCore.Image
import Graphics.UI.WXCore.Draw
import Graphics.UI.WXCore.WxcClassesAL
import Graphics.UI.WXCore.WxcClassesMZ

import Foreign
import Data.Word

import Control.Monad

main = do
   forM_ [0..500]
     (\i -> putStrLn ("Iteration : " ++ show i) >> createAndGetPixels)

createAndGetPixels = do
   bmp <- bitmapCreateEmpty (WX.Size 256 256) 24
   pixelsFromBitmap bmp

pixelsFromBitmap bmp = do
     image <- imageCreateFromBitmap bmp
     pixels <- imageGetData image
     putStrLn $ "pixels : " ++ show pixels
     bytes <- peekArray 8 (castPtr pixels)
     putStrLn $ "bytes : " ++ show (bytes :: [Word8])
     WX.Size w h <- imageGetSize image
     putStrLn $ "Image size : " ++ show (w,h)
     pixs <- imageGetPixels image
     putStrLn $ "number of pixs = " ++ show (length pixs)
     putStrLn $ "first pixel " ++ show (head pixs)

Re: [wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

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

Hi Jules,

Is this the same bug as this one from the Tracker?
  http://sourceforge.net/tracker/index.php?func=detail&aid=1003006&group_id=73133&atid=536845

(was submitted by Paul Johnson, I think)

Also, if you are so inclined, it would be extra-helpful if you could
submit your demonstrator as a test case in the bugs/ directory (darcs
send).  It would be extra-extra-helpful if you could work out a way to
reproduce this bug very consistently (for example, by repeatedly
loading the image in or something)

Thanks!

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

[wxhaskell-users] Some WX questions - a couple of missing bindings and a segfault

[Jules B. <ju...@je...>]

Hi,

Thanks to Eric's help earlier, I managed to get wx running and run
some simple programs in it. I have run into the following
(unconnected) problems with the API:

There doesn't seem to be a binding to wxImage's "SetOption" call. I
need to this to save a JPEG at anything other than the default
quality. I'm loading in a JPEG, cropping, and saving out: if you
recompress that at low quality you really suffer from jpg artifacts.

There doesn't seem to be a binding to the "wxImage-from-WXStream"
constructor. In particular, it would be nice to have a version using a
wxMemoryInputStream so that you can load a wxImage from a Ptr, such as
if you get an image via a network protocol or embedded in a larger
file.

I have random segfaults when calling imageGetPixels. Seems to be with
a probability of something like 25%. Here is the code I've written
(which generates an openGL texture from a WX bitmap):

textureFromBitmap bmp = do
     image <- imageCreateFromBitmap bmp
     pixels <- imageGetData image
     putStrLn $ "pixels : " ++ show pixels
     bytes <- peekArray 8 (castPtr pixels)
     putStrLn $ "bytes : " ++ show (bytes :: [Word8])
     WX.Size w h <- imageGetSize image
     putStrLn $ "Image size : " ++ show (w,h)
     pixs <- imageGetPixels image
     putStrLn $ "number of pixs = " ++ show (length pixs)
     putStrLn $ "first pixel " ++ show (head pixs)

     [tex] <- genObjectNames 1
     textureBinding Texture2D $= Just tex
     textureWrapMode Texture2D T $= (Repeated,Repeat)
     textureWrapMode Texture2D S $= (Repeated,Repeat)
     textureFilter Texture2D $= ((Nearest,  Nothing), Linear')
     let wxToColor3 :: WX.Color -> Color3 GLubyte
         wxToColor3 c = Color3 (fromIntegral $ WX.colorRed c)
                        (fromIntegral $ WX.colorGreen c)
                        (fromIntegral $ WX.colorBlue c)
         padded | w `mod` 2 == 0 = pixs
                | otherwise = concatMap (\x -> x ++ [WX.colorRGB 0 0 0]) .
                              chunksOf w $ pixs
         chunksOf n l = takeWhile (not.null) . map (take n) . iterate 
(drop n) $ l
     withArray (map wxToColor3 padded) $
       \a -> texImage2D Nothing NoProxy 0 RGBA' (TextureSize2D 
(fromIntegral w) (fromIntegral h)) 0
               (PixelData RGB UnsignedByte a)
     return tex

It doesn't appear to be relevant where the bitmap comes from, I've
seen the segfault with bitmaps coming from "bitmapCreateFromFile" as
well as from "bitmapCreateEmpty".

About 1 time in 4, this will segfault with the last thing printed
being the "Image size" putStrLn, leading me to think that
imageGetPixels is segfaulting. gdb doesn't tell me anything useful
- presumably because my wx libraries are not compiled with debug info?
Is there a wx configure option for that? I'll have a look and see what
I can see.

Thanks for providing such a useful binding,

Jules Bean

[wxhaskell-users] Google Summer of Code and wxhaskell TODOs

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

Hi everyone,

We have been recently discussing the possibility of mentoring a
wxHaskell project.  Shelarcy (Kido Takahiro), in particular, is
interested in being a mentor.

I would like to solicit ideas for possible projects and to see if
there is anybody would would be interested in working on such a
project.

One idea we had was to implement XRC support.  XRC is an XML format for
describing wxWidgets interfaces.  It allows you to build your GUI using
visual tools like wxGlade, and load the results into your application at
runtime.  This might be a useful thing to have.  We could also imagine
implementing support on this in phases, for example, starting with a
simple one-shot conversion and moving up to more dynamic use of the
format.

Do you have any other suggestions?

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

[wxhaskell-users] ANNOUNCE: wxHaskell 0.10.3 rc1

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

We are pleased to announce the first release candidate of wxHaskell
0.10.3.

This is the first update with binary packages available since June 2005,
and is the result of a great deal of work by a new team of contributors.

We are hoping to make a full release shortly, and issues and bug reports
either through the wxHaskell user mailing list
(wxh...@so...) or via the Sourceforge bug tracker
(http://sourceforge.net/tracker/?group_id=73133&atid=536845).

Highlights of 0.10.3 rc1 include:

- Support for Unicode builds of wxWidgets
- Support for additional widgets including calendar, toolbar divider,
styled text control (wxScintilla), media control
- Support for clipboard, drag and drop
- Support for 64bit (Linux) targets
- Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 retained if
you compile from source)
- Support for building with GHC 6.6.x and 6.8.x
- Parts of wxHaskell are now built with Cabal
- New test cases
- Removed support GHC version < 6.4
- Profiling support
- Smaller generated binary sizes (using --split-objs)

Binary packages are available from the wxHaskell download site at
http://sourceforge.net/project/showfiles.php?group_id=73133, for the
following platforms:

- Debian
- Windows
- OS X (Intel and PPC platforms)
- Source code .tar.gz and .zip
- Documentation (cross-platform)

About wxHaskell

wxHaskell is a Haskell binding to the wxWidgets GUI library. It provides
a native look and feel on Windows, OS X and Linux, and a medium level
programming interface.

The main project page for wxHaskell is at
http://wxhaskell.sourceforge.net.
The latest source code for wxHaskell can always be obtained from
http://darcs.haskell.org/wxhaskell.
There are developer (wxh...@li... and user
(wxh...@li...) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

wxHaskell was originally created by Daan Leijen. The contributors to
this new release include:

- Eric Kow
- shelarcy
- Arie Middelkoop
- Mads Lindstroem
- Jeremy O'Donoghue
- Lennart Augustson
-- 
  Jeremy O'Donoghue
  jer...@gm...

Re: [wxhaskell-users] Trouble with wxhaskell on OSX (Intel/10.4)

[Jules B. <ju...@je...>]

Eric Y. Kow wrote:
> Hi,
> 
>> But, it doesn't quite run fine. Where the button is supposed to be 
>> labelled 'Quit', it's labelled 'Q', and where the window itself is 
>> supposed to be labelled "Hello!", it's just labelled 'H'.
> 
> Ah! You need to configure wxWidgets with --enable-unicode.
> 
> Maybe we should work out a way for the configure script to detect if
> wxWidgets is unicode-enabled or not.
> 


D'oh!

Thanks.

Reconfigured, rebuilt and all is fine.

I hope to write some test wxhaskell code in a day or two and I'll report 
how it goes.

Jules

Re: [wxhaskell-users] Trouble with wxhaskell on OSX (Intel/10.4)

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

Hi,

> But, it doesn't quite run fine. Where the button is supposed to be 
> labelled 'Quit', it's labelled 'Q', and where the window itself is 
> supposed to be labelled "Hello!", it's just labelled 'H'.

Ah! You need to configure wxWidgets with --enable-unicode.

Maybe we should work out a way for the configure script to detect if
wxWidgets is unicode-enabled or not.

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

[wxhaskell-users] Trouble with wxhaskell on OSX (Intel/10.4)

[Jules B. <ju...@je...>]

Hi,

I have just tried to build wxhaskell on my Intel MacBook Pro, with OSX 
10.4 and ghc-6.6.1.

This is how it went:

Here are some notes on my attempt to compile wx-0.10.2 with ghc 6.6 on
an Intel MacOS X 10.4 platform.

Download wxMac-2.6.4.tar.gz from wx official home page.

carried out the following steps:

less INSTALL-MAC.txt
mkdir osx-build
cd osx-build/
../configure  --with-opengl
make -j3
sudo make install

then I tested some of the demo apps in-place, and that seemed to work 
well. 'bombs', 'life', etc: all seem to work well.

then wxcore:

cd wxcore-0.10.2
./configure
make
sudo make install

the I tried to build wx and discovered I needed a newer version of cabal.

(slight detour while I install cabal 1.2.3)

cd ../wx-0.10.2
runhaskell Setup.lhs configure
runhaskell Setup.lhs build
sudo runhaskell Setup.lhs install

Then I copied the "hello" example from
http://wxhaskell.sourceforge.net/quickstart.html, and it compiled fine!

(Remembering the magic OSX incantation, it looks like this:
ghc --make wxhello.hs
/usr/local/wxhaskell/bin/macosx-app -v wxhello
open wxhello.app/
)

But, it doesn't quite run fine. Where the button is supposed to be 
labelled 'Quit', it's labelled 'Q', and where the window itself is 
supposed to be labelled "Hello!", it's just labelled 'H'.

So I tried some of the more complex demo apps, like 'ImageViewer.hs' 
from samples in the wxcore distribution. Similar weird behaviour. The 
window is called "I" not "ImageViewer". The error message dialog says "I 
Error" not "ImageViewer Error". The menus are titled "ImageViewer", "&", 
and "&". The first item in the ImageViewer menu, which should be "About 
ImageViewer" is just "&". If you select it you get a dialog box 
containing the two lines "A" and "T".

If you run "Paint.hs", the "rotated text" which is suposed to be drawn 
just shows up as "r".

Very very peculiar! Any pointers or suggestions?

Jules

Re: [wxhaskell-users] wxhaskell under leopard

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

Hi,

> But now the sample code give a segmentation fault. Somebody has some
> hint on the reason?

Could you please try with wxWidgets 2.6?
See <http://haskell.org/haskellwiki/WxHaskell/Install>
 (and update the wiki if you get something working under Leopard)

Thanks!

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