ain = getContents >>= putStr . renderTags . flattenTree . tagTree .
> parseTags
>
> which also ends with the getMBlock error.
> Only "renderTags . parseTags" works fine (like the hexpat SAX parser).
>
> Why should tagsoup be better suited for building trees from larg
Have you looked at tagsoup?
On Feb 20, 2014 3:30 AM, "Christian Maeder"
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.inform
+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 ei
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 pa
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
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
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 see
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 Ju
jor 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).
--
g 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
__
On Jan 12, 2012 9:18 PM, "Morten Brodersen" <
morten.broder...@constrainttec.com> wrote:
>
> Unfortunately most unix/windows/tools/source
> controls/editors out there are Ascii only.
This is probably not true. I'm among the most annoyed people at this
Unicode trend... but the problem is in text e
On Tue, Dec 20, 2011 at 5:57 PM, Matthew Farkas-Dyck
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
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 si
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 e
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 th
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
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
ing 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
__
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 s
19 matches
Mail list logo
