wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

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

On Wed, 03 Mar 2004 14:26:00 +0000, Matthew Walton <ma...@al...> wrote:

>> You don't have to do that. If you give "--prefix" to configure it will work fine.
>> You can also give "--libdir" explicitly. When you specify "--help" at the end of
>> the options, you get a nice overview of all settings that will be used.
>
> That works for some packages but we can never be sure it will work for all, because quite a few programs and libraries encode run-time paths in their binaries based on the settings of prefix and related such options given to configure. Because we ultimately want the build system to install it to a different place to the place it will actually be run in, that can cause serious problems.
>
> Can you guarantee that wxHaskell does not have any such compile-time-encoded paths in it?

I can't guarantee it as I haven't tested myself on gentoo, but I believe that wxhaskell has
no compile-time encoded paths in its generated libraries. During linking I use "--soname"
to remove the directory part -- relying on the linker to find it (using LD_LIBRARY_PATH for
example, or by putting it in the same directory as the executable, or ...)

> A common solution is an install target allowing specification of a target directory to be used instead

Good idea, maybe I'll make that an extra option if that proves useful for gentoo unix.
Andres Loh is using Gentoo and he works just across my office so it would be relatively
painless to do some testing :-)

Thanks for the feedback,
-- Daan.


> I may be wrong, but I believe the GNU autotools make this kind of thing quite easy to do these days.

I guess that is right, but the autotools gave me too much trouble to
work across platforms (unix,win98,winXP,macOSX) and I dropped back to
hand-written config/make -- and now that it is done, there is not much
incentive anymore to do otherwise :-)

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Matthew W. <ma...@al...>]

Daan Leijen wrote:

> You don't have to do that. If you give "--prefix" to configure it will 
> work fine.
> You can also give "--libdir" explicitly. When you specify "--help" at 
> the end of
> the options, you get a nice overview of all settings that will be used.

That works for some packages but we can never be sure it will work for 
all, because quite a few programs and libraries encode run-time paths in 
their binaries based on the settings of prefix and related such options 
given to configure. Because we ultimately want the build system to 
install it to a different place to the place it will actually be run in, 
that can cause serious problems.

Can you guarantee that wxHaskell does not have any such 
compile-time-encoded paths in it?

A common solution is an install target allowing specification of a 
target directory to be used instead of /. Thus you might invoke

make DESTDIR="/var/lib/portage/work/wxHaskell-0.6.0/image/" install

and Portage will copy that tree into / after the install's been 
determined to be successful. It also records files and mtimes and things 
at this point for uninstallation at a later date.

I may be wrong, but I believe the GNU autotools make this kind of thing 
quite easy to do these days.

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

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

Gour wrote:
>> This is easily solved by giving the "--prefix" option to configure. See
>> the "building" page on the wxHaskell website. (wxhaskell normally installs
>> whereever you install wxWidgets).
>
> The point is that Gentoo has a concept of "safe sandbox" i.e. building process
> is done in temporary directory and if successful, it installs (emerges) into
> real directory.
>
> wxhaskell installs in /usr/bin (by default), so I had to add an option to allow
> wxhaskell ebuild to write directly into /usr/lib which is not safe in case
> something goes wrong since files in /usr/lib can be overwritten.
>
> I tried by patching configure & config/config.mk scripts to overcome LIBDIR
> entry.

You don't have to do that. If you give "--prefix" to configure it will work fine.
You can also give "--libdir" explicitly. When you specify "--help" at the end of
the options, you get a nice overview of all settings that will be used.

All the best,
  Daan.

-------------------------------------------------
> ./configure --prefix=/usr/sandbox --help
usage:
    ./configure [options]

options: [defaults in brackets]
  --help                 show this information
  --hc=<program>         the haskell compiler [ghc]
  --hcpkg=<program>      package compiler [ghc-pkg]
  --package-conf=<file>  optional local package configuration []
  --version=<version>    library version [0.6]

install options:
  --prefix=<dir>         platform independent install directory [/usr/sandbox]  <--- LOOK HERE
  --exec-prefix=<dir>    platform dependent install directory [<prefix>]
  --libdir=<dir>         library files install directory [<exec-prefix>/lib]	 <--- AND HERE
  --enable-strip         remove symbols from the libraries [no]
  --enable-upx           compress the dynamic libraries with upx [no]

