wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] How about use IOUArray Point Color or IOArray Point Color?

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

shelarcy wrote:
> I sent e-mail Daan directly, so this is summary.
> Result : IOUArray doesn't make faster this program.
> Program using Array is much faster.

Hmm, that is a shame. I do not see an obvious way to
make this faster in Haskell -- except for making Haskell
strict :-)

All the best,
And thanks for the experiment,
-- Daan.

> 
> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/haskell/haskell-jp/493
> 
> 
> On Tue, 09 Nov 2004 15:37:00 +0100, Daan Leijen <da...@cs...> wrote:
> 
>>> I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>>> recent days, so I tested Anti-Alias function to know how much faster.
>>>
>>> http://sourceforge.net/mailarchive/message.php?msg_id=9127088
>>>
>>> I'm not satisfied this performance. This function is too slowly yet.
>>> I think that bottleneck is read/write Array.
>>>
>>> http://d.hatena.ne.jp/tanakh/20040809#p1
>>>
>>> How about use IOUArray or IOArray?
>>>
>>>
>> I am currently not in the position to tweak much about this code (as
>> other things
>> have priority now, like drag&drop and printing). However, if you feel
>> that you can
>> make it faster by using IOUArray or something, please try to do so. If
>> you can
>> package it up nicely, I will most certainly add your patches to  
>> wxHaskell.
> 
> 

Re: [wxhaskell-users] How about use IOUArray Point Color or IOArray Point Color?

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

I sent e-mail Daan directly, so this is summary.
Result : IOUArray doesn't make faster this program.
Program using Array is much faster.

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/haskell/haskell-jp/493


On Tue, 09 Nov 2004 15:37:00 +0100, Daan Leijen <da...@cs...> wrote:
>> I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>> recent days, so I tested Anti-Alias function to know how much faster.
>>
>> http://sourceforge.net/mailarchive/message.php?msg_id=9127088
>>
>> I'm not satisfied this performance. This function is too slowly yet.
>> I think that bottleneck is read/write Array.
>>
>> http://d.hatena.ne.jp/tanakh/20040809#p1
>>
>> How about use IOUArray or IOArray?
>>
>>
> I am currently not in the position to tweak much about this code (as
> other things
> have priority now, like drag&drop and printing). However, if you feel
> that you can
> make it faster by using IOUArray or something, please try to do so. If
> you can
> package it up nicely, I will most certainly add your patches to  
> wxHaskell.

-- 
shelarcy <shelarcy capella.freemail.ne.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Sigsev on Process example

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

Hi Benedikt,

Thanks for your report, I'll have to read it more carefully tosee
if it helps or not, but it is good to know where it goes wrong.
Maybe I'll find it now.

Anyway, you can easily compile with debugging information
by editing the makefile. On line 637 you just add the gcc debug flags to
the given flags in WXC-CXXFLAGS.

Maybe you have to add some HCFLAGS too?   (write HCFLAGS += ...
somewhere after the include's in the makefile.

The "wxcd" thing is just when you are using MS visual studio.

-- Daan.

ps. Let's take this discussion offline, I reconfigured my spam filter
so I guess you can safely send me mail now :-)

Benedikt Grundmann wrote:

>Hello Daan, Hello List,
>
>I have some free time this weekend which I want to use to track down
>this sigsev bug.  Interestingly the bug does not appear that often 
>when running the Process.hs in a debugger.  But most of the time it
>does crash when I try to execute the unknown cmd `cmd' to times in a
>row.  I compiled process using ghc -debug -package wx --make Process.hs
>gdb says:
>
>Starting program: /home/dreamer/programming/wxhaskell/wxhaskell-0.8/samples/wx/a.out 
>[Thread debugging using libthread_db enabled]
>[New Thread 1090297408 (LWP 1826)]
>Detaching after fork from child process 1829.
>[New Thread 1100573616 (LWP 1830)]
>[New Thread 1108962224 (LWP 1831)]
>[Thread 1108962224 (zombie) exited]
>[Thread 1100573616 (zombie) exited]
>Detaching after fork from child process 1832.
>[New Thread 1100573616 (LWP 1833)]
>[New Thread 1108962224 (LWP 1834)]
>
>Program received signal SIGSEGV, Segmentation fault.
>[Switching to Thread 1108962224 (LWP 1834)]
>0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>(gdb) bt
>#0  0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#1  0x402219c9 in wxInputSink::Entry () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#2  0x403fc446 in wxThreadInternal::PthreadStart ()
>   from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
>#3  0x405cb9b4 in start_thread () from /lib/tls/libpthread.so.0
>#4  0x00000000 in ?? ()
>(gdb) 
>
>
>I don't know wether that is already helpfull to you or not.  How do I compile
>wxhaskell with full debugging information?  I noticed that there is something
>like wxcd in makefile.lib but there does not seem to be an accompanying 
>parameter in the configure script.
>
>
>Cheers,
>
>Bene
>
>
>PS:
>
>I originally intented not to write this email to the wxhaskell mailing list, as
>I wasn't sure wether this email was interesting to it.  And I had it only cc'ed to 
>Daniel Fischer (who happened to post another one of our problems yesterday evening 
>and is that colleque of mine I mentioned before).  But I just had to realize that
>your spam filter blocked my email.  
>
>
>  
>

Re: [wxhaskell-users] Sigsev on Process example

[Benedikt G. <Ben...@we...>]

Hello Daan, Hello List,

I have some free time this weekend which I want to use to track down
this sigsev bug.  Interestingly the bug does not appear that often 
when running the Process.hs in a debugger.  But most of the time it
does crash when I try to execute the unknown cmd `cmd' to times in a
row.  I compiled process using ghc -debug -package wx --make Process.hs
gdb says:

