Re: Windows build broken (again)

[Brandon Allbery]

On Thu, Oct 2, 2014 at 4:39 PM, Simon Peyton Jones simo...@microsoft.com
wrote:

 Presumably this is some kind of Windows escape-character problem.  But it
 has worked fine for years, so what is going on?


At a guess, something that was using / is now using \ and getting eaten by
the shell. Or quoting that was preventing the \s from being eaten has been
lost somewhere.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Source-markup language for GHC User's Guide

[Brandon Allbery]

On Tue, Oct 7, 2014 at 11:24 AM, Austin Seipp aus...@well-typed.com wrote:

 The more annoying bit is it will incur an extra dependency for GHC
 documentation - which, remember, is part of ./validate - but that's
 life, perhaps.


Docbook is a fairly large dependency in my experience?

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Curious Windows GHCi linker behaviour .o vs. .dll

[Brandon Allbery]

On Sat, Oct 11, 2014 at 9:24 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:

 Moreover, compiling and running the program still works, and the
 additional underscore is visible in `nm` as well:


Sounds like ghci's linker doesn't resolve weak symbols?

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Curious Windows GHCi linker behaviour .o vs. .dll

[Brandon Allbery]

On Sun, Oct 12, 2014 at 6:11 AM, Herbert Valerio Riedel hvrie...@gmail.com
wrote:

 Personally, I think this was a very questionable decision on
 Microsoft's part, as this way you effectively destroy any chance to
 simply compile existing POSIX-compatible source code for no good
 reason...


POSIX doesn't specify asm or linker level symbols, only C API. Most
Unix-like platforms have an underscore on the front of symbol names at link
level, so that the API doesn't have to avoid random platform-specific
register names or the assembler need to have magic prefixes on either
symbols or register names. So in fact, by adding the prefix underscore they
are *more* compatible with Unix linkage, and presumably the FFI for Windows
needs to start adding it the way the one for Unix does.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Problems adding a custom section to a Windows binary

[Brandon Allbery]

On Sun, Oct 12, 2014 at 6:28 PM, Gintautas Miliauskas 
gintautas.miliaus...@gmail.com wrote:

 I'm not sure if this is a gcc/binutils bug or not (the exact same commands
 with the same tools work fine on Linux binaries).


There are huge differences between Linux ELF and Windows PE32/PE64; it
would not be surprising if libbfd had bugs in the latter but not the
former. Beyond that, I don't know.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Avoiding the hazards of orphan instances without dependency problems

[Brandon Allbery]

On Sun, Oct 19, 2014 at 1:02 PM, David Feuer david.fe...@gmail.com wrote:

 with a flag -XAllowForbiddenInstancesAndInviteNasalDemons


One could argue this is spelled -XIncoherentInstances

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC Weekly News - 2014/10/20

[Brandon Allbery]

On Mon, Oct 20, 2014 at 10:22 AM, Austin Seipp aus...@well-typed.com
wrote:

 https://ghc.haskell.org/trac/ghc/blog/edit/weekly20141020


You might want to provide the ordinary mortals link instead of the edit
link. :)

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC Weekly News - 2014/10/20

[Brandon Allbery]

On Mon, Oct 20, 2014 at 10:26 AM, Alan  Kim Zimmerman alan.z...@gmail.com
wrote:

 All you have to do is edit out /edit/ in the URL


Yes, I did that. It's still better to not require people to do that

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Brandon Allbery]

On Thu, Oct 30, 2014 at 5:00 AM, Jan Stolarek jan.stola...@p.lodz.pl
wrote:

 Projects like Scala and Clojure require filling in a Contributor
 [License] Agreement. I have not
 bothered to investigate the exact purpose.


In the absence of a license agreement, the contribution is usually owned by
the submitter and not the project (copyright, see Berne convention). This
doesn't scale very well. A signed CLA allows the project to demonstrate
that the submitter has agreed to transfer ownership of the contribution to
the project('s administrators).

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: RFC: Properly stated origin of code contributions

[Brandon Allbery]

On Thu, Oct 30, 2014 at 11:25 AM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 I'm happy to ask the IP lawyers in my family for some opinions on this but
 I think what we are doing now is fine.


As Joachim already noted, it's a bit late to switch course for GHC; you'd
have to track down every past contributor. (I've been involved with
projects that needed to do that; if at all possible, avoid it.)

The reality, as I understand it (note that I Am Not A Lawyer(tm) but have
experience with projects that have had to face the question), is that
there's complex interactions between copyright law and contract law (not to
mention questions of how contract law affects contributions to an open
project). And both have a certain valid until proven otherwise aspect,
which often makes it wisest to not change what's already working well
enough --- especially since even asking a lawyer on the clock can
potentially have legal implications on the whole project (but only if
someone actually challenges in court and brings it up). As a result, the
FUD's kinda built into the legal structure. :/

(My earlier response is not incompatible with this; the question I was
answering was why a project might go with a CLA. In reality, whether the
answer is *relevant* to a project is certainly open to question. One
difference between the situation with GHC and the situation with Scala or
Perl 6 is that the latter are also defining a language specification, which
may have implications if there is a plan to submit it to an official
standards body at some point. For ghc, that rests on the language
committee, not the GHC developers.)

If it really bothers you, probably best to ask someone like the EFF. Almost
certainly do *not* formally ask a lawyer (informal is fine) --- they are
going to concentrate on the worst case, mainly because even asking for a
formal evaluation suggests that there is a need to worry about the worst
case. Otherwise, leave well enough alone.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Major commit to the constraint solver

[Brandon Allbery]

On Mon, Nov 3, 2014 at 8:11 PM, Richard Eisenberg e...@cis.upenn.edu wrote:

 Stderr:
 tar: --format: Cannot stat: No such file or directory
 tar: ustar: Cannot stat: No such file or directory
 tar: Error exit delayed from previous errors.
 make[2]: *** [cabal01] Error 1


Apple got rid of gnutar, it's now libarchive tar.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1 and GHC 7.8.3

[Brandon Allbery]

On Fri, Nov 7, 2014 at 3:26 PM, George Colpitts george.colpi...@gmail.com
wrote:

 command line: can't load .so/.DLL for:
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
 (dlopen(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib,
 9): no suitable image found.  Did find:

 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
 mach-o, but wrong filetype)


I'm afraid to ask how you managed that.

pyanfar:3380 Z$ file
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib:
Mach-O universal binary with 2 architectures

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
(for architecture x86_64): Mach-O 64-bit dynamically linked shared library
stub x86_64

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
(for architecture i386): Mach-O dynamically linked shared library stub i386


Do you somehow have ARM or PPC objects lying around? (Granted, I am on 10.9
still; I am upgrading a machine to 10.10 but may not have a Haskell
environment on it for a bit.)

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Is anybody able to build HEAD on Mac with Yosemite wtih Xcode 6.1 and GHC 7.8.3

[Brandon Allbery]

On Fri, Nov 7, 2014 at 3:39 PM, Brandon Allbery allber...@gmail.com wrote:


 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/libiconv.dylib
 (for architecture x86_64): Mach-O 64-bit dynamically linked shared library
 stub x86_64


On second thought... shared library stub? What's Apple up to now? This
may well be the problem; they don't actually contain anything except
symbols. (But again, this may be because I'm still on 10.9.)

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Keeping the Newcomers wiki page alive

[Brandon Allbery]

On Wed, Nov 12, 2014 at 5:32 PM, Joachim Breitner m...@joachim-breitner.de
wrote:

 The quality that we are looking for is “tacklabe by a newcomer“, i.e.
 not requiring too deep knowledge of GHC. Is there a nice word for that?
 I found “accessible”, “welcoming”, “appealing” – anything that sounds
 good in native English speaker’s ears? :-)


Various projects I'm involved with use

difficulty: beginner (or just beginner)
babydev-bait (!)
newcomer (several use newbie but I do not recommend that label)

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: mask in waitQSem

[Brandon Allbery]

On Fri, Nov 14, 2014 at 4:23 PM, Yuras Shumovich shumovi...@gmail.com
wrote:

 Here mask is used, but I looks completely useless for me. waitQSem
 itself should be called with async exceptions masked, otherwise there is
 no way to prevent resource leak.

 Do anyone know why mask is used here?


I thought QSem was known to be completely unsafe and
http://hackage.haskell.org/package/SafeSemaphore was recommended instead,
with QSem and friends slated for removal?

In any case, there are probably leftover attempts to make it safe, yes.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Brandon Allbery]

On Fri, Jan 2, 2015 at 6:18 PM, Johan Tibell johan.tib...@gmail.com wrote:

 I believe other compilers, e.g. GCC, ship debug symbols in separate files (
 https://packages.debian.org/sid/libc-dbg

 ) that e.g. GDB can then look up.


Lookaside debugging information is (a) a Linux-ism, although possibly also
included in mingw --- but not OS X or the *BSDs (b) on RPM-based systems at
least, is split out of objects into separate files, and thence into debug
packages, by the standard RPM support macros before the standard strip step
(I expect debuild does something similar on Debian-ish systems).

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Shipping core libraries with debug symbols

