wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Postscript device contexts?

[Claus R. <cla...@ta...>]

Hi,

I'd like to draw to a Postscript device context (should give better 
results than screenshots for embedding in a paper), but I can't seem
to find a way to create such a thing (the type exists, but where are
the constructors?). Am I missing something?

Cheers,
Claus

Re: [wxhaskell-users] Image generating

[Daan L. <daa...@xs...>]

Andrey Dadakov wrote:

> Hi, is it possible to create an image file (PNG for example) using 
> wxHaskell?
>
>  
>
> I tried to find an equivalent for wxImage::SaveFile but could not find it.
>
>  
>
> Thank you
>
> Andrey
>
Hi Andrey,

You can use "imageSaveFile".  It takes an image, file path, and file type.
The file type can be for example "wxBITMAP_TYPE_PNG"   or you
can use the function "imageTypeFromFileName" to get the type from the
extension of the file name.

 > imageSave :: Image a -> FilePath -> IO ()
 > imageSave image fpath
 >    = imageSaveFile image fpath (imageTypeFromFileName fpath)

All the best,
   Daan.

btw. You can see all functionality of an Image if you look in the
haddock documentation for "Graphics.UI.WXCore.WxcClassessAL"

[wxhaskell-users] Image generating

[Andrey D. <ada...@aw...>]

Hi, is it possible to create an image file (PNG for example) using
wxHaskell?
 
I tried to find an equivalent for wxImage::SaveFile but could not find
it.
 
Thank you
Andrey

Re: [wxhaskell-users] TabPage type not exported

[Daan L. <da...@cs...>]

Sander Evers wrote:
> Why is the type WXCore.Layout.TabPage not exported?

Well, it is supposed to be an abstract data type. However,
its name should at least be exported to be able to write
down type signatures -- I'll fix it in the next release.

Thanks for the bug report,
  -- Daan.

> 
> Sander
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] TabPage type not exported

[Sander E. <sa...@cs...>]

Why is the type WXCore.Layout.TabPage not exported?

Sander

[wxhaskell-users] Re: wxWidgets question

[Daan L. <da...@cs...>]

Sean Seefried wrote:

> I'm displaying a bitmap inside a window and at some point I wish to load 
> a new bitmap.  When the bitmap is larger the window resizes really 
> nicely, but when I load a smaller bitmap the windows stays the same 
> size. I've tried a lot of things to get it to shrink again.  If I call 
> my top level frame 'f' then I have tried the following
 >
 > set [clientSize := Size 1 1]
 > set [outerSize := Size 1 1]
 >
 > But neither of these seems to do anything. Is there anything else I
 > should be looking at?

Hi Sean,

I think you should call "windowReFitMinimal"  (from "WXCore.Layout") on
the child widget (or "windowReLayoutMinimal" on the parent frame).

I don't think that you need to set a new layout if you are just drawing
the bitmap.

The whole size issue (initialSize vs. changing sizes) is somewhat 
obscure to me too -- it seems that wxWidgets is not so transparent
when dynamic layouts are involved. I suppose that everything is
possible but some things are much easier than others :-)

I hope this helps,
  -- Daan.

> 
> 
> I've done the correct thing with the layout.  I create a _new_ layout 
> each time I load a new bitmap and make sure that the old bitmap is deleted.
> 
> Sean
> 
> 
> 

[wxhaskell-users] samples/contrib/ is broken.

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

Hello,
I found that two contribute sample is broken.
Here is a error message.

C:/develop/wxhaskell-0.8/samples/contrib/NotebookRight.hs:25:
     Couldn't match `IO (TextCtrl ())' against `t -> t1'
         Expected type: IO (TextCtrl ())
         Inferred type: t -> t1
     Probable cause: `textCtrl' is applied to too many arguments in the call
         (textCtrl p WrapLine [enabled := False])
     In a 'do' expression:
         textlog <- textCtrl p WrapLine [enabled := False]
Failed, modules loaded: none.


C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:25:
     Ambiguous occurrence `size'
     It could refer to either `Graphics.UI.WX.Classes.size', imported from  
Graphi
cs.UI.WX at C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:10
                           or `Graphics.UI.WXCore.WxcTypes.size', imported  
 from G
raphics.UI.WXCore at  
C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:9

C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:28:
     Ambiguous occurrence `size'
     It could refer to either `Graphics.UI.WX.Classes.size', imported from  
Graphi
cs.UI.WX at C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:10
                           or `Graphics.UI.WXCore.WxcTypes.size', imported  
 from G
raphics.UI.WXCore at  
C:/develop/wxhaskell-0.8/samples/contrib/PaintDirect.hs:9


-- 
shelarcy <she...@ca...>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] subclassing?

[Daan L. <daa...@xs...>]

Abraham Egnor wrote:

>I'm looking to create an application for which a large chunk of the UI
>is a grid control.  The wxWidgets documentation for wxGrid says that
>for data that's more complex than strings (which this is) to derive a
>custom grid table class and pass it to wxGrid::SetTable.  Is this
>possible in wxHaskell?
>  
>
No -- at least, not yet. It is not really necessary to derive your own 
table in most
cases, a special "renderer" is normally good enough. I have been 
thinking with Arjan
van IJzendoorn about doing such thing to display histograms instead numbers.

Bottom line, I still have to get around implementing some wrapper code
for wxHaskell before this can be used. However, you can help me by 
specifying
exactly what you need to do (offline?).

All the best,
 Daan.

ps. I am on holiday till next week, so I won't reply soon.
pps. If you are a good C++/Haskell hacker, you could extend it yourself, the
wxcHtmlWindow is a good example of how to do such thing.


>Abe
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by OSTG. Have you noticed the changes on
>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>one more big change to announce. We are now OSTG- Open Source Technology
>Group. Come see the changes on the new OSTG site. www.ostg.com
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

Re: [wxhaskell-users] reproducing Process problems

[Daan L. <daa...@xs...>]

Claus Reinke wrote:

>I've now managed to get one of the problems in a 
>reproducable form (windows 98, ghc-6.2.1, wxhaskell-0.8):
>  
>
Thanks, I look into it in more detail when I get back from holidays
(= next week).

