wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Compile problem: wxhaskell-0.9.4: wxUSE_ODBC definition?

[Howard B. G. <hg...@so...>]

Hi,

I am trying to compile wxhaskell-0.9.4 using the Gentoo ebuild. I have 
already reported the problem below to Gentoo, but I believe that the 
issue may be answered here instead, since it may be related to 
wxhaskell and wxwidgets, not just Gentoo.

PROBLEM:

Compile errors ("no member named...") in wxc/src/db.cpp:

RELEVANT OUTPUT:

i686-pc-linux-gnu-g++ -c wxc/src/db.cpp -o out/wxc/db.o -MD 
-march=athlon-xp -O2 -pipe -fstack-protector -fPIC 
-I/usr/lib/wx/include/gtk2-ansi-release-2.6 -I/usr/include/wx-2.6 
-DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES 
-D_LARGEFILE_SOURCE=1 -DNO_GCC_PRAGMA   -Iwxc/include
wxc/src/db.cpp: In function `int wxDbColInf_GetColumnSize(wxDbColInf*)':
wxc/src/db.cpp:1035: error: 'class wxDbColInf' has no member named 
'columnSize'
wxc/src/db.cpp: In function `int 
wxDbColInf_GetBufferLength(wxDbColInf*)':
wxc/src/db.cpp:1044: error: 'class wxDbColInf' has no member named 
'bufferLength'
wxc/src/db.cpp: In function `wxDbColInf* wxDb_GetResultColumns(wxDb*, 
int*)':
wxc/src/db.cpp:1158: error: 'class wxDbColInf' has no member named 
'columnSize'
make: *** [out/wxc/db.o] Error 1

------------------------------------
My hypothesis of the problem:

1. The code is looking for the #define of wxUSE_ODBC (at line 3 of 
wxc/src/db.cpp).

2. While I believe this (wxUSE_ODBC) should be defined, I'm 
hypothesizing that it isn't set anywhere (e.g., in a configuration file 
or an earlier include).

3. If wxUSE_ODBC isn't defined, then wx/db.h will NOT be included. 
Instead stub definitions of wxDb, wxDbColInf, wxDbInf, and wxDbTableInf 
will be used.

4. Since these stub definitions don't have and members, any attempt to 
reference members of these classes will fail.

5. It appears to me that this is what is happening in the error messages 
shown above.

6. I don't know where the definition of wxUSE_ODBC _should_be_ coming 
from, if my hypotheses are correct, so I don't have a solution at 
present.

Here is my specific Haskell and wxwidgets setup:

* Using /usr/lib/wx/config/gtk2-ansi-release-2.6
checking system:
 wx-config found
 ghc found
 ghc-pkg found
 haddock found
 install program found

configuration:
 library:     wxhaskell-0.9.4  (release 0)
 compiler:    ghc-6.4
 wxwidgets:   gtk-2.6.0
 with openGL: yes
 library dir: /var/tmp/portage/wxhaskell-0.9.4/image///usr/lib/ghc-6.4

I would appreciate any suggestions you can offer. Thanks in advance.

Howard B. Golden
Northridge, California, USA

[wxhaskell-users] Problems building wxHaskell 0.9.4-1 on Debian unstable with GHC 6.2.2

[Martin G. <ma...@cs...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

wxHello,

today I built wxHaskell from source and want to share my experience,
so that the build process can (hopefully) be fixed.

* The first problem is that the permissions on the package.conf file
  (located at /usr/lib/ghc-6.2.2 in my setup) are set incorrectly.
  I don't know whether that is a GHC or wxHaskell problem, but it
  leads to problems when building an example after installing, because
  the package.conf file is not world-readable.

* Second, but unfortunately not reproducible, I sometimes got linking
  errors about not finding symbols from the Parsec library.  This is
  possibly related, because maybe the package.conf file is in a broken
  state while GHC searches for the Parsec binaries.  Since I recompiled
  wxHaskell a dozen times, with manual chmod and/or removal of the
  package.conf file, I have not been able to reproduce the setup for
  which this problem occurs.  Maybe someone else has had a similar
  experience?

* It is not as easy as implied by the building instructions to install
  wxHaskell to another directory, because then the runtime loader will
  not find the libraries.  You either have to install in some standard
  place (/usr, /usr/local, if that's in your ld.so.conf) or to modify
  /etc/ld.so.conf -- not a nice alternative.  I know that this is a general
  problem, but maybe it could be mentioned on the installation page.

Now I'm glad that I got it running, and I want to than the developer(s)
for the effort put into wxHaskell.  Keep up the good work and thank you.

Best wishes,
  Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCifzAN+bWg9uANMIRAmFKAJ0e5RfVlbTVnzL5cHJLmyWFiDxFGQCfYiyc
rRId8HEHts82oxxSZU1uUpw=
=O0sV
-----END PGP SIGNATURE-----

[wxhaskell-users] missing frames around MDI child frames (WinXP)

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

When I make an MDI child frame, there is no frame around it containing
title bar with the usual buttons for minimize, restore/maximize, and
close.  I've set the resizeable, closeable, minimizeable, and
maximizeable to True.  The child window does resize, but I can't move it
etc.
 
Am I missing something?  Have MDI frames been tested in wxHaskell?
 
            - Conal

[wxhaskell-users] color/bgcolor or border attribute for panels

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

I'm trying to selectively highlight panels and controls.  I've tried
setting the "color" and the "bgcolor" attributes, with no visible effect
on panels.  I'm using a row & column layouts with enough spacing to
mouse into the space between controls, and I do get enter events there.
I've also tried using the border attribute on panels and controls, also
without visible result.  I'm running Windows XP.
 
Should color, bgcolor, or border work for panels?  
 
Is there another way to dynamically highlight a control or panel?
 
Thanks!
 
- Conal

[wxhaskell-users] bitmapButton with windows..

[Patrick S. <mai...@st...>]

Hi,

First of all I want to thank all people who worked on the binary windows =
release of wxHaskell.
Now I can compile my programms without having trouble because I don't =
have to compile wxHaskell by myself.
Thank you for not forgetting the OpenGl thing :)))

Now one question. When I create a bitmapButton, then the button is =
resized to the size of the image. On my windows xp box this isn't the =
case. The buttons keep their small size and the image borders are cut =
away.

I tried to convert my png files for the buttons to bmp format and played =
with all kind of clientSize, outerSize..
without success. The gtk on linux don't have such problems. Is there a =
way to fix it or is there a restriction of the size of images on buttons =
on windows?
I definitely need some button thing displaying a 60x60 image and react =
on clicks...

The creation of the buttons is just simple code:

bitmapButton p=20
  [ picture :=3D ("./Pictures/stone" ++ (show i)++ ".BMP")
  , on click :=3D (\_ ->(buttSelectStone (id2Stone i) varGP) >>=20
                   updatePlayerPanel varGP statusText p >>=20
                   repaint p)
  , clientSize :=3D sz 90 90]


Cheers
Patrick

Re: [wxhaskell-users] Beginner qustion - anonymous widgets?

[Arjan v. I. <af...@cs...>]

> How can I create anonymous widgets (i.e., do not assign them)?
>
> For instance think  of a row of buttons labeled as '1' to '0' and 
> activating the same callback with the Integers '1' to '0' respectivly.

It could go something like this: (untested code)

main = start $
	do
		f <- frame [ text := "Window with many buttons" ]
		buttons <- sequence
			[ button f [ text := show i, on command := doSomething i ]
			| i <- [0..9]
			]
		set f [ layout := fill (row 5 (map widget buttons)) ]

doSomething nr =
	do
		putStrLn "button " ++ show nr ++ "has been pressed

Cheers, Arjan

[wxhaskell-users] Beginner qustion - anonymous widgets?

[Yoel J. <yo...@em...>]

How can I create anonymous widgets (i.e., do not assign them)?

For instance think  of a row of buttons labeled as '1' to '0' and activating the same callback with the Integers '1' to '0' respectivly. 

The problem is that I can't see how can I fenerat these buttons in a function than layout them.

Yoel

Re: [wxhaskell-users] really, really basic newbie question

[Arjan v. I. <af...@cs...>]

Hi James,

> Chasing modules from: PDDemo.hs
> PDDemo.hs:
>     Can't find module `PersistentDocument'
>     (use -v to see a list of the files searched for)

