Re: Is GHC 6.8.2 on solaris 32 bits or 64 bits
Simon Marlow wrote: hsing-chou chen wrote: Thank you for porting GHC 6.8.2 to solaris, I am assigned a job to make sure GHC run 64 bits on solaris. Is your solaris port 64 bits. Or it only 32 BITS. I know 32 bits GHC can still run on 64 bits solaris. However company want to run really 64 bits GHC on solaris. Thanks a lot if you You want to look at the porting instructions: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet). This won't be easy, you'll need to know details of the processor architecture, and be prepared to learn about GHC internals. But it'll be fun, if you like that sort of thing :) That's too much for me. I'll wait until ghc-6.8 (or ghc-6.10) can be bootstrapped from C-sources. One (maybe minor) problem under Solaris (and MacOS I think) is that already configure decides by default to be under i386, i.e. in 32bit mode (through arch or uname -p). Only extending the call to gcc with -m64 will create 64Bit code. You have done it under Linux. Maybe you find an easy path from 32Bit to 64Bit under Linux that one may also try under Solaris and Macs. Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
1st call for participation AFP 2008, The Netherlands
1ST CALL FOR PARTICIPATION 6TH INTERNATIONAL SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING 2008 (AFP ’08) RADBOUD UNIVERSITY NIJMEGEN AND UTRECHT UNIVERSITY, THE NETHERLANDS MAY 19-24, 2008 http://www.st.cs.ru.nl/AFP_TFP_2008/ AFP is a series of international summer schools which aims to bring computer scientists, in particular young researchers and programmers, up to date with the latest advances in practical advanced functional programming. Functional programming emphasizes the evaluation of expressions rather than the execution of commands. We focus on functional programming techniques in “programming in the real world” and bridge the gap between results presented at programming conferences and material from textbooks on functional programming. In this school you will receive in depth lectures about advanced functional programming techniques, taught by experts in the field. Lectures are accompanied by practical problems to be solved by the students at the school. AFP 2008 is hosted by the Radboud University Nijmegen, and Utrecht University, The Netherlands, and will be held in the rural setting of Center Parcs “Het Heijderbos”, Heijen (in the vicinity of Nijmegen), The Netherlands. AFP 2008 is co-located with the 9th Symposium on Trends in Functional Programming (TFP’08), which is held after AFP’08. PROGRAM INFORMATION The following speakers will give the lectures (in alphabetic order): Umut Acar (Toyota Technological Institute, University of Chicago, US) Richard Bird (University of Oxford, UK) Olivier Danvy (University of Aarhus, DK) Johan Jeuring (Utrecht University, NL) Mark Jones (Portland State University, US) Ulf Norell (Chalmers University, SE) Simon Peyton Jones (Microsoft Research, UK) Rinus Plasmeijer (Radboud University Nijmegen, NL) During the summer school, all participants receive printed lecture notes. Participants are expected to have a notebook, in order to be able to participate with the practical problems. After the summer school, all lecture notes will be revised, reviewed, and published in the LNCS series of Springer. All registered participants receive a copy of these lecture notes. VENUE INFORMATION AFP (and TFP) is held in The Netherlands, at Center Parcs “Het Heijderbos” which is a holiday resort in the woodlands near the city of Nijmegen. We accomodate participants in DeLuxe Cottages, each of which has three separate bed-rooms, shared bathroom, toilet, kitchen, and terrace. Cottages will be shared by three participants. If you wish to reduce costs, you can choose to share a bedroom. The summer school and symposium will take place in the business center of the venue. Breakfast, lunch and diner is included within the limits of the venue. The resort features, amongst others, a sub-tropical swimming pool (free for participants), restaurants, shops, water sports lake, midget golf court, squash court, and outdoor and indoor tennis courts. Nijmegen is considered to be the oldest city of the Netherlands, being approximately 2000 years old. Nijmegen is located at the east border of the Netherlands, near Germany. Nijmegen can be reached easily from several airports such as Schiphol airport, Eindhoven airport, and Düsseldorf airport, as well as by train and car. Conveniently close to Center Parcs “Het Heijderbos” you will find airport Weeze in Germany. The venue Center Parcs “Het Heijderbos” can be reached from Nijmegen by train to Boxmeer (25 minutes). From there you will need to order a taxi. The venue can also be reached by car: parking is free for participants of AFP and TFP. SUMMER SCHOOL FEES AFP 2008 includes accommodation, conference, breakfast – lunch – diner, speakers, and proceedings costs. The early registration fee is € 995; the late registration fee is € 1095. Please note that if you require financial support, you can apply for a grant (see below). GRANT INFORMATION We have taken great care to reduce the registration cost as much as possible. We can grant a subsidy for a limited number of PhD student participants for whom the costs are still too high. In order to apply for this subsidy, you need to send (by surface mail or e-mail) a request for subsidy which contains your personal information, affiliation, a description of your current status, project description, a motivation why you should receive the grant, and a recommendation from your PhD supervisor. This letter should arrive before april 7 2008 to: Rinus Plasmeijer Radboud University Nijmegen Toernooiveld 1 6525ED Nijmegen [EMAIL PROTECTED] You will receive a notification whether your request has been granted before april 14 2008. REGISTRATION INFORMATION Early registration opens at march 1 2008. Late registration opens at april 15 2008. Registration closes at may 5 2008. We can not guarantee accommodation in case you wish to register later than may 5 2008. IMPORTANT DATES (ALL 2008) Early Registration Opens: March 1 Early Registration Deadline: April 14 Late Registration Opens: April 15
Re: Bootstrapping for Leopard
Manuel M T Chakravarty wrote: Things are complicated because - on Cygwin, pwd gives you /cygdrive/c/... - on MSYS, pwd gives you /c/... (remember we still support MSYS), and we want c:/... So we used to use cygpath on cygwin, and some horrible sed command on MSYS, IIRC. It was a mess, and frequently went wrong. Sure there are other ways to do it, but I think at the time it seemed simpler to write a Haskell program. In hindsight, probably a C program (compiled using mingw gcc) would be better for bootstrapping. A shell script would be problematic for the reasons above, I'm guessing. I understand that this is a difficult issues, but as it is booting from HC files and hence porting is simply broken. So, I wonder what the way forward is... Porting is simply broken for various reasons at the moment - in particular the switch to Cabal for building the libraries broke it. We knew this at the time, but felt it was more important to make the switch now and fix bootstrapping later. For pwd, I imagine the best way forward is to use a C program, I don't think there are any deep issues there. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC lazy eval optimization bug
Thank you for the explanation. Inlining does explain the behavior I was seeing, and -fno-state-hack does make the program behave the way I'd expect. I would like to humbly submit that perhaps this optimization should be off by default. It seems to me that any compiler optimization which can potentially increase your program's runtime by an order of complexity is dangerous. Also, while the Haskell Report doesn't seem to specify anything about lazy evaluation behavior, it seems to me that in order to program in Haskell, assuming that a computation assigned to a variable won't be recomputed multiple times is almost as necessary an assumption as assuming that the compiler will optimize away tail recursion. For instance GHC FAQ entry 7.2 implicitly assumes this is true: http://haskell.org/haskellwiki/GHC:FAQ#Does_GHC_do_common_subexpression_elimination.3F In my real program where I ran into this problem it took me quite a while to figure out why my program's performance wasn't making any sense, and why seemingly irrelevant changes to my code made the performance problem go away. Thank you, Adam On Feb 3, 2008, at 3:18 PM, Stefan O'Rear wrote: On Sun, Feb 03, 2008 at 02:37:42PM -0500, Adam P Jenkins wrote: The haskell program below demonstrates an optimization bug with the GHC compiler. I have tried this with ghc 6.8.1 on my MacBook Pro and on a Linux i686 machine. This email should build as a literate haskell program. Build the program as While this may be unfortunate, it is a consequence of document behavior; thus I would not consider it a bug per-se. Try with -fno-state-hack; the documentation for this option, I believe, should explain what is going on. (Hint: IO a ~ State# - (State#, a)) Stefan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Is GHC 6.8.2 on solaris 32 bits or 64 bits
Christian Maeder wrote: Simon Marlow wrote: hsing-chou chen wrote: Thank you for porting GHC 6.8.2 to solaris, I am assigned a job to make sure GHC run 64 bits on solaris. Is your solaris port 64 bits. Or it only 32 BITS. I know 32 bits GHC can still run on 64 bits solaris. However company want to run really 64 bits GHC on solaris. Thanks a lot if you You want to look at the porting instructions: http://hackage.haskell.org/trac/ghc/wiki/Building/Porting Start from GHC 6.6.1 (6.8.2 doesn't bootstrap from .hc files yet). This won't be easy, you'll need to know details of the processor architecture, and be prepared to learn about GHC internals. But it'll be fun, if you like that sort of thing :) That's too much for me. I'll wait until ghc-6.8 (or ghc-6.10) can be bootstrapped from C-sources. Waiting for 6.8 or 6.10 to be bootstrappable won't actually help with the porting you need to do to get a 64-bit Sparc port working. You'll still need to modify parts of the system that deal with architecture- and platform-specific things. If I get libffi integrated (hopefully for 6.10) then this will reduce the porting effort, as the clever libffi folks will already have 64-bit Sparc support. However, we'll likely be dropping the C backend in 6.10, so the only way to get good performance will be to write a native code generator. Hopefully by then we'll have refactored the NCG to make it easier to add new ones, though. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Bootstrapping for Leopard
On Mon, Feb 04, 2008 at 12:18:01PM +, Simon Marlow wrote: Porting is simply broken for various reasons at the moment - in particular the switch to Cabal for building the libraries broke it. We knew this at the time, but felt it was more important to make the switch now and fix bootstrapping later. Be prepared: I'll send some comments and (probably silly) questions on cvs-ghc@ in a few minutes ;-) For pwd, I imagine the best way forward is to use a C program, I don't think there are any deep issues there. Unless some windows people have the time to step in and help make it work with simple shell stuff, some C helpers would be just fine. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
