Re: Avoid blank line separating code and comments in Bird style?

2015-01-13 Thread Mateusz Kowalczyk 
On 01/13/2015 10:28 AM, R Sidhu wrote:
> Hi
> 
> This regarding GHC behaviour for literate Haskell programs in Bird
> style. GHC expects a blank line between comment[1] and code.
> Otherwise, during the literate pre-processor stage, the error
> 'unlit: Program line next to comment' is reported.
> 
> While above behaviour makes sense in general, there are situations
> where one would like to place comments adjacent to code with no
> intervening blank line. For example, in documenting a declaration
> using Haddock (in standard, non-literate Haskell), as shown in
> sections 3.1
> 
> and 3.2  of the
> Haddock User Guide, no blank line
> separates comment and code.
> 
> Any way to enable GHC to accept Bird style literate programs with
> no blank lines separating comment and code?
> 
> [1] 'Comment' (in context of Bird style) refers to text on lines not
> beginning with '>'.
> 
> Regards
> Sidhu
> 
> 

I don't understand the motivation here. If you want to use Haddock with
literate Haskell it has to look something like

> -- | Foo
> someCode = undefined

I believe it does not matter to GHC whether we give it

-- | Foo, no blank line
someCode = undefined


or


-- | Foo, blank line

someCode = undefined


Haddock would see both as just someCode with a comment attached.

I imagine you're suggesting that something like


Literate comment
> someCode = undefined


is allowed but your justification using Haddock doesn't make sense in
this case: ‘Literate comment’ will not be visible.

Correct me if I'm wrong on anything here, I very rarely use the .lhs .

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RFC: Unicode primes and super/subscript characters in GHC

