Re: idea to allow ghci to use a different libs list
On Fri, 2005-12-09 at 15:04 +0100, Sven Panne wrote: Am Mittwoch, 7. Dezember 2005 12:21 schrieb Duncan Coutts: On Fri, 2005-12-02 at 11:06 +, Simon Marlow wrote: On 30 November 2005 12:29, Duncan Coutts wrote: Attached is a simple code change to allow packages to specify a different list of extra libraries to link with when using the ghci and dlopen/LoadLibrary compared to when using the native system linker. Yes to the idea in principle; please go ahead and complete the patch. Ok, attached is the full patch. It has to be in two parts since the darcs repos for ghc and the libraries are separate. I've briefly tested the change. I built Gtk2Hs with ghc-6.5 with the patch. I modified (and registered) the gtk.package.conf file so that it specified: extra-libraries: gtk-x11-2.0, [...snip...], pthread extra-ghci-libraries: gtk-x11-2.0, [...snip...] [...] Hmmm, I haven't followed the thread too closely, but aren't we just hacking around the real cause here? Wouldn't it be better to teach GHCi's linker about the ld scripts, at least in a very basic form? My concern is that the proposed hack puts additional burden onto the autoconf magic of package developers and makes doing the right thing portably quite tricky, I guess... The other magic you'd have to teach GHCi's linker about is the case where the libfoo.a tells the runtime loader to use not foo.so but something slightly different like foo-v1.so. This is the problem we have with Gtk+ on Win32. The libgtk-win32-2.0.a file instructs the windows runtime loader to use libgtk-win32-2.0-0.dll. Obviously that works fine when ghc uses the system linker. However it fails when GHCi uses it's own linker. Another way of solving this would be if the GHC packages loaded by GHCi were native system dynamic libraries. Then the ordinary system linker would be used to create them and they would be linked against the right runtime .so/.dll files. That would also deal with the case of GNU ld scripts. However until we get packages as native dynamic libs we could still do with a solution. I appreciate that it is not an ideal solution. I do not expect it to be used very widely or for very long (basically until we get native dynamic libs). If we leave it as it is developers still have to do autoconf magic to do the workarounds. They've got to strip out libraries that are gnu ld scripts and just pray that some other lib implicitly depends upon the one they removed from the libs list. And sometime it's impossible to workaround (as in the case of Gtk2Hs on Win32). Duncan ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: recommended build system
The nightly binary snapshots for x86/Linux are currently hard-wired to use gcc-3.4.3, because I occasionally change gcc versions to make sure things are still working. I'll change it back to gcc. To workaround it you can add '-pgmc gcc' to the command line. Cheers, Simon On 09 December 2005 03:26, Frederik Eaton wrote: Does this depend on a certain version of gcc? $ ghc -M --make Matrix.hs -o matrix Chasing modules from: Matrix.hs [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) ghc-6.5.20051207: could not execute: gcc-3.4.3 I'm wondering why it is trying to execute something which isn't in my path... Frederik On Mon, Dec 05, 2005 at 10:51:19AM -, Simon Peyton-Jones wrote: Simon fixed this recently. The GHC HEAD build will not re-link with --make if none of the object files have changed. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@haskell.org Subject: recommended build system Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because ghc --make and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik ___ 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 ___ 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: recommended build system
Would I be the only user of the nightly binary snapshots? Frederik On Fri, Dec 09, 2005 at 09:23:16AM -, Simon Marlow wrote: The nightly binary snapshots for x86/Linux are currently hard-wired to use gcc-3.4.3, because I occasionally change gcc versions to make sure things are still working. I'll change it back to gcc. To workaround it you can add '-pgmc gcc' to the command line. Cheers, Simon On 09 December 2005 03:26, Frederik Eaton wrote: Does this depend on a certain version of gcc? $ ghc -M --make Matrix.hs -o matrix Chasing modules from: Matrix.hs [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) ghc-6.5.20051207: could not execute: gcc-3.4.3 I'm wondering why it is trying to execute something which isn't in my path... Frederik On Mon, Dec 05, 2005 at 10:51:19AM -, Simon Peyton-Jones wrote: Simon fixed this recently. The GHC HEAD build will not re-link with --make if none of the object files have changed. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@haskell.org Subject: recommended build system Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because ghc --make and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik ___ 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 ___ 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: recommended build system
This doesn't affect the source snapshots, only the Linux/x86 binaries. I think there are more people using the sources and the Linux/x86_64 binaries. Cheers, Simon On 09 December 2005 10:26, Frederik Eaton wrote: Would I be the only user of the nightly binary snapshots? Frederik On Fri, Dec 09, 2005 at 09:23:16AM -, Simon Marlow wrote: The nightly binary snapshots for x86/Linux are currently hard-wired to use gcc-3.4.3, because I occasionally change gcc versions to make sure things are still working. I'll change it back to gcc. To workaround it you can add '-pgmc gcc' to the command line. Cheers, Simon On 09 December 2005 03:26, Frederik Eaton wrote: Does this depend on a certain version of gcc? $ ghc -M --make Matrix.hs -o matrix Chasing modules from: Matrix.hs [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) ghc-6.5.20051207: could not execute: gcc-3.4.3 I'm wondering why it is trying to execute something which isn't in my path... Frederik On Mon, Dec 05, 2005 at 10:51:19AM -, Simon Peyton-Jones wrote: Simon fixed this recently. The GHC HEAD build will not re-link with --make if none of the object files have changed. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@haskell.org Subject: recommended build system Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because ghc --make and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik ___ 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 ___ 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: Optimizations for mutable structures?
Simon Marlow [EMAIL PROTECTED] writes: In the general case, for some arbitrary actions between the write and the read (excluding another write of course), there is no guarantee that the IORef remains unmodified. This is an analysis that's performed all the time in C compilers, it's quite straightforward to do a good approximation. One simple algorithm is: a store can be forwarded to a matching read as long as there are no intervening writes that may alias, or function calls. C does this and C has threads, so what's the difference? There is a big difference between C variables and IORefs. For one thing, a C variable can have scope local to a procedure. If so, then the suggested transformation is entirely valid even in the presence of threads, because no other thread is permitted access to the local variable. M[fp+offset(x)] - v ... w - M[fp+offset(x)] === M[fp+offset(x)] - v ... w - v Global variables are more tricky, but I guess it is probably common to permit the elimination of the 'read' there as well, even though technically this is unsafe in the presence of threads. My guess is that this behaviour is the cause of a lot of thread unsafeness in common C libraries however. M[address(x)] - v ... w - M[address(x)] === M[address(x)] - v ... w - v Haskell has neither local nor global variables in the same sense as C. IORefs more closely resemble C pointers. A pointer has indeterminate lifetime and scope. It can be passed around from procedure to procedure, and from thread to thread. There can be aliases to the same memory location in multiple other contexts. If I'm writing a hardware driver, the pointer address might be memory-mapped to a device register, in which case writing to that address and immediately reading back from it may not be an identity. I've certainly dealt with devices where the same hardware port when written to, expects control data, but when read from delivers status data. So here: M[M[x]] - v ... w - M[M[x]] it would be totally incorrect for the compiler to eliminate the read. Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New bug tracker: Trac
Am Dienstag, 6. Dezember 2005 17:42 schrieb Simon Marlow: [...] Developers with an account on cvs.haskell.org: please add yourselves as users on the Trac, so I can give out permissions to edit tickets. You create a user like this: - log in to cvs.haskell.org - htpasswd /srv/trac/ghc/trac.htpasswd username - type your password when prompted - let me know when you've done this Done! Cheers, S. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recommended build system
$ ghc -pgmc gcc --make Matrix.hs -o matrix Chasing modules from: Matrix.hs [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) ghc-6.5.20051208: could not execute: gcc-3.4.3 Hard-coding things is ... not ... nice ... Frederik On Fri, Dec 09, 2005 at 09:23:16AM -, Simon Marlow wrote: The nightly binary snapshots for x86/Linux are currently hard-wired to use gcc-3.4.3, because I occasionally change gcc versions to make sure things are still working. I'll change it back to gcc. To workaround it you can add '-pgmc gcc' to the command line. Cheers, Simon On 09 December 2005 03:26, Frederik Eaton wrote: Does this depend on a certain version of gcc? $ ghc -M --make Matrix.hs -o matrix Chasing modules from: Matrix.hs [1 of 2] Compiling Fu.Prepose ( Fu/Prepose.hs, Fu/Prepose.o ) ghc-6.5.20051207: could not execute: gcc-3.4.3 I'm wondering why it is trying to execute something which isn't in my path... Frederik On Mon, Dec 05, 2005 at 10:51:19AM -, Simon Peyton-Jones wrote: Simon fixed this recently. The GHC HEAD build will not re-link with --make if none of the object files have changed. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- [EMAIL PROTECTED] On Behalf Of Frederik Eaton Sent: 04 December 2005 00:46 To: glasgow-haskell-users@haskell.org Subject: recommended build system Hi all, I'm looking for a build system for my projects which will correctly handle all of ghc's dependencies. I.e. every time I ask it to rebuild an output file, it will only do the minimum amount of compilation necessary. This is important to me because ghc --make and cabal currently (AFAICT) will always relink an executable even when it is not necessary to do so; thus if I have a project with a bunch of libraries and executables, the cost of making a small modification and recompiling is very high, and it becomes hard to maintain focus on my projects after the initial design phase. I've just been playing around with GNU coreutils and was impressed with how well the build system works, and how fast the recompilation goes. Anyway, the system that darcs uses seems to work pretty well, should I copy that, or do people recommend other alternatives? Frederik ___ 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 ___ 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
[Haskell] Call for papers -- FOAL 2006: Foundations of Aspect-Oriented Languages
FOAL: Foundations of Aspect-Oriented Languages --- CALL FOR PAPERS --- Submission deadline: 25 January 2006 A one day workshop affiliated with AOSD 2006 in Bonn, Germany, on March 21, 2006. Themes and Goals FOAL is a forum for research in foundations of aspect-oriented programming languages. Areas of interest include but are not limited to: - Semantics of aspect-oriented languages - Specification and verification for such languages - Type systems - Static analysis - Theory of testing - Theory of aspect composition - Theory of aspect translation (compilation) and rewriting The workshop aims to foster work in foundations, including formal studies, promote the exchange of ideas, and encourage workers in the semantics and formal methods communities to do research in the area of aspect-oriented programming languages. All theoretical and foundational studies of this topic are welcome. The goals of FOAL are to: - Make progress on the foundations of aspect-oriented programming languages. - Exchange ideas about semantics and formal methods for aspect-oriented programming languages. - Foster interest within the programming language theory and types communities in aspect-oriented programming languages. - Foster interest within the formal methods community in aspect-oriented programming and the problems of reasoning about aspect-oriented programs. Workshop Format The planned workshop format is primarily presentation of papers and group discussion. Talks will come in three categories: long (30 minutes plus 15 minutes of discussion), short (20 minutes plus 5 minutes of discussion) and very short (7 minutes plus 3 minutes of discussion). The very short talks will allow for short presentations of topics for which results are not yet available, perhaps for researchers who are seeking feedback on ideas or seek collaborations. We also plan to ensure sufficient time for discussion of each presentation by limiting the number of long talks and having only a few short talks. Submissions Invitation to the workshop will be based on papers selected by the program committee; those wishing to attend but not having a paper to submit should contact the organizers directly to see if there is sufficient space in the workshop. FOAL solicits full-length, short, and very short papers on all areas of formal foundations of AOP languages. Submissions will be read by the program committee and designated reviewers. Papers will be selected for long, short, and very short presentation at the workshop based on their length, scientific merit, innovation, readability, and relevance. Papers previously published or already being reviewed by another conference are not eligible. Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than their paper length would otherwise command. We will limit the length of paper presentations and the number of papers presented to make sure that there is enough time for discussion. Papers presented at the workshop will be included in a technical report (from Iowa State University). Authors will retain their own copyright to the papers. Publication of papers at other venues will thus remain possible. We will also investigate having a special issue of a journal for revisions of selected papers after the workshop. Authors should note the following details: - Submissions are due no later than 23:00 GMT, Friday, 25 January, 2006. This is a firm deadline. - Authors must indicate whether they wish to be considered for a long, short, or very short presentation. - Papers for long presentations must not exceed 10 pages in length; those for short presentations must not exceed 5 pages in length, and those for very short presentations must not exceed 3 pages in length. - Some papers may not be selected for presentation, and some may be selected for presentation in shorter talks than requested. - We encourage use of the ACM Conference format for submissions, as this will be required for accepted papers. You must add page numbers (which are not part of the standard format) to your submissions, to make adding comments easier. - Submissions are to be sent as PDF (preferred) or postscript attachments in an email to Curtis Clifton, clifton -at- rose-hulman -dot- edu. We will notify the corresponding author of papers that are selected for presentation at the workshop by 10 February 2006. The early registration deadline for AOSD will be 17 February 2006. FOAL attendees must be registered for AOSD. Final versions of papers for the proceedings will be due on 7 March 2006. Important Dates * Submission Deadline 23:00 GMT, 25 January 2006 * Notification of Acceptance 10 February 2006 * AOSD Early Registration Deadline 17 February 2006 * Final Versions of Papers due 7 March 2006 * Workshop 21 March 2006 Program Committee * Mira Mezini (PC Chair) - Darmstadt University of Technology * Jonathan Aldrich -
Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mo
On Thu, 8 Dec 2005, Branimir Maksimovic wrote: From: Henning Thielemann [EMAIL PROTECTED] To: Branimir Maksimovic [EMAIL PROTECTED] CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mode Date: Thu, 8 Dec 2005 18:38:45 +0100 (MET) On Thu, 8 Dec 2005, Branimir Maksimovic wrote: program performs search replace on a String http://www.haskell.org/pipermail/haskell-cafe/2005-April/009692.html This is nice and ellegant but example search replace program runs more then 50% faster with my implementation. Is this intended: *SearchReplace searchr ha lo hha hha ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] STM reference?
GHC now has a Wiki http://cvs.haskell.org/trac/ghc/wiki, so I've started a new page to give pointers to material on concurrent programming using GHC. (The link is near the bottom.) Please add to it. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | Bulat Ziganshin | Sent: 09 December 2005 07:07 | To: Scherrer, Chad | Cc: haskell-cafe@haskell.org | Subject: Re: [Haskell-cafe] STM reference? | | Hello Chad, | | Friday, December 09, 2005, 3:09:29 AM, you wrote: | | SC Can anyone suggest some references to learn how to program using GHC | SC with threads? I've read a little bit about STM, but it's still pretty | SC mysterious to me. Is this the best approach to take? I've never used | SC threads in any language, but monads are fairly comfortable for me. | | STM is just additional instrument, you can completely avoid it (as we | had do until 6.4 release). Below is a list of papers related to | imperative programming in Haskell. first contains pragmatic | introduction in this world, including all concurrency stuffs, second | is about an real high-concurrency application designed by GHC team. | other papers is of more theoretical (and more strict) character | | Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language | calls in Haskell | [http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/markto berdorf.ps.gz] | Writing High-Performance Server Applications in Haskell, Case Study: A Haskell Web Server, | [http://www.haskell.org/~simonmar/papers/web-server.ps.gz] | [http://www.haskell.org/ghc/docs/papers/concurrent-haskell.ps.gz] | [http://www.haskell.org/~simonmar/papers/conc-ffi.pdf] | The Concurrent Haskell Foreign Function Interface | [http://www.haskell.org/ghc/docs/papers/threads.ps.gz] | Asynchronous Exceptions in Haskell [http://www.haskell.org/~simonmar/papers/async.ps.gz] | [http://research.microsoft.com/~simonpj/papers/stm/stm.pdf] | [http://www.haskell.org/ghc/docs/papers/except_ps.gz] | Imperative Functional Programming [http://www.haskell.org/ghc/docs/papers/imperative.ps.gz] | | | | -- | Best regards, | Bulatmailto:[EMAIL PROTECTED] | | | | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-conflicts] how to nicely implement phantom type coersion?
On 12/8/05, David Roundy [EMAIL PROTECTED] wrote: So is there some other approach that I can use for easily coercing phantom types based on runtime checks? Any suggestions? None here. Since H-M uses type unification to do type inference, you can't auto-create a program based on the inferred types around it. -- Taral [EMAIL PROTECTED] Computer science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how to nicely implement phantom type coersion?
On Thu, Dec 08, 2005 at 05:31:37PM -0500, Thomas Jger wrote: Since you're already using GADTs, why not also use them to witness type equality: Thanks for the suggestion! This just illustrates the rule that when using GADTs the solution to every problem is to introduce another GADT. It amazes me how many times that rule has proven true, and yet I *still* don't think to define a new GADT for every problem I run into... -- David Roundy http://www.darcs.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't Haskell catch up with Clean's uniqueness typing?
On Fri, Dec 09, 2005 at 05:49:15AM +0100, [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 09:59:25PM +0100, [EMAIL PROTECTED] wrote: p.s.: Strangely, Tomasz's reply again appears as being sent from my address in the archive. Anyone knows why? Maybe mailman is somehow confused by this weird address: xoxy = haskell-cafe [EMAIL PROTECTED] ? Relevant headers of this message: Received: from gourmet.spamgourmet.com (gourmet.spamgourmet.com [216.218.230.146]) by www.haskell.org (Postfix) with ESMTP id 3B4EF32413E for haskell-cafe@haskell.org; Thu, 8 Dec 2005 23:53:35 -0500 (EST) Received: from gourmet.spamgourmet.com (localhost [127.0.0.1]) by gourmet.spamgourmet.com (8.12.11/8.12.11) with ESMTP id jB94rVkT016328 for haskell-cafe@haskell.org; Thu, 8 Dec 2005 20:53:31 -0800 Received: (from [EMAIL PROTECTED]) by gourmet.spamgourmet.com (8.12.11/8.12.11/Submit) id jB94rTN4016311 for haskell-cafe@haskell.org; Thu, 8 Dec 2005 20:53:29 -0800 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by gourmet.spamgourmet.com (8.12.11/8.12.11) with ESMTP id jB94r4PP015879 for [EMAIL PROTECTED]; ^^ Thu, 8 Dec 2005 20:53:04 -0800 Looks like gourmet.spamgourmet.com resends to haskell-cafe@haskell.org messages addressed to [EMAIL PROTECTED] as if they were send from [EMAIL PROTECTED] As a result, messages are send to the list twice with different From: and To: headers, but with the same Message-Id (I see both but many programs will hide one of them). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] preffered 'map'
Benjamin Franksen [EMAIL PROTECTED] writes: import Data.Map as Map but now anywhere when I want ot use map it complains for name clashes, so I have to specifiy Prelude.map all the time. Is there a way to specify that i mean Prelude not Data 'map' (but not fqn) I use Hugs, 'cause error messages are more understandable. import Data.Map as Map import Prelude hiding (map) import qualified Prelude (map) better do: import qualified Data.Map as Map since: import A as B x, y, B.x, B.y import A as B(x) x, B.x import qualified A as B B.x, B.y (cf http://www.haskell.org/onlinereport/modules.html) i've been hit by this too. maybe the documentation at beginning of Map.hs should be changed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] preffered 'map'
On Fri, 9 Dec 2005, raptor wrote: hi, I imported : import Data.Map as Map but now anywhere when I want ot use map it complains for name clashes, so I have to specifiy Prelude.map all the time. If at all, better use List.map instead of Prelude.map ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapOfmap composition
raptor wrote: And second why when I try do do function composition i.e. : newf = map . f But this works : newf x = map (f x) Does f has constraints? It should work with a type signature. HTH Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monad applied in Java
My apology to those who don't care about Java. Please trash this note. I recently published two open source Java projects that are based on the Monad computation model learned from Haskell community. 1. A port for Parsec. This library is called Jparsec. It implements monadic parser combinator in Java. Not nearly as concise and clean because of the limitation of the Java language, but it implements the same idea. And it looks like the only monadic parser combinator lib in Java so far, according to my google homework. ;--) url: http://docs.codehaus.org/display/JPARSEC/home 2. A light-weight Dependency Injection container that's built around the Monad model. If you see sequence id=mybean bean var=a1 class=A1/ bean var=a2 class=A2/ method class=X name=create args=$a1,$a2/ /sequence You'll know what I'm talking about --- do-notation. With a bunch of bind calls under the hood, it is equivalent as saying: do a1 = bean A1 a2 = bean A2 method X create [a1,a2] url: http://docs.codehaus.org/display/YAN/home This is the only ioc container that uses Monad model in Java. Just FYI. Any comment is welcome. Ben.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapOfmap composition
On Friday 09 December 2005 17:31, Christian Maeder wrote: raptor wrote: And second why when I try do do function composition i.e. : newf = map . f But this works : newf x = map (f x) Does f has constraints? It should work with a type signature. To elaborate this very short comment: The above definition for newf is rejected because of the (infamous) monomorphism restriction. Either supply a type signature or an argument so that Haskell knows you want to define a function, not data. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strictness that GHC infers for functions
Duncan, How do you find out the strictness that ghc infers for functions? Thanks, Joel On Dec 8, 2005, at 8:09 PM, Duncan Coutts wrote: For example it's not currently convenient to find out the strictness that ghc infers for functions (though it is possible). Ideally an IDE or something would be able to present this sort of information along with the inferred type etc. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] matrix computations based on the GSL
Hi, I've just looked through this discussion, since I'm working on my own library, I wanted to see what people are doing. It's something like this, using the Prepose (Implicit Configurations) paper: data L n = L Int deriving (Show, Eq, Ord) -- singleton domain type S = L Zero class (Bounded a, Ix a) = IxB a instance ReflectNum n = Bounded (L n) where minBound = L 0 maxBound = L $ reflectNum (__ :: n) - 1 mul :: (Num k, IxB a, IxB b, IxB c) = Matrix k a b - Matrix k b c - Matrix k a c add :: (Num k, IxB a, IxB b) = Matrix k a b - Matrix k a b - Matrix k a b vec :: (Num k, IxB a, IxB b) = Matrix k a b - Matrix k (a,b) S This way one can form a type L n which represents integers between 0 inclusive and n (rather, 'reflectNum (__ :: n)') exclusive, which can serve to index the matrices and vectors... Of course, other index types are allowed, such as Either a b - if we want to, say, take the sum of two vector spaces, one indexed by a and the other by b, then the result should be indexed by Either a b, etc. - we never have to do anything with the type-level numerals other than assert equality, i.e. we don't have to be able to add or multiply them in our type-signatures, since structural operations will suffice. I think having the ability to guarantee through the type system that column and row dimensions are correct is of paramount importance to those who would use a matrix library, but so far in this thread I haven't seen any suggestions which would accomplish that. I'm sorry if I didn't read carefully. Does my approach not work? I haven't filled in the implementation yet, but it type-checks. Frederik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] What is a Boxed Array?
I've tried google and google scholar, wikipedia, and planetMath. Can't find a description. Can someone point me to a freely available reference? Thanks, John Velman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Boxed Array?
A box is a cell representing some value in a program. It generally contains a pointer to code (a thunk), or to a proper value. When evaluation of that box is forced for the first time, the code executes, and when it is done, it updates the pointer with a pointer to the result value. There are a number of slight variations on this scheme, but essentially the idea is that there is a layer of indirection which keeps track of whether the value has been evaluated yet or not. This sort of thing forms a major role in the implementation of a lazy language like Haskell. Ordinary Arrays in Haskell, say, Array i e for some index type i, and element type e, are arrays of boxed values. That is, each element of the array is a pointer to either code, or a value, and each may be evaluated separately and lazily. By contrast, unboxed arrays, like those of type UArray i e, are arrays of unboxed values. The layer of indirection which normally allows for separate lazy evaluation of the elements is missing. Consequently, such arrays consume much less space in overhead, however, there is a penalty to be paid in ease of use. The array's box now has code which determines the value of every element of the array as soon as it is forced. Thus, even a single lookup in the array will cause the entire array to be computed. If you were going to compute it anyway, you don't lose much. What you do lose however, is the ability to define the array elements recursively in terms of one another. The following definition works for boxed array types, but not unboxed ones: a = array (0,2) $ (0,0):(1,1):[(i, a ! (i-1) + a ! (i-2)) | i - [2..2]] Further, you restrict yourself to only a small collection of possible element types which have a compact unboxed representation. A list of these in the case of UArray is available in the documentation for Data.Array.Unboxed. One paper which might be of interest is the one located at http://citeseer.ist.psu.edu/peytonjones92implementing.html which describes the Spineless Tagless G-machine, a low-level mechanism used to implement Haskell code by GHC. Hope this helps, - Cale On 09/12/05, John Velman [EMAIL PROTECTED] wrote: I've tried google and google scholar, wikipedia, and planetMath. Can't find a description. Can someone point me to a freely available reference? Thanks, John Velman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] busting up a structured binary file
Hello Brian, Thursday, December 08, 2005, 10:54:29 PM, you wrote: BM I need to extract text from a structed binary file. Its a local BM database for a commercial app of proprietary structure, though the BM structure has been determined. So I need to move along a number of BM bytes, take a few chunks of so many more bytes and grab the string and BM move on to the next record, dumping the contents - ultimately dumping compile with ghc --make a.hs import Foreign.C.String import Foreign.C.Types import Foreign.Marshal.Alloc import Foreign.Ptr import Foreign.Storable import System.IO main = do h - openBinaryFile database ReadMode hSeek h AbsoluteSeek 137 buf - mallocBytes 10 hGetBuf h buf 10 str - peekCStringLen (buf,10) print str hClose h -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Boxed Array?
On Fri, Dec 09, 2005 at 02:29:33PM -0500, Cale Gibbard wrote: A box is a cell representing some value in a program. It generally contains a pointer to code (a thunk), or to a proper value. When evaluation of that box is forced for the first time, the code executes, and when it is done, it updates the pointer with a pointer to the result value. There are a number of slight variations on this scheme, but essentially the idea is that there is a layer of indirection which keeps track of whether the value has been evaluated yet or not. This sort of thing forms a major role in the implementation of a lazy language like Haskell. Ordinary Arrays in Haskell, say, Array i e for some index type i, and element type e, are arrays of boxed values. That is, each element of the array is a pointer to either code, or a value, and each may be evaluated separately and lazily. I just want to add that many strict languages also have a distinction between boxed and unboxed arrays (or offer only boxed arrays), because there are other reasons to box values besides implementing laziness, like for simplifying the memory model (which can simplify GC implementation), allowing to intermix values of different types (different kinds of polymorphism) or allow variable sized values (think strings, arrays and arbitrary size integers). Some concrete examples: Arrays in many scripting languages, like Python, are often boxed. There are some languages, like R, where there are many types of unboxed arrays, for efficiency reasons. The situation in OCaml is a bit more complicated - standard arrays are boxed in general, the tagged 31bit int hack makes them unboxed for ints, and arrays of doubles are unboxed as an exception - IIUC in some cases this requires a runtime check, for example in non-inlined functions which are polymorphic on the type of array elements. Best regards Tomasz -- I am searching for a programmer who is good at least in some of [Haskell, ML, C++, Linux, FreeBSD, math] for work in Warsaw, Poland ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Boxed Array?
Tomasz Zielonka: ... there are other reasons to box values besides implementing laziness, like for simplifying the memory model (which can simplify GC implementation), allowing to intermix values of different types (different kinds of polymorphism) or allow variable sized values (think strings, arrays and arbitrary size integers). Some concrete examples: Arrays in many scripting languages, like Python, are often boxed. There are some languages, like R, where there are many types of unboxed arrays, for efficiency reasons. There are nice unboxed arrays in Clean as well. The gain of efficiency is enormous. == Hmmm I thought that arrays in Python have no reason to be boxed. Lists, yes, since they are untyped, so they are arrays of pointers, but arrays are homogeneous. I don't know why boxing may simplify the *memory model*. The most dramatic effect of implicit boxing is the possibility - available in Smalltalk - to change the *identity* of an object. You write (x become y), and all references to the object assigned to x, point now to something completely different. A terrible weapon. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Differences in optimisiation with interactive and compiled mo
Still doesn't work, though: *Main searchr hahal jupp hahahalala hahahalala The problem is that the string to replace may contain a repeated pattern and the pattern that begins the actual occurence might be consumed before a failure is detected. And is *Main searchr bla remove bla bla remove bla bla really intended? Cheers, Daniel Am Freitag, 9. Dezember 2005 10:24 schrieb Branimir Maksimovic: From: Henning Thielemann [EMAIL PROTECTED] To: Branimir Maksimovic [EMAIL PROTECTED] CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mo Date: Fri, 9 Dec 2005 09:23:53 +0100 (MET) On Thu, 8 Dec 2005, Branimir Maksimovic wrote: From: Henning Thielemann [EMAIL PROTECTED] To: Branimir Maksimovic [EMAIL PROTECTED] CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Differences in optimisiation with interactive and compiled mode Date: Thu, 8 Dec 2005 18:38:45 +0100 (MET) On Thu, 8 Dec 2005, Branimir Maksimovic wrote: program performs search replace on a String http://www.haskell.org/pipermail/haskell-cafe/2005-April/009692.html This is nice and ellegant but example search replace program runs more then 50% faster with my implementation. Is this intended: *SearchReplace searchr ha lo hha hha ? thanks, this is a bug. I over optimised it :) that should be : searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs (x:fndSoFar) s | otherwise = (False,searchr''' s | (x:xs) fndSoFar) instead of searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs xxs s | otherwise = (False,searchr''' s xs xxs) where xxs = x:fndSoFar Just to say my algorithm takes some optimisation opportunities. For example if search replace able search baker search charlie then it will run much faster then if able search baker search charlie Worst case is repetitive first mathing character, but than it is fast as normal implementation. Greetings, Bane. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Boxed Array?
Thanks, this is very helpful. John Velman On Fri, Dec 09, 2005 at 02:29:33PM -0500, Cale Gibbard wrote: A box is a cell representing some value in a program. It generally ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is a Boxed Array?
Hmmm I thought that arrays in Python have no reason to be boxed. Lists, yes, since they are untyped, so they are arrays of pointers, but arrays are homogeneous. Python has a different meaning for list than the rest of the world. When python says list, read boxed array (heterogeneous) and when it says array read unboxed array (homogenous). I don't know why boxing may simplify the *memory model*. If you can have unboxed types floating around then you need to ether put them on the stack or your GC needs to be cool with them... relocating GC I imagine having especial trouble with unboxed types. Having a common handle on all types would certainly simplify the GC. I don't know if this is what he meant by memory model. The most dramatic effect of implicit boxing is the possibility - available in Smalltalk - to change the *identity* of an object. Wow, just when you thought you were safe from aliasing... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness that GHC infers for functions
Check section 6.2 of the ghc user's guide, under How do I find out a function's strictness :) It's in the .hi files. joelr1: Duncan, How do you find out the strictness that ghc infers for functions? Thanks, Joel On Dec 8, 2005, at 8:09 PM, Duncan Coutts wrote: For example it's not currently convenient to find out the strictness that ghc infers for functions (though it is possible). Ideally an IDE or something would be able to present this sort of information along with the inferred type etc. -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Differences in optimisiation with interactive and compiled mo
From: Daniel Fischer [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: Haskell-Cafe@haskell.org
Subject: Re: Differences in optimisiation with interactive and compiled mo
Date: Fri, 9 Dec 2005 23:27:00 +0100
Still doesn't work, though:
*Main searchr hahal jupp hahahalala
hahahalala
The problem is that the string to replace may contain a repeated pattern
and the pattern that begins the actual occurence might be consumed before a
failure is detected.
Yes, I've corrected it. Now it is just 25% faster and that is only with -O2
flag.
Here is whole thing, I hope there are no more bugs left :) :
module Main where
import IO
import List
main = do
hSetBuffering stdout LineBuffering
let sr = seasearch
rp = replace
str= able seaseaseasearch baker ssseasearch charlie
out = searchr sr rp (take (100*(length str)) $ cycle str)
out1 = replace sr rp (take (100*(length str)) $ cycle str)
putStrLn $ Working: ++ sr ++ ++ rp ++ ++ str
putStrLn $ (show (out == out1)) ++ \nDone\n
{- search replace able search baker search charlie -}
---
--infinite xs = xs ++ infinite xs
searchr :: String-String-String - String
searchr [] _ xs = xs
--searchr _ [] xs = xs
searchr _ _ [] = []
searchr sr rp xs | fst fnd = rp ++ searchr sr rp (snd $ snd fnd)
| otherwise = (reverse $ fst $ snd fnd) ++
searchr sr rp (snd $ snd fnd)
where fnd = searchr' sr xs
searchr' :: String-String-String - (Bool,(String,String))
searchr' (sr:srs) xs fndSoFar = searchr'' (sr:srs) xs fndSoFar
(False,False,) sr
searchr'' :: String-String-String-(Bool,Bool,String)-Char -
(Bool,(String,String))
searchr'' [] xs fnd _ _ = (True,(fnd,xs))
searchr'' _ [] fnd _ _ = (False,(fnd,[]))
searchr'' (sr:srs) (x:xs) fndSoFar (cnt,f,rollBack) s
| sr == x = if cnt (f || s == x)
then searchr'' srs xs fndSoFar (True,True,x:rollBack)
s
else searchr'' srs xs (x:fndSoFar) (True,f,rollBack) s
| otherwise = if not f
then (False,searchr''' s (x:xs) fndSoFar)
else (False,(fndSoFar,(reverse rollBack)++(x:xs)))
searchr''' :: Char-String-String - (String,String)
searchr''' sr [] fndSoFar = (fndSoFar,[])
searchr''' sr (x:xs) fndSoFar | sr/=x = searchr''' sr xs (x:fndSoFar)
| otherwise = (fndSoFar,x:xs)
---
replace :: forall a. (Eq a) = [a] - [a] - [a] - [a]
replace src dst =
foldr (\x xs - let y=x:xs
in if isPrefixOf src y
then dst ++ drop (length src) y
else y) []
And is
*Main searchr bla remove bla bla
remove bla bla
really intended?
Originaly yes, but I've changed that now.
Greetings, Bane.
Cheers, Daniel
Am Freitag, 9. Dezember 2005 10:24 schrieb Branimir Maksimovic:
From: Henning Thielemann [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Differences in optimisiation with
interactive
and compiled mo
Date: Fri, 9 Dec 2005 09:23:53 +0100 (MET)
On Thu, 8 Dec 2005, Branimir Maksimovic wrote:
From: Henning Thielemann [EMAIL PROTECTED]
To: Branimir Maksimovic [EMAIL PROTECTED]
CC: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Differences in optimisiation with
interactive and compiled mode
Date: Thu, 8 Dec 2005 18:38:45 +0100 (MET)
On Thu, 8 Dec 2005, Branimir Maksimovic wrote:
program performs search replace on a String
http://www.haskell.org/pipermail/haskell-cafe/2005-April/009692.html
This is nice and ellegant but example search replace program runs more
then 50% faster with my implementation.
Is this intended:
*SearchReplace searchr ha lo hha
hha
?
thanks, this is a bug. I over optimised it :)
that should be :
searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs
(x:fndSoFar) s
| otherwise = (False,searchr''' s
| (x:xs)
fndSoFar)
instead of
searchr'' (sr:srs) (x:xs) fndSoFar s | sr == x = searchr'' srs xs xxs s
| otherwise = (False,searchr''' s xs
xxs)
where xxs = x:fndSoFar
Just to say my algorithm takes some optimisation opportunities.
For example if search replace able search baker search charlie
then
it will run much
faster then if able search baker search charlie
Worst case is repetitive first mathing character, but than it is fast
as normal implementation.
Greetings, Bane.
_
Don't just search. Find. Check out the new MSN Search!
[Haskell-cafe] mailman issue
Sent: Friday, December 09, 2005 3:59 PM On Fri, Dec 09, 2005 at 05:49:15AM +0100, [EMAIL PROTECTED] wrote: On Thu, Dec 08, 2005 at 09:59:25PM +0100, [EMAIL PROTECTED] wrote: p.s.: Strangely, Tomasz's reply again appears as being sent from my address in the archive. Anyone knows why? Maybe mailman is somehow confused by this weird address: xoxy = haskell-cafe [EMAIL PROTECTED] ? Relevant headers of this message: [...] Looks like gourmet.spamgourmet.com resends to haskell-cafe@haskell.org messages addressed to [EMAIL PROTECTED] as if they were send from [EMAIL PROTECTED] That is right. Apparently, there is something going wrong with carbon copies at the forwarding service. I couldn't reach the provider yet, so for the time being, I won't use the Cc field here anymore. To avoid further confusion, please, refrain from using the forwarding address (i. e. the lengthy one, containing many funny signs and numbers) as destination of your posts, be it in the To or in the Cc field. My address to reply or send a Cc to is just [EMAIL PROTECTED] . Thanks, zooloo -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.13.12/192 - Release Date: 05.12.2005 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