Make sure that all files (PersistentDocument, PDDefaults, PDDemo) are in 
the same directory and that you pass --make to ghc.

Cheers, Arjan

Re: Re: [wxhaskell-users] really, really basic newbie question

[James M. <ji...@ya...>]

> As Daan pointed out, I have written a library for
> exactly these kind of 
> application. It handles graying out of menu items,
> undo & redo, title 
> bar updating etcetera. Enclosed you can find the
> library (2 files) and a 
> small demo that uses it. It solves the problem of
Many thanks (and to the rest of you as well).

I tried to build the files, and couldn't build the
demo (using ghc, not ghci).  I get the following
error:

Chasing modules from: PDDemo.hs
PDDemo.hs:
    Can't find module `PersistentDocument'
    (use -v to see a list of the files searched for)

I assume this's a standard thing I should know how to
handle, like plopping the .hi & .o files for the
module files in some directory besides the current
one, but unfortunately I don't know what that is. 
Would you mind clueing me in?

thanks again,

James



|-----------------------------------------------|
|   James Mitchell     | http://www.jimdesu.us  |
|-----------------------------------------------|
|When the shoe fits, the foot is forgotten; when|
|the belt fits, the belly is forgotten; when the|
|heart is right, "for" and "against" are        |
|forgotten. -- Chuang Tzu                       |
|-----------------------------------------------|


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