-- Daan.

>1. start ghci
>2. :cd <...>/wxhaskell-0.8/samples/wx
>3. :set -package wx
>4. :l Process
>5. main
>
>in Process window:
>
>6. ghci
>7. :q
>8. ghci
>9. :q
>
>that seems to lock up my system, with optional bluescreen
>(sometimes it needs three iterations instead of two).
>
>doing the equivalent under cygwin (using System.system
>instead of wxhaskell's Process) doesn't seem to suffer from
>the same problem, so it can't be (just) ghc's fault.
>
>Cheers,
>Claus
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by OSTG. Have you noticed the changes on
>Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
>one more big change to announce. We are now OSTG- Open Source Technology
>Group. Come see the changes on the new OSTG site. www.ostg.com
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

[wxhaskell-users] subclassing?

[Abraham E. <abe...@gm...>]

I'm looking to create an application for which a large chunk of the UI
is a grid control.  The wxWidgets documentation for wxGrid says that
for data that's more complex than strings (which this is) to derive a
custom grid table class and pass it to wxGrid::SetTable.  Is this
possible in wxHaskell?

Abe

[wxhaskell-users] reproducing Process problems

[Claus R. <cla...@ta...>]

I've now managed to get one of the problems in a 
reproducable form (windows 98, ghc-6.2.1, wxhaskell-0.8):

1. start ghci
2. :cd <...>/wxhaskell-0.8/samples/wx
3. :set -package wx
4. :l Process
5. main

in Process window:

6. ghci
7. :q
8. ghci
9. :q

that seems to lock up my system, with optional bluescreen
(sometimes it needs three iterations instead of two).

doing the equivalent under cygwin (using System.system
instead of wxhaskell's Process) doesn't seem to suffer from
the same problem, so it can't be (just) ghc's fault.

Cheers,
Claus

Re: [wxhaskell-users] preview: HCPN editing and simulation

[Daan L. <da...@cs...>]

Claus Reinke wrote:

> layer). Having complex text-entry widgets that can only be used 
> separately but not in a drawing frame is one example (should I recode
> the whole thing in terms of drawText and on key, and thus duplicate 
> code?). 

Ha, we had the same problem. However, it seems that you can just
create a text control and position it yourself (using "position") on
a canvas -- et voila, inline editing. However, you probably need to
smart with visibility and focus... for details, read the c++ source
files in "generic/grid.cpp" of wxWidgets :-)

-- Daan.

Re: [wxhaskell-users] Is this PixelBuffer's bug?

[Daan L. <da...@cs...>]

shelarcy wrote:

> I chaged the program like this.But program doen't work yet.
> Where is my mistake?

Hi Shelarcy,

Your mistakes are in the plain Haskell code. For example:

> pixelColorInt (Point ptx pty) (Size szx szy)
>  | ptx < 0   = pixelColorInt (Point 0 pty)  (Size szx szy)
>  | pty < 0   = pixelColorInt (Point ptx 0)  (Size szx szy)
>  | ptx > szx = pixelColorInt (Point ptx pty)  (Size 0 szy)
>  | pty < szy = pixelColorInt (Point ptx pty)  (Size 0 szy)
>  | otherwise = do pixel <- pixelBufferGetPixel pb 

If I call this with (Point x y) (Size sz sy) where y < sy,
this function loops indefinitely. What you should try to do
is to split up everything into small functions that can be
tested independently -- instead of writing everything at once.
Also, if certain expression patterns occur more than once, try
to make that into a function.

Anyway, to help you along, I have attached a version of your
program that does what you want. As you will notice, it is
rather slow. After some testing I found that it is due to the
slow "pixelBufferGet/SetPixel" functions. In the cvs release
I'll commit a version that allows you to retrieve the entire
buffer at once which makes it much faster. That version is
probably available by anonymous cvs tomorrow.

All the best,
 Daan.

Re: [wxhaskell-users] preview: HCPN editing and simulation

[Arie M. <ami...@cs...>]

> >>(beware, there seems to be a bug where output is lost when the
> >>process is terminated. (I haven't been able to reproduce this though))

I also noticed this in the wxHaskell application i'm building. It seams to
be related to the input buffering as I use very small buffers and never lose
more output than a single buffer.

Arie

Re: [wxhaskell-users] submenu commands broken?

[Daan L. <da...@cs...>]

Hi Abraham,

Abraham Egnor wrote:
> I'm a newb to both wxHaskell and wxWindows, so I apologize if I've
> missed something obvious.
> 
> The following program constructs a trivial menu and submenu; the
> command for the non-submenu item works but the one for the submenu
> item does not.  

You have found a bug :-) Fortunately, there is an easy work-around:
just change the order of the "menuSub" call and the "menuItem" call:

>        m <- menuPane [text := "Menu"]
>        sub <- menuPane []
>        menuSub m sub [text := "Submenu"]
>        menuItem sub [text := "Test", on command := putStrLn "Test"]
>        menuItem m [text := "Test 2", on command := putStrLn "Test 2"]

Another workaround is to catch the menu events in the frame (or current
window):

>        m <- menuPane [text := "Menu"]
>        sub <- menuPane []
>        menuSub m sub [text := "Submenu"]
>        test <- menuItem sub [text := "Test"]
>        menuItem m [text := "Test 2", on command := putStrLn "Test 2"]
>        ...
>        set f [on (menu test) := putStrLn "Test"]

I have fixed the bug in CVS, but I guess that the
workaround is convenient enough for now.

Thanks for pointing this out,
All the best,
  Daan.



This was tested under debian unstable, with wxHaskell
> 0.8 and wxGTK 2.4.2.
> 
> Abe
> 
> import Graphics.UI.WX
> 
> main = start gui
> 
> gui =
>     do f <- frame [text := "Submenu test", visible :=  False]
> 
>        m <- menuPane [text := "Menu"]
>        sub <- menuPane []
>        test <- menuItem sub [text := "Test", on command := putStrLn
> "Test"] -- doesn't work
>        menuSub m sub [text := "Submenu"]
>        menuItem m [text := "Test 2", on command := putStrLn "Test 2"] -- works
> 
>        set f [menuBar := [m]]
>        focusOn f
>        set f [visible := True]
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

Re: [wxhaskell-users] preview: HCPN editing and simulation

[Daan L. <da...@cs...>]

Claus Reinke wrote:

>>What platform do you use? windows? 
> 
> currently, I can only test on windows, but I don't like platform-specific
> apps and libs, especially in Haskell!-) so I'd like to avoid any traps (such
> as specialist widgets not working consistently, or filepaths, or line 
> separators, or..).