[Brandon Allbery]

On Fri, Jan 2, 2015 at 7:54 PM, Johan Tibell johan.tib...@gmail.com wrote:

 If we just built GHC with debug symbols enabled, everything should just
 work from a packaging perspective?


On most RPM systems, at least (I get debuginfo packages for local RPM
builds, with nothing special in the specs files). Someone else would have
to comment on Debian's build system, although I expect that it is similarly
automated.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: vectorisation code?

[Brandon Allbery]

On Mon, Jan 19, 2015 at 10:47 PM, Carter Schonwald 
carter.schonw...@gmail.com wrote:

 relatedly: wont the source be preserved in the git history if we remove
 it? the CPP etc solution is


Indeed; most of the projects I'm involved with have a specific policy to
*not* keep commented-out or otherwise disabled features in the active tree,
because they can be pulled back later from history or branches as
appropriate. You might want to either save it to a new branch or set a tag
on HEAD before removing it, so you can more easily find it later.

You've got a revision control system; let *it* do the work of keeping track
of stuff like this.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Put Error: before error output

[Brandon Allbery]

On Tue, Jan 27, 2015 at 12:02 PM, Konstantine Rybnikov k...@k-bx.com
wrote:

 Sorry, I didn't get what you mean. Do you mean `error` [0] function from
 Prelude? The discussion is currently not regarding runtime program
 behavior, nor it is about `error` function. It's rather regarding compiler
 output message on compilation failure, so it shouldn't get mixed with your
 program's runtime behavior in any way


...unless using runhaskell/runghc.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker error on OSX (symbol not found _iconv)

[Brandon Allbery]

On Sun, Jan 4, 2015 at 1:23 AM, Hemanth Kapila saihema...@gmail.com wrote:

  ld: couldn't dlopen() /usr/lib/libdtrace.dylib:
 dlopen(/usr/lib/libdtrace.dylib, 1): Symbol not found: _iconv
   Referenced from: /usr/lib/libmecabra.dylib
   Expected in: /opt/local/lib/libiconv.2.dylib
  in /usr/lib/libmecabra.dylib for architecture x86_64
  collect2: error: ld returned 1 exit status


You are mixing Apple and MacPorts libraries. (The same will happen with
Homebrew but it'll be using /usr/local/lib/libiconv.2.dylib.) Possibly you
also have DYLIB_LIBRARY_PATH set, which will compound the problem; *please*
do not do this. You are not on Linux where setting LD_LIBRARY_PATH is
common and relatively safe, DYLIB_LIBRARY_PATH will break things.

The iconv libraries contain static data which is not compatible between
versions, leading to core dumps unless something is done to force a link
time error. Both MacPorts and Homebrew rename symbols in iconv to force
this error.

Since you are building ghc, either you have forced it to use MacPorts
libraries when it otherwise wouldn't (see above re DYLD_LIBRARY_PATH) or
you at some point copied MacPorts libraries into system library paths (OS X
bakes full paths into object files and dylibs. This also means such
libraries cannot be used on a system without MacPorts installed without at
minimum using install_name_tool to change the baked-in paths).

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker error on OSX (symbol not found _iconv)

[Brandon Allbery]

On Sun, Jan 4, 2015 at 11:06 AM, Hemanth Kapila saihema...@gmail.com
wrote:

 I am not able to figure out the exact dependency issue here -  apparently,
 libHSrts cannot be built with the system version of libiconv  (configure
 step fails), while at the same time ghc-stage1 relies on some system tool
 that needs older version of libiconv.
 Is that a fair picture of the problem? I wondered why this does not occur
 for ghc-7.8.4 distributed sources.


So presumably ghc HEAD requires a newer iconv now, presumably for better
encoding handling. Many things do, which is why both MacPorts and Homebrew
include the newer one (and then must hack around incompatibility) instead
of sticking to Apple's.

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: Updating submodules

[Brandon Allbery]

On Tue, Jan 6, 2015 at 11:28 AM, Ryan Newton rrnew...@gmail.com wrote:

 Has everyone seen the git man page generator ;-)?  Hilarious.
 http://git-man-page-generator.lokaltog.net/


I still want the git version of http://thedoomthatcametopuppet.tumblr.com/
:p

-- 
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://www.haskell.org/mailman/listinfo/ghc-devs

Re: wither the Platform

[Brandon Allbery]

On Wed, Mar 25, 2015 at 10:24 AM, Mark Lentczner mark.lentcz...@gmail.com
wrote:

 The OpenGL stuff is a hard one, since it is large, but a very big painful
 build if you need it. Perhaps we need server/non-server versions of the
 platform - but only if we can get them out on the same day.


OpenGL has always been an odd fit; it was included partly because of the
size and complexity to build, but also because it was felt that
batteries-included had to include *some* kind of graphics library. I'm
inclined to think that it doesn't really belong in the core Platform,
myself.

-- 
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: wither the Platform

[Brandon Allbery]

On Wed, Mar 25, 2015 at 10:47 AM, Mike Meyer m...@mired.org wrote:

 The words Core Platform makes me think there ought to be a non-Core
 platform. This would actually match the Clojure model, where there's the
 stuff that's part of Clojure, a set of recommended libraries, and the
 library archive anyone can put stuff in. If the platform is going to
 undergo serious shrinkage, maybe the things that get pushed out - like the
 OpenGL stuff - should be considered for that middle category? Less rigorous
 testing, not bundled with the platform, but unlike all of hackage, an
 effort is made to insure that there's a repository where it builds on top
 of the core platform?


That's pretty much what I'm thinking of, yes. Not sure about less rigorous
testing --- but doesn't have to release at the same time is a
possibility.

-- 
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: GHC with cabal-install

[Brandon Allbery]

On Thu, Feb 26, 2015 at 7:41 PM, Kazu Yamamoto k...@iij.ad.jp wrote:

 Anyway, I would like to know reasons why the GHC binary package does
 not provide the cabal command.


Too many additional dependencies. Note that
https://www.haskell.org/cabal/download.html *does* provide binary packages,
specifically to address this.

-- 
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: RFC: Native -XCPP Proposal

[Brandon Allbery]

On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber 
singpol...@singpolyma.net wrote:

 Yes.  This is one of my favourite things in GHC-land -- that an existing,
 good-enough, standardised, and widely-deployed solution was chosen over a
 NiH reinvention of preprocessing


I have to assume my irony detector is broken as well. Or maybe I should
just assume that all the world's Linux with gcc is assumed to be forever
true and forever reliable by all right-thinking people so let's just
sweep the nonissue under the rug because it can oh so obviously never be a
real issue

Because I had to face this back a couple decades ago, when my employer
ported an application written in a 4GL (database language) to SCO Unix. The
4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO
used one integrated into its lexer (making it even more tightly wedded to C
syntax than clang's). Eventually we replaced its cpp with a wrapper that
ran m4 and redid everything else in m4's syntax.

Which is why I was always a bit worried about ghc relying on cpp, was
unsurprised when clang caused issues, and am rather annoyed that there are
people who believe that they can just ignore it because REAL users will
always be on Linux with gcc and all them furriners using weird OSes like OS
X and FreeBSD can safely be ignored with their
not-the-One-True-OS-and-compiler platforms.

Additional historical note that I assume True Believers will ignore as
meaningless: X11 used to make the same assumption that cpp was always and
forever guaranteed to be friendly to non-C and this still shows at times in
things like xrdb resource databases. They did accept the inevitable and
(mostly) stop abusing it that way, and are now moving away from imake which
likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter
the same inability to comprehend or accept change there.)

-- 
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: [Haskell-cafe] RFC: Native -XCPP Proposal

[Brandon Allbery]

On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge _deepf...@feelingofgreen.ru
wrote:

 Why *shouldn't* TH fill that role?  What can be done about it?


For one, it's difficult to make it available in cross compilers (granted,
work is being done on this) and not available on some platforms (ARM has
been a problem, dunno if it currently is). For another, I don't think you
can currently control things like imports or LANGUAGE pragmas --- and as TH
is currently constructed it's not clear that you could do so, or that you
could do so in a way that is sane for users.

This is not to say that I like cpp --- I'd like it a lot more if it weren't
actually using a C preprocessor that is not actually under our control or
guaranteed to be compatible with Haskell --- but it does provide a meta
in a different dimension than TH does.

-- 
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: StrictData and the parser

[Brandon Allbery]

On Thu, Jun 4, 2015 at 3:52 PM, Adam Sandberg Eriksson 
a...@sandbergericsson.se wrote:

 However after adding relevant rules for '~' in the parser[2] I get an
 explosion of shift/reduce conflicts as well as 4 extra reduce/reduce
 conflicts, see [3] for the happy info (the states with 36 shift/reduce
 conflicts seem to be the problematic ones)


