better improvement for nm-classic message?

[Brandon Allbery]

It's slower the first time it is run but should be fast afterward unless
you switch active Xcode toolchains, as xcrun caches the result.

--with-nm=$(xcrun --find nm-classic)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Every GHC-compiled program seg-fault (HEAD)

[Austin Seipp]

Travis can't build on Windows, I'm afraid.

I'm sort of mitigating another crisis right now, but here's a shot in
the dark - based on my Very Amazing Deductive Skills[1], completed in
mere seconds, I'm guessing that perhaps
e68195a96529cf1cc2d9cc6a9bc05183fce5ecea is relevant, one of Simon's
latest commits? e.g., just try, as a shot in the dark

$ git revert e68195a96529cf1cc2d9cc6a9bc05183fce5ecea

And build again.

[1] Note: my Very Amazing Deductive Skills in this case, are as
follows. Look at git log for the last few days. See that some C code
was changed. Immediately become suspicious that is the culprit,
because it's C code. So, yes, a complete shot in the dark, but it's
one that's served me well, too. :)

On Wed, Apr 27, 2016 at 3:36 PM, Simon Peyton Jones
 wrote:
> Does anyone feel able to look at
>
> https://ghc.haskell.org/trac/ghc/ticket/11988
>
> The symptom is that every single GHC-compiled binary now seg-faults on
> Windows (with HEAD).
>
> That’s pretty serious.
>
> Can Travis pinpoint the offending commit?
>
> Simon



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Every GHC-compiled program seg-fault (HEAD)

[Simon Peyton Jones]

Does anyone feel able to look at
https://ghc.haskell.org/trac/ghc/ticket/11988
The symptom is that every single GHC-compiled binary now seg-faults on Windows 
(with HEAD).
That’s pretty serious.
Can Travis pinpoint the offending commit?
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Custom Type Error not getting triggered in the nested Type function call

[Iavor Diatchki]

Hi,

yes, this looks like a bug.  Could you please file a report on the
bug-tracker?

-Iavor

On Wed, Apr 27, 2016 at 9:43 AM, Magesh B  wrote:

> Hello,
>
> I have partial type function which is invoked by another type function.
> When the inner type function fails with TypeError, outer type function is
> not been able to propagate that type error to its caller.
> As a result of it, I'm getting following error
>   • No instance for (KnownSymbol (NestedPartialTF (TypeError ...)))
>  instead of
>   • Unexpected type @ NestedPartialTF: Char
>
> Is this a bug? This behavior seems bit counter-intuitive as to work
> around, I had to write another (duplicate) type function at the top level
> to get the desired type error
>
> I'm using GHC-8 RC 3 and have attached complete src for reference.
>
> Regards,
> Magesh B
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bikeshedding request for GHCi's :type

[Christopher Allen]

I agree with Iavor that :type should report the real type. I see this only 
stymieing and frustrating efforts to teach the language.

I do like the :inst idea.

> On Apr 27, 2016, at 12:22 PM, Iavor Diatchki  wrote:
> 
> Hello Richard,
> 
> I think that `:type` should report the real type of an expressions (i.e., the 
> fully generalized inferred type, just like it does now).  Certainly I 
> wouldn't want `:type` to show me some kind of (more or less) arbitrary 
> specialization of the type.
> 
> It could be useful to have a ghci command that would show all instantiations 
> of a class method (just 1 level deep) using the instances that are currently 
> in scope.  This would be essentially a combination of `:info` on a class and 
> a method.  For example, this is what it would look like on some of the 
> methods in 7.10's Prelude:
> 
> :inst length
> length :: [a] -> Int
> length :: Maybe a -> Int
> length :: Either a b -> Int
> length :: (a,b) -> Int
> 
> :inst (==)
> (==) :: Integer -> Integer -> Bool
> (==) :: Word -> Word -> Bool
> ...
> (==) :: Eq a => [a] -> [a] -> Bool-- Note that we only instantiate the 
> outer class
> ...
> (==) :: (Eq a, Eq b, Eq c) => (a,b,c) -> (a,b,c) -> Bool  -- ditto
> 
> :inst mapM
> mapM :: Monad m => (a -> m b) -> [a] -> m [b]
> mapM :: Monad m => (a -> m b) -> Maybe a -> m (Maybe b)
> mapM :: Monad m => (a -> m b) -> Either e a -> m (Either e b)
> mapM :: Monad m => (a -> m b) -> (e,a) -> m (e,b)
> 
> This could be generalized to expressions, rather than just methods, but for 
> expressions with multiple constraints one could get an explosion of possible 
> instantiations.  However, it would be quite cool to allow things like this:
> 
> :inst 1
> 1 :: Word
> 1 :: Integer
> 1 :: Int
> 1 :: Float
> 1 :: Double
> 
> Anyway, just some ideas.
> 
> -Iavor
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, Apr 27, 2016 at 8:16 AM, Manuel Gómez  > wrote:
> On Wed, Apr 27, 2016 at 10:15 AM, John Leo  > wrote:
> > Speaking as someone teaching his coworkers Haskell now, Eric's is the best
> > suggestion I've seen so far.
> >
> > What I like about it:
> > * The original meaning of :type is unchanged.
> > * No new command is added (I prefer adding a flag to adding another
> > command).
> > * With the flag on, the full type is shown along with the possible
> > specializations (and good to note the list might not be exhaustive).  This
> > way, beginners can still see what the type should look like even if they
> > want to ignore it for now.  This is similar to learning to read Japanese by
> > using furigana.  It may be a bit confusing for beginners at first, but I
> > expect they'll quickly learn to ignore it until they need it, and I agree it
> > will be useful for experienced Haskellers.
> 
> Perhaps a pleasant solution would be to borrow a convention from the
> PostgreSQL community's interactive console psql and its meta-commands:
> http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS
>  
> 
> 
> For example:
> 
> > \d[S+] [ pattern ]
> >
> > For each [object] matching the pattern, show all columns, their types, the 
> > tablespace (if not the default) and any special attributes such as NOT NULL 
> > or defaults. […]  The command form \d+ is identical, except that more 
> > information is displayed: any comments associated with the columns of the 
> > table are shown, as is the presence of OIDs in the table, the view 
> > definition if the relation is a view, a non-default replica identitysetting.
> 
> Many psql commands use this convention: add a + to the end of the
> command, and you get extra information.  It’s quite nmemonic.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bikeshedding request for GHCi's :type