2014-06-15 Thread Mateusz Kowalczyk 
On 06/14/2014 04:48 PM, Mikhail Vorozhtsov wrote:
> Hello lists,
> 
> As some of you may know, GHC's support for Unicode characters in lexemes 
> is rather crude and hence prone to inconsistencies in their handling 
> versus the ASCII counterparts. For example, APOSTROPHE is treated 
> differently from PRIME:
> 
> λ> data a +' b = Plus a b
> :3:9:
>  Unexpected type ‘b’
>  In the data declaration for ‘+’
>  A data declaration should have form
>data + a b c = ...
> λ> data a +′ b = Plus a b
> 
> λ> let a' = 1
> λ> let a′ = 1
> :10:8: parse error on input ‘=’
> 
> Also some rather bizarre looking things are accepted:
> 
> λ> let ᵤxᵤy = 1
> 
> In the spirit of improving things little by little I would like to propose:
> 
> 1. Handle single/double/triple/quadruple Unicode PRIMEs the same way as 
> APOSTROPHE, meaning the following alterations to the lexer:
> 
> primes -> U+2032 | U+2033 | U+2034 | U+2057
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes)
> graphic -> small | large | symbol | digit | special | " | ' | primes
> varid -> (small { small | large | digit | ' | primes }) (EXCEPT reservedid)
> conid -> large { small | large | digit | ' | primes }
> 
> 2. Introduce a new lexer nonterminal "subsup" that would include the 
> Unicode sub/superscript[1] versions of numbers, "-", "+", "=", "(", ")", 
> Latin and Greek letters. And allow these characters to be used in names 
> and operators:
> 
> symbol -> ascSymbol | uniSymbol (EXCEPT special | _ | " | ' | primes | 
> subsup )
> digit -> ascDigit | uniDigit (EXCEPT subsup)
> small -> ascSmall | uniSmall (EXCEPT subsup) | _
> large -> ascLarge | uniLarge (EXCEPT subsup)
> graphic -> small | large | symbol | digit | special | " | ' | primes | 
> subsup
> varid -> (small { small | large | digit | ' | primes | subsup }) (EXCEPT 
> reservedid)
> conid -> large { small | large | digit | ' | primes | subsup }
> varsym -> (symbol (EXCEPT :) {symbol | subsup}) (EXCEPT reservedop | dashes)
> consym -> (: {symbol | subsup}) (EXCEPT reservedop)
> 
> If this proposal is received favorably, I'll write a patch for GHC based 
> on my previous stab at the problem[2].
> 
> P.S. I'm CC-ing Cafe for extra attention, but please keep the discussion 
> to the GHC users list.
> 
> [1] https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts
> [2] https://ghc.haskell.org/trac/ghc/ticket/5108
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

While personally I like the proposal (wanted prime and sub/sup scripts
way too many times), I worry what this means for compatibility reasons:
suddenly we'll have code that fails to build on 7.8 and before because
someone using 7.9/7.10+ used ′ somewhere. Even using CPP based on
version of the compiler used is not too great in this scenario because
it doesn't bring significant practical advantage to justify the CPP
clutter in code. If the choice is either extra lines due to CPP or using
‘'’ instead of ‘′’, I know which I'll go for.

I also worry (although not based on anything particular you said)
whether this will not change meaning of any existing programs. Does it
only allow new programs?

Will it be enabled by a pragma?

I simply worry about how practical it will be to use for actual programs
and libraries that will go out on Hackage and wider world, even if it is
accepted.

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Module that causes GHC-7.8 to exhaust memory when -O2 is on

2014-03-29 Thread Mateusz Kowalczyk 
On 29/03/14 17:31, David Fox wrote:
> The repository at http://src.seereason.com/o2bug contains a package that
> causes GHC-7.8.1 (rc2?) to exhaust 16GB of RAM and die when the -O2 flag is
> turned on.  I haven't been able to simplify it very much, almost any change
> to JSON.Render causes it to start working properly.  I did get it to fail
> using only packages available in hackage.  Just thought I should let folks
> know about this issue.  Let me know if it fails to fail.
> 
> Maybe someone who can log in could put this in trac.
> 
> 
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

You can log in to Trac with username ‘guest’ and password ‘guest’ I believe.

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: RC2 build failure on Debian: armhf

2014-03-15 Thread Mateusz Kowalczyk 
On 14/03/14 20:05, Joachim Breitner wrote:
> Hi,
> 
> armhf still fails like in RC1:
> https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armhf&ver=7.8.20140228-1&stamp=1394723755
> [..]
>0% (  0 /  5) in 'WwLib'
>0% (  0 /  2) in 'DmdAnal'
>0% (  0 /  2) in 'WorkWrap'
> 
> compiler/typecheck/TcSplice.lhs-boot:29:1:
> TcSplice.tcTopSpliceExpr is exported by the hs-boot file, but not 
> exported by the module
> 
> compiler/typecheck/TcSplice.lhs-boot:37:1:
> TcSplice.runMetaE is exported by the hs-boot file, but not exported by 
> the module
> 
> compiler/typecheck/TcSplice.lhs-boot:38:1:
> TcSplice.runMetaP is exported by the hs-boot file, but not exported by 
> the module
> 
> compiler/typecheck/TcSplice.lhs-boot:39:1:
> TcSplice.runMetaT is exported by the hs-boot file, but not exported by 
> the module
> 
> compiler/typecheck/TcSplice.lhs-boot:40:1:
> TcSplice.runMetaD is exported by the hs-boot file, but not exported by 
> the module
>   67% (  2 /  3) in 'CmmPipeline'
>0% (  0 /  3) in 'StgCmmHpc'
>0% (  0 / 13) in 'PrelInfo'
>0% (  0 /  4) in 'StgCmmCon'
>0% (  0 /  2) in 'StgCmmExpr'
>0% (  0 /  6) in 'StgCmmBind'
>0% (  0 /  2) in 'CmmParse'
>0% (  0 /  2) in 'StgCmm'
>5% (  9 /175) in 'TcRnMonad'
> make[2]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1
> 
> 
> Any ideas? Anyone feeling responsible?
> 
> Thanks,
> Joachim
> 
> 
> 
> 
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 

Does building without docs work? Does building HEAD with docs work?

I don't have an ARM machine to try and while it looks like Haddock
messing up, I'm somewhat sceptical that's where the problem is.

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: haskell xml parsing for larger files?

2014-02-20 Thread Mateusz Kowalczyk 
On 20/02/14 11:30, 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.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
> 

HXT will not work for you, you will run out of memory on files ~30MB. I
don't know about xml-conduit, I'd love to hear how it goes if you try it.

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Enabling TypeHoles by default

2014-01-13 Thread Mateusz Kowalczyk 
On 13/01/14 21:30, Daniil Frumin wrote:
> On ghc-dev Dominique Devriese has actually proposed changing TypeHoles
> to TypedHoles or to something similar, because "TypeHoles" sounds like
> you can have holes in types, just like in your example.
> 
> But what error message do you want to get if you have a hole in your
> type? GHC won't be able to tell you much
> 

Indeed I have seen the ghc-devs post. Using Hole instead of stating a
type is useful for me to me for two things:

* Causing type errors for type of the expression, for example to
specialise part of the signature and see what GHC infers for the rest of it

* Easily checking types of the expressions I'm working on inside of the
function. Sometimes one might lose track of types inside a larger
expression and it is useful to cause a type error with a hole on one of
the sub-expressions to see where we're at. GHCi doesn't provide a way to
check type of subexpressions, only top-level definitions so this is
particularly useful.

While the second problem can be mitigated in simple situations where we
have a single symbol expression such as

foo :: Integer -> Integer
foo x y = x + _y

the ‘_’ does not work for larger expressions. For example, the following

foo :: Integer -> Integer
foo x y = x + _(y + 3)

does not work as it actually gets translated to

foo :: Integer -. Integer
foo x y = x + _ (y + 3)

and rather than get the type of (y + 3), we get the type of the function
which takes that expression. Close but not quite. With _ for types I
could do

x + (y + 3 :: _)

as opposed to

data Hole
x + (y + 3 :: Hole)

It'd be great if I could spare myself defining Hole *and* get all the
information about bindings that _ provides.

-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Enabling TypeHoles by default

2014-01-13 Thread Mateusz Kowalczyk 
On 13/01/14 18:42, Krzysztof Gogolewski wrote:
> Hello,
> 
> As discussed on ghc-devs, I propose to enable -XTypeHoles in GHC by
> default. Rationale:
> 
> (1) This way holes are far easier to use; just entering "_" allows to check
> type of a subexpression, no need of adding "-XTypeHoles".
> 
> (2) This affects error messages only; i.e. the set of programs that compile
> stays the same - Haskell 2010. The only exception is that if you use
> -fdefer-type-errors, then a program with a hole compiles, but this seems
> fine with philosophy of -fdefer-type-errors.
> 
> If so: would you like it to be in 7.8 or wait a cycle? My preference is
> 7.8, two people (John and Richard) suggested 7.10.
> 
> -KG
> 

Sounds good. Are there plans to allow TypeHoles to actually sit in place
of types? In the past I did

```
data Hole

hole :: Hole
hole = undefined

foo :: Integer -> Integer
foo x = hole

bar :: Integer -> Hole
bar x y = x + y
```

to cause type errors that could guide me. I now don't have to resort to
the first use in ‘foo’ but I still have to define my own Hole type in ‘bar’.


-- 
Mateusz K.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overloaded record fields

2013-06-24 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/06/13 11:05, Mateusz Kowalczyk wrote:
> On 24/06/13 11:04, Roman Cheplyaka wrote:
>> * Mateusz Kowalczyk  [2013-06-24 
>> 10:47:09+0100]
>>> Restricting function composition to have spaces around it will 
>>> require changing a large amount of existing code if one is 
>>> willing to use it.
> 
>> I assume this semantics will be triggered only by an extension,
>> so there'd be no need to change existing code.
> 
>>> While I personally would like the restriction because I hate 
>>> seeing people skimp out on whitespace around operators, there
>>> are a lot of people with a different opinion than mine and I
>>> imagine it'd be a great inconvenience to make them change their
>>> code if they want to start using SORF.
> 
>> Well, if they *want* it, it's not unreasonable to require them
>> to *pay* for it (in the form of adjusting their coding style).
> 
>> Roman
> 
> Sure that it's unreasonable to have them change some of their code
> to use new, cool features. I'm just questioning whether it's
> absolutely necessary to do it by forcing restrictions on what is
> probably the most commonly used operator in the whole language.
> 
> 
> ___ 
> Glasgow-haskell-users mailing list 
> Glasgow-haskell-users@haskell.org 
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
That meant to say `that it's *not* unreasonable'.
- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRyBp0AAoJEM1mucMq2pqXHbEP/3myuTjcUiG59ee3/32PFZTQ
Qb0308VmgTzTMhZCKosn+iymgLm1DFThR5P3aOgRgixn2gnvIpf7tu3GhAYvn+5Q
BzpNwWOt17+sFBf0ovLW3bdFmKDQhzPy5OTtCcTDBAf6AyRJLFlTFRMFl4oQWpuF
KI34M0gNwKjh2NIDk3z21afVG7go9rdxtRZwMV9OqVwFgeAKJ4QY2U5kPu47p8cr
HOZzaPsPsdf89Izaun8X3ApYLO0fDvi55nbogTJCEN+BoqK/+ZE/upDAoLJB4k6m
iuFA86RmfJfHgrIWp2EpR3G7G6+jW/1gwOrx5RjXjyW6SzBTBuhcBQdmtIZXTqih
PhpWMmydS4iwYJWIAekiPbO2pCFlgeN++NJ4fyt2b8ypVfRm27k+xjfRso/up9gf
dNgU7WXlx1tm0mzLWzauMojK65HEDVd8IjQ0DRj9Prmr0EiB9e/KbrR592YFAl+p
7fvAGxV5Vc83LRN0smIg9RrHrPe8hVeDJTKbU5KU0QURil3RIMatIy0MNebIoz6u
csnmcXBKmYKGMifAvNYLOFGrwlvIEGdb0oPDf8WlP2A6LPDEecBLW1x9KUIMeLVf
b/x8KiGVw49J4Osr0vwI3U8ThxgrksNqHVPdxLYS5GvbPT8+74EPmMTVTixFOROY
oK26lPQ7hEUb++bGCBR+
=QZmK
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overloaded record fields

2013-06-24 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/06/13 11:04, Roman Cheplyaka wrote:
> * Mateusz Kowalczyk  [2013-06-24
> 10:47:09+0100]
>> Restricting function composition to have spaces around it will
>> require changing a large amount of existing code if one is
>> willing to use it.
> 
> I assume this semantics will be triggered only by an extension, so 
> there'd be no need to change existing code.
> 
>> While I personally would like the restriction because I hate
>> seeing people skimp out on whitespace around operators, there are
>> a lot of people with a different opinion than mine and I imagine
>> it'd be a great inconvenience to make them change their code if
>> they want to start using SORF.
> 
> Well, if they *want* it, it's not unreasonable to require them to
> *pay* for it (in the form of adjusting their coding style).
> 
> Roman
> 
Sure that it's unreasonable to have them change some of their code to
use new, cool features. I'm just questioning whether it's absolutely
necessary to do it by forcing restrictions on what is probably the
most commonly used operator in the whole language.

- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRyBnOAAoJEM1mucMq2pqXX54P/Rn4czScB9SMJnOMawzwHU3k
SiPRGjflgzTM3OK4D7AxF5q02jX0TbkS5GeZvXyQ59e8q1qeyvK9cXQsDX8v1GEb
oxx1bc+sNRhjz+8aSBvu3uBIVPq1VY6QHD7sQbmYCPMjfJLVXzI5XsWIpSnam0q8
8xBSeC93TaPTxloRzEFnxF2maAjIJ5YR3kXzb+xCUBrF1D6++P1gQKcseuFL+E4p
kqfaOMz4bdQ6T0fpzgZDvXGgopVz8J5pm0FfHTzhRJbCuWi7B9Ubpbt9a4mwtJo5
QZqozDuAFVy1b9MEBiGSh+XJDEFIrR6EdDvD9DXVE4qEr/3CNFL/HEXoEpaYchgw
kpxyzFLWyBOYPRk7z1D+Ge/hzoeAk11U4hj5BbTBtRQLgK/5rXgVprqn1cYFJhr5
bAlvip7+4Dns6NkA/mS9+14dQW97lvPhZcnhUnuRxFvyqTBTmqdlU5dyllDG7C4/
yJ1DY/kPpF94T6jyCJ85EAQmYxCRzSRMCvRTYzjwQTPZVbM2+WnQ9zdr/tJ6vuvW
Mb3PiAQnZEpl7dMv3PSEfkPToLAVwDM+9SFVpVkw9ICs1sjaK6V/NlCJDFtRGSBv
4P/FUYCMQpo/6W71e4IyYDuS0R5UyrTWu7QjCSWoO6jec3tVvwVxT/+ZKkCVzO8e
27eHbi3j/QC0Qe/FIkKD
=NRx3
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Overloaded record fields

2013-06-24 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24/06/13 08:44, Adam Gundry wrote:
> Hi everyone,
> 
> I am implementing an overloaded record fields extension for GHC as
> a GSoC project. Thanks to all those who gave their feedback on the 
> original proposal! I've started to document the plan on the GHC
> wiki:
> 
> http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/Plan
>
>  If you have any comments on the proposed changes, or anything is
> unclear about the design, I'd like to hear from you.
> 
> Thanks,
> 
> Adam Gundry
> 
> ___ 
> Glasgow-haskell-users mailing list 
> Glasgow-haskell-users@haskell.org 
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
On the wiki, you say ` It is critical to support dot-notation.' and
then you follow up with multiple reasons on why this is troublesome
because of the conflict with function composition.

You say `There is an overlap with the function composition operator,
but that is already true with qualified names.'

True, but qualified names always have LHS starting with a capital
letter while records wouldn't. I don't see how this is a supporting
argument.

Then you write:
Function composition will only work when surrounded by spaces,
thus (f . g).
Dot-notation for record selection only works with no spaces.

Restricting function composition to have spaces around it will require
changing a large amount of existing code if one is willing to use it.
While I personally would like the restriction because I hate seeing
people skimp out on whitespace around operators, there are a lot of
people with a different opinion than mine and I imagine it'd be a
great inconvenience to make them change their code if they want to
start using SORF. Have you considered not using a dot to begin with? I
imagine the reason behind the dot is that it makes it look like
methods on objects in OO languages which is a rather poor justification...

- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRyBWdAAoJEM1mucMq2pqXD08P/3MhVNa9GnuIABb5MT8gAq3Z
yuV/NJE4briRwtoM9ki2hciRbTluY0t7F0WlcjDgwmd2c7tO7XzGZFwx6RwsVQM6
4/fQ2jo2/HKR5+6IX3CF2zkKZGyZSUdaqdGFLUbTNw/VYnU7sP9l4TyvpEEB7P78
tCoycZ193qwH0V7I7Am57PSebFKtgKhmjXU9HKLT3wa1HRcFY5UDgi4fj/EoAHG+
ZAmxlg+8NhLbnR3lHNXC+8vUo6eG6TEf50Qn2MJNMW2CHSl8OyN+yFzTI0OO4yEK
gIirzzwz+hp4X/WOKVwUnRasv/j9EjTDx1f3ZwoJlT6UAKwh+TUxDNn8oIgLEyxi
9Vik73kvyCBBaWq8/K5CGYGtRrYQurZHBdxtfmiPe8HWWwYhNY2UKkEpKQhxzQJ2
aIl9coocdHWpbAW201dYBXkmC+Ey/oXDbubL/csaXH1kRF0HXghUacUIhIiYedk0
o5mySfd6SnsQ/Kqzjj2HM5Q0ib+5ExYmOgI21hEmWqjeeOz/oKamgaPTcrbXhWaQ
IY9isLnZwOYziGF6gs16TNfSvy8NCARCW03NjxM8gDxgXAC60ZNivZsfJ2ErjxY6
4cPqMmkXNbVTNssMbc+h4dpDGiQkwxrZKOP+RY1dp0mFtE7uY27RPRYgyW9LXfyO
L5EqGQoT18iVh7BZ7Ra7
=mkvJ
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Debugging GHCi

2013-06-01 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Nowadays I'm looking at Haddock and amongst other things, recent GHC
is a must. Due to this, I now have 7.6.3 on my system as well as a
build from yesterday (7.7.20130531), straight from git HEAD.

Building Haddock with --enable-tests, I then try to run some hspec (or
probably more appropriately, nanospec) tests. Simple stuff:
> ghci src/Spec.hs

> Prelude> :main

Tests run as expected and everything is fine until about 2 seconds
after main terminates: GHCi segfaults.

As a means of checking whether this is a problem with GHCi, I ran the
same commands with my 7.6.3 install and everything was fine - no
segfault. This clearly points to something being wrong with GHCi.

My question is, how would I even begin to investigate what's wrong? If
I want to file a bug, I need to have more information, especially
considering that someone I asked could not reproduce this. I have no
experience with GHCis guts and I'm not sure how to progress.

- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRqnINAAoJEM1mucMq2pqXSbEQAIM9+czAgoyHJQ4LCI+eRMWP
yM6pCxvQH5XLfSg6dD9UJASqsZ3kgaQcJsx77c1PCDXyU11hF5x3MygKOBKcqXoO
fC/khWqp1ru17tOhJ9nfpCTFm6HUI9RGKRYBJhsrUkv1DzY6tw5kJuwFqf/9e9jF
Om9wiqA1Sp0L1YEGnjcQ+ZB2/5gekPK4Il1iSWujrvo9JzGzJULXo94sxAXNa9P+
xuaSpTxKP1+6+zmuK1sSYgNNCP8b5yKXgwUjjI25s8MP6usXpvz5YRs760zMlpFl
l9ZepNMiWgcL9dxWI3g8TFrm3jE5EVgIQ+/3ytEoRuetYU713Dj4DQSu5dZkxZku
wdWuy/HVBOqpQf+fbMqlH4vW4Q4QIJbnU+qsRr6nNyoyEvGvuom4gXC18fHYqJST
r03WD/UXlF4KTXD45flypeOnkRrcFiws76gdRqwiXpec0WxmYjEYGzbIARfQrU9V
xWoykrTmVCbE8uG8FktXcjzirSAK5HAsy0sceurgPT8FDmSn9AFF03pOiW/A8Hli
d8WrS5uuTWprzFFaUtpPbERWLOxieLNJrpXeeKKICVLF4VNzlrjw9regToYh2rTq
tMaJgP61E8Vji2NhR1bk/TPPdOFtEB+cJnXDrn9Z6ICJlAmHXVCCQJA7KmsX5WGA
NEqif1T5kIkHLc0FUmZl
=nTqG
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: nightly builds: empty directory

2013-05-20 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20/05/13 17:08, Carter Schonwald wrote:
> Henning, you can git clone ghc from github and follow the
> directions on the trac wiki to build your own ghc they will
> correspond with head.
> 
> On Monday, May 20, 2013, Henning Thielemann wrote:
> 
>> 
>> The page
>> 
>> http://www.haskell.org/ghc/**download
>>
>>
>> 
refers to directories for the nightly builds, that are actually empty:
>> 
>> http://www.haskell.org/ghc/**dist/current/dist/
>>
>> 
http://www.haskell.org/ghc/**dist/stable/dist/
>> 
>> :-(
>> 
>> __**_ 
>> 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
> 
I'd like to add that there's already a thread about this very thing on
ghc-devs at [1].

[1] - http://www.mail-archive.com/ghc-devs@haskell.org/msg01214.html

- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRmlzzAAoJEM1mucMq2pqX120P/0517GGdtRUHzbGUNreTR9yz
b4UW0GbznnO4mzKGemSWjSQLH8AeFCPPOnCNO2EqfytyexJ58y8UzjwPvbxtB5Mf
H0xmWNcLoUmmPgRSfpKIw4MlOTpKYhpv8N2Equl26nH22lmtsG6S80ex8d7FROcm
8QIZ/NlK7T77IjqxKHZX4D4ZMWGqTQG3Q3RAaYnHSHbc1ApZ0Io8lj8bPUXQeiSe
sOLYW2V9wL5DQW43KxGnr4cCOFZugSiioCDlsN8Ko9cREU2qLEcXgmsN9iV0zaR2
ScEuKOTw/jSWAyp9T/ywV52XsByhpQKCe90rqXWdRJMyU7ZJtG5OqBftzSWNJppS
0WaQ/NxqK0xtfHXxS1oCtxyoIIfpq+2Lu/z0Rahi9ahXJ3ltlZOFjmr1utETf0HN
Jb2EhjaHfqMZ9PYx7P6DKpIzMkgWSRUMlBsQuRj2idhD8Qn5YX2KeZnt+xjclVA0
xrrtHQlC1dVN6Bmmy4xft+cagktwdGm6eLIyEAY2B5sebV2aaZEkNtKPX6clX8WV
GDLvo1ey1G+AhJJ3Xr25148ehF8NuP0S0iHV95haWj/lxVlreG5CgtJaCvkn14ap
tJ8GNTWg5Oh3DqIyNv6lH1BBcW1G1VLdSM4ALMGeXFl81nd2cJVC1PXBhAnDvc6T
YgNMVRQWkK9NIcNYU5aM
=pFS3
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Missing snapshots

2013-05-12 Thread Mateusz Kowalczyk 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

On the GHC download page [1], there are no available snapshots. Both
HEAD and STABLE branch dist directories are empty.

Any idea what the deal is?

[1] - http://www.haskell.org/ghc/download
- -- 
Mateusz K.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQIcBAEBAgAGBQJRj4bJAAoJEM1mucMq2pqXahAQAKS+IbI7BReGmuNWaPvkova5
eg+4yKcgC3wMeeOBocSYC7B+8x6p0XZaz8gY2BaOOfInDWeuCdHtXAtd3VCQf/5B
ZLTPxZztFwW9TNn28YnW9OmB09H3fmsFT3eMRYWJ7sEkVuuetWmsbYHKlUfXCs1o
f3fzK9N6iauvCMpbrYQyh1CIObltmh9xIuLl3pAQ5rFOlGqPrW8p3bMxyk1KF0gA
973yBgsWV0rlPx2/xysXXlxhZIpK5LLzJVzCKMBEqCE+8Uii/jtLFyps2ZCYOiI/
q4634JzTj13LR+wlxIRRQUqySTklGvBoWU0n5ZIhlB8AvMxoc7UCn7LfYMYDnwBb
C9Y9PMLoPS3XCVqrN2pQ8UCnqaTgzGRYAvbDjQGb51ta+DgppYnz7pKw+fWnV2X+
+OEjyEe10CQ0hsLyQ1mRUi/dI2b0RyypRP/q0PZiQ8qYurwel3W8+nsbt9NvkEdo
ZzNKmF+lRJGQEuj4cILkdepHX9DOhjBgIRma6Y6BcaurAnJtDKFrP9a5OAV7g1CB
T2tAJiEuYUHtIrAMaRqcRsCXwi/+1jJTv/bmeoAiniXh15l56L8dIQLt1Og05Dsq
haZqiLxOKzCib7k9AZJgE0wd8B1mFXv0E31cYCyMworGJU89aWkaKG+Bjlf2xWOS
mqVoJArrZCv7tkYoLdN2
=rENI
-END PGP SIGNATURE-

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users