Starting program: /home/dreamer/programming/wxhaskell/wxhaskell-0.8/samples/wx/a.out 
[Thread debugging using libthread_db enabled]
[New Thread 1090297408 (LWP 1826)]
Detaching after fork from child process 1829.
[New Thread 1100573616 (LWP 1830)]
[New Thread 1108962224 (LWP 1831)]
[Thread 1108962224 (zombie) exited]
[Thread 1100573616 (zombie) exited]
Detaching after fork from child process 1832.
[New Thread 1100573616 (LWP 1833)]
[New Thread 1108962224 (LWP 1834)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1108962224 (LWP 1834)]
0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
(gdb) bt
#0  0x40221dd4 in wxInputSinkEvent::Read () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#1  0x402219c9 in wxInputSink::Entry () from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#2  0x403fc446 in wxThreadInternal::PthreadStart ()
   from /usr/local/lib/libwxc-gtk2.4.2-0.8.so
#3  0x405cb9b4 in start_thread () from /lib/tls/libpthread.so.0
#4  0x00000000 in ?? ()
(gdb) 


I don't know wether that is already helpfull to you or not.  How do I compile
wxhaskell with full debugging information?  I noticed that there is something
like wxcd in makefile.lib but there does not seem to be an accompanying 
parameter in the configure script.


Cheers,

Bene


PS:

I originally intented not to write this email to the wxhaskell mailing list, as
I wasn't sure wether this email was interesting to it.  And I had it only cc'ed to 
Daniel Fischer (who happened to post another one of our problems yesterday evening 
and is that colleque of mine I mentioned before).  But I just had to realize that
your spam filter blocked my email.  


-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

[wxhaskell-users] new sizer and splitter window problems

[Daniel F. <daf...@st...>]

Hello wxHaskell users,

my sizer problems changed a little since my last mail. Now I'm able to
specify my problems more precisely.

(1) If the initial size of the left/upper pane of a splitter window is
    SMALLER than the minimal size of this left/upper pane (as given by
    the layout) it is not possible to resize the panes by dragging the
    the splitter bar. The problem does not persist if the inital size
    is greater than the minimum size. This behaviour has currently
    only been tested with Windows.
    
    Maybe there should be a check for the inital pane size repsecting
    the minimum pane size when layouting the splitter windows via
    "hsplit" or "vsplit" ? Or has the programmer to do this check ?

(2) I'm using nested splitter windows. On top level there is a
    splitter window with horizontal splitter bar. The lower pane of
    this splitter window just contains "regular" controls but the
    upper pane consists of another splitter window with vertical
    splitter bar (both panes just containing "regular" controls, too).
    The minimum sizes of all panes containing "regular" controls are
    respected well. But the minimum size of the upper pane of the top
    level splitter window (just containing the other splitter window)
    is just ignored. I can move the horizontal splitter bar up nearly
    to the upper edge of the frame. Shouldn't the minimum vertical
    size be just the maximum of the minimum vertical sizes of the
    upper panes? Have I forgotten to set anything? Or is this a bug?

    For illustration I made some screenshots. In image "1.gif" you
    see the application window as it should look like. In image
    "2.gif" you see the squeezed upper splitter pane.

(3) Furthermore there is an ugly redraw bug. When minimizing and then
    restoring the window (on Windows) sometimes list controls disappear
    magically. As you can see in screenshot "3.jpg" (taken just after
    restoring the window) instead of the list control there is only
    the panel visible (compare tp "1.jpg"). The error is reproducible
    but seems only to occur if the splitter positions has been changed
    before (aka, they are different than the initial splitter pane
    sizes).

(4) Please excuse the *large* dimensions of the screenshots but this
    is one of my problems, too. Although the list controls are set to
    a minimum size of only 100x100 pixels and there are no forced spaces
    in the layout I'm not able to resize below a size of about 1200x874
    pixels. But there should be more than enough room the make the
    window smaller, shouldn't it? I don't know where the too large
    minimum size constraints come from. Is there a way of "debugging"
    this by simply printing the computed minimum sizes of each
    control?

You find the screenshots mentioned above on the web:
    http://www.fischerbox.net/1.gif
    http://www.fischerbox.net/2.gif
    http://www.fischerbox.net/3.gif
I included the source for reference.
    
Hopefully anyone has ideas concerning these problems.
Many thanks in advance.

Daniel

Re: [wxhaskell-users] Sigsev on Process example

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

Benedikt Grundmann wrote:

>Well it's a *critical* part of an application I'm currently writing together
>with a colleque (part of my bachelor thesis in computer science).  Implementation
>is still in it's infancy so I could switch to another programming language
>even though I *really* want to use haskell :-).  Do you know wether it is a
>wxhaskell or a wxWidgets or wxGTK Problem?  I'm willing to give it some more
>work / testing but not much as my time constraints to not permit that.
>  
>
Ok, first of all try to compile wxHaskell with an experimental 
wxWidgets, like 2.5.2  (I haven't tried 2.5.3 yet).
Secondly, if you have a nice debugger, you could look into the wxHaskell 
process code. I have just
done so, and couldn't find any glaring errors, but maybe you'll find the 
problem with the right mix of
trace statements :-)

