You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(12) |
Aug
(34) |
Sep
(14) |
Oct
(36) |
Nov
(32) |
Dec
(15) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
(9) |
Mar
(31) |
Apr
(36) |
May
(17) |
Jun
(21) |
Jul
(13) |
Aug
(18) |
Sep
(2) |
Oct
(10) |
Nov
(18) |
Dec
(28) |
2005 |
Jan
(26) |
Feb
(15) |
Mar
(26) |
Apr
(11) |
May
(60) |
Jun
(3) |
Jul
(12) |
Aug
(4) |
Sep
(12) |
Oct
(19) |
Nov
(36) |
Dec
(10) |
2006 |
Jan
(6) |
Feb
(13) |
Mar
(6) |
Apr
(2) |
May
(9) |
Jun
(3) |
Jul
(6) |
Aug
(13) |
Sep
(1) |
Oct
(24) |
Nov
(33) |
Dec
(47) |
2007 |
Jan
(21) |
Feb
(41) |
Mar
(17) |
Apr
(9) |
May
(4) |
Jun
(20) |
Jul
(24) |
Aug
(71) |
Sep
(35) |
Oct
(10) |
Nov
(39) |
Dec
(39) |
2008 |
Jan
(24) |
Feb
(42) |
Mar
(61) |
Apr
(12) |
May
(11) |
Jun
(4) |
Jul
(9) |
Aug
(6) |
Sep
(6) |
Oct
(4) |
Nov
(3) |
Dec
(14) |
2009 |
Jan
(25) |
Feb
(18) |
Mar
(19) |
Apr
(24) |
May
(14) |
Jun
(7) |
Jul
(14) |
Aug
(25) |
Sep
(40) |
Oct
(20) |
Nov
(22) |
Dec
(4) |
2010 |
Jan
(55) |
Feb
(11) |
Mar
(9) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(7) |
Aug
(4) |
Sep
(15) |
Oct
(7) |
Nov
(2) |
Dec
(3) |
2011 |
Jan
(2) |
Feb
(1) |
Mar
(4) |
Apr
(6) |
May
(20) |
Jun
(30) |
Jul
(15) |
Aug
(4) |
Sep
(23) |
Oct
(24) |
Nov
(3) |
Dec
(8) |
2012 |
Jan
(23) |
Feb
(7) |
Mar
(19) |
Apr
(48) |
May
(8) |
Jun
(27) |
Jul
(10) |
Aug
(1) |
Sep
(11) |
Oct
(1) |
Nov
|
Dec
(3) |
2013 |
Jan
(1) |
Feb
|
Mar
(17) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2015 |
Jan
|
Feb
|
Mar
(14) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
2016 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Daan L. <daa...@xs...> - 2004-04-02 10:20:41
|
On Thu, 1 Apr 2004 16:08:51 -0500, Dylan Thurston <dp...@pe...> wrote: > On Thu, Apr 01, 2004 at 10:00:23AM +0100, Simon Marlow wrote: >> >> > Has anyone succeeded in getting wxhaskell to work under ghci on Linux? >> > On my system, I get an error message >> > >> > Loading package unix ... ghc-6.2: can't load .so/.DLL for: dl >> > (libdl.so: cannot open shared object file: No such file or directory) >> > >> > This sounds like it has nothing to do with wxhaskell, but is a GHC >> > problem. Any pointers? >> >> Is libdl.so in the usual place? (/usr/lib on my system) > > Yes. I have noticed that ghci can't load ".so" files that are stripped (while the ghc linker has no such problems.) -- Daan. (btw. I tested ghci on Fedora Core 1, and it works there) |
From: Gonzalo T. <gon...@so...> - 2004-04-02 02:17:52
|
Gour wrote: > Gonzalo Tarantola (gon...@so...) wrote: > > Hi! > > > > I'd also like to see Haskell getting more in the 'mainstream'. > Your project of writing GUI builder could be one nice step towards it. > I would also like that, and let's hope it helps! > > > Although not having (at the moment) enough time (besides testing building of > wxhaskell, ghc) to dive into Haskell & wxhaskell, I'm definitely interested > to use both of them in the future, I'm interested if the tool like wxglade > could be used with wxhaskell? > > There is also DialogBlocks dialog editor which 'understands' XRC too, as well > as wxDesigner. > > Maybe it will be worth to write Haskell application to parse XRC files and > generate appropriate wxhaskell code instead of writing GUI builder from a > scratch? > > In this way one can choose preferred GUI tool - free (wxglade) or commercial > (DialogBlocks & wxDesigner) and focusing on functional part of aplication in > Haskell. > > I think you're right. What you said was one of the approaches I was considering, and it can avoid me some headaches (But it'll get me others, surely :-)). I'll take a look at the tools you mention. > > These are some thoughts, but pls. bear in mind they are coming from one not > very familiar with the wxhaskell & Haskell programming . > Thanks for your opinions, I really appreciate them, they are very useful. > Sincerely, > Gour > Regards, Gonzalo |
From: Simon M. <sim...@mi...> - 2004-04-01 09:00:39
|
=20 > Has anyone succeeded in getting wxhaskell to work under ghci on Linux? > On my system, I get an error message >=20 > Loading package unix ... ghc-6.2: can't load .so/.DLL for: dl=20 > (libdl.so: cannot open shared object file: No such file or directory) >=20 > This sounds like it has nothing to do with wxhaskell, but is a GHC > problem. Any pointers? Is libdl.so in the usual place? (/usr/lib on my system) Cheers, Simon |
From: Daan L. <daa...@xs...> - 2004-04-01 08:28:17
|
On Thu, 1 Apr 2004 02:43:09 -0500, Dylan Thurston <dp...@pe...> wrote: > On Wed, Mar 03, 2004 at 01:50:58PM +0100, Daan Leijen wrote: >> >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). > > No, the wxhaskell install also writes to the GHC packages file, which > is at /usr/lib/ghc-6.2/package.conf on my system. You should use the "--package-conf" option to configure. Use "configure --help" to see all options. In general, to build locally, I use something like: > ./configure --prefix=~/local/wxhaskell --package-conf=~/packages Use "configure --help" to see all options. (Note that you can only use "~" with the latest cvs, use /home/name to circumvent this) If you also build wxWidgets locally: > ../configure --prefix=/home/daan/local/wxGTK-2.4.2 --disable-shared (Note "--disable-shared" is only recommended for the latest CVS version of wxhaskell (version 0.7)) Now, you can use for wxhaskell: > ./configure --wx-config=/home/daan/local/wxGTK-2.4.2/bin/wx-config --prefix=/home/daan/local/wxhaskell-gtk2.4.2 --package-conf=/home/daan/packages And than you can build multiple version next to each other (although you can only register one version with ghc each time). Note that you can use "make install", and "make uninstall" to test each version seperately. (with the latests CVS (version 0.7) the makefile knows about "DESTDIR", so you could sandbox that way too. There is also a "make install-files" that won't register the package. See "make help" for all targets.) All the best, Daan. Btw. I am currently in the process of releasing version 0.7, which will include rpm's this time :-) |
From: Gour <go...@ma...> - 2004-03-31 07:41:05
|
Gonzalo Tarantola (gon...@so...) wrote: Hi! > By the way, I plan to use wxHaskell in a project for university. Let me > tell you briefly what I want to do: > The first goal is to write a GUI builder in Haskell. I want the > application to show that Haskell can be a powerfull language for > prototyping and rapid application development (or at leas to be a > practical tool for that "weird people that program in Haskell"[1]). I'd also like to see Haskell getting more in the 'mainstream'. Your project of writing GUI builder could be one nice step towards it. > I would like to use wxHaskell to make the builder, and the builder > output will also use wxHaskell. If I manage to do that, I think it will > also help to show the strength of the wxHaskell library. Although not having (at the moment) enough time (besides testing building of wxhaskell, ghc) to dive into Haskell & wxhaskell, I'm definitely interested to use both of them in the future, I'm interested if the tool like wxglade could be used with wxhaskell? There is also DialogBlocks dialog editor which 'understands' XRC too, as well as wxDesigner. Maybe it will be worth to write Haskell application to parse XRC files and generate appropriate wxhaskell code instead of writing GUI builder from a scratch? In this way one can choose preferred GUI tool - free (wxglade) or commercial (DialogBlocks & wxDesigner) and focusing on functional part of aplication in Haskell. > > Well, that's all. If anyone have any comments or useful information, > please let me know. These are some thoughts, but pls. bear in mind they are coming from one not very familiar with the wxhaskell & Haskell programming . Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Gonzalo T. <gon...@so...> - 2004-03-31 03:13:25
|
First of all, thanks for your help I'm using wxGTK 2.4.2, so it shouldn't be the problem. I'll try to get the latest wxhaskell from CVS and see what I can do. By the way, I plan to use wxHaskell in a project for university. Let me tell you briefly what I want to do: The first goal is to write a GUI builder in Haskell. I want the application to show that Haskell can be a powerfull language for prototyping and rapid application development (or at leas to be a practical tool for that "weird people that program in Haskell"[1]). I would like to use wxHaskell to make the builder, and the builder output will also use wxHaskell. If I manage to do that, I think it will also help to show the strength of the wxHaskell library. Well, that's all. If anyone have any comments or useful information, please let me know. Regards, Gonzalo Tarantola [1] At least in my University, most students avoid functional programming as much as they can. Daan Leijen wrote: > On Sat, 27 Mar 2004 16:16:53 -0300, Gonzalo Tarantola > <gon...@so...> wrote: > >> Hi. Can anybody help me? >> >> I'm trying to install wxHaskell 0.6, but when I type make I get the >> following: > > > Hi Gonzalo, > > It is hard to guess what causes your problems. I think though that you > are trying to use wxHaskell 0.6 with wxGTK 2.5.1? In that case, > there are two solutions: > > 1) use wxGTK 2.4.2 (instead of 2.5.1) > 2) use the latest wxHaskell from CVS and configure wxGTK with > the "--disable-shared" flag. (see > <http://wxhaskell.sf.net/building.html>) > > I hope this helps, > All the best, > Daan. > > > |
From: Gour <go...@ma...> - 2004-03-30 09:07:48
|
Daan Leijen (daa...@xs...) wrote: > Hi Gour, > > The functions that are missing are indeed missing from the wxHaskell > library since version 0.4 (?). Anyway, you probably didn't rebuild the > wxHaskell library properly and you are linking against an older libwxcore0. > (ie. do a clean compile of everything). Thank you Daan. You're right. Some old libraries were lingering around, probably from some of my unproper ebuilds in the past. (otherwise, Gentoo keeps everything nicely.) Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Daan L. <daa...@xs...> - 2004-03-29 19:03:22
|
On Mon, 29 Mar 2004 19:33:13 +0200, Gour <go...@ma...> wrote: > I have problem when linking darcs pn my Gentoo box. > > I have tried to checkout latest wxhaskell code, but still I get the same errors. Hi Gour, The functions that are missing are indeed missing from the wxHaskell library since version 0.4 (?). Anyway, you probably didn't rebuild the wxHaskell library properly and you are linking against an older libwxcore0. (ie. do a clean compile of everything). All the best, Daan. > [...] > ghc -optc-Os -optc-march=pentium3 -optc-mfpmath=sse -optc-msse -optc-mmmx -optc-fomit-frame-pointer -optc-pipe -optc-funroll-loops -c hscurl.c > ghc -optc-Os -optc-march=pentium3 -optc-mfpmath=sse -optc-msse -optc-mmmx -optc-fomit-frame-pointer -optc-pipe -optc-funroll-loops -c rts.c > Linking darcs ... > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x736f): In function `sU1M_entry': > : undefined reference to `ELJApp_SendIdleEventsToWindow' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x7476): In function `sU24_entry': > : undefined reference to `ELJApp_SendIdleEvents' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x7ea6): In function `sU4k_entry': > : undefined reference to `ELJApp_GetWantDebugOutput' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x6ce0f): In function `s1dtl_ret': > : undefined reference to `wxNavigationKeyEvent_SetPropagate' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x82a1b): In function `s12nk_entry': > : undefined reference to `wxListEvent_GetOldItem' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x82bc7): In function `s12nH_entry': > : undefined reference to `wxListEvent_GetOldIndex' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xc8fab): In function `s1cFK_ret': > : undefined reference to `wxDllLoader_LoadLibrary' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xf5e47): In function `s1cgH_ret': > : undefined reference to `wxDllLoader_GetSymbol' > /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xf5fb5): In function `s1cgE_ret': > : undefined reference to `wxDllLoader_UnloadLibrary' > collect2: ld returned 1 exit status > make: *** [darcs] Error 1 > > > I have wxGTK-2.4.2. > > Any idea? > > Sincerely, > Gour > > |
From: Gour <go...@ma...> - 2004-03-29 17:33:41
|
Hi! I have problem when linking darcs pn my Gentoo box. I have tried to checkout latest wxhaskell code, but still I get the same errors. [...] ghc -optc-Os -optc-march=pentium3 -optc-mfpmath=sse -optc-msse -optc-mmmx -optc-fomit-frame-pointer -optc-pipe -optc-funroll-loops -c hscurl.c ghc -optc-Os -optc-march=pentium3 -optc-mfpmath=sse -optc-msse -optc-mmmx -optc-fomit-frame-pointer -optc-pipe -optc-funroll-loops -c rts.c Linking darcs ... /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x736f): In function `sU1M_entry': : undefined reference to `ELJApp_SendIdleEventsToWindow' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x7476): In function `sU24_entry': : undefined reference to `ELJApp_SendIdleEvents' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x7ea6): In function `sU4k_entry': : undefined reference to `ELJApp_GetWantDebugOutput' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x6ce0f): In function `s1dtl_ret': : undefined reference to `wxNavigationKeyEvent_SetPropagate' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x82a1b): In function `s12nk_entry': : undefined reference to `wxListEvent_GetOldItem' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0x82bc7): In function `s12nH_entry': : undefined reference to `wxListEvent_GetOldIndex' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xc8fab): In function `s1cFK_ret': : undefined reference to `wxDllLoader_LoadLibrary' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xf5e47): In function `s1cgH_ret': : undefined reference to `wxDllLoader_GetSymbol' /usr/lib/libwxcore0.a(WxcClasses.o)(.text+0xf5fb5): In function `s1cgE_ret': : undefined reference to `wxDllLoader_UnloadLibrary' collect2: ld returned 1 exit status make: *** [darcs] Error 1 I have wxGTK-2.4.2. Any idea? Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Daan L. <daa...@xs...> - 2004-03-29 09:15:05
|
On Sat, 27 Mar 2004 16:16:53 -0300, Gonzalo Tarantola <gon...@so...> wrote: > Hi. Can anybody help me? > > I'm trying to install wxHaskell 0.6, but when I type make I get the > following: Hi Gonzalo, It is hard to guess what causes your problems. I think though that you are trying to use wxHaskell 0.6 with wxGTK 2.5.1? In that case, there are two solutions: 1) use wxGTK 2.4.2 (instead of 2.5.1) 2) use the latest wxHaskell from CVS and configure wxGTK with the "--disable-shared" flag. (see <http://wxhaskell.sf.net/building.html>) I hope this helps, All the best, Daan. > > ~/Sources/wxHaskell/wxhaskell-0.6>make > c++ -c wxc/src/ewxw_main.cpp -o out/wxc/ewxw_main.o -MD > -I/usr/local/lib/wx/include/gtk2u-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ > -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Iwxc/include > In file included from wxc/src/ewxw_main.cpp:1: > wxc/include/wrapper.h: In constructor ` > ELJDragDataObject::ELJDragDataObject(void*, char*, int (*)(void*), int > (*)(void*, void*), int (*)(void*, int, const void*))': > wxc/include/wrapper.h:172: error: no matching function for call to ` > wxDataObjectSimple::wxDataObjectSimple(char*&)' > /usr/local/include/wx/dataobj.h:193: error: candidates are: > wxDataObjectSimple::wxDataObjectSimple(const wxDataObjectSimple&) > /usr/local/include/wx/dataobj.h:198: error: > wxDataObjectSimple::wxDataObjectSimple(const wxDataFormat& = > wxFormatInvalid) > wxc/include/wrapper.h: In constructor ` > ELJTextValidator::ELJTextValidator(void*, void*, void*, long int)': > wxc/include/wrapper.h:256: error: ambiguous overload for `wxString& = const > char*&' operator > /usr/local/include/wx/string.h:278: error: candidates are: wxString& > wxString::operator=(int) <near match> > /usr/local/include/wx/string.h:519: error: wxString& > wxString::operator=(const wxString&) <near match> > /usr/local/include/wx/string.h:521: error: wxString& > wxString::operator=(wchar_t) <near match> > /usr/local/include/wx/string.h:527: error: wxString& > wxString::operator=(const wxWCharBuffer&) <near match> > wxc/include/wrapper.h: At global scope: > wxc/include/wrapper.h:330: error: conflicting return type specified for ` > virtual char* ELJConnection::OnRequest(const wxString&, const wxString&, > int*, wxIPCFormat)' > /usr/local/include/wx/ipcbase.h:86: error: overriding `virtual wxChar* > wxConnectionBase::OnRequest(const wxString&, const wxString&, int*, > wxIPCFormat)' > wxc/include/wrapper.h: In constructor > `ELJConnection::ELJConnection(char*, int) > ': > wxc/include/wrapper.h:300: error: no matching function for call to ` > wxTCPConnection::wxTCPConnection(char*&, int&)' > /usr/local/include/wx/sckipc.h:60: error: candidates are: > wxTCPConnection::wxTCPConnection(wxTCPConnection&) > /usr/local/include/wx/sckipc.h:65: error: > wxTCPConnection::wxTCPConnection() > /usr/local/include/wx/sckipc.h:64: error: > wxTCPConnection::wxTCPConnection(wxChar*, int) > wxc/include/wrapper.h: In constructor `ELJPrintout::ELJPrintout(void*, > void*, > void*, void*, void*, void*, void*, void*, void*, void*)': > wxc/include/wrapper.h:412: error: conversion from `char*' to `const > wxString' > is ambiguous > /usr/local/include/wx/string.h:306: error: candidates are: > wxString::wxString(wchar_t, unsigned int = 1) <near match> > /usr/local/include/wx/string.h:284: error: > wxString::wxString(int) <near match> > wxc/include/wrapper.h: In constructor > `ELJPreviewFrame::ELJPreviewFrame(void*, > void*, void*, void*, void*, void*, void*, int, int, int, int, int)': > wxc/include/wrapper.h:474: error: conversion from `char*' to `const > wxString' > is ambiguous > /usr/local/include/wx/string.h:306: error: candidates are: > wxString::wxString(wchar_t, unsigned int = 1) <near match> > /usr/local/include/wx/string.h:284: error: > wxString::wxString(int) <near match> > wxc/include/wrapper.h: At global scope: > wxc/include/wrapper.h:533: error: invalid type `const char[11]' for default > argument to `const wxString&' > make: *** [out/wxc/ewxw_main.o] Error 1 > > > It looks to me like some type errors. How do I fix them? I tried with > wxhaskell 0.5 and I got the same result. > > > If it helps, the compiler version is > ~/Sources/wxHaskell/wxhaskell-0.6>c++ --version > c++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux) > > Thanks in advance, > > Gonzalo Tarantola > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users > |
From: Daan L. <daa...@xs...> - 2004-03-29 09:15:04
|
On Thu, 25 Mar 2004 17:42:41 +0000, Ian Lynagh <ig...@ea...> wrote: > Oh, I forgot to add that I could eliminate the flicker with > fullRepaintOnResize but then I can cause the screen to be redrawn > incorrectly as follows: Hmm, this doesn't happen on windows... I'll try it on wxGTK 2.5.1 to see what happens. > Hmm, but this only lets you specify globally whether you want to use > OpenGL, right? What I'd want to be able to do is install a single copy > of wxHaskell and use it to make either non-OpenGL or OpenGL programs. > Currently if I have the ability to make OpenGL programs then any > non-OpenGL programs I create will need to be linked against the GL > libraries anyway. Perhaps wxHaskell should create a libwxc-gl-0.6.so too > which contains the code for the OpenGL wxHaskell functionality to solve > this? In the same way that we have libwx_gtk-2.4.so.0 and > libwx_gtk_gl-2.4.so.0. I never thought about this. In the case of shared libraries, you are definitely right and we should generate two versions. However, I can now (in cvs head) link with static wxWidgets libraries, so I think that I can always support openGL in wxHaskell (as libwx_gtk_gl.a is linked in statically) -- the only question that remains is whether the application will load the system openGL libraries on demand or requires them to be present? (in the latter case, we need to provide two versions too). I am not to eager to provide two different versions of wxHaskell, so we should test first whether static linkage will work for us. Thanks for mentioning this, All the best, Daan. |
From: Gonzalo T. <gon...@so...> - 2004-03-27 19:16:40
|
Hi. Can anybody help me? I'm trying to install wxHaskell 0.6, but when I type make I get the following: ~/Sources/wxHaskell/wxhaskell-0.6>make c++ -c wxc/src/ewxw_main.cpp -o out/wxc/ewxw_main.o -MD -I/usr/local/lib/wx/include/gtk2u-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -Iwxc/include In file included from wxc/src/ewxw_main.cpp:1: wxc/include/wrapper.h: In constructor ` ELJDragDataObject::ELJDragDataObject(void*, char*, int (*)(void*), int (*)(void*, void*), int (*)(void*, int, const void*))': wxc/include/wrapper.h:172: error: no matching function for call to ` wxDataObjectSimple::wxDataObjectSimple(char*&)' /usr/local/include/wx/dataobj.h:193: error: candidates are: wxDataObjectSimple::wxDataObjectSimple(const wxDataObjectSimple&) /usr/local/include/wx/dataobj.h:198: error: wxDataObjectSimple::wxDataObjectSimple(const wxDataFormat& = wxFormatInvalid) wxc/include/wrapper.h: In constructor ` ELJTextValidator::ELJTextValidator(void*, void*, void*, long int)': wxc/include/wrapper.h:256: error: ambiguous overload for `wxString& = const char*&' operator /usr/local/include/wx/string.h:278: error: candidates are: wxString& wxString::operator=(int) <near match> /usr/local/include/wx/string.h:519: error: wxString& wxString::operator=(const wxString&) <near match> /usr/local/include/wx/string.h:521: error: wxString& wxString::operator=(wchar_t) <near match> /usr/local/include/wx/string.h:527: error: wxString& wxString::operator=(const wxWCharBuffer&) <near match> wxc/include/wrapper.h: At global scope: wxc/include/wrapper.h:330: error: conflicting return type specified for ` virtual char* ELJConnection::OnRequest(const wxString&, const wxString&, int*, wxIPCFormat)' /usr/local/include/wx/ipcbase.h:86: error: overriding `virtual wxChar* wxConnectionBase::OnRequest(const wxString&, const wxString&, int*, wxIPCFormat)' wxc/include/wrapper.h: In constructor `ELJConnection::ELJConnection(char*, int) ': wxc/include/wrapper.h:300: error: no matching function for call to ` wxTCPConnection::wxTCPConnection(char*&, int&)' /usr/local/include/wx/sckipc.h:60: error: candidates are: wxTCPConnection::wxTCPConnection(wxTCPConnection&) /usr/local/include/wx/sckipc.h:65: error: wxTCPConnection::wxTCPConnection() /usr/local/include/wx/sckipc.h:64: error: wxTCPConnection::wxTCPConnection(wxChar*, int) wxc/include/wrapper.h: In constructor `ELJPrintout::ELJPrintout(void*, void*, void*, void*, void*, void*, void*, void*, void*, void*)': wxc/include/wrapper.h:412: error: conversion from `char*' to `const wxString' is ambiguous /usr/local/include/wx/string.h:306: error: candidates are: wxString::wxString(wchar_t, unsigned int = 1) <near match> /usr/local/include/wx/string.h:284: error: wxString::wxString(int) <near match> wxc/include/wrapper.h: In constructor `ELJPreviewFrame::ELJPreviewFrame(void*, void*, void*, void*, void*, void*, void*, int, int, int, int, int)': wxc/include/wrapper.h:474: error: conversion from `char*' to `const wxString' is ambiguous /usr/local/include/wx/string.h:306: error: candidates are: wxString::wxString(wchar_t, unsigned int = 1) <near match> /usr/local/include/wx/string.h:284: error: wxString::wxString(int) <near match> wxc/include/wrapper.h: At global scope: wxc/include/wrapper.h:533: error: invalid type `const char[11]' for default argument to `const wxString&' make: *** [out/wxc/ewxw_main.o] Error 1 It looks to me like some type errors. How do I fix them? I tried with wxhaskell 0.5 and I got the same result. If it helps, the compiler version is ~/Sources/wxHaskell/wxhaskell-0.6>c++ --version c++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux) Thanks in advance, Gonzalo Tarantola |
From: Ian L. <ig...@ea...> - 2004-03-25 17:42:46
|
On Thu, Mar 25, 2004 at 11:32:17AM +0100, Daan Leijen wrote: > Hi Ian, > > >I've written a simple application using wxHaskell, mainly to see how the > >library works. It's at http://urchin.earth.li/~ian/mamot/ > > Ha, I have another screenshot :-) :-) > >I'm not sure how to get it to both display correctly and not flicker. > >I've tried various combinations of dcBuffer, windowFreeze/windowThaw, > >fullRepaintOnResize := False, but don't seem to have hit upon the magic > >combination yet? > > I want to document this soon, as it is rather obscurely done in wxWidgets. > I'll look into this issue in some more detail, maybe I can come up with > a nice abstraction. > > For now, you need to set "fullRepaintOnResize" indeed to "False", but you > need to > do that for both the frame and panel (and drawing areas?). Oh, I forgot to add that I could eliminate the flicker with fullRepaintOnResize but then I can cause the screen to be redrawn incorrectly as follows: * Make the window too small so the scroll bar appears * Scroll fully to the right * Make the window wider on the right The right hand side is then redrawn as the window gets bigger so you get lots of rights stuck on the right of the original left. My word that sentence is confusing - see http://urchin.earth.li/~ian/iv_rights.png for a screenshot. > Furthermore, it > could help to set the "wxCLIP_CHILDREN" flag. Try: Doing this to both alters the symptoms but it still isn't right. > Look also to the "imageviewer" sample. This also happens with your image viewer. > >The scrolled window seems to like increasing its virtual size when > >the window gets bigger unless I explicitly keep resetting it. Is there a > >nice way to get the behaviour I want? > > You have to be more specific about the behaviour you want -- should the > virtual size stay the same when the window is resized? Yes, sorry. The problem was that when the window got bigger the scrolled area was increasing its virtual size to match and so was getting scrollbars as soon as it was made any smaller. This doesn't seem to happen with your image viewer, though, so it might have just been me doing something silly and I can't easily check now, so probably best to ignore this one unless it comes up again. > >I have to give the "wx-config --gl-libs" options as well as the "--libs" > >ones when linking. Otherwise I get things like > > This is bug is fixed now -- cvs head lets you give the "--with-opengl" > flag to configure. Hmm, but this only lets you specify globally whether you want to use OpenGL, right? What I'd want to be able to do is install a single copy of wxHaskell and use it to make either non-OpenGL or OpenGL programs. Currently if I have the ability to make OpenGL programs then any non-OpenGL programs I create will need to be linked against the GL libraries anyway. Perhaps wxHaskell should create a libwxc-gl-0.6.so too which contains the code for the OpenGL wxHaskell functionality to solve this? In the same way that we have libwx_gtk-2.4.so.0 and libwx_gtk_gl-2.4.so.0. Thanks Ian |
From: Ian L. <ig...@ea...> - 2004-03-25 17:15:13
|
On Thu, Mar 25, 2004 at 12:04:59PM +0100, Daan Leijen wrote: > On Wed, 24 Mar 2004 18:52:52 +0000, Ian Lynagh <ig...@ea...> wrote: > > >Finally, when my program starts up it decides to be as small as > >possible. Again I haven't found the right way of convincing it to start > >off at some sensible size. > > I just found out that you can just say: > > >set f [clientSize := sz 300 300] > > after setting the "layout" and the window will have that initial size. > (on windowsXP at least) Aha, yup, thanks! I suspect it was the difference between set f [layout := fill (widget s), clientSize := sz 300 300] and set f [clientSize := sz 300 300, layout := fill (widget s)] that caught me out (but that's a wxWidgets issue rather than a wxHaskell one, of course). Thanks Ian |
From: Daan L. <daa...@xs...> - 2004-03-25 11:05:00
|
On Wed, 24 Mar 2004 18:52:52 +0000, Ian Lynagh <ig...@ea...> wrote: > Finally, when my program starts up it decides to be as small as > possible. Again I haven't found the right way of convincing it to start > off at some sensible size. I just found out that you can just say: > set f [clientSize := sz 300 300] after setting the "layout" and the window will have that initial size. (on windowsXP at least) -- Daan. |
From: Daan L. <daa...@xs...> - 2004-03-25 10:32:32
|
Hi Ian, > I've written a simple application using wxHaskell, mainly to see how the > library works. It's at http://urchin.earth.li/~ian/mamot/ Ha, I have another screenshot :-) > I'm not sure how to get it to both display correctly and not flicker. > I've tried various combinations of dcBuffer, windowFreeze/windowThaw, > fullRepaintOnResize := False, but don't seem to have hit upon the magic > combination yet? I want to document this soon, as it is rather obscurely done in wxWidgets. I'll look into this issue in some more detail, maybe I can come up with a nice abstraction. For now, you need to set "fullRepaintOnResize" indeed to "False", but you need to do that for both the frame and panel (and drawing areas?). Furthermore, it could help to set the "wxCLIP_CHILDREN" flag. Try: f <- frame [fullRepaintOnResize := False, style :~ \st -> st .+. wxCLIP_CHILDREN] Look also to the "imageviewer" sample. > I haven't worked out yet what "set p [defaultButton := ok]" does other > than set focus. To actually make a default button I need to do > "buttonSetDefault ok". Strange -- I'll try to fix this. (right now, the method "panelSetDefaultItem" is used instead of "buttonSetDefault") > m_metaDown seems to reflect whether numlock is on or not. As "on click" > checks that none of the modifiers are down this is quite annoying. Thanks for mentioning this, I'll check it on the Mac and if the behaviour is the same, I'll remove that check from "on click". > The scrolled window seems to like increasing its virtual size when > the window gets bigger unless I explicitly keep resetting it. Is there a > nice way to get the behaviour I want? You have to be more specific about the behaviour you want -- should the virtual size stay the same when the window is resized? > I have to give the "wx-config --gl-libs" options as well as the "--libs" > ones when linking. Otherwise I get things like This is bug is fixed now -- cvs head lets you give the "--with-opengl" flag to configure. > The program is 7M, or 3M after stripping. Perhaps this could be reduced > if -split-objs was used when compiling wxHaskell? Yes, I think so. It might even greatly reduce the program size but I haven't tried so yet. For now, I use "upx" on windows to pack the ".dll" (== ".so") file which reduces the 3M to about 600kb with microsoft visual c++. > Finally, when my program starts up it decides to be as small as > possible. Again I haven't found the right way of convincing it to start > off at some sensible size. A way around this is to give a minimal size (using "minsize" in the layout) However, the proper way to do this is of course to specify an "initial size", but I don't know yet how to do that -- but I'll look into it. Thanks for your comments, All the best, Daan. |
From: Ian L. <ig...@ea...> - 2004-03-24 18:52:55
|
Hi all, I've written a simple application using wxHaskell, mainly to see how the library works. It's at http://urchin.earth.li/~ian/mamot/ However, I've run into a few problems (using Debian's wxgtk 2.4.2.4 and wxHaskell 0.6): I'm not sure how to get it to both display correctly and not flicker. I've tried various combinations of dcBuffer, windowFreeze/windowThaw, fullRepaintOnResize := False, but don't seem to have hit upon the magic combination yet? I haven't worked out yet what "set p [defaultButton := ok]" does other than set focus. To actually make a default button I need to do "buttonSetDefault ok". m_metaDown seems to reflect whether numlock is on or not. As "on click" checks that none of the modifiers are down this is quite annoying. The scrolled window seems to like increasing its virtual size when the window gets bigger unless I explicitly keep resetting it. Is there a nice way to get the behaviour I want? I have to give the "wx-config --gl-libs" options as well as the "--libs" ones when linking. Otherwise I get things like /usr/lib/libwxc-0.6.so: undefined reference to `wxGLCanvas::SwapBuffers()' Splitting the library so the GL libraries are only necessary if you are using the GL functionality would be nice. The program is 7M, or 3M after stripping. Perhaps this could be reduced if -split-objs was used when compiling wxHaskell? Finally, when my program starts up it decides to be as small as possible. Again I haven't found the right way of convincing it to start off at some sensible size. Thanks Ian |
From: Jens P. <pet...@re...> - 2004-03-24 13:48:26
|
>>>>> "Daan" == Daan Leijen <daa...@xs...> writes: Daan> Announcement: wxHaskell version 0.6 I just uploaded a rpm package built for ghc-6.2.1 on Fedora Core 1 to: http://haskell.org/~petersen/rpms/wxhaskell/?C=M&O=D Jens |
From: Gour <go...@ma...> - 2004-03-04 08:39:30
|
Andres Loeh (kos...@ge...) wrote: > I already noticed that. I have just fixed it (hopefully) in > dev-haskell/wxhaskell-0.6-r1. Yup. This one works. Thanks. Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Andres L. <kos...@ge...> - 2004-03-03 22:49:52
|
> Just to report that your ebuild successsfuly emerged on my Gentoo box. > > So far I only tested it with HelloWorld.hs which gives: > > ./hello: error while loading shared libraries: libwxc-0.6.so: cannot open shared object file: No such file or directory > > (I'll try to debug it later.) I already noticed that. I have just fixed it (hopefully) in dev-haskell/wxhaskell-0.6-r1. > Thank you very much for contributing (very educative) ebuild for wxhaskell. You're welcome. Best, Andres |
From: Gour <go...@ma...> - 2004-03-03 21:42:31
|
Andres Loeh (kos...@ge...) wrote: Hi Andres, > I have just committed a dev-haskell/wxhaskell-0.6 ebuild to the Gentoo > CVS, so it should propagate within the next hour. I had it lying > around for some time now, but never got around to actually adding it. > It is tested on exactly one machine right now, but there seems to be > request for it -- so please test and provide feedback, also if it works > fine. Just to report that your ebuild successsfuly emerged on my Gentoo box. So far I only tested it with HelloWorld.hs which gives: ./hello: error while loading shared libraries: libwxc-0.6.so: cannot open shared object file: No such file or directory (I'll try to debug it later.) Thank you very much for contributing (very educative) ebuild for wxhaskell. Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: <wxh...@al...> - 2004-03-03 20:58:17
|
> I have added the library flags needed to link in the wx-gl libaries. > I hope it actually still works with a non-opengl-enabled version > of wxGTK, I haven't tried that. It does, I communicated this in private to Daan. "wx-config --gl-libs" on a non-OpenGL capable version of wxGTK returns the empty string. |
From: Andres L. <kos...@ge...> - 2004-03-03 17:35:42
|
[rearranged the original message a bit] > >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. I have just committed a dev-haskell/wxhaskell-0.6 ebuild to the Gentoo CVS, so it should propagate within the next hour. I had it lying around for some time now, but never got around to actually adding it. It is tested on exactly one machine right now, but there seems to be request for it -- so please test and provide feedback, also if it works fine. > >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. You can just specify multiple URI's in SRC_URI, and all of them get downloaded and unpacked by default. As Daan pointed out, in the case of wxhaskell, it's not needed though, as the source distribution contains everything to build the documentation. > >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. addwrite for the installation process is not an option. Usually, some combination of patching, setting prefix, or being lucky and have DESTDIR, helps. > 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. Should not be a problem. You could probably modify the Makefile and send the patch to Daan. I'm sure he will consider to apply it. > >>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. I have added the library flags needed to link in the wx-gl libaries. I hope it actually still works with a non-opengl-enabled version of wxGTK, I haven't tried that. Best, Andres |
From: Gour <go...@ma...> - 2004-03-03 16:26:46
|
Daan Leijen (daa...@xs...) wrote: > 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 ...) As I recall, (without using addwrite /usr/lib), the problem with just patching LIBDIR was that the package.conf file was messed up and after installation libraries could not be find when I tried some samples. However, I'm still green with the Haskell and ghc architecture, so I left things for the (better) future. otoh, wxhaskell is in a speed and my whxaskell build is still v0.3 :-( > 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. Thank you for your presence. I can try next thing to write a new ebuild and do some testing. > 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 :-) I understand you. Let's come together and write a decent Gentoo wxhaskell ebuild which can be submitted for inclusion! Sincerely, Gour -- Gour go...@ma... Registered Linux User #278493 |
From: Matthew W. <ma...@al...> - 2004-03-03 15:11:09
|
Daan Leijen wrote: > 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 ...) I'm not very big on the mysteries of linking and shared libraries and other such magic. I guess we could just try it and see :-) >> 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 :-) :-) >> 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 :-) Indeed. I personally dislike the autotools intensely, but sometimes they're the best available option. Clearly I think that indicates we need a new option. Thanks. Sorry if I'm coming over a bit abrupt, I'm writing these e-mails during compiles at work. |