Looks to me like it's confused about whether a ~ is part of an equality
constraint or is a laziness annotation. The former would be illegal at that
point, though, I'd think? Somewhere it believes a constraint might be
possible there, via btype.

As ezyang says in the message I see just came in, you'll need extra
production rules to distinguish that top level. Although I'd wonder why it
believes an equality constraint is acceptable there in the first place; is
that a lurking bug in the parser?

-- 
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: Abstract FilePath Proposal

[Brandon Allbery]

On Sun, Jun 28, 2015 at 5:09 PM, Neil Mitchell ndmitch...@gmail.com wrote:

 * I believe some Emacs user once told me that a//b is not the same as
 a/b in some circumstances.


Only when typing to an interactive path prompt; it lets you reset to /
without erasing the existing path prefix. This should never happen in
elisp, for example.

-- 
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: Abstract FilePath Proposal

[Brandon Allbery]

On Sat, Jul 4, 2015 at 3:26 PM, Sven Panne svenpa...@gmail.com wrote:

 To me the fundamental question which should be answered before any detail
 question is: Should we go on and continuously break minor things (i.e.
 basically give up any stability guarantees) or should we collect a bunch of
 changes first (leaving vital things untouched for that time) and release
 all those changes together, in longer intervals? That's IMHO a tough
 question which we somehow avoided to answer up to now. I would like to see
 a broader discussion like this first, both approaches have their pros and
 cons, and whatever we do, there should be some kind of consensus behind it.


I recall suggesting something along the lines of stable vs. research ghc
releases a few months back. This seems like it would fit in fairly well;
the problem is getting buy-in from certain parts of the ecosystem that seem
to prefer to build production-oriented packages from research/unstable
releases.

-- 
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: SV: [Haskell-cafe] RFC: Native -XCPP Proposal

[Brandon Allbery]

On Thu, May 21, 2015 at 11:51 AM, Herbert Valerio Riedel hvrie...@gmail.com
 wrote:

 Performance isn't (my) motivation for avoiding fork/exec (and the
 equivalent on Win32) but rather avoiding the added complexity of
 marshalling/IPC with fork/exec, as opposed to simply calling into a
 native Haskell function and crossing process boundaries and having to
 deal with the various things that can go wrong with the additional
 moving parts you encounter when controlling an external process. So this
 would IMO simplify code paths, and moreover I'd expect opportunities to
 actually make the Haskell cpphs API richer (in case it isn't already)
 and more tailored to GHC's lexer/parser pipeline and error-reporting.


Don't you still have to support -pgmF?

-- 
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: Typechecker / OverloadedStrings question 7.8 vs. 7.10

[Brandon Allbery]

On Mon, Aug 3, 2015 at 12:45 PM, Daniel Bergey ber...@teallabs.org wrote:

 I thought GHC would infer the type when only one instance is in scope,
 at least in some cases, like IsString.  But I could well be wrong about
 that.


Typeclasses are open-world; this is not a safe assumption, since instances
are global and an instance added elsewhere at some point in the future
could therefore break your program.

-- 
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: [Haskell-cafe] ANNOUNCE: GHC version 7.10.2

[Brandon Allbery]

On Thu, Jul 30, 2015 at 12:52 PM, James M jmar...@eecs.berkeley.edu wrote:

 There was talk from an earlier email thread of releasing the Haskell
 Platform at the same time as 7.10.2.


I think the right place to ask this is librar...@haskell.org. I would
imagine they're in final testing and/or getting release packages in place.
(Note as previously mentioned that text was just updated, and the
Platform needs that; this presumably means they had to start over making
release packages.)

-- 
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: Record syntax for pattern synonyms

[Brandon Allbery]

On Tue, Aug 11, 2015 at 9:11 AM, Richard Eisenberg e...@cis.upenn.edu
wrote:

 I haven't tried to do it, but I imagine you could do some cool lens-like
 constructs with proper (ab)use of this feature.


Seems likely given that generalizing record update was the original impetus
for lenses. :)

-- 
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: Improving the Get Haskell Experience

[Brandon Allbery]

On Mon, Jul 13, 2015 at 3:34 AM, Kosyrev Serge _deepf...@feelingofgreen.ru
wrote:

 ..And so, I can't help but wonder.. what if the Stack authors would have
 applied their expertise to provide the same user experience they
 achieved..

 ..but with Nix as an underlying technology?


Backpack (very roughly, a Nix-like Cabal package mechanism) is still in
development. Once it's out there, perhaps FPComplete will look into using
it with Stack?

-- 
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: New release of GHC 7.8 to support OS X El Capitan

[Brandon Allbery]

On Sat, Jul 18, 2015 at 7:39 AM, Ben Gamari b...@well-typed.com wrote:

 I would like to understand the root-cause of the issue. It seems that
 OS X will now raise EPERM instead of EACCES when certain files are
 accessed. That being said, it's not at all clear to me which system call
 is failing or why. Could someone familiar with El Capitan describe what
 exactly is going on here?


The trace showed access(/usr/bin/ar, 2) = -1/EPERM (instead of
-1/EACCES).

http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really
appears relevant. Sounds to me like they automatically set a bunch of stuff
immutable (chflags(1) schg flag; also see chflags(2), the underlying
syscall) and bump the (equivalent of) securelevel so it can't be altered
even by root after system boot. (Sadly, Apple did not bother to update the
manpages to reflect launchd.)

-- 
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: download all of Hackage?

[Brandon Allbery]

On Mon, Sep 14, 2015 at 10:43 AM, Richard Eisenberg 
wrote:

> Is there an easy way to download (but not compile) all of Hackage? I know
> of the hackager package, but that's about compiling. I just want a whole
> big load of Haskell code to play with. I thought I could find a link on
> Hackage to do this, but failed.
>

There's hackage-mirror, but I note it says it mirrors to S3.

-- 
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: -XStrict: Why some binders are not made strict?

[Brandon Allbery]

On Mon, Dec 7, 2015 at 8:40 PM, Ömer Sinan Ağacan 
wrote:

> With -XStrict 'x', 'xs', 'y' and 'ys' don't become strict. I'm wondering
> about
> the motivation behind this, I found this interesting. I always thought
> -XStrict
> gives me this guarantee: If I'm using an already-defined variable(bound by
> a
> let or pattern matching) in an expression, I can be sure that the variable
> won't be bottom in that expression, because it would be `seq`d before the
> expression is evaluated.
>

Aren't those already guaranteed to be strict because of pattern matching?
Try it again with irrefutable patterns.

-- 
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: Why upper bound version numbers?

[Brandon Allbery]

On Mon, Jun 6, 2016 at 5:02 PM, Dominick Samperi 
wrote:

> Consequently, it refuses to install with the latest ghc provided with
> the Haskell Platform (8.0.1).
>

base is not defined by the Platform, it is defined by (and ships with, and
must completely match) ghc.
And no, backward compatibility is not guaranteed; for a recent example, ghc
7.10 broke many programs by making Applicative a "superclass" of Monad and
by generalizing many Prelude functions to Foldable and/or Traversable.

-- 
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: Why upper bound version numbers?

[Brandon Allbery]

On Mon, Jun 6, 2016 at 8:19 PM, Dominick Samperi 
wrote:

> The odd thing about this is that to upper bound a package that you did
> not write (like base) you would have to know that incompatible changes
> were coming in subsequent revisions, or that features of the API that
> you rely on will be changed.
>

There is a versioning policy covering this. It has been found to be
necessary because otherwise people who try to build packages find
themselves with broken messes because of the assumption that any future
version of a package is guaranteed to be compatible.

-- 
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: [ANNOUNCE] Glasgow Haskell Compiler 8.0.1, release candidate 1

[Brandon Allbery]

On Wed, Jan 13, 2016 at 3:55 PM, Karel Gardas 
wrote:

> On 01/13/16 09:28 PM, George Colpitts wrote:
>
>> installs fine on mac but cabal install vector fails on primitive, looks
>> to me like gmp library is not provided
>>
>
> gmp should be probably provided by your OS. Looks like you will also need
> its -dev version too. Does
>

Won't help on OS X unless they have Fink installed, and even then that
means potentially getting a different libgmp than base is using.
If base includes libgmp, as it must on Windows / OS X, it should be made
available to other packages.

-- 
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: Phab failing to apply patches

[Brandon Allbery]

On Mon, Jan 18, 2016 at 12:09 PM, Thomas Miedema 
wrote:

> * you validate locally (in a different build directory, so you can keep
> using build flavour = devel2 in your development directory)
> * fork the ghc github repository, push your branch there, and let Travis
> validate it: https://ghc.haskell.org/trac/ghc/wiki/TestingPatches#Travis
>
> * ask Austin for some special Phabricator syntax that you could add when
> you submit the patch, to request Harbormaster not to rebase onto HEAD
> before validating
>

Seems to me that, if Harbormaster is already overloaded, the second option
should be preferred. Offloading from one limited resource (local machine)
to another that is also shared seems like a lose for everyone.

-- 
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: ghci and unfoldings?

[Brandon Allbery]

On Sun, Jan 17, 2016 at 9:40 PM, Conal Elliott  wrote:

> I'm developing a GHC plugin (using HERMIT), and I'd like to use ghci to
> speed up development. I'm able to do so, except that my plugin critically
> needs access to unfoldings, which appear to be unavailable in ghci. A
> little experimenting with ghc shows me that "-O" is the key, but "-O" is
> incompatible with "--interactive" (as in ghci). Is there any way to
> persuade ghci to make unfoldings available?


I think unfoldings are only done as part of optimization, and the bytecode
backend doesn't support optimization at all.

-- 
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: Best practices for merging?

[Brandon Allbery]

On Tue, Feb 2, 2016 at 9:23 AM, Alexander Berntsen <alexan...@plaimi.net>
wrote:

> On 02/02/16 15:20, Brandon Allbery wrote:
> > Only if it builds and passes tests across all ten commits.
> Yes, obviously. I have never worked anywhere where breaking commits
> were allowed, and I did not intend to suggest that breaking commits
> were a Good Idea or useful. They emphatically aren't.
>

The point is, this only applies once it's in the ghc repo. Works in
progress may well have such commits as long as they are cleaned up on
pushing --- which is why you would squash commits together losing
intermediate history, which is what started this thread. (This point was
actually made earlier in the thread, just not in so many words.)

-- 
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: Best practices for merging?

[Brandon Allbery]

On Tue, Feb 2, 2016 at 8:54 AM, Alexander Berntsen 
wrote:

> It then becomes comparatively trivial to hunt
> down the error by bisecting ten 25 line commits, when the converse is
> figuring out a 250+ lines patch.
>

Only if it builds and passes tests across all ten commits.

-- 
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: "Excuse me, I think this i my stop..." - Resigning from the Platform

[Brandon Allbery]

On Mon, Feb 22, 2016 at 11:15 AM, Simon Peyton Jones 
wrote:

> But then I received it again, yesterday.  The very same message!   I have
> no idea why.  Email is a Mysterious Medium.


I think they restarted the mailing list server; I got that message and a
handful of other messages, which apparently never got cleared from the mail
queue or something. And IIRC shortly before the resends, someone in
#haskell was asking if there were problems with the mailing lists.

(this kind of stuff is why I got out of the business of running mail
servers)

-- 
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: Unicode, strings, and Show

[Brandon Allbery]

On Wed, Mar 30, 2016 at 9:16 PM, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> Thank you for all the replies and especially pointing to this ticket.
>
> I think, the discussion on this ticket is actually misleading and there is
> a simple solution, which I added as a comment.
>

That is in fact not simple at all: with that, the ostensibly pure `show`
now depends on the user's locale and therefore should be in IO (and you
cannot reliably feed it to `read` in a program running in a different
locale)! This is why the ticket was concentrating on ghci, where it's at
least somewhat reasonable to assume a UTF8 environment.

-- 
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: Unicode, strings, and Show

[Brandon Allbery]

On Wed, Mar 30, 2016 at 9:50 PM, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> Firstly, we have
>
>   isPrint :: Char -> Bool
>
> Are you saying that this type is wrong?
>
> Secondly, how often do you feed the output of ’show’ to ’read’ in another
> locale versus how often is everybody whose whole life is outside of ASCII
> (i.e., not anglo-centric people) bothered by this shortcoming? (*)
>
> Moreover, the argument on the ticket was that changing the current
> implementation would go against the standard. Now that I am saying, the
> current implementation is not conforming to the standard, the standard
> suddenly doesn’t seem to matter. Personally, I would say, when we wrote
> that standard, we knew what we were doing.
>

The standard I am aware of is the Report, which deliberately limited the
output to the subset which is guaranteed to be usable in all locales. show
conforms to this; apparently people want it to *not* conform, and in a way
which requires some locale to become the One True Locale.

isPrint is, as per the language Report, based on what Char is --- which is
Unicode codepoints. Using it for output --- or for input, for that matter
--- gets you into locale issues because nobody anywhere guarantees that
Unicode codepoints that pass isPrint are representable in every locale.
isPrint is not the place to verify that a character can actually be
displayed in the current locale.

Or have you decided that ghc should require Unicode locales and nothing but
Unicode locales from now on? If so, what do you do when the next issue
comes up, where Unix is UTF8 and Windows is UTF16?

-- 
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: Specialized type hints

[Brandon Allbery]

On Thu, Mar 3, 2016 at 11:58 AM, Eric Seidel  wrote:

> On Wed, Mar 2, 2016, at 23:54, Christopher Allen wrote:
> > I'd like to see how warm people would be to catching GHC's type error
> > quality up a bit.
> >
> > I did a write-up on a confusion a reader of our book had:
> >
> > https://gist.github.com/bitemyapp/c27c721b92dab0248433
>
>
>
> Wow, this is a pretty nasty error message. In particular because it
> relies on the overloaded nature of integer literals.


We actually had another such situation come up in #haskell yesterday, btw.
Someone confused type constructors and data constructors, and the error
message assumed they wanted DataKinds and type level programming. This is
kinda bad for newcomers.

-- 
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

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: GHC 8.0.1-rc4 source tarball availability

[Brandon Allbery]

On Sat, Apr 23, 2016 at 8:50 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> It *seemed* to work fine even with that lib no longer at that path, but
> famous last words. It does seem that it doesn't do anything


It's only used when it needs to do something for which the CPU lacks
support so a call to an emulation is used instead of trying to generate
native code for it. Maybe you got lucky and ghc doesn't actually need it in
its C bits. Or maybe it'll explode only when there's a full moon in Scorpio
and Mars is ascendant. :/ (Well, when some rarely used operation happens to
need something that x86_64 needs help with. I don't think there are many of
those --- which means it's going to be an even rarer explosion.)

-- 
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: GHC 8.0.1-rc4 source tarball availability

[Brandon Allbery]

On Sat, Apr 23, 2016 at 8:05 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> and I *believe* but could be wrong that its better to have it point
> to /usr/lib/libgcc_s.1.dylib or something?
> otoh, the otool -L output of those respective things are VERY different
>

People will need to have that libgcc_s.1.dylib *by path* installed. Apple's
is likely too old to be compatible, so copying it or using
install_name_tool to repoint to it will likely lead to a non-working
program.

You mentioned at one point that you built using a local gcc install. gcc
uses its bundled libgcc_s; so you will have that dependency unless you
switch to /usr/bin/clang to build.

-- 
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: Draft 8.0 Mac build directions

[Brandon Allbery]

On Tue, May 3, 2016 at 11:32 AM, Ben Gamari  wrote:

> About font installation: do you know any any way to accomplish this
> at the terminal?
>

Just copy them to the appropriate directory (/Library/Fonts or
~/Library/Fonts); fontd will see and register them automatically.
Font Book automates this and includes some basic sanity checks; it does not
do any extra registration or etc.

-- 
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: macOS 10.12

[Brandon Allbery]

fwiw I suspect this is
http://git.haskell.org/ghc.git/commit/a0f1809742160ca0c07778f91f3e2a8ea147c0a4

On Thu, Jul 28, 2016 at 5:13 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Could you share your error messages ?
>
>
> On Wednesday, July 27, 2016, Manuel M T Chakravarty 
> wrote:
>
>> Has anybody tried compiling GHC with the (beta) macOS 10.12 Sierra SDK? I
>> just gave it a shot trying to compile GHC 7.8.3 and ran into a problem with
>> GetTime.c in the RTS. (I haven’t tried GHC 8.0.1.)
>>
>> Manuel
>>
>> ___
>> 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
>
>


-- 
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: Is Safe Haskell intended to allow segfaults?

[Brandon Allbery]

On Tue, Aug 9, 2016 at 4:19 PM, Edward Z. Yang  wrote:

> If you can execute subprocesses, you could always spawn gdb to
> attach via ptrace() to the parent process and then poke around
> memory.
>

Don't even need that if you're just talking segfaults, you can always spawn
a subprocess "kill -SEGV $PPID" :)

Unless you have full control over all the code that could be run in
subprocesses, it's not going to be safe much less Safe.

-- 
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: Request for feedback: deriving strategies syntax

[Brandon Allbery]

On Wed, Aug 3, 2016 at 10:52 PM, Richard Eisenberg 
wrote:

> I do not understand "not portable" here. Do you mean that some
> architectures don't support TH?


Sounded to me like they're targeting the standards path, which means not
tying it to something that's fairly inherently GHC specific.

-- 
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: Is Safe Haskell intended to allow segfaults?

[Brandon Allbery]

On Mon, Aug 8, 2016 at 1:27 PM, Ryan Newton  wrote:

> As usual?  So it is ok to segfault GHC?  Elsewhere it says "in the safe
> language you can trust the types", and I'd always assumed that meant Safe
> Haskell is a type safe language, even in the IO fragment.


Pretty sure it's impossible to allow IO without enabling all of it one way
or another. And as soon as you allow *any* IO, you're open to various kinds
of failures including segfaults. The only way you will get your type system
to prevent that is fully specified dependent typing both in your program
*and in the OS level interfaces*. I wish you luck on the latter.

-- 
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: Using stringize and string concatenation in ghc preprocessing

[Brandon Allbery]

On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar 
wrote:

> But "-optP" seems to only append to the flags that GHC already passes and
> gcc has no "-no-traditional" option to undo the effect of the
> "-traditional" that GHC has already passed. I think "-optP" should override
> the flags passed by ghc rather than appending to them. Is there a reason
> not to do that?
>
> Is there any other better way to achieve this? What is the standard way of
> doing this if any?
>

Removing -traditional will break much Haskell source. Go look at the
history of clang with ghc (clang doesn't do -traditional) to see what
happens. (tl;dr: without -traditional, cpp knows too much about what
constitutes valid C, and mangles and/or throws errors on valid Haskell that
doesn't lex the way C does.)

You might want to look at cpphs as an alternative preprocessor. There are
some ancient K hacks that could be used if absolutely necessary, but
cpphs should be a much simpler and cleaner solution.

-- 
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: cabal

[Brandon Allbery]

On Mon, Sep 5, 2016 at 12:40 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> bash$ which cabal
>
> /home/simonpj/.cabal/bin/cabal
>
> Maybe I need 1.24.  Which claims to be installed.  But WHERE is it
> installed?
>
>
Try "type cabal". "which" has a nasty tendency to show you what the next
shell you open (or sometimes the next time you login) will see; shells
remember what they've already seen, so it's probably still running the old
one (likely in /usr/bin or /usr/local/bin). POSIX requires "type" to show
what the *current* shell (thinks it) knows, not what some future shell will
see.

"hash -r" should work to reset the shell's idea of where cabal is, if
"type" says it's running a different cabal.

-- 
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: Allow top-level shadowing for imported names?

[Brandon Allbery]

On Wed, Oct 5, 2016 at 10:02 PM, Michael Sloan  wrote:

> What if instead we re-framed this as a "top-level where clause", like this:
>
> main :: IO ()
> main = putStrLn ("Hi" <> "There")
>
> other-function :: IO ()
> other-function = putStrLn ("I can " <> "also use it")
>
> -- NOTE: 0 indent!
>
> where
> (<>) :: String -> String -> String
> (<>) = (++)
>

This would actually be slightly odd parse-wise, as we're already *in* an
unindented where clause (module ... where)

-- 
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: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 8:38 PM, Christopher Allen 
wrote:

> This is so short-sighted and wrong that I don't think there's any
> point in my saying more. You've made it clear you don't care.
>

And --- note that I am not a ghc developer --- have made it clear that you
do not care how much extra work you make for already massively overworked
ghc developers.
You're not contributing. You're not helping. You're derailing.

-- 
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: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:05 PM, Michael Sloan  wrote:

> As a side observer, I find Christopher's comments to be spot on.


They're missing quite a bit, actually. Like how Rust had a bunch of
contributors even before they started, and Mozilla Corp. backing them.
Rust's solution is only viable if someone wants to bring those to the table
along with it; it's just not possible otherwise. There aren't enough people
*now* to build a whole new infrastructure.

I work with another open source project that is as short on contributors as
ghc is. It's part of my day job, even, and it's a regular topic at team
meetings. One comes to understand why this is not something that can be
done on a whim. (And my employer isn't big enough to do the heavy lifting
or provide bodies --- even ignoring that we feel it's best for us and our
customers that this project remain independent, not controlled by or
beholden to any company, which makes contributing somewhat difficult as a
political matter although we do our best.)

-- 
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: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:44 PM, Michael Sloan  wrote:

> It is irrelevant why Rust has an advantage. Lets please emulate their
> successful strategies instead of in-fighting.
>

Does that include having Mozilla Corp. backing them? What is your
suggestion for this?

I understand that you think this is an important cause for the dearth of
contributors --- I've watched enough would-be contributors bounce off the
code base (long before even considering the tooling) and give up to have
major doubts, as underlined by Richard's recent message --- but throwing
everything out and building a new infrastructure is not something that
happens by itself. It needs *people* and it needs *time*. And it's harder
(and needs more people and more time) when you have a couple decades' worth
of history (which Rust did not). If you have a solution to this problem,
I'm sure people would like to hear it.

-- 
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: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 8:17 PM, Christopher Allen 
wrote:

> They don't rely on bare Github, they use bots to automate and add
> structure in the ways you're trying to wring out of Phabricator.
>

Other way around: they, and pretty much every large project, are forced to
invent their own bots and automation to wring some usability out of
github's minimal functionality. Which is why other large projects use
phabricator, gerrit, etc. instead of dumping a massive amount of effort
into trying to make github do what they need.

-- 
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: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Sep 24, 2016 at 9:08 PM, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> Why are you so hostile to Chris? I don’t think that this is an appropriate
> way to treat somebody who is making a suggestion in good faith.


It may be in good faith. but it's not in good sense. There is a lot in the
background that made Rust's setup possible, and he's not bringing that to
the table, just assuming it'll somehow happen or that everyone else will
drop everything for the next few months and make it happen. And I feel like
he's being really pushy about committing already overworked people to this
--- and insisting that anyone opposed must have a hidden agenda or
otherwise cannot possibly have good reason to be opposed. It's not helpful
at all; it's basically a good way to stall ghc for the next few months at
least.

-- 
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: Create a ghc-simple-patch-propose list? Re: Notes from Ben's "contribute to ghc" discussion

[Brandon Allbery]

On Sat, Oct 1, 2016 at 4:47 PM, Simon Marlow  wrote:

> A nice trick for dealing with stacked diffs in Phabricator is to use "git
> rebase -i" to modify diffs in the middle of the stack.  You can also insert
> "x arc diff" between lines to automatically update later diffs on
> Phabricator after a rebase lower down the stack.
>
> You only need a single branch for the whole stack, and continually rebase
> it.  I also push the whole branch to github to get Travis to build it, but
> that's optional.
>

Perhaps someone could put a sample workflow on (one of...) the wiki(s).

-- 
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: [ANNOUNCE] GHC 8.0.2 release candidate 1

[Brandon Allbery]

On Sun, Nov 27, 2016 at 8:30 AM, Tuncer Ayaz  wrote:

> However, what's changed from 8.0.1 to 8.0.2 to trigger this? I mean,
> is a point release supposed to do this? I would expect 8.0 to 8.1 to
> break, but find it surprising x.0.1 to x.0.2 would as well.
>

ImpredicativeTypes has *always* been broken, just in different ways in
every release. Worse, it never had a real specification, therefore no
tests. I think it's just going to be ripped out finally in the next major
release, since VisibleTypeApplication should handle most of the use cases.

-- 
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: Reading floating point

[Brandon Allbery]

On Tue, Oct 11, 2016 at 10:41 AM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Could you elaborate or point me to where this philosophy is articulated in
> commentary in base or in the language standards ?


https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600011.4
is instructive, insofar as one can assume the restrictions it quotes that
do not agree with the semantics of Haskell imply a philosophy.

-- 
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: Please don’t break travis

[Brandon Allbery]

On Fri, Dec 9, 2016 at 3:56 PM, Ben Gamari  wrote:

> I seem to recall that this isn't the first time that this has happened.
> Given that our testsuite is only growing, what is the long-term plan for
> managing this?
>

Consider running the test suite as a separate job?

-- 
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: Attempt at a real world benchmark

[Brandon Allbery]

On Fri, Dec 9, 2016 at 9:50 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> The big issue is (a) design and implementation effort, and (b) dealing
> with the privacy issues.


And (c) not everyone is going to upgrade their ghc, even if you backport
the telemetry to older versions (potentially back to 7.6.3 or even
earlier), so likely you'd only get telemetry from new users.

-- 
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: Help needed: Restrictions of proc-notation with RebindableSyntax

[Brandon Allbery]

On Wed, Dec 21, 2016 at 12:15 AM, Edward Kmett  wrote:
>
> Given that little new code seems to be being written with Arrows in mind,
> while some older code makes heavy use of it (hxt, etc.), refactoring the
> arrow hierarchy is kind of a hard sell. It is by no means impossible, just
> something that would require a fair bit of community wrangling and a lot of
> work showing clear advantages to a new status quo at a time when its very
> hard to get anybody to care about arrow notation at all.
>

The arrowized-FRP folks seem to care a fair bit.

-- 
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: [Haskell-cafe] many haskell's mails are detected as spam on gmail

[Brandon Allbery]

On Tue, Dec 27, 2016 at 5:11 AM, Niklas Hambüchen  wrote:

> Despite Google's public claims to the contrary, I have found the Gmail
> spam filter not to work too reliably
>

I think it depends on your use case (and it's rather indicative of the core
problem of spam detection that spam is hard to distinguish from real
messages about e.g. attached invoices). I've had maybe 8 Haskell list
messages land in my spamtrap, gradually getting rarer as I "mark as not
spam" them.

-- 
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: LLVM calling convention for AVX2 and AVX512 registers

[Brandon Allbery]

On Wed, Mar 15, 2017 at 5:44 PM, Ben Gamari  wrote:

> Carter Schonwald  writes:
>
> > No matter *how* ghc ultimately bundles simd for high level
> > programming, it *will* have to bottom out into these target specific
> > operations at code gen time, and LLVM is *not* an abstraction for it.
> >
> I am very interested to hear what you mean by this; please do elaborate.
>

I'm a bit puzzled by this, as this is pretty much the exact kind of
abstraction LLVM is intended for as I understand it.

-- 
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: GHC 8.2.1-rc1 source tarball availability

[Brandon Allbery]

On Wed, Apr 5, 2017 at 9:17 PM, George Colpitts 
wrote:

> /Users/gcolpitts/Downloads/ghc-8.2.0.20170404/libffi
>

I don't think you want to be in the libffi subdirectory; any test suite
there would be specific to libffi and require you to follow its directions,
not the ghc testsuite directions.


-- 
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: [ANNOUNCE] GHC tarballs for Windows 10 Creators Update

[Brandon Allbery]

On Sat, Apr 15, 2017 at 10:06 AM, Sven Panne  wrote:

> I heavily rely on "stack" to install GHC version, so what is the intended
> way of telling "stack setup" about the suffix? If I understand things
> correctly, "stack setup" will install non-working versions on Windows with
> the Creators Update.


the stack devs will have to figure that out, but I'm sure they do their own
distribution instead of relying on an "alien" one anyway.

-- 
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: 8.2.1: Ord TyCon is gone?

[Brandon Allbery]

On Sat, Jul 29, 2017 at 10:07 AM, Ben Gamari  wrote:

> Hmm. I am unable to reproduce this,
>
> $ ghci
> λ> import Type.Reflection
> λ> let tc = typeRepTyCon (typeRep @Int)
> λ> tc == tc
> True
>
> Does that work for you?
>

Maybe I'm missing something, but doesn't that only test Eq, not Ord?

-- 
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: Which stable GHC release is expected to have support for linear types?

[Brandon Allbery]

On Sun, Jul 9, 2017 at 4:35 PM, Wolfgang Jeltsch 
wrote:

> I got the following error message:
>
> > fatal: Not a git repository: ${BASEDIR}/ghc/.git/modules/.
> arc-linters/arcanist-external-json-linter
>
> I guess this is because my local directory is not named “ghc”, but “ghc-
> linear”. In my opinion, the repository should not assume that a local
> copy of it resides in a directory of a certain name. Is this a GHC issue
> or an issue with your linear-types branch?
>

Sounds like they forgot to undo some Phabricator-specific setup from the
master ghc repo.

-- 
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: Which stable GHC release is expected to have support for linear types?

[Brandon Allbery]

On Wed, Jul 12, 2017 at 4:11 PM, Wolfgang Jeltsch 
wrote:

> I had thought about this possibility already, but then concluded that this
> was not the case, since types of the form a -o b were not supported.
> However, when looking at the diffs, I discovered that at the moment, only
> the Unicode syntax a ⊸ b is understood.
>

"-o" is going to give the lexer fits. Come up with a purely symbolic
version.

-- 
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: Which stable GHC release is expected to have support for linear types?

[Brandon Allbery]

On Sat, Jul 15, 2017 at 4:57 AM, Bardur Arantsson 
wrote:

> Maybe, but it seems a bit fragile to me...
>
> What about -*? At least there's no ambiguity there.
>

As previously stated: "Alternatives for “-o” I can think of are “~>”, “-:”,
and “-*”, the latter resembling the magic wand operators in the logic of
bunched implications and in separation logic, which are similar to the
lollipop in linear logic."

-- 
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: GHC release timing and future build infrastructure

[Brandon Allbery]

On Mon, Jul 31, 2017 at 10:19 PM, Ben Gamari  wrote:

> I just posted a pair of posts on the GHC blog [1,2] laying out some
> thoughts on the GHC release cycle timing [1] and how this relates to the
> in-progress Jenkins build infrastructure [2]. When you have a some time
> feel free to give them a read and comment (either here or on the Reddit
> thread [3]).
>

This release was actually a bit unusual for recent releases, in that a
significant delay did *not* come from working around a major breaking
behavior change in a Tier 1 platform; recent examples being macOS's load
commands limit and Ubuntu defaulting to position-independent executables.

I think this might be relevant to the question of slipping extra stuff into
releases: it's become so common to have extra time courtesy of Tier 1
platforms breaking things on us that slipping extra stuff in is now
expected.

-- 
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: Alex install failure

[Brandon Allbery]

On Fri, Aug 18, 2017 at 8:04 AM, Ben Gamari  wrote:

> Simon Peyton Jones via ghc-devs  writes:
> > I'm trying to update my installation of alex, on Unix (Ubuntu).  But I
> get the dump below
> > It's complaining about a lock file being an invalid argument (see
> highlight below).
> > If I manually remove the file I get past that, it successfully
> > installs tf-random, but the same thing happens on the next package. So
> > I can install packages one at a time, but that's silly.
>
> Hmm. Here's a shot in the dark: is home home directory mounted via NFS
> by any chance?
>

I was thinking CIFS, but pretty much the same issue. Or NTFS via FUSE
module.

-- 
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: Can I get the internal name of a package at runtime?

[Brandon Allbery]

On Sat, Oct 14, 2017 at 3:59 PM, MarLinn  wrote:

> That sounds reasonable, but also like there *can not be* a way to obtain
> that hash at runtime. And therefore, no way to discover the true package
> name.
>

I can think of a hacky way: make sure the symbol table is still present in
the executable and that you can find said executable, z-encode the part of
the package+version you know and a symbol you know, and look for symbols
that start with one and end with the other; the hash will be in between.

-- 
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: Can I get the internal name of a package at runtime?

[Brandon Allbery]

Oh, wait, that won;t work because you're trying to find the name of
something to load at runtime. But you can still z-encode the known parts of
the name and look for files starting and ending with those components; the
ABI hash won't matter because a dynamically loaded plugin can't use the
inlinings from the .hi file anyway. If you get multiple matches, you could
warn about it but because you can't use the .hi inlinings in that context
it won't matter which one you load.

On Sat, Oct 14, 2017 at 4:19 PM, Brandon Allbery <allber...@gmail.com>
wrote:

> On Sat, Oct 14, 2017 at 3:59 PM, MarLinn <monkle...@gmail.com> wrote:
>
>> That sounds reasonable, but also like there *can not be* a way to obtain
>> that hash at runtime. And therefore, no way to discover the true package
>> name.
>>
>
> I can think of a hacky way: make sure the symbol table is still present in
> the executable and that you can find said executable, z-encode the part of
> the package+version you know and a symbol you know, and look for symbols
> that start with one and end with the other; the hash will be in between.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
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: Can I get the internal name of a package at runtime?

[Brandon Allbery]

On Sat, Oct 14, 2017 at 12:48 PM, MarLinn  wrote:

> So the "actual" package name seems to be "Plugin-0.0.0.0-2QaFQQzYhnKJSP
> RXA7VtPe".
> That leaves the random(?) characters behind the version number to be
> explained.
>

ABI hash of that specific package build, which is needed because compiling
with different optimization levels etc. will change what part of the
internals gets exposed in the .hi file for inlining into other modules;
mismatches there lead to *really* weird behavior. (If you're lucky, it'll
"just" be a type mismatch in code you didn't write, because it came from
the .hi file. If unlucky, it compiles but dumps core at runtime.)

-- 
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: Compiling natively GHC for ARMv7l softabi

[Brandon Allbery]

On Tue, Oct 17, 2017 at 12:41 AM,  wrote:

> utils/ghc-cabal/ghc.mk:48: recipe for target 
> 'utils/ghc-cabal/dist/build/tmp/ghc-cabal'
> failed
> make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Killed
>

The OOM killer got you. Add swap if you can.

-- 
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: Ignoring ANN Module "HLint: ..."

[Brandon Allbery]

On Sun, Sep 24, 2017 at 1:44 AM, Moritz Angermann <
moritz.angerm...@gmail.com> wrote:

> can we detect annotations like `{-# ANN module "HLint: ignore Reduce
> duplication" #-}` easily?
> Right now this will result (without -fexternal-interpreter or a stage2
> compiler) in
>
>   Ignoring ANN annotation, because this is a stage-1 compiler without
> -fexternal-interpreter or doesn't support GHCi
>
> However, I do not see why this should require the external interpreter at
> all. This looks to me
> more like an informational comment?
>

As I understand it, ANNotations are intended for use with ghc plugins;
hlint's use of them is not *quite* an abuse, since it is relying on
haskell-src-exts handling of them rather than ghc's.

-- 
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: Ignoring ANN Module "HLint: ..."

[Brandon Allbery]

On Sun, Sep 24, 2017 at 1:51 AM, Moritz Angermann <
moritz.angerm...@gmail.com> wrote:
>
> > As I understand it, ANNotations are intended for use with ghc plugins;
> hlint's use of them is not *quite* an abuse, since it is relying on
> haskell-src-exts handling of them rather than ghc's.
>
> I did not mean to imply abuse here.  Just that this kind of annotation
> should not trigger the external interpreter
>

I didn't either, really; the main point is that ghc expects annotations to
be related to plugins, which *would* require the interpreter.

-- 
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: Alex install failure

[Brandon Allbery]

On Mon, Aug 28, 2017 at 1:42 PM, Ben Gamari  wrote:

> Hmm, interesting. So it seems almost certain at this point that you are
> not running the lock daemon. In contrast, on an NFSv3 client that I
> setup I see,
>

This is moderately likely to be common: many people incorrectly believe the
lock manager is a server-only daemon, and reliance on file locking is
uncommon enough that they are rarely disabused of this belief.

-- 
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: Can't push to haddock

[Brandon Allbery]

On Tue, Dec 19, 2017 at 4:30 AM, Sven Panne  wrote:

> I think this is a question of perspective: Having the master repository on
> GitHub doesn't mean you are in immediate danger or lose your "family
> jewels". IMHO it's quite the contrary: I'm e.g. sure that in case that
> something goes wrong with GitHub, there is far more manpower behind it to
> fix that than for any self-hosted repository. And you can of course have
> some mirror of your GitHub repo in case of e.g. an earthquake/meteor/... in
> the San Francisco area... ;-)
>

You're also assuming github doesn't suddenly pull a SourceForge (or a
Gitorious for that matter). Business cares not what it steamrolls in the
name of profit.

I fail to understand why, with multiple examples of the folly of this
belief out there, people are still willing to bet on *this* company being
*different* from all others and absolutely safe to trust.

-- 
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: Dynamically choosing the main function

[Brandon Allbery]

On Mon, Nov 13, 2017 at 2:46 AM, Harendra Kumar 
wrote:

> Also, the symbols are anyway exposed to the users, we just ask the users
> to not look at those.
>

Only if you built a dynamic executable, or built for debugging. Default
static executables are stripped.

-- 
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: Dynamically choosing the main function

[Brandon Allbery]

On Sun, Nov 12, 2017 at 11:18 AM, Harendra Kumar 
wrote:

> GHC allows choosing a main function at link time using the "-main-is"
> option. I was wondering if there is a possibility to choose the main
> function at runtime. Or even better, if something equivalent to "ghc -e"
> is somehow possible in a linked binary executable. If not, are there any
> plans to achieve something like that in future? Are there any theoretical,
> practical obstacles to that?
>

-e is just running the compiler's bytecode backend on an expression from
the command line instead of a declaration from a file. It's not related to
this.

I might point out that this is not at all common from any language. A
limited (and Unix-specific) mechanism is to have main pick from a list of
fixed operating modes based on the program's basename, which can be set in
the filesystem by making a hard link to the executable with a different
basename.

-- 
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: Long standing annoying issue in ghci

[Brandon Allbery]

On Tue, Dec 5, 2017 at 12:36 PM, cheater00 cheater00 
wrote:

> without color coding the prompt so I can't really turn it off. It
> seems like a simple arithmetic issue somewhere in the readline
> implementation.
>

It's not arithmetic except in the sense that it's not doing *any* math.
Color codes in a terminal are necessarily implemented as character
sequences (this is pretty much the definition of a terminal interface), and
haskeline makes no effort to recognize them, so it treats them the same as
displayed character sequences and skips over them as if they were displayed
characters.

GNU readline handles this by recognizing the character mode sequences as
not taking up character positions (this is more complex than you think
given that GNU readline doesn't assume all terminals obey the ANSI
standard; as it turns out, neither does haskeline, so it actually gets a
bit nasty), and recognizing the special behavior of carriage return, and
providing \[ \] escapes to declare the sequence inside as "invisible" to to
character positioning (and it's on the person crafting the prompt to insure
that it actually is). Beyond that, it'd actually have to implement a
'terminal emulator' internally to get it right in all cases --- and i'd be
on the user to ensure their declared terminal type matches the actual one
well enough for the 'terminal emulator' to reflect the terminal's actual
behavior, so it'd be a potential source of even weirder behavior.

So, (a) haskeline issue, not strictly ghc/ghci, and (b) not really fixable,
but partially work-around-able for common cases.

-- 
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: How to load & parse an HI (interface) file?

[Brandon Allbery]

The problem with the API is it's complex and can break between ghc versions.
But --show-iface is even more fragile and prone to break between ghc
versions.
The history of the plugins package constitutes a record of both kinds of
pain.

On Sat, Dec 2, 2017 at 9:11 PM, Saurabh Nanda <saurabhna...@gmail.com>
wrote:

> > I would be cautious about using the ghc-api hi file interfaces; hi files
> turn out to interact with a
> > lot of low-level parts in complex ways (even to the extent that they're
> a large part of why ghc
> > can't parallelize builds itself and attempts to change that have mostly
> failed).
>
> Are you cautioning against using the GHC API (as opposed to the
> --show-iface command line interface)
> or using HI files themselves?
>
> -- Saurabh.
>
>
> On Sun, Dec 3, 2017 at 2:04 AM, Brandon Allbery <allber...@gmail.com>
> wrote:
>
>> I would be cautious about using the ghc-api hi file interfaces; hi files
>> turn out to interact with a lot of low-level parts in complex ways (even to
>> the extent that they're a large part of why ghc can't parallelize builds
>> itself and attempts to change that have mostly failed).
>>
>> But if you must do this, you *really* want to have
>> https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler ready to hand
>> --- and go through it first so you have some idea of how it works; much of
>> it is links to the lower level details (often straight into the source).
>>
>> On Sat, Dec 2, 2017 at 10:59 AM, Saurabh Nanda <saurabhna...@gmail.com>
>> wrote:
>>
>>> (GHC newbie alert -- is this the right mailing list for these kind of
>>> questions?)
>>>
>>> I"m writing some code to figure out all the instances of particular
>>> type-classes and after exploring a lot of options (hlint, haskell-src-exts,
>>> annotations, doctests, etc), I realized that the compiler had already
>>> figured it out and written it to disk for me!
>>>
>>> More digging led me to https://www.stackage.org/haddo
>>> ck/lts-9.0/ghc-8.0.2/LoadIface.html#v:loadSrcInterface after which I
>>> got stuck. How does one call this function? Specifically:
>>>
>>> * What is SDoc and how to construct a reasonable value for this argument?
>>> * IsBootInterface would mostly be False, right?
>>> * What does `Maybe FastString` represent and how does one construct it?
>>> * Finally how does one evaluate the resulting monadic action to get
>>> access to the underlying `ModIface`?
>>>
>>> -- Saurabh.
>>>
>>>
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>> ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>
>
> --
> http://www.saurabhnanda.com
>



-- 
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: How to load & parse an HI (interface) file?

[Brandon Allbery]

I would be cautious about using the ghc-api hi file interfaces; hi files
turn out to interact with a lot of low-level parts in complex ways (even to
the extent that they're a large part of why ghc can't parallelize builds
itself and attempts to change that have mostly failed).

But if you must do this, you *really* want to have
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler ready to hand ---
and go through it first so you have some idea of how it works; much of it
is links to the lower level details (often straight into the source).

On Sat, Dec 2, 2017 at 10:59 AM, Saurabh Nanda 
wrote:

> (GHC newbie alert -- is this the right mailing list for these kind of
> questions?)
>
> I"m writing some code to figure out all the instances of particular
> type-classes and after exploring a lot of options (hlint, haskell-src-exts,
> annotations, doctests, etc), I realized that the compiler had already
> figured it out and written it to disk for me!
>
> More digging led me to https://www.stackage.org/haddock/lts-9.0/ghc-8.0.2/
> LoadIface.html#v:loadSrcInterface after which I got stuck. How does one
> call this function? Specifically:
>
> * What is SDoc and how to construct a reasonable value for this argument?
> * IsBootInterface would mostly be False, right?
> * What does `Maybe FastString` represent and how does one construct it?
> * Finally how does one evaluate the resulting monadic action to get access
> to the underlying `ModIface`?
>
> -- Saurabh.
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>


-- 
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: Q: Types in GADT pattern match

[Brandon Allbery]

On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif  wrote:

> My original question, though, is not answered yet, namely why not to
> detect that we are about to pattern match on a GADT constructor and
> allow the programmer to capture the *refined* type with her type
> annotation. Sure this would necessitate a change to the type checker,
> but would also increase the expressive power a bit.
>
> Is there some fundamental problem with this? Or simply nobody wanted
> to do this yet? Would it be hard to implement type checking *after*
> refinement on GADT(-like) patterns?
>

I wouldn't be surprised if type checking is precisely what enables
refinement, making this a bit chicken-and-egg.

-- 
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: Relocatable dist

[Brandon Allbery]

On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <
moritz.angerm...@gmail.com> wrote:

> However, I am now again at the point where I start hacking on the build
> system, while Hadrian is imminent.  And this is quite depressing
>

Realistically, while Hadrian going into the tree may be imminent, as I
understand it Hadrian becoming the primary build system --- or even a
viable alternative build system --- is not. It's more of a repo logistics
speed bump. Just let it go for now.

-- 
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: Relocatable dist

[Brandon Allbery]

Discussion I've been seeing is Hadrian will not be ready for production use
for 8.4. Pulling it in tree is scheduled for 8.4 mostly to make it easier
to keep up to date with other changes and to make it easier to work on and
test the various missing pieces: as I understand it, Hadrian can't yet deal
with all of the various platform special cases, etc. that an actual release
requires.

On Tue, Oct 24, 2017 at 8:02 PM, Manuel M T Chakravarty <
c...@justtesting.org> wrote:

> Why are you saying that?
>
> I think, Moritz is right. Hadrian is supposed to be the build system for
> 8.4. Adding new functionality for cross-compilation to the old build system
> is frustrating.
>
> Manuel
>
> Brandon Allbery <allber...@gmail.com>:
>
> On Tue, Oct 24, 2017 at 5:02 AM, Moritz Angermann <
> moritz.angerm...@gmail.com> wrote:
>
>> However, I am now again at the point where I start hacking on the build
>> system, while Hadrian is imminent.  And this is quite depressing
>>
>
> Realistically, while Hadrian going into the tree may be imminent, as I
> understand it Hadrian becoming the primary build system --- or even a
> viable alternative build system --- is not. It's more of a repo logistics
> speed bump. Just let it go for now.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>


-- 
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: pattern signatures

[Brandon Allbery]

Further complicated by the fact that that form used to be called a "pattern
signature" with accompanying extension, until that was folded into
ScopedTypeVariables extension.

On Fri, Jan 5, 2018 at 9:41 AM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Ah yes. I think we started with "pattern synonym signature" for (b) but
> have since denenerated to "pattern signature" which is quite confusing.
>
> User advice would be good!
>
> S
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 05 January 2018 13:48
> |  To: GHC 
> |  Subject: pattern signatures
> |
> |  Hi devs,
> |
> |  Is a pattern signature
> |
> |  a) something you put after `pattern P ::` ?
> |  b) something you put after `::` in a pattern, as in `foo (Proxy ::
> |  Proxy a)` ?
> |
> |  I've seen the term "pattern signature" apply to both, and I've been
> |  tripped up by this. Does anyone have terminology that unambiguously
> |  separates these two constructs that we can all adopt?
> |
> |  Thanks!
> |  Richard
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs=02%7C01%7Csimonpj%40microsoft.com%7Cbc86346cc90f4a9516d108d5
> |  5442f5a0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6365075689386605
> |  89=gvjnHyGAojz982UEV1u0hZPKH%2B%2F3UjiDlQm10%2BRZ7r8%3D
> |  =0
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
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: rolling span and groupBy for lists

[Brandon Allbery]

Why do I suddenly catch a whiff of https://xkcd.com/927/ ?

On Mon, Feb 5, 2018 at 1:13 PM, Harendra Kumar 
wrote:

> According to hayoo there seem to be 7 different implementations of this
> same function. Yours is 8th and mine is 9th and other people may have more
> not uploaded or maybe the ones that hayoo is not able to find. Does that
> make a case for including this in some standard place?
>
> -harendra
>
> On 5 February 2018 at 12:22, Evan Laforge  wrote:
>
>> I have my own list library with a bunch of things like this.  I think
>> it's what most people do, and some upload them to hackage, e.g.
>> utility-ht or the split package, or data-ordlist.
>>
>> Specifically, I think rollingGroupBy is what I call splitWith:
>>
>> -- | Split @xs@ before places where @f@ matches.
>> --
>> -- > split_with (==1) [1,2,1]
>> -- > --> [[], [1, 2], [1]]
>> split_with :: (a -> Bool) -> [a] -> NonNull [a]
>> -- ^ output is non-null, and the contents are also, except the first
>> one
>>
>> You can probably find something like this in 'split', or if not, that
>> might be a good place to contribute it.
>>
>> I have a bunch of grouping functions too, which I use all the time, so
>> if there's some kind of general list grouping package then maybe I
>> could put them there.
>>
>> On the other hand, this sort of thing is pretty individual, so it
>> doesn't seem so bad for each person to have their own local library.
>> That way you know it fits your style.  Ultimately I think that's why
>> none of the split functions made it into Data.List, every person has a
>> slightly different idea of what it should be.
>>
>> On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar 
>> wrote:
>> > Hi,
>> >
>> > For a small problem, I was looking for a groupBy like function that
>> groups
>> > based on a predicate on successive elements but I could not find one. I
>> > wrote these little functions for that purpose:
>> >
>> > -- | Like span, but with a predicate that compares two successive
>> elements.
>> > The
>> > -- span ends when the two successive elements do not satisfy the
>> predicate.
>> > rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a])
>> > rollingSpan _ xs@[] = (xs, xs)
>> > rollingSpan _ xs@[_] = (xs, [])
>> > rollingSpan p (x1:xs@(x2:_))
>> > | p x1 x2 =
>> > let (ys, zs) = rollingSpan p xs
>> > in (x1 : ys, zs)
>> > | otherwise = ([x1], xs)
>> >
>> > -- | Like 'groupBy' but with a predicate that compares two successive
>> > elements.
>> > -- A group ends when two successive elements do not satisfy the
>> predicate.
>> > rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]]
>> > rollingGroupBy _ [] = []
>> > rollingGroupBy cmp xs =
>> > let (ys, zs) = rollingSpan cmp xs
>> > in ys : rollingGroupBy cmp zs
>> >
>> > Are there any existing functions that serve this purpose or is there any
>> > simpler way to achieve such functionality? If not, where is the right
>> place
>> > for these, if any. Can they be included in Data.List in base?
>> >
>> > Thanks,
>> > Harendra
>> >
>> > ___
>> > 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
>
>


-- 
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: [Haskell-cafe] rolling span and groupBy for lists

[Brandon Allbery]

We have two groups of "leaders", with partially opposing goals. This is a
disaster looking for an excuse to happen.

On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar 
wrote:

> On 6 February 2018 at 00:33, Sergiu Ivanov  wrote:
>
>> Thus quoth  Harendra Kumar  on Mon Feb 05 2018 at 18:30 (+0100):
>> > Yes, Hayoo seems to be giving better results, I found more variants
>> having
>> > the behavior I want, it seems this variant is quite popular but still
>> not
>> > in any standard libraries.
>> >
>> > Interestingly the problem of too many choices and no standard one that
>> can
>> > be discovered applies to search engines as well. In this case there are
>> > only two choices but still it is of the same nature. I knew about hayoo
>> but
>> > forgot to use it in this case. How much time should one spend on
>> finding a
>> > trivial function before giving up and making the choice to write their
>> own?
>> > I wish there was a standard, quick, good quality way of discovering
>> what to
>> > use.  It seems the Haskell ecosystem DNA encourages more and more
>> > fragmentation rather than consolidation. I think the community/leaders
>> > should acknowledge this problem and work on making things better in the
>> > short/long run.
>>
>> A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort
>> in this direction, has been recently announced:
>>
>
> Unfortunately, in my opinion, SLURP is taking things exactly in the
> opposite direction. I was talking about the problem of choice above and
> SLURP is giving even more choices  and therefore encouraging more
> fragmentation. We should have just one good choice to stop wasting time and
> energy finding the best choice among millions available. Everyone should
> focus on making that one choice better rather spending energy in creating
> their own alternatives. This is where the Haskell ecosystem philosophy
> differs, it provides many choices in all aspects, it may be good in some
> cases but not always. SLURP is a technology solution which exactly fits in
> the same DNA. Technology can help us achieve the tasks that we set out to
> do but technology cannot motivate and influence us in what we choose to do
> and therefore ti cannot make the community focus on one goal - that
> requires real people leadership. If we do not focus on one goal, even with
> the best technology we may not succeed. Just my 2 cents.
>
> -harendra
>
>
>
>>
>>
>> > -harendra
>> >
>> > On 5 February 2018 at 22:02, Sergiu Ivanov  wrote:
>> >
>> >> Hello Harendra,
>> >>
>> >> Thus quoth  Harendra Kumar  on Mon Feb 05 2018 at 16:43 (+0100):
>> >> >
>> >> > The irony is that theoretically you can find a Haskell package or
>> >> > implementation of whatever you can imagine but quite often it takes
>> more
>> >> > time to discover it than writing your own.
>> >>
>> >> Sometimes Hayoo! helps me out in such situations:
>> >>
>> >>   http://hayoo.fh-wedel.de/?query=groupBy
>> >>
>> >> utility-ht shows up.
>> >>
>> >> --
>> >> Sergiu
>> >>
>>
>>
>> --
>> Sergiu
>>
>
>
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>



-- 
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