How does it work: first, I create a Process object that runs 
asynchronously and redirects input/output.
(See WXCore/Process.hs) The process objects sends events to a parent 
which catches them. The
"OnInput" events are the important ones. To implement non-blocking IO, 
those event handlers
(See WXCore/Events.hs) create "InputSink" objects to deal with that. The 
"inputSink" objects are
implemented by me in C code  (See wxc/src/extra.cpp,  a bit of a mess 
here, but you'll find the relevant section :-)
The InputSink class derives from the wxThread class and starts a 
seperate thread that reads from the
input stream. While the thread is not destroyed, it reads from the 
stream. When something is read, it
creates a "InputEvent" that contains the data and "posts" it to the main 
GUI loop where it can be processed
by the main GUI/Haskell event thread. How does the event know which 
object should get the event? well,
it has a special "id" that identifies it. However, now that I think 
about it, I take the input stream pointer as the
value which seems kind of wrong -- maybe it should be the "id" of the 
parent object for the process, or even
the id from the process object -- try to play with that a bit.

Well, I hope this helps a bit with debugging -- I couldn't reproduce 
your problems (yet), but I'll try later
this week.

-- Daan.

>Thanks again for your work,
>
>Cheers,
>
>Bene
>
>  
>

Re: [wxhaskell-users] Sigsev on Process example

[Benedikt G. <Ben...@we...>]

Hi Daan,

On Wednesday 10 November 2004 16:00, you wrote:
DL> Benedikt Grundmann wrote:
DL> 
DL> >Hello List,
DL> >
DL> >I just tried the Process example on my debian gnu linux (testing) laptop 
DL> >(intel centrino).  Linux kernel version 2.6.7.  
DL> >
DL> >wxgtk-2.4-config --version reports 2.4.2  (debian package)
DL> >ghc --version reports 6.2.1
DL> >
DL> >I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
DL> >faults most of the time:
DL> >  
DL> >
DL> Hi Benedikt,
DL> 
DL> The asynchronous process seemed to work well on windows, but since we 
DL> use it intensively
DL> with Helium, we noticed that it sometimes crashes too :-(  We still try 
DL> to debug this but it is
DL> a hard one to solve due to the asynchronous nature. We have not tested 
DL> it on debian, but maybe
DL> we should as it seems to occur at least at well-defined moments! 
DL> 

I did some more testing today:  I could reproduce the same behaviour on my
desktop machine (a 2.6 ghz pentium 4) running Debian GNU Linux 
(unstable bleeding edge).  On both machines I could "sometimes" see it actually
work roughly once every 20 tries.  

DL> Bottom line: the process feature has bugs.. and it won't get solved soon 
DL> as I am currently working
DL> on other features (like printing). However, I would like to see it 
DL> debugged as it is a tremendously
DL> useful feature and because we need to run Helium.
DL> 

Well it's a *critical* part of an application I'm currently writing together
with a colleque (part of my bachelor thesis in computer science).  Implementation
is still in it's infancy so I could switch to another programming language
even though I *really* want to use haskell :-).  Do you know wether it is a
wxhaskell or a wxWidgets or wxGTK Problem?  I'm willing to give it some more
work / testing but not much as my time constraints to not permit that.


Thanks again for your work,

Cheers,

Bene

-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

Re: [wxhaskell-users] Sigsev on Process example

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

Benedikt Grundmann wrote:

>Hello List,
>
>I just tried the Process example on my debian gnu linux (testing) laptop 
>(intel centrino).  Linux kernel version 2.6.7.  
>
>wxgtk-2.4-config --version reports 2.4.2  (debian package)
>ghc --version reports 6.2.1
>
>I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
>faults most of the time:
>  
>
Hi Benedikt,

The asynchronous process seemed to work well on windows, but since we 
use it intensively
with Helium, we noticed that it sometimes crashes too :-(  We still try 
to debug this but it is
a hard one to solve due to the asynchronous nature. We have not tested 
it on debian, but maybe
we should as it seems to occur at least at well-defined moments! 

Bottom line: the process feature has bugs.. and it won't get solved soon 
as I am currently working
on other features (like printing). However, I would like to see it 
debugged as it is a tremendously
useful feature and because we need to run Helium.

>What's going on?  On a side note how is one supposed to use the 
>inputStreamRead* collection of functions (see Graphics.UI.WXCore.Process)
>there does not seem to be a function to get an InputStream given a Process.
>  
>
These are just convenience functions on streams. There are used 
internally to provide the "OnReceive"
functions for processes and you can't use them directly on processes.

I hope this helps,
-- Daan.

>
>Cheers and Thanks for your help,
>
>
>Bene
>
>
>  
>

[wxhaskell-users] Sigsev on Process example

[Benedikt G. <Ben...@we...>]

Hello List,

I just tried the Process example on my debian gnu linux (testing) laptop 
(intel centrino).  Linux kernel version 2.6.7.  

wxgtk-2.4-config --version reports 2.4.2  (debian package)
ghc --version reports 6.2.1

I'm using wxhaskell-0.8 compiled using --with-opengl.  I get segmentation 
faults most of the time:

  - when trying to use a not existing command (cmd for example)
  - bash works and after bash is started all cmds executed inside bash
    do not cause sigsevs as well
  - ls (without bash) causes sigsev 
  - cat (without bash) works
  - cat Process.hs (without bash) causes sigsev
  - cat fooo (without bash fooo being a non existant file) causes sigsev

What's going on?  On a side note how is one supposed to use the 
inputStreamRead* collection of functions (see Graphics.UI.WXCore.Process)
there does not seem to be a function to get an InputStream given a Process.


Cheers and Thanks for your help,


Bene


-- 
Benedikt Grundmann

For animals, the entire universe has been neatly divided into things 
to (a) mate with, (b) eat, (c) run away from, and (d) rocks.
--- (Terry Pratchett, Equal Rites) ---

Re: [wxhaskell-users] How about use IOUArray Point Color or IOArray Point Color?

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

99...@tk... wrote:

>Hi.
> 
>I had known Cvs's wxHaskell's Pixel manipulate function was implemented
>recent days, so I tested Anti-Alias function to know how much faster.
> 
>http://sourceforge.net/mailarchive/message.php?msg_id=9127088
> 
>I'm not satisfied this performance. This function is too slowly yet.
>I think that bottleneck is read/write Array.
> 
>http://d.hatena.ne.jp/tanakh/20040809#p1
> 
>How about use IOUArray or IOArray?
>  
>
I am currently not in the position to tweak much about this code (as
other things
have priority now, like drag&drop and printing). However, if you feel
that you can
make it faster by using IOUArray or something, please try to do so. If
you can
package it up nicely, I will most certainly add your patches to wxHaskell.

Thanks
-- Daan.

> 
> 
>--
>shelarcy <shelarcy capella.freemail.ne.jp>
>http://page.freett.com/shelarcy/
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

Re: [wxhaskell-users] Re: problem with splitter windows and spin controls

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

Daniel Fischer wrote:

>Hello Daan,
>
>I haven't heard from you. So have you made any progress or could you
>reproduce the problem? Thanks again for you help.
>  
>
Sorry Daniel,

I haven't looked into this yet as I have been so busy lately. I'll try 
to look into
it later this week -- but don't get your hopes up too much: to me, it seems
like a wxWidgets problem.

-- Daan

>Daniel
>
>  
>
>> Daniel Fischer wrote:
>> 
>>    
>>
> >>Hello!
> >>
> >>I have a strange problem when using splitter windows with a spin
> >>control inside. I reduced my problem to the sample code below. When I
> >>running it on Windows I"m unable to resize the top left area by moving
> >>the vertical splitter bar left or right. But the horizontal splitter
> >>bar works fine. It seems to be a problem with the spin control. When
> >>replacing the spin control by a simple text entry (changing the line
> >>"spin <- spinCtrl panelLeft 0 100 []" to "spin <- textEntry panelLeft []")
> >>both splitter bars work fine. Strangly this problem does not occur
> >>when running it on Linux.
> >>
> >>Is it my fault or is there a bug in wxHaskell or in wxWidgets?
> >>I"m using Windows XP prof SP2, ghc 6.2.1 and wxHaskell 0.8.
> >>  
> >>
>  
>
>> It seems a wxWidgets problem. I will try this out on monday on my 
>> windowsXP system.
>> (it also seems that spin controls don"t propagate their events 
>> correctly, so it might be
>> related to that bug)
>> 
>> -- Daan.
>> 
>>    
>>
> >>And just another related question: how can I make the splitter windows
> >>respect the minimum size needed for the controls in the splitter
> >>panes?
> >>
> >>Many thanks in advance for your help
> >>Daniel Fischer
> >>
> >>---8<---------- sample code ----------8<---
> >>
> >>module Main where
> >>
> >>import Graphics.UI.WX
> >>import Graphics.UI.WXCore
> >>
> >>main :: IO ()
> >>main
> >>  = start gui
> >>
> >>gui :: IO ()
> >>gui
> >>  = do  f <- frame [ text := "error?" ]
> >>  
> >>        hSplit <- splitterWindow f [ style := wxSP_3DSASH ]
> >>        vSplit <- splitterWindow hSplit [ style := wxSP_3DSASH ]
> >>        panelLeft <- panel vSplit []
> >>        
> >>        spin <- spinCtrl panelLeft 0 100 []
> >>        entry <- textEntry panelLeft []
> >>        btn1 <- button panelLeft [ text := "Ok" ]
> >>        btn2 <- button panelLeft [ text := "Ok" ]
> >>        list1 <- listCtrl panelLeft [ columns := [("foo",AlignLeft,100)] ]
> >>        list2 <- listCtrl vSplit [ columns := [("bar",AlignLeft,100)] ]
> >>        list3 <- listCtrl hSplit [ columns := [("baz",AlignLeft,100)] ]
> >>        
> >>        subLayoutLeft <- return $ vfill $ column 5
> >>          [ boxed "box 1" $ row 5 [ fill $ widget spin, widget btn1 ]
> >>          , boxed "box 2" $ row 5 [ fill $ widget entry, widget btn2 ]
> >>          ]
> >>
> >>        layoutLeft <- return $ fill $ row 5 [ fill $ widget list1, subLayoutLeft ]
> >>        set panelLeft [ layout := layoutLeft ]
> >>        
> >>        layoutTop <- return $ vsplit vSplit 5 300 (widget panelLeft) (widget list2)
> >>        layoutAll <- return $ hsplit hSplit 5 300 layoutTop (widget list3)
> >>        
> >>        set f [ layout := minsize (sz 640 400) $ fill layoutAll ]
> >>
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> >>Use IT products in your business? Tell us what you think of them. Give us
> >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> >>http://productguide.itmanagersjournal.com/guidepromo.tmpl
> >>_______________________________________________
> >>wxhaskell-users mailing list
> >>wxhaskell-users@li...
> >>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
> >>
> >>
> >>  
> >>
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Sybase ASE Linux Express Edition - download now for FREE
>LinuxWorld Reader's Choice Award Winner for best database on Linux.
>http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

[wxhaskell-users] How about use IOUArray Point Color or IOArray Point Color?

[<99...@tk...>]

Hi.
 
I had known Cvs's wxHaskell's Pixel manipulate function was implemented
recent days, so I tested Anti-Alias function to know how much faster.
 
http://sourceforge.net/mailarchive/message.php?msg_id=9127088
 
I'm not satisfied this performance. This function is too slowly yet.
I think that bottleneck is read/write Array.
 
http://d.hatena.ne.jp/tanakh/20040809#p1
 
How about use IOUArray or IOArray?
 
 
--
shelarcy <shelarcy capella.freemail.ne.jp>
http://page.freett.com/shelarcy/

[wxhaskell-users] Re: problem with splitter windows and spin controls

[Daniel F. <dan...@on...>]

Hello Daan,

I haven't heard from you. So have you made any progress or could you
reproduce the problem? Thanks again for you help.

Daniel

>  Daniel Fischer wrote:
>  
 >>Hello!
 >>
 >>I have a strange problem when using splitter windows with a spin
 >>control inside. I reduced my problem to the sample code below. When I
 >>running it on Windows I"m unable to resize the top left area by moving
 >>the vertical splitter bar left or right. But the horizontal splitter
 >>bar works fine. It seems to be a problem with the spin control. When
 >>replacing the spin control by a simple text entry (changing the line
 >>"spin <- spinCtrl panelLeft 0 100 []" to "spin <- textEntry panelLeft []")
 >>both splitter bars work fine. Strangly this problem does not occur
 >>when running it on Linux.
 >>
 >>Is it my fault or is there a bug in wxHaskell or in wxWidgets?
 >>I"m using Windows XP prof SP2, ghc 6.2.1 and wxHaskell 0.8.
 >>  
 >>
>  It seems a wxWidgets problem. I will try this out on monday on my 
>  windowsXP system.
>  (it also seems that spin controls don"t propagate their events 
>  correctly, so it might be
>  related to that bug)
>  
>  -- Daan.
>  
 >>And just another related question: how can I make the splitter windows
 >>respect the minimum size needed for the controls in the splitter
 >>panes?
 >>
 >>Many thanks in advance for your help
 >>Daniel Fischer
 >>
 >>---8<---------- sample code ----------8<---
 >>
 >>module Main where
 >>
 >>import Graphics.UI.WX
 >>import Graphics.UI.WXCore
 >>
 >>main :: IO ()
 >>main
 >>  = start gui
 >>
 >>gui :: IO ()
 >>gui
 >>  = do  f <- frame [ text := "error?" ]
 >>  
 >>        hSplit <- splitterWindow f [ style := wxSP_3DSASH ]
 >>        vSplit <- splitterWindow hSplit [ style := wxSP_3DSASH ]
 >>        panelLeft <- panel vSplit []
 >>        
 >>        spin <- spinCtrl panelLeft 0 100 []
 >>        entry <- textEntry panelLeft []
 >>        btn1 <- button panelLeft [ text := "Ok" ]
 >>        btn2 <- button panelLeft [ text := "Ok" ]
 >>        list1 <- listCtrl panelLeft [ columns := [("foo",AlignLeft,100)] ]
 >>        list2 <- listCtrl vSplit [ columns := [("bar",AlignLeft,100)] ]
 >>        list3 <- listCtrl hSplit [ columns := [("baz",AlignLeft,100)] ]
 >>        
 >>        subLayoutLeft <- return $ vfill $ column 5
 >>          [ boxed "box 1" $ row 5 [ fill $ widget spin, widget btn1 ]
 >>          , boxed "box 2" $ row 5 [ fill $ widget entry, widget btn2 ]
 >>          ]
 >>
 >>        layoutLeft <- return $ fill $ row 5 [ fill $ widget list1, subLayoutLeft ]
 >>        set panelLeft [ layout := layoutLeft ]
 >>        
 >>        layoutTop <- return $ vsplit vSplit 5 300 (widget panelLeft) (widget list2)
 >>        layoutAll <- return $ hsplit hSplit 5 300 layoutTop (widget list3)
 >>        
 >>        set f [ layout := minsize (sz 640 400) $ fill layoutAll ]
 >>
 >>
 >>
 >>
 >>-------------------------------------------------------
 >>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
 >>Use IT products in your business? Tell us what you think of them. Give us
 >>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
 >>http://productguide.itmanagersjournal.com/guidepromo.tmpl
 >>_______________________________________________
 >>wxhaskell-users mailing list
 >>wxhaskell-users@li...
 >>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
 >>
 >>
 >>  
 >>

Re: [wxhaskell-users] my ray tracer using wxHaskell 0.8

[Bernie P. <bj...@cs...>]

On Fri, Oct 22, 2004 at 01:28:14PM +0200, Daan Leijen wrote:
> Bernie Pope wrote:
> >  - When you recompile the program and run it for the first time
> >    it doesn't get the size of the first window right (its too big).
> >
> >    Then when you run it again (and again ...) the window sizing
> >    is right.  
> > 
> >
> This is a known problem. I think you can solve it by creating the frame with
> a "visible := False" property, and setting it to true after setting the 
> layout.

Yes, that fixes the problem. Thanks.

> >  - I can't seem to get transparent bitmaps working properly
> >    using drawBitmap

> Can you send me the .png file? 

I'll send one to you in another mail (not to the list).

> All the best,
> Daan Leijen.

> ps. Have you looked at the latest direct pixel buffer functions in
> WXCore.Image?  The lastest cvs version contains functions to
> transform "Array Point Color" arrays into images and bitmaps
> (but than you need to build wxHaskell yourself)

I haven't looked. Sounds useful though. I'll probably wait until the
next stable realease before I try it.

Cheers,
Bernie.

Re: [wxhaskell-users] Problem linking WxHaskell sample program

[Volker W. <po...@vo...>]

On Sat, 23 Oct 2004, Daan Leijen wrote:

> You have configured wxHaskell with "--with-opengl" while wxWidgets is
> not compiled with it
> , and now that I think about it,  maybe it is the other way around, and
> you have to
> do "configure --with-opengl" when configuring wxHaskell.

Thanks, that's it. It works when I configure wxHaskell with
"--with-opengl".

Greetings,
Volker

Re: [wxhaskell-users] problem with splitter windows and spin controls

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

Daniel Fischer wrote:

>Hello!
>
>I have a strange problem when using splitter windows with a spin
>control inside. I reduced my problem to the sample code below. When I
>running it on Windows I'm unable to resize the top left area by moving
>the vertical splitter bar left or right. But the horizontal splitter
>bar works fine. It seems to be a problem with the spin control. When
>replacing the spin control by a simple text entry (changing the line
>"spin <- spinCtrl panelLeft 0 100 []" to "spin <- textEntry panelLeft []")
>both splitter bars work fine. Strangly this problem does not occur
>when running it on Linux.
>
>Is it my fault or is there a bug in wxHaskell or in wxWidgets?
>I'm using Windows XP prof SP2, ghc 6.2.1 and wxHaskell 0.8.
>  
>
It seems a wxWidgets problem. I will try this out on monday on my 
windowsXP system.
(it also seems that spin controls don't propagate their events 
correctly, so it might be
related to that bug)

-- Daan.

>And just another related question: how can I make the splitter windows
>respect the minimum size needed for the controls in the splitter
>panes?
>
>Many thanks in advance for your help
>Daniel Fischer
>
>---8<---------- sample code ----------8<---
>
>module Main where
>
>import Graphics.UI.WX
>import Graphics.UI.WXCore
>
>main :: IO ()
>main
>  = start gui
>
>gui :: IO ()
>gui
>  = do  f <- frame [ text := "error?" ]
>  
>        hSplit <- splitterWindow f [ style := wxSP_3DSASH ]
>        vSplit <- splitterWindow hSplit [ style := wxSP_3DSASH ]
>        panelLeft <- panel vSplit []
>        
>        spin <- spinCtrl panelLeft 0 100 []
>        entry <- textEntry panelLeft []
>        btn1 <- button panelLeft [ text := "Ok" ]
>        btn2 <- button panelLeft [ text := "Ok" ]
>        list1 <- listCtrl panelLeft [ columns := [("foo",AlignLeft,100)] ]
>        list2 <- listCtrl vSplit [ columns := [("bar",AlignLeft,100)] ]
>        list3 <- listCtrl hSplit [ columns := [("baz",AlignLeft,100)] ]
>        
>        subLayoutLeft <- return $ vfill $ column 5
>          [ boxed "box 1" $ row 5 [ fill $ widget spin, widget btn1 ]
>          , boxed "box 2" $ row 5 [ fill $ widget entry, widget btn2 ]
>          ]
>
>        layoutLeft <- return $ fill $ row 5 [ fill $ widget list1, subLayoutLeft ]
>        set panelLeft [ layout := layoutLeft ]
>        
>        layoutTop <- return $ vsplit vSplit 5 300 (widget panelLeft) (widget list2)
>        layoutAll <- return $ hsplit hSplit 5 300 layoutTop (widget list3)
>        
>        set f [ layout := minsize (sz 640 400) $ fill layoutAll ]
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

Re: [wxhaskell-users] Problem linking WxHaskell sample program

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

Volker Wysk wrote:

>Hello.
>
>I've compiled and installed WxHaskell-0.8 from source, but when I try to
>compile one of the examples, I get:
>  
>
>>ghc -package wx -o helloworld HelloWorld.hs
>>    
>>
>...
>/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SwapBuffers()'
>  
>

You have configured wxHaskell with "--with-opengl" while wxWidgets is 
not compiled with it
, and now that I think about it,  maybe it is the other way around, and 
you have to
do "configure --with-opengl" when configuring wxHaskell.

When you run configure again with this flag, and build again, it will 
surely work.
(actually, you only have to relink so you could take a shortcut by only 
removing
the ".so" and ".a" files in the "out" directory)

I hope this helps,
 -- Daan.

ps: <http://wxhaskell.sourceforge.net/building.html> gives more information.




>/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SetColour(char const*)'
>/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, wxGLCanvas const*, int, wxPoint const&, wxSize const&, long, wxString const&, int*, wxPalette const&)'
>/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SetCurrent()'
>/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&, int*, wxPalette const&)'
>collect2: ld returned 1 exit status
>
>When calling "readelf /usr/lib/libwxc-gtk2.4.2-0.8.so", the undefined
>symbols seem to be present in the library.
>
>I've also tried it with the prepackaged RPM, and am able to compile the
>program, but when I start it, I get:
>
>./helloworld: relocation error: /usr/lib/libwxc-gtk2.4.2-0.8.so: undefined symbol: _ZN10wxGLCanvasC1EP8wxWindowiRK7wxPointRK6wxSizelRK8wxStringPiRK9wxPalette
>
>I'm using Debian, and the standard Debian packages of WxWidgets. I had
>installed the RPM with alien.
>
>Any idea what's wrong?
>
>Thanks,
>Volker
>
>--
>Volker Wysk <po...@vo...>
>http://www.volker-wysk.de
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