documentation options:
  --username=<name>      username on sourceforge [dleijen]
  --haddock=<program>    haddock documentation tool [haddock]

wxwindows options:
  --wx-lib=<library>     wxWindows library [/usr/local/lib/wx_base-2.5.dll]
  --wx-toolkit=<name>    wxWindows gui toolkit [MSW]
  --wx-config=<program>  wxWindows configure script (must be the first option!)
                         [wx-config]

platform options:
  --dllext=<extension>   dynamic link library extension [.dll]
  --libprefix=<prefix>   library prefix []
  --extra-ld-opts=<opts> extra link options []
  --with-msc             compile wxWindows and wxc with microsoft vc++ [no]
  --wxc-libname=<name>   wxc library name [wxc]

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Gour <go...@ma...>]

Daan Leijen (daa...@xs...) wrote:

> The documentation is generated from the source, so there is no need to 
> include it.
> Furthermore, the binary releases include documentation nowadays. The doc 
> package
> is just provided for those that don't have haddock or don't want to build 
> the
> documentation themselves.

Oops..excuse me.

And, yes, I was thinking only about source package (not binary) release.

> >I was playing during the 0.30.4 but could not solve sandbox problem since
> >wxhaskell writes into /usr/lib.
> 
> This is easily solved by giving the "--prefix" option to configure. See
> the "building" page on the wxHaskell website. (wxhaskell normally installs
> whereever you install wxWidgets).

The point is that Gentoo has a concept of "safe sandbox" i.e. building process
is done in temporary directory and if successful, it installs (emerges) into
real directory.

wxhaskell installs in /usr/bin (by default), so I had to add an option to allow
wxhaskell ebuild to write directly into /usr/lib which is not safe in case
something goes wrong since files in /usr/lib can be overwritten.

I tried by patching configure & config/config.mk scripts to overcome LIBDIR
entry.

Now I am trying to build ghc-6.2 from source and/or waiting for official 6.2.1
since 6.2 is not usable. Then I'm going to resume Gentoo ebuild.

> ps. Let's take this discussion to "wxhaskell-users".

Yes. It was by mistaken cross-post.

Sincerely,
Gour

-- 
Gour
go...@ma...
Registered Linux User #278493

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Matthew W. <ma...@al...>]

Gour wrote:

> Matthew Walton (ma...@al...) wrote:
> 
> 
>>Plenty of ebuilds seem to work from multiple source packages... I can't 
>>see a particular difficulty in writing one that installs wxHaskell 
>>source and documentation simultaneously.
> 
> 
> Thank you for pointing this out. I never came across one.

You probably did, XFree86 uses several tarballs, although admittedly it 
does expand them all into the same place before building. There is 
though, as far as I can see, nothing to stop you making your own 
subdirectories of the build directory and extracting a tarball into each 
of those, then building and installing each of them as necessary.

> I was playing during the 0.30.4 but could not solve sandbox problem since
> wxhaskell writes into /usr/lib.
> 
> Of course, I did it with addwrite /usr/lib and some sed trickery (could not
> find haddock-base), but wanted to have more clean solution by patching Makefile.

That would be preferable. An install target that supports DESTDIR is a 
nice preferable solution for most projects. Not necessarily the easiest 
to implement though, but it depends on the build system.

>>Although having said that, I can't get wxHaskell stuff to link properly 
>>on my Gentoo box at the moment, probably because my OpenGL setup is 
>>rather broken.
> 
> 
> Do you have some wxhaskell ebuild handy?

No, I installed it by hand. I can have a go at writing an ebuild 
although if as you say wxHaskell writes into /usr/lib then a Makefile 
patch is probably in order. As I mentioned though, my wxHaskell is 
currently a bit broken so I'm going to have to sort that out first. 
Although I suspect the broken bit might actually be wxWidgets.

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

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

Dear Gour,

On Wed, 3 Mar 2004 12:58:53 +0100, Gour <go...@ma...> wrote:
> (Again), I have one suggestion for wxHaskell: to combine doc & src packages
> into one - wxhaskell-x-xx.

The documentation is generated from the source, so there is no need to include it.
Furthermore, the binary releases include documentation nowadays. The doc package
is just provided for those that don't have haddock or don't want to build the
documentation themselves.

> I was playing during the 0.30.4 but could not solve sandbox problem since
> wxhaskell writes into /usr/lib.

This is easily solved by giving the "--prefix" option to configure. See
the "building" page on the wxHaskell website. (wxhaskell normally installs
whereever you install wxWidgets).

>> Although having said that, I can't get wxHaskell stuff to link properly
>> on my Gentoo box at the moment, probably because my OpenGL setup is
>> rather broken.

You would only get openGL link errors if you build wxWidgets with "--with-glcanvas",
leaving out that option will drop support of the openGL canvas and link properly.
There also was a recent post on wxhaskell-users regarding openGL linking with more
recent wxWidget versions that might solve your link problems too.

Thanks for trying wxHaskell,
Sincerely,
  Daan.


ps. Let's take this discussion to "wxhaskell-users".

Re: [wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Gour <go...@ma...>]

Matthew Walton (ma...@al...) wrote:

> Plenty of ebuilds seem to work from multiple source packages... I can't 
> see a particular difficulty in writing one that installs wxHaskell 
> source and documentation simultaneously.

Thank you for pointing this out. I never came across one.

I was playing during the 0.30.4 but could not solve sandbox problem since
wxhaskell writes into /usr/lib.

Of course, I did it with addwrite /usr/lib and some sed trickery (could not
find haddock-base), but wanted to have more clean solution by patching Makefile.

> 
> Although having said that, I can't get wxHaskell stuff to link properly 
> on my Gentoo box at the moment, probably because my OpenGL setup is 
> rather broken.

Do you have some wxhaskell ebuild handy?

Sincerely,
Gour

-- 
Gour
go...@ma...
Registered Linux User #278493

[wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Matthew W. <ma...@al...>]

Gour wrote:

> Daan Leijen (daa...@xs...) wrote:
> 
> Hi Daan!
> 
> 
>>This new release fixes many bugs, adds basic support for MDI
>>applications and compiles with the latest CVS snapshots of wxWidgets.
>>For now, only an installer for windows is provided.
> 
> 
> Thank you very much for your cosntant work on wxHaskell. I hope in the future
> I'll find more time for wx(Haskell). At the moment I'm busys trying to 
> build ghc-6.2 from the source on win98 (in MSYS env) since released version
> is not usable.
> 
> (Again), I have one suggestion for wxHaskell: to combine doc & src packages
> into one - wxhaskell-x-xx. That will provide (easier) writing Gentoo ebuild 
> and integration into official tree. (I'm sure it can be included - it's getting
> mature & regularly maintained).

Plenty of ebuilds seem to work from multiple source packages... I can't 
see a particular difficulty in writing one that installs wxHaskell 
source and documentation simultaneously.

Although having said that, I can't get wxHaskell stuff to link properly 
on my Gentoo box at the moment, probably because my OpenGL setup is 
rather broken.

[wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Gour <go...@ma...>]

Daan Leijen (daa...@xs...) wrote:

Hi Daan!

> This new release fixes many bugs, adds basic support for MDI
> applications and compiles with the latest CVS snapshots of wxWidgets.
> For now, only an installer for windows is provided.

Thank you very much for your cosntant work on wxHaskell. I hope in the future
I'll find more time for wx(Haskell). At the moment I'm busys trying to 
build ghc-6.2 from the source on win98 (in MSYS env) since released version
is not usable.

(Again), I have one suggestion for wxHaskell: to combine doc & src packages
into one - wxhaskell-x-xx. That will provide (easier) writing Gentoo ebuild 
and integration into official tree. (I'm sure it can be included - it's getting
mature & regularly maintained).

Sincerely,
Gour

-- 
Gour
go...@ma...
Registered Linux User #278493

[wxhaskell-users] Re: wxGLCanvas

[<wxh...@al...>]

Until this gets fixed in the distribution, here is a patch for
'configure':

------- cut here --------
308c
  wxwinlibs="`$wxconfig --libs --gl-libs | tr '\n' ' '`"