Re: [wxhaskell-users] really, really basic newbie question

[Arjan v. I. <af...@cs...>]

Hi James,

 > That worked
> out ok, so I added code to correctly enable & disable
> menu attributes, such a disabling "Close" when there's
> no opened file. 
 > [...]

As Daan pointed out, I have written a library for exactly these kind of 
application. It handles graying out of menu items, undo & redo, title 
bar updating etcetera. Enclosed you can find the library (2 files) and a 
small demo that uses it. It solves the problem of the many parameters by 
putting everything in a big record.

Hope this helps, Arjan

Re: [wxhaskell-users] really, really basic newbie question

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

On Wed, 11 May 2005 10:06:13 +0200, Daan Leijen <da...@cs...> wrote:
> I believe that Arjan van IJzendoorn has released a utility
> library "PersistentDocument" that manages file open/close
> stuff for document oriented applications. I couldn't find it
> on the web but maybe you can send him an email and I am sure
> he tells you his tricks.

"PersistentDocument" is found by mailing-list log, here.
http://www.haskell.org/pipermail/haskell/2004-December/015078.html

But this first version function is very primitive sample.
If use this library, need to customise redo and undo
function for application.


> (Actually,
> I just read wxWidgets has an "wxUpdateUIEvent" especially to
> allow this kind of programming in C++ too where all the menu
> disabling/enabling is in one spot -- I'll add this event to the next
> release of wxHaskell).

Daan, When next release comes, after current two week work, or you
come back this project? If after come back this project, I hope you
commit on current work to CVS.

Because I want to use your current work - SOEgraphics on wxHaskell
- on my project. I already bind FFmpeg function to play AVI file on
wxHaskell. And I want to support save AVI from SOEGraphics Animation
(yes, I also want to combine Pan (PanTheon?) and Fran, if it is possible).

Drug&Drop is important for UI, but SOEGraphics are more important now.
so I wait this work done instead mail for question.

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

Re: [wxhaskell-users] really, really basic newbie question

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

Hi James,

James Mitchell wrote:
> In order to better learn Haskell, I've set myself a
> project that happens to include GUI work (I figure if
> I can't have a GUI w/ Haskell, then it's back to C++),

Great!

> so I downloaded wxHaskell, read the example, and coded
> up a little window with a "File" menu.  That worked
> out ok, so I added code to correctly enable & disable
> menu attributes, such a disabling "Close" when there's
> no opened file.  This also worked ok, but has left me
> with an organizational challenge.  I have a bundle of
> lines like this:
> 
> mNew      <- menuItem mFile [text := "&New"]
> 
> ... which isn't a big deal, but then when I want to
> code the actual event handlers, I end up with these
> huge parameter lists, with each of the items in
> question an individual variable.  If this were C or
> C++, I'd have each of these guys as a property of a
> structure or class, and then just pass around the
> structure as a whole.  What's the "right" way to do
> this with wxHaskell?

This is one of the main troubles with wxHaskell: the
library  doesn't offer a standard abstraction mechanism
and all state is passed explicitly. However, there are
some ways to make this less painful. I think that
the Dazzle application uses a big state record.
Something like:

data State = State { mNew :: MenuItem ()
                    , ...
                    , mainWindow :: Window ()
                    , ...
                    }

Each event handler gets the state passed. By using a record,
we can easily change the State while keeping all the code
that doesn't rely on the change the same.

Now, you can write a function "updateMenus :: State -> IO ()"
that just updates all the menus by looking at the "State" -- this
also guarantees that everything is done in one place. (Actually,
I just read wxWidgets has an "wxUpdateUIEvent" especially to
allow this kind of programming in C++ too where all the menu
disabling/enabling is in one spot -- I'll add this event to the next
release of wxHaskell).

I believe that Arjan van IJzendoorn has released a utility
library "PersistentDocument" that manages file open/close
stuff for document oriented applications. I couldn't find it
on the web but maybe you can send him an email and I am sure
he tells you his tricks.

I hope this helps,
-- Daan.



> 
> thanks in advance,
> 
> James
> 
> 
> 
> |-----------------------------------------------|
> |   James Mitchell     | http://www.jimdesu.us  |
> |-----------------------------------------------|
> |When the shoe fits, the foot is forgotten; when|
> |the belt fits, the belly is forgotten; when the|
> |heart is right, "for" and "against" are        |
> |forgotten. -- Chuang Tzu                       |
> |-----------------------------------------------|
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail Mobile 
> Take Yahoo! Mail with you! Check email on your mobile phone. 
> http://mobile.yahoo.com/learn/mail 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

Claus Reinke wrote:
>>I keep using 2.4.2 on windows since it
>>
>>1) seems to have just the same set of features as 2.6
>>2) is very stable
>>3) is the only version that works well with ghci
> 
> 
> 1) - there seem to be a few new features, but I don't have any urgent
>     need for them yet
>     - more interesting is that the change logs show a number of bug-fixes
>     and minor improvements
> 
> 2) hmm. you mean "insufficiently tested"?-)
> 
> 3) now, this is the worrying bit: if I take your and shelarcy's comments,
>     it seems that the further one moves from 2.4.2 towards the current
>     stable version, the more features stop cooperating with the Haskell
>     side tools. unless that can be fixed, wxHaskell will be cut off from
>     bug fixes, improvements, and new features developed in wxWidgets.

Yes, these are vallid concerns. Of course, in the long run, I hope that
ghci gets fixed and is able to reload the dynamic link libraries. If you
think about it, it should do so anyway for *all* dynamically linked code
-- it is a miracle that other libraries work correctly :-)

If this is not going to happen, someone will have to bite the bullet
and write a "re-initializer" for wxWidgets, but this is potentially
a lot of work and will need maintenance all the time -- something I try
to avoid.

>     (and don't tell me its only on windows, please - if it isn't portable,
>     with roughly the same feature-/bug-set, it isn't of any use!-). even
>     using different versions on different platforms is not quite the
>     kind of portability I would be hoping for..

Well, even if you use the same library version the portability will *not* be
perfect. This can be considered *the* feature of wxWidgets: since it uses
native widgets it gives a native look-and-feel, but also small differences
between platforms. My main goal for the "wx" layer is to create programs that
run directly on each platform -- but it might be that a final program needs
some tuning for each particular platform. "WXCore.Defines" can be used to
write platform specific code.

>>About the last point: all the newer versions of wxWidgets rely on static
>>initializers: these are initialized when the dynamic link library is loaded
>>(like static C++ constructors) -- when ghci loads. When I run a program from
>>ghci, everything is fine. However, ghci keeps the dll loaded and does not
>>reinitialize the library. When running the program again from the command line,
>>the library is in a random state and (usually) crashes. The fix is not easy:
>>either the wxWidgets library needs a thorough cleanup to be more stateless, or
>>the ghci interpreter needs special code to reload dynamic link libraries. I like
>>the last solution but it is a tricky business :-)
> 
> 
> you can already defer the -package wx option until after you've started 
> your ghci session, indeed 6.5 will infer the package from the module and
> load when running main for the first time. so loading dlls is not tied to 
> loading ghci but to when ghci loads the package. and if I keep loading 
> different modules that need different packages, then ghci should really 
> provide a way to get rid of packages and their dlls (which it doesn't).
> 
> I don't remember enough of my C++, but aren't static initialisers
> meant to initialise persistent state? so you're saying that you can
> still use ghci for an interactive session with several commands, but 
> there is no way to tell ghci that the current session is ended, and that
> the dll should be reloaded for a new session (short of exiting ghci..)?

Here is an example in C:

 > static Handle window = NULL;
 >
 > void runWxWidgets( void ) {
 >   if (window == NULL) { window = osCreateWindowHandle(); }
 >   osShowModalWindow( window );
 > }

When I create a haskell wrapper for "runWxWidgets", the first invokation
from ghci works fine. However, the next invokation crashes ghci as it
still uses the "old" window handle that is no longer valid for the OS.

In reality, it is a bit more complicated since a static C++ object does
not just get a value assigned, but also runs the code of the constructor.
There is generally no documented way to run the destructor except for
"unloading" the dll.

> It is unlikely that wxWindows will change its ways for us, so I guess 
> you're right - one needs a way to reset ghci. but if dynamic loading 
> already works, unloading shouldn't be difficult any more (unless 
> dynamic loading is handwritten instead of using the native support 
> libraries?). and once the dll is unloaded, setting the package again 
> should work. have you asked the ghci gurus? 
> 
> from a quick browse through ghci/{Linker,ObjLink}.lhs and 
> rts/Linker.c, it seems that (amongst lots of stuff I won't even try to 
> understand) there are special cases explicitly to avoid unloading 
> and re-loading an already loaded lib - perhaps some of those can 
> simply be dropped, or at least, a forced unload/reload be provided? 
> it might not be all that tricky - but the gurus will know!-)

The GHC guru's know about this particular problem. However, *someone* will
have to do it -- even though it is maybe not too hard to implement it,
it surely requires knowledge of ghc and intricate linker issues. It would
be very cool to have this working though :-)

Cheers,
  Daan.

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

Hi Claus,

Claus Reinke wrote:
>>- wxWidgets make install didn't copy all of the include files
>>    to the installation directory (just copying the one file mentioned
>>    on the wxHaskell building page seems to be sufficient, but I still
>>    wonder what is going on there)
> 
> ah, there are several of them, a pair for each platform, of which only
> one is copied. but this is an _old_ _stable_ release! why hasn't it
> been patched?

No sane person builds wxWidgets with "make & mingw" on a windows platform :-)

(and thus, it becomes a low priority issue for the wxWidgets people)

>>.. But "make dist" fails for wxHaskell, with what 
>>seems to be a cygwin problem:
>>
>>C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
>>      5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization
>>/bin/bash: fork: No such file or directory
>>make: *** [wxc-dist] Error 129
> 
> 
> updating cygwin didn't help. but slowing down the process revealed
> another error hidden behind this one, namely execvp complaining about
> too long a commandline. and if I do "make dist -n", I'm not really
> surprised about that complaint - have you ever looked at the things
> you're building there with your nice makefile function library?-)

Ah, I had this problem in another library of me.. You are right,
the command line will be way too long. Thanks for pointing this out,
I'll put it on the TODO list.

> ps. oh, the build with 6.5 on winxp works (thoroughly tested 
>     using wx/BouncingBalls;-), although 6.5 still has some issue
>     when running under bash, so one has to run ghci under cmd
>     instead.. it seems others have already seen that in their own
>     builds, but I didn't want to leave the error message issue 
>     open on the list.

That is good to know. Thanks.
-- Daan.

[wxhaskell-users] really, really basic newbie question

[James M. <ji...@ya...>]

Hi y'all,

In order to better learn Haskell, I've set myself a
project that happens to include GUI work (I figure if
I can't have a GUI w/ Haskell, then it's back to C++),
so I downloaded wxHaskell, read the example, and coded
up a little window with a "File" menu.  That worked
out ok, so I added code to correctly enable & disable
menu attributes, such a disabling "Close" when there's
no opened file.  This also worked ok, but has left me
with an organizational challenge.  I have a bundle of
lines like this:

mNew      <- menuItem mFile [text := "&New"]

... which isn't a big deal, but then when I want to
code the actual event handlers, I end up with these
huge parameter lists, with each of the items in
question an individual variable.  If this were C or
C++, I'd have each of these guys as a property of a
structure or class, and then just pass around the
structure as a whole.  What's the "right" way to do
this with wxHaskell?

thanks in advance,

James



|-----------------------------------------------|
|   James Mitchell     | http://www.jimdesu.us  |
|-----------------------------------------------|
|When the shoe fits, the foot is forgotten; when|
|the belt fits, the belly is forgotten; when the|
|heart is right, "for" and "against" are        |
|forgotten. -- Chuang Tzu                       |
|-----------------------------------------------|


		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

>I keep using 2.4.2 on windows since it
>
>1) seems to have just the same set of features as 2.6
>2) is very stable
>3) is the only version that works well with ghci

1) - there seem to be a few new features, but I don't have any urgent
    need for them yet
    - more interesting is that the change logs show a number of bug-fixes
    and minor improvements

2) hmm. you mean "insufficiently tested"?-)

3) now, this is the worrying bit: if I take your and shelarcy's comments,
    it seems that the further one moves from 2.4.2 towards the current
    stable version, the more features stop cooperating with the Haskell
    side tools. unless that can be fixed, wxHaskell will be cut off from
    bug fixes, improvements, and new features developed in wxWidgets.
    (and don't tell me its only on windows, please - if it isn't portable,
    with roughly the same feature-/bug-set, it isn't of any use!-). even
    using different versions on different platforms is not quite the
    kind of portability I would be hoping for..

>About the last point: all the newer versions of wxWidgets rely on static
>initializers: these are initialized when the dynamic link library is loaded
>(like static C++ constructors) -- when ghci loads. When I run a program from
>ghci, everything is fine. However, ghci keeps the dll loaded and does not
>reinitialize the library. When running the program again from the command line,
>the library is in a random state and (usually) crashes. The fix is not easy:
>either the wxWidgets library needs a thorough cleanup to be more stateless, or
>the ghci interpreter needs special code to reload dynamic link libraries. I like
>the last solution but it is a tricky business :-)

you can already defer the -package wx option until after you've started 
your ghci session, indeed 6.5 will infer the package from the module and
load when running main for the first time. so loading dlls is not tied to 
loading ghci but to when ghci loads the package. and if I keep loading 
different modules that need different packages, then ghci should really 
provide a way to get rid of packages and their dlls (which it doesn't).

I don't remember enough of my C++, but aren't static initialisers
meant to initialise persistent state? so you're saying that you can
still use ghci for an interactive session with several commands, but 
there is no way to tell ghci that the current session is ended, and that
the dll should be reloaded for a new session (short of exiting ghci..)? 

It is unlikely that wxWindows will change its ways for us, so I guess 
you're right - one needs a way to reset ghci. but if dynamic loading 
already works, unloading shouldn't be difficult any more (unless 
dynamic loading is handwritten instead of using the native support 
libraries?). and once the dll is unloaded, setting the package again 
should work. have you asked the ghci gurus? 

from a quick browse through ghci/{Linker,ObjLink}.lhs and 
rts/Linker.c, it seems that (amongst lots of stuff I won't even try to 
understand) there are special cases explicitly to avoid unloading 
and re-loading an already loaded lib - perhaps some of those can 
simply be dropped, or at least, a forced unload/reload be provided? 
it might not be all that tricky - but the gurus will know!-)

cheers,
claus

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

> - wxWidgets make install didn't copy all of the include files
>     to the installation directory (just copying the one file mentioned
>     on the wxHaskell building page seems to be sufficient, but I still
>     wonder what is going on there)

ah, there are several of them, a pair for each platform, of which only
one is copied. but this is an _old_ _stable_ release! why hasn't it
been patched?

> .. But "make dist" fails for wxHaskell, with what 
> seems to be a cygwin problem:
> 
> C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
>       5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization
> /bin/bash: fork: No such file or directory
> make: *** [wxc-dist] Error 129

updating cygwin didn't help. but slowing down the process revealed
another error hidden behind this one, namely execvp complaining about
too long a commandline. and if I do "make dist -n", I'm not really
surprised about that complaint - have you ever looked at the things
you're building there with your nice makefile function library?-)

perhaps it is not so much a cygwin bug but an excessive use of
resources? or is it an unfortunate implementation failing to keep
up with your demands? anyway:

removing the "echo" part from the cp&echo-function was sufficient
to let "make dist" go through, but I'm somewhat surprised that you 
didn't have the same problem when building your distribution for 
the webpage. any ideas?

cheers,
claus

ps. oh, the build with 6.5 on winxp works (thoroughly tested 
    using wx/BouncingBalls;-), although 6.5 still has some issue
    when running under bash, so one has to run ghci under cmd
    instead.. it seems others have already seen that in their own
    builds, but I didn't want to leave the error message issue 
    open on the list.

Re: [wxhaskell-users] slider value limit

[Patrick S. <mai...@st...>]

Hmm, I think you should think about it again. Let us assume you have a slider 
having the same width like your screen. The smallest step you are able to do 
is exactly one pixel on the screen. To reach every single value of a int 
slider that is over your screen you have to have a screen size of 32767 
pixels...

You should use a int slider and calculate your float values. With a slider of 
100 pixels you will never have more than 100 discrete steps. Even when you 
would have a real-valued slider you would only be able to reach a few 
points..

What are you trying to do?

Cheers
Patrick 


On Tuesday 10 May 2005 04:56, Conal Elliott wrote:
> There seems to be a value limit of 32767 for sliders.  Does anyone know
> a work-around?
>
> I'm really after a real-valued slider, which I was approximating with an
> int slider with inflated values.  Does anyone have a real-valued slider?
>
>             - Conal

[wxhaskell-users] slider value limit

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

There seems to be a value limit of 32767 for sliders.  Does anyone know
a work-around?
 
I'm really after a real-valued slider, which I was approximating with an
int slider with inflated values.  Does anyone have a real-valued slider?
 
            - Conal 

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

Claus Reinke wrote:

>- wxWidgets make install didn't copy all of the include files
>    to the installation directory (just copying the one file mentioned
>    on the wxHaskell building page seems to be sufficient, but I still
>    wonder what is going on there)
>  
>
It is a bug in wxWindows where a header file was accidently forgotten
in the install script.

-- Daan.

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

Claus Reinke wrote:

>>If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so.  
>>Sounds like there are still some hitches in compiling under windows.  - Conal
>>    
>>
>that is most likely because I tried to build with the current stable wxWidgets 
>version instead of the older 2.4.2 recommended by Dan. which is not to say 
>that wxHaskell shouldn't try to keep pace with wxWidgets;-).
>  
>
Yes, in principle, building on windows with wxWidgets 2.4.2 should be 
fairly painless.

> ps I only hope Daan will catch up with wxWidgets before the
>     gap gets too wide, with all his other commitments.

I do try to keep pace with wxWidgets: on GTK wxHaskell uses 2.6.0 by 
default and
on MacOSX 2.5.4 -- so everything is fine still. Since the Linux build 
doesn't use
ODBC, I never spotted the faults that you encountered on Windows.

I keep using 2.4.2 on windows since it

1) seems to have just the same set of features as 2.6
2) is very stable
3) is the only version that works well with ghci

About the last point: all the newer versions of wxWidgets rely on static
initializers: these are initialized when the dynamic link library is loaded
(like static C++ constructors) -- when ghci loads. When I run a program from
ghci, everything is fine. However, ghci keeps the dll loaded and does not
reinitialize the library. When running the program again from the 
command line,
the library is in a random state and (usually) crashes. The fix is not easy:
either the wxWidgets library needs a thorough cleanup to be more 
stateless, or
the ghci interpreter needs special code to reload dynamic link 
libraries. I like
the last solution but it is a tricky business :-)

-- Daan.

> 
>I'm currently trying to build with ghc-6.5 (one of the snapshots after Sigbjorn's
>fix, so I'm using an unpatched wxHaskell 0.9.4) and have been a lot more 
>successful with wxWindows 2.4.2. The build looks fairly clean and doesn't 
>take all that long. No need to meddle with sh/bash, do any of the other
>fiightening things mentioned in wxHaskell's cygwin installation guide, or do 
>anything to PATH other than adding ghc-6.5/bin, and prefixing Mingw/bin. 
>Neither do any of the other problems mentioned in my previous mail appear
>in this case. There were only two small things:
>
>- wxWidgets make install didn't copy all of the include files
>    to the installation directory (just copying the one file mentioned
>    on the wxHaskell building page seems to be sufficient, but I still
>    wonder what is going on there)
>
>- ghc-6.5's haddock needs to be told where to find its auxiliary 
>    files, which it is searching in the wrong directory 
>    (-l c:/ghc/ghc-6.5/docs/html/libraries helps).
>
>The problem I have at the moment is that I'm doing this on a remote
>machine, so I can't really test there, and I need to package things up
>to copy them here. But "make dist" fails for wxHaskell, with what 
>seems to be a cygwin problem:
>
>C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
>      5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization
>/bin/bash: fork: No such file or directory
>make: *** [wxc-dist] Error 129
>
>(I added SHELL=/bin/bash to makefile, in case that would help, but
>as you can see, it didn't). I haven't found any real info about this 
>problem, other than that it has been reported with fairly recent
>cygwin builds and not fixed in Cygwin DLL 1.5.15-1 release. the 
>suggested fix was to try the development snapshots of cygwin.. 
>so it may be fixed in the current cygwin already (1.5.16-1 release).
>
>but I don't know how to remote update cygwin (my only access 
>point is via said cygwin;-), so this will have to wait till tomorrow.
>
>Apart from that, building with the older wxWidgets version 
>and a fixed ghc seems to be painless, as Daan suggested.
>
>cheers,
>claus
>
>ps I only hope Daan will catch up with wxWidgets before the
>    gap gets too wide, with all his other commitments.
>
>
>  
>

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

Read this thread, then I try to build wxHskell with wxWidgets 2.6.0.

Okay, I see. wxHaskell can't use with wxWidgets 2.6.0's dll.

If use wxWidgets 2.6.0 on Windows, there are many problem.
Visual C++ 7.1 (Visual Studio .NET 2003) build wxc successfuly,
and build wxHaskell successfuly too.

But If use wxHaskell with wxWidgets 2.6.0's dll then libwxcore2.a
and wxcore2.o can't resolve wxc print function, so both ghc and ghci
can't use wxHaskell with wxWidgets 2.6.0's dll.

Yes, I knew current version doesn't match Visual C++ 7.1 (e.g. Visual C++
7.X's wxcdll doen't work with OpenGL Canvas.), so I don't know Visual C++
6.0 has same problem. But this conclusion - If want to build wxHaskell
on Windows, don't use wxWidgets 2.6.0 - are commonly.