[wxhaskell-users] Problem linking WxHaskell sample program

[Volker W. <po...@vo...>]

Hello.

I've compiled and installed WxHaskell-0.8 from source, but when I try to
compile one of the examples, I get:

> ghc -package wx -o helloworld HelloWorld.hs
...
/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SwapBuffers()'
/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SetColour(char const*)'
/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, wxGLCanvas const*, int, wxPoint const&, wxSize const&, long, wxString const&, int*, wxPalette const&)'
/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::SetCurrent()'
/usr/lib/libwxc-gtk2.4.2-0.8.so: undefined reference to `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, int, wxPoint const&, wxSize const&, long, wxString const&, int*, wxPalette const&)'
collect2: ld returned 1 exit status

When calling "readelf /usr/lib/libwxc-gtk2.4.2-0.8.so", the undefined
symbols seem to be present in the library.

I've also tried it with the prepackaged RPM, and am able to compile the
program, but when I start it, I get:

./helloworld: relocation error: /usr/lib/libwxc-gtk2.4.2-0.8.so: undefined symbol: _ZN10wxGLCanvasC1EP8wxWindowiRK7wxPointRK6wxSizelRK8wxStringPiRK9wxPalette

I'm using Debian, and the standard Debian packages of WxWidgets. I had
installed the RPM with alien.

Any idea what's wrong?

Thanks,
Volker

--
Volker Wysk <po...@vo...>
http://www.volker-wysk.de

[wxhaskell-users] problem with splitter windows and spin controls

[Daniel F. <daf...@st...>]

Hello!

I have a strange problem when using splitter windows with a spin
control inside. I reduced my problem to the sample code below. When I
running it on Windows I'm unable to resize the top left area by moving
the vertical splitter bar left or right. But the horizontal splitter
bar works fine. It seems to be a problem with the spin control. When
replacing the spin control by a simple text entry (changing the line
"spin <- spinCtrl panelLeft 0 100 []" to "spin <- textEntry panelLeft []")
both splitter bars work fine. Strangly this problem does not occur
when running it on Linux.

Is it my fault or is there a bug in wxHaskell or in wxWidgets?
I'm using Windows XP prof SP2, ghc 6.2.1 and wxHaskell 0.8.

And just another related question: how can I make the splitter windows
respect the minimum size needed for the controls in the splitter
panes?

Many thanks in advance for your help
Daniel Fischer

---8<---------- sample code ----------8<---

module Main where

import Graphics.UI.WX
import Graphics.UI.WXCore

main :: IO ()
main
  = start gui

gui :: IO ()
gui
  = do  f <- frame [ text := "error?" ]
  
        hSplit <- splitterWindow f [ style := wxSP_3DSASH ]
        vSplit <- splitterWindow hSplit [ style := wxSP_3DSASH ]
        panelLeft <- panel vSplit []
        
        spin <- spinCtrl panelLeft 0 100 []
        entry <- textEntry panelLeft []
        btn1 <- button panelLeft [ text := "Ok" ]
        btn2 <- button panelLeft [ text := "Ok" ]
        list1 <- listCtrl panelLeft [ columns := [("foo",AlignLeft,100)] ]
        list2 <- listCtrl vSplit [ columns := [("bar",AlignLeft,100)] ]
        list3 <- listCtrl hSplit [ columns := [("baz",AlignLeft,100)] ]
        
        subLayoutLeft <- return $ vfill $ column 5
          [ boxed "box 1" $ row 5 [ fill $ widget spin, widget btn1 ]
          , boxed "box 2" $ row 5 [ fill $ widget entry, widget btn2 ]
          ]

        layoutLeft <- return $ fill $ row 5 [ fill $ widget list1, subLayoutLeft ]
        set panelLeft [ layout := layoutLeft ]
        
        layoutTop <- return $ vsplit vSplit 5 300 (widget panelLeft) (widget list2)
        layoutAll <- return $ hsplit hSplit 5 300 layoutTop (widget list3)
        
        set f [ layout := minsize (sz 640 400) $ fill layoutAll ]

Re: [wxhaskell-users] my ray tracer using wxHaskell 0.8

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

Bernie Pope wrote:

>I promised I would send a link to it:
>
>   http://www.cs.mu.oz.au/~bjpop/code.html
>
>There's screenshots also.
>  
>
It looks quite cool :-)  As soon as I have some time, I'll try it
out on windows.

>   - When you recompile the program and run it for the first time
>     it doesn't get the size of the first window right (its too big).
>
>     Then when you run it again (and again ...) the window sizing
>     is right.  
>  
>
This is a known problem. I think you can solve it by creating the frame with
a "visible := False" property, and setting it to true after setting the 
layout.

>   - I can't seem to get transparent bitmaps working properly
>     using drawBitmap
>  
>
Can you send me the .png file?  I have never tried working with transparent
bitmaps and would like to investigate this. There is a good chance that 
I have
done something wrong in my abstractions so we should try some lowlevel
calls.

All the best,
 Daan Leijen.

ps. Have you looked at the latest direct pixel buffer functions in
WXCore.Image?  The lastest cvs version contains functions to
transform "Array Point Color" arrays into images and bitmaps
(but than you need to build wxHaskell yourself)


>Thanks to all those who put in the enormous effort to get wxHaskell
>going. I was really impressed with the library. I look forward to
>using it more often.
>  
>
Thanks, this is nice to hear :-)

>
>-------------------------------------------------------
>This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
>Use IT products in your business? Tell us what you think of them. Give us
>Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
>http://productguide.itmanagersjournal.com/guidepromo.tmpl
>_______________________________________________
>wxhaskell-users mailing list
>wxh...@li...
>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
>  
>

[wxhaskell-users] my ray tracer using wxHaskell 0.8

[Bernie P. <bj...@cs...>]

Hi all,

I promised I would send a link to it:

   http://www.cs.mu.oz.au/~bjpop/code.html

There's screenshots also.

It is not a very fancy raytracer. Just something simple
I made up to show our first year students how you might
use Haskell to do graphics.

A couple of oddities I noticed:

   - When you recompile the program and run it for the first time
     it doesn't get the size of the first window right (its too big).

     Then when you run it again (and again ...) the window sizing
     is right.  

   - I can't seem to get transparent bitmaps working properly
     using drawBitmap

     The docs say:

        drawBitmap :: DC a -> Bitmap () -> Point 
                      -> Bool -> [Prop (DC a)] -> IO ()

        Draw a bitmap. Takes a bitmap, a point and a boolean that 
        is True when the bitmap is drawn with a transparency mask.

     I'm using Gimp on linux to make a PNG with transparent background.
     When the boolean is False the background is painted pinkish.
     When it is True it is painted white (I would expect it to be
     transparent, and see the panel underneath).

     This may very well be a problem with me and not the library,
     so if anyone has a suggestion I'd like to hear it. 

Cheers,
Bernie.

PS

Thanks to all those who put in the enormous effort to get wxHaskell
going. I was really impressed with the library. I look forward to
using it more often.

Re: [wxhaskell-users] how to draw one pixel at a time?

[Bernie P. <bj...@cs...>]

On Mon, Oct 11, 2004 at 07:41:21PM +1000, Bernie Pope wrote:
> Hi wxHaskell people,
> 
> I have a little ray-tracer in Haskell. An image is
> produced as a stream of pixel intensities.
> 
> I want to use wxHaskell to write a display facilty that
> will render each pixel as it is generated by the tracer
> (so we can see the image being generated pixel by pixel).

Hi again,

I've done some more tinkering and here's what I've come up with.

When the user clicks the "render" button a new frame is created
containing a panel. A bitmap is drawn onto the panel on paint raw
events.

At each idle event for the panel, the program requests a chunk of
pixels from the raytracer. It then writes those pixels to their
respective positions in the bitmap pixelbuffer. Then it sends
a repaint event to the panel. When the supply of pixels runs out
(the emtpy list) the panel stops responding to idle events.

You can set the chunk size. Smaller sizes tend to slow the 
repaint process down.

The nice thing is we can have multiple simultaneous renderings
going on in different frames.

I'll post a link to the code when I'm done polishing it.

Cheers,
Bernie.

[wxhaskell-users] how to draw one pixel at a time?

[Bernie P. <bj...@cs...>]

Hi wxHaskell people,

I have a little ray-tracer in Haskell. An image is
produced as a stream of pixel intensities.

I want to use wxHaskell to write a display facilty that
will render each pixel as it is generated by the tracer
(so we can see the image being generated pixel by pixel).

My current thoughts are to create a panel and have it
render a bitmap on paint events. The bitmap is implemented
via "varCreate" and so on. The idea is to update the bitmap
and periodically repaint the panel.

Before I commit to this approach I thought it would be wise
to ask for advice in case there is a more idiomatic way
to do it.

Cheers,
Bernie.

Re: [wxhaskell-users] FunctionalForms, a combinator library for forms

[<dl...@xs...>]

It looks very cool Sander,
I'll try it out as soon as I get back from
holidays.

-- Daan


> I hereby present FunctionalForms, a combinator library for use with
> wxHaskell.
>
> FunctionalForms enables a very concise programming style for forms
> (dialogs which only show and edit a set of values):
> * control and layout definition are combined into one expression,
> * values are passed to and from the controls automatically,
> * no control pointers are used
> * no IO monad programming has to be done.
>
> FunctionalForms consists of a few Haskell modules which are easy to use.
> Most of the functions are very similar to wxHaskell's controls and
> layout combinators, although used in a different way.
>
> FunctionalForms is in an early stage, so it is not well-documented, but
> a small tutorial is available. I would like to invite the interested
> reader to try out the library and give feedback. Comments, questions and
> suggestions are very welcome.
>
> FunctionalForms can be found at:
> http://www.cs.ru.nl/~sandr/FunctionalForms
>
>
> Sander Evers
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] FunctionalForms, a combinator library for forms

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

I hereby present FunctionalForms, a combinator library for use with 
wxHaskell.

FunctionalForms enables a very concise programming style for forms 
(dialogs which only show and edit a set of values):
* control and layout definition are combined into one expression,
* values are passed to and from the controls automatically,
* no control pointers are used
* no IO monad programming has to be done.

FunctionalForms consists of a few Haskell modules which are easy to use. 
Most of the functions are very similar to wxHaskell's controls and 
layout combinators, although used in a different way.

FunctionalForms is in an early stage, so it is not well-documented, but 
a small tutorial is available. I would like to invite the interested 
reader to try out the library and give feedback. Comments, questions and 
suggestions are very welcome.

FunctionalForms can be found at:
http://www.cs.ru.nl/~sandr/FunctionalForms


Sander Evers