[Iavor Diatchki]

Hello Richard,

I think that `:type` should report the real type of an expressions (i.e.,
the fully generalized inferred type, just like it does now).  Certainly I
wouldn't want `:type` to show me some kind of (more or less) arbitrary
specialization of the type.

It could be useful to have a ghci command that would show all
instantiations of a class method (just 1 level deep) using the instances
that are currently in scope.  This would be essentially a combination of
`:info` on a class and a method.  For example, this is what it would look
like on some of the methods in 7.10's Prelude:

:inst length
length :: [a] -> Int
length :: Maybe a -> Int
length :: Either a b -> Int
length :: (a,b) -> Int

:inst (==)
(==) :: Integer -> Integer -> Bool
(==) :: Word -> Word -> Bool
...
(==) :: Eq a => [a] -> [a] -> Bool-- Note that we only instantiate the
outer class
...
(==) :: (Eq a, Eq b, Eq c) => (a,b,c) -> (a,b,c) -> Bool  -- ditto

:inst mapM
mapM :: Monad m => (a -> m b) -> [a] -> m [b]
mapM :: Monad m => (a -> m b) -> Maybe a -> m (Maybe b)
mapM :: Monad m => (a -> m b) -> Either e a -> m (Either e b)
mapM :: Monad m => (a -> m b) -> (e,a) -> m (e,b)

This could be generalized to expressions, rather than just methods, but for
expressions with multiple constraints one could get an explosion of
possible instantiations.  However, it would be quite cool to allow things
like this:

:inst 1
1 :: Word
1 :: Integer
1 :: Int
1 :: Float
1 :: Double

Anyway, just some ideas.

-Iavor




















On Wed, Apr 27, 2016 at 8:16 AM, Manuel Gómez  wrote:

> On Wed, Apr 27, 2016 at 10:15 AM, John Leo  wrote:
> > Speaking as someone teaching his coworkers Haskell now, Eric's is the
> best
> > suggestion I've seen so far.
> >
> > What I like about it:
> > * The original meaning of :type is unchanged.
> > * No new command is added (I prefer adding a flag to adding another
> > command).
> > * With the flag on, the full type is shown along with the possible
> > specializations (and good to note the list might not be exhaustive).
> This
> > way, beginners can still see what the type should look like even if they
> > want to ignore it for now.  This is similar to learning to read Japanese
> by
> > using furigana.  It may be a bit confusing for beginners at first, but I
> > expect they'll quickly learn to ignore it until they need it, and I
> agree it
> > will be useful for experienced Haskellers.
>
> Perhaps a pleasant solution would be to borrow a convention from the
> PostgreSQL community's interactive console psql and its meta-commands:
>
> http://www.postgresql.org/docs/current/static/app-psql.html#APP-PSQL-META-COMMANDS
>
> For example:
>
> > \d[S+] [ pattern ]
> >
> > For each [object] matching the pattern, show all columns, their types,
> the tablespace (if not the default) and any special attributes such as NOT
> NULL or defaults. […]  The command form \d+ is identical, except that more
> information is displayed: any comments associated with the columns of the
> table are shown, as is the presence of OIDs in the table, the view
> definition if the relation is a view, a non-default replica identitysetting.
>
> Many psql commands use this convention: add a + to the end of the
> command, and you get extra information.  It’s quite nmemonic.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bikeshedding request for GHCi's :type