.
------- cut here --------

Thanks



----- Original message -----
From: t1f8koj02@sn...
To: wxhaskell-users@li...
Subject: wxGLCanvas

Nevermind, I figured it out.
 
The package wxGTK-gl-2.4.1-fr1 provides:
/usr/lib/libwx_gtk_gl-2.4.so
/usr/lib/libwx_gtk_gl-2.4.so.0
/usr/lib/libwx_gtk_gl-2.4.so.0.0.0
 
So an additional option does indeed fix it:
 
ghc -package wx -o helloworld HelloWorld.hs -lwx_gtk_gl-2.4

[wxhaskell-users] new windows98 installer

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

Hi all,

I have just released an update of the windows installer of
wxHaskell 0.6 that works for window98 and windows95 too.

Apologies to those that have been struggling to get it
work on those platforms :-)

All the best,
  Daan.

[wxhaskell-users] Hug98 y GHC

[<ga...@ad...>]

Hi,
I=B4ve a Hugs98 application and a module compiled with GHC.
I need to join these two application using GHC, but i dont know how.
I tried to compile the Hugs98 application using GHC, but i couldnt
Somebody can help me?
Thanks
Gabriela

Re: [wxhaskell-users] few advices needed to make an ocaml binding of wxwindows

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

Hi Francois-Xavier,

> Ocaml (http://caml.inria.fr/) is a beautiful functionnal (but impure)
> language

I think most of us know ocaml :-), and I like it too: sober and
consistent design with an excellent compiler and libraries,

> (with side effects, sorry, nobody's perfect),

and a fatal flaw too ;-)

> So the question is:
> Did you find any problem in implementing it in a pure functionnal style=
,
> and could you tell me what are the pros and the cons in doing it this
> way ??

This is a really hard question! I think that making a binding to wxWidget=
s
is difficult in two areas:

1) technical: getting the marshalling layer working between wxWidgets and
the host language. (haskell solution: use wxEiffel wrappers and a haskell
wrapper generation tool (wxdirect)).

2) design: how do you represent the c++ model in your strongly typed
host language? (haskell solution: monads for side effects, phantom types
for modelling (type) inheritance, and type classes to group common operat=
ions.
(and at the higher wx level: existential types to model get/set functions
as attributes))

Regarding your specific question, I think that the pure functional interf=
ace
works out pretty well, also with regard to error messages produced by
the compiler. I guess that if you would have objects in your language, th=
at
might also provide a good direction -- however, note that one mostly uses
wxWidgets classes, you don't implement them yourself -- as such, the obje=
cts
will mostly be used as interfaces/types -- not as values that you manipul=
ate.

If you want to know more about the way inheritance is modelled in wxWidge=
ts,
you should read chapter 2/3 (?) of my thesis (available on my home page
(www.cs.uu.nl/~daan)) and read the quickstart guide and links on the wxHa=
skell
page.

Hope this helps,
  Daan.


ps. I guess that most people on this list are more interested in specific
wxHaskell things, so maybe you should write to me directly.



>
> I thank you in advance
> Fran=C3=A7ois-Xavier Houard
> Id...@In...
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

[wxhaskell-users] few advices needed to make an ocaml binding of wxwindows

[H. <Id...@In...>]