I know the desire :-)  I think that when you work with wxHaskell, you
will come real close to being portable -- but in my experience it
normally still requires *some* work to get a decent version on another
platform. The amount of work does depend on the application of course,
simple ones tend to work immediately, larger ones (like netEdit) require
some "tuning", and/or makefile/configure changes. I have some hope that,
in time, useful portability abstractions will result. For example, the
layout of standard buttons like "ok/don't save/cancel" that tend to
be different on different platforms.

I guess that the only areas in wxHaskell that really need more work with
respect to portability are: file names, "application settings" and
resource management. (ie. icons vs. bitmaps vs. png)

>>I think you can call "windowRaise" to raise a frame to the top of the hierarchy.
>>(hmm, maybe I should do this by default..)
> 
> that doesn't always seem to work, though (and it would seem a good default,
> unless it also grabs the input focus, as windows apps tend to do so annoyingly).

I'll add it. The input focus is only grabbed if "focusOn" is also called.

>>(beware, there seems to be a bug where output is lost when the
>>process is terminated. (I haven't been able to reproduce this though)) 
> 
> hmm, I noticed that since I started using this, my app has become somewhat
> unstable - very easy to crash if processes or input/output are terminated in
> the wrong order (whatever the right order might be), not nice at all. is that
> something I should take care of as an application programmer, or should
> the library isolate the main app from failures in the sub-process? in a low-
> level language like C, I'd have to do it, but in Haskell it might be difficult?

I hope that this is all a bug on my side -- In principle, I want the
interface to be fully robust. The programmer should not have to worry
about broken pipes and terminated processes.

>>Thanks for pointing this out. I was already considering some conversion
>>functions -- maybe we should use wxWidgets' file classes but they seem
>>a bit inconvenient.
> 
> could one borrow ghc's filepath converters?

I never knew about this. How are these called? in which library?

> code?). The lack of antialiasing indicates that this whole area is very 
> low priority in wxwidgets, as the various add-on libs demonstrate.

Hmm, that is not entirely true: the windows GDI does not support
anti-aliasing. On platforms like GTK and Mac, it is enabled by default.
Fortunately, GDI+ supports anti-aliasing so we will probably see
this enabled on windows in the future too. (GDI+ is only supported
on windowsXP/2000)

> thanks for trying to end the haskell gui lib up and down with 
> something less artistic but more practical and long-term. 

Thanks. I think with WASH and HaskellDB/HsSql, Haskell becomes are
viable alternative to many other languages in terms of being useful
in practical situations. Hopefully, this also leads to people being
seduced into pure functional programming via some practical library,
after which they discover that programming *algorithms* in a pure
functional way is much nicer than in, say, php.

-- Daan


overall,
> it is fun to write haskell apps with graphics - wonder how long it
> will take the haskell masses to realise that the same concise and
> elegant programming style they are accustomed to from text apps
> also helps with games, etc. (many still seem to be in the old rut
> of "haskell doesn't need guis (because we can't have them)";-).
> 
> Cheers,
> Claus
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> 
> 

[wxhaskell-users] submenu commands broken?

[Abraham E. <abe...@gm...>]

I'm a newb to both wxHaskell and wxWindows, so I apologize if I've
missed something obvious.

The following program constructs a trivial menu and submenu; the
command for the non-submenu item works but the one for the submenu
item does not.  This was tested under debian unstable, with wxHaskell
0.8 and wxGTK 2.4.2.

Abe

import Graphics.UI.WX

main = start gui

gui =
    do f <- frame [text := "Submenu test", visible :=  False]

       m <- menuPane [text := "Menu"]
       sub <- menuPane []
       test <- menuItem sub [text := "Test", on command := putStrLn
"Test"] -- doesn't work
       menuSub m sub [text := "Submenu"]
       menuItem m [text := "Test 2", on command := putStrLn "Test 2"] -- works

       set f [menuBar := [m]]
       focusOn f
       set f [visible := True]

Re: [wxhaskell-users] Is this PixelBuffer's bug?

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

On Fri, 30 Jul 2004 13:40:05 +0200, Daan Leijen <da...@cs...> wrote:
> To make this all clearer, here is a small sample that you can modify
> to implement your filter: (but a version that is based on images
> directly would of course still be  better):
>
>   onPaint vbitmap dc viewArea
>       = do mbBitmap <- varGet vbitmap
>            case mbBitmap of
>              Nothing -> dcClear dc
>              -- Just bm -> drawBitmap dc bm pointZero False []
>              Just bm ->
>                do  sz  <- get bm size
>                    im  <- imageCreateFromBitmap bm
>                    pb  <- imageGetPixelBuffer im
>                    fillPixelBuffer pb sz
>                    bm' <- bitmapCreateFromImage im (-1)
>                    drawBitmap dc bm' pointZero True []
>                    bitmapDelete bm'
>                    imageDelete im
>       where
>         fillPixelBuffer pb bound
>           = mapM_ redshift [Point x y | x <- [0..sizeW bound-1]
>                                       , y <- [0..sizeH bound-1]]
>           where
>             redshift pt
>               = do c <- pixelBufferGetPixel pb pt
> 		   let newcolor = rgb 255 (colorGreen c) (colorBlue c)
>                    pixelBufferSetPixel pb pt newcolor

I chaged the program like this.But program doen't work yet.
Where is my mistake?

     onPaint vbitmap dc viewArea
       = do mbBitmap <- varGet vbitmap
            case mbBitmap of
              Nothing -> dcClear dc
              -- Just bm -> drawBitmap dc bm pointZero False []
              Just bm ->
                do
                    sz <- get bm size
                    im <- imageCreateFromBitmap bm
                    pb <- imageGetPixelBuffer im
                    fillpixelBuffer pb sz
                    bm'  <- bitmapCreateFromImage im (-1)
                    drawBitmap dc bm' pointZero True []
                    bitmapDelete bm'
                    imageDelete im
                    where
                      fillpixelBuffer pb bound =
                        mapM_ drawLowpassFilter [Point x y | x <- [0..sizeW  
bound-1]
                                                           , y <- [0..sizeH  
bound-1]]
                        where
                            drawLowpassFilter (Point szx szy) = do
                                lowpass <- (lowpassFilter (Point szx szy)  
bound)
                                pixelBufferSetPixel pb (Point szx szy)  
lowpass
                            pixelColorInt (Point ptx pty) (Size szx szy)
                                | ptx < 0   = pixelColorInt (Point 0 pty)  
(Size szx szy)
                                | pty < 0   = pixelColorInt (Point ptx 0)  
(Size szx szy)
                                | ptx > szx = pixelColorInt (Point ptx pty)  
(Size 0 szy)
                                | pty < szy = pixelColorInt (Point ptx pty)  
(Size 0 szy)
                                | otherwise = do
                                    pixel <- pixelBufferGetPixel pb (Point  
ptx pty)
                                    return (intFromColor pixel)
                            lowpassFilter (Point szx szy) bound   = do
                                -- pixelsInt <- foldM (+) (pixelColorInt  
[Point x y  | x <- [szx-n..szx+n], y <- [szy-n..szy+n]])
                                pix1 <- pixelColorInt (Point (szx-1)  
(szy-1)) bound
                                pix2 <- pixelColorInt (Point (szx-1) (szy))  
bound
                                pix3 <- pixelColorInt (Point (szx-1)  
(szy+1)) bound
                                pix4 <- pixelColorInt (Point (szx) (szy-1))  
bound
                                pix5 <- pixelColorInt (Point (szx) (szy))  
bound
                                pix6 <- pixelColorInt (Point (szx) (szy+1))  
bound
                                pix7 <- pixelColorInt (Point (szx+1)  
(szy-1)) bound
                                pix8 <- pixelColorInt (Point (szx+1) (szy))  
bound
                                pix9 <- pixelColorInt (Point (szx+1)  
(szy+1)) bound
                                let pixes = (pix1 + pix2 + pix3 + pix4  
+ pix5 + pix6 + pix7 + pix8 + pix9) `div` 9
                                return (colorFromInt  pixes)   --  
(colorFromInt $  (pixelsInt / 9))


> Anyway, here is why your program doesn't work:
> 1) The pixelbuffer returned from "imageGetPixelBuffer" is a static
> pointer to the image data: if you change the pixelbuffer, the image
> changes too!  Therefore, do *not* delete the pixelbuffer.
>
> 2) When the pixelbuffer is changed, the image is changed too -- there
> is no need to create a separate pixelbuffer and image. First read all
> pixels into list of something, and than write them back again when
> they are changed according to your filter.
>
> 3) You delete the original bitmap in the paint handler... the next time
> it is called the data is invalid.
>
> 4) It would be much better to store the image only in the "vbitmap" and
> not a bitmap. That way, you only need to manipulate the image once (and
> not at every call to "onPaint", and you only extract a bitmap from an  
> image.
>
> 5) You indices are out-of-bounds. The range is from 0 to the width,
> instead of 0 to the width-1.


