Re: How to use C-land variable from Cmm-land?
On 09.12.2012, at 00:12, Yuras Shumovich shumovi...@gmail.com wrote: It looks wrong for me: the highest part of %rax remains uninitialized. When 32 bits are assigned to any of the standard registers, the upper 32 bits are implicitly set to zero. Intel is weird. Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposal: EPHEMERAL pragma
On 25.10.2012, at 16:45, Johan Tibell wrote: Interesting idea. On Thu, Oct 25, 2012 at 6:56 AM, José Pedro Magalhães j...@cs.uu.nl wrote: 3. Emit a warning if the generated core code still contains uses of Rep. I think this part will be really annoying, as GHC might end up generating warnings that the programmer can do nothing about (because some optimization failed to remove Rep). I think this is exactly the right idea. A compiler should emit errors about bad typing since type inference is somewhat complete, but should emit warnings about other incomplete analyses or optimizations. If you think that this is too noisy, by all means, don't emit these warnings by default and add a flag that enables them. my 2p, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Fwd: [Gtk2hs-users] GHC 7.4+ rts_evalIO
Dear ghc developers, there seems to be a change in the C functions of ghc. How do we fix this? Is there some guide as to what has changed? Thanks, Axel Begin forwarded message: From: Andriy Polishchuk andriy.s.polishc...@gmail.com Date: 27. Januar 2012 03:36:50 MEZ To: gtk2hs-us...@lists.sourceforge.net Subject: [Gtk2hs-users] GHC 7.4+ rts_evalIO Hello, I'm newbie in haskell, so didn't got success bumping package manually. With new GHC gtk does not build with the following error: System\Glib\hsgclosure.c:110:5: warning: passing argument 1 of 'rts_evalIO' from incompatible pointer type S:\prog\lang.haskell\ghc\lib/include/RtsAPI.h:202:6: note: expected 'struct Capability **' but argument is of type 'str ct Capability *' Are there any simple workarounds or it's hard stuff and it's better for me to wait new release? The reason I want to hack with new GHC is that on windows there is fixed bug with ghci that doesn't allow to interactively link related libraries. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Gtk2hs-users mailing list gtk2hs-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Gtk2hs-users] GHC 7.4+ rts_evalIO
Oh, ok, sorry, I didn't realize this was the same issue. Please ignore this email then. Axel On 28.01.2012, at 14:40, Eugene Kirpichov wrote: Axel, See my recent email to gtk2hs-users, I already proposed a fix for this. 28.01.2012, в 17:36, Axel Simon axel.si...@in.tum.de написал(а): Dear ghc developers, there seems to be a change in the C functions of ghc. How do we fix this? Is there some guide as to what has changed? Thanks, Axel Begin forwarded message: From: Andriy Polishchuk andriy.s.polishc...@gmail.com Date: 27. Januar 2012 03:36:50 MEZ To: gtk2hs-us...@lists.sourceforge.net Subject: [Gtk2hs-users] GHC 7.4+ rts_evalIO Hello, I'm newbie in haskell, so didn't got success bumping package manually. With new GHC gtk does not build with the following error: System\Glib\hsgclosure.c:110:5: warning: passing argument 1 of 'rts_evalIO' from incompatible pointer type S:\prog\lang.haskell\ghc\lib/include/RtsAPI.h:202:6: note: expected 'struct Capability **' but argument is of type 'str ct Capability *' Are there any simple workarounds or it's hard stuff and it's better for me to wait new release? The reason I want to hack with new GHC is that on windows there is fixed bug with ghci that doesn't allow to interactively link related libraries. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Gtk2hs-users mailing list gtk2hs-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: renamed GMP symbols in GHC
Hi all, On 04.01.2012, at 17:50, Joachim Breitner wrote: BTW, Is there a way to get the linker to create two independent copies of a library in one program space? Maybe if it is compiled as PIC (random name dropping here)? That would seem to be an elegant solution, as it makes the distro packers happy and you would not have to maintain a code copy. In the past, I've linked a C++ library that used gmpxx against a Haskell program by renaming all symbols starting with gmp to mygmp using objcopy. Unfortunately, this is not portable and completely broke down on Mac OS when Apple moved to fat binaries (Intel and PowerPC) since their objcopy version was crippled (there doesn't even seem to be an objcopy anymore on later OS X versions). Thus, renaming symbols after compilation is non-portable and sometimes not possible without writing your own tool. So, I propose to revert to renaming the symbols in the source code which could probably be done automatically using a lot of CPP #defines, starting from some sort of source code tar ball of gmp. This would also allow to always use the latest gmp sources without too much hassle. My 2p, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Gtk2hs-users] cairo error: ghc.exe: unable to load package `cairo-0.12.0'
Hi Daniel, On 04.04.2011, at 16:01, Daniel wrote: Hi list, I've built gtk2hs successfully for ghc-7.0.2, but if I try to load the example Drawing.hs from the cairo packages demo folder I get: *Main :load Drawing.hs [1 of 1] Compiling Main ( Drawing.hs, interpreted ) Ok, modules loaded: Main. *Main main Loading package transformers-0.2.2.0 ... linking ... done. Loading package mtl-2.0.1.0 ... linking ... done. Loading package array-0.3.0.2 ... linking ... done. Loading package containers-0.4.0.0 ... linking ... done. Loading package process-1.0.1.5 ... linking ... done. Loading package time-1.2.0.3 ... linking ... done. Loading package random-1.0.0.3 ... linking ... done. Loading package haskell98-1.1.0.1 ... linking ... done. Loading package cairo-0.12.0 ... linking ... interactive: C:/users/daniel/appd ata/roaming/cabal\cairo-0.12.0\ghc-7.0.2\HScairo-0.12.0.o: unknown symbol `_cair o_image_surface_get_data' ghc.exe: unable to load package `cairo-0.12.0' Have tried many things so far: * Starting with re-inited package database * Doing a $ nm /h/Gtk+/bin/libcairo-2.dll | grep -i cairo_image_surface_get_data yielding 68de04d8 T _cairo_image_surface_get_data * Temporarily renaming libcairo-2.dll (the only one found on my setup, even not-in-PATH ones are non-existent) yielding as expected dll not found error * as you can see there is no literal space in the gtk+ installation path (h:\Gtk+), only in the users haskell package installation path, but that's fairly standard with Windows I guess * Compilable with ghc --make ... though, but that's sadly not sufficient as Chart package isn't installable due to this issue If ghc --make works but interactively the object cannot be found, then it might be a ghc problem rather than ours, especially since the symbol exists in the DLL. Can somebody from the ghc group shed some light on the issue? Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi+Cairo, Windows
Hi Alexey, On 01.02.2011, at 16:47, Alexey Shumitsky wrote: Hi, I have problem with ghci+cairo on windows. When I try to load, for example like this ghci -package cairo it fails with the following error: Loading package random-1.0.0.2 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package syb-0.1.0.2 ... linking ... done. Loading package base-3.0.3.2 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. : C:\Users\alexeys\AppData\Roaming\cabal \cairo-0.12.0\ghc-6.12.3\HScairo-0.12.0.o: unknown symbol `_cairo_surface_destroy' Loading package cairo-0.12.0 ... linking ... : unable to load package `cairo-0.12.0' Even simplest programs don't work in interactive mode, like for example 'Text.hs' that comes with cairo package. However compiled with 'ghc --make' everything works as expected, so its not a missing dll problem - everything is in place. I used 'filemon' on ghci and in the log I can see that 'libcairo-2.dll' was found and loaded successfully (and this library has '_cairo_surface_destroy' symbol defined). So I don't understand - what more does it want and what can be done to combat it? Sorry about the slow feedback. I know that on Windows our Gtk2HsSetup.hs magic file does some name mangling that is necessary because the binary Gtk installer has some oddly named libraries. It might be that we didn't get this mangling right for cairo or that it has changed. I had hoped that somebody with a windows machine might reply to your problems. But maybe you could give us the version of the binary installer. If its new, then they might have changed the naming... Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 21.01.2011, at 09:10, Simon Peyton-Jones wrote: | So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised Indeed I suspect the NonDecreasingIndentation change is a proposal for Haskell Prime pocess. Or if it isn't it could be is if someone proposed it. That's the process we have in place for changing the base language. I have proposed to incorporate this extension into the Haskell standard. Axel Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Axel Simon | Sent: 20 January 2011 20:23 | To: Simon Marlow | Cc: GHC users | Subject: Re: backward compatibility | | Hi Simon, | | On Jan 20, 2011, at 17:54, Simon Marlow wrote: | | The layout fix is this change: | | | http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d | 436cf6aac | | Another case where GHC was not strictly standards-compliant, and it | was fixed by adding a flag for the extension. | | | These were all bugs, but fixing them broke some code, | unfortunately. In cases like this we *could* deprecate the | behaviour for one major release with a warning, before removing it. | However there's a non-trivial cost to doing so, and in some of these | cases it would have been quite awkward to implement the warning | (plus the cost of adding tests to make sure we actually got the | warning right; it's easy to introduce yet more bugs). Furthermore, | deprecations are often ignored, so sometimes the breakage is just | delayed. | | Hopefully that explains why sometimes we make breaking changes. If | the breaking change has a high enough impact, then it becomes | worthwhile to add backwards compatibility (via warnings / | deprecation or whatever). Of course from the point of view of the | user, the impact is always either high (it broke) or zero (it | didn't) :-) We have to make a judgement as to whether we should | spend effort on backwards compatibility or not. Perhaps we're | getting it wrong - so feedback from users is always valuable. | | I appreciate that you want to make ghc compliant to the standard. But | to be honest, it is still the case that ghc defines the de-facto | standard of what a Haskell program can be, since many programs do | employ one or more ghc-only extensions. | | In the case of the layout bug, I think it might be worth considering | going the other way: adjusting the standard with what ghc has always | done. If I understand correctly, all my code using: | | foo = do |some computation |trace I am here $ do |some more computation | | will break. I use this style of coding a lot to avoid too much | indentation and thus I would have to enable this extension everywhere | (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 | implementations of Haskell 2010 in a decade, then they might not have | this extension. Furthermore, if they claim they actually do implement | the layout extension then they still might get it wrong in some subtle | way. An extension is never as well exercised as the non-extension part | of the compiler. I therefore think that keeping the number of | extensions to a minimum should be a high priority. It seems that the | ghc team is going overboard with the amount of extensions and their | granularity that I do not believe that there will ever be another | compiler since implementing all these extensions is a nightmare. The | road of may extensions is leading down the road that the Haskell | standards aimed to avoid: having a single implementation defining what | a Haskell program can be. | | So, again, for this particular extension I suggest that the layout | rule in the standard(s) should be revised -- if I'm mistaken, this | will not break other programs. | | Cheers, | Axel | | | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RelaxedLayout language extensions should be default for Haskell
Hi,
following the discussion on the ghc mailing list, I propose that the
new RelaxedLayout extension that is proposed for ghc 7.1 should be
incorporated into the language standard.
The motivation is that ghc 7.1 have silently implemented the
RelaxedLayout by default and that removing this feature will break
many programs without any gain except that ghc complies to the
standard. Hence, it would be better that the standard is adjusted, as
this would imply no changes to current ghc compilers nor user programs.
As I'm not familiar with the technical details, I can only give an
idea about what RelaxedLayout does. Haskell 2010 would parse
foo = do
some computation
trace hello $ do
other computation
such that other computation belongs to the first do, i.e.
foo = do
{ some computation
; trace hello $ do
; other computation
}
which leads to a parse error since the second do not followed by any
instructions. The relaxed layout extension opens a new block after a
do if the next line commences on in the same column as the current
block. Thus, it would parse the example above as:
foo = do
{ some computation
; trace hello $ do
{ other computation
}
}
Observations:
- the proposal has been implemented in ghc for years
- it does not break any existing programs (as far as I can see)
- incorporating this proposal into the standard involves no
implementation effort for the ghc compiler nor any program that
compiles with ghc
Cheers,
Axel
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: RelaxedLayout language extensions should be default for Haskell
On 21.01.2011, at 09:41, Axel Simon wrote:
Hi,
following the discussion on the ghc mailing list, I propose that the
new RelaxedLayout extension that is proposed for ghc 7.1 should be
incorporated into the language standard.
Sorry, this should read NondecreasingIndentation.
Axel
The motivation is that ghc 7.1 have silently implemented the
RelaxedLayout by default and that removing this feature will break
many programs without any gain except that ghc complies to the
standard. Hence, it would be better that the standard is adjusted,
as this would imply no changes to current ghc compilers nor user
programs.
As I'm not familiar with the technical details, I can only give an
idea about what RelaxedLayout does. Haskell 2010 would parse
foo = do
some computation
trace hello $ do
other computation
such that other computation belongs to the first do, i.e.
foo = do
{ some computation
; trace hello $ do
; other computation
}
which leads to a parse error since the second do not followed by
any instructions. The relaxed layout extension opens a new block
after a do if the next line commences on in the same column as the
current block. Thus, it would parse the example above as:
foo = do
{ some computation
; trace hello $ do
{ other computation
}
}
Observations:
- the proposal has been implemented in ghc for years
- it does not break any existing programs (as far as I can see)
- incorporating this proposal into the standard involves no
implementation effort for the ghc compiler nor any program that
compiles with ghc
Cheers,
Axel
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: backward compatibility
Hi Simon, On Jan 20, 2011, at 17:54, Simon Marlow wrote: The layout fix is this change: http://hackage.haskell.org/trac/ghc/changeset/9a82b1ffa35fa4c3927c66a1037a37d436cf6aac Another case where GHC was not strictly standards-compliant, and it was fixed by adding a flag for the extension. These were all bugs, but fixing them broke some code, unfortunately. In cases like this we *could* deprecate the behaviour for one major release with a warning, before removing it. However there's a non-trivial cost to doing so, and in some of these cases it would have been quite awkward to implement the warning (plus the cost of adding tests to make sure we actually got the warning right; it's easy to introduce yet more bugs). Furthermore, deprecations are often ignored, so sometimes the breakage is just delayed. Hopefully that explains why sometimes we make breaking changes. If the breaking change has a high enough impact, then it becomes worthwhile to add backwards compatibility (via warnings / deprecation or whatever). Of course from the point of view of the user, the impact is always either high (it broke) or zero (it didn't) :-) We have to make a judgement as to whether we should spend effort on backwards compatibility or not. Perhaps we're getting it wrong - so feedback from users is always valuable. I appreciate that you want to make ghc compliant to the standard. But to be honest, it is still the case that ghc defines the de-facto standard of what a Haskell program can be, since many programs do employ one or more ghc-only extensions. In the case of the layout bug, I think it might be worth considering going the other way: adjusting the standard with what ghc has always done. If I understand correctly, all my code using: foo = do some computation trace I am here $ do some more computation will break. I use this style of coding a lot to avoid too much indentation and thus I would have to enable this extension everywhere (and get warnings (or errors?) for older ghcs). Even if we had 2 or 3 implementations of Haskell 2010 in a decade, then they might not have this extension. Furthermore, if they claim they actually do implement the layout extension then they still might get it wrong in some subtle way. An extension is never as well exercised as the non-extension part of the compiler. I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be. So, again, for this particular extension I suggest that the layout rule in the standard(s) should be revised -- if I'm mistaken, this will not break other programs. Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: backward compatibility
On 21.01.2011, at 03:12, Ian Lynagh wrote: On Thu, Jan 20, 2011 at 09:22:37PM +0100, Axel Simon wrote: In the case of the layout bug, I think it might be worth considering going the other way: adjusting the standard with what ghc has always done. Anyone can propose language changes - the process is described here: http://hackage.haskell.org/trac/haskell-prime/wiki/Process I therefore think that keeping the number of extensions to a minimum should be a high priority. It seems that the ghc team is going overboard with the amount of extensions and their granularity that I do not believe that there will ever be another compiler since implementing all these extensions is a nightmare. The road of may extensions is leading down the road that the Haskell standards aimed to avoid: having a single implementation defining what a Haskell program can be. I'm not sure if you're saying there should be fewer new language features implemented, less fine-grained control over which are enabled, or something else? I agree that new language features is required to make Haskell a research platform. So it would be awkward to try to stop people from adding new language features. I don't mind if highly experimental language features come in many varieties (i.e. with fine-grained control about what is allowed). I'm more concerned about standard extensions that many (even most) people use somewhere in their projects. I get the feeling that these get split up into too many individual language features which will make it difficult for other compilers to implement the extension and the switched-off extension correctly. Haskell 2010 is going into the right direction in making some of these features mandatory which means that they become language features that you can't switch them off anymore. This makes it more likely that future compilers can implement a comprehensive Haskell language. So yes, less fine-grained control for features people use often. The layout rule seems to be one extension that can go into the report (both 98 and 2010) without breaking any program. If this is really so, then I think it is easiest for compiler writer and users if such a change is made to the report. I think only very few language features qualify for going directly into the reports since most of them can break programs. Hope this clarifies my opinion, Cheers, Axel Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] More work to be done re: haskell.org move?
Hi Brent, On 14.12.2010, at 16:02, Brent Yorgey wrote: On Mon, Dec 13, 2010 at 10:35:22AM -0800, Don Stewart wrote: Hi Paul, The move is complete. There are no haskell.org services running there now. You could shut down the machine in December if you wish. Everyone keeps saying the move is complete but I'm not sure it's really true. I understand in theory that people were given ample time and warning to migrate content, but in practice it has not worked. Off the top of my head I know of at least haskell.org/arrows haskell.org/gtk2hs, two key pieces of infrastructure/knowledge that have not made the move and that people have asked about in the last few days. Are there any plans to copy over things like this? Relying on maintiners to do it has obviously not worked. I stand ready to help but am not quite sure what needs to happen from a technical point of view. Wrt Gtk2Hs, I've copied the files but I think I need to dump the data base that backed up the WordPress CMS. I have no clue about these things which led me to ignore the migration in the hope that everything would be fine. I think I need somebody with (My)SQL knowledge to install a server on community.haskell.org and to copy over the database contents from the oldhaskell.org server. After that, I can have a stab at getting WordPress running again against the reinstated database content. So if anybody (with root access?) can do the mirgration of the content, then that would be swell. Cheers, Axel -Brent -- Don paul.hudak: Dear All: My research group is paying $200/month to maintain the old haskell.org at Yale, and we cannot continue doing this indefinitely -- indeed, I had hoped that we could have turned off the machine by now. I propose that we shut down the old server on Jan 31, 2011. Hopefully this will give everyone adequate time to move their files. Best, -Paul Hudak -Original Message- From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org ] On Behalf Of Frank Rosemeier Sent: Sunday, December 12, 2010 10:30 AM To: Thomas Schilling Cc: Ian Lynagh; Haskell Subject: Re: [Haskell] Please help me to reconstruct the Yarrow website! Re: New haskell.org server Hello Thomas, thank you very much for this link! I am glad that the Yarrow website is accessible. I will try to move it to the community server as soon as possible. How long will the pages being hosted at Yale? Is it possible to redirect the old Yarrow address to this one? Kind regards Frank Rosemeier Am 10.12.2010 um 18:25 schrieb Thomas Schilling: It's still available at http://haskell.cs.yale.edu/yarrow/ I believe the correct new location will be on community server. See http://community.haskell.org/ for instructions on how to get an account there. On 10 December 2010 12:23, Frank Rosemeier fr...@rosemeier.info wrote: Dear Haskellers, today I have noticed that the link http://www.haskell.org/yarrow is broken! Who is responsible or can help me to reconstruct the Yarrow home page? To my mind this it is not a fair treatment of the Yarrow wersite: I asked in September for prolongation of this website, than I have been informed thirty days ago that it has to be moved, so that I asked for support with the migration process about a week ago and today the homepage is not accessible. I would like to have more time and more support! Is it possible to setup the old home page for some weeks (or better months) again? Kind regards Frank Rosemeier Anfang der weitergeleiteten E-Mail: Von: Frank Rosemeier fr...@rosemeier.info Datum: 2. Dezember 2010 10:08:08 GMT+01:00 An: Ian Lynagh ig...@earth.li Kopie: Frank ((FH Hamm)) Rosemeier frank.roseme...@fh- hamm.srh.de Betreff: Re: Yarrow website! Re: [Haskell] New haskell.org server Hello Ian, I am sorry that the Yarrow homepage has to be moved. How long will the old website be accessible? I would prefer to have the redirection for some years (not only for some months) because presumably it will take some months to create the new home for Yarrow. Are there any tools or tutors to help me with this migration? Kind regards Frank Am 20.11.2010 um 16:29 schrieb Ian Lynagh: Hi Frank, Sorry for the slow reply; it's taken longer than I expected to get everything worked out. On Thu, Sep 09, 2010 at 07:21:48PM +0200, Frank Rosemeier wrote: the Yarrow website has been hosted by haskell.org for some years now (http://www.haskell.org/yarrow/ ). Thank you very much for this service! I would be very happy, if you could transfer these pages to the new server. The haskell.org committee have decided that the community server would be a better fit for the yarrow site. We will be happy to add a redirect from http://www.haskell.org/yarrow/ to the community site for a few months, so links don't instantly break. To get an account on the community server, you need to fill in: http://community.haskell.org/admin/account_request.html and then to get a
Re: [Haskell] Please help me to reconstruct the Yarrow website! Re: New haskell.org server
Hi Paul, On Dec 13, 2010, at 17:01, Hudak, Paul wrote: Dear All: My research group is paying $200/month to maintain the old haskell.org at Yale, and we cannot continue doing this indefinitely -- indeed, I had hoped that we could have turned off the machine by now. I propose that we shut down the old server on Jan 31, 2011. Hopefully this will give everyone adequate time to move their files. Admittedly, I should have backed up my website a long time ago. I've just tried to do that and found that the disk of your sever is completely full. I now wonder if the backup is actually complete. I'll just backup what's there. So I guess this is a warning to other people. Cheers, Axel -Original Message- From: haskell-boun...@haskell.org [mailto:haskell- boun...@haskell.org] On Behalf Of Frank Rosemeier Sent: Sunday, December 12, 2010 10:30 AM To: Thomas Schilling Cc: Ian Lynagh; Haskell Subject: Re: [Haskell] Please help me to reconstruct the Yarrow website! Re: New haskell.org server Hello Thomas, thank you very much for this link! I am glad that the Yarrow website is accessible. I will try to move it to the community server as soon as possible. How long will the pages being hosted at Yale? Is it possible to redirect the old Yarrow address to this one? Kind regards Frank Rosemeier Am 10.12.2010 um 18:25 schrieb Thomas Schilling: It's still available at http://haskell.cs.yale.edu/yarrow/ I believe the correct new location will be on community server. See http://community.haskell.org/ for instructions on how to get an account there. On 10 December 2010 12:23, Frank Rosemeier fr...@rosemeier.info wrote: Dear Haskellers, today I have noticed that the link http://www.haskell.org/yarrow is broken! Who is responsible or can help me to reconstruct the Yarrow home page? To my mind this it is not a fair treatment of the Yarrow wersite: I asked in September for prolongation of this website, than I have been informed thirty days ago that it has to be moved, so that I asked for support with the migration process about a week ago and today the homepage is not accessible. I would like to have more time and more support! Is it possible to setup the old home page for some weeks (or better months) again? Kind regards Frank Rosemeier Anfang der weitergeleiteten E-Mail: Von: Frank Rosemeier fr...@rosemeier.info Datum: 2. Dezember 2010 10:08:08 GMT+01:00 An: Ian Lynagh ig...@earth.li Kopie: Frank ((FH Hamm)) Rosemeier frank.roseme...@fh- hamm.srh.de Betreff: Re: Yarrow website! Re: [Haskell] New haskell.org server Hello Ian, I am sorry that the Yarrow homepage has to be moved. How long will the old website be accessible? I would prefer to have the redirection for some years (not only for some months) because presumably it will take some months to create the new home for Yarrow. Are there any tools or tutors to help me with this migration? Kind regards Frank Am 20.11.2010 um 16:29 schrieb Ian Lynagh: Hi Frank, Sorry for the slow reply; it's taken longer than I expected to get everything worked out. On Thu, Sep 09, 2010 at 07:21:48PM +0200, Frank Rosemeier wrote: the Yarrow website has been hosted by haskell.org for some years now (http://www.haskell.org/yarrow/ ). Thank you very much for this service! I would be very happy, if you could transfer these pages to the new server. The haskell.org committee have decided that the community server would be a better fit for the yarrow site. We will be happy to add a redirect from http://www.haskell.org/yarrow/ to the community site for a few months, so links don't instantly break. To get an account on the community server, you need to fill in: http://community.haskell.org/admin/account_request.html and then to get a project for yarrow: http://community.haskell.org/admin/project_request.html Information on how to use a community project is here: http://community.haskell.org/admin/using_project.html Please let me know if you have any problems. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Push the envelope. Watch it bend. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Gtk2Hs 0.12.0 released
Dear all, the Gtk2Hs team is happy to announce a new release of the core packages glib, gio, pango, cairo, and gtk all in version 0.12.0. Andy Steward has put in a lot of effort to add many new functions to gtk, thereby getting close to covering the full Gtk+ API. John Obbele has kindly investigated into fixing some memory leaks. These new packages should build with Cabal 0.10.0, that is, with the upcoming ghc 7 release. Please note that you need to manually install gtk2hs-buildtools before attempting to install any of the packages above! If in doubt, please read the INSTALL instructions found on our web-site: http://haskell.org/gtk2hs/download/ Comments and feedback welcome. Axel (on behalf of the Gtk2Hs team) About Gtk2Hs Gtk2Hs is a set of Haskell bindings to many of the libraries included in the Gtk+/Gnome platform. Gtk+ is an extensive and mature multi- platform toolkit for creating graphical user interfaces. GUIs written using Gtk2Hs use themes to resemble the native look on Windows. Gtk is the toolkit used by Gnome, one of the two major GUI toolkits on Linux. On Mac OS programs written using Gtk2Hs are run by Apple’s X11 server but may also be linked against a native Aqua implementation of Gtk. Gtk2Hs features: • Automatic memory management (unlike some other C/C++ GUI libraries, Gtk+ provides proper support for garbage-collected languages) • Unicode support • High quality vector graphics using Cairo • Extensive reference documentation • An implementation of the “Haskell School of Expression” graphics API • Bindings to many other libraries that build on Gtk: gio, GConf, GtkSourceView 2.0, glade, gstreamer, vte, webkit (released separately) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Gtk2Hs 0.11.1 released
Dear all, after a few months of shaking out bugs, we've released a new patch- level version of Gtk2Hs, the binding to the Gtk+ GUI library suite. Notable changes: - several bug fixes with respect to concurrency on a variety of platforms - linking problems in ghci have been resolved - pango now includes functions to draw text on Cairo surfaces; this makes it possible to render Unicode text into PDF/PS/SVG/PNG documents without the need for the GUI part in the gtk package - we included the demos in the tar balls (we forgot that last time...) - other bug fixes Please see our web-site http://www.haskell.org/gtk2hs/ for further information and read http://code.haskell.org/gtk2hs/INSTALL if you plan to give it a go! Cheers, Axel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: behaviour of ghci on .c modules that are part of a library
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the addresses of these global variables
are all wrong when ghci is executing the code. So, I think I hit:
http://hackage.haskell.org/trac/ghc/ticket/781
I was able to work around this problem by compiling the C modules with
-fPIC. This bug is pretty bad, I'd say. I've added myself to its CC
list.
Cheers,
Axel
On 14.07.2010, at 16:51, Axel Simon wrote:
Hi all,
I'm trying to debug a segfault relating to the memory management in
Gtk2Hs. Rather than make you read the ticket http://hackage.haskell.org/trac/gtk2hs/ticket/1183
, I'll describe the problem:
- compiler 6.12.1 or 6.12.3
- darcs head of Gtk2Hs with #define DEBUG instead of #undef DEBUG in
gtk/Graphics/UI/Gtk/General/hsthread.c
- platform Ubuntu Linux, x86-64
- to reproduce: cd gtk2hs/gtk/demo/hello and run ghci World.hs and
type 'main'
A window with the Hello World button appears. After a few seconds,
the GC runs and the finaliser of the GtkButton is run since the
Haskell program no longer holds a reference to that object (only the
GtkWindow in C land has).
Thus, the GC calls a C function gtk2hs_g_object_unref_from_mainloop
which is supposed to enqueue the object into a global data structure
from which objects are later taken and g_object_unref is called on
them.
This global data structure is protected by a mutex, which is
acquired using g_static_mutex_lock:
void gtk2hs_g_object_unref_from_mainloop(gpointer object) {
int mutex_locked = 0;
if (threads_initialised) {
#ifdef DEBUG
printf(acquiring lock to add a %s object at %lx\n,
g_type_name(G_OBJECT_TYPE(object)), (unsigned long)
object);
printf(value of lock function is %lx\n,
(unsigned long)
g_thread_functions_for_glib_use.mutex_lock);
#endif
g_rand_new();
#if defined( WIN32 )
EnterCriticalSection(gtk2hs_finalizer_mutex);
#else
g_static_mutex_lock(gtk2hs_finalizer_mutex);
#endif
mutex_locked = 1;
}
[..]
The program prints:
acquiring lock to add a GtkButton object at 22d8020
value of lock function is 0
zsh: segmentation fault ghci World
Now the debugging weirdness starts. Whatever I do, I cannot get gdb
to find the symbol gtk2hs_g_object_unref_from_mainloop.
Since the function above is contained in a C file that comes with
our Haskell library, I tried to add cc-options: -g and cc-
options: -ggdb -O0, but maybe somewhere symbols are stripped. So I
added the bogus function call to g_rand_new() which is not called
anywhere else and gdb stops as follows:
acquiring lock to add a GtkButton object at 2105020
value of lock function is 0
[Switching to Thread 0x741ff710 (LWP 15735)]
Breakpoint 12, 0x7115bfa0 in g_rand_new () from /usr/lib/
libglib-2.0.so
This all seems reasonable, but:
(gdb) bt
#0 0x7115bfa0 in g_rand_new () from /usr/lib/libglib-2.0.so
#1 0x419b3792 in ?? ()
#2 0x7678f078 in ?? ()
i.e. the calling context is broken. I'm very, very sure that the
caller is indeed the above mentioned function and since g_rand_new
isn't called anywhere in my Haskell program (and otherwise the
calling context would be sane).
I'm also passing the address of gtk2hs_g_object_unref_from_mainloop
as FinalizerPtr to all my ForeignPtrs, so there is no inlining going
on.
Back to the culprit, the call to g_static_mutex_lock. This is a
macro that expands to
*g_thread_functions_for_glib_use.mutex_lock
where g_thread_functions_for_glib is a global variable that contains
a lot of function pointers. At the break point, it contains this:
(gdb) print g_thread_functions_for_glib_use
$33 = {mutex_new = 0x70cd9820 g_mutex_new_posix_impl,
mutex_lock = 0x76c8b3c0 __pthread_mutex_lock,
mutex_trylock = 0x70cd97b0 g_mutex_trylock_posix_impl,
mutex_unlock = 0x76c8ca00 __pthread_mutex_unlock,
mutex_free = 0x70cd9740 g_mutex_free_posix_impl,
[..]
So the call to g_mutex_lock should call the function
__pthread_mutex_lock but it calls NULL.
I hoped that writing this email would give me a bit more insight
into the problem, but for now I suspect that something overwrites
either the stack or the code of the function.
On the same platform, the compiled version prints:
acquiring lock to add a GtkButton object at 1b05820
value of lock function is 7f7adcabd3c0
within mutex: adding finalizer to a GtkButton object!
On Mac OS or i386, using ghci or ghc, version 6.10.4, it works as
well.
Now for the fun bit: on i386 using ghci version 6.12.1 it works too.
So it's an x86-64 and ghc 6.12.1 bug. According to Christian Maeder
who submitted the ticket, the problem persists in 6.12.3.
Any hints and help appreciated,
Cheers,
Axel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users
Re: [Gtk2hs-devel] behaviour of ghci on .c modules that are part of a library
Hi Simon,
On 16.07.2010, at 14:29, Simon Marlow wrote:
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the addresses of these global variables
are all wrong when ghci is executing the code. So, I think I hit:
http://hackage.haskell.org/trac/ghc/ticket/781
I was able to work around this problem by compiling the C modules
with
-fPIC. This bug is pretty bad, I'd say. I've added myself to its CC
list.
Urgh. It's a nasty bug, but not one that we can fix, because it's
an artifact of the small memory model used on x86_64. The only fix
is to use -fPIC.
It might be possible to use -fPIC either by default, or perhaps just
for .c files and when compiling data references from FFI
declarations in Haskell code, that's something we could look into.
We might want -fPIC on by default anyway if we switch to using
dynamic linking by default (but we're not yet sure what
ramifications that will have).
Well, my fix is:
if arch(x86_64)
cc-options: -fPIC
This only affects the C files we compile of which there are only two
at the moment. I am happy with this solution since I know which files
are affected.
But basically this bug will hit me whenever I use a global C variable
from within Haskell? I hope there are none that we use, they should
all be accessed using functions, so we should be safe.
Cheers,
Axel
Cheers,
Simon
Cheers,
Axel
On 14.07.2010, at 16:51, Axel Simon wrote:
Hi all,
I'm trying to debug a segfault relating to the memory management in
Gtk2Hs. Rather than make you read the ticket
http://hackage.haskell.org/trac/gtk2hs/ticket/1183
, I'll describe the problem:
- compiler 6.12.1 or 6.12.3
- darcs head of Gtk2Hs with #define DEBUG instead of #undef DEBUG in
gtk/Graphics/UI/Gtk/General/hsthread.c
- platform Ubuntu Linux, x86-64
- to reproduce: cd gtk2hs/gtk/demo/hello and run ghci World.hs and
type 'main'
A window with the Hello World button appears. After a few seconds,
the GC runs and the finaliser of the GtkButton is run since the
Haskell program no longer holds a reference to that object (only the
GtkWindow in C land has).
Thus, the GC calls a C function gtk2hs_g_object_unref_from_mainloop
which is supposed to enqueue the object into a global data structure
from which objects are later taken and g_object_unref is called on
them.
This global data structure is protected by a mutex, which is
acquired using g_static_mutex_lock:
void gtk2hs_g_object_unref_from_mainloop(gpointer object) {
int mutex_locked = 0;
if (threads_initialised) {
#ifdef DEBUG
printf(acquiring lock to add a %s object at %lx\n,
g_type_name(G_OBJECT_TYPE(object)), (unsigned long)
object);
printf(value of lock function is %lx\n,
(unsigned long)
g_thread_functions_for_glib_use.mutex_lock);
#endif
g_rand_new();
#if defined( WIN32 )
EnterCriticalSection(gtk2hs_finalizer_mutex);
#else
g_static_mutex_lock(gtk2hs_finalizer_mutex);
#endif
mutex_locked = 1;
}
[..]
The program prints:
acquiring lock to add a GtkButton object at 22d8020
value of lock function is 0
zsh: segmentation fault ghci World
Now the debugging weirdness starts. Whatever I do, I cannot get gdb
to find the symbol gtk2hs_g_object_unref_from_mainloop.
Since the function above is contained in a C file that comes with
our Haskell library, I tried to add cc-options: -g and cc-
options: -ggdb -O0, but maybe somewhere symbols are stripped. So I
added the bogus function call to g_rand_new() which is not called
anywhere else and gdb stops as follows:
acquiring lock to add a GtkButton object at 2105020
value of lock function is 0
[Switching to Thread 0x741ff710 (LWP 15735)]
Breakpoint 12, 0x7115bfa0 in g_rand_new () from /usr/lib/
libglib-2.0.so
This all seems reasonable, but:
(gdb) bt
#0 0x7115bfa0 in g_rand_new () from /usr/lib/libglib-2.0.so
#1 0x419b3792 in ?? ()
#2 0x7678f078 in ?? ()
i.e. the calling context is broken. I'm very, very sure that the
caller is indeed the above mentioned function and since g_rand_new
isn't called anywhere in my Haskell program (and otherwise the
calling context would be sane).
I'm also passing the address of gtk2hs_g_object_unref_from_mainloop
as FinalizerPtr to all my ForeignPtrs, so there is no inlining going
on.
Back to the culprit, the call to g_static_mutex_lock. This is a
macro that expands to
*g_thread_functions_for_glib_use.mutex_lock
where g_thread_functions_for_glib is a global variable that contains
a lot of function pointers. At the break point, it contains this:
(gdb) print g_thread_functions_for_glib_use
$33 = {mutex_new = 0x70cd9820g_mutex_new_posix_impl,
mutex_lock = 0x76c8b3c0__pthread_mutex_lock,
mutex_trylock = 0x70cd97b0g_mutex_trylock_posix_impl
behaviour of ghci on .c modules that are part of a library
Hi all,
I'm trying to debug a segfault relating to the memory management in
Gtk2Hs. Rather than make you read the ticket http://hackage.haskell.org/trac/gtk2hs/ticket/1183
, I'll describe the problem:
- compiler 6.12.1 or 6.12.3
- darcs head of Gtk2Hs with #define DEBUG instead of #undef DEBUG in
gtk/Graphics/UI/Gtk/General/hsthread.c
- platform Ubuntu Linux, x86-64
- to reproduce: cd gtk2hs/gtk/demo/hello and run ghci World.hs and
type 'main'
A window with the Hello World button appears. After a few seconds,
the GC runs and the finaliser of the GtkButton is run since the
Haskell program no longer holds a reference to that object (only the
GtkWindow in C land has).
Thus, the GC calls a C function gtk2hs_g_object_unref_from_mainloop
which is supposed to enqueue the object into a global data structure
from which objects are later taken and g_object_unref is called on them.
This global data structure is protected by a mutex, which is acquired
using g_static_mutex_lock:
void gtk2hs_g_object_unref_from_mainloop(gpointer object) {
int mutex_locked = 0;
if (threads_initialised) {
#ifdef DEBUG
printf(acquiring lock to add a %s object at %lx\n,
g_type_name(G_OBJECT_TYPE(object)), (unsigned long)
object);
printf(value of lock function is %lx\n,
(unsigned long)
g_thread_functions_for_glib_use.mutex_lock);
#endif
g_rand_new();
#if defined( WIN32 )
EnterCriticalSection(gtk2hs_finalizer_mutex);
#else
g_static_mutex_lock(gtk2hs_finalizer_mutex);
#endif
mutex_locked = 1;
}
[..]
The program prints:
acquiring lock to add a GtkButton object at 22d8020
value of lock function is 0
zsh: segmentation fault ghci World
Now the debugging weirdness starts. Whatever I do, I cannot get gdb to
find the symbol gtk2hs_g_object_unref_from_mainloop.
Since the function above is contained in a C file that comes with our
Haskell library, I tried to add cc-options: -g and cc-options: -
ggdb -O0, but maybe somewhere symbols are stripped. So I added the
bogus function call to g_rand_new() which is not called anywhere
else and gdb stops as follows:
acquiring lock to add a GtkButton object at 2105020
value of lock function is 0
[Switching to Thread 0x741ff710 (LWP 15735)]
Breakpoint 12, 0x7115bfa0 in g_rand_new () from /usr/lib/
libglib-2.0.so
This all seems reasonable, but:
(gdb) bt
#0 0x7115bfa0 in g_rand_new () from /usr/lib/libglib-2.0.so
#1 0x419b3792 in ?? ()
#2 0x7678f078 in ?? ()
i.e. the calling context is broken. I'm very, very sure that the
caller is indeed the above mentioned function and since g_rand_new
isn't called anywhere in my Haskell program (and otherwise the calling
context would be sane).
I'm also passing the address of gtk2hs_g_object_unref_from_mainloop as
FinalizerPtr to all my ForeignPtrs, so there is no inlining going on.
Back to the culprit, the call to g_static_mutex_lock. This is a macro
that expands to
*g_thread_functions_for_glib_use.mutex_lock
where g_thread_functions_for_glib is a global variable that contains a
lot of function pointers. At the break point, it contains this:
(gdb) print g_thread_functions_for_glib_use
$33 = {mutex_new = 0x70cd9820 g_mutex_new_posix_impl,
mutex_lock = 0x76c8b3c0 __pthread_mutex_lock,
mutex_trylock = 0x70cd97b0 g_mutex_trylock_posix_impl,
mutex_unlock = 0x76c8ca00 __pthread_mutex_unlock,
mutex_free = 0x70cd9740 g_mutex_free_posix_impl,
[..]
So the call to g_mutex_lock should call the function
__pthread_mutex_lock but it calls NULL.
I hoped that writing this email would give me a bit more insight into
the problem, but for now I suspect that something overwrites either
the stack or the code of the function.
On the same platform, the compiled version prints:
acquiring lock to add a GtkButton object at 1b05820
value of lock function is 7f7adcabd3c0
within mutex: adding finalizer to a GtkButton object!
On Mac OS or i386, using ghci or ghc, version 6.10.4, it works as well.
Now for the fun bit: on i386 using ghci version 6.12.1 it works too.
So it's an x86-64 and ghc 6.12.1 bug. According to Christian Maeder
who submitted the ticket, the problem persists in 6.12.3.
Any hints and help appreciated,
Cheers,
Axel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mallocForeignPtr vs. C
Hi Evan, Ed, On Jul 12, 2010, at 22:53, Edward Z. Yang wrote: Excerpts from Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010: Yeah, that's definitely the safest and simplest. But the copying defeats the purpose of passing a pointer in the first place, which was to not have to copy the giant array just to pass it. Well, if your C code wasn't squirreling away the pointer, you could have avoided the copy. Memory copies in C are suprisingly cheap; I'm really surprised how often I see memcpy() in high performance code (though, it may be the case that the details of the algorithm are a much more important influence on performance.) If your C code has a way to properly unref a pointer then you could wrap your ForeignPtr in a StablePtr and pass that to C land. Once C has freed the StablePtr the ForeignPtr can become dead when Haskell has dropped all references and it will be garbage collected. The downside is that your C code needs to hold the StablePtr and do the accesses through the Ptr in the ForeignPtr, so it needs to be able to store two pointers at once. Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mallocForeignPtr vs. C
On Jul 13, 2010, at 22:17, Edward Z. Yang wrote: Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010: If your C code has a way to properly unref a pointer then you could wrap your ForeignPtr in a StablePtr and pass that to C land. Once C has freed the StablePtr the ForeignPtr can become dead when Haskell has dropped all references and it will be garbage collected. Does ForeignPtr have a guaranteed representation from C land? I feel like you want to create a stable pointer and then unsafely cast the foreign pointer into a real pointer, which would effectively fizzle the original foreign pointer's finalizer. Well, if the C code hangs on to the StablePtr that wraps the ForeignPtr, its finalizer won't be run. But can run again once the StablePtr is freed. So you can take out the Ptr in the ForeignPtr and use it in C land as long as C holds on to the StablePtr. Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hsc2hs on Mac OS 10.6 unreliable?
Hi Christian, On 09.06.2010, at 10:30, Christian Maeder wrote: Chris Kuklewicz schrieb: hsc2hs: On OS 10.6 ghc is calling hsc2hs without any special -arch option, and hsc2hs is calculating offsets in x86_64 mode. This is breaking the interface between ghc and c-structures for various libraries. In particular I ran into this with gtk2hs. It may suffice to get '--cc-flag=-m32 --ld-flag=-m32' to hsc2hs as a work around. While ticket #2965 is not yet fixed it would be better if hsc2hs understood the default arch on OS X 10.6 is not compatible with ghc. Sorry, I'm only on a 32bit Mac, but my (installed) hsc2hs (for ghc-6.12.2.20100521) file contains: HSC2HS_EXTRA=--cflag=-m32 --lflag=-m32 -I... Is this not sufficient for 64bit Macs, too? I guess it would be enough, but obiously ghc or cabal should do this correctly themselves. What I would like to get out of this email thread is a set of rules that allows me to hack around this issue. So far: if os(darwin) arch(x86_64) impl(ghc =6.10 =6.12) cpp-options: -DHSC2HS_EXTRA=--cflag=-m32 --lflag=-m32 (although I'm not even sure the above works). Is the above rule correct and future-proof? Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
hsc2hs on Mac OS 10.6 unreliable?
Hi all, we're facing serious problems (the seg'faulting kind) with Gtk2Hs on Mac OS 10.6. Chris has tracked this down to incorrect structure offsets that hsc2hs calculates. The offsets that hsc2hs calculates are too large, so it is probably in x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so it must have been compiled with something like -arch i386. My question is the following: What is the right way to compile unixy software on Mac OS 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not producing its C file in the correct way? It seems that a C Gtk+ program works correctly when compiled with no special flags. The only thing we could do is to pass some magic option to hsc2hs when it creates the C program that calculates the offsets. Detecting how Gtk + was compiled would require some sort of autoconf magic which is beyond a simple cabal file. So I probably cannot hope for an easy fix. Any comments or experience appreciated, cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [Haskell] Gtk2Hs version 0.11.0 released
Ups, some chronological hick-up here. But I think your question is answered now :-) Note: On 27.05.2010, at 20:13, Axel Simon wrote: for example, i can't use previous gtk2hs version with ghc 6.10.4 on windows because there is no prebuilt library and i'm not brave enough to compile it myself. is it true that gtk2hs 0.11 should automatically compile with any ghc 6.10/6.12 on windows and we no more need prebuilt installers? Yes, but you do need to install the bundle of Gtk+ libraries. I think compiling Gtk2Hs on Windows is not doable for the average developer which is a big step forwards as to where we were before. It's supposed to be is now doable. Axel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
On 27.05.2010, at 16:28, Christian Maeder wrote: Axel Simon schrieb: Hi Ian, I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell). 1. I could not install gtk2hs-0.11.0 under x86 Solaris. Linking /tmp/glib-0.11.025732/glib-0.11.0/dist/setup/setup ... Configuring glib-0.11.0... Preprocessing library glib-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks: ./System/Glib/GObject.chs:107: (column 22) [ERROR] Unknown identifier! Cannot find a definition for `g_object_get_type' in the header file. Yup, we didn't test on Solaris. However, this is a Gtk+ version problem. The above mentioned function does not exist in Gtk+ 2.14 because it would be equivalent to G_TYPE_OBJECT. I've fixed this in the darcs repository. cabal: Error: some packages failed to install: 2. under a x86 Mac with a GTK-2.14 framework I got: Linking /tmp/gtk-0.11.025922/gtk-0.11.0/dist/setup/setup ... Configuring gtk-0.11.0... setup: ./Graphics/UI/Gtk/General/IconTheme.chs: invalid argument cabal: Error: some packages failed to install: gtk-0.11.0 failed during the building phase. The exception was: This bug occurs if you're running in anything else but UTF-8 locale. As Andy said, this is fixed in darcs. The packages cairo-0.11.0 gio-0.11.0 glib-0.11.0 pango-0.11.0 built fine. The GTK-2.14 framework is: http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/intel-mac/gtk2-framework.dmg and originally came from http://r.research.att.com/ For the next point, it would really help us, if you could check out the darcs repo and build again. That would then also entail ironing out the problems with Gtk+ 2.14. 3. Under linux we still have a problem with the new gtk2hs-0.11.0 version. http://trac.informatik.uni-bremen.de:8080/hets/ticket/794 This would be very interesting to resolve. I assume: - you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0. Cheers, Axel Cheers, Axel On May 23, 2010, at 20:42, Ian Lynagh wrote: Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ building and installing ghc-6.12.2.20100521, compiling and running our large hets binary (without gtk2hs) worked. Thanks Christian As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: [Gtk2hs-users] ANNOUNCE: GHC 6.12.3 Release Candidate 1
On 27.05.2010, at 19:50, Bulat Ziganshin wrote: Hello Axel, Thursday, May 27, 2010, 8:42:08 PM, you wrote: - you use -threaded to compile your program - you only use postGUISync and postGUIAsync from threads different to the Gtk2Hs thread Is this true? If yes, I'll give you an elaboration on how threads are supposed to work in Gtk+ (I think I finally understood this!) and what I've changed in 0.11.0. i'm among (probably many) developers who interested to hear it. i believe that gtk2hs uses thread where it was initialized as main (this thread should be bound so it's either main thread or one created with runInBoundThread/forkOS) and the everything should either run in this thread directly, or in signal hadlers (that are executed in this thread) or via postGUISync/postGUIAsync. moreover postGUISync can't be used inside main GUI thread due to locking as you may remember, once i proposed to add wrapper that is equal to id in main GUI thread but equal to postGUISync in other threads. or even better, wrap all gtk2hs operations in this wrapper Yes, I should perhaps dig that up and implement it. I actually suspect that Christian ran either into this problem or that he doesn't compile with -threaded. Hopefully it's one of those two options and not another concurrency bug in Gtk2Hs. So the story with the threads is as follows: You can use just a single thread. This is done when you compile without -threaded. You need to do the 'addIdle 50 yield' trick. You can use the -threaded option to ghc or you use ghci. Now there exists one lock for the whole of Gtk+. This lock must be acquired before gtk_init is called. (This is what I fixed before the release: without it, it worked on Unix but not on Windows.) The lock remains acquired by the OS thread that calls Gtk+. In particular, it remains acquire as long as signals are pending and dispatched. The only time this look is released is when Gtk+ enters its main loop. It may then block on input or run an idle handler. During this time, it is possible for a different OS thread (or any odd Haskell thread that may or may not run in a different OS thread) to acquire the lock, modify some widget state and release the lock. However, most widget methods call also to the OS and accessing the Win32 API from more than one OS thread is not possible due to Win32 using some thread-local state. Thus, using this method for concurrent updates is not recommended. Enter postGUIAsync. This method will add an idle handler to the Gtk+ main loop (this is done by glib in a thread safe way) which executes an action from the idle handler. This idle handler will be called from the main loop and thus be in the Gtk+ OS thread. The action can therefore safely access all widget methods. Since the action is performed in the Gtk+ OS thread, no expensive computation should be done, merely the widgets should be updated. I hope this helps to clarify the thread situation in Gtk+. Cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Gtk2Hs version 0.11.0 released
Hi Bulat, On 27.05.2010, at 19:14, Bulat Ziganshin wrote: Hello Axel, Tuesday, May 25, 2010, 4:02:21 PM, you wrote: the Gtk2Hs team is very happy to announce the release of version 0.11.0, the first release that comes in Cabal packages! can be built with GHC 6.10 and 6.12 and Cabal 1.6 and 1.8. However, does it mean that i can just issue cabal install gtk with any 6.10.* or 6.12.* version and it will be compiled automatically? overall, can you please give us details what Cabal support gives to us developers who uses gtk2hs? In order to install Gtk2Hs, one has to indeed say cabal install gtk2hs-buildtools cabal install gtk (assuming that ~/.cabal/bin is on your PATH). I has been suggested to us that gtk2hs-buildtools should install a fake library, so that gtk can depend on it and have the build tools installed as a side-effect. About the benefits to the developers, I guess there are the obvious: - an application x that depends on gtk can be compiled by saying 'cabal install x' (but see above) - no more fiddling with ./configure in MinGW on Windows - faster compilation time Maybe I'm missing the point of your question, though. Cheers, Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[2]: [Haskell] Gtk2Hs version 0.11.0 released
Hi Bulat, On 27.05.2010, at 20:04, Bulat Ziganshin wrote: Hello Axel, Thursday, May 27, 2010, 9:50:57 PM, you wrote: does it mean that i can just issue cabal install gtk with any 6.10.* or 6.12.* version and it will be compiled automatically? overall, can Maybe I'm missing the point of your question, though. for example, i can't use previous gtk2hs version with ghc 6.10.4 on windows because there is no prebuilt library and i'm not brave enough to compile it myself. is it true that gtk2hs 0.11 should automatically compile with any ghc 6.10/6.12 on windows and we no more need prebuilt installers? Yes, but you do need to install the bundle of Gtk+ libraries. I think compiling Gtk2Hs on Windows is not doable for the average developer which is a big step forwards as to where we were before. See: http://code.haskell.org/gtk2hs/INSTALL Cheers, Axel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[4]: [Haskell] Gtk2Hs version 0.11.0 released
Hi Bulat, On 27.05.2010, at 20:21, Bulat Ziganshin wrote: Hello Axel, Thursday, May 27, 2010, 10:13:45 PM, you wrote: http://code.haskell.org/gtk2hs/INSTALL thank you. and what if i deploy my gtk2hs application via hackage? is it enough for user to run cabal install myapp to install my app and all runtime gtk/gtk2hs libraries she need to run it? Once we manage to install the gtk2hs-buildtools package automatically, yes. See my previous message. Cheers, Axel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Gtk2Hs version 0.11.0 released
Dear all, the Gtk2Hs team is very happy to announce the release of version 0.11.0, the first release that comes in Cabal packages! Gtk2Hs is a collection of wrappers around the Gtk+ graphical user interface suite. However, it is more than just user interfaces! Using a subset of packages, you can also render high quality graphics and text to PDF, PS, PNG and SVG documents. Gtk2Hs consists of code that is partly generated but always adjusted by hand afterwards, especially the documentation. One of our aims it to make the Haskell interface self-contained and Haskell-lish. For example, memory management is fully automatic (of course!) and the store of widgets displaying tables or lists is a Haskell data structure. We have invested a great deal to make Gtk2Hs work in multi- threaded programs which was challenging given the concurrent garbage collector of GHC. Due to this effort, Gtk2Hs works from within GHCi and, of course, it works on Windows. This release has been tested on Linux, Mac OS X and Windows (XP/7). It can be built with GHC 6.10 and 6.12 and Cabal 1.6 and 1.8. However, since it's our first Cabal release, there might be rough edges, so any feedback is appreciated. The use of Cabal means that Gtk2Hs is now split into the following packages: • gtk2hs-buildtools: build tools, required to build from source • glib: object type system and data structures • gio: an OS-agnostic file access API • cairo: a 2D vector graphics library • pango: a Unicode-aware font rendering engine • gtk: the base GUI library • gconf: configuration database • glade: a library to build user interfaces from XML descriptions • gnomevfs: an OS-agnostic file access API (deprecated) • gstreamer: a multimedia streaming framework • gtkglext: an OpenGL widget • gtksourceview2: a source-code widget • soegtk: an API providing functions for Paul Hudak’s Haskell School of Expressions book • svgcairo: writing Cairo graphics to SVG files • vte: a terminal widget • webkit: a web-browser widget, based on Apple’s webkit library The aim is to concentrate future development on the core packages (i.e. the first six packages from the list above) and encourage external contributions to the remaining packages by putting them into their own repositories and granting write access to people. Through this process we hope to encourage external contributions and to accelerate the development of the core libraries. To install from sources, see: http://haskell.org/gtk2hs/download/ Documentation can be found here: http://haskell.org/gtk2hs/documentation/ Many thanks to all the external contributors that helped us prepare the release! Happy GUIing, Axel (on behalf of the Gtk2Hs team)___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GHC 6.12.3 Release Candidate 1
Hi Ian, I can build this version on Mac OS X 10.5 and compile Gtk2Hs against it. All concurrency demos work and the more complicated demos work that trigger several levels of callbacks (to C and back to Haskell). Cheers, Axel On May 23, 2010, at 20:42, Ian Lynagh wrote: Hi all, We are pleased to announce the first release candidate for GHC 6.12.3: http://www.haskell.org/ghc/dist/6.12.3-rc1/ As well as the source tarball: ghc-6.12.2.20100521-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
segmentation fault in Gtk2Hs callbacks
Good morning, I'm looking at ticket http://hackage.haskell.org/trac/ghc/ticket/4038 and wonder who is to blame: - this segmentation fault occurs in Gtk2Hs' callbacks (i.e. a Haskell function pointer is being passed to C land) and in a signal (where a general machinery is used to invoke a Haskell function), thus, it doesn't seem to be the way callbacks are used - the segfault only occurs in ghc 6.12.2 not in ghc 6.12.1 However, in the release notes of 6.12.2 there are no changes indicated that look like the RTS has changed. So I would like to simply ask: Are any of the GHC developers aware of any change in the concurrency or GC behaviour in GHC's RTS? Have any other parameters changed (perhaps something with multithreading?). Neither Gtk2Hs nor GHC seem to have changed, yet, there are these intermittend segfaults. It would be good to know which part is the culprit. Thanks, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Proposed ghc-pkg and cabal feature - right list?
I'm replying to Simon M. and myself, as should have sent my first
reply to the ghc users list, I guess.
On 14.03.2010, at 10:54, Axel Simon wrote:
Hi Dan,
I reply to libraries, I think that's the right list for Cabal.
On 13.03.2010, at 21:39, Dan Knapp wrote:
There doesn't seem to be a mailing list for Cabal itself, so I'm
posting here. I came up with an idea for a small feature that I
believe would make a useful addition to ghc-pkg and Cabal. I'm
willing to implement it myself, but I have had some previous
experiences with other projects where I did some work and then the
maintainers said sorry, not interested, so I want to gauge interest
before I start. Who should I talk to?
The feature itself is this: Arbitrary key-value pairs in Cabal
package files and the installed-package database. The use-case is
for
an application supporting plugins to discover installed plugins
compatible with it, interrogating these fields through the GHC API.
For Gtk2Hs I would like to have a similar feature. Gtk2Hs is a
wrapper for Gtk+. It evolves on its own (for which the package has a
version number) but it may wrap different versions of Gtk+.
I think people using Gtk2Hs need to be able to conditionally compile
certain code fragments, depending on which Gtk+ version Gtk2Hs
wraps. However, I had something simpler in mind than providing any
kind of key,value pairs: I would like to export certain Cabal
flags into the package, which could be as easy as specifying:
Flag gtk_2_2
Description: Build objects for Gtk+ version 2.2.
Exported: True
Flag gtk_2_4
Description: Build objects for Gtk+ version 2.4.
Exported: True
Flag gtk_2_6
Description: Build objects for Gtk+ version 2.6.
Exported: True
where the 'Exported' would mean that this flag should be added to
the package data base. A package would then be
gtk-0.10.4{gtk_2_2,gtk_2_4}
if the first two flags would be set by Cabal. A package could then
depend on gtk-0.10.4 in which certain flags are set. Moreover, I
would then want cabal to compile a users package with -Dgtk_2_2 -
Dgtk_2_4 so the user can use CPP to conditionally compile code.
You suggestion of using arbitrary key,value pairs is more general
and needs more thought. You would have to extend Cabal quite a bit
whereas my proposal is more lightweight in that it can build on top
of Cabal's Boolean flags. May I ask:
- could you express your package properties using Boolean flags
(which are set by Cabal automatically)?
- if not, could you not express your plug-in concept using several
packages?
Cheers,
Axel.
For example, my content-management system FruitTart could enumerate
the list of installed packages looking for packages which export a
field fruit-tart-plugin-interface-version with a numeric value
matching the interface version it's expecting.
I'm not quite sure I understand the use case here. Are you saying you
want to writing something within Cabal? Or do you want to use the
Cabal API to find out if a certain package is available?
If you're talking about dynamic plug-ins then I assume it must be the
latter. Besides the technical difficulty of loading a GHC package
dynamically (that I don't know anything about), what prevents you from
looking for a package that contains just the plug in?
On 15.03.2010, at 16:38, Simon Marlow wrote:
My first thought was hmm, there must be another way to do that,
but I can't think of one, or at least a good one.
Perhaps having arbitrary key-value pairs in the package database
would be a good thing. It would help us to avoid breaking things
when we need to change the format, for one thing. We could start
using key-values for new fields rather than adding them to
InstalledPackageInfo. However, then we have a strange situation
where some fields get distinguished status in InstalledPackageInfo.
Of course, for some of those fields we have richer types (e.g.
License), so it makes sense.
So for me, I can't see any serious objections to doing this, but I'd
also ask on the cabal-de...@haskell.org list (in particular we
should hear what Duncan Coutts thinks).
Before implementing anything like general key,value pairs, I would
like to see the exact usage of these fields? So Dan wants to query
these dynamically using an API. I'm much more interested in having CPP
macros defined so I can compile code conditionally. For this purpose,
the key,value pairs are not necessarily suitable since Dan might want
to define a pair that does not create a valid -Dkey=value instruction
for CPP.
Cheers,
Axel.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] two PhD positions in static analysis, Technical University Munich, Germany
Dear all, The chair II for computer science at the Technical University Munich is offering two PhD positions in the area of program analysis. The first position (low-level analysis) is centered around defining an implementing an analysis of x86 assembler code and, in particular, of concurrency constructs. The second position (high-level analysis) is geared towards the analysis of data structures (aka shape analysis) using numeric invariants. The intention is to extend an existing analyzer that performs a forward-reachability analysis with the aim to prove the absence of memory management errors and other defects in legacy C software. This analyzer is written in Haskell. first position: low-level analysis -- Most program analysis tools operate on the source code, usually C, since information on variable types, data structures and basic blocks is not available in the executable. One problem with this approach is the definition of the exact semantics of C source code as many constructs commonly found in hand-written programs are ``implementation-dependent'' or even ``undefined'' according to the C standard. These uncertainties are exacerbated when analyzing programs that make use of concurrency constructs. The goal is therefore to directly analyze the resulting x86 machine code and to reconstruct the control flow graph and data structures on-the-fly. The analysis of concurrent programs moreover requires that (abstract) states are propagated between different threads. The challenge here lies in storing a minimum number of abstract states (to reduce the memory requirements) and to get away with a minimum amount of propagation between threads. - second position: high-level analysis --- One recurring challenge in analysing programs is the precise summarization of data structures. This so-called shape analysis commonly uses logic formulae (e.g. separation logic) to describe a data structure contained in a memory region. In this approach, a predicate must be present that describes the invariant (e.g. list(p) might mean that p points to a memory region containing a singly-linked list). If no predicate is available that matches the data structure that is being built by a program, the logic formula must be discarded in order to ensure termination, thereby discarding both, the shape of a memory region and the information on how it is connected to other memory regions. The goal of this position is to find novel abstractions that infer the shape of a memory region and its connection to other memory regions separately. The connection to other memory regions are then annotated with numeric variables that denote how many memory regions are reachable via the connection. The values of these variables is then tracked separately, allowing a more graceful loss of precision. am only the numeric information needs to be relaxed since number of different shapes is fixed by the structure of the program. - Both positions are fully funded for 4 years and do not come with any teaching duties. The PhD students may start as soon as January 1, 2010. The salary is TVL E13 (about 2900 EUR/1650 EUR per month). The positions are part of the Emmy Noether Programme Verifying Legacy C Programs using Numeric Domains which is headed by Axel Simon. This project, in turn, is located within the chair of Helmut Seidl. The PhD students will be supervised by Axel Simon. What you should provide: - Master (or equivalent) degree in Computer Science or Maths - good programming skills - an interest in compiler construction, program optimization and the like - not afraid of discrete maths, lattices etc. - good writing skills in English and Haskell - an electronic application including detailed CV by December 1 (later applications may not be considered) Contact: Please send applications and any enquiries to: axel.si...@ens.fr ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Problem with profiling
On May 31, 2009, at 21:20, Marco Túlio Gontijo e Silva wrote: Hello, recently there was a thread about a problem in profiling in gtk2hs-users, and it was menitoned that this could be a GHC6 bug. The problem is described in http://sourceforge.net/mailarchive/forum.php? thread_name=1242762143.18742.277.camel%40zezinhoforum_name=gtk2hs- users . Do you think this is a gtk2hs specific problem, or is it something about GHC? Are you sure that you compiled from scratch, i.e. did you do a 'make distclean'? You could try to give --disable-split-objs to configure and see if that helps. Axel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [grapefruit] can't run Grapefruit
On May 25, 2009, at 19:26, Dean Herington wrote: I decided to try on Max OS X (10.5). It seemed to get a bit further, but still no joy. Anyone have a suggestion? bash-3.2$ ghci GHCi, version 6.10.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude :m + Graphics.UI.Grapefruit.Circuit Prelude Graphics.UI.Grapefruit.Circuit :m + Graphics.UI.Grapefruit.GTK Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK :m + Examples.Grapefruit.Simple Prelude Graphics.UI.Grapefruit.Circuit Graphics.UI.Grapefruit.GTK Examples.Grapefruit.Simple run GTK mainCircuit Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package old-time-1.0.0.2 ... linking ... done. Loading package random-1.0.0.1 ... linking ... done. Loading package QuickCheck-2.1.0.1 ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.1 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package filepath-1.1.0.2 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. Loading package directory-1.0.0.3 ... linking ... done. Loading package process-1.0.1.1 ... linking ... done. Loading package haskell98 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package gtk-0.10.0 ... linking ... done. Loading package TypeCompose-0.6.4 ... linking ... done. Loading package lazysmallcheck-0.3 ... linking ... done. Loading package Stream-0.3.1 ... linking ... done. Loading package arrows-0.4.1.1 ... linking ... done. Loading package grapefruit-frp-0.0.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package type-level-0.2.2 ... linking ... done. Loading package type-equality-check-0.0.0.0 ... linking ... done. Loading package grapefruit-records-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-0.0.0.0 ... linking ... done. Loading package grapefruit-examples-0.0.0.0 ... linking ... done. Loading package grapefruit-ui-gtk-0.0.0.0 ... linking ... done. *** Exception: Cannot initialize GUI. Of course! You need to run your program in X11, not in the Terminal. I can't comment on the windows problem since I think ghci not being able to load the .dll file is a ghci problem, unless I'm mistaken and it's a naming issue. Cheers, Axel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: Help : A problem with IO
Hi Abdullah, On Wed, 2008-11-26 at 21:48 +0530, abdullah abdul Khadir wrote: Hi, The function getMyLine written by me is intended for getting a complete string from the standard input. import IO getMyLine :: IO [Char] getMyLine = do c - getChar if(c == '\n') then return elsecs - getMyLine return [c] a) you forgot a 'do' after 'else' b) your email would be answered quicker on haskell-beginners or haskell-cafe since haskell is mainly used for announcements. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] release manager needed for Gtk2Hs
Good morning all, the Gtk2Hs library, one of the two major GUI libraries for Haskell, is in need of a release manager. With the upcoming HACR, I have realised that we haven't released in a long time despite the fact that there are many new developments in the darcs repository (the ListStore and TreeStore implemented in Haskell are now usable from all relevant widgets, e.g., ComboBox, IconView). Duncan has been busy working on Cabal which will allow us to swap Gtk2Hs' autoconf-based infrastructure to Cabal one day. I myself have relocated and very limited access to the various platforms that Gtk2Hs runs on. So while I'm still pushing towards a 1.0 release by working on Gtk2Hs, I don't have the resources to do the releases. Helping us releasing Gtk2Hs does not imply a long-term commitment. For now, we'd be very grateful for somebody helping us out with the next two releases (now and around Xmas). Ideally you have: - Access to a Linux, Windows, Sun and MacOS machine (no biggie if you don't have a Mac). - Root access to the Linux and Windows machine. - Experience using autoconf, possibly automake. - Knowledge of darcs. - Experience of how broken sed on Solaris is. - Machines that have a really ancient versions of Gtk installed. - One machine that has the latest Gtk installed as well as the SourceView widget, one of the HTML browser widgets, libglade, svgcairo, gconf, gnomevfs, glext and gstreamer libraries. What we would like you to do is: - Fix configuration issues that people have reported. - Build the library on all platforms mentioned above. - Build a source release. - Produce a binary installer on Windows. - Put the documentatio online. - Make announcements. What would be great: - Build a binary installer for Mac using the Aqua port of Gtk+. - Make the library build documentation using the new haddock. What you get out of it: - Experience working with a 82 kLoc Haskell project. - Mentioned in the Hall of Fame on our webpage. - Eternal gratefulness from us and our growing community of users. - A beer from me or Duncan when the situation arises. If you're interested, please send an email to me or Duncan. Cheers, Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] C++ bindings
Hi Wolfgang,
On Oct 12, 2007, at 15:22, Wolfgang Jeltsch wrote:
Hello,
what are good approaches for creating Haskell bindings to C++
libraries? The
most promising so far seems to create C wrappers around the C++
libraries and
then bind to them. Is it feasible to bind directly to C++ using
ccall by
relying on some standardized C++ ABI? What about H/Direct? Are
there any
other good ways?
Since the name mangling of C++ members, classes and functions are
compiler specific, I don't think there is a good way of directly
calling the C++ functions and methods. I wrapped all C++ methods of
my classes in C functions. I use the following structure:
C++ header file tvpi.hh:
#ifndef __TVPI_H
#define __TVPI_H
namespace Tvpi {
class Domain {
public:
Domain();
void joinWiden(Domain prev, mpz_class extrapolate);
};
#endif // __TVPI_H
==
C header file tvpi_c.h
#ifndef TVPI_C_H_
#define TVPI_C_H_
#ifdef __cplusplus
extern C {
#endif // __cplusplus
#undef TVPI_TYPE_DECLARATION
#define TVPI_TYPE_DECLARATION(Type) \
typedef struct Type ## _tag Type ## _t; \
typedef Type ## _t * Type ## _p; \
typedef Type ## _t const* const_ ## Type ## _p
TVPI_TYPE_DECLARATION(Domain);
Domain_p tvpiNew(void);
void tvpiFree(Domain_p d);
void tvpiJoin(Domain_p d1, Domain_p d2);
#ifdef __cplusplus
}
#endif // __cplusplus
#endif // TVPI_C_H_
==
C wrapper file, tvpi_c.cpp:
#include tvpi_c.h
#include tvpi.hh
using namespace Tvpi;
templateclass ToType, class FromType
const ToType* to_const(const FromType* x) {
return reinterpret_castconst ToType*(x);
}
templateclass ToType, class FromType
ToType* to_nonconst(FromType* x) {
return reinterpret_castToType*(x);
}
Domain_p tvpiNew() {
return to_nonconstDomain_t, Domain(new Domain());
}
void tvpiFree(Domain_p d) {
delete to_nonconstDomain, Domain_t(d);
}
Domain_p tvpiCopy(Domain_p d) {
return to_nonconstDomain_t, Domain
(new Domain(*to_constDomain, Domain_t(d)));
}
void tvpiJoin(Domain_p d1, Domain_p d2) {
mpz_class w(-1);
to_nonconstDomain, Domain_t(d2)-joinWiden(*to_nonconstDomain,
Domain_t(d1
), w);
}
==
I'm not claiming it's pretty, but it works on several g++ versions.
You also need to pass
something like -pgml g++ -optl -pg to ghc so it know that it should
link using g++ (and thereby linking against the C++ runtime).
Hope this helps,
Axel.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] reading from stdin
Hi,
I'm trying to continuously output data to a file handle while reading
single characters from the user to adjust the speed at which things are
output. I'm interested to get this to work in Hugs on Windows.
I successfully used the following function ghci under Mac OS:
{{{
getUserInput :: IO (Maybe Char)
getUserInput = do
hasInput - hReady stdin
if hasInput then liftM Just (hGetChar stdin) else return Nothing
}}}
This function returns a character to me if there's one available.
If anybody could give me a hint how to get this working in Hugs under
Windows, please tell me.
For the entertainment value, here's what's happening currently:
a) ghci under Unix
A character is returned if it is available, otherwise the function
returns immediately.
b) Hugs under Unix
Characters are not recognised when typed. The characters are returned as
soon as return is hit. The function does not block.
c) ghci under Windows
The function does not block until a character is entered. Once a
character is entered, the function blocks until return is hit.
d) Hugs under Windows
The function aborts immediately somewhere in IO.hWaitForInput with an
'invalid operation (unsupported opperation)' error.
I don't know what the right behaviour is, and I don't really care. But:
a) is the behaviour I want, but unfortunately for platform d)
b) must be due to ghci and Hugs having different opinions on whether
stdin should be line buffered or unbuffered
c) this is weird
d) this is broken
How can I get platform d) working with the behaviour of a)?
Thanks a lot,
Axel.
P.S.: Sorry to post to [EMAIL PROTECTED], but nothing else seemed to match.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell fast (?) arrays
Frederico, On Tue, 2007-05-01 at 13:59 +0200, Federico Squartini wrote: I was reading an old post where Hal Daume III was analyzing Haskell performance for arrays. He proposed a test program which initializes an array, reverse it a number of times, and sums the contents. So I wrote a c++ reference program, a naive haskell version using lists and I also tweaked a little bit with the IOArray version, which should be the fastest. Unfortunately there is a huge performance gap. Haskell is slower by a factor of ten, even when using imperative style. I think the version using lists is a bit unfair, since in C++ you don't re-allocate the array on the heap and the Haskell version gives you a very nice high-level abstraction of lists. With respect to the imperative version, I would suggest a) letting the program run for longer so you get more reliable timing. b) use a similar optimisations that we've done for a demo of modifying images in-situ for our Gtk2Hs library (in http://darcs.haskell.org/gtk2hs/demo/fastdraw/FastDraw.hs ): import Data.Array.Base ( unsafeWrite ) doFromTo 0 255 $ \y - doFromTo 0 255 $ \x - -- Here, writeArray was replaced with unsafeWrite. The latter does -- not check that the index is within bounds which has a tremendous -- effect on performance. -- writeArray pbData (2+x*chan+y*row) blue -- checked indexing unsafeWrite pbData (2+x*chan+y*row) blue -- unchecked indexing Here, doFromTo is much faster and using unsafeWrite instead of writeArray eliminates the array bound check, which is a big win again. Then again, it is questionable if you really want to do that kind of low-level programming in Haskell. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
haddock's image markup doesn't work for me
Hi, I tried to put images into my comments as follows: -- | images/stock-icons/stock_about_24.png but it produces TD CLASS=doc A HREF=images/stock-icons/stock_about_24.png lt;images/stock-icons/stock_about_24.pnggt;/A i.e. there shouldn't be any around the url of the image. Am I missing something here? Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: haddock's image markup doesn't work for me
On Thu, 2006-12-07 at 14:07 +, Neil Mitchell wrote: Hi -- | images/stock-icons/stock_about_24.png Why not: -- | images/stock-icons/stock_about_24.png I thought that was the syntax. I don't want to link to the image, I want to see it on the web-page. The announcement of haddock 0.8 included the line: * New markup url for including images. And I thought this would be really cool for our Gtk2Hs project, but so far it's not cool at all. Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] I18N, external strings
A comment on gettext, On Nov 15, 2006, at 17:35, Stefan Aeschbacher wrote: Hi there is a project for i18n on sourceforge. It contains for example bindings to the gettext library which could be helpful. I'm not sure though how up to date this project is (project page looks very empty). The code is still available in the sourceforge cvs repository: http://haskell-i18n.cvs.sourceforge.net/haskell-i18n/ I think gettext would be a very nice thing to use in Haskell. At the moment, it is slightly inefficient to lookup a string in order to substitute it for a translation. For instance, say l_ is your translations function, saying (l_ Translate this) is compiled into a C string constant, that GHC then turns lazily into a list of characters, which l_ then turns into an array in C land to pass to the gettext function, which, in turn, returns a new C string array that has to be turned into a Haskell string again. So I'm glad Lennart proposed to turn String into a class which would then make it possible to pass a pointer to a contant C string to gettext. Axel. Stefan 2006/11/15, Johannes Waldmann [EMAIL PROTECTED] : (I.e. I want output in several languages, with the language configurable at runtime, and I want to add languages without recompilation.) a typical source text (for my application) is here MailScanner warning: numerical links are often malicious: http://141.57.11.163/cgi-bin/cvsweb/tool/src/Graph/Circle/Plain.hs? rev=1.2 it contains (German) text strings all over the place. In Java/Eclipse, I would Source - Externalize Strings and this replaces each string by something like Messages.getString(Foobar.0) where Messages is a global variable (constructed at program start from reading a properties file) In Haskell, I see at least two problems: a) reading the file is in IO b) there are no global variables. implicit parameters perhaps? c) when I'm trying to be clever, I use deriving Show/Read or similar. then i18n should rename the constructors/accessors? I rather not. MailScanner warning: numerical links are often malicious: http://141.57.11.163/cgi-bin/cvsweb/tool/src/Grammatik/Type.hs.drift? rev=1.6 Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- http://www.imn.htwk-leipzig.de/~waldmann/ --- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: quoting in error messages
On Fri, 2006-04-07 at 16:23 +0100, Simon Peyton-Jones wrote: What do others think? It'd be dead easy to replace `thing' by thing in GHC's error messages, if that's what a majority want. I'd agree with Frederik. Most errors do not involve string constants and `foo' is rather awkward unless run through latex. Axel. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Frederik Eaton | Sent: 07 April 2006 13:40 | To: glasgow-haskell-bugs@haskell.org | Subject: quoting in error messages | | Hi, | | This is quite a minor issue but I just wanted to point out that it | would be a little easier on the eye to use double quotes rather than | paired single quotes in error messages e.g.: | | Couldn't match the rigid variable `d'' against `Bar a' | `d'' is bound by the polymorphic type `forall d d'. | (Data d, Data d') = | t d d' - t d d'' | | Thanks, | | Frederik ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [Haskell] IO == ST RealWorld
On Tue, 2006-01-24 at 09:17 +, Simon Peyton-Jones wrote: | Is there any reason why IO should not be defined as: |type IO a = ST RealWorld a | in implementations that support ST? | | This way IORef/STRef and IOArray/STArray can be merged. I know under the | hood they already share code, but this way they can also share an interface. Indeed, this was the way we had it originally in GHC. It does seem like a good idea. We changed it for reasons that I know that we have forgotten, alas, because we tried to recall about a year ago. It's always possible that the original reasons for the change no longer apply. Perhaps someone can try it out? Is the reason for not having this type synonym maybe bad type error messages? In my program, I've got a type synonym just like that: type ExecM a = StateT FixpointState (ReaderT ProgReaderState IO) a When I erroneously give the simple function warn :: Context - W.Warning - ExecM () warn ctxt warn = do an extra argument in the type signature warn :: Context - W.Warning - Int - ExecM () I get: Couldn't match `(-) Int' against `StateT FixpointState (ReaderT ProgReaderState IO)' Expected type: Int - t Inferred type: ExecM () Even if you've defined the type synonym yourself, it takes a while to realise that the type synonym and the ExecM () are the same, in particular since the type variable t is omitted in the first part. There are many other places in the libraries which could do with a generalisation of types, but where similarly difficult type error messages will arise. One function that particularly annoyed me is in Control.Exception handle :: (Exception - IO a) - IO a - IO a should be handle :: MonadIO m = (Exception - m a) - m a - m a to be usable with my ExecM monad. liftIO doesn't really help here. If it weren't for the type error messages, I would suggest to generalise all function using IO a to MonadIO m = m a. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)
Keean et al, On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote: My solution to this when developing a database library for my own use was to define the API in a bracket notation style, and only provide safe functions. The idea is that the function obtains the resource, calls a function passed as an argument, then frees the resource, so all resouces are guaranteed to be freed in the correct order... for example: dbConnectWith :: DbName - (DbHandle - IO Result) - Result dbConnectWith name workFn = do handle - dbConnectTo name workFn handle `finally` dbDisconnect handle In this way you avoid finalizers... and everthing is safe providing you only export the with style functions from the library... Here's an example from the library, the connect function: I suppose you meant to write result rather than Result. This style of functions is only safe if the user ensures that DbHandle is never returned as part of the result. You should have that in your documentation. As far as I can tell, the only general solution is to use finalizers and, if you really need to enforce a sequence of finialization, touchForeignPtr. A practical issue with touchForeignPtr is that it cannot be conveniently called from another finalizer, since the latter live in C. I can think of three solutions: a) You keep all pointers to your database (handles, connections, etc) in one C structure and keep one ForeignPtr to that. On deallocation, you call a custom C function that frees all the objects in the C data structure in the right sequence. b) You wrap all C data structures in reference-counting objects. On creation of a connection you increment the reference count of the database. Each foreign pointer you create will also increment the reference count. On deallocation of either, the reference count is decremented and the object freed if it has dropped to zero. c) In your special case you could wrap the data base in a StablePtr whenever you create the first connection and subsequently count the number of connections you create. You free the StablePtr when there are no more connections. Solution b) might be impossible to implement if the library itself frees the pointers without consulting your reference count first. If the library frees objects without asking you first, but allows some sort of finalizers, then solution a) makes it possible to at least mark the object as invalid (which all your Haskell functions would have to check). Otherwise solution a) is a bit inefficient, especially if your library calls Haskell functions and passes points to them -- in this case you need to check if this points is already in your data structure and insert it if necessary. Solution c) might be the easiest in your case where the data base always outlives connections and pointers to connections are never passed to Haskell except when they are created. Axel. Chris Kuklewicz wrote: Benjamin Franksen wrote: On Wednesday 04 January 2006 20:13, John Goerzen wrote: Well, yes and no. It would be impossible to garbage collect (and thus finalize) any object for which references to it still exist. Statement handles in HDBC maintain references to the database handle pointers, either directly or indirectly, so I can't see how it is possible for a database handle to be finalized before the statement handle in this situation. Hi John, I fear it /is/ possible. This is a very unfortunate situation and one I had quite some difficulties to understand, when Simon Marlow explained it to me. The problem is that finalization of the statement handle might be delayed indefinitely. The data dependencies between statement and connection handle only ensures that whenever the statement handle is alive, then too is the connection handle. But it does not say anything about what happens in which order after /both/ are dead (garbage). As soon as the connection handle to garbage, too, bothe handles can be finalized in /any/ order. As I pointed out before, this is a very bad thing, because it makes finalizers a whole lot less useful than they could be if an order between finalizations could be specified (directly or indirectly). The arguments against such a solution are mostly: (1) it is difficult to implement efficienty and (2) the programmer could accidentally cause finalizer deadlocks by specifying circular dependencies. Ben This is also mentioned in the documentation: http://www.haskell.org/ghc/docs/6.4.1/html/libraries/base/Foreign-ForeignPtr.html#v%3AtouchForeignPtr touchForeignPtr :: ForeignPtr a - IO () This function ensures that the foreign object in question is alive at the given place in the sequence of IO actions. In particular withForeignPtr does a touchForeignPtr after it executes the user action. Note that this function should not be used to express liveness dependencies between ForeignPtrs. For example, if the
Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)
On Mon, 2006-01-09 at 11:33 +0100, Benjamin Franksen wrote: On Monday 09 January 2006 10:03, Axel Simon wrote: On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote: My solution to this when developing a database library for my own use was to define the API in a bracket notation style, and only provide safe functions. The idea is that the function obtains the resource, calls a function passed as an argument, then frees the resource, so all resouces are guaranteed to be freed in the correct order... for example: dbConnectWith :: DbName - (DbHandle - IO Result) - Result dbConnectWith name workFn = do handle - dbConnectTo name workFn handle `finally` dbDisconnect handle In this way you avoid finalizers... and everthing is safe providing you only export the with style functions from the library... Here's an example from the library, the connect function: I suppose you meant to write result rather than Result. This style of functions is only safe if the user ensures that DbHandle is never returned as part of the result. You should have that in your documentation. I wanted to mention this too, but you were quicker ;) As far as I can tell, the only general solution is to use finalizers and, if you really need to enforce a sequence of finialization, touchForeignPtr. Repeat: touchForeignPtr can NOT be used to enforce finalization order. Ok, I re-read that thread. I agree. However, it is likely that the library you're using allows connections to be freed after the database is freed. If not, you can still all three methods I posted to get around the problem: Each connection needs to ref the database pointer and deref that pointer when the finalizer is run. That way, the database is never dead until all finalizers of all connections are run. A practical issue with touchForeignPtr is that it cannot be conveniently called from another finalizer, since the latter live in C. What do you mean live in C? Can't or shouldn't finalizers be written in Haskell, too? Well, before ghc 6.0 and the new FFI, finalizers where Haskell functions. Since this was tricky to implement, so finalizers are now C functions. This has other implications, e.g. you can't pass a closure of several pointers to the C function, the C finalizer will just get the one pointer it wraps. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Drawing charts via Haskell
On Tue, 2005-12-20 at 15:14 +0100, Gerbrand van Dieijen wrote: Hello, I plan to develop a library in Haskell to draw charts, such as pie charts, bar charts and line charts, to visualize data. Functionality will be similar to gnuplot, or chart libraries that already exist for other languages. The chart library is for (part of) my master-thesis project and it is still in its planning phase. There are several graphic-libraries for Haskell, but I couldn't find any specifically for drawing charts. To avoid that I am reinventing the wheel, does anyone know of such a library that is already developed or being developed? There is a diagram editor called blobs based on wxHaskell, although I doubt that that's any good for your purpose. Rather that implementing it yourself, why don't you tell gnuplot to generate a png and display that in a widget? Does it have to be interactive (selection etc.)? Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Making Haskell more open
On Sun, 2005-11-13 at 18:18 +0100, Wolfgang Jeltsch wrote: Am Freitag, 11. November 2005 20:08 schrieb John Velman: I agree with Gour. I found txt2tags as a result of a discussion on the GTK2HS list. It is simple to use, readable as is, or easily transformable to a variety of targets. Also, it is consistent with bird-track literate Haskell, so I can run my .lhs documents through txt2tags and get html, latex, pretty text, or a bunch of things I haven't tried yet including *.doc (msword) (the latter via txt2tags for html, soffice to go from html to *.doc). The most important question is: Does txt2tags use logical markup? No, it is very layout driven. The advantage is that its dead simple. To be honest we (the Gtk2Hs people) haven't started on our tutorial yet, so we don't have any experience with txt2tags yet. If you think that logical markup is important, then I'd like to point out that DocBook gives you some structure, but you still put in some meaning on top of that, i.e. DocBook has extensive markup for specifying C function signatures, but you'd have to extend it to give you anything that goes beyond pure layout information for things like Haskell functions or code snippets. I think the right thing is to keep ghc's manual in DocBook. What people add will not be whole chapters, but rather paragraphs. The markup you need to learn for that can easily be gleamed from the surrounding text. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: ghci-6.4.1 on solaris
On Fri, 2005-09-16 at 15:03 +0100, Simon Marlow wrote: I've checked it in. Please let me know if it enhances your life... I'm trying. But I'm too stupid to use CVS. The repository moved so I tried: [EMAIL PROTECTED]:~/source/ghc-6.4-branch:505$ cvs -d :pserver:[EMAIL PROTECTED]:/cvs update -d PAM start error: Critical error - immediate abort Fatal error, aborting. cvs [update aborted]: unrecognized auth response from cvs.haskell.org: pam failed to release authenticator It's probably something stupid. The bug I'm reporting is that the change of the CVS server to cvs.haskell.org is not reflected in the CVS cheat sheet. Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] Gtk2Hs 0.9.9 released
Dear all, A new release for Gtk2Hs, namely version 0.9.9 is now available. This is a bug-fix release which is meant to fix various issues in the 0.9.8 release. The tarball is available from at Sourceforge. The md5 checksum is 3276545190248d40c683cd42f51a1b6e. Changes since 0.9.8: * many documentation fixes * documentation builds with the new haddock 0.7 * fixed an intolerant parser in c2hs, the C header-file scanner * fixed segfaults when disconnecting signal handlers * fixed segfaults in signals that pass TextIters * add Pixmap from Gdk (not gtk_pixmap which is deprecated) * added ChildAttributes to all containers * minor fixes to our Makefile Please report any problems with this release to our emailing list, [EMAIL PROTECTED] . Axel (on behalf of the Gtk2Hs team). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ST/STRef vs. IO/IORef
On Wed, 2005-08-03 at 12:07 -0500, Srinivas Nedunuri wrote: I was wondering what advice folks had. In particular, what are the disadvantages to doing everything in the IO monad - ie why even bother with the ST monad? The most obvious disadvantage is that the IO monad has no equivalent of runST. OK, I'm missing something here. What is the big deal about runST? Can I not get the IO equivalent by simply running the program at the top level (assuming I don't have multiple threads going). Do you have a practical example of needing runST in several places in your program? Having recently used the MonadReader and MonadState classes, I got the impression that ST should actually be deprecated. It seems to me that they are a relic from the time when there were no threads, i.e. when everything was in a single IO monad and you couldn't run another IO computation in independently. Nowadays, you can use one of the MonadState monad if you want lazy computation (on top of which you can implement state read and write accesses similar to IORefs) or IO-enabled computation (if you use MonadState.StateT and embed an IO monad at the core). Is this view correct? If not, could there be a comment as to what ST is useful (rather than a reference to a full blown paper that pre- dates the MonadState,... libraries). Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ST/STRef vs. IO/IORef
On Thu, 2005-08-04 at 10:58 +0200, Wolfgang Jeltsch wrote: Am Donnerstag, 4. August 2005 10:21 schrieb Axel Simon: [...] Nowadays, you can use one of the MonadState monad State transformer monads like State and StateT can be implemented without using special language features. So there was always the opportunity to implement something like State or StateT. So, in a way, we always could use the MonadState monads. If ST could be replaced by MonadState monads, ST had never been included in the libraries, I suppose. Well, MonadState needs multi-parameter type classes, and hence, require much more than ST. if you want lazy computation (on top of which you can implement state read and write accesses similar to IORefs) or IO-enabled computation (if you use MonadState.StateT and embed an IO monad at the core). The point is that the MonadState monads don't give you update-in-place. Update-in-place is exactly the reason why ST is there. Ok, granted. In particular I take your point about array accesses. However, I am not quite convinced that using ST has any advantages over using IO directly. Of course, one could claim that programmers wants to protect themselves from themselves by disallowing arbitrary IO. But if that is the only advantage then I'd rather go for the flexibility to use arbitrary IO later on without having to rewrite my whole program. Thanks for you comment, Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] offside rule question
Brian, On Thu, 2005-07-14 at 19:58 -0500, Brian Smith wrote: On 7/14/05, Frederik Eaton [EMAIL PROTECTED] wrote: On Thu, Jul 14, 2005 at 03:15:32AM +0200, Lennart Augustsson wrote: The offside rule is patronizing. :) It tries to force you to lay out your program in a certain way. If you like that way, good. I disagree. The offside rule in general makes a more concise syntax available to the programmer, who would probably choose a similar indentation style anyway. The issue that I brought up is a case where the programmer is *prevented* from using a certain syntax, for the sole reason that, if what you say is correct, someone has determined that the prohibition is good for him. I dislike such design rationales because they always end up hurting advanced users, who may have atypical needs, but who should ideally play an important role in promoting the language to others; it makes it seem like the plan is I don't understand how a rule that requires one to prefer easier-to-read layout over more-difficult-to-read layout is bad, if each alternative is of equal verbosity (as is the case here). I agree with Frederik since I've been bitten by that rule before. Defining a single function like so: let a very long definition of a = and the body has to be here is a very long application to and and using long arguments like definition is a pain in is harder to read and might force you to use shorter, less descriptive variable names. let an even longer definition of a function called an = is much easer to read I think in It is up to the programmer to write easy to write programs, not the language. I changed the 'a' to 'a' afterwards which also forced me to indent the whole rhs as well. It's not a good feature IMHO. That said, I don't know if it's easy to change of if there are other ambiguities popping up. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [HOpenGL] FW: ghc-6.4.1 on solaris
On Tue, 2005-07-12 at 12:54 +0100, Simon Marlow wrote: On 12 July 2005 11:52, Christian Maeder wrote: Sven Panne wrote: FYI: I've just committed a fix to CVS HEAD for GHC on SPARC to reduce the register pressure on gcc, which will probably make its way into GHC 6.4.1. The OpenGL/GLUT packages compile fine now with gcc 3.4.4 on SPARC, success stories and/or tragic failures with this patch are highly welcome... Good, I'm trying to create a release. Would you also dare to look into the mangler to fix the linking problem of ghci? Or do you have clue how to do this, Simon? Sorry, I don't have any idea what's causing that problem. ...but it would be nice to get it fixed. The symbol seens to stem from ghc/compiler/cmm/CLabel.hs where it says: pprCLbl ModuleRegdLabel = ptext SLIT(_module_registered) Is this meant to be an external symbol? And what does it do? Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: [HOpenGL] FW: ghc-6.4.1 on solaris
On Tue, 2005-07-12 at 13:27 +0100, Simon Marlow wrote: On 12 July 2005 13:14, Axel Simon wrote: On Tue, 2005-07-12 at 12:54 +0100, Simon Marlow wrote: On 12 July 2005 11:52, Christian Maeder wrote: Sven Panne wrote: FYI: I've just committed a fix to CVS HEAD for GHC on SPARC to reduce the register pressure on gcc, which will probably make its way into GHC 6.4.1. The OpenGL/GLUT packages compile fine now with gcc 3.4.4 on SPARC, success stories and/or tragic failures with this patch are highly welcome... Good, I'm trying to create a release. Would you also dare to look into the mangler to fix the linking problem of ghci? Or do you have clue how to do this, Simon? Sorry, I don't have any idea what's causing that problem. ...but it would be nice to get it fixed. The symbol seens to stem from ghc/compiler/cmm/CLabel.hs where it says: pprCLbl ModuleRegdLabel = ptext SLIT(_module_registered) Is this meant to be an external symbol? And what does it do? _module_registered is a single word-sized variable in every module. The symbol is supposed to be local, and hence not visible to other modules (otherwise it clashes, of course). On Sparc, it appears that something is going wrong either in the mangler or the splitter or the linker, and this symbol is leaking(?). You could check whether it is indeed local as it is supposed to be in the library modules. eg. if I say 'nm libHSbase.a | grep module_registered' on Linux, I get nothing back. [EMAIL PROTECTED]:~/source/ghc-6.4-branch:519$ nm libraries/base/libHSbase.a | grep module_registered [11]| 4| 4|OBJT |GLOB |0|COMMON | _module_registered [23]| 4| 4|OBJT |GLOB |0|COMMON | _module_registered [11]| 4| 4|OBJT |GLOB |0|COMMON | _module_registered [9] | 4| 4|OBJT |GLOB |0|COMMON | _module_registered [9] | 4| 4|OBJT |GLOB |0|COMMON | _module_registered [10]| 4| 4|OBJT |GLOB |0|COMMON | _module_registered ...and so on. So it is global in every single source file. Do I know check how the .c file looks like? The symbol is defined in e.g. Arrow__84.o Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Compiling ghc 6.4 with ghc 5.04.3
On Wed, 2005-07-06 at 10:06 +0100, Simon Peyton-Jones wrote: That's weird. We compile 6.4 with 5.04.3 every night. Maybe you are using different flags than we are? - can you send your build.mk I haven't changed anything, i.e. no build.mk. - plus a full transcript so we can see what flags are being passed to ghc (e.g. -O2) below is the full last invocation of the link stage that fails (stage1 compiler), attached is that invocation redone with -v Is your source tree for 6.4 - the STABLE branch, or - the exact bits for 6.4 downloaded from the download site? It's the tar ball from the web-site. Under /lib there is libc-2.2.5.so and libc.so.6. Is there any other prerequisite that this Debian machine might not fulfil? Thanks, Axel ==fptools== make all -wr; in /home/part3/cur/as49/gonzo/source/ghc-6.4/ghc/compiler /usr/local/bin/ghc -o stage1/ghc-6.4 -H16m -O -istage1/utils - istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude - istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/specialise -istage1/simplCore -istage1/stranal - istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main - istage1/profiling -istage1/parser -istage1/cprAnalysis - istage1/compMan -istage1/ndpFlatten -istage1/iface -istage1/cmm - istage1/nativeGen -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc- timing -I. -IcodeGen -InativeGen -Iparser -package posix -recomp -Rghc- timing -H16M '-#include hschooks.h' -i../lib/compat- L../lib/compat -lghccompat -no-link-chk stage1/basicTypes/BasicTypes.o stage1/basicTypes/DataCon.o stage1/basicTypes/Demand.o stage1/basicTypes/FieldLabel.o stage1/basicTypes/Id.o stage1/basicTypes/IdInfo.o stage1/basicTypes/Literal.o stage1/basicTypes/MkId.o stage1/basicTypes/Module.o stage1/basicTypes/Name.o stage1/basicTypes/NameEnv.o stage1/basicTypes/NameSet.o stage1/basicTypes/NewDemand.o stage1/basicTypes/OccName.o stage1/basicTypes/RdrName.o stage1/basicTypes/SrcLoc.o stage1/basicTypes/UniqSupply.o stage1/basicTypes/Unique.o stage1/basicTypes/Var.o stage1/basicTypes/VarEnv.o stage1/basicTypes/VarSet.o stage1/cmm/CLabel.o stage1/cmm/Cmm.o stage1/cmm/CmmLex.o stage1/cmm/CmmLint.o stage1/cmm/CmmParse.o stage1/cmm/CmmUtils.o stage1/cmm/MachOp.o stage1/cmm/PprC.o stage1/cmm/PprCmm.o stage1/codeGen/Bitmap.o stage1/codeGen/CgBindery.o stage1/codeGen/CgCallConv.o stage1/codeGen/CgCase.o stage1/codeGen/CgClosure.o stage1/codeGen/CgCon.o stage1/codeGen/CgExpr.o stage1/codeGen/CgForeignCall.o stage1/codeGen/CgHeapery.o stage1/codeGen/CgInfoTbls.o stage1/codeGen/CgLetNoEscape.o stage1/codeGen/CgMonad.o stage1/codeGen/CgParallel.o stage1/codeGen/CgPrimOp.o stage1/codeGen/CgProf.o stage1/codeGen/CgStackery.o stage1/codeGen/CgTailCall.o stage1/codeGen/CgTicky.o stage1/codeGen/CgUtils.o stage1/codeGen/ClosureInfo.o stage1/codeGen/CodeGen.o stage1/codeGen/SMRep.o stage1/compMan/CompManager.o stage1/coreSyn/CoreFVs.o stage1/coreSyn/CoreLint.o stage1/coreSyn/CorePrep.o stage1/coreSyn/CoreSubst.o stage1/coreSyn/CoreSyn.o stage1/coreSyn/CoreTidy.o stage1/coreSyn/CoreUnfold.o stage1/coreSyn/CoreUtils.o stage1/coreSyn/ExternalCore.o stage1/coreSyn/MkExternalCore.o stage1/coreSyn/PprCore.o stage1/coreSyn/PprExternalCore.o stage1/cprAnalysis/CprAnalyse.o stage1/deSugar/Check.o stage1/deSugar/Desugar.o stage1/deSugar/DsArrows.o stage1/deSugar/DsBinds.o stage1/deSugar/DsCCall.o stage1/deSugar/DsExpr.o stage1/deSugar/DsForeign.o stage1/deSugar/DsGRHSs.o stage1/deSugar/DsListComp.o stage1/deSugar/DsMonad.o stage1/deSugar/DsUtils.o stage1/deSugar/Match.o stage1/deSugar/MatchCon.o stage1/deSugar/MatchLit.o stage1/hsSyn/HsBinds.o stage1/hsSyn/HsDecls.o stage1/hsSyn/HsExpr.o stage1/hsSyn/HsImpExp.o stage1/hsSyn/HsLit.o stage1/hsSyn/HsPat.o stage1/hsSyn/HsSyn.o stage1/hsSyn/HsTypes.o stage1/hsSyn/HsUtils.o stage1/iface/BinIface.o stage1/iface/BuildTyCl.o stage1/iface/IfaceEnv.o stage1/iface/IfaceSyn.o stage1/iface/IfaceType.o stage1/iface/LoadIface.o stage1/iface/MkIface.o stage1/iface/TcIface.o stage1/main/CmdLineOpts.o stage1/main/CodeOutput.o stage1/main/Config.o stage1/main/Constants.o stage1/main/DriverFlags.o stage1/main/DriverMkDepend.o stage1/main/DriverPhases.o stage1/main/DriverPipeline.o stage1/main/DriverState.o stage1/main/DriverUtil.o stage1/main/ErrUtils.o stage1/main/Finder.o stage1/main/GetImports.o stage1/main/HscMain.o stage1/main/HscStats.o stage1/main/HscTypes.o stage1/main/Main.o stage1/main/PackageConfig.o stage1/main/Packages.o stage1/main/ParsePkgConf.o stage1/main/SysTools.o stage1/main/TidyPgm.o stage1/nativeGen/AsmCodeGen.o stage1/nativeGen/MachCodeGen.o stage1/nativeGen/MachInstrs.o stage1/nativeGen/MachRegs.o stage1/nativeGen/NCGMonad.o stage1/nativeGen/PositionIndependentCode.o
Compiling ghc 6.4 with ghc 5.04.3
Hi, I'm trying to bootstrap 6.4 with a binary 5.04.3 on Debian Linux. I get the following during linking: stage1/nativeGen/AsmCodeGen.o: In function `slZu_dflt': stage1/nativeGen/AsmCodeGen.o(.text+0x7ebe): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZB_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x7ffc): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZD_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x8004): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slAj_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x82bc): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o: In function `slZL_1_alt': stage1/nativeGen/AsmCodeGen.o(.text+0x82c4): undefined reference to `GHCziPrim_zdwZ2H_entry' stage1/nativeGen/AsmCodeGen.o(.text+0xb0bc): more undefined references to `GHCziPrim_zdwZ2H_entry' follow collect2: ld returned 1 exit status ghc: 4414788 bytes, 2 GCs, 155432/155432 avg/max bytes residency (1 samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (10.98 elapsed), 0.02 GC (0.02 elapsed) :ghc make[2]: *** [stage1/ghc-6.4] Error 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/home/part3/cur/as49/gonzo/source/ghc-6.4/ghc' make: *** [build] Error 1 Can anyone tell me a) if 6.4 is supposed to compile with 5.04.3. b) if not, via what other version can I get from 5.04.3 to 6.4. c) if there is a newer binary package of ghc that works with glibc 2.2 Thanks, Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Compiling ghc 6.4 with ghc 5.04.3
On Wed, 2005-07-06 at 10:06 +0100, Simon Peyton-Jones wrote: That's weird. We compile 6.4 with 5.04.3 every night. Maybe you are using different flags than we are? - can you send your build.mk - plus a full transcript so we can see what flags are being passed to ghc (e.g. -O2) I'm using gcc 2.95.4, maybe that's the oddity. ld is GNU ld version 2.12.90.0.1 20020307 Debian/GNU Linux Axel. Is your source tree for 6.4 - the STABLE branch, or - the exact bits for 6.4 downloaded from the download site? Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-bugs- | [EMAIL PROTECTED] On Behalf Of Axel Simon | Sent: 06 July 2005 09:14 | To: glasgow-haskell-bugs@haskell.org | Subject: Compiling ghc 6.4 with ghc 5.04.3 | | Hi, | | I'm trying to bootstrap 6.4 with a binary 5.04.3 on Debian Linux. | | I get the following during linking: | | stage1/nativeGen/AsmCodeGen.o: In function `slZu_dflt': | stage1/nativeGen/AsmCodeGen.o(.text+0x7ebe): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZB_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x7ffc): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZD_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x8004): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slAj_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x82bc): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o: In function `slZL_1_alt': | stage1/nativeGen/AsmCodeGen.o(.text+0x82c4): undefined reference to | `GHCziPrim_zdwZ2H_entry' | stage1/nativeGen/AsmCodeGen.o(.text+0xb0bc): more undefined references | to `GHCziPrim_zdwZ2H_entry' follow | collect2: ld returned 1 exit status | ghc: 4414788 bytes, 2 GCs, 155432/155432 avg/max bytes residency (1 | samples), 5M in use, 0.01 INIT (0.00 elapsed), 0.01 MUT (10.98 elapsed), | 0.02 GC (0.02 elapsed) :ghc | make[2]: *** [stage1/ghc-6.4] Error 1 | make[1]: *** [all] Error 1 | make[1]: Leaving directory | `/home/part3/cur/as49/gonzo/source/ghc-6.4/ghc' | make: *** [build] Error 1 | | Can anyone tell me | | a) if 6.4 is supposed to compile with 5.04.3. | b) if not, via what other version can I get from 5.04.3 to 6.4. | c) if there is a newer binary package of ghc that works with glibc 2.2 | | Thanks, | Axel. | | | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Building ghc-6.4-branch on Solaris
On Thu, 2005-06-09 at 15:24 +0200, Christian Maeder wrote: Axel Simon wrote: gcc -O -Wall -I../../../ghc/includes -I../../../ghc/rts -I/core/include-c env.c -o env.p_o cc1: /core/include: Not a directory My gcc does not complain about that missing directory. I was able to create a working installation under solaris with: ./configure --disable-opengl --disable-glut --disable-openal Ouch, yes, that is easier than my fiddling. Thanks. Regarding my problem, I changed the Makefile in hslibs: Index: posix/cbits/Makefile === RCS file: /cvs/fptools/hslibs/posix/cbits/Makefile,v retrieving revision 1.17 diff -r1.17 Makefile 7,8c7 SRC_CC_OPTS += -I$(GHC_INCLUDE_DIR) -I$(GHC_RUNTIME_DIR) \ -I$(GHC_LIB_DIR)/core/include --- SRC_CC_OPTS += -I$(GHC_INCLUDE_DIR) -I$(GHC_RUNTIME_DIR) Now it works for me, too. if I compile the ghc without SplitObjs=NO in mk/build.mk I get annoying but probably harmless warnings during compilations: Warning: retaining unknown function `getpwuid_r' in output from C compiler Warning: retaining unknown function `getpwnam_r' in output from C compiler Warning: retaining unknown function `getgrgid_r' in output from C compiler Warning: retaining unknown function `getgrnam_r' in output from C compiler I haven't overridden anything in build.mk, so I assume SplitObjs=YES. When would I observe these warnings? Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Building ghc-6.4-branch on Solaris
Hi, after faking my way around the not-enough-register in libraries/OpenGL recently reported on the HOpenGL list, I ran into the following: ==fptools== gmake all - --no-print-directory -r; in /nfs/myrtle/d24/part2/home/cur/as49/source/ghc-6.4- branch/hslibs/posix/cbits gcc -O -Wall -I../../../ghc/includes -I../../../ghc/rts -I/core/include-c env.c -o env.p_o cc1: /core/include: Not a directory The directory /core/include doesn't exist, what the makefile says is ./hslibs/posix/cbits/Makefile: -I$(GHC_LIB_DIR)/core/include however, I can't find GHC_LIB_DIR in any of the config files. Is it dead? Any help appreciated, Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] Should inet_ntoa Be Pure?
On 5/7/05, Dominic Steinitz [EMAIL PROTECTED] wrote: Does anyone know why these are in the IO monad? Aren't they pure functions converting between dotted-decimal strings and a 32-bit network byte ordered binary value? I guess the answer is no for both: The first one can fail and the second one overwrites a fixed string buffer (yuck!). From the man page: The return value from inet_ntoa() points to a buffer which is overwritten on each call. This buffer is implemented as thread-specific data in multithreaded applications. Hence ntoa needs to be an IO action so that the value is read immediately before the next ntoa call is executed. What you could do is to apply unsafePerformIO to On Sat, 2005-05-07 at 13:40 +0200, David Sankel wrote: Below is the relevant source code. [..] inet_ntoa :: HostAddress - IO String inet_ntoa haddr = do pstr - c_inet_ntoa haddr peekCString pstr function which is safe. Both function should probably be deprecated in favour of ntop and pton since only these can also deal with IPv6 addresses. Furthermore ntop can be a pure function as it takes a 46-byte string buffer as argument. Axel. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Bad eta expand during building
Hi,
I'm just trying to compile ghc 6.4. I was a bit put off by ton's of Bad
eta expand messages scrolling off my screen. It looks like this:
Bad eta expand
1
__coerce GHCziBase.Z0T{(w) tc 40}
(CmmParse.zgzg{v rej3}
@ GHCziBase.Z0T{(w) tc 40}
@ GHCziBase.Z0T{(w) tc 40}
(__coerce CmmParse.ExtCode{tc r3CA} happyzuxzu1{v a3WU})
(__coerce CmmParse.ExtCode{tc r3CA} happyzuxzu2{v a3WT})
(__coerce CmmParse.Env{tc r3CI} eta{v sb4W}))
GHCziBase.Z0T{(w) tc 40}
ghc: 1194327916 bytes, 3628 GCs, 13332977/21631780 avg/max bytes
residency (11 samples), 57M in use, 0.00 INIT (0.00 elapsed), 5.13 MUT
(39.72 elapsed), 2.47 GC (2.59 elapsed) :ghc
../../ghc/compiler/stage1/ghc-inplace -H16m -O -istage2/utils -
istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -
istage2/rename -istage2/typecheck -istage2/deSugar -istage2/coreSyn
-istage2/specialise -istage2/simplCore -istage2/stranal -
istage2/stgSyn -istage2/simplStg -istage2/codeGen -istage2/main -
istage2/profiling -istage2/parser -istage2/cprAnalysis -
istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm -
istage2/nativeGen -istage2/ghci -Istage2 -DGHCI -package template-
haskell -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno-
generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -
package Cabal -recomp -Rghc-timing -H16M '-#include hschooks.h'-c
utils/FiniteMap.lhs -o stage2/utils/FiniteMap.o -ohi
stage2/utils/FiniteMap.hi
I don't know which files this refers to as there were way too many of
these messages to scroll back. But the next file is obviously
FiniteMap.lhs
Does this message have to scare me? And if yes, why does the build
proceed?
Axel.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
ghc sensitive to struct layout
Good morning, gcc uses a different convention from the Microsoft environment when it comes to laying out fields in C structs, in particular bit fields. Can I pass the -optc--mms-bitfields to ghc when it compiles via C without negative effect? This flag is not implicit at the moment which I assume means that ghc itself is not compiled with --mms-bitfields on Windows. ghc surely includes struct declarations when it compiles the generated C files, so the question is whether all its structs are laid out the same regardless of which layout option one chooses. Thank, Axel. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-pkg -g fails on Solaris
On 18 Jan 2005, at 15:12, Duncan Coutts wrote: Hi, On all Unix platforms except Darwin, ghc-pkg calls: ld -r -x -o HSfoo.o --whole-archive libHSfoo.a See: ghc/utils/ghc-pkg/Main.hs, function autoBuildGHCiLib This works for the GNU linker. For the Solaris linker (which takes the name ld, GNU ld gets gld if it's installed) this does not work. The Solaris linker does not understand the -x or --whole-archive flags. I built GHC by setting some funny autoconf variables to the GNU versions of the linker and the archiver. However, the real bug, IMHO, is that ghc-pkg uses ld in the current search path instead of the one ghc was configured with. GNU ld has the nice side effect that it is much faster than Sun's ld. The only way seems to build the ghci library by hand. Axel. ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ghc-6.2.2: unknown package name: Main (again)
Hi, On Wed, 2004-12-01 at 17:36, Gregory Wright wrote: I cleaned out all of the *.o and *.hi files and rebuilt. Everything was OK. No doubt there was something stale in one of the *.hi files, although the error message is perplexing to those of us who don't channel Simonness ;--) I came across the same problem today. crossroads-able ghc --make -package hsshellscript -o asgraph asgraph.hs Chasing modules from: asgraph.hs Skipping Reformat ( ./Reformat.hs, ./Reformat.o ) Skipping Main ( asgraph.hs, asgraph.o ) Linking ... ghc-6.2.2: unknown package name: Main However, building the package (hsshellscript) with the additional option -package-name hsshellscript Files that *use* the package foo keep track of this dependency in the .hi files. However they track the name that you give with the -package-name option when compiling the package, not the name given with -package when you compile the program. I guess in your case you forgot to compile the package with -package-name=foo such that the package was implicitly named Main. Solution: Rebuild the library with the proper -package-name flag and rebuild everything that uses that package. Axel. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show
On Mon, 2004-11-22 at 23:34, John Velman wrote:
In a nutshell:
I want to use the old value of a tag to compute the new value, in a
callback,
I want to access the tag from other callbacks, and
I want to the value to a mutable list from within the callback.
I'd certainly be interested in doing without global variables, and would
appreciate any advice.
For GUI programming you don't need global variables. You can partially
apply all those values to the callback that are necessary. In
particular, those values can be MVars or IORefs which are like pointers
to a value (i.e. you can modify them). For example to draw a bit of
graphics:
canvas - drawingAreaNew
text - canvas `widgetCreateLayout` Hello World.
canvas `onExpose` updateCanvas canvas text
where the function updateCanvas takes 3 arguments:
updateCanvas :: DrawingArea - PangoLayout - Event - IO Bool
updateCanvas canvas text (Expose { area=rect }) = do
(By the way, I'm using Linux, and so far it looks like HTk is my choice for
the GUI interface.)
I don't know if HTk is still maintained. The most popular GUI toolkit is
wxHaskell now; if you're only developing on Unix then gtk2hs might be a
choice.
Axel.
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
ghci of RPM package of ghc 6.2.2 segfaults
I installed the ghc 6.2.2 RPM package on a system that didn't have anything Haskell like installed on it before. When I run ghci I get: ~/current/sources/analyzer:$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.2.2, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Segmentation fault ~/current/sources/analyzer:$ I don't know what is going on and I don't know how to narrow it down. Saying ghci -v doesn't help either, the last lines are: Hsc static flags: -static *** Parser: *** Desugar: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package base ... linking ... done. Segmentation fault ~/current/sources/analyzer:$ The PATH is fine, ldd says: ~/current/sources/analyzer:$ ldd /usr/lib/ghc-6.2.2/ghc-6.2.2 libreadline.so.4 = /usr/lib/libreadline.so.4 (0x0091e000) libncurses.so.5 = /usr/lib/libncurses.so.5 (0x0731a000) libdl.so.2 = /lib/libdl.so.2 (0x00262000) libm.so.6 = /lib/tls/libm.so.6 (0x0023d000) libgmp.so.3 = /usr/lib/sse2/libgmp.so.3 (0x00268000) libc.so.6 = /lib/tls/libc.so.6 (0x0012) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x00107000) ~/current/sources/analyzer:$ How can I track this down? Has anybody experienced a similar problem? Am I just stupid? Any help appreciated, Axel. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Text.ParserCombinators.Parsec requires -package text.
On Wed, Sep 08, 2004 at 10:35:35AM +0100, Simon Marlow wrote: Following up to my own message: On 08 September 2004 10:26, Simon Marlow wrote: [..] Not to mention incompatible C libraries: suppose I have two packages implementing Haskll layers over gtk 1.2 and 2.0 - I can't try to link both of those, even if the Haskell layers don't overlap. But of course, you could implement link everything for just the packages which are normally enabled by default (i.e. the ones marked auto, which currently correspond to the hierarchical ones). These are non-overlapping and link-compatible by definition, so that would work fine. But if I have two layers over gtk 1.2 and 2.0 and both use the hierarchical module system and are therefore marked as auto you would have the same problem of linking in two versions of gtk which doesn't work. Did I miss something? Axel. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell] for large x, log (x::Integer) :: Double
On Sun, Jul 04, 2004 at 12:32:39PM +0200, Dylan Thurston wrote:
On Wed, Jun 30, 2004 at 03:07:00PM -0700, Greg Buchholz wrote:
-- Inspired from Mr. Howard Oakley. Might not qualify as good,
-- but with this function I get log10(x)=849.114419903382
...
For those who aren't aware: working with logs base 2 internally will
be very much faster than logs base 10, since the numbers are stored
internally in a base-2 representation. (Note that 'show' converts to
base 10, which involves a large number of divisions in the easy
algorithm.)
You could actually have a constant-time log function for Integer by
looking at the internal representation. A gmp integer consists of an array
of limbs (usually the size of your machine's register), the used bytes
size within that allocated space and the sign bit in the MSB of size.
All integers are thus stored as unsigned quantities, hence it should be
sufficient to look at size and the highest limb in the array to determine
how many bits the number uses. I once wrote a marshaling function from
Integer to C gmp integers which I attach. It should help as starting
point. (The conversion from C to Haskell might be flawed, I always had
problems reading them back in and never found out where. So beware).
Axel.
Run through hsc2hs:
import GHC.Base
import GHC.IOBase
import Foreign
import Foreign.C
-- A dummy data type for the external mpz_struct.
data MpzStruct = MpzStruct
-- To use the guts of an integer in C land, we need to copy the data of the
-- number from the GCed Haskell land to safer C land.
withInteger :: Integer - (Ptr MpzStruct - IO a) - IO a
withInteger (J## size## barr##) act = do
-- Make space for a mpz_t struct.
allocaBytes #{const sizeof(__mpz_struct)} $ \mpzPtr - do
let bytesInLimbs = I## (sizeofByteArray## barr##)
let limbs@(I## limbs##) = bytesInLimbs `div` #{const sizeof(mp_limb_t)}
-- Make space for a limb as big as the one of the Integer.
allocaBytes bytesInLimbs $ \limbPtr@(Ptr addr##) - do
-- Copy the limb of the Integer to the newly created mpz_t.
let
copy## :: Int## - State## RealWorld - (## State## RealWorld, () ##)
copy## 0## s = (## s, () ##)
copy## i## s =
case i## -## 1## of { i'## -
case indexWord#{const 8*sizeof(mp_limb_t)}Array##
barr## i'## of { val## -
case writeWord#{const 8*sizeof(mp_limb_t)}OffAddr##
addr## i'## val## s of { s' -
copy## i'## s'
}
}
}
IO $ \s - copy## limbs## s
-- Fill the structure
#{poke __mpz_struct, _mp_alloc} (castPtr mpzPtr) limbs
#{poke __mpz_struct, _mp_size} (castPtr mpzPtr) (I## size##)
#{poke __mpz_struct, _mp_d} (castPtr mpzPtr) limbPtr
act mpzPtr
withInteger small act = withInteger (toBig small) act
-- To transfer an integer to Haskell land we allocate an mpz_t
-- structure, initialize it, send it to the C function,
-- then copy its content to Haskell and finally free it.
extractInteger :: (Ptr MpzStruct - IO a) - IO (Integer, a)
extractInteger act =
-- Make space for a mpz_t struct.
allocaBytes #{const sizeof(__mpz_struct)} $ \mpzPtr -
bracket_ (mpz_init mpzPtr) (mpz_clear mpzPtr) $ do
res - act mpzPtr
-- Extract the contents of the mpz_t to a Haskell integer.
(I## alloc##) - #{peek __mpz_struct, _mp_alloc} (castPtr mpzPtr)
(I## size##) - #{peek __mpz_struct, _mp_size} (castPtr mpzPtr)
(Ptr addr##) - #{peek __mpz_struct, _mp_d} (castPtr mpzPtr)
val - IO $ \s## -
case newByteArray## (alloc## *## #{const sizeof(mp_limb_t)}##) s## of
{ (## s1##, mutarr## ##) -
let
copy## :: Int## - State## RealWorld - State## RealWorld
copy## 0## s## = s##
copy## i## s##=
let
i'## = i## -## 1##
val## = indexWord#{const 8*sizeof(mp_limb_t)}OffAddr##
addr## i'##
s'## = writeWord#{const 8*sizeof(mp_limb_t)}Array##
mutarr## i'## val## s##
in copy## i'## s'## in
case copy## alloc## s1## of { s2## -
case unsafeFreezeByteArray## mutarr## s2## of {
(## s3##, barr## ##) - (## s3##, J## size## barr## ##)
}
}
}
return (val, res)
foreign import ccall unsafe __gmpz_init mpz_init :: Ptr MpzStruct - IO ()
foreign import ccall unsafe __gmpz_clear mpz_clear :: Ptr MpzStruct - IO ()
Re: [Haskell] COM port IO on a Windows machine?
On Wed, Mar 17, 2004 at 05:46:25PM +1030, Peter Pudney wrote: I have a microcontroller connected to the COM2 port on a Windows machine, and want my Haskell program to interact with it. My Haskell program is working nicely on my Mac, with interaction using stdin and stdout, but I am not familiar with Windows and a quick Google search did not give me any information on how to get Haskell IO happening through a Windows serial port. * How should I open the COM2 port? IO Mode? Buffering? * How do I write and read? I presume I can set the port parameters fusing something like: ...; e - system MODE COM2 19200,*,N,1,P; ... You can also set these default parameters somewhere in the Control Panel. In case the openFile function is implemented under Windows by calling CreateFile in the Windows API, then you can just call openFile with the name COM2:19200,8,N,1,P or simliar and use standard read and write functions on files. Maybe this helps, Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GHC EXE Windows
At 08:09 04/03/04 +, Stenio wrote: GHC executable file only works in MS-DOS. I would like run the executable file on Windows. Can someone help me Thanks Did you write a GUI program and each time you double click your program gets started out of a DOS window? If that is the case you need to supply the -subsystem windows (or similar) to the gcc compiler so it links in the code for starting a GUI, not a console, application. If you're using a pre-packages GUI library, then that library should specify this linker flag in the package description. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Announce: wxHaskell 0.6
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. 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. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] 3d or Nd geometry library?
On Fri, Feb 13, 2004 at 11:31:39AM -0800, Abraham Egnor wrote: I was somewhat surprised to see that there's only one geometry library on the haskell libraries page, and further dismayed to find that it for the most part only does 2d. It seems like haskell should be a natural fit for higher-order geometric libraries - has anyone heard of such? What kind of geometry algorithms are you searching for? Perhaps the answer to you question is that computational geometry is hard to get right and thus deserves to be written in C or C++ for better accessiblity. In case you are interested in convex polyhedra then I can provide you with a Haskell binding to the Parma Polyhedra Library (search for Parma PPL). The binding is a bit still buggy, probably because I didn't manage to marshal Integers propperly. When I find the flaw, the binding will come with the library (like the O'Caml interface). But you're right, especially due to the built-in arbitrary precision integers and rationals, Haskell is ideal for computational geometry. I attach the Graham convex hull algorithm, just for the sake of it. Axel. module Graham where import List import Ratio --import Debug.Trace(trace) type Vertex = (Rational, Rational) -- Removes double elements in a sorted list. remDoubles :: Eq a = [a] - [a] remDoubles [] = [] remDoubles (x:xs) = x:rD x xs where rD _ [] = [] rD last (x:xs) | x==last = rD last xs | otherwise = x:rD x xs -- Extract the point with the smallest y and largest x coordinate. getHullVertex :: [Vertex] - Vertex getHullVertex [] = error getHullVertex: empty set of points getHullVertex ps = foldl1 maxVertex ps where maxVertex :: Vertex - Vertex - Vertex maxVertex p1@(x1, y1) p2@(x2, y2) | y1y2 = p1 | y2y1 = p2 | x1x2 = p1 | otherwise = p2 -- Test three points for being ordered clockwise. If the argument simple is -- false pair this test lexicographically with the distance of the second -- and the thirds point. isCW :: Vertex - Vertex - Vertex - Ordering isCW (a, b) (c, d) (e, f) = let dx21 = c-a dy21 = d-b dx31 = e-a dy31 = f-b in case compare (dy31*dx21) (dy21*dx31) of LT - LT GT - GT EQ - compare (dx21*dx21+dy21*dy21) (dx31*dx31+dy31*dy31) -- Sort the list of points according to one point on the hull. preprocess :: [Vertex] - [Vertex] preprocess [] = [] preprocess pts = mp:sortBy (isCW mp) (filter ((/=) mp) pts) where mp = getHullVertex pts -- Remove points in the interior. graham :: [Vertex] - [Vertex] graham = gh . remDoubles . preprocess where gh [EMAIL PROTECTED] = points gh [EMAIL PROTECTED] = points gh [EMAIL PROTECTED],_] = points gh (p:o:ints) = init $ walk [o,p] (ints++[p]) -- Unfortunately lists all grow to the left in Haskell. Imagine the -- first argument to be written in reverse order. We are traversing -- the point set clockwise, so that the result does not have to be -- reversed. walk :: [Vertex] - [Vertex] - [Vertex] walk ps [] = ps walk (pM:pL:out) (pF:inp) | isCW pL pM pF/=GT = walk (pF:pM:pL:out) inp | otherwise = walk (pL:out) (pF:inp) walk [EMAIL PROTECTED] (pF:inp) = walk (pF:point) inp walk ps ps' = error $ weird point sets: ++show (length ps)++ and ++ show (length ps')++ long. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GHC 64bit?
On Fri, Feb 13, 2004 at 10:20:43AM +0100, Ketil Malde wrote: [EMAIL PROTECTED] (Donald Bruce Stewart) writes: SimonM may want to comment, but at the moment I think GHC is limited to 4G, but only due to lack of 64bit machines/demand on the developers. There is an IA64 port somewhere, and I suspect other 64-bit architectures as well. Presumably they support 4Gb? I wonder if such an effort is worthwhile. If all pointers are suddenly twice the size then the footprint of a program roughly doubles. Hence to run a program that that needs more than 4GB of RAM on a 32 bit architecture you would need more than 8GB of RAM on a 64 bit machine (and e.g. Apples G5 machines only support 8GB of on-board memory). It would be interesting if Haskell programs could run in the lower 4 GB while running in 64 bit mode. Then you could have large data structures (or memory mapped files) in C land. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Making a spreadsheet with Haskell
On Thu, Feb 12, 2004 at 03:00:29PM +0100, Miren Cob Isasi de Virgala wrote: Hi, I would like to know how can I make a spreadsheet using Haskell (something like Excel, a very-reduced version, of course) Do I need any kind of special library? How can I make the interface so the user can introduce data, select data and so on? You need to have tons of time, choose a GUI library (wxHaskell or gtk2hs, ...) and get going. If you plan to use Haskell within the spreadsheet you might want to look at Vital: http://www.cs.kent.ac.uk/projects/vital/ Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GreenCard (How to Marshell Int64)
On Thu, Dec 11, 2003 at 08:55:25PM -0500, Liwen Huang wrote: Hello: I am using GreenCard to import some C code into Haskell. The code I want to import uses long in a lot of places. I tried to write my own DIS for it and I also write a very simple test program. However, the DIS does not work properly. My program and test result are as following: -- module TLong where import Foreign.GreenCard type Long = Int64 %dis long x = int64 x Just out of curiosity: Are you sure that the long C types on your system actually refer to 64-bit integer. On most platform they refer to 32 bit types. You would need long long to get 64 bit integers. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Announce: Gtk2hs version 0.9.4
gtk2hs - A Haskell binding for Gtk+ version 2 GUI Toolkit. This binding provides a low-level wrapper around the Gtk GUI Toolkit. It covers nearly all widgets and thus provides a stable development API. Recent additions include the SourceView widget contributed by Duncan Coutts. The library is mainly for developers targeting the Gnome platform, otherwise you might be better off with wxHaskell or HToolkit. Highlights: - hand-crafted bindings - automatic memory management - compiles out-of-the box on FreeBSD, (Redhat) Linux, Solaris, X Darwin, MinGW (with the Windows port of Gtk) - compiles with GHC 5.04.X and GHC 6.0.X Available from https://sourceforge.net/projects/gtk2hs/ Please report all problems to [EMAIL PROTECTED] . Enjoy, Axel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Future of Haskell: GUI development
[This is a summary on the GUI discussion at the Haskell workshop/HIM, as announced by Henrik Nilsson] The future development of GUI libraries for Haskell The development of Haskell applications with a graphical user interface has long been complicated by the large number of mostly incomplete libraries. In spring of this year people tried to focus the development effort and came up with the idea of a Common GUI API (CGA for short) which should define an intersection of three major platform APIs (Win32, Gnome/Gtk and Mac OS X) and that addresses the requirements of the platform's style guide (or human interface guidelines). The process of defining this CGA is a major undertaking. The alternative is to use a readily available cross-platform API, like wxWindows, at the expense of creating applications that might violate a platform's style guide and the cannot make use of platform specific functionality. A quick poll at the Haskell workshop revealed that 1/3 of the people thought that the CGA approach is worthwhile, 2/3 thought that the cross-platform approach is adequate. Hence the CGA idea as it stands right now will not be pursued. The discussions at the Haskell Implementor Meeting (HIM) yielded some interesting options (or compromises) that could help to target and unify the development effort of the different library maintainers. In particular we would like to - focus development on wxWindows (in form of wxHaskell) as this cross-platform toolkit should be adequate for most needs - move the programming model of Yahu (Attribute/set/get functionality) into the Haskell library hierarchy so that other (GUI) libraries can use it. - exploit wxWindow's capability to extract platforms specific handles/objects. The goal is to use other libraries (like gtk+hs, gtk2hs, Mocca, etc.) if wxWindows does not provide the needed functionality. - mention the names of the maintainers of each GUI library on the Haskell web site so that programmers can estimate how well-maintained a library is. Update these names regularly. In case people feel inclined to still pursue the CGA idea, one of the following two routes could be taken: - re-expose parts of wxHaskell in a way that forces the user to write applications that look and feel native on different platforms, i.e. a Common GUI API on top of wxWindows - write a GUI Builder application for Haskell; it would surely make Haskell itself more attractive as a rapid development language (such a Builder could also cater for the look-and-feel requirements of the different platforms) Please send any comments or critics to [EMAIL PROTECTED] . All input (and development effort) is welcome. Axel (on behalf of the GUI Task Force). ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Reading/Writing Binary Data in Haskell
On Thu, Jul 10, 2003 at 09:28:38AM +0200, Martin Sjgren wrote:
tor 2003-07-10 klockan 04.56 skrev Glynn Clements:
OTOH, existing implementations (at least GHC and Hugs) currently read
and write 8-bit binary, i.e. characters 0-255 get read and written
as-is and anything else breaks, and changing that would probably
break a fair amount of existing code.
What I would like to see, is a package for converting between different
encodings and character sets. Python has two types for strings, 'str'
(which is just a sequence of octets) and 'unicode'.
Char in Haskell can represent Unicode and bytes are Word8. What is a bad
legacy is that functions like withCString deal with bytes not with Unicode
(or rather UTF8). I use the following as a workaround until there is some
result from the internationalization effort for Haskell
(http://sourceforge.net/projects/haskell-i18n/).
Cheers,
Axel.
{-# OPTIONS -cpp #-}
-- * This module adds CString-like functions that handle UTF8 strings.
-- Furthermore it serves as an impedance matcher for different compiler
-- versions.
module FFI(
with,
nullForeignPtr,
foreignFree,
withUTFString,
withUTFStringLen,
newUTFString,
newUTFStringLen,
peekUTFString,
peekUTFStringLen,
module Foreign,
#if __GLASGOW_HASKELL__=504
module Foreign.C
#else
module CForeign
#endif
) where
import Monad(liftM)
import Char
import LocalData(unsafePerformIO)
#if __GLASGOW_HASKELL__=504
import Data.Bits
import Foreign.C
import qualified Foreign
import Foreign hiding (with)
#else
import Bits
import CForeign
import qualified Foreign
import Foreign hiding (withObject)
#endif
#if __GLASGOW_HASKELL__=504
with :: (Storable a) = a - (Ptr a - IO b) - IO b
with = Foreign.with
#else
with :: (Storable a) = a - (Ptr a - IO b) - IO b
with = Foreign.withObject
#endif
#if __GLASGOW_HASKELL__=600
foreign import ccall unsafe free
free' :: FinalizerPtr a
foreignFree :: Ptr a - FinalizerPtr a
foreignFree _ = free'
nullForeignPtr :: ForeignPtr a
nullForeignPtr = unsafePerformIO $ newForeignPtr nullPtr free'
#else
nullForeignPtr :: ForeignPtr a
nullForeignPtr = unsafePerformIO $ newForeignPtr nullPtr (return ())
foreignFree :: Ptr a - IO ()
foreignFree = free
#endif
-- Define withUTFString to emit UTF-8.
--
withUTFString :: String - (CString - IO a) - IO a
withUTFString hsStr = withCString (toUTF hsStr)
-- Define withUTFStringLen to emit UTF-8.
--
withUTFStringLen :: String - (CStringLen - IO a) - IO a
withUTFStringLen hsStr = withCStringLen (toUTF hsStr)
-- Define newUTFString to emit UTF-8.
--
newUTFString :: String - IO CString
newUTFString = newCString . toUTF
-- Define newUTFStringLen to emit UTF-8.
--
newUTFStringLen :: String - IO CStringLen
newUTFStringLen = newCStringLen . toUTF
-- Define peekUTFString to retrieve UTF-8.
--
peekUTFString :: CString - IO String
peekUTFString strPtr = liftM fromUTF $ peekCString strPtr
-- Define peekUTFStringLen to retrieve UTF-8.
--
peekUTFStringLen :: CStringLen - IO String
peekUTFStringLen strPtr = liftM fromUTF $ peekCStringLen strPtr
-- Convert Unicode characters to UTF-8.
--
toUTF :: String - String
toUTF [] = []
toUTF (x:xs) | ord x=0x007F = x:toUTF xs
| ord x=0x07FF = chr (0xC0 .|. ((ord x `shift` (-6)) ..
0x1F)):
chr (0x80 .|. (ord x .. 0x3F)):
toUTF xs
| otherwise = chr (0xE0 .|. ((ord x `shift` (-12)) ..
0x0F)):
chr (0x80 .|. ((ord x `shift` (-6)) ..
0x3F)):
chr (0x80 .|. (ord x .. 0x3F)):
toUTF xs
-- Convert UTF-8 to Unicode.
--
fromUTF :: String - String
fromUTF [] = []
fromUTF (all@(x:xs)) | ord x=0x7F = x:fromUTF xs
| ord x=0xBF = err
| ord x=0xDF = twoBytes all
| ord x=0xEF = threeBytes all
| otherwise = err
where
twoBytes (x1:x2:xs) = chr (((ord x1 .. 0x1F) `shift` 6) .|.
(ord x2 .. 0x3F)):fromUTF xs
twoBytes _ = error fromUTF: illegal two byte sequence
threeBytes (x1:x2:x3:xs) = chr (((ord x1 .. 0x0F) `shift` 12) .|.
((ord x2 .. 0x3F) `shift` 6) .|.
(ord x3 .. 0x3F)):fromUTF xs
threeBytes _ = error fromUTF: illegal three byte sequence
err = error fromUTF: illegal UTF-8 character
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: GUI for Windows
On Mon, Mar 03, 2003 at 04:21:22PM +0100, [EMAIL PROTECTED] wrote: What User Interface Library would you recommend for use under Windows? I tried FranTk but it crashes as soon as I run the display function (under hugs) and with ghc it won't even compile (I already tinkered with the makefiles, so finally I could make the package, but then the demos won't compile). Any ideas, suggestions? There has been a lot of discussions about defining a common API for GUIs, you get an impression when you read the archives for [EMAIL PROTECTED] HToolkit+Ports+GIO tries to provide functionality that works with Gtk and Win32 as backend. In contrast, there is the more complete gtk2hs binding which uses Gtk 2.0 on Unix, Windows and Mac (more info from me). There is Object I/O wich is specific to Windows and comes with GHC. There are more options like HGL which is more for graphics AFAIK and higher-level approaches like Fudgets (not for Windows). There is no best way right now so it would be wrong to give a definite answer here. Hope this helps, Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Gtk and Object I/O
Hi folks, when I first asked Manuel (author of gtk+hs) if it is ok to make my Gtk binding public, he said something along the lines of I can't keep you from making it public and I am not going to stop gtk+hs because of this. So it seems we are all waiting for the critical user mass that makes our own beloved GUI library (binding) the standard GUI library. For the sake of Haskell, we can only hope that this will actually happen one day. A sad side-effects of this is that most of us GUI developers waste a tremendous amount of time. A paper is just not worth the effort we put in writing the code. More to the point: On Fri, Jan 17, 2003 at 01:34:59AM -0800, Krasimir Angelov wrote: Dear Axel, The Object I/O development is currently frozen. The native Win32 backend works but maybe still have bugs. I still support the library but only for bugfixes. I tried develop GTK backend for Object I/O but I found many difficulties. The main trouble is that the original Clean library are developed only for Windows. I think that Object I/O must be rewriten from scratch to make it more portable. Up to here it sounded quite encouraging. My Gtk2 programs seem to be very stable on Windows and - with careful design of the GUI - applications will behave and look very similar to MFC applications IMHO. Thus I thought that providing a known higher level layer similar to Object I/O would serve the needs of most people who would like to build applications with GUIs. Using the Object I/O techniques could attract those who have used this library before. Of course, this layer on top of Gtk2hs would be new and incompatible, simply because Gtk is so much different from Win32 when it comes to high level GUI objects. For that reason I started my new project HToolkit (http://sourceforge.net/projects/htoolkit). The project maintain both GTK and native Win32 API. The library are separated in two levels. The low level is written in C and has two versions: for Win32 and for GTK. I think that the low level part are mostly completed (about 80-90% of GUI related Win32 and GTK API). ... The last week Daan Leijen started development of Port library. This is very thin Haskell layer over the low level C part. The idea is to make it reusable in other high level GUI libraries. Another library which is possibly portable (sorry)? Could you elaborate Daan? After its completion I will retarget HToolkit to use Port. I hope that for the feature the Port will be ported to Mac platform. I am tempted to claim that a library which tries to use only native high-level API functions is doomed to behave slightly different on the various platforms (I heard that from Java). Furthermore, trying to unify several APIs sounds like taking the intersection which in turn reduces the functionality. I know that exactly this was proposed some years ago as a basic GUI library for Haskell, but I personally doubt that a restricted but portable GUI library serves anybody. I think that for the time being developers which want to use Haskell for development of large scale projects are a trouble. There are nine known GUI libraries: * Gtk+HS * iHaskell * Gtk2HS * HTk * TclHaskell * Fudgets * FranTk * Object I/O * Yahu None of them are capable for large scale development for some reason. I might convert gtk2hs to the hierarchical module system which would break code. After that we only need to add bits here and there. A production-quality version 1.0 will be available this summer (That is the plan anyway). The HTk, TclHaskell, FranTk and Yahu are based on Tcl/Tk. The Tcl/Tk backend are portable but slow. The Gtk+HS, iHaskell, Gtk2HS are based on GTK. The backend is powerful and portable (GTK = 2.0) but I prefer to use just native libraries on different platforms. I guess I should say me too. But being portable is more important for the success of Haskell as a language. The Object I/O is Win32 specific. I think that there is a need of one portable and efficient library. I hope we all agree to this. I post this message to [EMAIL PROTECTED] because I think that development of nice libraries requires agreement of the entire Haskell Community on basic design lines. Good idea. Agreement is nice, but we cannot ask the community to vote for one library and therewith force people to abandon their GUI projects. Each of us can only hope that the very own GUI library becomes the de-facto standard. I am looking for people which are interested in the development of a standard GUI library. Two answers: Me too. and I am.. But how can we proceed from here? I think we should all be more flexible and communicate more openly and earlier. The latter probably would have avoided that I went off and did my own Gtk binding. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Announce: Gtk2hs version 0.9.2
Gtk2hs - A Haskell binding for Gtk+ version 2 Note: This is not gtk+hs. New features in this release: - Tree/List widgets support new features like selections and editing - drawing primitives allow the creation of costom widgets - documentation in DocBook XML automatically created from source (preliminary) - builds with GHC 5.04 - number of smaller additions and fixes The binding is available at: http://gtk2hs.sourceforge.net/ Merry Christmas, Axel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Constant space infinite itteration ... solution?
On Friday, December 13, 2002, at 05:06 PM, Jan Kort wrote: Also ... I've been using the graphics libs with HUGS, but I can't find the equivalent in GHC ... what is the recomended library for writing GUIs in GHC Haskell? And where do I get it? shameless advert You may as well try Gtk2HS which is a binding to Haskell specifically for Gtk version 2. http://gtk2hs.sourceforge.net /shameless advert Or look on the Haskell home page under libraries. Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
hsc2hs does not fail
Hi, for some reason hsc2hs does not fail if the automatically generated program fails to execute. This only happends if I forget to set LD_LIBRARY_PATH before saying make. But it leads to a confusing error messages when an empty .hs file is left and ghc complaints with file name does not match module name. The patch below was done against ghc-5.02.2 on FreeBSD. Cheers, Axel. *** Main.hs~Fri Sep 14 17:15:11 2001 --- Main.hs Tue Apr 16 11:29:28 2002 *** *** 504,510 _ - return () removeFile oProgName ! system (execProgName++ ++outName) removeFile progName when needsH $ writeFile outHName $ --- 504,513 _ - return () removeFile oProgName ! progStatus - system (execProgName++ ++outName) ! case progStatus of ! e@(ExitFailure _) - exitWith e ! _ - return () removeFile progName when needsH $ writeFile outHName $ ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Announce: Gtk2Hs - A Haskell binding for Gtk2
Note: This is not gtk+hs. Gtk2Hs is a rewrite of gtk+hs. It is a binding to the recently released version of Gtk2 with a couple of improvements over gtk+hs: - Automatic memory management. - Nearly complete coverage of widget functions and their signals, including the new text and list widgets. - The convenience wrapper MoGuL (Monad Gui Library) makes it possible to create and lookup named widgets in a type safe way. - Unicode support. - Object-oriented calling convention for widget functions. - Pragmatically uses both c2hs and hsc acquire information about the C files. Automatically generates callback handlers and the widget type hierarchy. - Needs ghc version 5.00 or later, makes use of the --make flag and complies quite quickly (12 mins). I am currently only providing CVS access to the sources. Find them at: https://sourceforge.net/cvs/?group_id=49207 At the moment it does not compile on Solaris due to the 4 parameter restriction of GHC for dynamic callbacks. Feedback is very welcome, a good place to send it to is: [EMAIL PROTECTED] Share and enjoy, Axel. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Weird symbol prevents GHCi from loading my package.
Hi,
I built quite a big library and turned it into a package. It works fine if
use ghc -package gtk2 Blah.hs to compile things. But when I convert all
the libraries to object files as described in the documentation, GHCi
refuses to load the whole machinery:
~/source/mogul/fpDemo:$ ghci -package gtk2 Arabic.hs
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 5.02.2, for Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package std ... linking ... done.
Loading package lang ... linking ... done.
Loading package gtk2 ...
GHCi runtime linker: fatal error: I found a duplicate definition for
symbol
gcc2_compiled.
whilst processing object file
/home/as49/local/lib/gtk2hs/gtk2hs.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
The symbol obviously has nothing to do with GHCi, but I don't have a clue
how it got there and it probably does not matter as long as I don't use
GHCi. Does anybody know where it comes from? My library consists of a huge
bunch of modules, most of them having C calls and callbacks.
Thanks for hints,
Axel.
P.S.: Output from
~/source/mogul/fpDemo:$ ghc-pkg -s gtk2
Package
{name = gtk2,
import_dirs = [/home/as49/local/lib/gtk2hs/hi],
source_dirs = [],
library_dirs =
[/home/as49/local/lib,
/home/as49/local/lib/gtk2hs,
/usr/X11R6/lib,
/usr/local/lib],
hs_libraries = [gtk2hs],
extra_libraries =
[X11,
Xext,
atk,
gdk-x11-1.3,
gdk_pixbuf-1.3,
glib-1.3,
gmodule-1.3,
gobject-1.3,
gtk-x11-1.3,
iconv,
intl,
m,
pango,
pangox],
include_dirs =
[/home/as49/local/include/atk-1.0,
/home/as49/local/include/glib-2.0,
/home/as49/local/include/gtk-2.0,
/home/as49/local/include/pango-1.0,
/home/as49/local/lib/glib-2.0/include,
/home/as49/local/lib/gtk-2.0/include,
/home/as49/local/lib/gtk2hs/hi,
/usr/X11R6/include],
c_includes =
[Container_stub.h,
General_stub.h,
Signal_stub.h,
TreeSelection_stub.h,
gtk/gtk.h],
package_deps = [lang],
extra_ghc_opts = [-fglasgow-exts],
extra_cc_opts = [],
extra_ld_opts = [-u TreeSelection_dwzw, -u TreeSelection_dwzx]}
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: types from ghc - got them!
On Tue, 21 Nov 2000, Bernard James POPE wrote: Obviously there are issues with type variables which are quantified outside the local definition, but careful naming of things should be able to fix this. Hi, For my master thesis I wrote a tool called Typeview (presented at IFL'00) that can display the types of arbitrary expressions (even in programs that are not typecorrect). We chose to append an underscore to every type variable that is not quantified at the examined expression: f :: a - (a, Int) f x = let g y = (x,y) in g 3 In this program the type of the local expression is g:: b - (_a,b). This approach could be used for local type annotations (and thereby replacing the pattern annotations), the :t command and error messages. Of course you have to make sure that _a is not ambiguous. Cheers, Axel. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Extensible data types?
On Mon, 25 Sep 2000, Jose Romildo Malaquias wrote: Is there any Haskell implementation that supports extensible data types, in which new value constructors can be added to a previously declared data type? I think this is what the TREX (extensible records) in Hugs are about. Take a look at http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/exts.html section 7.2. Axel.
Re: Extensible data types?
Is there any Haskell implementation that supports extensible data types, in which new value constructors can be added to a previously declared data type? I think this is what TREX (extensible records) in Hugs are about. Take a look at http://www.cse.ogi.edu/PacSoft/projects/Hugs/pages/hugsman/exts.html The TREX extension enable the addition of new fields to a record type. What I am looking for is a way of extending a data type with new forms of values, and not a given value form with new "fields". Yes, ok. I agree. But couldn't you say something like data Expr = Int Integer | Cte String | Var String | App (Rec ()) and extend the record in the last constructor by a label sum:: (Expr,Expr), pro::(Expr,Expr) etc.? Axel.
RE: Haskell jobs (fwd)
On Wed, 19 Jul 2000, S. Alexander Jacobson wrote: * the codebase needs to be production qualty (handle millions of hits per day) * there should be a network of users (or a support organization) running and supporting the software Hi, I think most of the Haskell libraries found on www.haskell.org have this "experimental" flavour which makes serious application development a risky undertaking. Beyond that you need the always evolving extentions in GHC to write real world applications. The latter will hopefully change with a new Haskell standard, but the libraries will always suffer from being prototype implementations of good ideas. My suggestion is to divide the library section into two distinct areas: One for industrial-strength and complete libraries that will remain stable as long as Haskell lives and one for the rest. This might even motivate people to complete their libraries in order that it might move into the "industrial" section. Greetings, Axel Simon.
Re: Haskell jobs (fwd)
On Wed, 19 Jul 2000, George Russell wrote: What you need for that is SUPPORT, for example, to ensure that things still work when Haskell changes. This is difficult to guarantee in an academic environment. But the success of a language will depend on the quality of the libraries, too. If we cannot figure out a way to supply Haskell with working libraries, the language itself won't reach outside the academic world. It even takes a long time to figure out what a specific library is up to and if it's complete etc. Even if the academic staff can only give marginal support for their libraries due to their lack of time, it still might be sensible to mark libraries as "complete" (Is this a candidate for our application?) or even "Haskell 98 compliant" (Will the library compile with future versions of GHC/HBC?). Cheers, Axel.
underscore does not start a varid
Hi, my program uses (data-) variables beginning with _. This is legal Haskell 98 and Hugs accepts it. GHC 4.06 thinks these are constructors. Cheers, Axel.
hsc crashes when compiling GHC 4.06 sources
Hi, I downloaded the sources from GHC 4.06, made the shallow tree, added a build.mk in mk/ with -H80, later with -H80 -O2, made ./configure in ghc/ and ./configure in the main tree, (copied both .y files because happy doesn't work on links done with lndir -- it's only NT), said make boot and then make all () ===fptools== Recursively making `all' in std ... PWD = /ghc/ghc-4.06/ghc/lib ==fptools== make all --unix --no-print-directory -r; in /ghc/ghc-4.06/ghc/lib/std rm -f PrelBase.o ; if [ ! -d PrelBase ]; then mkdir PrelBase; else find PrelBase -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../driver/ghc-inplace -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -fcompiling-prelude -static -keep-hc-files-too -keep-s-files-too -H32m -K32m -c PrelBase.lhs -o PrelBase.o -osuf o (acutally I wonder where my -H80m and the -O2 is). A message box appears and tells me about a read action from the statement at 0x62eaaece which attempted to read from 0x0cfc2603, Visual C says it's in HSPREL.DLL. I don't know if this is of any use: EAX = 0001 EBX = 6755A250 ECX = 035C20A8 EDX = 0CFC25FF ESI = 675598DC EDI = 035C20B8 EIP = 62EAAECE ESP = 029CF748 EBP = 035C1F74 EFL = 0293 CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 0038 GS = OV=0 UP=0 EI=1 PL=1 ZR=0 AC=1 PE=0 CY=1 The statement is a 62EAAECE mov eax,dword ptr [edx+eax*4] I am using the binary distribution of ghc 4.05, Windows NT SP5 and SP6a. If there is anything I can do to produce more information or an easier (safer) way to build ghc on my own, let me know. Thanks, Axel.
No crash anymore.
Hi again, please forget that about the crashing hsc. I've reinstalled ghc-4.045 (it still calls itself 4.05) and it works as good as before. Now I've deleted everthing else, checked out the current cvs tree, made the shallow tree current/, did autoconf and ./configure in /current/ghc and the same in current/. Now I typed make boot (still cygwin make) and got the following: ==fptools== make boot --unix --no-print-directory -r; in /ghc/current/ghc/rts if [ ! -f gmp/configure ] ; then ( cd gmp autoconf ); fi; if [ ! -f gmp/mpn/configure ] ; then ( cd gmp/mpn autoconf ); fi; if [ ! -f gmp/mpz/configure ] ; then ( cd gmp/mpz autoconf ); fi; if [ ! -f gmp/mpz/tests/configure ] ; then ( cd gmp/mpz/tests autoconf ); fi; cd gmp ./configure --host=i386-unknown-cygwin32 ./configure: 4: Syntax error: word unexpected (expecting ")") make[2]: *** [boot] Error 2 make[1]: *** [boot] Error 1 make: *** [boot] Error 1 which is obviously at the same place where this other error about gmp was. The lines 4 to 6 in current/ghc/rts/gmp/configure are AC_INIT(Makefile.in) AC_CONFIG_SUBDIRS(mpn mpz) which don't look too bad. I'm stuck again. Any advice appreciated, and yes, I'm using autoconf 2.13 with a patch from Sven Panne. Axel.
Programming Win32
Hi all, I tried to write a Win32 program in with GHC 4.05 but I am stumbeling over the definition type WNDCLASS = (ClassStyle, -- style HINSTANCE, -- hInstance MbHICON, -- hIcon MbHCURSOR, -- hCursor MbHBRUSH,-- hbrBackground MbLPCSTR,-- lpszMenuName ClassName) -- lpszClassName which looks fine if I'd knew where to get hInstance. main doesn't give it to me. Can specify something like winMain hInstance ... = as my main program entry? Or a more sensible question: Is there any userguide on how to use the Win32 library? Cheers, Axel.
Installation Problem on NT
Hi, I installed the GHC 2.10 binary bundle on my Win NT system. Both options (install and in-place) come up with the following problem (where main is the trivial program from the install.html file): bash-2.01$ ghc -o hello Main.hs ( 1037) Exception: STATUS_ACCESS_VIOLATION ( 1037) Dumping stack trace to .core Doing the same in verbose mode reveals the following error in the compiler: ghc:compile:Output file Main.o doesn't exist ghc:compile:Interface file Main.hi doesn't exist ghc:recompile:Input file Main.hs newer than Main.o Haskell compiler: /Programme/fptools/lib/i386-unknown-cygwin32/ghc-2.10/hsc ,-W ,/tmp/ghc1 000.cpp -fignore-interface-pragmas -fomit-interface-pragmas -fsimplify [ -fflo at-lets-exposing-whnf -ffloat-primops-ok -fcase-of-case -fdo-case-elim -freuse-c on -fpedantic-bottoms -fsimpl-uf-use-threshold3 -fmax-simplifier-iterations4 ] -fwarn-overlapping-patterns -fwarn-missing-methods -fwarn-duplicate-exports -h imap=.%.hi:/Programme/fptools/lib/i386-unknown-cygwin32/ghc-2.10/imports%.hi - v -hifile=/tmp/ghc1000.hi -C=/tmp/ghc1000.hc +RTS -H600 -K100 main/CmdLineOpts.lhs:486: Non-exhaustive patterns in function `simpl_sep' Command exited with non-zero status 1 What went wrong? Perl and Cygwin obviously work and my PATH should be ok as well. Thank you for your help, Axel Simon.