Hi
I am a french student, and I have to make an ocaml binding of WxWidget
as a project for my university.
Ocaml (http://caml.inria.fr/) is a beautiful functionnal (but impure)
language, with imperative and objects capabilities, which can be
byte-compiled or native-compiled or interpreted, with many and many nice
features that make it quiete a nice stuff to study, but, this is not the
subject, the subject is that I need an advice: as Ocaml has a very
elegant functionnal layer (with side effects, sorry, nobody's perfect),
but also an object one, i have to choose between making a functionnal
implementation or an object one (or even a mixte one).
So the question is:=20
Did you find any problem in implementing it in a pure functionnal style,
and could you tell me what are the pros and the cons in doing it this
way ??

I thank you in advance
Fran=C3=A7ois-Xavier Houard
Id...@In...

Re: [wxhaskell-users] Re: wxGLCanvas

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

Hi t1f8koj02 :-)

On Tue, 24 Feb 2004 01:05:49 -0600, <t1f...@sn...> wrote:

> The package wxGTK-gl-2.4.1-fr1 provides:
> /usr/lib/libwx_gtk_gl-2.4.so
> /usr/lib/libwx_gtk_gl-2.4.so.0
> /usr/lib/libwx_gtk_gl-2.4.so.0.0.0
>
> So an additional option does indeed fix it:
>
> ghc -package wx -o helloworld HelloWorld.hs -lwx_gtk_gl-2.4

Thanks for finding this out and testing on red hat 9. I would
like to add this note to the website (and maybe provide it
automatically through configure). Could you maybe tell
me in detail how you have build wxWidgets and how you
build wxHaskell? (you can send me a private email)

I have also never been able to get HOpenGL working on my
machine, so if you succeed in doing that I would love to
hear about it (and a screenshot would be nice :-)

Thanks,
  Daan.


>
>
> ----- Original message -----
> From: t1f...@sn...
> To: wxh...@li...
> Date: 24 Feb 2004 06:05:29 -0000
> Subject: wxGLCanvas
>
> Hello, I built and install wxHaskell on RedHat 9 (fully updated through
> freshrpms.net) without error.  However, now when I try to build the
> HelloWorld application, I get the following errors.  Should I be passing
> a library name to ghc?  Please help.  Thanks!!
>
> $ ghc -package wx -o helloworld HelloWorld.hs
> /usr/local/lib/libwxc-0.6.so: undefined reference to
> `wxGLCanvas::SwapBuffers()'/usr/local/lib/libwxc-0.6.so: undefined
> reference to `wxGLCanvas::SetColour(char const*)'
> /usr/local/lib/libwxc-0.6.so: undefined reference to
> `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, wxGLCanvas const*, int,
> wxPoint const&, wxSize const&, long,
> wxString const&, int*, wxPalette const&)'
> /usr/local/lib/libwxc-0.6.so: undefined reference to
> `wxGLCanvas::SetCurrent()'
> /usr/local/lib/libwxc-0.6.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
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Re: wxGLCanvas

[<t1f...@sn...>]

Nevermind, I figured it out.

The package wxGTK-gl-2.4.1-fr1 provides:
/usr/lib/libwx_gtk_gl-2.4.so
/usr/lib/libwx_gtk_gl-2.4.so.0
/usr/lib/libwx_gtk_gl-2.4.so.0.0.0

So an additional option does indeed fix it:

ghc -package wx -o helloworld HelloWorld.hs -lwx_gtk_gl-2.4



----- Original message -----
From: t1f...@sn...
To: wxh...@li...
Date: 24 Feb 2004 06:05:29 -0000
Subject: wxGLCanvas

Hello, I built and install wxHaskell on RedHat 9 (fully updated through
freshrpms.net) without error.  However, now when I try to build the
HelloWorld application, I get the following errors.  Should I be passing
a library name to ghc?  Please help.  Thanks!!

$ ghc -package wx -o helloworld HelloWorld.hs
/usr/local/lib/libwxc-0.6.so: undefined reference to
`wxGLCanvas::SwapBuffers()'/usr/local/lib/libwxc-0.6.so: undefined
reference to `wxGLCanvas::SetColour(char const*)'
/usr/local/lib/libwxc-0.6.so: undefined reference to
`wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, wxGLCanvas const*, int,
wxPoint const&, wxSize const&, long,
wxString const&, int*, wxPalette const&)'
/usr/local/lib/libwxc-0.6.so: undefined reference to
`wxGLCanvas::SetCurrent()'
/usr/local/lib/libwxc-0.6.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

[wxhaskell-users] wxGLCanvas

[<t1f...@sn...>]

Hello, I built and install wxHaskell on RedHat 9 (fully updated through freshrpms.net) without error.  However, now when I try to build the HelloWorld application, I get the following errors.  Should I be passing a library name to ghc?  Please help.  Thanks!!



$ ghc -package wx -o helloworld HelloWorld.hs

/usr/local/lib/libwxc-0.6.so: undefined reference to `wxGLCanvas::SwapBuffers()'/usr/local/lib/libwxc-0.6.so: undefined reference to `wxGLCanvas::SetColour(char const*)'

/usr/local/lib/libwxc-0.6.so: undefined reference to `wxGLCanvas::wxGLCanvas[in-charge](wxWindow*, wxGLCanvas const*, int, wxPoint const&, wxSize const&, long,

wxString const&, int*, wxPalette const&)'

/usr/local/lib/libwxc-0.6.so: undefined reference to `wxGLCanvas::SetCurrent()'

/usr/local/lib/libwxc-0.6.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

[wxhaskell-users] Re: [Haskell] Announce: wxHaskell 0.6

[Axel S. <A....@ke...>]

On Mon, Feb 23, 2004 at 01:33:38PM +0100, Daan Leijen wrote:
> Announcement: wxHaskell version 0.6
> ----------------------------------------------------------------------
> Tested on:
> - windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2
> - MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004)
> - MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2
> - Red Hat Linux 10 (Fedora) with ghc 6.2
> - FreeBSD, with ghc 5.05.xxxx and wxGTK 2.4.1
> - and wxHaskell has been known to run on other platforms :-)

It doesn't compile on Sun's Solaris. The linker falls over when building a 
shared library. Just in case anybody has succeeded in building on Solaris 
I'd like to know.

Thanks,
Axel.
 

[wxhaskell-users] Announce: wxHaskell 0.6

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

Announcement: wxHaskell version 0.6
----------------------------------------------------------------------

<http://wxhaskell.sourceforge.net>

This new release fixes many bugs, adds basic support for MDI
applications and compiles with the latest CVS snapshots of wxWidgets.
For now, only an installer for windows is provided.

All the best,
  Daan.

News (see the wxHaskell website for more information):
- wxWindows is now called wxWidgets! (and yes, it is due to Microsoft :-)
- wxWidgets runs on mobile phones (Symbian OS).
- Borland Builder-X will ship with wxWidgets as its windowing toolkit.

Updates:
- Support for MDI applications
- Combobox now catches enter keys through "on command"
- Many list-like controls now react on "on select" instead of "on command"
- Attribute "enable" is now called "enabled"
- Resize bugs are fixed,  new "dynamic" layout combinator added
- Repaint bugs are fixed, new "fullRepaintOnResize" attribute added.
- Basic support for unicode fonts (see the screenshots page)

Tested on:
- windowsXP and windows 2000 with ghc 6.2, 6.0.1, and wxMSW 2.4.2
- MacOS X 10.3 (Panther) with ghc 6.2 and wxMAC 2.5.1 (20 feb 2004)
- MacOS X 10.2 (Jaguar) with ghc 6.0.1 and wxMAC 2.4.2
- Red Hat Linux 10 (Fedora) with ghc 6.2
- FreeBSD, with ghc 5.05.xxxx and wxGTK 2.4.1
- and wxHaskell has been known to run on other platforms :-)


----------------------------------------------------------------------
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.

wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows
and MacOS X.

And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.

All the best,
   Daan Leijen.

Re: [wxhaskell-users] Build problems on Linux

[Andreas B. <ba...@in...>]

Hi Daan,

On Tue, Dec 23, 2003 at 04:34:30PM +0100, Daan Leijen wrote:

> You are building with GHC 6.2, and it has some different package names.
> You can fix it for now by adding the "parsec" package when building
> wxdirect. I think that a quick and dirty way to make it work
> would be to add the line:
> 
> HCFLAGS += -package parsec
> 
> to the start of the makefile.
> Unfortunately, I won't be able to check this as I don't have 6.2 yet.
> I am currently working on a new release (0.5) and that release will
> work with ghc 6.2 out of the box.

That did the trick.  Thanks heaps.

Cheers,
Andi.

Re: [wxhaskell-users] Build problems on Linux

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

Hi Andreas,

You are building with GHC 6.2, and it has some different package names.
You can fix it for now by adding the "parsec" package when building
wxdirect. I think that a quick and dirty way to make it work
would be to add the line:

HCFLAGS += -package parsec

to the start of the makefile.
Unfortunately, I won't be able to check this as I don't have 6.2 yet.
I am currently working on a new release (0.5) and that release will
work with ghc 6.2 out of the box.

Hope this helps,
  Daan.



On Tue, 23 Dec 2003 15:32:48 +0100, Andreas Bauer <ba...@in...> wrote:

> Hi all,
>
> a make of 0.4 under Linux, using wxGTK 2.4.2 reveals the following
> errors:
>
> -------------8<---------------------------------------------------------
>
> ghc  -o out/wxdirect/wxdirect out/wxdirect/Map.o out/wxdirect/Set.o out/wxdirect/MultiSet.o out/wxdirect/HaskellNames.o out/wxdirect/Types.o out/wxdirect/ParseEiffel.o out/wxdirect/ParseC.o out/wxdirect/Classes.o out/wxdirect/DeriveTypes.o out/wxdirect/CompileHeader.o out/wxdirect/CompileClassTypes.o out/wxdirect/CompileClasses.o out/wxdirect/CompileDefs.o out/wxdirect/Main.o
> out/wxdirect/Classes.o(.text+0x3d): In function `__stginit_Classes_':
> : undefined reference to `__stginit_TextziParserCombinatorsziParsec_'
> out/wxdirect/Classes.o(.text+0xa0): In function `rbR_srt':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_many_closure'
> out/wxdirect/Classes.o(.text+0xa4): In function `rbR_srt':
> : undefined reference to `TextziParserCombinatorsziParsecziChar_oneOf_closure'
> out/wxdirect/Classes.o(.text+0x122): In function `s2hr_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziChar_oneOf_closure'
> out/wxdirect/Classes.o(.text+0x18d): In function `rbR_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_many_closure'
> out/wxdirect/Classes.o(.text+0x1a0): In function `rc7_srt':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
> out/wxdirect/Classes.o(.text+0x1dc): In function `s2hO_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
> out/wxdirect/Classes.o(.text+0x24c): In function `s2hR_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
> out/wxdirect/Classes.o(.text+0x2b9): In function `rc7_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
> out/wxdirect/Classes.o(.text+0x2d0): In function `rc5_srt':
> : undefined reference to `TextziParserCombinatorsziParsecziCombinator_many1_closure'
> out/wxdirect/Classes.o(.text+0x2d4): In function `rc5_srt':
> : undefined reference to `TextziParserCombinatorsziParsecziChar_alphaNum_closure'
> out/wxdirect/Classes.o(.text+0x2fc): In function `s2hV_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziChar_alphaNum_closure'
> out/wxdirect/Classes.o(.text+0x301): In function `s2hV_entry':
> : undefined reference to `TextziParserCombinatorsziParsecziCombinator_many1_closure'
>
> -------------8<---------------------------------------------------------
>
> Any ideas what I am missing?  This is, obviously, a library dependency
> problem, but I can't figure it out myself.
>
>   $ ghc --version
>   The Glorious Glasgow Haskell Compilation System, version 6.2
>
> Please CC me in case you reply, as I am not member of this list (yet).
>
> Thanks in advance,
> Andi.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Build problems on Linux

[Andreas B. <ba...@in...>]

Hi all,

a make of 0.4 under Linux, using wxGTK 2.4.2 reveals the following
errors:

-------------8<---------------------------------------------------------

ghc  -o out/wxdirect/wxdirect out/wxdirect/Map.o out/wxdirect/Set.o out/wxdirect/MultiSet.o out/wxdirect/HaskellNames.o out/wxdirect/Types.o out/wxdirect/ParseEiffel.o out/wxdirect/ParseC.o out/wxdirect/Classes.o out/wxdirect/DeriveTypes.o out/wxdirect/CompileHeader.o out/wxdirect/CompileClassTypes.o out/wxdirect/CompileClasses.o out/wxdirect/CompileDefs.o out/wxdirect/Main.o
out/wxdirect/Classes.o(.text+0x3d): In function `__stginit_Classes_':
: undefined reference to `__stginit_TextziParserCombinatorsziParsec_'
out/wxdirect/Classes.o(.text+0xa0): In function `rbR_srt':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_many_closure'
out/wxdirect/Classes.o(.text+0xa4): In function `rbR_srt':
: undefined reference to `TextziParserCombinatorsziParsecziChar_oneOf_closure'
out/wxdirect/Classes.o(.text+0x122): In function `s2hr_entry':
: undefined reference to `TextziParserCombinatorsziParsecziChar_oneOf_closure'
out/wxdirect/Classes.o(.text+0x18d): In function `rbR_entry':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_many_closure'
out/wxdirect/Classes.o(.text+0x1a0): In function `rc7_srt':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
out/wxdirect/Classes.o(.text+0x1dc): In function `s2hO_entry':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
out/wxdirect/Classes.o(.text+0x24c): In function `s2hR_entry':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
out/wxdirect/Classes.o(.text+0x2b9): In function `rc7_entry':
: undefined reference to `TextziParserCombinatorsziParsecziPrim_zdfMonadGenParser_closure'
out/wxdirect/Classes.o(.text+0x2d0): In function `rc5_srt':
: undefined reference to `TextziParserCombinatorsziParsecziCombinator_many1_closure'
out/wxdirect/Classes.o(.text+0x2d4): In function `rc5_srt':
: undefined reference to `TextziParserCombinatorsziParsecziChar_alphaNum_closure'
out/wxdirect/Classes.o(.text+0x2fc): In function `s2hV_entry':
: undefined reference to `TextziParserCombinatorsziParsecziChar_alphaNum_closure'
out/wxdirect/Classes.o(.text+0x301): In function `s2hV_entry':
: undefined reference to `TextziParserCombinatorsziParsecziCombinator_many1_closure'

-------------8<---------------------------------------------------------

Any ideas what I am missing?  This is, obviously, a library dependency
problem, but I can't figure it out myself.

  $ ghc --version
  The Glorious Glasgow Haskell Compilation System, version 6.2

Please CC me in case you reply, as I am not member of this list (yet).

Thanks in advance,
Andi.

[wxhaskell-users] design questions

[<72...@in...>]

Hi Daan. I have been checking wxwindows docs, but I have seen nothing about 
exception handling. Do you know if wxwindows have a proper exception handling?. 
It is not very nice to core dump every time a WXCore call goes wrong, and 
haskell code cannot catch errors in wxc.dll. And the wxEiffel binding seems to 
ignore error handling, too.

Unrelated: I have seen you put strictness annotations on low-level haskell data 
like Point, Size, etc., but no in more abstract data like Layout. Why? Is it 
important for the performance?

Regards.

Jose David.



---------------------------------------------
Este mensaje lo ha enviado un Alumno de la Universidad de Malaga.
http://www.alumnos.uma.es/

[wxhaskell-users] strictness annotations on wxhaskell

[<72...@in...>]

Hi Daan, I hope you remember me, Jose David. I was developing my own yahu-like 
library. I have realized you use strictness annotations ('!' symbol) in the 
event and font algebraic data of WXCore, but no in more complex data, like 
Layout. Have you special reasons for this, or perhaps is performance-irrelevant 
to make strictness annotations in higher level data? I suposse it's because the 
way you modify the layout - maybe it is worth to no evaluate combinator-
replaced layout options. I ask you this stuff because I found almost no 
references about in the haskell report, the mailing list nor the hawiki.

By the way, do you know it is worth to make strictness annotations on multi-
argument data constructors? All I have found about this is that GHC unboxes 
single argument, strict annotated data constructors.

Thanks in advance.

Jose David.



---------------------------------------------
Este mensaje lo ha enviado un Alumno de la Universidad de Malaga.
http://www.alumnos.uma.es/

RE: [wxhaskell-users] Menues problem

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

Sorry for the previous mail, I accidently hit "ctrl-enter"...

Hi Gaby

> The compiler prompts this error
> menuprincipal.hs:23: The last statement in a 'do' construct must be an
expression

You probably have a layout error. This is a general Haskell syntax
issue and you may find more information on the Haskell faq or wiki
pages. anyhow:

1) replace all you "tab" characters by whitespace
2) neatly align all the statements in the "do" expression
3) check if all parenthesis match
4) and you might even add a "return ()" statement at the
   end to be safe

and things should work ok again.

All the best,
 Daan.