Re: haskell xml parsing for larger files?
Have you looked at tagsoup? On Feb 20, 2014 3:30 AM, Christian Maeder christian.mae...@dfki.de wrote: Hi, I've got some difficulties parsing large xml files ( 100MB). A plain SAX parser, as provided by hexpat, is fine. However, constructing a tree consumes too much memory on a 32bit machine. see http://trac.informatik.uni-bremen.de:8080/hets/ticket/1248 I suspect that sharing strings when constructing trees might greatly reduce memory requirements. What are suitable libraries for string pools? Before trying to implement something myself, I'ld like to ask who else has tried to process large xml files (and met similar memory problems)? I have not yet investigated xml-conduit and hxt for our purpose. (These look scary.) In fact, I've basically used the content trees from The (simple) xml package and switching to another tree type is no fun, in particular if this gains not much. Thanks Christian ___ 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: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
+1 While it might work for teaching, it's not reasonable to ask software developers who want to write useful software to depend on haskell98 instead of base if they want more relevant types. I'd go one step further and say that we're not just talking about whether someone is an advanced user either. I'm probably among the more advanced of Haskell users, but I'd still rather see specialized type signatures in cases where one specific instance is far more common than the others. Yes, I know that certain combinators like (***) and () are useful for functions, for example. It still makes me less productive to have those things stuffed off in a corner where they are difficult to get to, and described in needlessly abstract language. I honestly can't understand the viewpoint that says that having the compiler choose the unique most general type for imported symbols (or give an error if none exists) is too complicated, yet programmers manually substituting common instances into type signatures is no big deal. The first is fairly obvious work done by the compiler, which the second needs programmers (yes, even experienced ones) to occasionally get out a pencil and paper to work out the details. On Tue, May 28, 2013 at 1:23 AM, Daniel Gorín dgo...@dc.uba.ar wrote: It is not only a matter of teaching, I think. After first learning the very basics of a language, browsing the libraries that come included is a more or less standard way of getting more acquainted with it. By including only the abstract versions we are making it much harder to learn the common idioms. For instance, at the moment, how likely is that someone will start using (), (***), (+++) or any of the useful combinators in Control.Arrow from reading its haddock? These are very handy functions, easy to understand when specialized to (-), but are usually reserved for advanced users since they are presented only in their most general way. With an extension like this one available, one could propose including specialized versions of them in Data.Function and/or Data.Tuple/Data.Either; today it would be a very bad idea due to the clash with Control.Arrow! Daniel On May 28, 2013, at 3:27 AM, Edward A Kmett wrote: This is basically what you get by default already with the raw proposal we've been talking about -- the Preludes in the haskell98 and haskell2010 remain unmodified by this proposal and are available for teaching use. Sent from my iPhone On May 27, 2013, at 8:53 PM, Andrew Farmer afar...@ittc.ku.edu wrote: I generally agree with Iavor's points, but if this is such an issue, why not make Prelude more general by default and have a special 'Prelude.Basic' with the more specific type signatures for beginners? The general Prelude would be implicitly imported as now, unless the module imported Prelude.Basic unqualified. Then make Hackage warn/reject packages that use Prelude.Basic. Tutorials/Books would have to tell readers to add a magic import Prelude.Basic at the beginning of their source files, but tutorials for other languages do this (public static void main(..)?) to relatively little complaint. Sorry, I'm sure this has been proposed before... but the proposed extension seems complicated to avoid some qualified imports/hidings. If we really want people to use Foldable's foldr by default, then make it the default and let beginners add a magic line once per file to get simpler types. Andrew On Mon, May 27, 2013 at 5:07 PM, Daniel Gorín dgo...@dc.uba.ar wrote: Hi Iavor, On May 27, 2013, at 6:18 PM, Iavor Diatchki wrote: Hello, On Fri, May 24, 2013 at 12:42 AM, Daniel Gorín dgo...@dc.uba.ar wrote: On May 24, 2013, at 9:28 AM, Simon Peyton-Jones wrote: How about (in Haskell98) module Data.List ( foldr, ...) import qualified Data.Foldable foldr :: (a - b - b) - b - [a] - b foldr = Data.Foldable.foldr It would not be the same! Using your example one will get that the following fails to compile: import Data.List import Data.Foldable f = foldr The problem is that Data.List.foldr and Data.Foldable.foldr are here different symbols with the same name. This is precisely why Foldable, Traversable, Category, etc are awkward to use. The proposal is to make Data.List reexport Data.Foldable.foldr (with a more specialized type) so that the module above can be accepted. I think that it is perfectly reasonable for this to fail to compile---to me, this sort of implicit shadowing based on what extensions are turned on would be very confusing. It may seem obvious with a well-known example, such as `foldr`, but I can easily imagine getting a headache trying to figure out a new library that makes uses the proposed feature in anger :) I understand your concern, but I don't quite see how a library could abuse this feature. I mean, a library could export the same symbol with different
Re: A language extension for dealing with Prelude.foldr vs Foldable.foldr and similar dilemmas
I agree that it would be unfortunate to complicate the Prelude definitions of foldr and such by generalizing to type classes like Foldable. This proposal seems attractive to me as a way to reconcile abstraction when it's needed, and simplicity for beginners. However, it does seem like a common pattern might be to want to re-export a more generic symbol alongside a rewrite rule that substitutes a more efficient implementation for a specific type. Consider Text, ByteString, and Vector, for example. Is that doable with rewrite rules and this proposal? I'd also point out that the first of the two (-XMoreSpecificExports) would be convenient even without the other. Many people already routinely list type signatures in comments after each symbol of the export list. This would just allow the compiler to check and enforce the contracts that people are already documenting in comments. Adding optional type checking where people are already writing type signatures anyway seems like an obvious win. On Mon, May 27, 2013 at 5:07 PM, Daniel Gorín dgo...@dc.uba.ar wrote: Hi Iavor, On May 27, 2013, at 6:18 PM, Iavor Diatchki wrote: Hello, On Fri, May 24, 2013 at 12:42 AM, Daniel Gorín dgo...@dc.uba.ar wrote: On May 24, 2013, at 9:28 AM, Simon Peyton-Jones wrote: How about (in Haskell98) module Data.List ( foldr, ...) import qualified Data.Foldable foldr :: (a - b - b) - b - [a] - b foldr = Data.Foldable.foldr It would not be the same! Using your example one will get that the following fails to compile: import Data.List import Data.Foldable f = foldr The problem is that Data.List.foldr and Data.Foldable.foldr are here different symbols with the same name. This is precisely why Foldable, Traversable, Category, etc are awkward to use. The proposal is to make Data.List reexport Data.Foldable.foldr (with a more specialized type) so that the module above can be accepted. I think that it is perfectly reasonable for this to fail to compile---to me, this sort of implicit shadowing based on what extensions are turned on would be very confusing. It may seem obvious with a well-known example, such as `foldr`, but I can easily imagine getting a headache trying to figure out a new library that makes uses the proposed feature in anger :) I understand your concern, but I don't quite see how a library could abuse this feature. I mean, a library could export the same symbol with different specialized types in various modules, but you, the user of the library, will see them as different symbols with conflicting name, just like now you see symbols Prelude.foldr and Data.Foldable.foldr exported by base... unless, of course, you specifically activate the extension (the one called MoreSpecificImports in my first mail). That is, it would be an opt-in feature. Also, using module-level language extensions does not seem like the right tool for this task: what if I wanted to use the most general version of one symbol, but the most specific version of another? Do you have a particular example in mind? The more general version of every symbol can be used wherever the more specialized one fits, and in the (seemingly rare?) case where the extra polymorphism may harm you and that adding a type annotation is not convenient enough, you could just hide the import of more the general version. Do you anticipate this to be a common scenario? One needs a more fine grained tool, and I think that current module system already provides enough features to do so (e.g., explicit export lists, `hiding` clauses`, and qualified imports). For example, it really does not seem that inconvenient (and, in fact, I find it helpful!) to write the following: import Data.List hiding (foldr) import Data.Foldable But this doesn't scale that well, IMO. In real code even restricted to the the base package the hiding clauses can get quite long and qualifying basic polymorphic functions starts to feel like polymorphism done wrong. This can very well be just a matter of taste, but apparently so many people have strong feelings about this issue that it is seriously being proposed to move Foldable and Traversable to the Prelude, removing all the monomorphic counterparts (that is, make Prelude export the unspecialized versions). While this would be certainly convenient for me, I think it would be an unfortunate move: removing concrete (monomorphic) functions in favor of abstract versions will make a language that is already hard to learn, even harder (but there was a long enough thread in the libraries mailing list about this already!). In any case this proposal is an attempt to resolve this tension without penalizing any of the sides. Thanks, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org
Re: Dynamic libraries by default and GHC 7.8
I'm curious how much of the compile twice situation for static and dynamic libraries could actually be shared. Even if it's not likely to be implemented in the next year or two, IMO it would make a big difference if it were feasible to generate both static and dynamic libraries at the same time and share some large percent of the compile time. It seems to me that making GHCi always dynamic but GHC static by default, with the default being for Cabal to build both static and dynamic libraries, is the right answer. After all, static binaries are the right answer for binaries on everything but a few resource-limited mobile platforms anyway. Doubling the compile times is harsh, but I think it's particularly justifiable if it were something that eventually, if it annoys someone enough, they will pound out the code to fix it. Or... how hard would it be to make GHCi fall back to interpreting modules from any packages that don't have dynamic libraries? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
On Tue, Jul 10, 2012 at 5:53 AM, Wolfgang Jeltsch g9ks1...@acme.softbase.org wrote: If we use \case for functions, we should use proc case for arrows; if we use \of for functions, we should use proc of for arrows. By the way, is proc a layout herald already? No, proc is not a layout herald. The normal pattern is to use a do in the command part of the proc syntax, so it's do that introduces the layout. So proc of would fit in cleanly as a way to do proc with multiple patterns. Or proc case, but again that's just a really ugly language wart, IMO uglier than just writing out the longhand version of proc x - case x of. -- Chris Smith ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
Right, it seems to me that there are basically three reasonable proposals here: 1. \ of with multiple arguments. This is consistent with existing layout, and seems like a nice generalization of lambda syntax. 2. case of with a single argument. This is consistent with existing layout, and seems like a nice generalization of sections. 3. \ introducing layout, possibly with changes to layout rules. A much more intrusive change, but it does have a nice efficiency to it. Either of the first two would be fine. For that matter, they could even *both* be done -- with #2 being a shorthand to avoid parentheses -- without seeming too redundant to me. I tend to see the third option as too intrusive and dangerous, but I can see the argument for doing it. Given that we have these three options, I really don't see the benefit to \ case or similar ideas, which complicate layout rules for little reason, and mix syntax in such a way that it's difficult for me at least to even predict whether parentheses are required. On Mon, Jul 9, 2012 at 8:52 AM, Twan van Laarhoven twa...@gmail.com wrote: On 09/07/12 14:44, Simon Marlow wrote: I now think '\' is too quiet to introduce a new layout context. The pressing need is really for a combination of '\' and 'case', that is single-argument so that we don't have to write parentheses. I think '\case' does the job perfectly. If you want a multi-clause multi-argument function, then give it a name. There is an advantage here for \of in favor of \case, namely that of already introduces layout, while case does not. Twan ___ 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-cafe] Call to arms: lambda-case is stuck and needs your help
Whoops, my earlier answer forgot to copy mailing lists... I would love to see \of, but I really don't think this is important enough to make case sometimes introduce layout and other times not. If it's going to obfuscate the lexical syntax like that, I'd rather just stick with \x-case x of. On Jul 6, 2012 3:15 PM, Strake strake...@gmail.com wrote: On 05/07/2012, Mikhail Vorozhtsov mikhail.vorozht...@gmail.com wrote: Hi. After 21 months of occasional arguing the lambda-case proposal(s) is in danger of being buried under its own trac ticket comments. We need fresh blood to finally reach an agreement on the syntax. Read the wiki page[1], take a look at the ticket[2], vote and comment on the proposals! +1 for \ of multi-clause lambdas It looks like binding of to me, which it ain't, but it is nicely brief... ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: thoughts on the record update problem
On Thu, Mar 8, 2012 at 1:00 PM, Greg Weber g...@gregweber.info wrote: This discussion has largely centered around trying to come up with a hack that desugars to Haskell's existing language constructs. There is an alternative to a desugaring hack: add a real record construct to the language. I am not sure what distinction you are making between real record construct and desugaring hack. As far as I can see, all major proposals currently desugar to type classes... not as a hack but because type classes *are* how Haskell does type-directed resolution. I don't think there are any ground rules set against proposing a system that doesn't use type classes. If you wanted, you could certainly propose a system that defines brand new and potentially very different semantics for a desired record system from scratch, and has nothing to do with type classes. I tend to think it would be a poor idea, both because it would be a large amount of work to be sure the semantics are even nailed down well, and because then the progress of abstraction over that new construct would happen independently from the existing progress of abstraction over type classes, and we'd end up with a more complex and warty language as a result. In any case, I'm in agreement that stop arguing about semantics and just implement something is a very bad idea. We aren't arguing about implementation choices here; we're arguing about pretty fundamental questions of semantics of records and labels, and the way to settle fundamental questions about the record system we hope to be using in 10 years time is not based on who has time after work for GHC hacking this month. -- Chris Smith ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: thoughts on the record update problem
On Thu, Mar 8, 2012 at 2:09 PM, Greg Weber g...@gregweber.info wrote: The semantics that will be exposed to users have already been largely decide upon. Admittedly I haven't had time to carefully read some parts of this thread, and if that claim is true, then of course implementation should be the major concern. But it seems unlikely that claim is true, since in the very same email you express what looks like a pretty serious concern about the semantics that will be exposed to users (namely, the need for a new kind of type annotation). -- Chris Smith ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck strake...@gmail.com wrote: Another thought: Perhaps bang as record selection operator. It would avoid further corner cases of dot, and it's not unprecedented in Haskell (e.g. Data.Map.!). We already have weird syntax rules for dot, and the proposed change (i.e., dot is an identifier when surrounded with spaces, else it's reserved syntax) actually makes the rules *simpler* in some ways rather than more complex... so why wouldn't we do it that way? The more difficult bit isn't about quirks of syntax, but rather about some significant semantic issues and differing design goals should we have a built-in notion of lenses... if so, which formulation... what kinds of punning do we want to preserve, and how deeply should punning go in the semantics, versus be a shallow kind of sugar... how does that interact with the type system... and so on. These are the significant problems. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mkTopLevEnv: not interpreted main:Main
Simon, thank you! That makes sense then. I'd missed the fact that including the entire top-level scope requires the module to be interpreted. I suppose the right thing to do would be to not do that; but sadly, that seems to also mean that modules without a 'module Foo where' only export the single symbol 'main', and I liked the idea of students in my class not having to write out the module bit explicitly. So I've been actually using interpreted code the whole time? If so, I suppose there's no loss in taking out HscAsm entirely, then! -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: mkTopLevEnv: not interpreted main:Main
Here's a test case: the complete source code is in the following. I
compile it with:
ghc -package ghc --make Test.hs
The GHC version is
cdsmith@godel:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.2.1
Then run the application several times in a row. If you count to 3
between runs, it's fine. If you run it multiple times in a row rapidly,
you get intermittent errors, as so:
cdsmith@godel:~$ ./Test
Just 42
cdsmith@godel:~$ ./Test
Just 42
cdsmith@godel:~$ ./Test
Test: mkTopLevEnv: not interpreted main:Main
cdsmith@godel:~$ ./Test
Just 42
cdsmith@godel:~$ ./Test
Test: mkTopLevEnv: not interpreted main:Main
cdsmith@godel:~$ ./Test
Just 42
cdsmith@godel:~$ ./Test
Test: mkTopLevEnv: not interpreted main:Main
Note this isn't even in the same process! But it's definitely caused by
running the test multiple times in a quick sequence.
Here's the complete source code for Test.hs
{-# LANGUAGE MagicHash #-}
import System.IO.Unsafe
import GHC.Exts (unsafeCoerce#)
import GHC.Paths (libdir)
import qualified GHC as GHC
import qualified DynFlags as GHC
compile :: IO (Maybe Int)
compile = GHC.runGhc (Just libdir) $ do
dflags - GHC.getSessionDynFlags
let dflags' = dflags {
GHC.ghcMode = GHC.CompManager,
GHC.ghcLink = GHC.LinkInMemory,
GHC.hscTarget = GHC.HscAsm,
GHC.optLevel = 2,
GHC.safeHaskell = GHC.Sf_Safe
}
GHC.setSessionDynFlags dflags'
target - GHC.guessTarget A.hs Nothing
GHC.setTargets [target]
r - fmap GHC.succeeded (GHC.load GHC.LoadAllTargets)
case r of
True - do
mods - GHC.getModuleGraph
let mainMod = GHC.ms_mod (head mods)
GHC.setContext [ mainMod ] [ ]
v - GHC.compileExpr a :: Integer
return (Just (unsafeCoerce# v))
False - return Nothing
main = do
writeFile A.hs a = 42
print = compile
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: mkTopLevEnv: not interpreted main:Main
Here's a version with fewer flags/features, that acts the same.
I tried removing the loading of an external module, and that did *not*
exhibit the problem. It also does *not* fail when the file name is
different each time, so the fact that it's the same file, A.hs, each
time is somehow part of the issue.
I'm getting to the point where I can't imagine what this could possibly
be about.
{-# LANGUAGE MagicHash #-}
import System.IO.Unsafe
import GHC.Exts (unsafeCoerce#)
import GHC.Paths (libdir)
import qualified GHC as GHC
import qualified DynFlags as GHC
compile :: IO (Maybe Int)
compile = GHC.runGhc (Just libdir) $ do
dflags - GHC.getSessionDynFlags
let dflags' = dflags { GHC.ghcLink = GHC.LinkInMemory }
GHC.setSessionDynFlags dflags'
target - GHC.guessTarget A.hs Nothing
GHC.setTargets [target]
r - fmap GHC.succeeded (GHC.load GHC.LoadAllTargets)
case r of
True - do
mods - GHC.getModuleGraph
let mainMod = GHC.ms_mod (head mods)
GHC.setContext [ mainMod ] [ ]
v - GHC.compileExpr a :: Integer
return (Just (unsafeCoerce# v))
False - return Nothing
main = do
writeFile A.hs a = 42
print = compile
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: mkTopLevEnv: not interpreted main:Main
Thanks everyone for the help! I'm working now on reproducing this with HEAD, and if I do, I'll write a ticket. On the other hand, it only seems to be an issue when one is recompiling a file within one second of the first attempt, and Felipe's workaround of deleting the .hi and .o files fixes it even then. I can't imagine recompiling a file multiple times per second is a common use case, so this is probably low priority! -- Chris ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: mkTopLevEnv: not interpreted main:Main
Thanks, Simon.
I will work on building a smaller complete test case that reproduces the
issue, and I could have done a better job of at least pointing out the
relevant code for you. Sorry about that.
I'm definitely not building my own IIModule. The use of the GHC API is
as follows. (I'm fairly sure you can ignore doWithErrors, so I haven't
included it; it just sets up some log actions and exception and signal
handlers, runs its argument in the Ghc monad, and converts the result
from a Maybe to an Either that reports errors).
doWithErrors :: GHC.Ghc (Maybe a) - IO (Either [String] a)
compile :: String - String - FilePath - IO (Either [String] t)
compile vname tname fn = doWithErrors $ do
dflags - GHC.getSessionDynFlags
let dflags' = dflags {
GHC.ghcMode = GHC.CompManager,
GHC.ghcLink = GHC.LinkInMemory,
GHC.hscTarget = GHC.HscAsm,
GHC.optLevel = 2,
GHC.safeHaskell = GHC.Sf_Safe,
GHC.packageFlags = [GHC.TrustPackage gloss,
GHC.ExposePackage gloss-web-adapters ]
}
GHC.setSessionDynFlags dflags'
target - GHC.guessTarget fn Nothing
GHC.setTargets [target]
r - fmap GHC.succeeded (GHC.load GHC.LoadAllTargets)
case r of
True - do
mods - GHC.getModuleGraph
let mainMod = GHC.ms_mod (head mods)
GHC.setContext [ mainMod ]
[ GHC.simpleImportDecl
(GHC.mkModuleName Graphics.Gloss),
GHC.simpleImportDecl
(GHC.mkModuleName GlossAdapters) ]
v - GHC.compileExpr $ vname ++ :: ++ tname
return (Just (unsafeCoerce# v))
False - return Nothing
--
Chris
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
mkTopLevEnv: not interpreted main:Main
So I'm trying to fix a bug in a web application that's using the GHC API with GHC 7.2. If it helps, the application is gloss-web, source code at https://github.com/cdsmith/gloss-web and the relevant module is src/Source.hs. The error I'm getting is no location info: mkTopLevEnv: not interpreted main:MyModule I get this occasionally when two pieces of source code happen to get compiled at approximately the same time, but most of the time everything works fine. The module name there is whichever one I've defined in the source code I'm compiling. It's correct that the module is not interpreted; I'm specifying options hscTarget = HscAsm ghcLink = LinkInMemory But it's unclear to me why GHC occasionally decides to require that it be interpreted and complain, when compiling the code works fine in any other circumstance. Anyone else seen anything like this, or know what the cause is? A few notes: 1. It doesn't appear to be a straight-forward reentrancy issue, as wrapping uses of the GHC API with an MVar lock doesn't affect it at all. However, it definitely *is* correlated with multiple compiles at approximately the same time. Very odd there. 2. On a whim, I tried adding a performGC before and after each use of the compiler to try to isolate the uses of the GHC API more completely. Oddly enough, a performGC before the compile makes the problem much WORSE. I found that interesting; maybe it's a hint. 3. If you want to build my code and reproduce it, the easiest way is to comment out line 110 (keepAlive cmap digest 30) of src/Source.hs. Doing so will break the bit that caches recently compiled source code, making it much easier to actually call the GHC API several times in rapid succession just by rapidly clicking the Run button in the web app. If there's anything I can do to get more information, I'm happy to do so as well. I'm not terribly familiar with the flags or options for GHC, as I've never done this before. -- Chris Smith ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHCi, version 6.10.1 crashes without message
I reproduced the error on my setup (GHC 6.10.1 on WS2003), and received SEH
exception 0xC0FD, which is STATUS_STACK_OVERFLOW A new guard page for
the stack cannot be created. It looks like something is overflowing the OS
stack or improperly bumping the guard page at the end of the allocated stack
(which is used to extend the stack on demand).
I could not get the crash to occur in GHC 6.8.3 via GHCi on the same system.
Instead, evaluation blocks forever with 0% CPU, interruptable with CTRL+C.
On Tue, Jan 13, 2009 at 10:15 AM, Heiko Studt st...@fmi.uni-passau.dewrote:
Hi (and hello everybody),
I read the FAQ, I searched down till Nov 2008, but did not find anything.
I hope I didn't miss a FAQ or somewhat. (If so, please apologize!)
My (freshly installed) GHCi 6.10.1 runs on Windows XP on Intel Dual Core.
I used the .msi of the Webpage some two weeks ago.
I got some strange program as example and tried out - and my ghci died
quitly without any helping message.
Here is the original programm:
| f x y z = a + b*c + b + fun c
| where a = x * y + z
| b = c * fun x
| c = a * b
| fun x = x * x + 1
For testing out in previous of this posting, the following is the very
same and had the same problem:
| let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c * fun x; c
= a * b; fun x = x * x + 1}
The query to die was f 1 2 3.
I tried with verbose ghci:
| C:\...\ghc-6.10.1\binghci -v
| GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
| Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted
by GHC
| version 6.8.3
| Using package config file: C:\...\GHC-61~1.1\package.conf
| hiding package base-3.0.3.0 to avoid conflict with later version
base-4.0.0.0
| wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
| wired-in package integer mapped to integer-0.1.0.0
| wired-in package base mapped to base-4.0.0.0
| wired-in package rts mapped to rts-1.0
| wired-in package haskell98 mapped to haskell98-1.0.1.0
| wired-in package syb mapped to syb-0.1.0.0
| wired-in package template-haskell mapped to template-haskell-2.3.0.0
| wired-in package dph-seq mapped to dph-seq-0.3
| wired-in package dph-par mapped to dph-par-0.3
| Hsc static flags: -static
| Loading package ghc-prim ... linking ... done.
| Loading package integer ... linking ... done.
| Loading package base ... linking ... done.
| Prelude let f x y z = a + b*c + b + fun c where {a = x * y + z; b = c *
fun x;
| c = a * b; fun x = x * x + 1}
| *** Parser:
| *** Desugar:
| *** Simplify:
| *** CorePrep:
| *** ByteCodeGen:
| Prelude f 1 2 3
| *** Parser:
| *** Desugar:
| *** Simplify:
| *** CorePrep:
| *** ByteCodeGen:
|
| C:\...\ghc-6.10.1\bin
I hope I could help finding some strange bug, killing 99% of your
problems with Haskell, life and love, although I am very sure
this one is only minor... ;-)
MFG (With friendly regards)
--
Heiko Studt st...@fmi.uni-passau.de
___
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