[John Leo]

Speaking as someone teaching his coworkers Haskell now, Eric's is the best
suggestion I've seen so far.

What I like about it:
* The original meaning of :type is unchanged.
* No new command is added (I prefer adding a flag to adding another
command).
* With the flag on, the full type is shown along with the possible
specializations (and good to note the list might not be exhaustive).  This
way, beginners can still see what the type should look like even if they
want to ignore it for now.  This is similar to learning to read Japanese by
using furigana.  It may be a bit confusing for beginners at first, but I
expect they'll quickly learn to ignore it until they need it, and I agree
it will be useful for experienced Haskellers.

John

On Tue, Apr 26, 2016 at 5:18 PM, Eric Seidel  wrote:

> I think design A (deeply instantiate + generalize) produces the most
> sensible types. I don't know what the curly braces mean (perhaps that we
> can't use type application anymore since the order changed?) but I don't
> think they'd show up at all without -fprint-explicit-foralls, right? If
> so, I'm not too concerned about it.
>
> I also think 2C is a neat idea and should be explored further, but I
> don't think it should be the default behavior of :type. I've always
> expected :type to print the exact type we would infer for the
> expression.
>
> Perhaps instead of changing the default behavior of :type or adding new
> commands, we could add a flag to enhance :type's output. For example,
>
>   > :type mapM
>   mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
>   > :set -fprint-type-specializations
>   > :type mapM
>   mapM :: (Monad m, Traversable t) => (a -> m b) -> t a -> m (t b)
>   Possible Specializations:
>   mapM :: Monad m => (a -> m b) -> [a] -> m [b]
>   mapM :: (a -> Maybe b) -> [a] -> Maybe [b]
>   ...
>
> I think this could be useful even for experienced Haskellers, though I'm
> a bit concerned that printing the full type at the top will leave
> beginners as bewildered as ever..
>
> Eric
>
> On Tue, Apr 26, 2016, at 06:08, Richard Eisenberg wrote:
> > Hi devs,
> >
> > Over the weekend, I was pondering the Haskell course I will be teaching
> > next year and shuddered at having to teach Foldable at the same time as
> > `length`. So I implemented feature request #10963
> > (https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way
> > for a user to request a specialization of a type. It all works
> > wonderfully, but there is a real user-facing design issue here around the
> > default behavior of :type and whether or not to add new :type-y like
> > commands. I have outlined the situation here:
> > https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type
> >
> > I'd love some broad input on this issue. If you've got a stake in how
> > this all works, please skim that wiki page and comment on #10963.
> >
> > Thanks!
> > Richard
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.0.1-rc4 source tarball availability

[Ben Gamari]

Karel Gardas  writes:

> Hi,
>
> distros for
>
> sparc-solaris2.11
> i386-solaris2.11
> x86_64-solaris2.11
> powerpc64-linux
> x86_64-openbsd5.9
>
> uploaded and signed in http://uloz.to/xPKKdvtV/bindist-tar
>
Thanks Karel!

I've started to fetch the tarball; I'll likely announce the release
later today.

Cheers,

- Ben


signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.0.1-rc4 source tarball availability

[Karel Gardas]

Hi,

distros for

sparc-solaris2.11
i386-solaris2.11
x86_64-solaris2.11
powerpc64-linux
x86_64-openbsd5.9

uploaded and signed in http://uloz.to/xPKKdvtV/bindist-tar

Thanks,
Karel

On 04/22/16 04:27 PM, Ben Gamari wrote:

tl;dr: If you would like to produce a binary distribution for GHC
8.0.1-rc4 then let us know, grab the source distribution and
start building. The binary distributions will be all released one
week from today.


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: perf.haskell.org’s list of branches got more useful

[Joachim Breitner]

Hi,

Am Mittwoch, den 27.04.2016, 05:42 +0200 schrieb Bardur Arantsson:
> You can always shorten the text or use abbreviations and then add
> hover
> text with the 'full name' of the column. Mouse hover text isn't *great*
> UX-wise, but probably better than nothing. It's generally a little less
> 'discoverable' even if people are generally used to the idea of hover
> tooltips. Additionnaly, I'm not sure how well this will work for blind
> people who use screen readers.

I believe this is getting off topic on this list; I invite you to
continue brainstorming on https://github.com/nomeata/gipeda/issues/37


Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs