[Haskell-cafe] typeclass and functional dependency problem
I'm writing a Gtk2hs app, and I have several custom widgets that are composite objects represented by records, one field of which is a container widget. I am trying to write a replacement for gtk2hs's boxPackStart boxPackStart :: (BoxClass self, WidgetClass child) = self - child - Packing - Int - IO () that will accept either a gtk widget or one of my custom widgets to place in the box, and do the right thing. Here's my attempt at it; what I want to know is why the commented out bit didn't work and I had to individually add instances of widgets instead: - -- packable objects class WidgetClass w = Packable a w | a - w where widgetOf :: a - w --instance WidgetClass w = Packable w w where --widgetOf = id instance Packable Button Button where widgetOf = id instance Packable Entry Entry where widgetOf = id instance Packable Label Label where widgetOf = id instance Packable Notebook Notebook where widgetOf = id instance Packable HBox HBox where widgetOf = id -- add widget to box boxPackS :: (BoxClass b, WidgetClass w, Packable a w) = b - a - Packing - Int - IO () boxPackS box child p i = boxPackStart box (widgetOf child) p i - If I try to use instance WidgetClass w = Packable w w where widgetOf = id instead, I get the compilation error Editor.hs:23:10: Functional dependencies conflict between instance declarations: instance Packable PairBox VBox -- Defined at Editor.hs:23:10-30 instance WidgetClass w = Packable w w -- Defined at GuiUtils.hs:13:10-38 even though PairBox does not belong to WidgetClass. martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to show a utf8 string?
Hi, I am using LDAP hackage to do some ldap searching. I am not sure if this is its problem. All Chinese chars returned like \29579. How to convert it to the actual Chinese char? I thought it was my terminal's fault, so tried to use System.IO.UTF8 to put the result into a file and viewed by firefox, no luck. -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to show a utf8 string?
Have you tried using putStrLn? Small GHCI example: Prelude putStrLn \29579 王 I believe the Show instances for chars and strings escape all characters with a codepoint 127. 2012/1/10 Magicloud Magiclouds magicloud.magiclo...@gmail.com: Hi, I am using LDAP hackage to do some ldap searching. I am not sure if this is its problem. All Chinese chars returned like \29579. How to convert it to the actual Chinese char? I thought it was my terminal's fault, so tried to use System.IO.UTF8 to put the result into a file and viewed by firefox, no luck. -- 竹密岂妨流水过 山高哪阻野云飞 ___ 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] How to show a utf8 string?
On Tue, Jan 10, 2012 at 7:55 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I am using LDAP hackage to do some ldap searching. I am not sure if this is its problem. All Chinese chars returned like \29579. How to convert it to the actual Chinese char? I thought it was my terminal's fault, so tried to use System.IO.UTF8 to put the result into a file and viewed by firefox, no luck. Are you using print? Did you try putStrLn? Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] SMP parallelism increasing GC time dramatically
As it turns out, I ran into a similar issue with a concurrent Gibbs sampling implmentation I've been working on. Increasing -H fixed the regression, as expected. I'd be happy to provide data if someone was interested. Yes, please. Even if it turns out not a ThreadScope issue, it's still a valuable test case. I will try reproducing it and report back. Please use my email address miko...@well-typed.com or the ThreadScope Trac. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] typeclass and functional dependency problem
From: Martin DeMello martindeme...@gmail.com Subject: [Haskell-cafe] typeclass and functional dependency problem I'm writing a Gtk2hs app, and I have several custom widgets that are composite objects represented by records, one field of which is a container widget. I am trying to write a replacement for gtk2hs's boxPackStart boxPackStart :: (BoxClass self, WidgetClass child) = self - child - Packing - Int - IO () that will accept either a gtk widget or one of my custom widgets to place in the box, and do the right thing. Here's my attempt at it; what I want to know is why the commented out bit didn't work and I had to individually add instances of widgets instead: - -- packable objects class WidgetClass w = Packable a w | a - w where widgetOf :: a - w --instance WidgetClass w = Packable w w where -- widgetOf = id instance Packable Button Button where widgetOf = id instance Packable Entry Entry where widgetOf = id instance Packable Label Label where widgetOf = id instance Packable Notebook Notebook where widgetOf = id instance Packable HBox HBox where widgetOf = id -- add widget to box boxPackS :: (BoxClass b, WidgetClass w, Packable a w) = b - a - Packing - Int - IO () boxPackS box child p i = boxPackStart box (widgetOf child) p i - If I try to use instance WidgetClass w = Packable w w where widgetOf = id instead, I get the compilation error Editor.hs:23:10: Functional dependencies conflict between instance declarations: instance Packable PairBox VBox -- Defined at Editor.hs:23:10-30 instance WidgetClass w = Packable w w -- Defined at GuiUtils.hs:13:10-38 even though PairBox does not belong to WidgetClass. This is a very common problem. The line instance WidgetClass w = Packable w w where means Every type is an instance of Packable by this declaration, not Every type that has a WidgetClass instance is a Packable by this declaration, which is what you wanted. So you end up with two Packable instances for PairBox, Packable PairBox PairBox and Packable PairBox Container (or whatever type you used), which causes this conflict. This is a consequence of Haskell type classes being open. Even if you don't have a WidgetClass instance for a type (PairBox) in scope where you define this instance, one could be defined elsewhere and be in scope at a call site. Unfortunately Haskell doesn't provide a way to write what you want. I can think of a few solutions, none of which are ideal: 1. Create separate instances for each type. Writing some generating code to do this is probably the best available option. 2. Convert everything to a Container. 3. Make boxPackS a TH splice, and use a naming convention to differentiate your objects from the built-in widgets. I don't like 3) because it's fragile. Pretty much everything else is a variant of either 1 (lots of instance decls) or 2 (another function call/separate functions). John L. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to show a utf8 string?
Thank you guys. I forgot the point that print involves show. On Tue, Jan 10, 2012 at 6:27 PM, Roel van Dijk vandijk.r...@gmail.com wrote: Have you tried using putStrLn? Small GHCI example: Prelude putStrLn \29579 王 I believe the Show instances for chars and strings escape all characters with a codepoint 127. 2012/1/10 Magicloud Magiclouds magicloud.magiclo...@gmail.com: Hi, I am using LDAP hackage to do some ldap searching. I am not sure if this is its problem. All Chinese chars returned like \29579. How to convert it to the actual Chinese char? I thought it was my terminal's fault, so tried to use System.IO.UTF8 to put the result into a file and viewed by firefox, no luck. -- 竹密岂妨流水过 山高哪阻野云飞 ___ 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] Monad-control rant
On 01/10/2012 12:17 AM, Edward Z. Yang wrote: Hello Mikhail, Hi. (Apologies for reviving a two month old thread). Have you put some thought into whether or not these extra classes generalize in a way that is not /quite/ as general as MonadBaseControl (so as to give you the power you need) but still allow you to implement the functionality you are looking for? I'm not sure but it seems something along the lines of unwind-protect ala Scheme might be sufficient. I'm not sure I'm following you. The problem with MonadBaseControl is that it is /not/ general enough. It assumes that you can eject/inject all the stacked effects as a value of some data type. Which works fine for the standard transformers because they are /implemented/ this way. But not for monads that are implemented in operational style, as interpreters, because the interpreter state cannot be internalized. This particular implementation bias causes additional issues when the lifted operation is not fully suited for ejecting/injecting. For example the `Control.Exception.finally` (or unwind-protect), where we can neither inject (at least properly) the effects into nor eject them from the finalizer. That's why I think that the whole lift operations from the bottom approach is wrong (the original goal was to lift `Control.Exception`). The right way would be to capture the control semantics of IO as a set of type classes[1] and then implement the general versions of the operations you want to lift. That's what I tried to do with the monad-abord-fd package. Hopefully this makes sense to you. [1] Which turn out to be quite general: MonadAbort/Recover/Finally are just a twist of MonadZero/MonadPlus; MonadMask is expectedly more specific, but permits a nice no-op implementation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad-control rant
Excerpts from Mikhail Vorozhtsov's message of Tue Jan 10 09:54:38 -0500 2012: On 01/10/2012 12:17 AM, Edward Z. Yang wrote: Hello Mikhail, Hi. (Apologies for reviving a two month old thread). Have you put some thought into whether or not these extra classes generalize in a way that is not /quite/ as general as MonadBaseControl (so as to give you the power you need) but still allow you to implement the functionality you are looking for? I'm not sure but it seems something along the lines of unwind-protect ala Scheme might be sufficient. I'm not sure I'm following you. The problem with MonadBaseControl is that it is /not/ general enough. Sorry, I mispoke. The sense you are using it is the more general a type class is, the more instances you can write for it. I think the design goal I'm going for here is, a single signature which covers MonadAbort/Recover/Finally in a way that unifies them. Which is not more general, except in the sense that it contains more type classes (certainly not general in the mathematical sense.) It assumes that you can eject/inject all the stacked effects as a value of some data type. Which works fine for the standard transformers because they are /implemented/ this way. But not for monads that are implemented in operational style, as interpreters, because the interpreter state cannot be internalized. This particular implementation bias causes additional issues when the lifted operation is not fully suited for ejecting/injecting. For example the `Control.Exception.finally` (or unwind-protect), where we can neither inject (at least properly) the effects into nor eject them from the finalizer. That's why I think that the whole lift operations from the bottom approach is wrong (the original goal was to lift `Control.Exception`). The right way would be to capture the control semantics of IO as a set of type classes[1] and then implement the general versions of the operations you want to lift. That's what I tried to do with the monad-abord-fd package. I think this is generally a useful goal, since it helps define the semantics of IO more sharply. However, the exceptions mechanism is actually fairly well specified, as far as semantics go, see A Semantics for Imprecise Exceptions and Asynchronous Exceptions in Haskell. So I'm not sure if monad-abort-fd achieves the goal of expressing these interfaces, in typeclass form, as well as allowing users to interoperate cleanly with existing language support for these facilities. [1] Which turn out to be quite general: MonadAbort/Recover/Finally are just a twist of MonadZero/MonadPlus Now that's interesting! Is this an equivalence, e.g. MonadZero/MonadPlus imply MonadAbort/Recover/Finally and vice-versa, or do you need to make some slight modifications? It seems that you somehow need support for multiple zeros of the monad, as well as a way of looking at them. MonadMask is expectedly more specific, but permits a nice no-op implementation. (See my earlier comments about asynchronous exceptions.) Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Simple type-class experiment turns out not so simple...
On 1/9/12 7:54 AM, Luminous Fennell wrote: On Mon, Jan 09 2012 at 10:37 +0100, Steve Horne wrote: On 08/01/2012 21:13, Brandon Allbery wrote: (Also, de facto I think it's already more or less been decided in favor of type families, just because functional dependencies are (a) a bit alien [being a glob of Prolog-style logic language imported into the middle of System Fc] and (b) [as I understand it] difficult to verify that the code in the compiler is handling all the potential corner cases right [mainly because of (a)]. Isn't Haskell doing some prolog-ish things anyway? I thought the compiler must be doing unification to resolve type inference within expressions. Even quite basic type reconstruction (e.g. for ML) needs unification, see e.g. Pierce TaPL chapter 22. The algorithm is rather easy to understand and implement. Though it can be somewhat involved to optimize, since the naive implementation is really quite inefficient. If you don't want to worry about the details, there's always: http://hackage.haskell.org/package/unification-fd -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Code generation and optimisation for compiling Haskell
Although I'm far from being an expert Haskell programmer, I think I'm ready to look into some of the details of how it's compiled. I've a copy of Modern Compiler Design (Grune, Bal, Jacobs and Langendoen) - I first learned a lot of lexical and parsing stuff from it quite a few years ago. Today, I started looking through the functional languages section - I've read it before, but never absorbed much of it. Graph reduction, lambda lifing, etc - it seems pretty simple. Far too simple. It's hard to believe that decent performance is possible if all the work is done by a run-time graph reduction engine. Simon Peyton Jones has written a couple of books on implementing functional languages which are available for free download. At a glance, they seem to covers similar topics in much more detail. However, they're from 1987 and 1992. Considering SPJs period of despair when he couldn't get practical performance for monadic I/O, these seem very dated. Some time ago, I made a note to look up the book Functional Programming and Parallel Graph Rewriting (I forget why) but again that's from the early 90's. I've also got a note to look up Urban Boquists thesis. SPJ also has some papers on compilation - http://research.microsoft.com/en-us/um/people/simonpj/papers/papers.html#compiler - and the papers on optimisation by program transformation have caught my eye. Are there any current text-books that describe the techniques used by compilers like GHC to generate efficient code from functional languages? It's OK to assume some knowledge of basic compiler theory - the important stuff is code generation and optimisation techniques for lazy functional languages in particular. Also, what papers should I read? Am I on the right lines with the ones I've mentioned above? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: sloth-0.0.1
Hi, I have just released a prototype implementation of a tool (http://hackage.haskell.org/package/sloth) for checking whether a function is unnecessarily strict. It is inspired by Olaf Chitils StrictCheck tool (http://www.cs.kent.ac.uk/people/staff/oc/) but does not propose improvements that lead to non-sequential function definitions. For more details there is a short explanation with some examples at http://www.informatik.uni-kiel.de/fileadmin/arbeitsgruppen/ca_prog_develop/Projekte/Sloth/Examples.pdf. If you discover a bug or have any questions please use the human bug tracking system at jan_christiansen[at]gmx[dot]de. Cheers, Jan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] feed release plan
Hi all, thanks for the input about feed. Unless I hear from Sigbjorn or Don I will make a release soon, along these lines: - it will depend on xml-conduit - it will include a fix or two from Gwern Branwen and Frédéric Bour - the version will be 1.0 - the maintainer will be Haskell community librar...@haskell.org - the repo will be moved to github, under my account since I don't think there's a haskell community one Cheers, -Simon On Jan 2, 2012, at 11:01 AM, Michael Snoyman wrote: If I may: I'm about to upload a new version of xml-enumerator that will state that it's officially deprecated in favor of xml-conduit. My guess is you'll be able to migrate to the latter by just changing the package name in your cabal file. On Mon, Jan 2, 2012 at 8:54 PM, Simon Michael si...@joyful.com wrote: Hi Sigbjorn (and Don), I'm back for another reason. feed leaks and uses a lot of memory due to the xml package. Rather than fix xml I ported feed to xml-enumerator, which is used by yesod and more actively maintained than xml. This seems to have fixed the problem so I'm thinking of uploading this version to hackage as feed-1.0 (which I'll use for rss2irc and hackagebot.) Please let me know whether you agree. Also you might be interested in moving your repo (http://code.galois.com/cgi-bin/gitweb?p=feed.git;a=summary) to github ? This would make it easier to publish my changes, either to the main repo or a branch or fork. Otherwise I'll need to get them to your repo somehow. Thanks again, -Simon On Feb 21, 2011, at 5:14 PM, Simon Michael wrote: thanks for feed. I'm just investigating a bug with rss2irc, and I think I'm seeing problems in the current feed on hackage. It lookas as if there's no way to get item updated date as opposed item published date, and getItemPublishDate actually gets the updated date in the case of an atom feed (http://hackage.haskell.org/packages/archive/feed/0.3.8/doc/html/src/Text-Feed-Query.html#getItemPublishDate). I'd like to contribute a fix. Would you be able to make feed's repo public, eg on darcsden.com or github ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHCi with wxhaskell-dev
I'm working on a dev branch of wxHaskell [1] and one of the new features is that you can use wxHaskell in GHCi (again), but I seem to have broken something in the process: Firstly: wxHaskell works in GHCi insomuch as: You can load the hello world sample [2] in GHCi, do main, see the window spawn, close it and be returned to the GHCi prompt. What I'm interested in is the case where you call wxHaskell's start function [3] from GHCi. The result is becoming stuck with no way back to the GHCi prompt without resorting to sending kill signals. I made a screen cast to illustrate my findings [4]: 1. Once you've done start $ return () you can press ^C all you want, there's no way back to the GHCi prompt. 2. If you send three (less has no effect) kills to the GHCi process it will exit, but it will exit GHCi as well (instead of putting you back at the GHCi prompt). 3. If you do start $ return () but *do not* try and ^C, you can send a single kill to GHCi and be returned to the GHCi prompt. My questions: 1. Why doesn't GHCi respond to the ^C? 2a. Why does entering ^C from within GHCi then prevent you from getting back to the GHCi prompt? 2b. Why doesn't any other input (i.e. entering anything but ^C) cause this behaviour? 3. If you have sent ^C from GHCi, why do you then have to kill three times to get out of GHCi? Feel free to pull the repo [1] and try it out, you'll need the latest dev release of wxWidgets [5] installed. Thanks! Dave, [1] http://darcsden.com/DukeDave/wxhaskell-dev [2] http://darcsden.com/DukeDave/wxhaskell-dev/browse/samples/wx/HelloWorld.hs [3] http://darcsden.com/DukeDave/wxhaskell-dev/browse/wx/src/Graphics/UI/WX.hs#L-58 [4] http://youtu.be/sEI48ultdS0 [5] http://sourceforge.net/projects/wxwindows/files/2.9.3/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] When will constraint kinds roll out?
Just a quick, logistical question: I see constraint kinds didn't make it to GHC 7.2.2; does anyone have guesses when the extension will roll out in an official release? Our research team is interested in using Haskell for an EDSL, and having both constraint kinds and access to all of the libraries on Hackage would be optimal. (I've been writing an EDSL with monad transformers and the rmonad package myself, but think it is too difficult and cumbersome if we are to use Haskell EDSL approaches more broadly). Thanks in advance, Nicholas — https://ntung.com — 4432-nstung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When will constraint kinds roll out?
On Tue, Jan 10, 2012 at 1:04 PM, Nicholas Tung nt...@ntung.com wrote: Just a quick, logistical question: I see constraint kinds didn't make it to GHC 7.2.2; does anyone have guesses when the extension will roll out in an official release? Our research team is interested in using Haskell for an EDSL, and having both constraint kinds and access to all of the libraries on Hackage would be optimal. (I've been writing an EDSL with monad transformers and the rmonad package myself, but think it is too difficult and cumbersome if we are to use Haskell EDSL approaches more broadly). Constraint kinds are in the release branch for the upcoming 7.4 release, and were in the build of 7.4.1 RC 1 that went out a bit ago: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021310.html I'm not on the GHC team, but from what I've seen new features like this generally don't get added in point releases (something like from 7.1.1 to 7.2.2). Antoine Thanks in advance, Nicholas — https://ntung.com — 4432-nstung ___ 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] feed release plan
Simon Michael wrote: - the repo will be moved to github, under my account since I don't think there's a haskell community one Haskell package janitors might be an appropriate one: https://github.com/haskell-pkg-janitors Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] feed release plan
There is also: https://github.com/haskell where a bunch of us are hosting librari On 10 January 2012 12:01, Erik de Castro Lopo mle...@mega-nerd.com wrote: Simon Michael wrote: - the repo will be moved to github, under my account since I don't think there's a haskell community one Haskell package janitors might be an appropriate one: https://github.com/haskell-pkg-janitors Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.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] Where is the pairing-with-monoid monad instance?
Is the standard pair-with-monoid monad instance in some standard place? I see the Applicative instance in Control.Applicative, and the pair-with-monoid Functor instance in Control.Monad.Instances, and the (-) e and Either e monad instances also in Control.Monad.Instances. I'm looking for something like instance Monoid o = Monad ((,) o) where return a= (mempty,a) (o,a) = f = (o `mappend` o', b) where (o',b) = f a Where is it hiding from me? Thanks, - Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Hi, I'm building gtk2hs on a mac with -fsplit-objs, and during compilation of the largest file, which produces about 7000 split objects, the linking phase fails. I'm assuming that's because the command line length has been exceeded, because other files compile fine, without -fsplit-objs it compiles fine too, and it compiles fine *with* -fsplit-objs on other OS - so perhaps the reason is in mac's tempfile name generation (they're longer than on other platforms) or something. Anyway. I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files. It'd be fun for me to implement this as my first contribution to ghc; is this a good idea in general? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] debugging snap app
Hi, I'm trying to get the debugging messages in snap-server in order to find the socket leaking in my snap app. I find the doc on snapframework.com says that setting an environment variable DEBUG=1 will enable the app to output the messages in stderr. But I don't get any. I installed the snap-server package using -fopenssl flag but without -fnodebug, so I think it's normal. Any idea on this? Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC exceeding command line length limit with split-objs - and a possible fix
Oh well... looks like building ghc won't be easy, as it doesn't build with llvm-gcc and it's not easy to get a real gcc on Lion. But I don't stop trying :) On Wed, Jan 11, 2012 at 11:12 AM, Eugene Kirpichov ekirpic...@gmail.comwrote: Hi, I'm building gtk2hs on a mac with -fsplit-objs, and during compilation of the largest file, which produces about 7000 split objects, the linking phase fails. I'm assuming that's because the command line length has been exceeded, because other files compile fine, without -fsplit-objs it compiles fine too, and it compiles fine *with* -fsplit-objs on other OS - so perhaps the reason is in mac's tempfile name generation (they're longer than on other platforms) or something. Anyway. I think a nice fix would be to employ gcc's ability to read options from a file - gcc @file - and write overly long option strings into temp files. It'd be fun for me to implement this as my first contribution to ghc; is this a good idea in general? -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ -- Eugene Kirpichov Principal Engineer, Mirantis Inc. http://www.mirantis.com/ Editor, http://fprog.ru/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
