From: Daan L. <daa...@xs...> - 2003-09-16 13:25:11
|
Announcement: wxHaskell version 0.2 ---------------------------------------------------------------------- <http://wxhaskell.sourceforge.net> The new release has (improved) support for tree controls, list controls, toolbars, splitter windows, sliders, gauges, and bitmap buttons. Screenshots of these widgets on different platforms have been added to the website. Furthermore, there are numerous small bug fixes, especially for wxGTK. A list of non-compatible changes is attached at the end of this mail. ---------------------------------------------------------------------- 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 wxWindows -- 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 -- 2766 methods in 505 classes with 1279 constant definitions. wxHaskell has been build with GHC 6.0/6.01 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. ps. More funny statistics: the wxWindows libraries have been downloaded over a million times at sourceforge! The Python binding to wxWindows (wxPython) about 600.000 times, and the Haskell binding to wxWindows about 100 times :-) ---------------------------------------------------------------------- Breaking changes to version 0.1: - Renamed the "WXH" layer to "WXCore". > import Graphics.UI.WXCore instead of > import Graphics.UI.WXH - Changed the interface of menu items a bit. The label and help text is now supplied via attributes: > medit <- menuPane [text := "&Edit"] > mfont <- menuItem medit [text := "&Font...\tCtrl+F" > ,help := "Set the font"] |
From: Sven P. <Sve...@in...> - 2003-09-16 16:18:53
|
I just had a look at wxHaskell (GHC from CVS, about a week old, SuSE Linux 8.2 on x86). A few remarks: * It would be nice if the directory created by unzipping wxhaskell-src-0.2.zip contained a version number. * It would be even nicer if wxhaskell-doc-0.2.zip unzipped into a *single* directory. * You need `-package parsec' for linking wxdirect nowadays. * When HelloWorld terminates, it segfaults in wxVariant()'s destructor. I have no idea what's going on here, but I can only repeat my warnings stated some time ago: Mixing a C++ library with pure C (= GHC's code) is a highly delicate, platform/compiler dependent and fragile thing to do... * The package configuration should include linker flags for the path of libwxc.so, otherwise a non-superuser has to fiddle around with LD_LIBRARY_PATH and the like. Furthermore, the library documentation says: "Portability: portable", but this is not the case at all, wxHaskell uses quite a few extensions (apart from the FFI, which can be considered portable nowadays): * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around with unboxed values and GHC interna for performance reasons. Is this really necessary? (Apart from that, it triggers a bug in GHC's new Lexer :-} * The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses a scoped type variable. This could probably be rewritten to something more portable. * wx/src/Graphics/UI/WX/Attributes.hs uses existentially quantified data constructors (:=, :~, ::=, and ::~) for purely aesthetical reasons. * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with functional dependencies. * Type synonyms in instance heads + complex instance heads are quite pervasive: wx/src/Graphics/UI/WX/{Events,Window,Frame,Menu,Timer,Draw,Controls,Dialogs}.hs wxcore/src/Graphics/UI/WXCore/Layout.hs I don't want to sound too negative, Daan has done an impressive job, but I'm a bit concerned about all this non-portable stuff when we are planning to use wxHaskell as the basis for our GUI efforts. Cheers, S. |
From: Daan L. <daa...@xs...> - 2003-09-16 20:11:56
|
Hi Sven, > the library documentation says: "Portability: > portable", but this is not the case at all, wxHaskell uses > quite a few extensions (apart from the FFI, which can be > considered portable nowadays): wxHaskell consists of two layers: WXCore and WX. The WXCore layer is supposed to be totally Haskell98 compatible (or really easy to make compatible). The WX layer is a nice haskellized version of the wxWindows API on top of WXCore that uses extensions. > * wxcore/src/Graphics/UI/WXCore/IntMap.hs fiddles around > with unboxed values and GHC interna for performance reasons. Is this > really necessary? (Apart from that, it triggers a bug in GHC's new Lexer :-} No, it is not. Actually on <http://www.cs.uu.nl/~daan/ddata.html> you can find a Hugs98 and "standard" haskell98 version. I just used this one as I only use GHC but it can easily be replaced. > * The default declaration of setBitMask in wx/src/Graphics/UI/WX/Types.hs uses > a scoped type variable. This could probably be rewritten to something more > portable. Thanks for the hint. I'll remove the type declaration. > * wx/src/Graphics/UI/WX/Attributes.hs uses existentially > quantified data constructors (:=, :~, ::=, and ::~) for purely > aesthetical reasons. Yes, I am considering changing it to "=:" operators, that look less nice, but remove the dependency on rank-2 polymorphism. However, I haven't removed them yet as 1) not enough people complained, 2) any serious haskell compiler supports "forall" now, and 3) the (:=) operator looks *really* good, and 4) I depend on more devious things already which are harder to avoid, namely: > * Type synonyms in instance heads + complex instance heads are quite pervasive: This is a devious thing to do, but totally unavoidable given the way I model inheritance with phantom types. I have considered using type classes to model the inheritance but that leads to a) other dependencies on extensions, b) hard to understand error messages, and c) a much more complex model. (See Andre Pang's master thesis for a ingenious way to model full inheritance) On the other hand, phantom type inheritance is easy *and* using type synonyms in instance heads is *very* convenient (a huge improvement compared to all the instance declarations I had to write for GIO). (So, I guess I am making a case for supporting this extension in future Haskells as it is so useful). > * wx/src/Graphics/UI/WX/Classes.hs uses MPTC with > functional dependencies. Hmm, yes, but these could be removed -- they are not very important. > I don't want to sound too negative, Daan has done an > impressive job, but I'm a bit concerned about all this > non-portable stuff when we are planning to use wxHaskell as > the basis for our GUI efforts. I share your concerns. However, keep in mind that WXCore is Haskell98 + FFI, and that only the nicified abstraction WX uses extensions. That is, anyone can build another nicified abstraction that is H98 compatible. However, it seems that for "real" libraries, one wants a bit more power. In the end though, I would like wxHaskell to be an open community effort and not to be "daan's" library. In that sense, anyone can change the libraries interface if enough people support that. I am not emotionally attached to my design and will certainly support people that want to change or fix the library (especially given my lack of time to spend on this project :-). All the best, and thanks for your comments, Daan. > Cheers, > S. > > > _______________________________________________ > Haskell mailing list > Ha...@ha... http://www.haskell.org/mailman/listinfo/haskell > > |
From: Daan L. <daa...@xs...> - 2003-09-16 20:11:56
|
Hi Sven, (I'll reply to the portability issues in a separate mail) > * It would be nice if the directory created by unzipping > wxhaskell-src-0.2.zip contained a version number. > > * It would be even nicer if wxhaskell-doc-0.2.zip unzipped > into a *single* directory. > > * You need `-package parsec' for linking wxdirect nowadays. Thanks for the hints. I'll look into it for a future version. I will not actively support CVS GHC's though -- that will be too much work :-) > * When HelloWorld terminates, it segfaults in wxVariant()'s > destructor. I have no idea what's going on here, but I can only repeat my > warnings stated some time ago: Mixing a C++ library with pure C (= GHC's code) > is a highly delicate, platform/compiler dependent and fragile thing to do... I am quite sure that this has nothing to do with C vs. C++ :-) (I am not linking at all with C++ directly -- instead I am using extern C wrappers that are used in a separate dynamic link library with their own C++ runtime system. This is just like calling any other systems library. ) The segfault is really weird though -- it might be that you started "main" twice from GHCi (a known bug in wxGTK), that your GHC is broken, that you use an old GTK, anything really.... :-( > * The package configuration should include linker flags for > the path of libwxc.so, otherwise a non-superuser has to fiddle around with > LD_LIBRARY_PATH and the like. I am fairly hesitant here -- this means that I need two different package description files -- one for binary installs and one for developer installs. I'll look into it, but since I am not a real unix wizard, maybe you can tell me offline what you exactly need/want. All the best, Daan. |
From: Sven P. <Sve...@in...> - 2003-09-17 09:27:40
|
[ Removed Haskell list from Cc:, it's becoming a bit wxHaskell specific... ] Daan Leijen wrote: >> * You need `-package parsec' for linking wxdirect nowadays. > > Thanks for the hints. I'll look into it for a future version. > I will not actively support CVS GHC's though -- that will be too much > work :-) Well, if you like it or not: You'll have to handle versionitis somehow. The upcoming GHC 6.2 will need that flag, too. >> * When HelloWorld terminates, it segfaults in wxVariant()'s >>destructor. [...] > I am quite sure that this has nothing to do with C vs. C++ :-) > (I am not linking at all with C++ directly -- instead I am using extern C > wrappers that are used in a separate dynamic link library with their own > C++ runtime system. This is just like calling any other systems library.) No, it is not: A library has no "runtime system", it's usually the startup code which cares for things like global constructors/destructors, sets up exception handling, initializes the memory allocator, etc. And you get the correct startup code for the language you are using (C vs. C++) "under the hood" when linking your application together. At least that's the story for *nix systems I'm aware of, I don't have a clue on WinDoze. One of the problems with wxHaskell currently is that the applications are linked together (via GHC) with a C compiler, not a C++ one. > The segfault is really weird though -- it might be that you started > "main" twice from GHCi (a known bug in wxGTK), Nope, I used GHC and started the resulting executable directly. > that your GHC is broken, The usual "help desk" answer... ;-) > that you use an old GTK, I'm on the bleeding edge already, doing regular online updates of my SuSE system. > anything really.... :-( Another suspect is casting: I'm not quite sure what you are doing in the low-level parts, but I see a lot of casts. The problem is: In C++, casting is not necessarily value preserving for pointers in the presence of multiple inheritance (or virtual base classes, IIRC). >> * The package configuration should include linker flags for >>the path of libwxc.so, otherwise a non-superuser has to fiddle around >> with LD_LIBRARY_PATH and the like. > > I am fairly hesitant here -- this means that I need two different package > description files -- one for binary installs and one for developer installs. > I'll look into it, but since I am not a real unix wizard, maybe you can > tell me offline what you exactly need/want. I was thinking of something like an -rpath option for the linker, so that the resulting executable would automatically find the dynamic library. BTW, do we really need a *dynamic* library here? Cheers, S. |
From: Daan L. <daa...@xs...> - 2003-09-17 09:52:42
|
Hi Sven, > Well, if you like it or not: You'll have to handle > versionitis somehow. The upcoming GHC 6.2 will need that flag, too. Yes, I will handle versionitis :-) Just not CVS heads. > > I am quite sure that this has nothing to do with C vs. C++ :-) > > [snip] > > No, it is not: A library has no "runtime system", it's > [snip] I am quite sure that the startup code is correctly executed as all the C++ code is in a separate dynamic link library, and not linked in as an object file. One reason that I think it is ok is that I am using the same system as the wxEiffel people and they have used this on many unix and windows systems, even with the LCC compiler to compile their eiffel C code, and GCC to compile the C++ code. The wxPython project also combines it in the same kind of way. So, that is why I think we should first look at other causes for your segfault. Especially since no such problems have occurred on my test platforms: Red hat linux, Gentoo linux, and FreeBSD with GTK 1.2 and 2+. > Another suspect is casting: I'm not quite sure what you are > doing in the low-level parts, but I see a lot of casts. The problem is: In > C++, casting is not necessarily value preserving for pointers in the > presence of multiple inheritance (or virtual base classes, IIRC). Oh yeah, it is terrible on the low-level. My own extensions already use a typed interface without casting. However, remember that this is code that comes directly from the wxEiffel project and has been tested quite well over the years (and is semi-automatically generated). (and they are not "real" casts: just "void*" to class* -- not casts between classes). Maybe one day, the wx.NET binding gets far enough -- this is a somewhat cleaner binding that also lends itself well to automatic marshalling generation. > I was thinking of something like an -rpath option for the > linker, so that the resulting executable would automatically find the dynamic > library. BTW, do we really need a *dynamic* library here? Yes! otherwise we *do* get all those C vs. C++ linking problems that you describe. Actually, on most platforms you can't even link in C++ code due to all kinds of linking errors with the standard C libraries (stdc vs. stdc++) Maybe GHC can be convinced to use the C++ compiler to compile all its stuff?? That would surely solve our problems. For now, the user just has to fiddle with dynamic libraries but I'll look into the -rpath option. For the MacOSX installer, we just fix the path :-) (/usr/local/wxhaskell) (just as the GHC installer does btw). Question: I do use the "--soname" option when linking everything, maybe I can just put a full install path over there? Cheers, Daan. > > Cheers, > S. > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > > |
From: Wolfgang T. <wol...@gm...> - 2003-09-17 16:57:48
|
Let me provide a few comments about the C++ linking story.... Sven Panne wrote: > No, it is not: A library has no "runtime system", it's usually the > startup > code [...]. And you get the > correct startup code for the language you are using (C vs. C++) "under > the > hood" when linking your application together. On Mac OS X, Windows/Mingw32 and RedHat Linux 8, you get the same startup code no matter whether you use gcc or g++. The only difference between the gcc and g++ linker drivers is that g++ adds -lstdc++. On Mac OS X, every dynamic library gets it's own startup code (haven't checked on Linux or Windows, but I guess it's the same). Daan Leijen: > Yes! otherwise we *do* get all those C vs. C++ linking problems that > you describe. Actually, on most platforms you can't even link in C++ > code > due to all kinds of linking errors with the standard C libraries (stdc > vs. stdc++) > > Maybe GHC can be convinced to use the C++ compiler to compile all its > stuff?? That would surely solve our problems. A small mixed C++ & Haskell test program, runs fine on Mac OS X, Windows and RedHat 8 when I add -lstdc++ to the command line. On Windows, there's of course the problem that GHC includes it's own copy of GCC, but no C++ includes, but I happen to have another copy of them :-). While being short, my test program uses static constructors and destructors, and it calls the C++ standard library (iostream and string, to be exact), and everything works perfectly. What kinds of problems did you experience? GHCi, on the other hand, cannot currenlty load C++ object files (nor can it currently load the C++ standard library on systems where it's a static library), so using dynamic libraries is definitely necessary at least during development. Of course, it would be nice if I could just statically link my wxHaskell application when I'm done, but GHCi is more important. Cheers, Wolfgang |