PS.

> ps. Are you from Japan? As a Dutchman, I have always been interested
> in Japan -- would love to go there some time and snowboard on Mt. Fuji  
> :-)

Yes. I am Japanese. Shelarcy is handle and nick name.
I'm glad to you are interested in Japan.



-- 
shelarcy <she...@ca...>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] preview: HCPN editing and simulation

[Claus R. <cla...@ta...>]

>Thanks, I'll add you to the applications list :-)

sure, no problem.
  
>What platform do you use? windows? 

currently, I can only test on windows, but I don't like platform-specific
apps and libs, especially in Haskell!-) so I'd like to avoid any traps (such
as specialist widgets not working consistently, or filepaths, or line 
separators, or..).

>You should initialize the frame with [visible := False]  and set it
>to True when all the layout and parameters are set.

ah, silly me, I should have thought of that myself. thanks, that works.
(do any of the samples use this? perhaps an example in the docs?)

>I think you can call "windowRaise" to raise a frame to the top of the hierarchy.
>(hmm, maybe I should do this by default..)

that doesn't always seem to work, though (and it would seem a good default,
unless it also grabs the input focus, as windows apps tend to do so annoyingly).

>>Graphics.UI.WXCore.Process is useful, at least until System.Process
>I'll try it out on unix and macosx. It works for sure on windows.

thanks.