I think this problem doesn't exist in wxWidgets 2.5.3. Only ghci problem
(and 7.1's OpenGL prolem) exists.


On Sun, 08 May 2005 18:25:25 +0200, Daan Leijen <da...@cs...> wrote:
>> as for being able to build wxhaskell themselves, I'm in the process
>> of giving that a go (windows xp with cygwin and mingw,ghc-6.4.1,
>> wxhaskell-src-0.9.4-1.zip,wxWidgets 2.6.0+2 patches). wxWidgets
>> seems to have built and installed just fine, and ./configure for
>> wxHaskell works, but when trying to make wxHaskell, I get the
>> error below. Any suggestions?
>
> (snip compiler error message)
> However, I have build wxHaskell with odbc on Windows -- but I was using
> Visual C++ 6.0.
> So, if you have visual studio, I recommend building it using the visual
> studio
> project. It is all explained in the build guide. With wxHaskell, you
> would do:
>
>  > ./configure --with-msc  [--wxc-libname=wxcd]
>
> open the visual studio project wxc/wxc-2.x.dsw
> build the dll
>
>  > make
>
> First of all, I strongly recommend wxWidgets 2.4.2 since it is the only
> version that works with ghci. Newer wxWidgets version use static
> initializers that are not properly desctructed when the dynamic
> link library is not re-loaded. Furthermore, there doesn't seem to
> be that many new features useful on Windows.




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

RE: [wxhaskell-users] programmatic bitmap construction?

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

Oops - forgot to google before asking.  Looks like I want "direct image
manipulation"
(http://wxhaskell.sourceforge.net/doc/Graphics.UI.WXCore.Image.html#7)
or maybe "pixel buffers".  Looks pretty straightforward.

	- Conal

-----Original Message-----
From: wxh...@li...
[mailto:wxh...@li...] On Behalf Of Conal
Elliott
Sent: Sunday, May 08, 2005 8:58 PM
To: wxhaskell-users
Subject: [wxhaskell-users] programmatic bitmap construction?

I'd like to make wxhaskell bitmaps or images programmatically.  Is that
possible?  Any pointers?  - Conal

[wxhaskell-users] programmatic bitmap construction?

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

I'd like to make wxhaskell bitmaps or images programmatically.  Is that
possible?  Any pointers?  - Conal

Re: [wxhaskell-users] announce: wxHaskell 0.9.4, windows bug fix release

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

>If anyone does compile up a 6.4.1-compatible version of wxHaskell and is willing to share it, please say so.  
>Sounds like there are still some hitches in compiling under windows.  - Conal

that is most likely because I tried to build with the current stable wxWidgets 
version instead of the older 2.4.2 recommended by Dan. which is not to say 
that wxHaskell shouldn't try to keep pace with wxWidgets;-).
 
I'm currently trying to build with ghc-6.5 (one of the snapshots after Sigbjorn's
fix, so I'm using an unpatched wxHaskell 0.9.4) and have been a lot more 
successful with wxWindows 2.4.2. The build looks fairly clean and doesn't 
take all that long. No need to meddle with sh/bash, do any of the other
fiightening things mentioned in wxHaskell's cygwin installation guide, or do 
anything to PATH other than adding ghc-6.5/bin, and prefixing Mingw/bin. 
Neither do any of the other problems mentioned in my previous mail appear
in this case. There were only two small things:

- wxWidgets make install didn't copy all of the include files
    to the installation directory (just copying the one file mentioned
    on the wxHaskell building page seems to be sufficient, but I still
    wonder what is going on there)

- ghc-6.5's haddock needs to be told where to find its auxiliary 
    files, which it is searching in the wrong directory 
    (-l c:/ghc/ghc-6.5/docs/html/libraries helps).

The problem I have at the moment is that I'm doing this on a remote
machine, so I can't really test there, and I need to package things up
to copy them here. But "make dist" fails for wxHaskell, with what 
seems to be a cygwin problem:

C:\cygwin\bin\bash.exe (2124): *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32 error 487
      5 [main] bash 1584 fork_parent: child 2124 died waiting for longjmp before initialization
/bin/bash: fork: No such file or directory
make: *** [wxc-dist] Error 129

(I added SHELL=/bin/bash to makefile, in case that would help, but
as you can see, it didn't). I haven't found any real info about this 
problem, other than that it has been reported with fairly recent
cygwin builds and not fixed in Cygwin DLL 1.5.15-1 release. the 
suggested fix was to try the development snapshots of cygwin.. 
so it may be fixed in the current cygwin already (1.5.16-1 release).

but I don't know how to remote update cygwin (my only access 
point is via said cygwin;-), so this will have to wait till tomorrow.

Apart from that, building with the older wxWidgets version 
and a fixed ghc seems to be painless, as Daan suggested.

cheers,
claus

ps I only hope Daan will catch up with wxWidgets before the
    gap gets too wide, with all his other commitments.