I get the errors when running the testsuite too, but I excerpted the
earliest recache warning from my full validation run. The same tests
consistently fail for me.
I only get the errors when running the testsuite with BINDIST=YES, as
expected.
Geoff
On 06/24/2013 12:49 PM, Jan Stolarek wrote:
The same tests consistently fail for me.
Even if you run them separately with 'make TEST=failingTest'?
I only get the errors when running the testsuite with BINDIST=YES, as
expected.
I'm running validation without BINDIST=YES at the moment, will run the second
validation later.
Where do you
I thought it was obvious that I only meant that it was reliable for me :)
Reliable for me is a bit of oxymoron in the context of validating correctness
of software :) I
guess that's why I titled this thread Unreliability of the build system.
I'm running ext4.
Is there any method by which you
On 2013-06-24 22:25, Iavor Diatchki wrote:
I think that good support for writing literate Haskell in markdown
notation would be great! Over the weekend I updated the wiki page with
a fairly detailed description of the proposal, which Trevor implemented.
What do folks think about the
This argument is a little tenuous in my opinion. Markdown is very
ill-specified formally speaking with many implementations (including
our beloved Pandoc) featuring various extensions. It is not really a
'standard' in the typical sense. Pandoc actually only recently
supported 'GitHub code
I'm not against adding this to GHC, but it's trivial to have it as a
separate program (see my markdown-unlit [1]). Maybe the external
program is more flexible when it comes to extending/bug fixing?
But if you decide to add it to GHC, then please also add test cases for
the proposed code.
As a
I would definitely take advantage of this feature (for blog posts
mostly) if it gets merged.
+1
On Mon, Jun 24, 2013 at 1:25 PM, Iavor Diatchki
iavor.diatc...@gmail.com wrote:
Hello,
I think that good support for writing literate Haskell in markdown notation
would be great! Over the weekend
On 06/24/2013 09:21 PM, Jan Stolarek wrote:
My only claim was that I have a set of steps that can reliably reproduce
an error on my system, not that these steps will reliably reproduce it
on an arbitrary system, e.g., yours. Still, being able to reliably
reproduce an error, even if only on one
Just a quick update: I patched a local copy of 7.6.3 to add
FastString.string_table to the CoreMonad.reinitializeGlobals mechanism.
After that change, I can invoke the front-end
(parser,renamer,typechecker,desugarer) from within my plugin on a simple
example.
Original module:
module Test where