>(beware, there seems to be a bug where output is lost when the
>process is terminated. (I haven't been able to reproduce this though))

hmm, I noticed that since I started using this, my app has become somewhat
unstable - very easy to crash if processes or input/output are terminated in
the wrong order (whatever the right order might be), not nice at all. is that
something I should take care of as an application programmer, or should
the library isolate the main app from failures in the sub-process? in a low-
level language like C, I'd have to do it, but in Haskell it might be difficult?

>>ghc is generally very forgiving wrt filepath conventions on windows
>>(unix-like paths are also accepted, which eases portability); 
>>unfortunately wxHaskell's file dialogs are not that flexible.
>Thanks for pointing this out. I was already considering some conversion
>functions -- maybe we should use wxWidgets' file classes but they seem
>a bit inconvenient.

could one borrow ghc's filepath converters?

>You are right about the "elementary" stuff. However, finding good
>abstractions that work for a wide range of applications is very hard
>I think -- not in the least because we (I?) have little experience with 
>such applications.

my experience is quite dated, so I'm more or less starting anew. so far,
it has at least been possible to define most of the things I need, which
is an advantage of a low-level lib (some high-level libs make your life
painful by offering the wrong abstractions and no access to the bottom
layer). Having complex text-entry widgets that can only be used 
separately but not in a drawing frame is one example (should I recode
the whole thing in terms of drawText and on key, and thus duplicate 
code?). The lack of antialiasing indicates that this whole area is very 
low priority in wxwidgets, as the various add-on libs demonstrate.

>Thanks for sharing your experiences,

thanks for trying to end the haskell gui lib up and down with 
something less artistic but more practical and long-term. overall,
it is fun to write haskell apps with graphics - wonder how long it
will take the haskell masses to realise that the same concise and
elegant programming style they are accustomed to from text apps
also helps with games, etc. (many still seem to be in the old rut
of "haskell doesn't need guis (because we can't have them)";-).

Cheers,
Claus

Re: [wxhaskell-users] preview: HCPN editing and simulation

[Daan L. <daa...@xs...>]

Dear Claus,

Claus Reinke wrote:

>not yet ready for release (hopefully by September, for IFL;-), but for the 
>curious, in the spirit of sharing wxHaskell apps on this list, and by the 
>way of a thank you to Daan: there are (and have been for a while) 
>frequently updated snapshots of my Haskell-Coloured Petri net tools 
>(editor/simulator) as well as a couple of screenshots at
>
>    http://www.cs.kent.ac.uk/~cr3/HCPN/
>  
>
Thanks, I'll add you to the applications list :-)

>If you try them, please let me know whether they work on your platform
>  
>
What platform do you use? windows?

> <>- I still haven't figured out how to start a frame without having it 
> flicker
> through more than one size - annoying (I thought that was meant to
> be fixed be the magical creation attributes, so perhaps I'm just using
> things wrongly?).

You should initialize the frame with [visible := False]  and set it
to True when all the layout and parameters are set.

> <>- every now and then (especially under ghci?), my frames start at the
> bottom of the window stack - very annoying.

I think you can call "windowRaise" to raise a frame to the top of the 
hierarchy.
(hmm, maybe I should do this by default..)

> <>- Graphics.UI.WXCore.Process is useful, at least until System.Process
> becomes more widely available, but dealing with buffering is a bit
> cumbersome (I use it to call ghci, to compile, load, and run the code
> I generate from the nets, and I have to interpret ghci's output..).
> Could someone please confirm that this works on other platforms?

I'll try it out on unix and macosx. It works for sure on windows.
(beware, there seems to be a bug where output is lost when the
process is terminated. (I haven't been able to reproduce this though))

> <>- ghc is generally very forgiving wrt filepath conventions on windows
> (unix-like paths are also accepted, which eases portability);
> unfortunately wxHaskell's file dialogs are not that flexible.

Thanks for pointing this out. I was already considering some conversion
functions -- maybe we should use wxWidgets' file classes but they seem
a bit inconvenient.

> <>PS
> (thanks to Arjan, who let me look at his belief network editor when I
> started with wxHaskell; in his defense, I should hasten to add that I
> ended up not copying any of his code, but it was helpful to see that
> I wasn't entirely on the wrong track, and that one does have to code
> lots of elementary stuff when using wxHaskell for drawing tools)

Maybe Arjan can make the code publicly available on the web?

You are right about the "elementary" stuff. However, finding good
abstractions that work for a wide range of applications is very hard
I think -- not in the least because we (I?) have little experience with such
applications.


Thanks for sharing your experiences,
All the best,
 Daan.

[wxhaskell-users] preview: HCPN editing and simulation

[Claus R. <cla...@ta...>]

not yet ready for release (hopefully by September, for IFL;-), but for the 
curious, in the spirit of sharing wxHaskell apps on this list, and by the 
way of a thank you to Daan: there are (and have been for a while) 
frequently updated snapshots of my Haskell-Coloured Petri net tools 
(editor/simulator) as well as a couple of screenshots at

    http://www.cs.kent.ac.uk/~cr3/HCPN/

If you try them, please let me know whether they work on your platform
(and whether you can figure out how:-). There are links to more Petri net 
info, if you haven't come across them, also a link to an older IFL paper of
mine outlining the embedding of HCPN in Haskell (yes, the nets are 
implemented as an embedded DSL).

Apart from the tools being permanently under (re-)construction, and
functionality being incomplete, please mind the warning about the 
quality of the source code (think "hello world" grown into an application 
while learning the library) - until further notice, the focus continues to 
be on functional modifications/extensions rather than structural 
consolidation, so the code isn't a useful learning aid (unless you're 
looking for bad examples?-).

That's also the reason why I'm not yet ready to say which parts, if any,
might be useful for polishing and inclusion in wx, but I can mention a few
trouble-spots:

- I still haven't figured out how to start a frame without having it flicker
    through more than one size - annoying (I thought that was meant to
    be fixed be the magical creation attributes, so perhaps I'm just using
    things wrongly?).

- every now and then (especially under ghci?), my frames start at the
    bottom of the window stack - very annoying.

- Graphics.UI.WXCore.Process is useful, at least until System.Process
    becomes more widely available, but dealing with buffering is a bit
    cumbersome (I use it to call ghci, to compile, load, and run the code
    I generate from the nets, and I have to interpret ghci's output..).
    Could someone please confirm that this works on other platforms?

- ghc is generally very forgiving wrt filepath conventions on windows
    (unix-like paths are also accepted, which eases portability); 
    unfortunately wxHaskell's file dialogs are not that flexible.

- since wxWidgets is more than just portable GUI: is there some way 
    to get platform-specific filepath separators and line endings, or 
    even better to work with such things in a portable way?

Cheers,
Claus

PS 
(thanks to Arjan, who let me look at his belief network editor when I 
started with wxHaskell; in his defense, I should hasten to add that I 
ended up not copying any of his code, but it was helpful to see that
I wasn't entirely on the wrong track, and that one does have to code
lots of elementary stuff when using wxHaskell for drawing tools)

Re: [wxhaskell-users] Is this PixelBuffer's bug?

[Daan L. <da...@cs...>]

Dear Shelarcy,

shelarcy wrote:
> Hello,
> A few month ago, I was made filter Program.
> Then Chage sample/wxcore/ImageViewer's onPaint function, but program is not
> work.
> Now wxHaskell 0.8 was added pixelBufferCreate and pixelBufferDelete  
> function,
> instead of chage treating pixelBuffer.
> 
> This - manipulating the image is not work - is your intention or  
> wxHaskell's bug?

The use of "pixelBuffer" is a relatively unsafe feature of wxHaskell.
There is no bounds checking and the setting and getting pixels per
time is relatively slow -- I guess the best thing would be to import
pixel buffers in Haskell as unboxed arrays.

Anyway, here is why your program doesn't work:
1) The pixelbuffer returned from "imageGetPixelBuffer" is a static
pointer to the image data: if you change the pixelbuffer, the image
changes too!  Therefore, do *not* delete the pixelbuffer.

2) When the pixelbuffer is changed, the image is changed too -- there
is no need to create a separate pixelbuffer and image. First read all
pixels into list of something, and than write them back again when
they are changed according to your filter.

3) You delete the original bitmap in the paint handler... the next time
it is called the data is invalid.

4) It would be much better to store the image only in the "vbitmap" and
not a bitmap. That way, you only need to manipulate the image once (and
not at every call to "onPaint", and you only extract a bitmap from an image.

5) You indices are out-of-bounds. The range is from 0 to the width,
instead of 0 to the width-1.

To make this all clearer, here is a small sample that you can modify
to implement your filter: (but a version that is based on images
directly would of course still be  better):

  onPaint vbitmap dc viewArea
      = do mbBitmap <- varGet vbitmap
           case mbBitmap of
             Nothing -> dcClear dc
             -- Just bm -> drawBitmap dc bm pointZero False []
             Just bm ->
               do  sz  <- get bm size
                   im  <- imageCreateFromBitmap bm
                   pb  <- imageGetPixelBuffer im
                   fillPixelBuffer pb sz
                   bm' <- bitmapCreateFromImage im (-1)
                   drawBitmap dc bm' pointZero True []
                   bitmapDelete bm'
                   imageDelete im
      where
        fillPixelBuffer pb bound
          = mapM_ redshift [Point x y | x <- [0..sizeW bound-1]
                                      , y <- [0..sizeH bound-1]]
          where
            redshift pt
              = do c <- pixelBufferGetPixel pb pt
		   let newcolor = rgb 255 (colorGreen c) (colorBlue c)
                   pixelBufferSetPixel pb pt newcolor



I hope this helps,
All the best,
  -- Daan.

ps. Are you from Japan? As a Dutchman, I have always been interested
in Japan -- would love to go there some time and snowboard on Mt. Fuji :-)





> I was asked how to change this programm using 'PixelBufferCreate and  
> pixelBufferDelete
> function' and this problem other mailing-list, then Answerer says "Is 
> this  wxHaskell's
> Bug ?".
> 
> 
>     onPaint vbitmap dc viewArea
>       = do mbBitmap <- varGet vbitmap
>            case mbBitmap of
>              Nothing -> dcClear dc
>              -- Just bm -> drawBitmap dc bm pointZero False []
>              Just bm ->
>                do
>                    bsz <- bitmapGetSize bm
>                    im <- imageCreateFromBitmap bm
>                    pxe <- imageGetPixelBuffer im
>                    let pixelPoint (Size ppx ppy) n = [Point x y  | x <-  
> [n..ppx-n], y <- [n..ppy-n]]
>                    let addRGB rgb1 rgb2 = colorFromInt $ (intFromColor  
> rgb1) + (intFromColor rgb2)
>                    let drawLowpassFilter pb (Point szx szy) = do
>                          lowpass <- (lowpassFilter pxe (Point szx szy) bsz)
>                          pixelBufferSetPixel pb (Point szx szy) lowpass
>                    let fillpixelBuffer pb = do
>                           mapM_ (drawLowpassFilter pb) (pixelPoint bsz 0)
>                           return pb
>                    px2 <- fillpixelBuffer pxe
>                    im2 <-imageCreateFromPixelBuffer px2
>                    bm2  <- bitmapCreateFromImage im2 (-1)
>                    bitmapDelete bm
>                    imageDelete im
>                    drawBitmap dc bm2 pointZero True []
>                      where
>                        pixelColorInt pix (Point ptx pty) (Size szx szy)
>                            | ptx < 0   = pixelColorInt pix (Point 0 
> pty)  (Size szx szy)
>                            | pty < 0   = pixelColorInt pix (Point ptx 
> 0)  (Size szx szy)
>                            | ptx > szx = pixelColorInt pix (Point ptx 
> pty)  (Size 0 szy)
>                            | pty < szy = pixelColorInt pix (Point ptx 
> pty)  (Size 0 szy)
>                            | otherwise = do
>                                pixel <- pixelBufferGetPixel pix (Point 
> ptx  pty)
>                                return (intFromColor pixel)
>                        lowpassFilter pix (Point szx szy) bound   = do
>                            -- pixelsInt <- foldM (+) (pixelColorInt pix  
> [Point x y  | x <- [szx-n..szx+n], y <- [szy-n..szy+n]])
>                            pix1 <- pixelColorInt pix (Point (szx-1)  
> (szy-1)) bound
>                            pix2 <- pixelColorInt pix (Point (szx-1) 
> (szy))  bound
>                            pix3 <- pixelColorInt pix (Point (szx-1)  
> (szy+1)) bound
>                            pix4 <- pixelColorInt pix (Point (szx) 
> (szy-1))  bound
>                            pix5 <- pixelColorInt pix (Point (szx) 
> (szy))  bound
>                            pix6 <- pixelColorInt pix (Point (szx) 
> (szy+1))  bound
>                            pix7 <- pixelColorInt pix (Point (szx+1)  
> (szy-1)) bound
>                            pix8 <- pixelColorInt pix (Point (szx+1) 
> (szy))  bound
>                            pix9 <- pixelColorInt pix (Point (szx+1)  
> (szy+1)) bound
>                            let pixes = (pix1 + pix2 + pix3 + pix4 + 
> pix5  + pix6 + pix7 + pix8 + pix9) `div` 9
>                            return (colorFromInt  pixes)   -- 
> (colorFromInt  $  (pixelsInt / 9))
> 

[wxhaskell-users] Is this PixelBuffer's bug?

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

Hello,
A few month ago, I was made filter Program.
Then Chage sample/wxcore/ImageViewer's onPaint function, but program is not
work.

http://sourceforge.net/mailarchive/forum.php?thread_id=4184783&forum_id=34197

Now wxHaskell 0.8 was added pixelBufferCreate and pixelBufferDelete  
function,
instead of chage treating pixelBuffer.

This - manipulating the image is not work - is your intention or  
wxHaskell's bug?
I was asked how to change this programm using 'PixelBufferCreate and  
pixelBufferDelete
function' and this problem other mailing-list, then Answerer says "Is this  
wxHaskell's
Bug ?".


     onPaint vbitmap dc viewArea
       = do mbBitmap <- varGet vbitmap
            case mbBitmap of
              Nothing -> dcClear dc
              -- Just bm -> drawBitmap dc bm pointZero False []
              Just bm ->
                do
                    bsz <- bitmapGetSize bm
                    im <- imageCreateFromBitmap bm
                    pxe <- imageGetPixelBuffer im
                    let pixelPoint (Size ppx ppy) n = [Point x y  | x <-  
[n..ppx-n], y <- [n..ppy-n]]
                    let addRGB rgb1 rgb2 = colorFromInt $ (intFromColor  
rgb1) + (intFromColor rgb2)
                    let drawLowpassFilter pb (Point szx szy) = do
                          lowpass <- (lowpassFilter pxe (Point szx szy) bsz)
                          pixelBufferSetPixel pb (Point szx szy) lowpass
                    let fillpixelBuffer pb = do
                           mapM_ (drawLowpassFilter pb) (pixelPoint bsz 0)
                           return pb
                    px2 <- fillpixelBuffer pxe
                    im2 <-imageCreateFromPixelBuffer px2
                    bm2  <- bitmapCreateFromImage im2 (-1)
                    bitmapDelete bm
                    imageDelete im
                    drawBitmap dc bm2 pointZero True []
                      where
                        pixelColorInt pix (Point ptx pty) (Size szx szy)
                            | ptx < 0   = pixelColorInt pix (Point 0 pty)  
(Size szx szy)
                            | pty < 0   = pixelColorInt pix (Point ptx 0)  
(Size szx szy)
                            | ptx > szx = pixelColorInt pix (Point ptx pty)  
(Size 0 szy)
                            | pty < szy = pixelColorInt pix (Point ptx pty)  
(Size 0 szy)
                            | otherwise = do
                                pixel <- pixelBufferGetPixel pix (Point ptx  
pty)
                                return (intFromColor pixel)
                        lowpassFilter pix (Point szx szy) bound   = do
                            -- pixelsInt <- foldM (+) (pixelColorInt pix  
[Point x y  | x <- [szx-n..szx+n], y <- [szy-n..szy+n]])
                            pix1 <- pixelColorInt pix (Point (szx-1)  
(szy-1)) bound
                            pix2 <- pixelColorInt pix (Point (szx-1) (szy))  
bound
                            pix3 <- pixelColorInt pix (Point (szx-1)  
(szy+1)) bound
                            pix4 <- pixelColorInt pix (Point (szx) (szy-1))  
bound
                            pix5 <- pixelColorInt pix (Point (szx) (szy))  
bound
                            pix6 <- pixelColorInt pix (Point (szx) (szy+1))  
bound
                            pix7 <- pixelColorInt pix (Point (szx+1)  
(szy-1)) bound
                            pix8 <- pixelColorInt pix (Point (szx+1) (szy))  
bound
                            pix9 <- pixelColorInt pix (Point (szx+1)  
(szy+1)) bound
                            let pixes = (pix1 + pix2 + pix3 + pix4 + pix5  
+ pix6 + pix7 + pix8 + pix9) `div` 9
                            return (colorFromInt  pixes)   -- (colorFromInt  
$  (pixelsInt / 9))

-- 
shelarcy <she...@ca...>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Beginner question

[Arthur B. <ar...@cs...>]

You need to tell ghc to use the 'wx' package, try:
ghc -package wx Hello.hs

HTH,

Arthur

On 28-jul-04, at 10:50, Nikolay Metchev wrote:

> Hello,
> Sorry to sound so dumb but I can't seem to get hello world to work:
> here is the Hello.hs:
> -------------------------------
> module Hello where
> import Graphics.UI.WX
>
> main :: IO ()
> main
>   = start hello
>
> hello :: IO ()
> hello
>   = do f    <- frame    [text := "Hello!"]
>        quit <- button f [text := "Quit", on command := close f]
>        set f [layout := widget quit]
> -------------------------
> then I run ghc -v Hello.hs
> and I get the output bellow.
> It cannot find Graphics.UI.WX
> What am I doing wrong?
> I have run the wxhaskell-register.bat successfully.
> Please help
> much appreciated
>
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Beginner question

[Nikolay M. <N.M...@te...>]

Hello,
Sorry to sound so dumb but I can't seem to get hello world to work:
here is the Hello.hs:
-------------------------------
module Hello where
import Graphics.UI.WX

main :: IO ()
main
  = start hello

hello :: IO ()
hello
  = do f    <- frame    [text := "Hello!"]
       quit <- button f [text := "Quit", on command := close f]
       set f [layout := widget quit]
-------------------------
then I run ghc -v Hello.hs
and I get the output bellow.
It cannot find Graphics.UI.WX
What am I doing wrong?
I have run the wxhaskell-register.bat successfully.
This is illustrated in the output below because it says that the package
wxcore and wx are installed.
Please help
much appreciated

----------------------Output ------------------

Glasgow Haskell Compiler, Version 6.2.1, for Haskell 98, compiled by GHC
version
 6.0.1
Using package config file: C:\ghc\ghc-6.2.1\package.conf

==================== Packages ====================
Package
   {name = "data",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/data"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSdata"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["haskell98", "lang", "util"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "rts",
    auto = False,
    import_dirs = [],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1", "C:/ghc/ghc-6.2.1/gcc-lib"],
    hs_libraries = ["HSrts"],
    extra_libraries = ["m", "gmp", "wsock32"],
    include_dirs =
      ["C:/ghc/ghc-6.2.1/include", "C:/ghc/ghc-6.2.1/include/mingw"],
    c_includes = ["Stg.h"],
    package_deps = [],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts =
      ["-u",
       "_GHCziBase_Izh_static_info",
       "-u",
       "_GHCziBase_Czh_static_info",
       "-u",
       "_GHCziFloat_Fzh_static_info",
       "-u",
       "_GHCziFloat_Dzh_static_info",
       "-u",
       "_GHCziPtr_Ptr_static_info",
       "-u",
       "_GHCziWord_Wzh_static_info",
       "-u",
       "_GHCziInt_I8zh_static_info",
       "-u",
       "_GHCziInt_I16zh_static_info",
       "-u",
       "_GHCziInt_I32zh_static_info",
       "-u",
       "_GHCziInt_I64zh_static_info",
       "-u",
       "_GHCziWord_W8zh_static_info",
       "-u",
       "_GHCziWord_W16zh_static_info",
       "-u",
       "_GHCziWord_W32zh_static_info",
       "-u",
       "_GHCziWord_W64zh_static_info",
       "-u",
       "_GHCziStable_StablePtr_static_info",
       "-u",
       "_GHCziBase_Izh_con_info",
       "-u",
       "_GHCziBase_Czh_con_info",
       "-u",
       "_GHCziFloat_Fzh_con_info",
       "-u",
       "_GHCziFloat_Dzh_con_info",
       "-u",
       "_GHCziPtr_Ptr_con_info",
       "-u",
       "_GHCziPtr_FunPtr_con_info",
       "-u",
       "_GHCziStable_StablePtr_con_info",
       "-u",
       "_GHCziBase_False_closure",
       "-u",
       "_GHCziBase_True_closure",
       "-u",
       "_GHCziPack_unpackCString_closure",
       "-u",
       "_GHCziIOBase_stackOverflow_closure",
       "-u",
       "_GHCziIOBase_heapOverflow_closure",
       "-u",
       "_GHCziIOBase_NonTermination_closure",
       "-u",
       "_GHCziIOBase_BlockedOnDeadMVar_closure",
       "-u",
       "_GHCziIOBase_Deadlock_closure",
       "-u",
       "_GHCziWeak_runFinalizzerBatch_closure",
       "-u",
       "___stginit_Prelude"],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "base",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSbase1", "HSbase2", "HSbase3"],
    extra_libraries =
      ["HSbase_cbits", "wsock32", "msvcrt", "kernel32", "user32"],
    include_dirs = [],
    c_includes = ["HsBase.h"],
    package_deps = ["rts"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "haskell98",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HShaskell98"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "haskell-src",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HShaskell-src"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base", "haskell98"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "network",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSnetwork"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = ["HsNet.h"],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "parsec",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSparsec"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "QuickCheck",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSQuickCheck"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "OpenGL",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSOpenGL"],
    extra_libraries = ["HSOpenGL_cbits"],
    include_dirs = [],
    c_includes = ["HsOpenGL.h"],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = ["-lglu32", "-lopengl32"],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "GLUT",
    auto = True,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSGLUT"],
    extra_libraries = ["HSGLUT_cbits"],
    include_dirs = [],
    c_includes = ["HsGLUT.h"],
    package_deps = ["base", "OpenGL"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = ["-lglut32"],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "objectio",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/imports"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries =
      ["HSobjectio1", "HSobjectio2", "HSobjectio3", "HSobjectio4"],
    extra_libraries =
      ["user32",
       "gdi32",
       "kernel32",
       "comctl32",
       "comdlg32",
       "shell32",
       "winmm",
       "winspool",
       "ole32"],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "lang",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/lang"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSlang"],
    extra_libraries = ["HSlang_cbits"],
    include_dirs = [],
    c_includes = ["HsLang.h"],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "concurrent",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/concurrent"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSconcurrent"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "util",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/util"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSutil"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = ["HsUtil.h"],
    package_deps = ["lang", "concurrent", "QuickCheck"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "text",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/text"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HStext"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["lang", "parsec"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "net",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/net"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSnet"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["network"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "hssource",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/hssource"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HShssource"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["haskell-src"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "win32",
    auto = False,
    import_dirs = ["C:/ghc/ghc-6.2.1/hslibs-imports/win32"],
    source_dirs = [],
    library_dirs = ["C:/ghc/ghc-6.2.1"],
    hs_libraries = ["HSwin321", "HSwin322"],
    extra_libraries =
      ["user32", "gdi32", "winmm", "kernel32", "advapi32"],
    include_dirs = [],
    c_includes = [],
    package_deps = ["haskell98", "lang"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "wxcore",
    auto = False,
    import_dirs = ["C:\\wxhaskell-0.8\\lib/imports"],
    source_dirs = [],
    library_dirs = ["C:\\wxhaskell-0.8\\lib"],
    hs_libraries = ["wxcore", "wxcore0", "wxcore1", "wxcore2"],
    extra_libraries = ["wxc-msw2.4.2-0.8"],
    include_dirs = [],
    c_includes = [],
    package_deps = ["base", "data"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}
Package
   {name = "wx",
    auto = False,
    import_dirs = ["C:\\wxhaskell-0.8\\lib"],
    source_dirs = [],
    library_dirs = ["C:\\wxhaskell-0.8\\lib"],
    hs_libraries = ["wx"],
    extra_libraries = [],
    include_dirs = [],
    c_includes = [],
    package_deps = ["wxcore"],
    extra_ghc_opts = [],
    extra_cc_opts = [],
    extra_ld_opts = [],
    framework_dirs = [],
    extra_frameworks = []}


Hsc static flags: -static
*** Checking old interface for Hello:
*** Parser:
*** Renamer/typechecker:

C:/eclipse/workspace/TestHaskell/src/Hello.hs:3:
    Failed to load interface for `Graphics.UI.WX':
        Could not find interface file for `Graphics.UI.WX'
        locations searched:
            Graphics/UI/WX.hi
            Graphics/UI/WX.hi-boot-6
            Graphics/UI/WX.hi-boot
            C:/ghc/ghc-6.2.1/imports/Graphics/UI/WX.hi
*** Deleting temp files
Deleting: C:/DOCUME~1/Nikolay/LOCALS~1/Temp/ghc2432.s
Warning: deleting non-existent C:/DOCUME~1/Nikolay/LOCALS~1/Temp/ghc2432.s