From george.colpitts at gmail.com  Thu Jan  1 13:58:40 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 09:58:40 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
Message-ID: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>

I built from source on Mac OS and found the following issues:


   - llvm , compiling with llvm (3.4.2) gives the following warnings:
      - $ ghc  -fllvm cubeFast.hs
      [1 of 1] Compiling Main             ( cubeFast.hs, cubeFast.o )
      clang: warning: argument unused during compilation:
      '-fno-stack-protector'
      clang: warning: argument unused during compilation: '-D
      TABLES_NEXT_TO_CODE'
      clang: warning: argument unused during compilation: '-I .'
      clang: warning: argument unused during compilation: '-fno-common'
      clang: warning: argument unused during compilation: '-U __PIC__'
      clang: warning: argument unused during compilation: '-D __PIC__'
      Linking cubeFast ...
      - running the resulting executable crashes (compiling without -fllvm
      gives no warnings and executable works properly)
      -  cat bigCube.txt | ./cubeFast > /dev/null
      Segmentation fault: 11
      - Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
      Exception Codes:       KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460


   - ?cabal install vector fails:
   - [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
      Data/Vector/Fusion/Stream/Monadic.hs,
      dist/build/Data/Vector/Fusion/Stream/Monadic.o )
      <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,
      5): 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)
   - ?cabal install cpphs fails:?
   -    cabal install cpphs
      Resolving dependencies...
      Configuring cpphs-1.13...
      Building cpphs-1.13...
      Failed to install cpphs-1.13
      Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ):
      Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
      Fields allowed in this section:
      name, version, cabal-version, build-type, license, license-file,
      license-files, copyright, maintainer, stability, homepage,
      package-url, bug-reports, synopsis, description, category, author,
      tested-with, data-files, data-dir, extra-source-files,
      extra-tmp-files, extra-doc-files
      Configuring cpphs-1.13...
      Building cpphs-1.13...
      Preprocessing library cpphs-1.13...
      - Language/Preprocessor/Cpphs.hs:1:1:
          Could not find module ?Prelude?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/CppIfdef.hs:32:8:
          Could not find module ?Numeric?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/CppIfdef.hs:33:8:
          Could not find module ?System.IO.Unsafe?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/CppIfdef.hs:34:8:
          Could not find module ?System.IO?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/MacroPass.hs:29:8:
          Could not find module ?Control.Monad?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/MacroPass.hs:30:8:
          Could not find module ?System.Time?
          Perhaps you meant
            System.CPUTime (needs flag -package-key base-4.8.0.0)
            System.Cmd (needs flag -package-key
      process-1.2.1.0 at proce_ADbmNMhxdsoDn9NrOWjezu)
            System.Mem (needs flag -package-key base-4.8.0.0)
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/MacroPass.hs:31:8:
          Could not find module ?System.Locale?
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/Options.hs:22:8:
          Could not find module ?Data.Maybe?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Cpphs/ReadFirst.hs:19:8:
          Could not find module ?System.Directory?
          It is a member of the hidden package
      ?directory-1.2.1.1 at direc_3m6Ew9I164U5MIkATLCdb8?.
          Perhaps you need to add ?directory? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Unlit.hs:5:8:
          Could not find module ?Data.Char?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.

      Language/Preprocessor/Unlit.hs:6:8:
          Could not find module ?Data.List?
          It is a member of the hidden package ?base-4.8.0.0?.
          Perhaps you need to add ?base? to the build-depends in your
      .cabal file.
          Use -v to see a list of the files searched for.
      cabal: Error: some packages failed to install:
      cpphs-1.13 failed during the building phase. The exception was:
      ExitFailure 1

?Configuration details:


   - Mac OS 10.10.1 (Yosemite)
   -  uname -a
   Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
   00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
   - llvm info:
   -  opt --version
   LLVM (http://llvm.org/):
     LLVM version 3.4.2
     Optimized build with assertions.
     Built Oct 31 2014 (23:14:30).
     Default target: x86_64-apple-darwin14.0.0
     Host CPU: corei7
   -  gcc --version
   gcc (Homebrew gcc 4.9.1) 4.9.1
   Copyright (C) 2014 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is
   NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
   PURPOSE.
   - ? /usr/bin/ghc --info
    [("Project name","The Glorious Glasgow Haskell Compilation System")
    ,("GCC extra via C opts"," -fwrapv")
    ,("C compiler command","/usr/bin/gcc")
    ,("C compiler flags"," -m64 -fno-stack-protector")
    ,("C compiler link flags"," -m64")
    ,("Haskell CPP command","/usr/bin/gcc")
    ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
   -Wno-unicode -Wno-trigraphs")
    ,("ld command","/usr/bin/ld")
    ,("ld flags"," -arch x86_64")
    ,("ld supports compact unwind","YES")
    ,("ld supports build-id","NO")
    ,("ld supports filelist","YES")
    ,("ld is GNU ld","NO")
    ,("ar command","/usr/bin/ar")
    ,("ar flags","clqs")
    ,("ar supports at file","NO")
    ,("touch command","touch")
    ,("dllwrap command","/bin/false")
    ,("windres command","/bin/false")
    ,("libtool command","libtool")
    ,("perl command","/usr/bin/perl")
    ,("target os","OSDarwin")
    ,("target arch","ArchX86_64")
    ,("target word size","8")
    ,("target has GNU nonexec stack","False")
    ,("target has .ident directive","True")
    ,("target has subsections via symbols","True")
    ,("Unregisterised","NO")
    ,("LLVM llc command","llc")
    ,("LLVM opt command","opt")
    ,("Project version","7.8.3")
    ,("Booter version","7.6.3")
    ,("Stage","2")
    ,("Build platform","x86_64-apple-darwin")
    ,("Host platform","x86_64-apple-darwin")
    ,("Target platform","x86_64-apple-darwin")
    ,("Have interpreter","YES")
    ,("Object splitting supported","YES")
    ,("Have native code generator","YES")
    ,("Support SMP","YES")
    ,("Tables next to code","YES")
    ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
   thr_debug_dyn l_dyn thr_l_dyn")
    ,("Support dynamic-too","YES")
    ,("Support parallel --make","YES")
    ,("Dynamic by default","NO")
    ,("GHC Dynamic","YES")
    ,("Leading underscore","YES")
    ,("Debug on","False")

    ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3")
    ,("Global Package
   DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d")
    ]
   - Not sure I found the correct instructions for building from source,  I
   used the following:
      -

      $ autoreconf
      $ ./configure
      $ make
      $ make install




On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin at well-typed.com>
wrote:

> We are pleased to announce the first release candidate for GHC 7.10.1:
>
>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
>
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>
> We plan to make the 7.10.1 release sometime in February of 2015. We
> expect another RC to occur during January of 2015.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/2aee43f9/attachment.html>

From malcolm.wallace at me.com  Thu Jan  1 14:43:02 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Thu, 01 Jan 2015 14:43:02 +0000
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
In-Reply-To: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>
References: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>
Message-ID: <817C2B57-5168-4903-8EF7-BFC31062FE96@me.com>


On 1 Jan 2015, at 13:58, George Colpitts wrote:

> Configuring cpphs-1.13...
> Building cpphs-1.13...
> Warning: cpphs.cabal: Unknown fields: build-depends (line 5)

>     Could not find module ?Prelude?
>     It is a member of the hidden package ?base-4.8.0.0?.
>     Perhaps you need to add ?base? to the build-depends in your .cabal file.

The two statements "unknown field build-depends" and "add package to build-depends" seem rather contradictory.  How can this be fixed?

Regards,
    Malcolm


From hesselink at gmail.com  Thu Jan  1 15:02:15 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Thu, 1 Jan 2015 16:02:15 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
In-Reply-To: <817C2B57-5168-4903-8EF7-BFC31062FE96@me.com>
References: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>
 <817C2B57-5168-4903-8EF7-BFC31062FE96@me.com>
Message-ID: <CAPeieQHasMa=usmff8R-kukLD2WKrk+=QxtdETTd1cZiaN9zOA@mail.gmail.com>

It seems to be building a very old cpphs (1.13) with a new version of
cabal. cpphs-1.13 has a top-level build-depends statement which isn't
allowed anymore: it should now be added to the library section, which
is what the error message tries to indicate.

Erik

On Thu, Jan 1, 2015 at 3:43 PM, Malcolm Wallace <malcolm.wallace at me.com> wrote:
>
> On 1 Jan 2015, at 13:58, George Colpitts wrote:
>
>> Configuring cpphs-1.13...
>> Building cpphs-1.13...
>> Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
>
>>     Could not find module ?Prelude?
>>     It is a member of the hidden package ?base-4.8.0.0?.
>>     Perhaps you need to add ?base? to the build-depends in your .cabal file.
>
> The two statements "unknown field build-depends" and "add package to build-depends" seem rather contradictory.  How can this be fixed?
>
> Regards,
>     Malcolm
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From george.colpitts at gmail.com  Thu Jan  1 17:08:44 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 13:08:44 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
Message-ID: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>

?$ ?
cabal update
Downloading the latest package list from hackage.haskell.org
Note: *there is a new version of cabal-install available.*
To upgrade, run: cabal install cabal-install
bash-3.2$ *cabal install -j3 cabal-install *
*?...?*


*Resolving dependencies...cabal: Could not resolve dependencies:*
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6)
next goal: process (dependency of cabal-install-1.20.0.6)
rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
process
=> unix==2.7.1.0/installed-4ae...)
trying: process-1.2.1.0
next goal: directory (dependency of cabal-install-1.20.0.6)
rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.5 && <4.8)
rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.6)
rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.5)
rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.4)
rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
process => directory>=1.1 && <1.3)
Dependency tree exhaustively searched.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/3b8bfdb7/attachment.html>

From johan.tibell at gmail.com  Thu Jan  1 17:34:43 2015
From: johan.tibell at gmail.com (Johan Tibell)
Date: Thu, 1 Jan 2015 12:34:43 -0500
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
Message-ID: <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>

Try

cabal install --allow-newer=base -j3 cabal-install

Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the
upper bound on the base dependency if 1.20 is indeed compatible with the
latest base.

On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

>
>
> ?$ ?
> cabal update
> Downloading the latest package list from hackage.haskell.org
> Note: *there is a new version of cabal-install available.*
> To upgrade, run: cabal install cabal-install
> bash-3.2$ *cabal install -j3 cabal-install *
> *?...?*
>
>
> *Resolving dependencies...cabal: Could not resolve dependencies:*
> trying: cabal-install-1.20.0.6 (user goal)
> trying: base-4.8.0.0/installed-779... (dependency of
> cabal-install-1.20.0.6)
> next goal: process (dependency of cabal-install-1.20.0.6)
> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> process
> => unix==2.7.1.0/installed-4ae...)
> trying: process-1.2.1.0
> next goal: directory (dependency of cabal-install-1.20.0.6)
> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.5 && <4.8)
> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.6)
> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.5)
> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.4)
> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
> process => directory>=1.1 && <1.3)
> Dependency tree exhaustively searched.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/23e9aef2/attachment.html>

From george.colpitts at gmail.com  Thu Jan  1 18:00:20 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 14:00:20 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
Message-ID: <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>

Thanks, there seems to be dependency issues:

cabal install --allow-newer=base -j3 cabal-install
Resolving dependencies...
In order, the following would be installed:
deepseq-1.3.0.2 (latest: 1.4.0.0) (new version)
bytestring-0.10.4.1 (new version)
containers-0.5.6.2 (reinstall) changes: deepseq-1.4.0.0 -> 1.3.0.2
pretty-1.1.2.0 (new version)
text-1.2.0.3 (reinstall) changes: bytestring-0.10.6.0 -> 0.10.4.1,
deepseq-1.4.0.0 -> 1.3.0.2
parsec-3.1.7 (reinstall) changes: bytestring-0.10.6.0 -> 0.10.4.1
network-uri-2.6.0.1 (new package)
time-1.4.2 (latest: 1.5.0.1) (new version)
random-1.1 (reinstall) changes: time-1.5.0.1 -> 1.4.2
unix-2.7.1.0 (reinstall) changes: bytestring-0.10.6.0 -> 0.10.4.1,
time-1.5.0.1 -> 1.4.2
directory-1.2.1.0 (new version)
network-2.6.0.2 (new package)
HTTP-4000.2.19 (new package)
process-1.2.1.0 (reinstall) changes: deepseq-1.4.0.0 -> 1.3.0.2,
directory-1.2.1.1 -> 1.2.1.0
Cabal-1.20.0.3 (new version)
zlib-0.5.4.2 (new package)
cabal-install-1.20.0.6 (new package)
cabal: The following packages are likely to be broken by the reinstalls:
semigroups-0.16.0.1
void-0.7
contravariant-1.2.0.1
semigroupoids-4.2
bifunctors-4.2
comonad-4.2.2
parallel-3.2.0.6
hscolour-1.20.3
hpc-0.6.0.2
ghc-7.10.0.20141222
hoopl-3.10.0.2
hastache-0.6.1
haskeline-0.7.2.0
cereal-0.4.1.0
monad-par-extras-0.3.3
binary-0.7.2.3
bin-package-db-0.0.0.0
Cabal-1.22.0.0
attoparsec-0.12.1.2
abstract-deque-0.3
Glob-0.7.5
scientific-0.3.3.3
polyparse-1.11
cpphs-1.18.6
haskell-src-exts-1.16.0.1
hashable-1.2.3.1
unordered-containers-0.2.5.1
blaze-builder-0.3.3.4
MonadRandom-0.3.0.1
extra-1.0
cmdargs-0.10.12
directory-1.2.1.1
ansi-terminal-0.6.2.1
ansi-wl-pprint-0.6.7.1
Use --force-reinstalls if you want to install anyway.

On Thu, Jan 1, 2015 at 1:34 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Try
>
> cabal install --allow-newer=base -j3 cabal-install
>
> Once GHC 7.10 is out we might make another Cabal 1.20 release to bump the
> upper bound on the base dependency if 1.20 is indeed compatible with the
> latest base.
>
> On Thu, Jan 1, 2015 at 12:08 PM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>>
>>
>> ?$ ?
>> cabal update
>> Downloading the latest package list from hackage.haskell.org
>> Note: *there is a new version of cabal-install available.*
>> To upgrade, run: cabal install cabal-install
>> bash-3.2$ *cabal install -j3 cabal-install *
>> *?...?*
>>
>>
>> *Resolving dependencies...cabal: Could not resolve dependencies:*
>> trying: cabal-install-1.20.0.6 (user goal)
>> trying: base-4.8.0.0/installed-779... (dependency of
>> cabal-install-1.20.0.6)
>> next goal: process (dependency of cabal-install-1.20.0.6)
>> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
>> process
>> => unix==2.7.1.0/installed-4ae...)
>> trying: process-1.2.1.0
>> next goal: directory (dependency of cabal-install-1.20.0.6)
>> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
>> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
>> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.5 && <4.8)
>> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
>> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
>> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.6)
>> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.5)
>> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.4)
>> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
>> (conflict:
>> process => directory>=1.1 && <1.3)
>> Dependency tree exhaustively searched.
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/d4a97308/attachment.html>

From the.dead.shall.rise at gmail.com  Thu Jan  1 18:15:13 2015
From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov)
Date: Thu, 1 Jan 2015 19:15:13 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
 <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>
Message-ID: <CA+tcxkDhJ3nAQ8ikQ7h2rycgpjgF=gcLjUJyxtcpiO14dD2HfQ@mail.gmail.com>

Hi,

On 1 January 2015 at 19:00, George Colpitts <george.colpitts at gmail.com> wrote:
> Thanks, there seems to be dependency issues:

Try also adding '--allow-newer=bytestring,deepseq'.

From george.colpitts at gmail.com  Thu Jan  1 18:27:43 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 14:27:43 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CA+tcxkDhJ3nAQ8ikQ7h2rycgpjgF=gcLjUJyxtcpiO14dD2HfQ@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
 <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>
 <CA+tcxkDhJ3nAQ8ikQ7h2rycgpjgF=gcLjUJyxtcpiO14dD2HfQ@mail.gmail.com>
Message-ID: <CAB-d4A5em3tzaygUGw2vaEsQ9UmKTUo3AzFzkjn+Hn36dtNiiw@mail.gmail.com>

Thanks but that doesn't seem to work either:

 cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
cabal-install
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: cabal-install-1.20.0.6 (user goal)
trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6)
next goal: process (dependency of cabal-install-1.20.0.6)
rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
process
=> unix==2.7.1.0/installed-4ae...)
trying: process-1.2.1.0
next goal: directory (dependency of cabal-install-1.20.0.6)
rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.5 && <4.8)
rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.6)
rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.5)
rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
directory => base>=4.2 && <4.4)
rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
process => directory>=1.1 && <1.3)
Dependency tree exhaustively searched.

On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov <
the.dead.shall.rise at gmail.com> wrote:

> Hi,
>
> On 1 January 2015 at 19:00, George Colpitts <george.colpitts at gmail.com>
> wrote:
> > Thanks, there seems to be dependency issues:
>
> Try also adding '--allow-newer=bytestring,deepseq'.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/ea39443c/attachment.html>

From george.colpitts at gmail.com  Thu Jan  1 18:34:49 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 14:34:49 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A5em3tzaygUGw2vaEsQ9UmKTUo3AzFzkjn+Hn36dtNiiw@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
 <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>
 <CA+tcxkDhJ3nAQ8ikQ7h2rycgpjgF=gcLjUJyxtcpiO14dD2HfQ@mail.gmail.com>
 <CAB-d4A5em3tzaygUGw2vaEsQ9UmKTUo3AzFzkjn+Hn36dtNiiw@mail.gmail.com>
Message-ID: <CAB-d4A4v==o_n_fuw-pRHy92oVp=+eW+s3QeAhtxD7K5AQ=2HA@mail.gmail.com>

following solves dependency problems, added a few more packages, thanks!

 cabal install
--allow-newer=base,bytestring,deepseq,unix,process,time,random -j3
cabal-install


On Thu, Jan 1, 2015 at 2:27 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Thanks but that doesn't seem to work either:
>
>  cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
> cabal-install
> Resolving dependencies...
> cabal: Could not resolve dependencies:
> trying: cabal-install-1.20.0.6 (user goal)
> trying: base-4.8.0.0/installed-779... (dependency of
> cabal-install-1.20.0.6)
> next goal: process (dependency of cabal-install-1.20.0.6)
> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> process
> => unix==2.7.1.0/installed-4ae...)
> trying: process-1.2.1.0
> next goal: directory (dependency of cabal-install-1.20.0.6)
> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.5 && <4.8)
> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.6)
> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.5)
> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.4)
> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
> process => directory>=1.1 && <1.3)
> Dependency tree exhaustively searched.
>
> On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov <
> the.dead.shall.rise at gmail.com> wrote:
>
>> Hi,
>>
>> On 1 January 2015 at 19:00, George Colpitts <george.colpitts at gmail.com>
>> wrote:
>> > Thanks, there seems to be dependency issues:
>>
>> Try also adding '--allow-newer=bytestring,deepseq'.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/edf0ef2c/attachment.html>

From george.colpitts at gmail.com  Thu Jan  1 18:42:10 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 14:42:10 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A4v==o_n_fuw-pRHy92oVp=+eW+s3QeAhtxD7K5AQ=2HA@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <CAK-tuPak28f79evJFNVX7QLaZCEVm6NqdP=rWG7zGD29Uv9Sdg@mail.gmail.com>
 <CAB-d4A5Edu4Gvm8f3psN2PUp+LbreO0mGUPgdVwx60Y5So8s-A@mail.gmail.com>
 <CA+tcxkDhJ3nAQ8ikQ7h2rycgpjgF=gcLjUJyxtcpiO14dD2HfQ@mail.gmail.com>
 <CAB-d4A5em3tzaygUGw2vaEsQ9UmKTUo3AzFzkjn+Hn36dtNiiw@mail.gmail.com>
 <CAB-d4A4v==o_n_fuw-pRHy92oVp=+eW+s3QeAhtxD7K5AQ=2HA@mail.gmail.com>
Message-ID: <CAB-d4A7f3_D=KPudrZ2vBWkiPb-tmux2JJkY-P+jeJaCs1m-_Q@mail.gmail.com>

however still fails to install but now due to problems with cabal itself

[76 of 76] Compiling Main             (
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/setup.hs,
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/Main.o
)
Linking
/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/Cabal-1.20.0.3-62215/Cabal-1.20.0.3/dist/setup/setup
...
Configuring Cabal-1.20.0.3...
Building Cabal-1.20.0.3...
Preprocessing library Cabal-1.20.0.3...

on the commandline: Warning:
    -package-name is deprecated: Use -this-package-key instead
ghc: ghc no longer supports single-file style package databases
(dist/package.conf.inplace) use 'ghc-pkg init' to create the database with
the correct format.
Updating documentation index
/Users/gcolpitts/Library/Haskell/share/doc/index.html
cabal: Error: some packages failed to install:
Cabal-1.20.0.3 failed during the building phase. The exception was:
ExitFailure 1
cabal-install-1.20.0.6 depends on Cabal-1.20.0.3 which failed to install.

On Thu, Jan 1, 2015 at 2:34 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> following solves dependency problems, added a few more packages, thanks!
>
>  cabal install
> --allow-newer=base,bytestring,deepseq,unix,process,time,random -j3
> cabal-install
>
>
> On Thu, Jan 1, 2015 at 2:27 PM, George Colpitts <george.colpitts at gmail.com
> > wrote:
>
>> Thanks but that doesn't seem to work either:
>>
>>  cabal install --allow-newer=base --allow-newer=bytestring,deepseq -j3
>> cabal-install
>> Resolving dependencies...
>> cabal: Could not resolve dependencies:
>> trying: cabal-install-1.20.0.6 (user goal)
>> trying: base-4.8.0.0/installed-779... (dependency of
>> cabal-install-1.20.0.6)
>> next goal: process (dependency of cabal-install-1.20.0.6)
>> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
>> process
>> => unix==2.7.1.0/installed-4ae...)
>> trying: process-1.2.1.0
>> next goal: directory (dependency of cabal-install-1.20.0.6)
>> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
>> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
>> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.5 && <4.8)
>> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
>> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
>> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.6)
>> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.5)
>> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
>> directory => base>=4.2 && <4.4)
>> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
>> (conflict:
>> process => directory>=1.1 && <1.3)
>> Dependency tree exhaustively searched.
>>
>> On Thu, Jan 1, 2015 at 2:15 PM, Mikhail Glushenkov <
>> the.dead.shall.rise at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> On 1 January 2015 at 19:00, George Colpitts <george.colpitts at gmail.com>
>>> wrote:
>>> > Thanks, there seems to be dependency issues:
>>>
>>> Try also adding '--allow-newer=bytestring,deepseq'.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/4ae1343e/attachment.html>

From ezyang at mit.edu  Thu Jan  1 18:54:47 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 01 Jan 2015 13:54:47 -0500
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
Message-ID: <1420138452-sup-5875@sabre>

If you still have your old GHC around, it will be much better to
compile the newest cabal-install using the *old GHC*, and then
use that copy to bootstrap a copy of the newest cabal-install.

Edward

Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
> ?$ ?
> cabal update
> Downloading the latest package list from hackage.haskell.org
> Note: *there is a new version of cabal-install available.*
> To upgrade, run: cabal install cabal-install
> bash-3.2$ *cabal install -j3 cabal-install *
> *?...?*
> 
> 
> *Resolving dependencies...cabal: Could not resolve dependencies:*
> trying: cabal-install-1.20.0.6 (user goal)
> trying: base-4.8.0.0/installed-779... (dependency of cabal-install-1.20.0.6)
> next goal: process (dependency of cabal-install-1.20.0.6)
> rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> process
> => unix==2.7.1.0/installed-4ae...)
> trying: process-1.2.1.0
> next goal: directory (dependency of cabal-install-1.20.0.6)
> rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.5 && <4.8)
> rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.6)
> rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.5)
> rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> directory => base>=4.2 && <4.4)
> rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0 (conflict:
> process => directory>=1.1 && <1.3)
> Dependency tree exhaustively searched.

From george.colpitts at gmail.com  Thu Jan  1 19:23:50 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 15:23:50 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <1420138452-sup-5875@sabre>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <1420138452-sup-5875@sabre>
Message-ID: <CAB-d4A6JfvLO8ayPFKjoSNEmqkBCij9E29memabdka2dLh6xPw@mail.gmail.com>

I still have 7.8.3 but it doesn't seem to want to build the latest cabal:

 ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.8.3
bash-3.2$ cabal install cabal-install
Resolving dependencies...
Configuring cabal-install-1.20.0.6...
Building cabal-install-1.20.0.6...
Installed cabal-install-1.20.0.6
Updating documentation index
/Users/gcolpitts/Library/Haskell/share/doc/index.html




On Thu, Jan 1, 2015 at 2:54 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> If you still have your old GHC around, it will be much better to
> compile the newest cabal-install using the *old GHC*, and then
> use that copy to bootstrap a copy of the newest cabal-install.
>
> Edward
>
> Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
> > ?$ ?
> > cabal update
> > Downloading the latest package list from hackage.haskell.org
> > Note: *there is a new version of cabal-install available.*
> > To upgrade, run: cabal install cabal-install
> > bash-3.2$ *cabal install -j3 cabal-install *
> > *?...?*
> >
> >
> > *Resolving dependencies...cabal: Could not resolve dependencies:*
> > trying: cabal-install-1.20.0.6 (user goal)
> > trying: base-4.8.0.0/installed-779... (dependency of
> cabal-install-1.20.0.6)
> > next goal: process (dependency of cabal-install-1.20.0.6)
> > rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> > process
> > => unix==2.7.1.0/installed-4ae...)
> > trying: process-1.2.1.0
> > next goal: directory (dependency of cabal-install-1.20.0.6)
> > rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> > time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> > rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> > directory => base>=4.5 && <4.8)
> > rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> > base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> > rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> > directory => base>=4.2 && <4.6)
> > rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> > directory => base>=4.2 && <4.5)
> > rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> > directory => base>=4.2 && <4.4)
> > rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
> (conflict:
> > process => directory>=1.1 && <1.3)
> > Dependency tree exhaustively searched.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/102587d6/attachment.html>

From ezyang at mit.edu  Thu Jan  1 19:37:08 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 01 Jan 2015 14:37:08 -0500
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <CAB-d4A6JfvLO8ayPFKjoSNEmqkBCij9E29memabdka2dLh6xPw@mail.gmail.com>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <1420138452-sup-5875@sabre>
 <CAB-d4A6JfvLO8ayPFKjoSNEmqkBCij9E29memabdka2dLh6xPw@mail.gmail.com>
Message-ID: <1420141005-sup-3185@sabre>

Oh, because Cabal HQ hasn't cut a release yet.

Try installing out of Git.  https://github.com/haskell/cabal/

Edward

Excerpts from George Colpitts's message of 2015-01-01 14:23:50 -0500:
> I still have 7.8.3 but it doesn't seem to want to build the latest cabal:
> 
>  ghc --version
> The Glorious Glasgow Haskell Compilation System, version 7.8.3
> bash-3.2$ cabal install cabal-install
> Resolving dependencies...
> Configuring cabal-install-1.20.0.6...
> Building cabal-install-1.20.0.6...
> Installed cabal-install-1.20.0.6
> Updating documentation index
> /Users/gcolpitts/Library/Haskell/share/doc/index.html
> 
> On Thu, Jan 1, 2015 at 2:54 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > If you still have your old GHC around, it will be much better to
> > compile the newest cabal-install using the *old GHC*, and then
> > use that copy to bootstrap a copy of the newest cabal-install.
> >
> > Edward
> >
> > Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
> > > ?$ ?
> > > cabal update
> > > Downloading the latest package list from hackage.haskell.org
> > > Note: *there is a new version of cabal-install available.*
> > > To upgrade, run: cabal install cabal-install
> > > bash-3.2$ *cabal install -j3 cabal-install *
> > > *?...?*
> > >
> > >
> > > *Resolving dependencies...cabal: Could not resolve dependencies:*
> > > trying: cabal-install-1.20.0.6 (user goal)
> > > trying: base-4.8.0.0/installed-779... (dependency of
> > cabal-install-1.20.0.6)
> > > next goal: process (dependency of cabal-install-1.20.0.6)
> > > rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> > > process
> > > => unix==2.7.1.0/installed-4ae...)
> > > trying: process-1.2.1.0
> > > next goal: directory (dependency of cabal-install-1.20.0.6)
> > > rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> > > time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> > > rejecting: directory-1.2.1.0 (conflict: base==4.8.0.0/installed-779...,
> > > directory => base>=4.5 && <4.8)
> > > rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> > > base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> > > rejecting: directory-1.1.0.2 (conflict: base==4.8.0.0/installed-779...,
> > > directory => base>=4.2 && <4.6)
> > > rejecting: directory-1.1.0.1 (conflict: base==4.8.0.0/installed-779...,
> > > directory => base>=4.2 && <4.5)
> > > rejecting: directory-1.1.0.0 (conflict: base==4.8.0.0/installed-779...,
> > > directory => base>=4.2 && <4.4)
> > > rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
> > (conflict:
> > > process => directory>=1.1 && <1.3)
> > > Dependency tree exhaustively searched.
> >

From george.colpitts at gmail.com  Thu Jan  1 20:57:59 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 1 Jan 2015 16:57:59 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - problem with latest
 cabal-install
In-Reply-To: <1420141005-sup-3185@sabre>
References: <CAB-d4A58+MUVM7emYP+4nK9VqebC86ripsEpTmupdr3fbbvAjg@mail.gmail.com>
 <1420138452-sup-5875@sabre>
 <CAB-d4A6JfvLO8ayPFKjoSNEmqkBCij9E29memabdka2dLh6xPw@mail.gmail.com>
 <1420141005-sup-3185@sabre>
Message-ID: <CAB-d4A6-PC+hnr=LCN5hZT+Q5C31_xow54Yf0TEBhjvZ=NoCdA@mail.gmail.com>

Thanks, I seem to have got that to work

On Thu, Jan 1, 2015 at 3:37 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Oh, because Cabal HQ hasn't cut a release yet.
>
> Try installing out of Git.  https://github.com/haskell/cabal/
>
> Edward
>
> Excerpts from George Colpitts's message of 2015-01-01 14:23:50 -0500:
> > I still have 7.8.3 but it doesn't seem to want to build the latest cabal:
> >
> >  ghc --version
> > The Glorious Glasgow Haskell Compilation System, version 7.8.3
> > bash-3.2$ cabal install cabal-install
> > Resolving dependencies...
> > Configuring cabal-install-1.20.0.6...
> > Building cabal-install-1.20.0.6...
> > Installed cabal-install-1.20.0.6
> > Updating documentation index
> > /Users/gcolpitts/Library/Haskell/share/doc/index.html
> >
> > On Thu, Jan 1, 2015 at 2:54 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> > > If you still have your old GHC around, it will be much better to
> > > compile the newest cabal-install using the *old GHC*, and then
> > > use that copy to bootstrap a copy of the newest cabal-install.
> > >
> > > Edward
> > >
> > > Excerpts from George Colpitts's message of 2015-01-01 12:08:44 -0500:
> > > > ?$ ?
> > > > cabal update
> > > > Downloading the latest package list from hackage.haskell.org
> > > > Note: *there is a new version of cabal-install available.*
> > > > To upgrade, run: cabal install cabal-install
> > > > bash-3.2$ *cabal install -j3 cabal-install *
> > > > *?...?*
> > > >
> > > >
> > > > *Resolving dependencies...cabal: Could not resolve dependencies:*
> > > > trying: cabal-install-1.20.0.6 (user goal)
> > > > trying: base-4.8.0.0/installed-779... (dependency of
> > > cabal-install-1.20.0.6)
> > > > next goal: process (dependency of cabal-install-1.20.0.6)
> > > > rejecting: process-1.2.1.0/installed-2db... (conflict: unix==2.7.1.0,
> > > > process
> > > > => unix==2.7.1.0/installed-4ae...)
> > > > trying: process-1.2.1.0
> > > > next goal: directory (dependency of cabal-install-1.20.0.6)
> > > > rejecting: directory-1.2.1.1/installed-b08... (conflict: directory =>
> > > > time==1.5.0.1/installed-c23..., cabal-install => time>=1.1 && <1.5)
> > > > rejecting: directory-1.2.1.0 (conflict: base==
> 4.8.0.0/installed-779...,
> > > > directory => base>=4.5 && <4.8)
> > > > rejecting: directory-1.2.0.1, 1.2.0.0 (conflict:
> > > > base==4.8.0.0/installed-779..., directory => base>=4.2 && <4.7)
> > > > rejecting: directory-1.1.0.2 (conflict: base==
> 4.8.0.0/installed-779...,
> > > > directory => base>=4.2 && <4.6)
> > > > rejecting: directory-1.1.0.1 (conflict: base==
> 4.8.0.0/installed-779...,
> > > > directory => base>=4.2 && <4.5)
> > > > rejecting: directory-1.1.0.0 (conflict: base==
> 4.8.0.0/installed-779...,
> > > > directory => base>=4.2 && <4.4)
> > > > rejecting: directory-1.0.1.2, 1.0.1.1, 1.0.1.0, 1.0.0.3, 1.0.0.0
> > > (conflict:
> > > > process => directory>=1.1 && <1.3)
> > > > Dependency tree exhaustively searched.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150101/2536223c/attachment.html>

From george.colpitts at gmail.com  Fri Jan  2 13:12:34 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 2 Jan 2015 09:12:34 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - feedback on Mac OS
In-Reply-To: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>
References: <CAB-d4A7kbzMS7c5VHPsSuJGxV9fXftuDtUhqkSbZZc9YfuiB9A@mail.gmail.com>
Message-ID: <CAB-d4A7SJFiA7eih92UCUHLKSuS4JhQW-7b-ynHCRSOUZeLUXg@mail.gmail.com>

Only problem remaining is compiling with -fllvm and running resulting
executable

Other problems below have now been solved:


   - cpphs - new version resolves problem
   - cabal install vector - upgrade to gcc (Homebrew gcc 4.9.2_1) 4.9.2
   solves problem


On Thu, Jan 1, 2015 at 9:58 AM, George Colpitts <george.colpitts at gmail.com>
wrote:

> I built from source on Mac OS and found the following issues:
>
>
>    - llvm , compiling with llvm (3.4.2) gives the following warnings:
>       - $ ghc  -fllvm cubeFast.hs
>       [1 of 1] Compiling Main             ( cubeFast.hs, cubeFast.o )
>       clang: warning: argument unused during compilation:
>       '-fno-stack-protector'
>       clang: warning: argument unused during compilation: '-D
>       TABLES_NEXT_TO_CODE'
>       clang: warning: argument unused during compilation: '-I .'
>       clang: warning: argument unused during compilation: '-fno-common'
>       clang: warning: argument unused during compilation: '-U __PIC__'
>       clang: warning: argument unused during compilation: '-D __PIC__'
>       Linking cubeFast ...
>       - running the resulting executable crashes (compiling without
>       -fllvm gives no warnings and executable works properly)
>       -  cat bigCube.txt | ./cubeFast > /dev/null
>       Segmentation fault: 11
>       - Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
>       Exception Codes:       KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460
>
>
>    - ?cabal install vector fails:
>    - [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic (
>       Data/Vector/Fusion/Stream/Monadic.hs,
>       dist/build/Data/Vector/Fusion/Stream/Monadic.o )
>       <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,
>       5): 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)
>    - ?cabal install cpphs fails:?
>    -    cabal install cpphs
>       Resolving dependencies...
>       Configuring cpphs-1.13...
>       Building cpphs-1.13...
>       Failed to install cpphs-1.13
>       Build log ( /Users/gcolpitts/.cabal/logs/cpphs-1.13.log ):
>       Warning: cpphs.cabal: Unknown fields: build-depends (line 5)
>       Fields allowed in this section:
>       name, version, cabal-version, build-type, license, license-file,
>       license-files, copyright, maintainer, stability, homepage,
>       package-url, bug-reports, synopsis, description, category, author,
>       tested-with, data-files, data-dir, extra-source-files,
>       extra-tmp-files, extra-doc-files
>       Configuring cpphs-1.13...
>       Building cpphs-1.13...
>       Preprocessing library cpphs-1.13...
>       - Language/Preprocessor/Cpphs.hs:1:1:
>           Could not find module ?Prelude?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/CppIfdef.hs:32:8:
>           Could not find module ?Numeric?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/CppIfdef.hs:33:8:
>           Could not find module ?System.IO.Unsafe?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/CppIfdef.hs:34:8:
>           Could not find module ?System.IO?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/MacroPass.hs:29:8:
>           Could not find module ?Control.Monad?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/MacroPass.hs:30:8:
>           Could not find module ?System.Time?
>           Perhaps you meant
>             System.CPUTime (needs flag -package-key base-4.8.0.0)
>             System.Cmd (needs flag -package-key
>       process-1.2.1.0 at proce_ADbmNMhxdsoDn9NrOWjezu)
>             System.Mem (needs flag -package-key base-4.8.0.0)
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/MacroPass.hs:31:8:
>           Could not find module ?System.Locale?
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/Options.hs:22:8:
>           Could not find module ?Data.Maybe?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Cpphs/ReadFirst.hs:19:8:
>           Could not find module ?System.Directory?
>           It is a member of the hidden package
>       ?directory-1.2.1.1 at direc_3m6Ew9I164U5MIkATLCdb8?.
>           Perhaps you need to add ?directory? to the build-depends in
>       your .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Unlit.hs:5:8:
>           Could not find module ?Data.Char?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>
>       Language/Preprocessor/Unlit.hs:6:8:
>           Could not find module ?Data.List?
>           It is a member of the hidden package ?base-4.8.0.0?.
>           Perhaps you need to add ?base? to the build-depends in your
>       .cabal file.
>           Use -v to see a list of the files searched for.
>       cabal: Error: some packages failed to install:
>       cpphs-1.13 failed during the building phase. The exception was:
>       ExitFailure 1
>
> ?Configuration details:
>
>
>    - Mac OS 10.10.1 (Yosemite)
>    -  uname -a
>    Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
>    00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
>    - llvm info:
>    -  opt --version
>    LLVM (http://llvm.org/):
>      LLVM version 3.4.2
>      Optimized build with assertions.
>      Built Oct 31 2014 (23:14:30).
>      Default target: x86_64-apple-darwin14.0.0
>      Host CPU: corei7
>    -  gcc --version
>    gcc (Homebrew gcc 4.9.1) 4.9.1
>    Copyright (C) 2014 Free Software Foundation, Inc.
>    This is free software; see the source for copying conditions.  There
>    is NO
>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>    PURPOSE.
>    - ? /usr/bin/ghc --info
>     [("Project name","The Glorious Glasgow Haskell Compilation System")
>     ,("GCC extra via C opts"," -fwrapv")
>     ,("C compiler command","/usr/bin/gcc")
>     ,("C compiler flags"," -m64 -fno-stack-protector")
>     ,("C compiler link flags"," -m64")
>     ,("Haskell CPP command","/usr/bin/gcc")
>     ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
>    -Wno-unicode -Wno-trigraphs")
>     ,("ld command","/usr/bin/ld")
>     ,("ld flags"," -arch x86_64")
>     ,("ld supports compact unwind","YES")
>     ,("ld supports build-id","NO")
>     ,("ld supports filelist","YES")
>     ,("ld is GNU ld","NO")
>     ,("ar command","/usr/bin/ar")
>     ,("ar flags","clqs")
>     ,("ar supports at file","NO")
>     ,("touch command","touch")
>     ,("dllwrap command","/bin/false")
>     ,("windres command","/bin/false")
>     ,("libtool command","libtool")
>     ,("perl command","/usr/bin/perl")
>     ,("target os","OSDarwin")
>     ,("target arch","ArchX86_64")
>     ,("target word size","8")
>     ,("target has GNU nonexec stack","False")
>     ,("target has .ident directive","True")
>     ,("target has subsections via symbols","True")
>     ,("Unregisterised","NO")
>     ,("LLVM llc command","llc")
>     ,("LLVM opt command","opt")
>     ,("Project version","7.8.3")
>     ,("Booter version","7.6.3")
>     ,("Stage","2")
>     ,("Build platform","x86_64-apple-darwin")
>     ,("Host platform","x86_64-apple-darwin")
>     ,("Target platform","x86_64-apple-darwin")
>     ,("Have interpreter","YES")
>     ,("Object splitting supported","YES")
>     ,("Have native code generator","YES")
>     ,("Support SMP","YES")
>     ,("Tables next to code","YES")
>     ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
>    thr_debug_dyn l_dyn thr_l_dyn")
>     ,("Support dynamic-too","YES")
>     ,("Support parallel --make","YES")
>     ,("Dynamic by default","NO")
>     ,("GHC Dynamic","YES")
>     ,("Leading underscore","YES")
>     ,("Debug on","False")
>
>     ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3")
>     ,("Global Package
>    DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d")
>     ]
>    - Not sure I found the correct instructions for building from source,
>    I used the following:
>       -
>
>       $ autoreconf
>       $ ./configure
>       $ make
>       $ make install
>
>
>
>
> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>> We are pleased to announce the first release candidate for GHC 7.10.1:
>>
>>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
>>
>> This includes the source tarball and bindists for 64bit/32bit Linux
>> and Windows. Binary builds for other platforms will be available
>> shortly. (CentOS 6.5 binaries are not available at this time like they
>> were for 7.8.x). These binaries and tarballs have an accompanying
>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>
>> We plan to make the 7.10.1 release sometime in February of 2015. We
>> expect another RC to occur during January of 2015.
>>
>> Please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150102/e96ac88f/attachment.html>

From ezyang at mit.edu  Sun Jan  4 07:54:58 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 03 Jan 2015 23:54:58 -0800
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <CAOrUaLaDkih2Cdwm861rPf32TTwkxyGDAu=G0ONpjFnehkvM3Q@mail.gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
 <20141022105441.GA14512@machine>
 <CAOrUaLa5L0-LK-5S=m7Owt5PjrERmVVkNN8o+_UWiR=RGc8iKg@mail.gmail.com>
 <87a94n808i.fsf@gmail.com>
 <CAOrUaLaL00xpJWJnT-_+fTt475rKcO4xrkRLOtg_EDh9RySdHA@mail.gmail.com>
 <1414533995-sup-9843@sabre>
 <CAOrUaLaDkih2Cdwm861rPf32TTwkxyGDAu=G0ONpjFnehkvM3Q@mail.gmail.com>
Message-ID: <1420357849-sup-8899@sabre>

Hey guys,

I have a local branch of ghc-7.8 which can be compiled by 7.10.
The most annoying patch that needed to be backported was AMP
adjustment changes.  I also messed up some stuff involving LANGUAGE
pragmas which I am going to go back and clean up.

    https://github.com/ezyang/ghc/tree/ghc-7.8

There are also some changes to hoopl, transformers and hpc (mostly
because their bootstrap libraries.)

Unfortunately I can't easily Phab these changes.  Any suggestions
for how to coordinate landing these changes?

Edward

Excerpts from Yitzchak Gale's message of 2014-12-28 13:38:47 -0500:
> Resurrecting this thread:
> 
> My impression was that Edward's suggestion was a simple and
> obvious solution to the problem of previous GHC versions quickly
> becoming orphaned and unbuildable. But Austin thought that this
> thread was stuck.
> 
> Would Edward's suggestion be difficult to implement for any
> reason? Specifically, right now would be the time to do it, and
> it would mean:
> 
> 1. Create a 7.8.5 branch.
> 2. Tweak the stage 1 Haskell sources to build with 7.10 and tag
> 3. Create only a source tarball and upload it to the download
> site
> 
> Thanks,
> Yitz
> 
> On Wed, Oct 29, 2014 at 12:10 AM, Edward Z. Yang wrote:
> > Excerpts from Yitzchak Gale's message of 2014-10-28 13:58:08 -0700:
> >> How about this: Currently, every GHC source distribution
> >> requires no later than its own version of GHC for bootstrapping.
> >> Going backwards, that chops up the sequence of GHC versions
> >> into tiny incompatible pieces - there is no way to start with a
> >> working GHC and work backwards to an older version by compiling
> >> successively older GHC sources.
> >>
> >> If instead each GHC could be compiled using at least one
> >> subsequent version, the chain would not be broken. I.e.,
> >> always provide a compatibility flag or some other reasonably
> >> simple mechanism that would enable the current GHC to
> >> compile the source code of at least the last previous released
> >> version.
> >
> > Here is an alternate proposal: when we make a new major version release,
> > we should also make a minor version release of the previous series, which
> > is prepped so that it can compile from the new major version.  If it
> > is the case that one version of the compiler can compile any other
> > version in the same series, this would be sufficient to go backwards.
> >
> > Concretely, the action plan is very simple too: take 7.6 and apply as
> > many patches as is necessary to make it compile from 7.8, and cut
> > a release with those patches.
> >
> > Edward

From ezyang at mit.edu  Sun Jan  4 17:31:34 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sun, 04 Jan 2015 09:31:34 -0800
Subject: GHC 7.4.2 on Ubuntu Trusty
In-Reply-To: <87iognrm4b.fsf@gmail.com>
References: <CAOrUaLYD0VWa=v5xNcSQWYC6Ru6paY77jLRPzzUEuwzVQe1WzQ@mail.gmail.com>
 <20141022105441.GA14512@machine>
 <CAOrUaLa5L0-LK-5S=m7Owt5PjrERmVVkNN8o+_UWiR=RGc8iKg@mail.gmail.com>
 <87a94n808i.fsf@gmail.com>
 <CAOrUaLaL00xpJWJnT-_+fTt475rKcO4xrkRLOtg_EDh9RySdHA@mail.gmail.com>
 <1414533995-sup-9843@sabre>
 <CAOrUaLaDkih2Cdwm861rPf32TTwkxyGDAu=G0ONpjFnehkvM3Q@mail.gmail.com>
 <1420357849-sup-8899@sabre> <87iognrm4b.fsf@gmail.com>
Message-ID: <1420392485-sup-5443@sabre>

For transformers, I needed:

diff --git a/Control/Monad/Trans/Error.hs b/Control/Monad/Trans/Error.hs
index 0158a8a..0dea478 100644
--- a/Control/Monad/Trans/Error.hs
+++ b/Control/Monad/Trans/Error.hs
@@ -57,6 +57,10 @@ instance MonadPlus IO where
     mzero       = ioError (userError "mzero")
     m `mplus` n = m `catchIOError` \_ -> n
 
+instance Alternative IO where
+    empty = mzero
+    (<|>) = mplus
+
 #if !(MIN_VERSION_base(4,4,0))
 -- exported by System.IO.Error from base-4.4
 catchIOError :: IO a -> (IOError -> IO a) -> IO a

For hpc, I needed:

     Build-Depends:
-        base       >= 4.4.1 && < 4.8,
+        base       >= 4.4.1 && < 4.9,
         containers >= 0.4.1 && < 0.6,
         directory  >= 1.1   && < 1.3,
-        time       >= 1.2   && < 1.5
+        time       >= 1.2   && < 1.6

For hoopl, I needed:

-  Build-Depends:     base >= 4.3 && < 4.8
+  Build-Depends:     base >= 4.3 && < 4.9

For the latter two, I think this should be a perfectly acceptable
point release.  For transformers, we could also just ifdef the
Alternative into the GHC sources.

Edward

Excerpts from Herbert Valerio Riedel's message of 2015-01-04 00:22:28 -0800:
> Hello Edward,
> 
> On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote:
> 
> [...]
> 
> > There are also some changes to hoopl, transformers and hpc (mostly
> > because their bootstrap libraries.)
> 
> ...what kind of changes specifically? 
> 
> Once thing that needs to be considered is that we'd require to upstream
> changes to transformers (it's not under GHC HQ's direct control) for a
> transformers point(?) release ... and we'd need that as we can't release
> any source-tarball that contains libraries (which get installed into the
> pkg-db) that don't match their upstream version on Hackage.
> 
> Cheers,
>   hvr

From adam at well-typed.com  Mon Jan  5 16:44:31 2015
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 05 Jan 2015 16:44:31 +0000
Subject: What to do when garbage collector is slow?
In-Reply-To: <CACZfFFkm5KDVQvN0K_c+uST6jHBxCVDrat2Pgb-V=gmKwJeTuQ@mail.gmail.com>
References: <CACZfFFkm5KDVQvN0K_c+uST6jHBxCVDrat2Pgb-V=gmKwJeTuQ@mail.gmail.com>
Message-ID: <54AABF6F.7060206@well-typed.com>

Hi David,

On 23/12/14 10:59, David Spies wrote:
> I have a program that, to all appearances, is behaving properly.  It
> uses very little memory to run, it has the profile I would expect
> looking at +RTS -hc.  I have no reason to believe there is a memory leak
> (in the sense that it's not lazily holding on to things it no longer
> needs or strictly generating things it doesn't need yet).  But it's
> slow, and according to -sstderr, most of the time is spent
> garbage-collecting.
> 
> Why is the garbage-collector consuming so much running time? How can I
> deal with it?

It's entirely possible that your program is allocating a lot of data
that quickly becomes garbage, even if it is not holding on to it for too
long (i.e. leaking memory). Remember that the heap profile shows only
data that is being retained, so there might be unnecessary allocation
even if the heap profile looks sensible. You can use a time and
allocation profile (-p) to find out what is doing most of the allocation.

A quick glance at the profile suggests that funArray and mapWithIdx,
both of which construct lists and then immediately turn them into
arrays, are the likely culprits. Perhaps you can avoid constructing the
intermediate lists?

Hope this helps,

Adam


> The program is a solution to this problem:
> https://open.kattis.com/problems/tourist
> 
> The input data can be found here:
> http://heim.ifi.uio.no/~db/nm-i-programmering/nm2004/testdata/h.in


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From voldermort at hotmail.com  Tue Jan  6 13:39:17 2015
From: voldermort at hotmail.com (harry)
Date: Tue, 6 Jan 2015 06:39:17 -0700 (MST)
Subject: install-strip
Message-ID: <1420551557815-5763372.post@n5.nabble.com>

Trying to build 7.8.4 from the source distribution (linux).

make install-strip should work as per trac #1851, and the target does indeed
appear in distrib/Makefile. However, the build uses the top-level Makefile,
which doesn't, leading to

# make install-strip
===--- building phase 0
make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds
make[1]: Nothing to be done for `phase_0_builds'.
===--- building phase 1
make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds
make[1]: Nothing to be done for `phase_1_builds'.
===--- building final phase
make -r --no-print-directory -f ghc.mk phase=final install-strip
make[1]: *** No rule to make target `install-strip'.  Stop.
make: *** [install-strip] Error 2

Am I doing something wrong?



--
View this message in context: http://haskell.1045720.n5.nabble.com/install-strip-tp5763372.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From hesselink at gmail.com  Tue Jan  6 14:56:46 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Tue, 6 Jan 2015 15:56:46 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1
In-Reply-To: <CAEs96n1ciXiuuXkaH=zOx9PnhkqTou+eJ=URkDYbWwKXkbhN2w@mail.gmail.com>
References: <CAEs96n1ciXiuuXkaH=zOx9PnhkqTou+eJ=URkDYbWwKXkbhN2w@mail.gmail.com>
Message-ID: <CAPeieQEVGcemVh_T=pFCWhif-oowwqWm7D0y7MOvBZ6nb_nnEQ@mail.gmail.com>

I made a Mac OS X build. If people want to try it out, you can
download it from [0]. Let me know if you run into any issues.

Regards,

Erik

[0] https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nNFR4WUVNZzRtbGs&export=download

On Tue, Dec 23, 2014 at 3:36 PM, Austin Seipp <austin at well-typed.com> wrote:
> We are pleased to announce the first release candidate for GHC 7.10.1:
>
>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
>
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>
> We plan to make the 7.10.1 release sometime in February of 2015. We
> expect another RC to occur during January of 2015.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From maoe at foldr.in  Tue Jan  6 23:31:38 2015
From: maoe at foldr.in (Mitsutoshi Aoe)
Date: Wed, 7 Jan 2015 08:31:38 +0900
Subject: Changes to the type checker with respect to UndecidableInstances
In-Reply-To: <618BE556AADD624C9C918AA5D5911BEF5628EDF8@DB3PRD3001MB020.064d.mgd.msft.net>
References: <68089B9E-CEBD-4555-A178-99E858231606@foldr.in>
 <618BE556AADD624C9C918AA5D5911BEF5628EDF8@DB3PRD3001MB020.064d.mgd.msft.net>
Message-ID: <CAMLnt0OAX-8_ZGZED3XEbWG6deya2hGHGeO0t=z5YC7A42AtQg@mail.gmail.com>

Hi Simon,

Thanks. So there was a bug in the type checker. Do you have a link to
the ticket or commits which fixed the issue?

Mitsutoshi

2014-12-30 19:56 GMT+09:00 Simon Peyton Jones <simonpj at microsoft.com>:
> UndecidableInstances is supposed to be needed if GHC can?t prove that the
> instance declarations terminate.  But here it can be sure they terminate.
> GHC 7.6.3 didn?t realise this.
>
>
>
> I?ll modify the user manual to be clearer on this point.
>
>
>
> Simon
>
>
>
> From: Glasgow-haskell-users
> [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Mitsutoshi
> Aoe
> Sent: 28 December 2014 10:47
> To: glasgow-haskell-users at haskell.org
> Subject: Changes to the type checker with respect to UndecidableInstances
>
>
>
> Hi,
>
>
>
> I found a difference between GHC 7.6.3 and 7.8.3 with respect to
> UndecidableInstances.
>
>
>
> https://gist.github.com/maoe/57a4346eb36aee159916
>
>
>
> 7.6.3 requires UndecidableInstances to compile this snippet whereas 7.8.3
> doesn't. What has changed in the type checker?
>
>
>
> Mitsutoshi
>
>

From brandon.m.simmons at gmail.com  Wed Jan  7 20:21:48 2015
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Wed, 7 Jan 2015 15:21:48 -0500
Subject: Compiling a cabal project with LLVM on GHC 7.10 RC1
Message-ID: <CAAyGGynh70pc++qycn+A9PzZGDAYcwx2L4WPyAzkpD=0hojBKw@mail.gmail.com>

I've tried:

  $ cabal install --only-dependencies -w
/usr/local/bin/ghc-7.10.0.20141222  --enable-tests --enable-benchmarks
--ghc-option=-fllvm --ghc-option=-static
  $ cabal configure -w /usr/local/bin/ghc-7.10.0.20141222
--enable-tests --enable-benchmarks --ghc-option=-fllvm
--ghc-option=-static
  $ cabal build
  Building foo-0.3.0.0...
  Preprocessing library foo-0.3.0.0...

  when making flags consistent: Warning:
      Using native code generator rather than LLVM, as LLVM is
incompatible with -fPIC and -dynamic   on this platform

I don't see anything referencing "PIC" in the output of cabal build
-v. I can build a hello world program, just fine with `ghc --make`:

  $ /usr/local/bin/ghc-7.10.0.20141222 --make -O2 -fllvm   Main.hs
  [1 of 1] Compiling Main             ( Main.hs, Main.o )
  Linking Main ...

Thanks,
Brandon

From ezyang at mit.edu  Wed Jan  7 20:30:06 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Wed, 07 Jan 2015 12:30:06 -0800
Subject: Compiling a cabal project with LLVM on GHC 7.10 RC1
In-Reply-To: <CAAyGGynh70pc++qycn+A9PzZGDAYcwx2L4WPyAzkpD=0hojBKw@mail.gmail.com>
References: <CAAyGGynh70pc++qycn+A9PzZGDAYcwx2L4WPyAzkpD=0hojBKw@mail.gmail.com>
Message-ID: <1420662555-sup-7486@sabre>

...is there -dynamic in the -v output?  Don't you also want
--disable-shared?

Excerpts from Brandon Simmons's message of 2015-01-07 12:21:48 -0800:
> I've tried:
> 
>   $ cabal install --only-dependencies -w
> /usr/local/bin/ghc-7.10.0.20141222  --enable-tests --enable-benchmarks
> --ghc-option=-fllvm --ghc-option=-static
>   $ cabal configure -w /usr/local/bin/ghc-7.10.0.20141222
> --enable-tests --enable-benchmarks --ghc-option=-fllvm
> --ghc-option=-static
>   $ cabal build
>   Building foo-0.3.0.0...
>   Preprocessing library foo-0.3.0.0...
> 
>   when making flags consistent: Warning:
>       Using native code generator rather than LLVM, as LLVM is
> incompatible with -fPIC and -dynamic   on this platform
> 
> I don't see anything referencing "PIC" in the output of cabal build
> -v. I can build a hello world program, just fine with `ghc --make`:
> 
>   $ /usr/local/bin/ghc-7.10.0.20141222 --make -O2 -fllvm   Main.hs
>   [1 of 1] Compiling Main             ( Main.hs, Main.o )
>   Linking Main ...
> 
> Thanks,
> Brandon

From brandon.m.simmons at gmail.com  Wed Jan  7 21:03:05 2015
From: brandon.m.simmons at gmail.com (Brandon Simmons)
Date: Wed, 7 Jan 2015 16:03:05 -0500
Subject: Compiling a cabal project with LLVM on GHC 7.10 RC1
In-Reply-To: <1420662555-sup-7486@sabre>
References: <CAAyGGynh70pc++qycn+A9PzZGDAYcwx2L4WPyAzkpD=0hojBKw@mail.gmail.com>
 <1420662555-sup-7486@sabre>
Message-ID: <CAAyGGymBtnwHpyCX+xYnAWwYTZpWgDNxa1L3_rTEWLm86oyijQ@mail.gmail.com>

On Wed, Jan 7, 2015 at 3:30 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> ...is there -dynamic in the -v output?  Don't you also want
> --disable-shared?

Oh yeah, it looks like I have some invocations like:

    /usr/local/bin/ghc-7.10.0.20141222 -shared -dynamic ... -static ...

--disable-shared seems to be what I needed:

    cabal configure -w /usr/local/bin/ghc-7.10.0.20141222
--enable-tests --enable-benchmarks --ghc-option=-fllvm
--ghc-option=-static --disable-shared

Thanks!

>
> Excerpts from Brandon Simmons's message of 2015-01-07 12:21:48 -0800:
>> I've tried:
>>
>>   $ cabal install --only-dependencies -w
>> /usr/local/bin/ghc-7.10.0.20141222  --enable-tests --enable-benchmarks
>> --ghc-option=-fllvm --ghc-option=-static
>>   $ cabal configure -w /usr/local/bin/ghc-7.10.0.20141222
>> --enable-tests --enable-benchmarks --ghc-option=-fllvm
>> --ghc-option=-static
>>   $ cabal build
>>   Building foo-0.3.0.0...
>>   Preprocessing library foo-0.3.0.0...
>>
>>   when making flags consistent: Warning:
>>       Using native code generator rather than LLVM, as LLVM is
>> incompatible with -fPIC and -dynamic   on this platform
>>
>> I don't see anything referencing "PIC" in the output of cabal build
>> -v. I can build a hello world program, just fine with `ghc --make`:
>>
>>   $ /usr/local/bin/ghc-7.10.0.20141222 --make -O2 -fllvm   Main.hs
>>   [1 of 1] Compiling Main             ( Main.hs, Main.o )
>>   Linking Main ...
>>
>> Thanks,
>> Brandon

From dominic at steinitz.org  Sun Jan 11 23:04:17 2015
From: dominic at steinitz.org (Dominic Steinitz)
Date: Sun, 11 Jan 2015 23:04:17 +0000
Subject: Equality Constraints (a ~ b)
Message-ID: <610ECD79-680B-454B-A715-A0A3C3C2E386@steinitz.org>

Hi,

I am trying to find more background on these. They don?t exist in the Haskell 2010 Language Report, they didn?t exist in ghc 6.8.2 but make an appearance in 7.0.1. The documentation in the manual is rather sparse and doesn?t contain a reference: https://downloads.haskell.org/~ghc/latest/docs/users_guide.pdf section 7.11. Folk on #ghc referred me to http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/. I can find papers that refer to ~ in F_C (aka FC?) but as far as I can tell not in the Haskell language itself.

Many thanks

Dominic Steinitz
dominic at steinitz.org
http://idontgetoutmuch.wordpress.com


From ekmett at gmail.com  Mon Jan 12 00:16:32 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Sun, 11 Jan 2015 19:16:32 -0500
Subject: Equality Constraints (a ~ b)
In-Reply-To: <610ECD79-680B-454B-A715-A0A3C3C2E386@steinitz.org>
References: <610ECD79-680B-454B-A715-A0A3C3C2E386@steinitz.org>
Message-ID: <CAJumaK8PyCMW3Ngu7F3BzSewvkqmt2WyqC-nHANu8WzCqLfsUg@mail.gmail.com>

They were introduced as part of the System Fc rewrite.

The Fc approach has the benefit of unifying a lot of the work on GADTs,
functional dependencies, type and data families, etc. all behind the scenes.

Every once in a while, (~) constraints can leak into the surface language
and it can be useful to be able to talk about them in the surface language
of Haskell, because otherwise it isn't clear how to talk about F a ~ G b
style constraints, which arise in practice when you work with type families.

-Edward


On Sun, Jan 11, 2015 at 6:04 PM, Dominic Steinitz <dominic at steinitz.org>
wrote:

> Hi,
>
> I am trying to find more background on these. They don?t exist in the
> Haskell 2010 Language Report, they didn?t exist in ghc 6.8.2 but make an
> appearance in 7.0.1. The documentation in the manual is rather sparse and
> doesn?t contain a reference:
> https://downloads.haskell.org/~ghc/latest/docs/users_guide.pdf section
> 7.11. Folk on #ghc referred me to
> http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/. I
> can find papers that refer to ~ in F_C (aka FC?) but as far as I can tell
> not in the Haskell language itself.
>
> Many thanks
>
> Dominic Steinitz
> dominic at steinitz.org
> http://idontgetoutmuch.wordpress.com
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150111/d8fb9073/attachment.html>

From petersen at fedoraproject.org  Tue Jan 13 01:26:08 2015
From: petersen at fedoraproject.org (Jens Petersen)
Date: Tue, 13 Jan 2015 10:26:08 +0900
Subject: ANNOUNCE: GHC version 7.8.4
In-Reply-To: <CAEs96n1hf0b1FHdPSKWsOCQu4kzsQBObOfqvwhrX0r-=hanPRQ@mail.gmail.com>
References: <CAEs96n1hf0b1FHdPSKWsOCQu4kzsQBObOfqvwhrX0r-=hanPRQ@mail.gmail.com>
Message-ID: <CAEDGBqKe45OgsgJ-D5G08=ntJa_gdPr7qSjgi+4FRHiUCwFWsw@mail.gmail.com>

>
> The GHC Team is pleased to announce a new patchlevel release of GHC, 7.8.4.
>

Thanks, I created a Fedora Copr repo with 7.8.4:

 http://copr.fedoraproject.org/coprs/petersen/ghc-7.8.4/

it has builds for current Fedora releases and EPEL 7.

Cheers, Jens
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150113/d2321608/attachment.html>

From mike at proclivis.com  Tue Jan 13 06:02:55 2015
From: mike at proclivis.com (Michael Jones)
Date: Mon, 12 Jan 2015 23:02:55 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
Message-ID: <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>

Sorry I am reviving an old problem, but it has resurfaced, such that one system behaves different than another.

Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax, something bad is going on. In summary, the same code that runs on two machines does not run on a third machine. So this indicates I have not made any breaking changes to the code or cabal files. Compiling with GHC 7.8.3.

This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1 kernel. It is a dual core 64 bit I86 Atom processor. The application hangs at startup. If I remove the -C0.00N option and instead use -V0, the application runs. It has bad timing properties, but it does at least run. Note that a hang hangs an IO thread talking USB, and the GUI thread.

When testing with the -C0.00N option, it did run 2 times out of 20 tries, so fail means fail most but not all of the time. When it did run, it continued to run properly. This perhaps indicates some kind of internal race condition.

In the fail to run case, it does some printing up to the point where it tries to create a wxHaskell frame. In another non-UI version of the program it also fails to run. Logging to a file gives a similar indication. It is clear that the program starts up, then fails during the run in some form of lockup, well after the initial startup code.

If I run with the strace command, it always runs with -C0.00N.

All the above was done with profiling enabled, so I removed that and instead enabled eventlog to look for clues.

In this case it lies between good and bad, in that IO to my USB is working, but the GUI comes up blank and never paints. Running this case without -v0 (event log) the gui partially paints and stops, but USB continues.

Questions:

1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of scheduling/thread problems?
2) Is there anything about the nature of a thread using USB, I2C, or wxHaskell IO that leads to problems that a pure calculation app would not have?
3) Any ideas how to track down the problem when changing conditions (compiler or runtime options) affects behavior?
4) Are there other options besides -V and -C for the runtime that might apply?
5) What does -V0 do that makes a problem program run?

Mike




On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com> wrote:

> John,
> 
> Adding -C0.005 makes it much better. Using -C0.001 makes it behave more like -N4.
> 
> Thanks. This saves my project, as I need to deploy on a single core Atom and was stuck.
> 
> Mike
> 
> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
> 
>> By any chance do the delays get shorter if you run your program with `+RTS -C0.005` ?  If so, I suspect you're having a problem very similar to one that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some reason), involving possible misbehavior of the thread scheduler.
>> 
>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:
>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>> 
>> I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination.
>> 
>> When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so.
>> 
>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4.
>> 
>> The program is compiled -O2 with profiling. The -N2/4 version uses more memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
>> 
>> I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running.
>> 
>> One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler.
>> 
>> What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help?
>> 
>> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get.
>> 
>> Any hints appreciated.
>> 
>> Mike
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150112/bd537708/attachment.html>

From sidhu1f at gmail.com  Tue Jan 13 10:28:02 2015
From: sidhu1f at gmail.com (R Sidhu)
Date: Tue, 13 Jan 2015 15:58:02 +0530
Subject: Avoid blank line separating code and comments in Bird style?
Message-ID: <CADhE+R9JV_awSrqCGnjUp1YkhdGQXnOxDCL6M+Rth6aiSyGEhQ@mail.gmail.com>

Hi

This regarding GHC behaviour for literate Haskell programs in Bird
style. GHC expects a blank line between comment[1] and code.
Otherwise, during the literate pre-processor stage, the error
'unlit: Program line next to comment' is reported.

While above behaviour makes sense in general, there are situations
where one would like to place comments adjacent to code with no
intervening blank line. For example, in documenting a declaration
using Haddock (in standard, non-literate Haskell), as shown in
sections 3.1
<https://www.haskell.org/haddock/doc/html/markup.html#idm140354810917952>
and 3.2 <http://www.haskell.org/haddock/doc/html/ch03s02.html> of the
Haddock User Guide, no blank line
separates comment and code.

Any way to enable GHC to accept Bird style literate programs with
no blank lines separating comment and code?

[1] 'Comment' (in context of Bird style) refers to text on lines not
beginning with '>'.

Regards
Sidhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150113/fb811083/attachment.html>

From m.konecny at aston.ac.uk  Tue Jan 13 12:08:02 2015
From: m.konecny at aston.ac.uk (Michal =?utf-8?B?S29uZcSNbsO9?=)
Date: Tue, 13 Jan 2015 12:08:02 +0000
Subject: conflicting multi-parameter family instance declarations
Message-ID: <1832368.1lnfQvkoMq@eascs10819dl>

Dear all,

The following compiles with ghc 7.6 but fails with ghc 7.8:

-----
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
module Test where

class M t s where
    type T t s
    
data I t = I t

instance M t t where
    type (T t t) = ()
    
instance M t (I t) where
    type (T t (I t)) = ()
-----

The error I get with ghc 7.8.3 and 7.8.4 is:

Test.hs:12:10:
    Conflicting family instance declarations:
      T t t -- Defined at Test.hs:12:10
      T t (I t) -- Defined at Test.hs:15:10


I am curious if this change is an improvement or a bug.  I would be grateful for help as this issue affects a fairly large library I develop.

Best regards,
Michal
-- 
|-| Dr. Michal Konecny, Computer Science, Aston University 
|-| Room MB212D | Tel +44 121 204 3462 | Fax +44 121 204 3681
|-| http://duck.aston.ac.uk/konecnym
|-| OpenPGP key http://duck.aston.ac.uk/konecnym/ki.aston


From simonpj at microsoft.com  Tue Jan 13 12:21:43 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 13 Jan 2015 12:21:43 +0000
Subject: conflicting multi-parameter family instance declarations
In-Reply-To: <1832368.1lnfQvkoMq@eascs10819dl>
References: <1832368.1lnfQvkoMq@eascs10819dl>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF562A294F@DB3PRD3001MB020.064d.mgd.msft.net>

Alas it's deliberate.  See Section 6 of "Closed type families" http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/, and the recent thread on https://ghc.haskell.org/trac/ghc/ticket/9918

Maybe you can add your example to that ticket, with some indication of why it's important to you.

The difficulty is that lifting this restriction actually makes the type system unsound.

Simon

|  -----Original Message-----
|  From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
|  bounces at haskell.org] On Behalf Of Michal Konecn?
|  Sent: 13 January 2015 12:08
|  To: glasgow-haskell-users at haskell.org
|  Subject: conflicting multi-parameter family instance declarations
|  
|  Dear all,
|  
|  The following compiles with ghc 7.6 but fails with ghc 7.8:
|  
|  -----
|  {-# LANGUAGE TypeFamilies #-}
|  {-# LANGUAGE FlexibleInstances #-}
|  {-# LANGUAGE MultiParamTypeClasses #-}
|  module Test where
|  
|  class M t s where
|      type T t s
|  
|  data I t = I t
|  
|  instance M t t where
|      type (T t t) = ()
|  
|  instance M t (I t) where
|      type (T t (I t)) = ()
|  -----
|  
|  The error I get with ghc 7.8.3 and 7.8.4 is:
|  
|  Test.hs:12:10:
|      Conflicting family instance declarations:
|        T t t -- Defined at Test.hs:12:10
|        T t (I t) -- Defined at Test.hs:15:10
|  
|  
|  I am curious if this change is an improvement or a bug.  I would be
|  grateful for help as this issue affects a fairly large library I
|  develop.
|  
|  Best regards,
|  Michal
|  --
|  |-| Dr. Michal Konecny, Computer Science, Aston University Room MB212D
|  |
|  |-| Tel +44 121 204 3462 | Fax +44 121 204 3681
|  |-| http://duck.aston.ac.uk/konecnym OpenPGP key
|  |-| http://duck.aston.ac.uk/konecnym/ki.aston
|  
|  _______________________________________________
|  Glasgow-haskell-users mailing list
|  Glasgow-haskell-users at haskell.org
|  http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From fuuzetsu at fuuzetsu.co.uk  Tue Jan 13 13:46:13 2015
From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk)
Date: Tue, 13 Jan 2015 13:46:13 +0000
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <CADhE+R9JV_awSrqCGnjUp1YkhdGQXnOxDCL6M+Rth6aiSyGEhQ@mail.gmail.com>
References: <CADhE+R9JV_awSrqCGnjUp1YkhdGQXnOxDCL6M+Rth6aiSyGEhQ@mail.gmail.com>
Message-ID: <54B521A5.7020905@fuuzetsu.co.uk>

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

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

> -- | Foo
> someCode = undefined

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

-- | Foo, no blank line
someCode = undefined


or


-- | Foo, blank line

someCode = undefined


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

I imagine you're suggesting that something like


Literate comment
> someCode = undefined


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

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

-- 
Mateusz K.

From bgamari.foss at gmail.com  Tue Jan 13 20:02:54 2015
From: bgamari.foss at gmail.com (Ben Gamari)
Date: Tue, 13 Jan 2015 15:02:54 -0500
Subject: Thread behavior in 7.8.3
In-Reply-To: <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
Message-ID: <87oaq2wis1.fsf@gmail.com>

Michael Jones <mike at proclivis.com> writes:

> Sorry I am reviving an old problem, but it has resurfaced, such that
> one system behaves different than another.
>
[snip]

> 1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of scheduling/thread problems?
> 2) Is there anything about the nature of a thread using USB, I2C, or wxHaskell IO that leads to problems that a pure calculation app would not have?

Do you know about [1]? This is a regression due to an interface change
that arose from the new event manager. `usb` 1.3.0.0` has a workaround,
GHC 7.10 will have a fixed event manager [2].

Given that it sounds like your program works some of the time this may
not be relevant but I thought it would be negligent not to mention it.

Cheers,

- Ben


[1] https://github.com/basvandijk/usb/issues/7
[2] https://phabricator.haskell.org/D347
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150113/95f6a295/attachment.sig>

From david.feuer at gmail.com  Tue Jan 13 23:02:13 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 13 Jan 2015 18:02:13 -0500
Subject: Future of the boxes package--call for ideas
Message-ID: <CAMgWh9t0jsnxSTTu9JS--sV2r3K1uLPnYJaQAsEC5K7far9=eg@mail.gmail.com>

I've just taken over maintainership of the boxes package, and will be
making a maintenance release shortly (as soon as I figure out how and get
added to the maintainers group). The package, however, currently suffers
from a paucity of bug reports (no problem) and feature requests (not so
great).

To keep things lively, I need a bit of help from two groups of people. If
you use the package but wish it could do something more for you, I want to
know about it. If you considered using the package but rejected it because
it couldn't quite handle your job, I want to know about that too. I'd
prefer if people would open issues and pull requests at
https://github.com/treeowl/boxes/issues but I will also accept requests by
email.

Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150113/be2160bc/attachment.html>

From mike at proclivis.com  Tue Jan 13 23:09:29 2015
From: mike at proclivis.com (Michael Jones)
Date: Tue, 13 Jan 2015 16:09:29 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <87oaq2wis1.fsf@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <87oaq2wis1.fsf@gmail.com>
Message-ID: <3AB08D9F-222A-4CE8-B794-7C515ACA800A@proclivis.com>

Ben,

Interesting.

In this case, I can duplicate the problem when not using USB (USB to i2c dongle) by using /dev/i2c_n, and when I do use USB, in some cases the USB is working (can see i2c on scope), but the GUI is hung. So I believe this is not causing the problem.

Thanks,

Mike

On Jan 13, 2015, at 1:02 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:

> Michael Jones <mike at proclivis.com> writes:
> 
>> Sorry I am reviving an old problem, but it has resurfaced, such that
>> one system behaves different than another.
>> 
> [snip]
> 
>> 1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of scheduling/thread problems?
>> 2) Is there anything about the nature of a thread using USB, I2C, or wxHaskell IO that leads to problems that a pure calculation app would not have?
> 
> Do you know about [1]? This is a regression due to an interface change
> that arose from the new event manager. `usb` 1.3.0.0` has a workaround,
> GHC 7.10 will have a fixed event manager [2].
> 
> Given that it sounds like your program works some of the time this may
> not be relevant but I thought it would be negligent not to mention it.
> 
> Cheers,
> 
> - Ben
> 
> 
> [1] https://github.com/basvandijk/usb/issues/7
> [2] https://phabricator.haskell.org/D347



From sidhu1f at gmail.com  Wed Jan 14 07:42:49 2015
From: sidhu1f at gmail.com (sidhu1f)
Date: Wed, 14 Jan 2015 13:12:49 +0530
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <54B521A5.7020905@fuuzetsu.co.uk>
References: <54B521A5.7020905@fuuzetsu.co.uk>
Message-ID: <54b61e12.e25f460a.54e6.3ba7@mx.google.com>

At Wed, 14 Jan 2015 12:31:54 +0530,
Mateusz Kowalczyk wrote:

> I imagine you're suggesting that something like

> Literate comment
> > someCode = undefined

This (literate comment followed by code with no intervening blank
line) is exactly what I want (regret my explanation was unclear). But
when I try it, GHC reports the error 'unlit: Program line next to
comment'.

> is allowed ...

As you mention above behaviour is allowed, could you let me know how
to enable it?

Regards
Sidhu

From eir at cis.upenn.edu  Wed Jan 14 15:55:41 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Wed, 14 Jan 2015 10:55:41 -0500
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <54b61e12.e25f460a.54e6.3ba7@mx.google.com>
References: <54B521A5.7020905@fuuzetsu.co.uk>
 <54b61e12.e25f460a.54e6.3ba7@mx.google.com>
Message-ID: <5FDCE389-6B8C-49E0-A343-FCB9CFD7B6A8@cis.upenn.edu>

I think the underlying problem here is that there is a difference between "literate" comments and "normal" comments.

In a bird-style literate Haskell file, this is what I'll call a literate comment:

~~~
A line with no marker at the beginning
~~~

A normal comment is in a line of Haskell code, put with a comment indicator:

~~~
> -- This is a "normal" comment
~~~

When GHC sees a bird-style literate Haskell file, it first strips out all lines that don't begin with >. Then, it starts doing its real work, including parsing Haddock comments. So, to use a Haddock comment in a literate Haskell file, you'd need to use the "normal" comment style:

~~~
> -- | Make a numbered widget
> mkWidget :: Int -> Widget
~~~

There is no way to use Haddock markup in a "literate" comment.

But, as Mateusz points out, there may be blank lines between the Haddock comment and the thing being described:

~~~
> -- | Get the number of a widget
>
> widgetNum :: Widget -> Int
~~~

I hope this clarifies things!
Richard


On Jan 14, 2015, at 2:42 AM, sidhu1f <sidhu1f at gmail.com> wrote:

> At Wed, 14 Jan 2015 12:31:54 +0530,
> Mateusz Kowalczyk wrote:
> 
>> I imagine you're suggesting that something like
> 
>> Literate comment
>>> someCode = undefined
> 
> This (literate comment followed by code with no intervening blank
> line) is exactly what I want (regret my explanation was unclear). But
> when I try it, GHC reports the error 'unlit: Program line next to
> comment'.
> 
>> is allowed ...
> 
> As you mention above behaviour is allowed, could you let me know how
> to enable it?
> 
> Regards
> Sidhu
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


From sidhu1f at gmail.com  Wed Jan 14 16:54:35 2015
From: sidhu1f at gmail.com (sidhu1f)
Date: Wed, 14 Jan 2015 22:24:35 +0530
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <5FDCE389-6B8C-49E0-A343-FCB9CFD7B6A8@cis.upenn.edu>
References: <54B521A5.7020905@fuuzetsu.co.uk>
 <54b61e12.e25f460a.54e6.3ba7@mx.google.com>
 <5FDCE389-6B8C-49E0-A343-FCB9CFD7B6A8@cis.upenn.edu>
Message-ID: <54b69f65.a181460a.6363.65fe@mx.google.com>

At Wed, 14 Jan 2015 10:55:41 -0500,
Richard Eisenberg wrote:
> 
> I think the underlying problem here is that there is a difference between "literate" comments and "normal" comments.
> 
> In a bird-style literate Haskell file, this is what I'll call a literate comment:
> 
> ~~~
> A line with no marker at the beginning
> ~~~
> 
> A normal comment is in a line of Haskell code, put with a comment indicator:
> 
> ~~~
> > -- This is a "normal" comment
> ~~~
> 
> When GHC sees a bird-style literate Haskell file, it first strips out all lines that don't begin with >. Then, it starts doing its real work, including parsing Haddock comments. So, to use a Haddock comment in a literate Haskell file, you'd need to use the "normal" comment style:
> 
> ~~~
> > -- | Make a numbered widget
> > mkWidget :: Int -> Widget
> ~~~
> 
> There is no way to use Haddock markup in a "literate" comment.
> 
> But, as Mateusz points out, there may be blank lines between the Haddock comment and the thing being described:
> 
> ~~~
> > -- | Get the number of a widget
> >
> > widgetNum :: Widget -> Int
> ~~~

I understand and agree with all you say above...
 
> I hope this clarifies things!

...but unfortunately it doesn't solve my problem. I guess my attempt
to motivate with the Haddock use case confused things.

What I want to do has nothing to do with Haddock. All I would like is,
very simply (in Bird style) literate comment and code next to each
other with No Intervening Blank Lines separating them. But GHC doesn't
accept this and GHC reports the error 'unlit: Program line next to
comment'. If I add a blank line between the literate comment and code,
GHC accepts it.

Summarizing, following is accepted by GHC without error (notice blank
line separating literate comment and code):

   literate comment
   
   > haskell code

For following GHC reports error, but it is what I require:

   literate comment
   > code

So. Is there any way GHC can be coaxed to accept a Bird style literal
Haskell file with no blank line separating code and literal comment?

> Richard
> 

Sidhu


> 
> On Jan 14, 2015, at 2:42 AM, sidhu1f <sidhu1f at gmail.com> wrote:
> 
> > At Wed, 14 Jan 2015 12:31:54 +0530,
> > Mateusz Kowalczyk wrote:
> > 
> >> I imagine you're suggesting that something like
> > 
> >> Literate comment
> >>> someCode = undefined
> > 
> > This (literate comment followed by code with no intervening blank
> > line) is exactly what I want (regret my explanation was unclear). But
> > when I try it, GHC reports the error 'unlit: Program line next to
> > comment'.
> > 
> >> is allowed ...
> > 
> > As you mention above behaviour is allowed, could you let me know how
> > to enable it?
> > 
> > Regards
> > Sidhu
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 



From andres at well-typed.com  Wed Jan 14 17:12:31 2015
From: andres at well-typed.com (=?UTF-8?Q?Andres_L=C3=B6h?=)
Date: Wed, 14 Jan 2015 18:12:31 +0100
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <54b69f65.a181460a.6363.65fe@mx.google.com>
References: <54B521A5.7020905@fuuzetsu.co.uk>
 <54b61e12.e25f460a.54e6.3ba7@mx.google.com>
 <5FDCE389-6B8C-49E0-A343-FCB9CFD7B6A8@cis.upenn.edu>
 <54b69f65.a181460a.6363.65fe@mx.google.com>
Message-ID: <CALjd_v60R1PP+xSkoD3L0RULt4fKrZb2yJdexNkBWZRgRGAc1w@mail.gmail.com>

Hi everyone.

I think invoking GHC(i) with -optL-q might work.

Cheers,
  Andres

-- 
Andres L?h, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com

Registered in England & Wales, OC335890
250 Ice Wharf, 17 New Wharf Road, London N1 9RF, England

From sidhu1f at gmail.com  Thu Jan 15 04:49:59 2015
From: sidhu1f at gmail.com (sidhu1f)
Date: Thu, 15 Jan 2015 10:19:59 +0530
Subject: Avoid blank line separating code and comments in Bird style?
In-Reply-To: <CALjd_v60R1PP+xSkoD3L0RULt4fKrZb2yJdexNkBWZRgRGAc1w@mail.gmail.com>
References: <54B521A5.7020905@fuuzetsu.co.uk>
 <54b61e12.e25f460a.54e6.3ba7@mx.google.com>
 <5FDCE389-6B8C-49E0-A343-FCB9CFD7B6A8@cis.upenn.edu>
 <54b69f65.a181460a.6363.65fe@mx.google.com>
 <CALjd_v60R1PP+xSkoD3L0RULt4fKrZb2yJdexNkBWZRgRGAc1w@mail.gmail.com>
Message-ID: <54b74711.5167460a.3b43.1953@mx.google.com>

At Wed, 14 Jan 2015 18:12:31 +0100,
Andres L?h wrote:
> 
> Hi everyone.
> 
> I think invoking GHC(i) with -optL-q might work.

Solved my problem! My thanks to you Andres (and to Mateusz and Richard
also).

> 
> Cheers,
>   Andres
> 

Sidhu

From george.colpitts at gmail.com  Sat Jan 17 12:36:00 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 17 Jan 2015 08:36:00 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS
 platform
Message-ID: <CAB-d4A6p49-+FTb0wSOxiu1zH8EdxdfpG2TuuADiBgEcBZV9cA@mail.gmail.com>

   - Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My
   problem is described below.
   - Which is the recommended gcc to use when building source?
      - GNU gcc  4.9.2
      - Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
   - When using ghci with 7.10.1 RC1 I get the following errors
   intermittently. Is anybody else seeing these?
      - Too late for parseStaticFlags: call it before runGhc or runGhcT
      *** Exception: ExitFailure 1
      - ld: library not found for -l:ghc31505_10.dylib
      collect2: error: ld returned 1 exit status
      phase `Linker' failed (exitcode = 1)

?Thanks?

On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Only problem remaining is compiling with -fllvm and running resulting
> executable
>
> ?.
> ?..?
>
>
>
>    - llvm , compiling with llvm (3.4.2) gives the following warnings:
>       - $ ghc  -fllvm cubeFast.hs
>       [1 of 1] Compiling Main             ( cubeFast.hs, cubeFast.o )
>       clang: warning: argument unused during compilation:
>       '-fno-stack-protector'
>       clang: warning: argument unused during compilation: '-D
>       TABLES_NEXT_TO_CODE'
>       clang: warning: argument unused during compilation: '-I .'
>       clang: warning: argument unused during compilation: '-fno-common'
>       clang: warning: argument unused during compilation: '-U __PIC__'
>       clang: warning: argument unused during compilation: '-D __PIC__'
>       Linking cubeFast ...
>       - running the resulting executable crashes (compiling without
>       -fllvm gives no warnings and executable works properly)
>       -  cat bigCube.txt | ./cubeFast > /dev/null
>       Segmentation fault: 11
>       - Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
>       Exception Codes:       KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460
>
>
>>    - ?...
>>
>> ?Configuration details:
>>
>>
>>    - Mac OS 10.10.1 (Yosemite)
>>    -  uname -a
>>    Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
>>    00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
>>    - llvm info:
>>    -  opt --version
>>    LLVM (http://llvm.org/):
>>      LLVM version 3.4.2
>>      Optimized build with assertions.
>>      Built Oct 31 2014 (23:14:30).
>>      Default target: x86_64-apple-darwin14.0.0
>>      Host CPU: corei7
>>    -  gcc --version
>>    gcc (Homebrew gcc 4.9.1) 4.9.1
>>    Copyright (C) 2014 Free Software Foundation, Inc.
>>    This is free software; see the source for copying conditions.  There
>>    is NO
>>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>    PURPOSE.
>>    - ? /usr/bin/ghc --info
>>     [("Project name","The Glorious Glasgow Haskell Compilation System")
>>     ,("GCC extra via C opts"," -fwrapv")
>>     ,("C compiler command","/usr/bin/gcc")
>>     ,("C compiler flags"," -m64 -fno-stack-protector")
>>     ,("C compiler link flags"," -m64")
>>     ,("Haskell CPP command","/usr/bin/gcc")
>>     ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
>>    -Wno-unicode -Wno-trigraphs")
>>     ,("ld command","/usr/bin/ld")
>>     ,("ld flags"," -arch x86_64")
>>     ,("ld supports compact unwind","YES")
>>     ,("ld supports build-id","NO")
>>     ,("ld supports filelist","YES")
>>     ,("ld is GNU ld","NO")
>>     ,("ar command","/usr/bin/ar")
>>     ,("ar flags","clqs")
>>     ,("ar supports at file","NO")
>>     ,("touch command","touch")
>>     ,("dllwrap command","/bin/false")
>>     ,("windres command","/bin/false")
>>     ,("libtool command","libtool")
>>     ,("perl command","/usr/bin/perl")
>>     ,("target os","OSDarwin")
>>     ,("target arch","ArchX86_64")
>>     ,("target word size","8")
>>     ,("target has GNU nonexec stack","False")
>>     ,("target has .ident directive","True")
>>     ,("target has subsections via symbols","True")
>>     ,("Unregisterised","NO")
>>     ,("LLVM llc command","llc")
>>     ,("LLVM opt command","opt")
>>     ,("Project version","7.8.3")
>>     ,("Booter version","7.6.3")
>>     ,("Stage","2")
>>     ,("Build platform","x86_64-apple-darwin")
>>     ,("Host platform","x86_64-apple-darwin")
>>     ,("Target platform","x86_64-apple-darwin")
>>     ,("Have interpreter","YES")
>>     ,("Object splitting supported","YES")
>>     ,("Have native code generator","YES")
>>     ,("Support SMP","YES")
>>     ,("Tables next to code","YES")
>>     ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn
>>    thr_dyn thr_debug_dyn l_dyn thr_l_dyn")
>>     ,("Support dynamic-too","YES")
>>     ,("Support parallel --make","YES")
>>     ,("Dynamic by default","NO")
>>     ,("GHC Dynamic","YES")
>>     ,("Leading underscore","YES")
>>     ,("Debug on","False")
>>
>>     ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3")
>>     ,("Global Package
>>    DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d")
>>     ]
>>    - Not sure I found the correct instructions for building from
>>    source,  I used the following:
>>       -
>>
>>       $ autoreconf
>>       $ ./configure
>>       $ make
>>       $ make install
>>
>>
>>
>>
>> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin at well-typed.com>
>> wrote:
>>
>>> We are pleased to announce the first release candidate for GHC 7.10.1:
>>>
>>>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
>>>
>>> This includes the source tarball and bindists for 64bit/32bit Linux
>>> and Windows. Binary builds for other platforms will be available
>>> shortly. (CentOS 6.5 binaries are not available at this time like they
>>> were for 7.8.x). These binaries and tarballs have an accompanying
>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>>
>>> We plan to make the 7.10.1 release sometime in February of 2015. We
>>> expect another RC to occur during January of 2015.
>>>
>>> Please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150117/9d1f9d67/attachment.html>

From hesselink at gmail.com  Sat Jan 17 18:38:38 2015
From: hesselink at gmail.com (Erik Hesselink)
Date: Sat, 17 Jan 2015 19:38:38 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS
 platform
In-Reply-To: <CAB-d4A6p49-+FTb0wSOxiu1zH8EdxdfpG2TuuADiBgEcBZV9cA@mail.gmail.com>
References: <CAB-d4A6p49-+FTb0wSOxiu1zH8EdxdfpG2TuuADiBgEcBZV9cA@mail.gmail.com>
Message-ID: <CAPeieQF_+-k9-vi8WDvSQFzrLeOCeypxZOFGarBRUeSOjGMhwA@mail.gmail.com>

Hi George,

I've not tried compiling via llvm, but I have a working Mac GHC 7.10
build that I've been using, and haven't seen any of the other issues
you mentioned. I'm not sure what's recommended but I believe I'm using
clang (see output below). If you want to try my build, you can
download it at [1]. BTW, the info you posted seems to be from 7.8, not
7.10.

Regards,

Erik

[1] https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nNFR4WUVNZzRtbGs&export=download

$ gcc --version
Configured with: --prefix=/Library/Developer/CommandLineTools/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

$ ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/usr/bin/gcc")
 ,("C compiler flags"," -m64 -fno-stack-protector")
 ,("C compiler link flags"," -m64")
 ,("Haskell CPP command","/usr/bin/gcc")
 ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
-Wno-unicode -Wno-trigraphs ")
 ,("ld command","/usr/bin/ld")
 ,("ld flags"," -arch x86_64")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","YES")
 ,("ld is GNU ld","NO")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","clqs")
 ,("ar supports at file","NO")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("Unregisterised","NO")
 ,("LLVM llc command","llc")
 ,("LLVM opt command","opt")
 ,("Project version","7.10.0.20141222")
 ,("Project Git commit id","a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a")
 ,("Booter version","7.8.3")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","NO")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn l_dyn thr_l_dyn")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222")
 ,("Global Package
DB","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d")
 ]

On Sat, Jan 17, 2015 at 1:36 PM, George Colpitts
<george.colpitts at gmail.com> wrote:
> Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My problem is
> described below.
> Which is the recommended gcc to use when building source?
>
> GNU gcc  4.9.2
> Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
>
> When using ghci with 7.10.1 RC1 I get the following errors intermittently.
> Is anybody else seeing these?
>
> Too late for parseStaticFlags: call it before runGhc or runGhcT
> *** Exception: ExitFailure 1
> ld: library not found for -l:ghc31505_10.dylib
> collect2: error: ld returned 1 exit status
> phase `Linker' failed (exitcode = 1)
>
> Thanks
>
> On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts <george.colpitts at gmail.com>
> wrote:
>>
>> Only problem remaining is compiling with -fllvm and running resulting
>> executable
>>
>> .
>> ..
>>
>>
>> llvm , compiling with llvm (3.4.2) gives the following warnings:
>>
>> $ ghc  -fllvm cubeFast.hs
>> [1 of 1] Compiling Main             ( cubeFast.hs, cubeFast.o )
>> clang: warning: argument unused during compilation: '-fno-stack-protector'
>> clang: warning: argument unused during compilation: '-D
>> TABLES_NEXT_TO_CODE'
>> clang: warning: argument unused during compilation: '-I .'
>> clang: warning: argument unused during compilation: '-fno-common'
>> clang: warning: argument unused during compilation: '-U __PIC__'
>> clang: warning: argument unused during compilation: '-D __PIC__'
>> Linking cubeFast ...
>> running the resulting executable crashes (compiling without -fllvm gives
>> no warnings and executable works properly)
>>  cat bigCube.txt | ./cubeFast > /dev/null
>> Segmentation fault: 11
>> Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
>> Exception Codes:       KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460
>>>
>>> ...
>>>
>>> Configuration details:
>>>
>>> Mac OS 10.10.1 (Yosemite)
>>>  uname -a
>>> Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
>>> 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
>>> llvm info:
>>>  opt --version
>>> LLVM (http://llvm.org/):
>>>   LLVM version 3.4.2
>>>   Optimized build with assertions.
>>>   Built Oct 31 2014 (23:14:30).
>>>   Default target: x86_64-apple-darwin14.0.0
>>>   Host CPU: corei7
>>>  gcc --version
>>> gcc (Homebrew gcc 4.9.1) 4.9.1
>>> Copyright (C) 2014 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>> /usr/bin/ghc --info
>>>  [("Project name","The Glorious Glasgow Haskell Compilation System")
>>>  ,("GCC extra via C opts"," -fwrapv")
>>>  ,("C compiler command","/usr/bin/gcc")
>>>  ,("C compiler flags"," -m64 -fno-stack-protector")
>>>  ,("C compiler link flags"," -m64")
>>>  ,("Haskell CPP command","/usr/bin/gcc")
>>>  ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
>>> -Wno-unicode -Wno-trigraphs")
>>>  ,("ld command","/usr/bin/ld")
>>>  ,("ld flags"," -arch x86_64")
>>>  ,("ld supports compact unwind","YES")
>>>  ,("ld supports build-id","NO")
>>>  ,("ld supports filelist","YES")
>>>  ,("ld is GNU ld","NO")
>>>  ,("ar command","/usr/bin/ar")
>>>  ,("ar flags","clqs")
>>>  ,("ar supports at file","NO")
>>>  ,("touch command","touch")
>>>  ,("dllwrap command","/bin/false")
>>>  ,("windres command","/bin/false")
>>>  ,("libtool command","libtool")
>>>  ,("perl command","/usr/bin/perl")
>>>  ,("target os","OSDarwin")
>>>  ,("target arch","ArchX86_64")
>>>  ,("target word size","8")
>>>  ,("target has GNU nonexec stack","False")
>>>  ,("target has .ident directive","True")
>>>  ,("target has subsections via symbols","True")
>>>  ,("Unregisterised","NO")
>>>  ,("LLVM llc command","llc")
>>>  ,("LLVM opt command","opt")
>>>  ,("Project version","7.8.3")
>>>  ,("Booter version","7.6.3")
>>>  ,("Stage","2")
>>>  ,("Build platform","x86_64-apple-darwin")
>>>  ,("Host platform","x86_64-apple-darwin")
>>>  ,("Target platform","x86_64-apple-darwin")
>>>  ,("Have interpreter","YES")
>>>  ,("Object splitting supported","YES")
>>>  ,("Have native code generator","YES")
>>>  ,("Support SMP","YES")
>>>  ,("Tables next to code","YES")
>>>  ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
>>> thr_debug_dyn l_dyn thr_l_dyn")
>>>  ,("Support dynamic-too","YES")
>>>  ,("Support parallel --make","YES")
>>>  ,("Dynamic by default","NO")
>>>  ,("GHC Dynamic","YES")
>>>  ,("Leading underscore","YES")
>>>  ,("Debug on","False")
>>>
>>> ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3")
>>>  ,("Global Package
>>> DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d")
>>>  ]
>>> Not sure I found the correct instructions for building from source,  I
>>> used the following:
>>>
>>> $ autoreconf
>>> $ ./configure
>>> $ make
>>> $ make install
>>>
>>>
>>>
>>> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin at well-typed.com>
>>> wrote:
>>>>
>>>> We are pleased to announce the first release candidate for GHC 7.10.1:
>>>>
>>>>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
>>>>
>>>> This includes the source tarball and bindists for 64bit/32bit Linux
>>>> and Windows. Binary builds for other platforms will be available
>>>> shortly. (CentOS 6.5 binaries are not available at this time like they
>>>> were for 7.8.x). These binaries and tarballs have an accompanying
>>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>>>
>>>> We plan to make the 7.10.1 release sometime in February of 2015. We
>>>> expect another RC to occur during January of 2015.
>>>>
>>>> Please test as much as possible; bugs are much cheaper if we find them
>>>> before the release!
>>>>
>>>> --
>>>> Regards,
>>>>
>>>> Austin Seipp, Haskell Consultant
>>>> Well-Typed LLP, http://www.well-typed.com/
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From mike at proclivis.com  Sun Jan 18 01:15:09 2015
From: mike at proclivis.com (Michael Jones)
Date: Sat, 17 Jan 2015 18:15:09 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
Message-ID: <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>

I have narrowed down the problem a bit. It turns out that many times if I run the program and wait long enough, it will start. Given an event log, it may take from 1000-10000 entries sometimes.

When I look at a good start vs. slow start, I see that in both cases things startup and there is some thread activity for thread 2 and 3, then the application starts creating other threads, which is when the wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case, it just gets stuck on thread 2/3 activity for a very long time.

If I switch from -C0.001 to -C0.010, the startup is more reliable, in that most starts result in an immediate GUI and i2c IO.

The behavior suggests to me that some initial threads are starving the ability for other threads to start, and perhaps on a dual core machine it is more of a problem than single or quad core machines. For certain, due to some printing, I know that the main thread is starting, and that a print just before the first fork is not printing. Code between them is evaluating wxhaskell functions, but the main frame is not yet asked to become visible. From last week, I know that an non-gui version of the app is getting stuck, but I do not know if it eventually runs like this case.

Is there some convention that when I look at an event log you can tell which threads are OS threads vs threads from fork?

Perhaps someone that knows the scheduler might have some advice. It seems odd that a scheduler could behave this way. The scheduler should have some built in notion of fairness.


On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com> wrote:

> Sorry I am reviving an old problem, but it has resurfaced, such that one system behaves different than another.
> 
> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax, something bad is going on. In summary, the same code that runs on two machines does not run on a third machine. So this indicates I have not made any breaking changes to the code or cabal files. Compiling with GHC 7.8.3.
> 
> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1 kernel. It is a dual core 64 bit I86 Atom processor. The application hangs at startup. If I remove the -C0.00N option and instead use -V0, the application runs. It has bad timing properties, but it does at least run. Note that a hang hangs an IO thread talking USB, and the GUI thread.
> 
> When testing with the -C0.00N option, it did run 2 times out of 20 tries, so fail means fail most but not all of the time. When it did run, it continued to run properly. This perhaps indicates some kind of internal race condition.
> 
> In the fail to run case, it does some printing up to the point where it tries to create a wxHaskell frame. In another non-UI version of the program it also fails to run. Logging to a file gives a similar indication. It is clear that the program starts up, then fails during the run in some form of lockup, well after the initial startup code.
> 
> If I run with the strace command, it always runs with -C0.00N.
> 
> All the above was done with profiling enabled, so I removed that and instead enabled eventlog to look for clues.
> 
> In this case it lies between good and bad, in that IO to my USB is working, but the GUI comes up blank and never paints. Running this case without -v0 (event log) the gui partially paints and stops, but USB continues.
> 
> Questions:
> 
> 1) Does ghc 7.8.4 have any improvements that might pertain to these kinds of scheduling/thread problems?
> 2) Is there anything about the nature of a thread using USB, I2C, or wxHaskell IO that leads to problems that a pure calculation app would not have?
> 3) Any ideas how to track down the problem when changing conditions (compiler or runtime options) affects behavior?
> 4) Are there other options besides -V and -C for the runtime that might apply?
> 5) What does -V0 do that makes a problem program run?
> 
> Mike
> 
> 
> 
> 
> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com> wrote:
> 
>> John,
>> 
>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave more like -N4.
>> 
>> Thanks. This saves my project, as I need to deploy on a single core Atom and was stuck.
>> 
>> Mike
>> 
>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com> wrote:
>> 
>>> By any chance do the delays get shorter if you run your program with `+RTS -C0.005` ?  If so, I suspect you're having a problem very similar to one that we had with ghc-7.8 (7.6 too, but it's worse on ghc-7.8 for some reason), involving possible misbehavior of the thread scheduler.
>>> 
>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com> wrote:
>>> I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>> 
>>> I moved from 7.6 to 7.8 and my application behaves very differently. I have three threads, an application thread that plots data with wxhaskell or sends it over a network (depends on settings), a thread doing usb bulk writes, and a thread doing usb bulk reads. Data is moved around with TChan, and TVar is used for coordination.
>>> 
>>> When the application was compiled with 7.6, my stream of usb traffic was smooth. With 7.8, there are lots of delays where nothing seems to be running. These delays are up to 40ms, whereas with 7.6 delays were a 1ms or so.
>>> 
>>> When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it runs fine without with -N2/4.
>>> 
>>> The program is compiled -O2 with profiling. The -N2/4 version uses more memory,  but in both cases with 7.8 and with 7.6 there is no space leak.
>>> 
>>> I tired to compile and use -ls so I could take a look with threadscope, but the application hangs and writes no data to the file. The CPU fans run wild like it is in an infinite loop. It at least pops an unpainted wxhaskell window, so it got partially running.
>>> 
>>> One of my libraries uses option -fsimpl-tick-factor=200 to get around the compiler.
>>> 
>>> What do I need to know about changes to threading and event logging between 7.6 and 7.8? Is there some general documentation somewhere that might help?
>>> 
>>> I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar ball and installed myself, after removing 7.6 with apt-get.
>>> 
>>> Any hints appreciated.
>>> 
>>> Mike
>>> 
>>> 
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>> 
>> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150117/749a2651/attachment-0001.html>

From donn at avvanta.com  Sun Jan 18 06:00:32 2015
From: donn at avvanta.com (Donn Cave)
Date: Sat, 17 Jan 2015 22:00:32 -0800 (PST)
Subject: Thread behavior in 7.8.3
In-Reply-To: <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
Message-ID: <20150118060032.ECCA3F3935@mail.avvanta.com>

Quoth Michael Jones <mike at proclivis.com>,
...
>> 5) What does -V0 do that makes a problem program run?

Well, there's that SIGVTALRM barrage, you may remember we went
over that mid-August.  I expect there are other effects.

	Donn

From george.colpitts at gmail.com  Sun Jan 18 20:04:06 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 18 Jan 2015 16:04:06 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS
 platform
In-Reply-To: <CAPeieQF_+-k9-vi8WDvSQFzrLeOCeypxZOFGarBRUeSOjGMhwA@mail.gmail.com>
References: <CAB-d4A6p49-+FTb0wSOxiu1zH8EdxdfpG2TuuADiBgEcBZV9cA@mail.gmail.com>
 <CAPeieQF_+-k9-vi8WDvSQFzrLeOCeypxZOFGarBRUeSOjGMhwA@mail.gmail.com>
Message-ID: <CAB-d4A6v7dT9OqTc1pRc98rYHu5xbG3Hapr6QLUMF09hV57TsA@mail.gmail.com>

Eric, thanks for the quick response, that is good news that you are not
seeing the problems I see.

However after I rebuilt with Apple gcc and still see the errors when
calling main from ghci.
One is an open ticket, https://ghc.haskell.org/trac/ghc/ticket/9277# which
was reported in versions before 7.10.1 so I updated it with the details of
my experience.

I am running Yosemite 10.10.1. What version are you running?

I did notice some  difference between our two systems.

I have

 /usr/bin/gcc --version
Configured with: *--prefix=/Applications/Xcode.app/Contents/Developer/usr*
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

while you have *--prefix=/Library/Developer/CommandLineTools/usr*

When I try

bash-3.2$ xcode-select --install
xcode-select: error: command line tools are already installed, use
"Software Update" to install updates

it doesn't change anything, I still have the above prefix.

Also, you are right, my last email had info for the wrong ghc, when I look
at the right one and yours I see the following difference. You have

,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222")
,("Global Package
DB","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d")

I have

 ,("LibDir","/usr/local/lib/ghc-7.10.0.20141222")
 ,("Global Package DB","/usr/local/lib/ghc-7.10.0.20141222/package.conf.d")

I am doing a build by doing the following:

$ autoreconf
$ ./configure
$ make
$ make install

?The correct output from ghc --info for me is:

ghc --info
 [("Project name","The Glorious Glasgow Haskell Compilation System")
 ,("GCC extra via C opts"," -fwrapv")
 ,("C compiler command","/usr/bin/gcc")
 ,("C compiler flags"," -m64 -fno-stack-protector")
 ,("C compiler link flags"," -m64")
 ,("Haskell CPP command","/usr/bin/gcc")
 ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
-Wno-unicode -Wno-trigraphs ")
 ,("ld command","/usr/bin/ld")
 ,("ld flags"," -arch x86_64")
 ,("ld supports compact unwind","YES")
 ,("ld supports build-id","NO")
 ,("ld supports filelist","YES")
 ,("ld is GNU ld","NO")
 ,("ar command","/usr/bin/ar")
 ,("ar flags","clqs")
 ,("ar supports at file","NO")
 ,("touch command","touch")
 ,("dllwrap command","/bin/false")
 ,("windres command","/bin/false")
 ,("libtool command","libtool")
 ,("perl command","/usr/bin/perl")
 ,("target os","OSDarwin")
 ,("target arch","ArchX86_64")
 ,("target word size","8")
 ,("target has GNU nonexec stack","False")
 ,("target has .ident directive","True")
 ,("target has subsections via symbols","True")
 ,("Unregisterised","NO")
 ,("LLVM llc command","/usr/local/bin/llc")
 ,("LLVM opt command","/usr/local/bin/opt")
 ,("Project version","7.10.0.20141222")
 ,("Project Git commit id","a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a")
 ,("Booter version","7.8.3")
 ,("Stage","2")
 ,("Build platform","x86_64-apple-darwin")
 ,("Host platform","x86_64-apple-darwin")
 ,("Target platform","x86_64-apple-darwin")
 ,("Have interpreter","YES")
 ,("Object splitting supported","YES")
 ,("Have native code generator","YES")
 ,("Support SMP","YES")
 ,("Tables next to code","YES")
 ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
thr_debug_dyn l_dyn thr_l_dyn")
 ,("Support dynamic-too","YES")
 ,("Support parallel --make","YES")
 ,("Support reexported-modules","YES")
 ,("Support thinning and renaming package flags","YES")
 ,("Uses package keys","YES")
 ,("Dynamic by default","NO")
 ,("GHC Dynamic","YES")
 ,("Leading underscore","YES")
 ,("Debug on","False")
 ,("LibDir","/usr/local/lib/ghc-7.10.0.20141222")
 ,("Global Package DB","/usr/local/lib/ghc-7.10.0.20141222/package.conf.d")
 ]?


On Sat, Jan 17, 2015 at 2:38 PM, Erik Hesselink <hesselink at gmail.com> wrote:

> Hi George,
>
> I've not tried compiling via llvm, but I have a working Mac GHC 7.10
> build that I've been using, and haven't seen any of the other issues
> you mentioned. I'm not sure what's recommended but I believe I'm using
> clang (see output below). If you want to try my build, you can
> download it at [1]. BTW, the info you posted seems to be from 7.8, not
> 7.10.
>
> Regards,
>
> Erik
>
> [1]
> https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nNFR4WUVNZzRtbGs&export=download
>
> $ gcc --version
> Configured with: --prefix=/Library/Developer/CommandLineTools/usr
> --with-gxx-include-dir=/usr/include/c++/4.2.1
> Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin13.4.0
> Thread model: posix
>
> $ ghc --info
>  [("Project name","The Glorious Glasgow Haskell Compilation System")
>  ,("GCC extra via C opts"," -fwrapv")
>  ,("C compiler command","/usr/bin/gcc")
>  ,("C compiler flags"," -m64 -fno-stack-protector")
>  ,("C compiler link flags"," -m64")
>  ,("Haskell CPP command","/usr/bin/gcc")
>  ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
> -Wno-unicode -Wno-trigraphs ")
>  ,("ld command","/usr/bin/ld")
>  ,("ld flags"," -arch x86_64")
>  ,("ld supports compact unwind","YES")
>  ,("ld supports build-id","NO")
>  ,("ld supports filelist","YES")
>  ,("ld is GNU ld","NO")
>  ,("ar command","/usr/bin/ar")
>  ,("ar flags","clqs")
>  ,("ar supports at file","NO")
>  ,("touch command","touch")
>  ,("dllwrap command","/bin/false")
>  ,("windres command","/bin/false")
>  ,("libtool command","libtool")
>  ,("perl command","/usr/bin/perl")
>  ,("target os","OSDarwin")
>  ,("target arch","ArchX86_64")
>  ,("target word size","8")
>  ,("target has GNU nonexec stack","False")
>  ,("target has .ident directive","True")
>  ,("target has subsections via symbols","True")
>  ,("Unregisterised","NO")
>  ,("LLVM llc command","llc")
>  ,("LLVM opt command","opt")
>  ,("Project version","7.10.0.20141222")
>  ,("Project Git commit id","a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a")
>  ,("Booter version","7.8.3")
>  ,("Stage","2")
>  ,("Build platform","x86_64-apple-darwin")
>  ,("Host platform","x86_64-apple-darwin")
>  ,("Target platform","x86_64-apple-darwin")
>  ,("Have interpreter","YES")
>  ,("Object splitting supported","NO")
>  ,("Have native code generator","YES")
>  ,("Support SMP","YES")
>  ,("Tables next to code","YES")
>  ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
> thr_debug_dyn l_dyn thr_l_dyn")
>  ,("Support dynamic-too","YES")
>  ,("Support parallel --make","YES")
>  ,("Support reexported-modules","YES")
>  ,("Support thinning and renaming package flags","YES")
>  ,("Uses package keys","YES")
>  ,("Dynamic by default","NO")
>  ,("GHC Dynamic","YES")
>  ,("Leading underscore","YES")
>  ,("Debug on","False")
>
>  ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222")
>  ,("Global Package
>
> DB","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d")
>  ]
>
> On Sat, Jan 17, 2015 at 1:36 PM, George Colpitts
> <george.colpitts at gmail.com> wrote:
> > Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My
> problem is
> > described below.
> > Which is the recommended gcc to use when building source?
> >
> > GNU gcc  4.9.2
> > Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
> >
> > When using ghci with 7.10.1 RC1 I get the following errors
> intermittently.
> > Is anybody else seeing these?
> >
> > Too late for parseStaticFlags: call it before runGhc or runGhcT
> > *** Exception: ExitFailure 1
> > ld: library not found for -l:ghc31505_10.dylib
> > collect2: error: ld returned 1 exit status
> > phase `Linker' failed (exitcode = 1)
> >
> > Thanks
> >
> > On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts <
> george.colpitts at gmail.com>
> > wrote:
> >>
> >> Only problem remaining is compiling with -fllvm and running resulting
> >> executable
> >>
> >> .
> >> ..
> >>
> >>
> >> llvm , compiling with llvm (3.4.2) gives the following warnings:
> >>
> >> $ ghc  -fllvm cubeFast.hs
> >> [1 of 1] Compiling Main             ( cubeFast.hs, cubeFast.o )
> >> clang: warning: argument unused during compilation:
> '-fno-stack-protector'
> >> clang: warning: argument unused during compilation: '-D
> >> TABLES_NEXT_TO_CODE'
> >> clang: warning: argument unused during compilation: '-I .'
> >> clang: warning: argument unused during compilation: '-fno-common'
> >> clang: warning: argument unused during compilation: '-U __PIC__'
> >> clang: warning: argument unused during compilation: '-D __PIC__'
> >> Linking cubeFast ...
> >> running the resulting executable crashes (compiling without -fllvm gives
> >> no warnings and executable works properly)
> >>  cat bigCube.txt | ./cubeFast > /dev/null
> >> Segmentation fault: 11
> >> Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
> >> Exception Codes:       KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460
> >>>
> >>> ...
> >>>
> >>> Configuration details:
> >>>
> >>> Mac OS 10.10.1 (Yosemite)
> >>>  uname -a
> >>> Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19
> >>> 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64
> >>> llvm info:
> >>>  opt --version
> >>> LLVM (http://llvm.org/):
> >>>   LLVM version 3.4.2
> >>>   Optimized build with assertions.
> >>>   Built Oct 31 2014 (23:14:30).
> >>>   Default target: x86_64-apple-darwin14.0.0
> >>>   Host CPU: corei7
> >>>  gcc --version
> >>> gcc (Homebrew gcc 4.9.1) 4.9.1
> >>> Copyright (C) 2014 Free Software Foundation, Inc.
> >>> This is free software; see the source for copying conditions.  There is
> >>> NO
> >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> >>> PURPOSE.
> >>> /usr/bin/ghc --info
> >>>  [("Project name","The Glorious Glasgow Haskell Compilation System")
> >>>  ,("GCC extra via C opts"," -fwrapv")
> >>>  ,("C compiler command","/usr/bin/gcc")
> >>>  ,("C compiler flags"," -m64 -fno-stack-protector")
> >>>  ,("C compiler link flags"," -m64")
> >>>  ,("Haskell CPP command","/usr/bin/gcc")
> >>>  ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token
> >>> -Wno-unicode -Wno-trigraphs")
> >>>  ,("ld command","/usr/bin/ld")
> >>>  ,("ld flags"," -arch x86_64")
> >>>  ,("ld supports compact unwind","YES")
> >>>  ,("ld supports build-id","NO")
> >>>  ,("ld supports filelist","YES")
> >>>  ,("ld is GNU ld","NO")
> >>>  ,("ar command","/usr/bin/ar")
> >>>  ,("ar flags","clqs")
> >>>  ,("ar supports at file","NO")
> >>>  ,("touch command","touch")
> >>>  ,("dllwrap command","/bin/false")
> >>>  ,("windres command","/bin/false")
> >>>  ,("libtool command","libtool")
> >>>  ,("perl command","/usr/bin/perl")
> >>>  ,("target os","OSDarwin")
> >>>  ,("target arch","ArchX86_64")
> >>>  ,("target word size","8")
> >>>  ,("target has GNU nonexec stack","False")
> >>>  ,("target has .ident directive","True")
> >>>  ,("target has subsections via symbols","True")
> >>>  ,("Unregisterised","NO")
> >>>  ,("LLVM llc command","llc")
> >>>  ,("LLVM opt command","opt")
> >>>  ,("Project version","7.8.3")
> >>>  ,("Booter version","7.6.3")
> >>>  ,("Stage","2")
> >>>  ,("Build platform","x86_64-apple-darwin")
> >>>  ,("Host platform","x86_64-apple-darwin")
> >>>  ,("Target platform","x86_64-apple-darwin")
> >>>  ,("Have interpreter","YES")
> >>>  ,("Object splitting supported","YES")
> >>>  ,("Have native code generator","YES")
> >>>  ,("Support SMP","YES")
> >>>  ,("Tables next to code","YES")
> >>>  ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn
> >>> thr_debug_dyn l_dyn thr_l_dyn")
> >>>  ,("Support dynamic-too","YES")
> >>>  ,("Support parallel --make","YES")
> >>>  ,("Dynamic by default","NO")
> >>>  ,("GHC Dynamic","YES")
> >>>  ,("Leading underscore","YES")
> >>>  ,("Debug on","False")
> >>>
> >>>
> ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3")
> >>>  ,("Global Package
> >>>
> DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d")
> >>>  ]
> >>> Not sure I found the correct instructions for building from source,  I
> >>> used the following:
> >>>
> >>> $ autoreconf
> >>> $ ./configure
> >>> $ make
> >>> $ make install
> >>>
> >>>
> >>>
> >>> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin at well-typed.com>
> >>> wrote:
> >>>>
> >>>> We are pleased to announce the first release candidate for GHC 7.10.1:
> >>>>
> >>>>     https://downloads.haskell.org/~ghc/7.10.1-rc1/
> >>>>
> >>>> This includes the source tarball and bindists for 64bit/32bit Linux
> >>>> and Windows. Binary builds for other platforms will be available
> >>>> shortly. (CentOS 6.5 binaries are not available at this time like they
> >>>> were for 7.8.x). These binaries and tarballs have an accompanying
> >>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
> >>>>
> >>>> We plan to make the 7.10.1 release sometime in February of 2015. We
> >>>> expect another RC to occur during January of 2015.
> >>>>
> >>>> Please test as much as possible; bugs are much cheaper if we find them
> >>>> before the release!
> >>>>
> >>>> --
> >>>> Regards,
> >>>>
> >>>> Austin Seipp, Haskell Consultant
> >>>> Well-Typed LLP, http://www.well-typed.com/
> >>>> _______________________________________________
> >>>> ghc-devs mailing list
> >>>> ghc-devs at haskell.org
> >>>> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>>
> >>>
> >>
> >
> >
> > _______________________________________________
> > Glasgow-haskell-users mailing list
> > Glasgow-haskell-users at haskell.org
> > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150118/c63a866c/attachment-0001.html>

From mike at proclivis.com  Sun Jan 18 22:36:51 2015
From: mike at proclivis.com (Michael Jones)
Date: Sun, 18 Jan 2015 15:36:51 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <20150118060032.ECCA3F3935@mail.avvanta.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <20150118060032.ECCA3F3935@mail.avvanta.com>
Message-ID: <C3FC6E78-7661-4A85-9E29-BFE02525C676@proclivis.com>

Donn,

True, but in that case I was using a driver for the Aardvark, and my current two test cases use:

A) DC1613A from LTC
B) /dev/i2c driver with FFI wrapper I wrote

Case A uses the haskell usb package and libusb. I suppose SIGVALRM could be in used in the libusb driver. I know for sure it is not used by my I2C stuff, unless it is behind the /dev/i2c user mode calls.

But interesting. Obviously the scheduler is using timers from the OS.

Is it really an advantage not to use OS threads all around? Is there anyway to enable such behavior to see if things are better?

Mike

On Jan 17, 2015, at 11:00 PM, Donn Cave <donn at avvanta.com> wrote:

> Quoth Michael Jones <mike at proclivis.com>,
> ...
>>> 5) What does -V0 do that makes a problem program run?
> 
> Well, there's that SIGVTALRM barrage, you may remember we went
> over that mid-August.  I expect there are other effects.
> 
> 	Donn



From marlowsd at gmail.com  Mon Jan 19 10:37:51 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 19 Jan 2015 10:37:51 +0000
Subject: Thread behavior in 7.8.3
In-Reply-To: <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
Message-ID: <54BCDE7F.6050908@gmail.com>

Hi Michael,

Previously in this thread it was pointed out that your code was doing 
busy waiting, and so the problem can be fixed by modifying your code to 
not do busy waiting.  Did you do this?  The -C flag is just a workaround 
which will make the RTS reschedule more often, it won't fix the 
underlying problem.

The code you showed us was:

sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> 
ProcessT m (Spec, String) ()
sendTransactions dev dts = repeatedly $ do
   dts' <- liftIO $ atomically $ readTVar dts
   when (dts' == True) (do
       (_, transactions) <- await
       liftIO $ sendOut dev transactions)

This loops when the contents of the TVar is False.

Cheers,
Simon

On 18/01/2015 01:15, Michael Jones wrote:
> I have narrowed down the problem a bit. It turns out that many times if
> I run the program and wait long enough, it will start. Given an event
> log, it may take from 1000-10000 entries sometimes.
>
> When I look at a good start vs. slow start, I see that in both cases
> things startup and there is some thread activity for thread 2 and 3,
> then the application starts creating other threads, which is when the
> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
> it just gets stuck on thread 2/3 activity for a very long time.
>
> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
> that most starts result in an immediate GUI and i2c IO.
>
> The behavior suggests to me that some initial threads are starving the
> ability for other threads to start, and perhaps on a dual core machine
> it is more of a problem than single or quad core machines. For certain,
> due to some printing, I know that the main thread is starting, and that
> a print just before the first fork is not printing. Code between them is
> evaluating wxhaskell functions, but the main frame is not yet asked to
> become visible. From last week, I know that an non-gui version of the
> app is getting stuck, but I do not know if it eventually runs like this
> case.
>
> Is there some convention that when I look at an event log you can tell
> which threads are OS threads vs threads from fork?
>
> Perhaps someone that knows the scheduler might have some advice. It
> seems odd that a scheduler could behave this way. The scheduler should
> have some built in notion of fairness.
>
>
> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
> <mailto:mike at proclivis.com>> wrote:
>
>> Sorry I am reviving an old problem, but it has resurfaced, such that
>> one system behaves different than another.
>>
>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>> something bad is going on. In summary, the same code that runs on two
>> machines does not run on a third machine. So this indicates I have not
>> made any breaking changes to the code or cabal files. Compiling with
>> GHC 7.8.3.
>>
>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>> the application runs. It has bad timing properties, but it does at
>> least run. Note that a hang hangs an IO thread talking USB, and the
>> GUI thread.
>>
>> When testing with the -C0.00N option, it did run 2 times out of 20
>> tries, so fail means fail most but not all of the time. When it did
>> run, it continued to run properly. This perhaps indicates some kind of
>> internal race condition.
>>
>> In the fail to run case, it does some printing up to the point where
>> it tries to create a wxHaskell frame. In another non-UI version of the
>> program it also fails to run. Logging to a file gives a similar
>> indication. It is clear that the program starts up, then fails during
>> the run in some form of lockup, well after the initial startup code.
>>
>> If I run with the strace command, it always runs with -C0.00N.
>>
>> All the above was done with profiling enabled, so I removed that and
>> instead enabled eventlog to look for clues.
>>
>> In this case it lies between good and bad, in that IO to my USB is
>> working, but the GUI comes up blank and never paints. Running this
>> case without -v0 (event log) the gui partially paints and stops, but
>> USB continues.
>>
>> Questions:
>>
>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>> kinds of scheduling/thread problems?
>> 2) Is there anything about the nature of a thread using USB, I2C, or
>> wxHaskell IO that leads to problems that a pure calculation app would
>> not have?
>> 3) Any ideas how to track down the problem when changing conditions
>> (compiler or runtime options) affects behavior?
>> 4) Are there other options besides -V and -C for the runtime that
>> might apply?
>> 5) What does -V0 do that makes a problem program run?
>>
>> Mike
>>
>>
>>
>>
>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>> <mailto:mike at proclivis.com>> wrote:
>>
>>> John,
>>>
>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>> more like -N4.
>>>
>>> Thanks. This saves my project, as I need to deploy on a single core
>>> Atom and was stuck.
>>>
>>> Mike
>>>
>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>> <mailto:jwlato at gmail.com>> wrote:
>>>
>>>> By any chance do the delays get shorter if you run your program with
>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>> thread scheduler.
>>>>
>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>> <mailto:mike at proclivis.com>> wrote:
>>>>
>>>>     I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>
>>>>     I moved from 7.6 to 7.8 and my application behaves very
>>>>     differently. I have three threads, an application thread that
>>>>     plots data with wxhaskell or sends it over a network (depends on
>>>>     settings), a thread doing usb bulk writes, and a thread doing
>>>>     usb bulk reads. Data is moved around with TChan, and TVar is
>>>>     used for coordination.
>>>>
>>>>     When the application was compiled with 7.6, my stream of usb
>>>>     traffic was smooth. With 7.8, there are lots of delays where
>>>>     nothing seems to be running. These delays are up to 40ms,
>>>>     whereas with 7.6 delays were a 1ms or so.
>>>>
>>>>     When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>     runs fine without with -N2/4.
>>>>
>>>>     The program is compiled -O2 with profiling. The -N2/4 version
>>>>     uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>     is no space leak.
>>>>
>>>>     I tired to compile and use -ls so I could take a look with
>>>>     threadscope, but the application hangs and writes no data to the
>>>>     file. The CPU fans run wild like it is in an infinite loop. It
>>>>     at least pops an unpainted wxhaskell window, so it got partially
>>>>     running.
>>>>
>>>>     One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>     around the compiler.
>>>>
>>>>     What do I need to know about changes to threading and event
>>>>     logging between 7.6 and 7.8? Is there some general documentation
>>>>     somewhere that might help?
>>>>
>>>>     I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>     ball and installed myself, after removing 7.6 with apt-get.
>>>>
>>>>     Any hints appreciated.
>>>>
>>>>     Mike
>>>>
>>>>
>>>>     _______________________________________________
>>>>     Glasgow-haskell-users mailing list
>>>>     Glasgow-haskell-users at haskell.org
>>>>     <mailto:Glasgow-haskell-users at haskell.org>
>>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> <mailto:Glasgow-haskell-users at haskell.org>
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From peter.trommler at ohm-hochschule.de  Mon Jan 19 11:04:12 2015
From: peter.trommler at ohm-hochschule.de (Peter Trommler)
Date: Mon, 19 Jan 2015 12:04:12 +0100
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS
 platform
References: <CAB-d4A6p49-+FTb0wSOxiu1zH8EdxdfpG2TuuADiBgEcBZV9cA@mail.gmail.com>
Message-ID: <m9iodi$n1j$1@ger.gmane.org>

George Colpitts wrote:

[...]
>    - When using ghci with 7.10.1 RC1 I get the following errors
>    intermittently. Is anybody else seeing these?
[...]
>       - ld: library not found for -l:ghc31505_10.dylib
>       collect2: error: ld returned 1 exit status
>       phase `Linker' failed (exitcode = 1)
This is ticket #9875 (https://ghc.haskell.org/trac/ghc/ticket/9875)
and it is fixed in HEAD and has been merged into the 7.10 branch. The
fix will be in ghc 7.10.1 RC2.

Peter 


From verteiler at volker-wysk.de  Tue Jan 20 04:14:15 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Tue, 20 Jan 2015 05:14:15 +0100
Subject: Package version question with Cabal
Message-ID: <1871694.ATtXvhJ6tZ@debian>

Hi!

I've uploaded my library to Hackage, and now I'm trying to install it via 
cabal:

~/src/hsshellscript $ cabal install 
Resolving dependencies...
In order, the following will be installed:
hsshellscript-3.3.3 (reinstall)
Warning: Note that reinstalls are always dangerous. Continuing anyway...
Configuring hsshellscript-3.3.3...
Building hsshellscript-3.3.3...
Preprocessing library hsshellscript-3.3.3...
In-place registering hsshellscript-3.3.3...
Creating package registration file: /tmp/pkgConf-hsshellscript-3.37397.3
Installing library in
/home/v/.cabal/lib/x86_64-linux-ghc-7.8.3/hsshellscript-3.3.3
Registering hsshellscript-3.3.3...
Installed hsshellscript-3.3.3

~/src/hsshellscript $ cabal list hsshellscript
* hsshellscript
    Synopsis: Haskell for Unix shell scripting tasks
    Default available version: 3.3.2
    Installed versions: 3.3.1, 3.3.2, 3.3.3
    Homepage: http://www.volker-wysk.de/hsshellscript/
    License:  LGPL

The thing wich looks like a problem is, that the new version isn't made the 
"Default available version". It is 3.3.3, but "Default available version" is 
still 3.3.2.

Is this a problem? How do I register a new default version?

Bye
Volker


From verteiler at volker-wysk.de  Tue Jan 20 04:26:26 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Tue, 20 Jan 2015 05:26:26 +0100
Subject: Package version question with Cabal
In-Reply-To: <1871694.ATtXvhJ6tZ@debian>
References: <1871694.ATtXvhJ6tZ@debian>
Message-ID: <1608761.LNcUlofKem@debian>

Am Dienstag, 20. Januar 2015, 05:14:15 schrieb Volker Wysk:
> ~/src/hsshellscript $ cabal install

Oops, this should be "cabal install hsshellscript-3.3.3", not just "cabal 
install":

~/src/hsshellscript $ cabal install hsshellscript-3.3.3
Resolving dependencies...
All the requested packages are already installed:
hsshellscript-3.3.3
Use --reinstall if you want to reinstall anyway.

But when I try "--reinstall", I get this error:

~/src/hsshellscript $ cabal --reinstall install hsshellscript-3.3.3
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: hsshellscript (user goal)
rejecting: hsshellscript-3.3.2, 3.3.1, 3.3.0, 3.2.0, 3.1.0 (global constraint
requires ==3.3.3)
Dependency tree exhaustively searched.

What does this mean...?

I've also in vain searched for a way to remove a cabal installed package.

Thanks,
Volker


From allbery.b at gmail.com  Tue Jan 20 04:32:09 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Mon, 19 Jan 2015 23:32:09 -0500
Subject: Package version question with Cabal
In-Reply-To: <1871694.ATtXvhJ6tZ@debian>
References: <1871694.ATtXvhJ6tZ@debian>
Message-ID: <CAKFCL4WmhjmzbZQJfkBgUrhzsWAfxzhykbj_-ZRRGVH8DacrJw@mail.gmail.com>

On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk <verteiler at volker-wysk.de>
wrote:

> I've uploaded my library to Hackage, and now I'm trying to install it via
> cabal:
>

At a guess, the index has not yet been updated --- you may need to wait
some time (might be as short as an hour) before trying to install it from
Hackage.

You also need to run "cabal update" to download the updated package index
so your local cabal-install knows about the new package.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150119/b31c0834/attachment.html>

From vogt.adam at gmail.com  Tue Jan 20 05:29:34 2015
From: vogt.adam at gmail.com (adam vogt)
Date: Tue, 20 Jan 2015 00:29:34 -0500
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
Message-ID: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>

Hello List,

With ghc - 7.8 and 7.6 the following program is accepted:

{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}

class (UnF (F a) ~ a, Show a) => C a where
    type F a
    f :: F a -> a

type family UnF a

g :: forall a. C a => a -> String
g _ = show a
  where a = f (undefined :: F a) -- :: a


ghc-7.10.0.20141222 does not accept the program unless I uncomment the
type signature (a :: a).


I believe this is the main difference that prevents HList from
compiling with 7.10, but I could have made a mistake in coming up with
this minimal example.

Regards,
Adam

From bjp at informatik.uni-kiel.de  Tue Jan 20 11:20:41 2015
From: bjp at informatik.uni-kiel.de (=?UTF-8?B?QmrDtnJuIFBlZW3DtmxsZXI=?=)
Date: Tue, 20 Jan 2015 12:20:41 +0100
Subject: GHC 7.10 regression when using foldr
Message-ID: <54BE3A09.10201@informatik.uni-kiel.de>

I just discovered that the following program compiled fine using GHC
7.8.4 but was rejected by GHC 7.10.1-rc1:

~~~
data List a = Nil | Cons a (List a)

instance Read a => Read (List a) where
  readsPrec d s = map convert (readsPrec d s)
    where
    convert (xs, s2) = (foldr Cons Nil xs, s2)
~~~

GHC 7.10 now complains:

~~~
Read.hs:5:23:
    Could not deduce (Foldable t0) arising from a use of ?convert?
    from the context (Read a)
      bound by the instance declaration at Read.hs:4:10-32
    The type variable ?t0? is ambiguous
    Note: there are several potential instances:
      instance Foldable (Either a) -- Defined in ?Data.Foldable?
      instance Foldable Data.Proxy.Proxy -- Defined in ?Data.Foldable?
      instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i)
        -- Defined in ?Data.Foldable?
      ...plus three others
    In the first argument of ?map?, namely ?convert?
    In the expression: map convert (readsPrec d s)
    In an equation for ?readsPrec?:
        readsPrec d s
          = map convert (readsPrec d s)
          where
              convert (xs, s2) = (foldr Cons Nil xs, s2)

Read.hs:5:32:
    Could not deduce (Read (t0 a)) arising from a use of ?readsPrec?
    from the context (Read a)
      bound by the instance declaration at Read.hs:4:10-32
    The type variable ?t0? is ambiguous
    Relevant bindings include
      readsPrec :: Int -> ReadS (List a) (bound at Read.hs:5:3)
    Note: there are several potential instances:
      instance (Read a, Read b) => Read (Either a b)
        -- Defined in ?Data.Either?
      instance forall (k :: BOX) (s :: k). Read (Data.Proxy.Proxy s)
        -- Defined in ?Data.Proxy?
      instance (GHC.Arr.Ix a, Read a, Read b) => Read (GHC.Arr.Array a b)
        -- Defined in ?GHC.Read?
      ...plus 18 others
    In the second argument of ?map?, namely ?(readsPrec d s)?
    In the expression: map convert (readsPrec d s)
    In an equation for ?readsPrec?:
        readsPrec d s
          = map convert (readsPrec d s)
          where
              convert (xs, s2) = (foldr Cons Nil xs, s2)
~~~

The reason is the usage of foldr, which changed its type from

  foldr :: (a -> b -> b) -> b -> [a] -> b -- GHC 7.8.4

to

  foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b -- GHC 7.10.1

Thus, the use of foldr is now ambiguous. I can fix this by providing a
type signature

  convert :: ([a], String) -> (List a, String)

However, is this breaking change intended?

Regards,
Bj?rn





From malcolm.wallace at me.com  Tue Jan 20 11:43:30 2015
From: malcolm.wallace at me.com (Malcolm Wallace)
Date: Tue, 20 Jan 2015 11:43:30 +0000
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <54BE3A09.10201@informatik.uni-kiel.de>
References: <54BE3A09.10201@informatik.uni-kiel.de>
Message-ID: <93D54D0A-25AE-4A05-803B-4CB866915B90@me.com>


On 20 Jan 2015, at 11:20, Bj?rn Peem?ller wrote:

> The reason is the usage of foldr, which changed its type from
>   foldr :: (a -> b -> b) -> b -> [a] -> b -- GHC 7.8.4
> to
>  foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b -- GHC 7.10.1
> Thus, the use of foldr is now ambiguous. I can fix this by providing a
> type signature
>   convert :: ([a], String) -> (List a, String)
> 
> However, is this breaking change intended?

I believe this kind of breakage was predicted by those opposed to the change of signature.  That is not quite the same thing as being intended or desired.

Regards,
    Malcolm


From ekmett at gmail.com  Tue Jan 20 11:45:10 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 06:45:10 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <54BE3A09.10201@informatik.uni-kiel.de>
References: <54BE3A09.10201@informatik.uni-kiel.de>
Message-ID: <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>

There is a limited set of situations where the new signatures can fail to
infer, where it would infer before.

This can happen when you construct a Foldable/Traversable value using
polymorphic tools (like Read) that were previously instantiated for list,
but where since foldr et al. are now polymorphic, this doesn't give enough
information for it to know that [] is the instance you wanted.

Ultimately, there is, of course, a balancing act between flexibility and
inference.

I can at least say that the incident rate for cases seems to be very low,
especially when it is contrasted against the pain users have had with using
the existing Foldable/Traversable imports where virtually everything in
them collided with less useful versions of the same combinator (e.g. mapM)
from the Prelude that a dozen other modules (e.g. Control.Monad and
virtually every module in mtl) insisted on re-exporting, making it a game
of whack-a-mole to try to hide them.

The fix here is to supply a manual type signature on the helper.

-Edward

On Tue, Jan 20, 2015 at 6:20 AM, Bj?rn Peem?ller <bjp at informatik.uni-kiel.de
> wrote:

> I just discovered that the following program compiled fine using GHC
> 7.8.4 but was rejected by GHC 7.10.1-rc1:
>
> ~~~
> data List a = Nil | Cons a (List a)
>
> instance Read a => Read (List a) where
>   readsPrec d s = map convert (readsPrec d s)
>     where
>     convert (xs, s2) = (foldr Cons Nil xs, s2)
> ~~~
>
> GHC 7.10 now complains:
>
> ~~~
> Read.hs:5:23:
>     Could not deduce (Foldable t0) arising from a use of ?convert?
>     from the context (Read a)
>       bound by the instance declaration at Read.hs:4:10-32
>     The type variable ?t0? is ambiguous
>     Note: there are several potential instances:
>       instance Foldable (Either a) -- Defined in ?Data.Foldable?
>       instance Foldable Data.Proxy.Proxy -- Defined in ?Data.Foldable?
>       instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i)
>         -- Defined in ?Data.Foldable?
>       ...plus three others
>     In the first argument of ?map?, namely ?convert?
>     In the expression: map convert (readsPrec d s)
>     In an equation for ?readsPrec?:
>         readsPrec d s
>           = map convert (readsPrec d s)
>           where
>               convert (xs, s2) = (foldr Cons Nil xs, s2)
>
> Read.hs:5:32:
>     Could not deduce (Read (t0 a)) arising from a use of ?readsPrec?
>     from the context (Read a)
>       bound by the instance declaration at Read.hs:4:10-32
>     The type variable ?t0? is ambiguous
>     Relevant bindings include
>       readsPrec :: Int -> ReadS (List a) (bound at Read.hs:5:3)
>     Note: there are several potential instances:
>       instance (Read a, Read b) => Read (Either a b)
>         -- Defined in ?Data.Either?
>       instance forall (k :: BOX) (s :: k). Read (Data.Proxy.Proxy s)
>         -- Defined in ?Data.Proxy?
>       instance (GHC.Arr.Ix a, Read a, Read b) => Read (GHC.Arr.Array a b)
>         -- Defined in ?GHC.Read?
>       ...plus 18 others
>     In the second argument of ?map?, namely ?(readsPrec d s)?
>     In the expression: map convert (readsPrec d s)
>     In an equation for ?readsPrec?:
>         readsPrec d s
>           = map convert (readsPrec d s)
>           where
>               convert (xs, s2) = (foldr Cons Nil xs, s2)
> ~~~
>
> The reason is the usage of foldr, which changed its type from
>
>   foldr :: (a -> b -> b) -> b -> [a] -> b -- GHC 7.8.4
>
> to
>
>   foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b -- GHC 7.10.1
>
> Thus, the use of foldr is now ambiguous. I can fix this by providing a
> type signature
>
>   convert :: ([a], String) -> (List a, String)
>
> However, is this breaking change intended?
>
> Regards,
> Bj?rn
>
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/b6b05968/attachment-0001.html>

From osymandias+glasgow-haskell-users at gmail.com  Tue Jan 20 13:08:14 2015
From: osymandias+glasgow-haskell-users at gmail.com (Nicholas Clarke)
Date: Tue, 20 Jan 2015 13:08:14 +0000
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
Message-ID: <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>

I'd like to be able to use the UNPACK pragma on an existentially quantified
datatype. So as in the below example:

{-# LANGUAGE ExistentialQuantification #-}

data Foo = forall a. Show a => Foo !a
instance Show Foo where
  show (Foo a) = "Foo! " ++ show a

data Bar =
    Bar {-# UNPACK #-} !Foo
  deriving (Show)

main :: IO ()
main = do
  let foo = Foo "Hello"
      bar = Bar foo
  print bar

I would expect the `Foo` constructor to be unpacked into Bar, as if I had
written:

data Bar = forall a. Show a => Bar !a

However, instead I get the 'Ignoring unusable UNPACK pragma on the first
argument of ?Bar?' warning. Is there a reason this shouldn't work, or a
workaround to get it to do so?

Cheers,

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/b4f1835a/attachment.html>

From ky3 at atamo.com  Tue Jan 20 14:00:52 2015
From: ky3 at atamo.com (Kim-Ee Yeoh)
Date: Tue, 20 Jan 2015 21:00:52 +0700
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
Message-ID: <CAPY+ZdRC0FoGTvAqkKiRys5M=aM9+-x3=4FeQVtr2fmKD43-LA@mail.gmail.com>

On Tue, Jan 20, 2015 at 6:45 PM, Edward Kmett <ekmett at gmail.com> wrote:

> I can at least say that the incident rate for cases seems to be very low,
> especially when it is contrasted against the pain users have had with using
> the existing Foldable/Traversable imports where virtually everything in
> them collided with less useful versions of the same combinator (e.g. mapM)
> from the Prelude that a dozen other modules (e.g. Control.Monad and
> virtually every module in mtl) insisted on re-exporting, making it a game
> of whack-a-mole to try to hide them.



There are few reports because the change hasn't affected the dark majority
yet. RC builds are used by a tiny fraction. There's a long tail of users
still on 7.6, 7.4, 7.2, and 6.x.

The whack-a-mole game needs only to be played once and the results shared
among those relying on the abstractions. Was that route ever explored?

The FTP discussion needs to be re-opened. And it will be, eventually.

-- Kim-Ee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/2003d5ee/attachment.html>

From roma at ro-che.info  Tue Jan 20 14:35:20 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Tue, 20 Jan 2015 16:35:20 +0200
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
 <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
Message-ID: <54BE67A8.5050108@ro-che.info>

Interesting question. I managed to trace this to:

compiler/basicTypes/MkId.hs:699

isUnpackableType fam_envs ty
  | Just (tc, _) <- splitTyConApp_maybe ty
  , Just con <- tyConSingleAlgDataCon_maybe tc
  , isVanillaDataCon con
  = ok_con_args (unitNameSet (getName tc)) con
  | otherwise
  = False

where isVanillaDataCon is defined as:

dcVanilla :: Bool,
-- True <=> This is a vanilla Haskell 98 data constructor
--          Its type is of form
--              forall a1..an . t1 -> ... tm -> T a1..an
--          No existentials, no coercions, nothing.

There's no explanation why this limitation is introduced; it might be
just a conservative one.

On 20/01/15 15:08, Nicholas Clarke wrote:
> I'd like to be able to use the UNPACK pragma on an existentially
> quantified datatype. So as in the below example:
> 
> {-# LANGUAGE ExistentialQuantification #-}
> 
> data Foo = forall a. Show a => Foo !a
> instance Show Foo where
>   show (Foo a) = "Foo! " ++ show a
> 
> data Bar =
>     Bar {-# UNPACK #-} !Foo
>   deriving (Show)
> 
> main :: IO ()
> main = do
>   let foo = Foo "Hello"
>       bar = Bar foo
>   print bar
> 
> I would expect the `Foo` constructor to be unpacked into Bar, as if I
> had written:
> 
> data Bar = forall a. Show a => Bar !a
> 
> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
> argument of ?Bar?' warning. Is there a reason this shouldn't work, or a
> workaround to get it to do so?


From mike at proclivis.com  Tue Jan 20 15:49:06 2015
From: mike at proclivis.com (Michael Jones)
Date: Tue, 20 Jan 2015 08:49:06 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <54BCDE7F.6050908@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
Message-ID: <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>

Simon,

This was fixed some time back. I combed the code base looking for other busy loops and there are no more. I commented out the code that runs the I2C + Machines + IO stuff, and only left the GUI code. It appears that just the wxhaskell part of the program fails to start. This matches a previous observation based on printing.

I?ll see if I can hack up the code to a minimal set that I can publish. All the IP is in the I2C code, so I might be able to get it down to one file.

Mike

On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> Hi Michael,
> 
> Previously in this thread it was pointed out that your code was doing busy waiting, and so the problem can be fixed by modifying your code to not do busy waiting.  Did you do this?  The -C flag is just a workaround which will make the RTS reschedule more often, it won't fix the underlying problem.
> 
> The code you showed us was:
> 
> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
> sendTransactions dev dts = repeatedly $ do
>  dts' <- liftIO $ atomically $ readTVar dts
>  when (dts' == True) (do
>      (_, transactions) <- await
>      liftIO $ sendOut dev transactions)
> 
> This loops when the contents of the TVar is False.
> 
> Cheers,
> Simon
> 
> On 18/01/2015 01:15, Michael Jones wrote:
>> I have narrowed down the problem a bit. It turns out that many times if
>> I run the program and wait long enough, it will start. Given an event
>> log, it may take from 1000-10000 entries sometimes.
>> 
>> When I look at a good start vs. slow start, I see that in both cases
>> things startup and there is some thread activity for thread 2 and 3,
>> then the application starts creating other threads, which is when the
>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>> it just gets stuck on thread 2/3 activity for a very long time.
>> 
>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>> that most starts result in an immediate GUI and i2c IO.
>> 
>> The behavior suggests to me that some initial threads are starving the
>> ability for other threads to start, and perhaps on a dual core machine
>> it is more of a problem than single or quad core machines. For certain,
>> due to some printing, I know that the main thread is starting, and that
>> a print just before the first fork is not printing. Code between them is
>> evaluating wxhaskell functions, but the main frame is not yet asked to
>> become visible. From last week, I know that an non-gui version of the
>> app is getting stuck, but I do not know if it eventually runs like this
>> case.
>> 
>> Is there some convention that when I look at an event log you can tell
>> which threads are OS threads vs threads from fork?
>> 
>> Perhaps someone that knows the scheduler might have some advice. It
>> seems odd that a scheduler could behave this way. The scheduler should
>> have some built in notion of fairness.
>> 
>> 
>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>> <mailto:mike at proclivis.com>> wrote:
>> 
>>> Sorry I am reviving an old problem, but it has resurfaced, such that
>>> one system behaves different than another.
>>> 
>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>>> something bad is going on. In summary, the same code that runs on two
>>> machines does not run on a third machine. So this indicates I have not
>>> made any breaking changes to the code or cabal files. Compiling with
>>> GHC 7.8.3.
>>> 
>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>> the application runs. It has bad timing properties, but it does at
>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>> GUI thread.
>>> 
>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>> tries, so fail means fail most but not all of the time. When it did
>>> run, it continued to run properly. This perhaps indicates some kind of
>>> internal race condition.
>>> 
>>> In the fail to run case, it does some printing up to the point where
>>> it tries to create a wxHaskell frame. In another non-UI version of the
>>> program it also fails to run. Logging to a file gives a similar
>>> indication. It is clear that the program starts up, then fails during
>>> the run in some form of lockup, well after the initial startup code.
>>> 
>>> If I run with the strace command, it always runs with -C0.00N.
>>> 
>>> All the above was done with profiling enabled, so I removed that and
>>> instead enabled eventlog to look for clues.
>>> 
>>> In this case it lies between good and bad, in that IO to my USB is
>>> working, but the GUI comes up blank and never paints. Running this
>>> case without -v0 (event log) the gui partially paints and stops, but
>>> USB continues.
>>> 
>>> Questions:
>>> 
>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>> kinds of scheduling/thread problems?
>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>> wxHaskell IO that leads to problems that a pure calculation app would
>>> not have?
>>> 3) Any ideas how to track down the problem when changing conditions
>>> (compiler or runtime options) affects behavior?
>>> 4) Are there other options besides -V and -C for the runtime that
>>> might apply?
>>> 5) What does -V0 do that makes a problem program run?
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>> <mailto:mike at proclivis.com>> wrote:
>>> 
>>>> John,
>>>> 
>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>> more like -N4.
>>>> 
>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>> Atom and was stuck.
>>>> 
>>>> Mike
>>>> 
>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>> <mailto:jwlato at gmail.com>> wrote:
>>>> 
>>>>> By any chance do the delays get shorter if you run your program with
>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>> thread scheduler.
>>>>> 
>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>> 
>>>>>    I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>> 
>>>>>    I moved from 7.6 to 7.8 and my application behaves very
>>>>>    differently. I have three threads, an application thread that
>>>>>    plots data with wxhaskell or sends it over a network (depends on
>>>>>    settings), a thread doing usb bulk writes, and a thread doing
>>>>>    usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>    used for coordination.
>>>>> 
>>>>>    When the application was compiled with 7.6, my stream of usb
>>>>>    traffic was smooth. With 7.8, there are lots of delays where
>>>>>    nothing seems to be running. These delays are up to 40ms,
>>>>>    whereas with 7.6 delays were a 1ms or so.
>>>>> 
>>>>>    When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>    runs fine without with -N2/4.
>>>>> 
>>>>>    The program is compiled -O2 with profiling. The -N2/4 version
>>>>>    uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>>    is no space leak.
>>>>> 
>>>>>    I tired to compile and use -ls so I could take a look with
>>>>>    threadscope, but the application hangs and writes no data to the
>>>>>    file. The CPU fans run wild like it is in an infinite loop. It
>>>>>    at least pops an unpainted wxhaskell window, so it got partially
>>>>>    running.
>>>>> 
>>>>>    One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>    around the compiler.
>>>>> 
>>>>>    What do I need to know about changes to threading and event
>>>>>    logging between 7.6 and 7.8? Is there some general documentation
>>>>>    somewhere that might help?
>>>>> 
>>>>>    I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>    ball and installed myself, after removing 7.6 with apt-get.
>>>>> 
>>>>>    Any hints appreciated.
>>>>> 
>>>>>    Mike
>>>>> 
>>>>> 
>>>>>    _______________________________________________
>>>>>    Glasgow-haskell-users mailing list
>>>>>    Glasgow-haskell-users at haskell.org
>>>>>    <mailto:Glasgow-haskell-users at haskell.org>
>>>>>    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>> 
>>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> <mailto:Glasgow-haskell-users at haskell.org>
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



From marlowsd at gmail.com  Tue Jan 20 16:00:08 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 20 Jan 2015 16:00:08 +0000
Subject: Thread behavior in 7.8.3
In-Reply-To: <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
Message-ID: <54BE7B88.5000209@gmail.com>

My guess would be that either
  - a thread is in a non-allocating loop
  - a long-running foreign call is marked unsafe

Either of these would block the other threads.  ThreadScope together 
with some traceEventIO calls might help you identify the culprit.

Cheers,
Simon

On 20/01/2015 15:49, Michael Jones wrote:
> Simon,
>
> This was fixed some time back. I combed the code base looking for other busy loops and there are no more. I commented out the code that runs the I2C + Machines + IO stuff, and only left the GUI code. It appears that just the wxhaskell part of the program fails to start. This matches a previous observation based on printing.
>
> I?ll see if I can hack up the code to a minimal set that I can publish. All the IP is in the I2C code, so I might be able to get it down to one file.
>
> Mike
>
> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> Hi Michael,
>>
>> Previously in this thread it was pointed out that your code was doing busy waiting, and so the problem can be fixed by modifying your code to not do busy waiting.  Did you do this?  The -C flag is just a workaround which will make the RTS reschedule more often, it won't fix the underlying problem.
>>
>> The code you showed us was:
>>
>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
>> sendTransactions dev dts = repeatedly $ do
>>   dts' <- liftIO $ atomically $ readTVar dts
>>   when (dts' == True) (do
>>       (_, transactions) <- await
>>       liftIO $ sendOut dev transactions)
>>
>> This loops when the contents of the TVar is False.
>>
>> Cheers,
>> Simon
>>
>> On 18/01/2015 01:15, Michael Jones wrote:
>>> I have narrowed down the problem a bit. It turns out that many times if
>>> I run the program and wait long enough, it will start. Given an event
>>> log, it may take from 1000-10000 entries sometimes.
>>>
>>> When I look at a good start vs. slow start, I see that in both cases
>>> things startup and there is some thread activity for thread 2 and 3,
>>> then the application starts creating other threads, which is when the
>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>>> it just gets stuck on thread 2/3 activity for a very long time.
>>>
>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>>> that most starts result in an immediate GUI and i2c IO.
>>>
>>> The behavior suggests to me that some initial threads are starving the
>>> ability for other threads to start, and perhaps on a dual core machine
>>> it is more of a problem than single or quad core machines. For certain,
>>> due to some printing, I know that the main thread is starting, and that
>>> a print just before the first fork is not printing. Code between them is
>>> evaluating wxhaskell functions, but the main frame is not yet asked to
>>> become visible. From last week, I know that an non-gui version of the
>>> app is getting stuck, but I do not know if it eventually runs like this
>>> case.
>>>
>>> Is there some convention that when I look at an event log you can tell
>>> which threads are OS threads vs threads from fork?
>>>
>>> Perhaps someone that knows the scheduler might have some advice. It
>>> seems odd that a scheduler could behave this way. The scheduler should
>>> have some built in notion of fairness.
>>>
>>>
>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>>> <mailto:mike at proclivis.com>> wrote:
>>>
>>>> Sorry I am reviving an old problem, but it has resurfaced, such that
>>>> one system behaves different than another.
>>>>
>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>>>> something bad is going on. In summary, the same code that runs on two
>>>> machines does not run on a third machine. So this indicates I have not
>>>> made any breaking changes to the code or cabal files. Compiling with
>>>> GHC 7.8.3.
>>>>
>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>>> the application runs. It has bad timing properties, but it does at
>>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>>> GUI thread.
>>>>
>>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>>> tries, so fail means fail most but not all of the time. When it did
>>>> run, it continued to run properly. This perhaps indicates some kind of
>>>> internal race condition.
>>>>
>>>> In the fail to run case, it does some printing up to the point where
>>>> it tries to create a wxHaskell frame. In another non-UI version of the
>>>> program it also fails to run. Logging to a file gives a similar
>>>> indication. It is clear that the program starts up, then fails during
>>>> the run in some form of lockup, well after the initial startup code.
>>>>
>>>> If I run with the strace command, it always runs with -C0.00N.
>>>>
>>>> All the above was done with profiling enabled, so I removed that and
>>>> instead enabled eventlog to look for clues.
>>>>
>>>> In this case it lies between good and bad, in that IO to my USB is
>>>> working, but the GUI comes up blank and never paints. Running this
>>>> case without -v0 (event log) the gui partially paints and stops, but
>>>> USB continues.
>>>>
>>>> Questions:
>>>>
>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>>> kinds of scheduling/thread problems?
>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>>> wxHaskell IO that leads to problems that a pure calculation app would
>>>> not have?
>>>> 3) Any ideas how to track down the problem when changing conditions
>>>> (compiler or runtime options) affects behavior?
>>>> 4) Are there other options besides -V and -C for the runtime that
>>>> might apply?
>>>> 5) What does -V0 do that makes a problem program run?
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>>
>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>>> <mailto:mike at proclivis.com>> wrote:
>>>>
>>>>> John,
>>>>>
>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>>> more like -N4.
>>>>>
>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>>> Atom and was stuck.
>>>>>
>>>>> Mike
>>>>>
>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>>> <mailto:jwlato at gmail.com>> wrote:
>>>>>
>>>>>> By any chance do the delays get shorter if you run your program with
>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>>> thread scheduler.
>>>>>>
>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>
>>>>>>     I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>>>
>>>>>>     I moved from 7.6 to 7.8 and my application behaves very
>>>>>>     differently. I have three threads, an application thread that
>>>>>>     plots data with wxhaskell or sends it over a network (depends on
>>>>>>     settings), a thread doing usb bulk writes, and a thread doing
>>>>>>     usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>>     used for coordination.
>>>>>>
>>>>>>     When the application was compiled with 7.6, my stream of usb
>>>>>>     traffic was smooth. With 7.8, there are lots of delays where
>>>>>>     nothing seems to be running. These delays are up to 40ms,
>>>>>>     whereas with 7.6 delays were a 1ms or so.
>>>>>>
>>>>>>     When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>>     runs fine without with -N2/4.
>>>>>>
>>>>>>     The program is compiled -O2 with profiling. The -N2/4 version
>>>>>>     uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>>>     is no space leak.
>>>>>>
>>>>>>     I tired to compile and use -ls so I could take a look with
>>>>>>     threadscope, but the application hangs and writes no data to the
>>>>>>     file. The CPU fans run wild like it is in an infinite loop. It
>>>>>>     at least pops an unpainted wxhaskell window, so it got partially
>>>>>>     running.
>>>>>>
>>>>>>     One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>>     around the compiler.
>>>>>>
>>>>>>     What do I need to know about changes to threading and event
>>>>>>     logging between 7.6 and 7.8? Is there some general documentation
>>>>>>     somewhere that might help?
>>>>>>
>>>>>>     I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>>     ball and installed myself, after removing 7.6 with apt-get.
>>>>>>
>>>>>>     Any hints appreciated.
>>>>>>
>>>>>>     Mike
>>>>>>
>>>>>>
>>>>>>     _______________________________________________
>>>>>>     Glasgow-haskell-users mailing list
>>>>>>     Glasgow-haskell-users at haskell.org
>>>>>>     <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at haskell.org
>>>> <mailto:Glasgow-haskell-users at haskell.org>
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>

From eir at cis.upenn.edu  Tue Jan 20 16:23:56 2015
From: eir at cis.upenn.edu (Richard Eisenberg)
Date: Tue, 20 Jan 2015 09:23:56 -0700
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
In-Reply-To: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
References: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
Message-ID: <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>

After quite a bit of thought, I agree that this is a regression and that the original program should be accepted.

Make a bug report!

Thanks,
Richard

From verteiler at volker-wysk.de  Tue Jan 20 16:28:37 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Tue, 20 Jan 2015 17:28:37 +0100
Subject: Package version question with Cabal
In-Reply-To: <CAKFCL4WmhjmzbZQJfkBgUrhzsWAfxzhykbj_-ZRRGVH8DacrJw@mail.gmail.com>
References: <1871694.ATtXvhJ6tZ@debian>
 <CAKFCL4WmhjmzbZQJfkBgUrhzsWAfxzhykbj_-ZRRGVH8DacrJw@mail.gmail.com>
Message-ID: <11953569.UK6BFZdD5V@debian>

Am Montag, 19. Januar 2015, 23:32:09 schrieben Sie:
> On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk <verteiler at volker-wysk.de>
> 
> wrote:
> > I've uploaded my library to Hackage, and now I'm trying to install it via
> > cabal:
> At a guess, the index has not yet been updated --- you may need to wait
> some time (might be as short as an hour) before trying to install it from
> Hackage.
> 
> You also need to run "cabal update" to download the updated package index
> so your local cabal-install knows about the new package.

I'm not completely sure what happened, but now it seems to work. The "Default 
available version" is the latest one. Looks like you have been right. Thanx.

Volker

From ekmett at gmail.com  Tue Jan 20 16:34:56 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 11:34:56 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAPY+ZdRC0FoGTvAqkKiRys5M=aM9+-x3=4FeQVtr2fmKD43-LA@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CAPY+ZdRC0FoGTvAqkKiRys5M=aM9+-x3=4FeQVtr2fmKD43-LA@mail.gmail.com>
Message-ID: <CAJumaK_tXuGWcVNVWPsgRy3_Kdp1ZkPyu_ciCRY89NRtYYFZ=g@mail.gmail.com>

On Tue, Jan 20, 2015 at 9:00 AM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:

>

> There are few reports because the change hasn't affected the dark majority
> yet. RC builds are used by a tiny fraction. There's a long tail of users
> still on 7.6, 7.4, 7.2, and 6.x.
>

We've been actively testing since the first time we had a usable
implementation of both the Foldable/Traversable proposal and AMP. Very
large chunks of hackage have been built in house with hand-patched
upstreams to maximize how much of it we can build and we've been using that
to try to minimize impact. Herbert has been hard at work on this for six
months now.

It was known going in that there'd be some broken eggs, and that there'd be
a large number of details to figure out, so Simon formed the core libraries
committee in part to have someone responsible for making decisions around
situations like this.

Far and away the greatest contributing factor to build failures in 7.10 is
the AMP. More code is broken by the import of (<*>) in Applicative alone.
As in, going into the same release, the Foldable/Traversable changes barely
blip the build-failure radar, by a factor of 50 compared to AMP-induced
failures.

The whack-a-mole game needs only to be played once and the results shared
> among those relying on the abstractions. Was that route ever explored?
>

Yes. You could say that this is precisely what we've been doing since 2008.
We've had a dozen or so alternate preludes. Nobody wants the extra build
dependency or per module setup cost. We've had a proposal to eliminate the
Prelude entirely by Igloo, to make it so if you import Prelude.Foo you'd
get that Prelude and not the other. I also spent much of 2014 going around
to every Haskell meetup I could make it to around the world looking for
more direct feedback from folks. The list goes on of options that have been
put on the table.

It does nothing to stem the tide of users who reinvent these abstractions,
or who by dint of the undiscoverability of the current API never find out
about it. The classy-prelude for instance when it was first released didn't
know that there was any pre-existing relationship between virtually all the
combinators it offered and split things up into dozens of classes.

A separate Prelude doesn't address the fact that the limited versions of
these functions are re-exported over and over across dozens of other
modules within base and without.

To that end we had a proposal. It had the most feedback of any proposal
ever put forth on the libraries mailing list, but it went through with
something like 90% approval. I'm not one to speak of "mandates from the
people", but if anything ever came close, that sounds like one to me.

The FTP discussion needs to be re-opened. And it will be, eventually.
>

That statement needs some seriously sinister music. ;)

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/4cf352c7/attachment.html>

From vogt.adam at gmail.com  Tue Jan 20 16:42:41 2015
From: vogt.adam at gmail.com (adam vogt)
Date: Tue, 20 Jan 2015 11:42:41 -0500
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
In-Reply-To: <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
References: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
 <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
Message-ID: <CAHfjoWkMNZOdxpuQwjcLhsVtS0Afs-3f958qO_rKg+fvwC-mpQ@mail.gmail.com>

I've added it as https://ghc.haskell.org/trac/ghc/ticket/10009

On Tue, Jan 20, 2015 at 11:23 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> After quite a bit of thought, I agree that this is a regression and that the original program should be accepted.
>
> Make a bug report!
>
> Thanks,
> Richard

From verteiler at volker-wysk.de  Tue Jan 20 18:36:09 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Tue, 20 Jan 2015 19:36:09 +0100
Subject: "Found hole"
Message-ID: <4314332.VFU07dKVqU@debian>

Hello!

What is a "hole"? 

This program fails to compile:

main = _exit 0

I get this error message:

ex.hs:1:8:
    Found hole ?_exit? with type: t
    Where: ?t? is a rigid type variable bound by
               the inferred type of main :: t at ex.hs:1:1
    Relevant bindings include main :: t (bound at ex.hs:1:1)
    In the expression: _exit
    In an equation for ?main?: main = _exit

When I replace "_exit" with "foo", it produces a "not in scope" error, as 
expected. What is special about "_exit"? It doesn't occur in the Haskell 
Hierarchical Libraries.

Bye
Volker


From allbery.b at gmail.com  Tue Jan 20 18:44:01 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Tue, 20 Jan 2015 13:44:01 -0500
Subject: "Found hole"
In-Reply-To: <4314332.VFU07dKVqU@debian>
References: <4314332.VFU07dKVqU@debian>
Message-ID: <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>

On Tue, Jan 20, 2015 at 1:36 PM, Volker Wysk <verteiler at volker-wysk.de>
wrote:

> What is a "hole"?


https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/typed-holes.html

When I replace "_exit" with "foo", it produces a "not in scope" error, as
> expected. What is special about "_exit"? It doesn't occur in the Haskell
> Hierarchical Libraries.
>

The leading underscore invokes the typed holes extension. If you want to
use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
of the source file. (I am not sure why this extension was enabled by
default.)

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/951f80a6/attachment.html>

From ezyang at mit.edu  Tue Jan 20 18:46:32 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 20 Jan 2015 10:46:32 -0800
Subject: "Found hole"
In-Reply-To: <4314332.VFU07dKVqU@debian>
References: <4314332.VFU07dKVqU@debian>
Message-ID: <1421779560-sup-5338@sabre>

Hello Volker,

All identifiers prefixed with an underscore are "typed holes",
see:
https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/typed-holes.html

Edward

Excerpts from Volker Wysk's message of 2015-01-20 10:36:09 -0800:
> Hello!
> 
> What is a "hole"? 
> 
> This program fails to compile:
> 
> main = _exit 0
> 
> I get this error message:
> 
> ex.hs:1:8:
>     Found hole ?_exit? with type: t
>     Where: ?t? is a rigid type variable bound by
>                the inferred type of main :: t at ex.hs:1:1
>     Relevant bindings include main :: t (bound at ex.hs:1:1)
>     In the expression: _exit
>     In an equation for ?main?: main = _exit
> 
> When I replace "_exit" with "foo", it produces a "not in scope" error, as 
> expected. What is special about "_exit"? It doesn't occur in the Haskell 
> Hierarchical Libraries.
> 
> Bye
> Volker
> 

From goodingm at gmail.com  Tue Jan 20 18:47:09 2015
From: goodingm at gmail.com (htebalaka)
Date: Tue, 20 Jan 2015 11:47:09 -0700 (MST)
Subject: "Found hole"
In-Reply-To: <4314332.VFU07dKVqU@debian>
References: <4314332.VFU07dKVqU@debian>
Message-ID: <1421779629113-5764057.post@n5.nabble.com>

They are described at these two links:
https://www.haskell.org/haskellwiki/GHC/Typed_holes
https://downloads.haskell.org/~ghc/7.8.1-rc1/docs/html/users_guide/typed-holes.html

Essentially, identifiers that are not otherwise in scope and consist of an
underscore or that have a trailing underscore are treated as holes, for
which you wish to know which type was inferred. Previously you would need to
do something like add a wrong type signature, so that the compiler would
complain that the type you gave doesn't match what it inferred.

Though I get a different error message:

Found hole ?_exit? with type: a0 -> t
    Where: ?a0? is an ambiguous type variable
           ?t? is a rigid type variable bound by

There really should be a Num constraint as well, but at least in 7.8 it
doesn't seem to include those.


Volker Wysk-5 wrote
> Hello!
> 
> What is a "hole"? 
> 
> This program fails to compile:
> 
> main = _exit 0
> 
> I get this error message:
> 
> ex.hs:1:8:
>     Found hole ?_exit? with type: t
>     Where: ?t? is a rigid type variable bound by
>                the inferred type of main :: t at ex.hs:1:1
>     Relevant bindings include main :: t (bound at ex.hs:1:1)
>     In the expression: _exit
>     In an equation for ?main?: main = _exit
> 
> When I replace "_exit" with "foo", it produces a "not in scope" error, as 
> expected. What is special about "_exit"? It doesn't occur in the Haskell 
> Hierarchical Libraries.
> 
> Bye
> Volker
> 
> _______________________________________________
> Glasgow-haskell-users mailing list

> Glasgow-haskell-users@

> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users





--
View this message in context: http://haskell.1045720.n5.nabble.com/Found-hole-tp5764054p5764057.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From verteiler at volker-wysk.de  Tue Jan 20 19:22:53 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Tue, 20 Jan 2015 20:22:53 +0100
Subject: "Found hole"
In-Reply-To: <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
Message-ID: <1612444.cEMbd0gv7n@debian>

Hi!

Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
> The leading underscore invokes the typed holes extension. If you want to
> use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
> of the source file.

I get this error, when I use "{-# LANGUAGE NoTypedHoles #-}":

   ex.hs:1:14: Unsupported extension: NoTypedHoles

I'm using GHC 7.8.3. Could it be that the "NoTypedHoles" extension was added
not before 7.8.4 (the most current version).

Bye
Volker

From ahammel87 at gmail.com  Tue Jan 20 19:25:26 2015
From: ahammel87 at gmail.com (Alex Hammel)
Date: Tue, 20 Jan 2015 11:25:26 -0800
Subject: "Found hole"
In-Reply-To: <1612444.cEMbd0gv7n@debian>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <1612444.cEMbd0gv7n@debian>
Message-ID: <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>

The only reference to a NoTypedHoles extension google can find is this
thread. Odd.

On Tue, Jan 20, 2015 at 11:22 AM, Volker Wysk <verteiler at volker-wysk.de>
wrote:

> Hi!
>
> Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
> > The leading underscore invokes the typed holes extension. If you want to
> > use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first
> line
> > of the source file.
>
> I get this error, when I use "{-# LANGUAGE NoTypedHoles #-}":
>
>    ex.hs:1:14: Unsupported extension: NoTypedHoles
>
> I'm using GHC 7.8.3. Could it be that the "NoTypedHoles" extension was
> added
> not before 7.8.4 (the most current version).
>
> Bye
> Volker
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/8ba47a15/attachment.html>

From david.feuer at gmail.com  Tue Jan 20 19:37:59 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 20 Jan 2015 14:37:59 -0500
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
In-Reply-To: <CAHfjoWkMNZOdxpuQwjcLhsVtS0Afs-3f958qO_rKg+fvwC-mpQ@mail.gmail.com>
References: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
 <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
 <CAHfjoWkMNZOdxpuQwjcLhsVtS0Afs-3f958qO_rKg+fvwC-mpQ@mail.gmail.com>
Message-ID: <CAMgWh9tYUTGYCzBhanVTU5bMU2KaO8oZeijL8gjsVWW-nYCfgQ@mail.gmail.com>

And I've closed it as worksforme. I couldn't reproduce the problem
with 7.11.20150103.

On Tue, Jan 20, 2015 at 11:42 AM, adam vogt <vogt.adam at gmail.com> wrote:
> I've added it as https://ghc.haskell.org/trac/ghc/ticket/10009
>
> On Tue, Jan 20, 2015 at 11:23 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>> After quite a bit of thought, I agree that this is a regression and that the original program should be accepted.
>>
>> Make a bug report!
>>
>> Thanks,
>> Richard
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From ahammel87 at gmail.com  Tue Jan 20 20:39:55 2015
From: ahammel87 at gmail.com (Alex Hammel)
Date: Tue, 20 Jan 2015 12:39:55 -0800
Subject: "Found hole"
In-Reply-To: <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <1612444.cEMbd0gv7n@debian>
 <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>
Message-ID: <CA+_xFer3gWWC3ncBbnbJsfOOFVt3W4YjOg9hHp9XyVAxTOs9sg@mail.gmail.com>

You can get typed holes to compile with a warning and a runtime error with
the -fdefer-type-errors flag, if that's what you want.

However, it's perfectly legal to use identifiers which look like typed
holes. This works fine on 7.8.3ghc:

_exit = print
main = _exit 0

On Tue, Jan 20, 2015 at 11:25 AM, Alex Hammel <ahammel87 at gmail.com> wrote:

> The only reference to a NoTypedHoles extension google can find is this
> thread. Odd.
>
> On Tue, Jan 20, 2015 at 11:22 AM, Volker Wysk <verteiler at volker-wysk.de>
> wrote:
>
>> Hi!
>>
>> Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
>> > The leading underscore invokes the typed holes extension. If you want to
>> > use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first
>> line
>> > of the source file.
>>
>> I get this error, when I use "{-# LANGUAGE NoTypedHoles #-}":
>>
>>    ex.hs:1:14: Unsupported extension: NoTypedHoles
>>
>> I'm using GHC 7.8.3. Could it be that the "NoTypedHoles" extension was
>> added
>> not before 7.8.4 (the most current version).
>>
>> Bye
>> Volker
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/297ace3e/attachment.html>

From david.feuer at gmail.com  Tue Jan 20 20:46:20 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 20 Jan 2015 15:46:20 -0500
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
In-Reply-To: <CAMgWh9tYUTGYCzBhanVTU5bMU2KaO8oZeijL8gjsVWW-nYCfgQ@mail.gmail.com>
References: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
 <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
 <CAHfjoWkMNZOdxpuQwjcLhsVtS0Afs-3f958qO_rKg+fvwC-mpQ@mail.gmail.com>
 <CAMgWh9tYUTGYCzBhanVTU5bMU2KaO8oZeijL8gjsVWW-nYCfgQ@mail.gmail.com>
Message-ID: <CAMgWh9sJKVkN==8L4-XneQgW=8sj_KWkCgjr0sVbHO1A4J2arA@mail.gmail.com>

Wrongly, as it turned out. Sorry! The problem remains.

On Tue, Jan 20, 2015 at 2:37 PM, David Feuer <david.feuer at gmail.com> wrote:
> And I've closed it as worksforme. I couldn't reproduce the problem
> with 7.11.20150103.
>
> On Tue, Jan 20, 2015 at 11:42 AM, adam vogt <vogt.adam at gmail.com> wrote:
>> I've added it as https://ghc.haskell.org/trac/ghc/ticket/10009
>>
>> On Tue, Jan 20, 2015 at 11:23 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
>>> After quite a bit of thought, I agree that this is a regression and that the original program should be accepted.
>>>
>>> Make a bug report!
>>>
>>> Thanks,
>>> Richard
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From migmit at gmail.com  Tue Jan 20 20:51:32 2015
From: migmit at gmail.com (migmit)
Date: Tue, 20 Jan 2015 21:51:32 +0100
Subject: "Found hole"
In-Reply-To: <CA+_xFer3gWWC3ncBbnbJsfOOFVt3W4YjOg9hHp9XyVAxTOs9sg@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <1612444.cEMbd0gv7n@debian>
 <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>
 <CA+_xFer3gWWC3ncBbnbJsfOOFVt3W4YjOg9hHp9XyVAxTOs9sg@mail.gmail.com>
Message-ID: <53341255-5B84-4D8B-940D-8736E6CA93E8@gmail.com>

DON'T DO THAT!

Seriously, turn off compile-time type checking completely just to start an identifier with an underscore???

?????????? ? iPad

> 20 ???. 2015 ?., ? 21:39, Alex Hammel <ahammel87 at gmail.com> ???????(?):
> 
> You can get typed holes to compile with a warning and a runtime error with the -fdefer-type-errors flag, if that's what you want.
> 
> However, it's perfectly legal to use identifiers which look like typed holes. This works fine on 7.8.3ghc:
> 
> _exit = print
> main = _exit 0
> 
>> On Tue, Jan 20, 2015 at 11:25 AM, Alex Hammel <ahammel87 at gmail.com> wrote:
>> The only reference to a NoTypedHoles extension google can find is this thread. Odd.
>> 
>>> On Tue, Jan 20, 2015 at 11:22 AM, Volker Wysk <verteiler at volker-wysk.de> wrote:
>>> Hi!
>>> 
>>> Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
>>> > The leading underscore invokes the typed holes extension. If you want to
>>> > use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
>>> > of the source file.
>>> 
>>> I get this error, when I use "{-# LANGUAGE NoTypedHoles #-}":
>>> 
>>>    ex.hs:1:14: Unsupported extension: NoTypedHoles
>>> 
>>> I'm using GHC 7.8.3. Could it be that the "NoTypedHoles" extension was added
>>> not before 7.8.4 (the most current version).
>>> 
>>> Bye
>>> Volker
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/28287f5e/attachment.html>

From david.feuer at gmail.com  Tue Jan 20 21:01:19 2015
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 20 Jan 2015 16:01:19 -0500
Subject: "Found hole"
In-Reply-To: <53341255-5B84-4D8B-940D-8736E6CA93E8@gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <1612444.cEMbd0gv7n@debian>
 <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>
 <CA+_xFer3gWWC3ncBbnbJsfOOFVt3W4YjOg9hHp9XyVAxTOs9sg@mail.gmail.com>
 <53341255-5B84-4D8B-940D-8736E6CA93E8@gmail.com>
Message-ID: <CAMgWh9tJnBSxK0aH-P9jOfBzW6w8TQA9CpJdtS8or0TJVj7EPw@mail.gmail.com>

Just use exit_ or something instead. Typed holes are a *really useful*
mechanism.

On Tue, Jan 20, 2015 at 3:51 PM, migmit <migmit at gmail.com> wrote:
> DON'T DO THAT!
>
> Seriously, turn off compile-time type checking completely just to start an
> identifier with an underscore???
>
> ?????????? ? iPad
>
> 20 ???. 2015 ?., ? 21:39, Alex Hammel <ahammel87 at gmail.com> ???????(?):
>
> You can get typed holes to compile with a warning and a runtime error with
> the -fdefer-type-errors flag, if that's what you want.
>
> However, it's perfectly legal to use identifiers which look like typed
> holes. This works fine on 7.8.3ghc:
>
> _exit = print
> main = _exit 0
>
> On Tue, Jan 20, 2015 at 11:25 AM, Alex Hammel <ahammel87 at gmail.com> wrote:
>>
>> The only reference to a NoTypedHoles extension google can find is this
>> thread. Odd.
>>
>> On Tue, Jan 20, 2015 at 11:22 AM, Volker Wysk <verteiler at volker-wysk.de>
>> wrote:
>>>
>>> Hi!
>>>
>>> Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie:
>>> > The leading underscore invokes the typed holes extension. If you want
>>> > to
>>> > use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first
>>> > line
>>> > of the source file.
>>>
>>> I get this error, when I use "{-# LANGUAGE NoTypedHoles #-}":
>>>
>>>    ex.hs:1:14: Unsupported extension: NoTypedHoles
>>>
>>> I'm using GHC 7.8.3. Could it be that the "NoTypedHoles" extension was
>>> added
>>> not before 7.8.4 (the most current version).
>>>
>>> Bye
>>> Volker
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From simonpj at microsoft.com  Tue Jan 20 21:09:17 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 20 Jan 2015 21:09:17 +0000
Subject: ghc-7.10.0 type inference regression when faking injective type
 families
In-Reply-To: <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
References: <CAHfjoW=PB32dZusdLJGd5h+Dg8gqtKE2yTRyZes=3gSCdVCCJA@mail.gmail.com>
 <DE0CBD6B-A01B-4504-B1D8-1AD6208BF22E@cis.upenn.edu>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF562ABEB8@DB3PRD3001MB020.064d.mgd.msft.net>

Yes, I fixed it on the train. Most helpful.  Busy tomorrow but I should have a fix committed by the end of the week

Simon

| -----Original Message-----
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Richard Eisenberg
| Sent: 20 January 2015 16:24
| To: adam vogt
| Cc: Glasgow-Haskell-Users
| Subject: Re: ghc-7.10.0 type inference regression when faking injective
| type families
| 
| After quite a bit of thought, I agree that this is a regression and that
| the original program should be accepted.
| 
| Make a bug report!
| 
| Thanks,
| Richard
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From bos at serpentine.com  Tue Jan 20 22:17:01 2015
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue, 20 Jan 2015 14:17:01 -0800
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
Message-ID: <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>

On Tue, Jan 20, 2015 at 3:45 AM, Edward Kmett <ekmett at gmail.com> wrote:

> Ultimately, there is, of course, a balancing act between flexibility and
> inference.
>
> I can at least say that the incident rate for cases seems to be very low,
> especially when it is contrasted against the pain users have had with using
> the existing Foldable/Traversable imports where virtually everything in
> them collided with less useful versions of the same combinator (e.g. mapM)
> from the Prelude that a dozen other modules (e.g. Control.Monad and
> virtually every module in mtl) insisted on re-exporting, making it a game
> of whack-a-mole to try to hide them.
>

For the record, it took me almost an hour to update attoparsec to fix all
the various regressions, or to put it more charitably changes, introduced
in GHC 7.10. I have twenty-something other packages to go through. I don't
keep track of the time sunk from release to release, but this feels
somewhat worse than average.

Basically, the more careful you are in writing a package, the more each
update of GHC and base costs in nickel-and-dime tweaks to keep a build
clean. It's not a very happy-making feedback loop. "Be a good citizen, and
your reward is to spend *even more* time cleaning up!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/4f74de5a/attachment.html>

From hvr at gnu.org  Tue Jan 20 23:02:48 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 21 Jan 2015 00:02:48 +0100
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 (Bryan O'Sullivan's message of "Tue, 20 Jan 2015 14:17:01 -0800")
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
Message-ID: <878ugxginb.fsf@gnu.org>

Hello Bryan,

On 2015-01-20 at 23:17:01 +0100, Bryan O'Sullivan wrote:

[...]

> For the record, it took me almost an hour to update attoparsec to fix all
> the various regressions, or to put it more charitably changes, introduced
> in GHC 7.10. I have twenty-something other packages to go through. I don't
> keep track of the time sunk from release to release, but this feels
> somewhat worse than average.

I'm a bit confused, several past attoparsec versions seem to build just
fine with GHC 7.10:

  https://ghc.haskell.org/~hvr/buildreports/attoparsec.html

were there hidden breakages not resulting in compile errors?
Or are the fixes you mention about restoring -Wall hygiene?

> Basically, the more careful you are in writing a package, the more each
> update of GHC and base costs in nickel-and-dime tweaks to keep a build
> clean. It's not a very happy-making feedback loop. "Be a good citizen, and
> your reward is to spend *even more* time cleaning up!"

Cheers,
  hvr

From goodingm at gmail.com  Tue Jan 20 23:11:58 2015
From: goodingm at gmail.com (htebalaka)
Date: Tue, 20 Jan 2015 16:11:58 -0700 (MST)
Subject: "Found hole"
In-Reply-To: <CAMgWh9tJnBSxK0aH-P9jOfBzW6w8TQA9CpJdtS8or0TJVj7EPw@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <1612444.cEMbd0gv7n@debian>
 <CA+_xFeojuH-n4+jn+D-YPKrn5H2KLFNVoUe62QW1-xN+KDjvcw@mail.gmail.com>
 <CA+_xFer3gWWC3ncBbnbJsfOOFVt3W4YjOg9hHp9XyVAxTOs9sg@mail.gmail.com>
 <53341255-5B84-4D8B-940D-8736E6CA93E8@gmail.com>
 <CAMgWh9tJnBSxK0aH-P9jOfBzW6w8TQA9CpJdtS8or0TJVj7EPw@mail.gmail.com>
Message-ID: <1421795518275-5764081.post@n5.nabble.com>

Unless it behaves differently in GHC than GHCi, you can still use underscore
prefixed identifiers, provided they are in scope. I only get a type hole
message if the identifier isn't defined anywhere else.

>> let _x = 2
>> _x
2
>> _y
Found hole '_y' with type: t
...



--
View this message in context: http://haskell.1045720.n5.nabble.com/Found-hole-tp5764054p5764081.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From bos at serpentine.com  Tue Jan 20 23:12:02 2015
From: bos at serpentine.com (Bryan O'Sullivan)
Date: Tue, 20 Jan 2015 15:12:02 -0800
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <878ugxginb.fsf@gnu.org>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
Message-ID: <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>

On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <hvr at gnu.org> wrote:

> I'm a bit confused, several past attoparsec versions seem to build just
> fine with GHC 7.10:
>
>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
>
> were there hidden breakages not resulting in compile errors?
> Or are the fixes you mention about restoring -Wall hygiene?
>

I build with -Wall -Werror, and also have to maintain the test and
benchmark suites.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/0a10eff9/attachment.html>

From ekmett at gmail.com  Tue Jan 20 23:22:57 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 18:22:57 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
Message-ID: <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>

Building -Wall clean across this change-over has a big of a trick to it.

The easiest way I know of when folks already had lots of

import Data.Foldable
import Data.Traversable

stuff

is to just add

import Prelude

explicitly to the bottom of your import list rather than painstakingly
exclude the imports with CPP.

This has the benefit of not needing a bunch of CPP to manage what names
come from where.

Why? GHC checks that the imports provide something 'new' that is used by
the module in a top-down fashion, and you are almost suredly using
something from Prelude that didn't come from one of the modules above.

On the other hand the implicit import of Prelude effectively would come
first in the list.

It is a dirty trick, but it does neatly side-step this problem for folks in
your situation.

-Edward

On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <bos at serpentine.com>
wrote:

>
> On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <hvr at gnu.org>
> wrote:
>
>> I'm a bit confused, several past attoparsec versions seem to build just
>> fine with GHC 7.10:
>>
>>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
>>
>> were there hidden breakages not resulting in compile errors?
>> Or are the fixes you mention about restoring -Wall hygiene?
>>
>
> I build with -Wall -Werror, and also have to maintain the test and
> benchmark suites.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/afe18e28/attachment.html>

From ezyang at mit.edu  Tue Jan 20 23:27:39 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 20 Jan 2015 15:27:39 -0800
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
Message-ID: <1421796438-sup-4859@sabre>

Hello Edward,

Shouldn't we publicize this trick? Perhaps in the changelog?

Edward

Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> Building -Wall clean across this change-over has a big of a trick to it.
> 
> The easiest way I know of when folks already had lots of
> 
> import Data.Foldable
> import Data.Traversable
> 
> stuff
> 
> is to just add
> 
> import Prelude
> 
> explicitly to the bottom of your import list rather than painstakingly
> exclude the imports with CPP.
> 
> This has the benefit of not needing a bunch of CPP to manage what names
> come from where.
> 
> Why? GHC checks that the imports provide something 'new' that is used by
> the module in a top-down fashion, and you are almost suredly using
> something from Prelude that didn't come from one of the modules above.
> 
> On the other hand the implicit import of Prelude effectively would come
> first in the list.
> 
> It is a dirty trick, but it does neatly side-step this problem for folks in
> your situation.
> 
> -Edward
> 
> On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <bos at serpentine.com>
> wrote:
> 
> >
> > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <hvr at gnu.org>
> > wrote:
> >
> >> I'm a bit confused, several past attoparsec versions seem to build just
> >> fine with GHC 7.10:
> >>
> >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> >>
> >> were there hidden breakages not resulting in compile errors?
> >> Or are the fixes you mention about restoring -Wall hygiene?
> >>
> >
> > I build with -Wall -Werror, and also have to maintain the test and
> > benchmark suites.
> >

From ekmett at gmail.com  Tue Jan 20 23:41:13 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 18:41:13 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <1421796438-sup-4859@sabre>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
Message-ID: <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>

Sure.

Adding it to the CHANGELOG makes a lot of sense. I first found out about it
only a few weeks ago when Herbert mentioned it in passing.

Of course, the geek in me definitely prefers technical fixes to human ones.
Humans are messy. =)

I'd be curious how much of the current suite of warnings could be fixed
just by switching the implicit Prelude import to the end of the import list
inside GHC.

Now that Herbert has all of his crazy tooling to build stuff with 7.10 and
with HEAD, it might be worth trying out such a change to see how much it
reduces the warning volume and if it somehow manages to introduce any new
warnings.

I hesitate to make such a proposal this late in the release candidate game,
but if it worked it'd be pretty damn compelling.

-Edward



On Tue, Jan 20, 2015 at 6:27 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Hello Edward,
>
> Shouldn't we publicize this trick? Perhaps in the changelog?
>
> Edward
>
> Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> > Building -Wall clean across this change-over has a big of a trick to it.
> >
> > The easiest way I know of when folks already had lots of
> >
> > import Data.Foldable
> > import Data.Traversable
> >
> > stuff
> >
> > is to just add
> >
> > import Prelude
> >
> > explicitly to the bottom of your import list rather than painstakingly
> > exclude the imports with CPP.
> >
> > This has the benefit of not needing a bunch of CPP to manage what names
> > come from where.
> >
> > Why? GHC checks that the imports provide something 'new' that is used by
> > the module in a top-down fashion, and you are almost suredly using
> > something from Prelude that didn't come from one of the modules above.
> >
> > On the other hand the implicit import of Prelude effectively would come
> > first in the list.
> >
> > It is a dirty trick, but it does neatly side-step this problem for folks
> in
> > your situation.
> >
> > -Edward
> >
> > On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <bos at serpentine.com>
> > wrote:
> >
> > >
> > > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <hvr at gnu.org>
> > > wrote:
> > >
> > >> I'm a bit confused, several past attoparsec versions seem to build
> just
> > >> fine with GHC 7.10:
> > >>
> > >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> > >>
> > >> were there hidden breakages not resulting in compile errors?
> > >> Or are the fixes you mention about restoring -Wall hygiene?
> > >>
> > >
> > > I build with -Wall -Werror, and also have to maintain the test and
> > > benchmark suites.
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/790df7f9/attachment.html>

From ezyang at mit.edu  Tue Jan 20 23:47:06 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 20 Jan 2015 15:47:06 -0800
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
 <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>
Message-ID: <1421797532-sup-1045@sabre>

I like this proposal: if you're explicit about an import that
would otherwise be implicit by Prelude, you shouldn't get a
warning for it. If it is not already the case, we also need to
make sure the implicit Prelude import never causes "unused import"
errors.

Edward

Excerpts from Edward Kmett's message of 2015-01-20 15:41:13 -0800:
> Sure.
> 
> Adding it to the CHANGELOG makes a lot of sense. I first found out about it
> only a few weeks ago when Herbert mentioned it in passing.
> 
> Of course, the geek in me definitely prefers technical fixes to human ones.
> Humans are messy. =)
> 
> I'd be curious how much of the current suite of warnings could be fixed
> just by switching the implicit Prelude import to the end of the import list
> inside GHC.
> 
> Now that Herbert has all of his crazy tooling to build stuff with 7.10 and
> with HEAD, it might be worth trying out such a change to see how much it
> reduces the warning volume and if it somehow manages to introduce any new
> warnings.
> 
> I hesitate to make such a proposal this late in the release candidate game,
> but if it worked it'd be pretty damn compelling.
> 
> -Edward
> 
> On Tue, Jan 20, 2015 at 6:27 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > Hello Edward,
> >
> > Shouldn't we publicize this trick? Perhaps in the changelog?
> >
> > Edward
> >
> > Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> > > Building -Wall clean across this change-over has a big of a trick to it.
> > >
> > > The easiest way I know of when folks already had lots of
> > >
> > > import Data.Foldable
> > > import Data.Traversable
> > >
> > > stuff
> > >
> > > is to just add
> > >
> > > import Prelude
> > >
> > > explicitly to the bottom of your import list rather than painstakingly
> > > exclude the imports with CPP.
> > >
> > > This has the benefit of not needing a bunch of CPP to manage what names
> > > come from where.
> > >
> > > Why? GHC checks that the imports provide something 'new' that is used by
> > > the module in a top-down fashion, and you are almost suredly using
> > > something from Prelude that didn't come from one of the modules above.
> > >
> > > On the other hand the implicit import of Prelude effectively would come
> > > first in the list.
> > >
> > > It is a dirty trick, but it does neatly side-step this problem for folks
> > in
> > > your situation.
> > >
> > > -Edward
> > >
> > > On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <bos at serpentine.com>
> > > wrote:
> > >
> > > >
> > > > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <hvr at gnu.org>
> > > > wrote:
> > > >
> > > >> I'm a bit confused, several past attoparsec versions seem to build
> > just
> > > >> fine with GHC 7.10:
> > > >>
> > > >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> > > >>
> > > >> were there hidden breakages not resulting in compile errors?
> > > >> Or are the fixes you mention about restoring -Wall hygiene?
> > > >>
> > > >
> > > > I build with -Wall -Werror, and also have to maintain the test and
> > > > benchmark suites.
> > > >
> >

From ekmett at gmail.com  Tue Jan 20 23:49:08 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 18:49:08 -0500
Subject: "Found hole"
In-Reply-To: <4314332.VFU07dKVqU@debian>
References: <4314332.VFU07dKVqU@debian>
Message-ID: <CAJumaK_3F-mHR0i0nvOvDxxGafxArJdQMLggkbgpE5wksWjakQ@mail.gmail.com>

FWIW- you can think of a 'hole' as a "not in scope" error with a ton of
useful information about the type such a term would have to have in order
to go in the location you referenced it.

This promotes a very useful style of type-driven development that is common
in Agda, where you write out your program and then leave holes that start
with _'s to fill in later.

Since no new programs are accepted or rejected, GHC turned on "holes"
support by default. Users have historically faked this style with
ImplicitParams by labeling their holes ?foo, but that approach doesn't give
any information on what local stuff could be used to plug the hole.

The only thing that changed is the nature of the error message, which
carefully track what variables are in scope, how they are instantiated, and
what type the missing term is used at.

Since libraries like lens were already making heavy use of the _'d
namespace this only happens if the name isn't already in use. This is why
you can define _'d things just fine. The main thing that happened is if you
typo the name of a lens, well, your error messages got even worse. ;)

-Edward

On Tue, Jan 20, 2015 at 1:36 PM, Volker Wysk <verteiler at volker-wysk.de>
wrote:

> Hello!
>
> What is a "hole"?
>
> This program fails to compile:
>
> main = _exit 0
>
> I get this error message:
>
> ex.hs:1:8:
>     Found hole ?_exit? with type: t
>     Where: ?t? is a rigid type variable bound by
>                the inferred type of main :: t at ex.hs:1:1
>     Relevant bindings include main :: t (bound at ex.hs:1:1)
>     In the expression: _exit
>     In an equation for ?main?: main = _exit
>
> When I replace "_exit" with "foo", it produces a "not in scope" error, as
> expected. What is special about "_exit"? It doesn't occur in the Haskell
> Hierarchical Libraries.
>
> Bye
> Volker
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/f97ffe34/attachment.html>

From ekmett at gmail.com  Wed Jan 21 00:36:53 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 19:36:53 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <1421797532-sup-1045@sabre>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
 <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>
 <1421797532-sup-1045@sabre>
Message-ID: <CAJumaK_6PV66v_hNvkC_SN-OAgUz5PZKuioyKBAEq5cL_A8ytA@mail.gmail.com>

It isn't without a cost. On the down-side, the results of
-ddump-minimal-imports would be er.. less minimal.



On Tue, Jan 20, 2015 at 6:47 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> I like this proposal: if you're explicit about an import that
> would otherwise be implicit by Prelude, you shouldn't get a
> warning for it. If it is not already the case, we also need to
> make sure the implicit Prelude import never causes "unused import"
> errors.
>
> Edward
>
> Excerpts from Edward Kmett's message of 2015-01-20 15:41:13 -0800:
> > Sure.
> >
> > Adding it to the CHANGELOG makes a lot of sense. I first found out about
> it
> > only a few weeks ago when Herbert mentioned it in passing.
> >
> > Of course, the geek in me definitely prefers technical fixes to human
> ones.
> > Humans are messy. =)
> >
> > I'd be curious how much of the current suite of warnings could be fixed
> > just by switching the implicit Prelude import to the end of the import
> list
> > inside GHC.
> >
> > Now that Herbert has all of his crazy tooling to build stuff with 7.10
> and
> > with HEAD, it might be worth trying out such a change to see how much it
> > reduces the warning volume and if it somehow manages to introduce any new
> > warnings.
> >
> > I hesitate to make such a proposal this late in the release candidate
> game,
> > but if it worked it'd be pretty damn compelling.
> >
> > -Edward
> >
> > On Tue, Jan 20, 2015 at 6:27 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> > > Hello Edward,
> > >
> > > Shouldn't we publicize this trick? Perhaps in the changelog?
> > >
> > > Edward
> > >
> > > Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> > > > Building -Wall clean across this change-over has a big of a trick to
> it.
> > > >
> > > > The easiest way I know of when folks already had lots of
> > > >
> > > > import Data.Foldable
> > > > import Data.Traversable
> > > >
> > > > stuff
> > > >
> > > > is to just add
> > > >
> > > > import Prelude
> > > >
> > > > explicitly to the bottom of your import list rather than
> painstakingly
> > > > exclude the imports with CPP.
> > > >
> > > > This has the benefit of not needing a bunch of CPP to manage what
> names
> > > > come from where.
> > > >
> > > > Why? GHC checks that the imports provide something 'new' that is
> used by
> > > > the module in a top-down fashion, and you are almost suredly using
> > > > something from Prelude that didn't come from one of the modules
> above.
> > > >
> > > > On the other hand the implicit import of Prelude effectively would
> come
> > > > first in the list.
> > > >
> > > > It is a dirty trick, but it does neatly side-step this problem for
> folks
> > > in
> > > > your situation.
> > > >
> > > > -Edward
> > > >
> > > > On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <
> bos at serpentine.com>
> > > > wrote:
> > > >
> > > > >
> > > > > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <
> hvr at gnu.org>
> > > > > wrote:
> > > > >
> > > > >> I'm a bit confused, several past attoparsec versions seem to build
> > > just
> > > > >> fine with GHC 7.10:
> > > > >>
> > > > >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> > > > >>
> > > > >> were there hidden breakages not resulting in compile errors?
> > > > >> Or are the fixes you mention about restoring -Wall hygiene?
> > > > >>
> > > > >
> > > > > I build with -Wall -Werror, and also have to maintain the test and
> > > > > benchmark suites.
> > > > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/ab593e24/attachment-0001.html>

From ezyang at mit.edu  Wed Jan 21 00:40:52 2015
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 20 Jan 2015 16:40:52 -0800
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <CAJumaK_6PV66v_hNvkC_SN-OAgUz5PZKuioyKBAEq5cL_A8ytA@mail.gmail.com>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
 <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>
 <1421797532-sup-1045@sabre>
 <CAJumaK_6PV66v_hNvkC_SN-OAgUz5PZKuioyKBAEq5cL_A8ytA@mail.gmail.com>
Message-ID: <1421800791-sup-1973@sabre>

I don't see why that would be the case: we haven't *excluded* any
old import lists, so -ddump-minimal-imports could still
take advantage of Prelude in a warning-free way.

Edward

Excerpts from Edward Kmett's message of 2015-01-20 16:36:53 -0800:
> It isn't without a cost. On the down-side, the results of
> -ddump-minimal-imports would be er.. less minimal.
> 
> On Tue, Jan 20, 2015 at 6:47 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > I like this proposal: if you're explicit about an import that
> > would otherwise be implicit by Prelude, you shouldn't get a
> > warning for it. If it is not already the case, we also need to
> > make sure the implicit Prelude import never causes "unused import"
> > errors.
> >
> > Edward
> >
> > Excerpts from Edward Kmett's message of 2015-01-20 15:41:13 -0800:
> > > Sure.
> > >
> > > Adding it to the CHANGELOG makes a lot of sense. I first found out about
> > it
> > > only a few weeks ago when Herbert mentioned it in passing.
> > >
> > > Of course, the geek in me definitely prefers technical fixes to human
> > ones.
> > > Humans are messy. =)
> > >
> > > I'd be curious how much of the current suite of warnings could be fixed
> > > just by switching the implicit Prelude import to the end of the import
> > list
> > > inside GHC.
> > >
> > > Now that Herbert has all of his crazy tooling to build stuff with 7.10
> > and
> > > with HEAD, it might be worth trying out such a change to see how much it
> > > reduces the warning volume and if it somehow manages to introduce any new
> > > warnings.
> > >
> > > I hesitate to make such a proposal this late in the release candidate
> > game,
> > > but if it worked it'd be pretty damn compelling.
> > >
> > > -Edward
> > >
> > > On Tue, Jan 20, 2015 at 6:27 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> > >
> > > > Hello Edward,
> > > >
> > > > Shouldn't we publicize this trick? Perhaps in the changelog?
> > > >
> > > > Edward
> > > >
> > > > Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> > > > > Building -Wall clean across this change-over has a big of a trick to
> > it.
> > > > >
> > > > > The easiest way I know of when folks already had lots of
> > > > >
> > > > > import Data.Foldable
> > > > > import Data.Traversable
> > > > >
> > > > > stuff
> > > > >
> > > > > is to just add
> > > > >
> > > > > import Prelude
> > > > >
> > > > > explicitly to the bottom of your import list rather than
> > painstakingly
> > > > > exclude the imports with CPP.
> > > > >
> > > > > This has the benefit of not needing a bunch of CPP to manage what
> > names
> > > > > come from where.
> > > > >
> > > > > Why? GHC checks that the imports provide something 'new' that is
> > used by
> > > > > the module in a top-down fashion, and you are almost suredly using
> > > > > something from Prelude that didn't come from one of the modules
> > above.
> > > > >
> > > > > On the other hand the implicit import of Prelude effectively would
> > come
> > > > > first in the list.
> > > > >
> > > > > It is a dirty trick, but it does neatly side-step this problem for
> > folks
> > > > in
> > > > > your situation.
> > > > >
> > > > > -Edward
> > > > >
> > > > > On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <
> > bos at serpentine.com>
> > > > > wrote:
> > > > >
> > > > > >
> > > > > > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <
> > hvr at gnu.org>
> > > > > > wrote:
> > > > > >
> > > > > >> I'm a bit confused, several past attoparsec versions seem to build
> > > > just
> > > > > >> fine with GHC 7.10:
> > > > > >>
> > > > > >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> > > > > >>
> > > > > >> were there hidden breakages not resulting in compile errors?
> > > > > >> Or are the fixes you mention about restoring -Wall hygiene?
> > > > > >>
> > > > > >
> > > > > > I build with -Wall -Werror, and also have to maintain the test and
> > > > > > benchmark suites.
> > > > > >
> > > >
> >

From ekmett at gmail.com  Wed Jan 21 00:49:52 2015
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 20 Jan 2015 19:49:52 -0500
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <1421800791-sup-1973@sabre>
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
 <CAJumaK8bGTOadbrfJUxDaUb0H7yUR7TiPUqrYU2wVR8OOjsrHw@mail.gmail.com>
 <1421797532-sup-1045@sabre>
 <CAJumaK_6PV66v_hNvkC_SN-OAgUz5PZKuioyKBAEq5cL_A8ytA@mail.gmail.com>
 <1421800791-sup-1973@sabre>
Message-ID: <CAJumaK-C9W-cOq4B50jxkyY4oMJ+DEWnRUGUXC9bX5znp2cTTw@mail.gmail.com>

I was assuming that the list was generated by doing more or less the same
check we do now. I haven't looked at the code for it.

If so, then it seems it wouldn't flag a now-unnecessary Data.Traversable
dependency for instance. At least not without rather significant retooling.

I might be off in my understanding of how it works, though.

-Edward

On Tue, Jan 20, 2015 at 7:40 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> I don't see why that would be the case: we haven't *excluded* any
> old import lists, so -ddump-minimal-imports could still
> take advantage of Prelude in a warning-free way.
>
> Edward
>
> Excerpts from Edward Kmett's message of 2015-01-20 16:36:53 -0800:
> > It isn't without a cost. On the down-side, the results of
> > -ddump-minimal-imports would be er.. less minimal.
> >
> > On Tue, Jan 20, 2015 at 6:47 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
> >
> > > I like this proposal: if you're explicit about an import that
> > > would otherwise be implicit by Prelude, you shouldn't get a
> > > warning for it. If it is not already the case, we also need to
> > > make sure the implicit Prelude import never causes "unused import"
> > > errors.
> > >
> > > Edward
> > >
> > > Excerpts from Edward Kmett's message of 2015-01-20 15:41:13 -0800:
> > > > Sure.
> > > >
> > > > Adding it to the CHANGELOG makes a lot of sense. I first found out
> about
> > > it
> > > > only a few weeks ago when Herbert mentioned it in passing.
> > > >
> > > > Of course, the geek in me definitely prefers technical fixes to human
> > > ones.
> > > > Humans are messy. =)
> > > >
> > > > I'd be curious how much of the current suite of warnings could be
> fixed
> > > > just by switching the implicit Prelude import to the end of the
> import
> > > list
> > > > inside GHC.
> > > >
> > > > Now that Herbert has all of his crazy tooling to build stuff with
> 7.10
> > > and
> > > > with HEAD, it might be worth trying out such a change to see how
> much it
> > > > reduces the warning volume and if it somehow manages to introduce
> any new
> > > > warnings.
> > > >
> > > > I hesitate to make such a proposal this late in the release candidate
> > > game,
> > > > but if it worked it'd be pretty damn compelling.
> > > >
> > > > -Edward
> > > >
> > > > On Tue, Jan 20, 2015 at 6:27 PM, Edward Z. Yang <ezyang at mit.edu>
> wrote:
> > > >
> > > > > Hello Edward,
> > > > >
> > > > > Shouldn't we publicize this trick? Perhaps in the changelog?
> > > > >
> > > > > Edward
> > > > >
> > > > > Excerpts from Edward Kmett's message of 2015-01-20 15:22:57 -0800:
> > > > > > Building -Wall clean across this change-over has a big of a
> trick to
> > > it.
> > > > > >
> > > > > > The easiest way I know of when folks already had lots of
> > > > > >
> > > > > > import Data.Foldable
> > > > > > import Data.Traversable
> > > > > >
> > > > > > stuff
> > > > > >
> > > > > > is to just add
> > > > > >
> > > > > > import Prelude
> > > > > >
> > > > > > explicitly to the bottom of your import list rather than
> > > painstakingly
> > > > > > exclude the imports with CPP.
> > > > > >
> > > > > > This has the benefit of not needing a bunch of CPP to manage what
> > > names
> > > > > > come from where.
> > > > > >
> > > > > > Why? GHC checks that the imports provide something 'new' that is
> > > used by
> > > > > > the module in a top-down fashion, and you are almost suredly
> using
> > > > > > something from Prelude that didn't come from one of the modules
> > > above.
> > > > > >
> > > > > > On the other hand the implicit import of Prelude effectively
> would
> > > come
> > > > > > first in the list.
> > > > > >
> > > > > > It is a dirty trick, but it does neatly side-step this problem
> for
> > > folks
> > > > > in
> > > > > > your situation.
> > > > > >
> > > > > > -Edward
> > > > > >
> > > > > > On Tue, Jan 20, 2015 at 6:12 PM, Bryan O'Sullivan <
> > > bos at serpentine.com>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On Tue, Jan 20, 2015 at 3:02 PM, Herbert Valerio Riedel <
> > > hvr at gnu.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> I'm a bit confused, several past attoparsec versions seem to
> build
> > > > > just
> > > > > > >> fine with GHC 7.10:
> > > > > > >>
> > > > > > >>   https://ghc.haskell.org/~hvr/buildreports/attoparsec.html
> > > > > > >>
> > > > > > >> were there hidden breakages not resulting in compile errors?
> > > > > > >> Or are the fixes you mention about restoring -Wall hygiene?
> > > > > > >>
> > > > > > >
> > > > > > > I build with -Wall -Werror, and also have to maintain the test
> and
> > > > > > > benchmark suites.
> > > > > > >
> > > > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150120/e96788c1/attachment.html>

From mike at proclivis.com  Wed Jan 21 03:43:48 2015
From: mike at proclivis.com (Michael Jones)
Date: Tue, 20 Jan 2015 20:43:48 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <54BE7B88.5000209@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
Message-ID: <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>

Simon,

The code below hangs on the frameEx function.

But, if I change it to:

       f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool" rectZero (frameDefaultStyle .|. wxMAXIMIZE)

it will progress, but no frame pops up, except once in many tries. Still hangs, but progresses through all the setup code.

However, I did make past statements that a non-GUI version was hanging. So I am not blaming wxHaskell. Just noting that in this case it is where things go wrong.

Anyone,

Are there any wxHaskell experts around that might have some insight? 

(Remember, works on single core 32 bit, works on quad core 64 bit, fails on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the code base to fix problems like this?)

? CODE SAMPLE --------

gui :: IO ()
gui
  = do
       values <- varCreate []                            -- Values to be painted
       timeLine <- varCreate 0                           -- Line time
       sample <- varCreate 0                             -- Sample Number
       running <- varCreate True                         -- True when telemetry is active

<<HANG HERE>>

       f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope Tool"] objectNull
      
Setup GUI components code was here

       return ()

go :: IO ()
go = do
    putStrLn "Start GUI"
    start $ gui

exeMain :: IO ()
exeMain = do
  hSetBuffering stdout NoBuffering
  getArgs >>= parse
  where
    parse ["-h"] = usage   >> exit
    parse ["-v"] = version >> exit
    parse []     = go
    parse [url, port, session, target] = goServer url port (read session) (read target)
 
    usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
    version = putStrLn "Haskell linti-scope 0.1.0.0"
    exit    = System.Exit.exitWith System.Exit.ExitSuccess
    die     = System.Exit.exitWith (System.Exit.ExitFailure 1)

#ifndef MAIN_FUNCTION
#define MAIN_FUNCTION exeMain
#endif
main = MAIN_FUNCTION

On Jan 20, 2015, at 9:00 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> My guess would be that either
> - a thread is in a non-allocating loop
> - a long-running foreign call is marked unsafe
> 
> Either of these would block the other threads.  ThreadScope together with some traceEventIO calls might help you identify the culprit.
> 
> Cheers,
> Simon
> 
> On 20/01/2015 15:49, Michael Jones wrote:
>> Simon,
>> 
>> This was fixed some time back. I combed the code base looking for other busy loops and there are no more. I commented out the code that runs the I2C + Machines + IO stuff, and only left the GUI code. It appears that just the wxhaskell part of the program fails to start. This matches a previous observation based on printing.
>> 
>> I?ll see if I can hack up the code to a minimal set that I can publish. All the IP is in the I2C code, so I might be able to get it down to one file.
>> 
>> Mike
>> 
>> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>>> Hi Michael,
>>> 
>>> Previously in this thread it was pointed out that your code was doing busy waiting, and so the problem can be fixed by modifying your code to not do busy waiting.  Did you do this?  The -C flag is just a workaround which will make the RTS reschedule more often, it won't fix the underlying problem.
>>> 
>>> The code you showed us was:
>>> 
>>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
>>> sendTransactions dev dts = repeatedly $ do
>>>  dts' <- liftIO $ atomically $ readTVar dts
>>>  when (dts' == True) (do
>>>      (_, transactions) <- await
>>>      liftIO $ sendOut dev transactions)
>>> 
>>> This loops when the contents of the TVar is False.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> On 18/01/2015 01:15, Michael Jones wrote:
>>>> I have narrowed down the problem a bit. It turns out that many times if
>>>> I run the program and wait long enough, it will start. Given an event
>>>> log, it may take from 1000-10000 entries sometimes.
>>>> 
>>>> When I look at a good start vs. slow start, I see that in both cases
>>>> things startup and there is some thread activity for thread 2 and 3,
>>>> then the application starts creating other threads, which is when the
>>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>>>> it just gets stuck on thread 2/3 activity for a very long time.
>>>> 
>>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>>>> that most starts result in an immediate GUI and i2c IO.
>>>> 
>>>> The behavior suggests to me that some initial threads are starving the
>>>> ability for other threads to start, and perhaps on a dual core machine
>>>> it is more of a problem than single or quad core machines. For certain,
>>>> due to some printing, I know that the main thread is starting, and that
>>>> a print just before the first fork is not printing. Code between them is
>>>> evaluating wxhaskell functions, but the main frame is not yet asked to
>>>> become visible. From last week, I know that an non-gui version of the
>>>> app is getting stuck, but I do not know if it eventually runs like this
>>>> case.
>>>> 
>>>> Is there some convention that when I look at an event log you can tell
>>>> which threads are OS threads vs threads from fork?
>>>> 
>>>> Perhaps someone that knows the scheduler might have some advice. It
>>>> seems odd that a scheduler could behave this way. The scheduler should
>>>> have some built in notion of fairness.
>>>> 
>>>> 
>>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>>>> <mailto:mike at proclivis.com>> wrote:
>>>> 
>>>>> Sorry I am reviving an old problem, but it has resurfaced, such that
>>>>> one system behaves different than another.
>>>>> 
>>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>>>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>>>>> something bad is going on. In summary, the same code that runs on two
>>>>> machines does not run on a third machine. So this indicates I have not
>>>>> made any breaking changes to the code or cabal files. Compiling with
>>>>> GHC 7.8.3.
>>>>> 
>>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>>>> the application runs. It has bad timing properties, but it does at
>>>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>>>> GUI thread.
>>>>> 
>>>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>>>> tries, so fail means fail most but not all of the time. When it did
>>>>> run, it continued to run properly. This perhaps indicates some kind of
>>>>> internal race condition.
>>>>> 
>>>>> In the fail to run case, it does some printing up to the point where
>>>>> it tries to create a wxHaskell frame. In another non-UI version of the
>>>>> program it also fails to run. Logging to a file gives a similar
>>>>> indication. It is clear that the program starts up, then fails during
>>>>> the run in some form of lockup, well after the initial startup code.
>>>>> 
>>>>> If I run with the strace command, it always runs with -C0.00N.
>>>>> 
>>>>> All the above was done with profiling enabled, so I removed that and
>>>>> instead enabled eventlog to look for clues.
>>>>> 
>>>>> In this case it lies between good and bad, in that IO to my USB is
>>>>> working, but the GUI comes up blank and never paints. Running this
>>>>> case without -v0 (event log) the gui partially paints and stops, but
>>>>> USB continues.
>>>>> 
>>>>> Questions:
>>>>> 
>>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>>>> kinds of scheduling/thread problems?
>>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>>>> wxHaskell IO that leads to problems that a pure calculation app would
>>>>> not have?
>>>>> 3) Any ideas how to track down the problem when changing conditions
>>>>> (compiler or runtime options) affects behavior?
>>>>> 4) Are there other options besides -V and -C for the runtime that
>>>>> might apply?
>>>>> 5) What does -V0 do that makes a problem program run?
>>>>> 
>>>>> Mike
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>> 
>>>>>> John,
>>>>>> 
>>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>>>> more like -N4.
>>>>>> 
>>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>>>> Atom and was stuck.
>>>>>> 
>>>>>> Mike
>>>>>> 
>>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>>>> <mailto:jwlato at gmail.com>> wrote:
>>>>>> 
>>>>>>> By any chance do the delays get shorter if you run your program with
>>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>>>> thread scheduler.
>>>>>>> 
>>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>> 
>>>>>>>    I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>>>> 
>>>>>>>    I moved from 7.6 to 7.8 and my application behaves very
>>>>>>>    differently. I have three threads, an application thread that
>>>>>>>    plots data with wxhaskell or sends it over a network (depends on
>>>>>>>    settings), a thread doing usb bulk writes, and a thread doing
>>>>>>>    usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>>>    used for coordination.
>>>>>>> 
>>>>>>>    When the application was compiled with 7.6, my stream of usb
>>>>>>>    traffic was smooth. With 7.8, there are lots of delays where
>>>>>>>    nothing seems to be running. These delays are up to 40ms,
>>>>>>>    whereas with 7.6 delays were a 1ms or so.
>>>>>>> 
>>>>>>>    When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>>>    runs fine without with -N2/4.
>>>>>>> 
>>>>>>>    The program is compiled -O2 with profiling. The -N2/4 version
>>>>>>>    uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>>>>    is no space leak.
>>>>>>> 
>>>>>>>    I tired to compile and use -ls so I could take a look with
>>>>>>>    threadscope, but the application hangs and writes no data to the
>>>>>>>    file. The CPU fans run wild like it is in an infinite loop. It
>>>>>>>    at least pops an unpainted wxhaskell window, so it got partially
>>>>>>>    running.
>>>>>>> 
>>>>>>>    One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>>>    around the compiler.
>>>>>>> 
>>>>>>>    What do I need to know about changes to threading and event
>>>>>>>    logging between 7.6 and 7.8? Is there some general documentation
>>>>>>>    somewhere that might help?
>>>>>>> 
>>>>>>>    I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>>>    ball and installed myself, after removing 7.6 with apt-get.
>>>>>>> 
>>>>>>>    Any hints appreciated.
>>>>>>> 
>>>>>>>    Mike
>>>>>>> 
>>>>>>> 
>>>>>>>    _______________________________________________
>>>>>>>    Glasgow-haskell-users mailing list
>>>>>>>    Glasgow-haskell-users at haskell.org
>>>>>>>    <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>>    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users at haskell.org
>>>>> <mailto:Glasgow-haskell-users at haskell.org>
>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>> 
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
>> 



From carter.schonwald at gmail.com  Wed Jan 21 05:34:44 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 21 Jan 2015 00:34:44 -0500
Subject: Thread behavior in 7.8.3
In-Reply-To: <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
Message-ID: <CAHYVw0xWMLy+tAPATp21jCyVGLwg3BNEKAP1gJ-8+CsF0fuUUA@mail.gmail.com>

i think ben gamari hit similar/related issues with the lib usb bindings in
7.8, and i believe some / all of them are fixed in 7.10
(i could be mixing things up though)

On Tue, Jan 20, 2015 at 10:43 PM, Michael Jones <mike at proclivis.com> wrote:

> Simon,
>
> The code below hangs on the frameEx function.
>
> But, if I change it to:
>
>        f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool"
> rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>
> it will progress, but no frame pops up, except once in many tries. Still
> hangs, but progresses through all the setup code.
>
> However, I did make past statements that a non-GUI version was hanging. So
> I am not blaming wxHaskell. Just noting that in this case it is where
> things go wrong.
>
> Anyone,
>
> Are there any wxHaskell experts around that might have some insight?
>
> (Remember, works on single core 32 bit, works on quad core 64 bit, fails
> on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the code base to
> fix problems like this?)
>
> ? CODE SAMPLE --------
>
> gui :: IO ()
> gui
>   = do
>        values <- varCreate []                            -- Values to be
> painted
>        timeLine <- varCreate 0                           -- Line time
>        sample <- varCreate 0                             -- Sample Number
>        running <- varCreate True                         -- True when
> telemetry is active
>
> <<HANG HERE>>
>
>        f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope
> Tool"] objectNull
>
> Setup GUI components code was here
>
>        return ()
>
> go :: IO ()
> go = do
>     putStrLn "Start GUI"
>     start $ gui
>
> exeMain :: IO ()
> exeMain = do
>   hSetBuffering stdout NoBuffering
>   getArgs >>= parse
>   where
>     parse ["-h"] = usage   >> exit
>     parse ["-v"] = version >> exit
>     parse []     = go
>     parse [url, port, session, target] = goServer url port (read session)
> (read target)
>
>     usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
>     version = putStrLn "Haskell linti-scope 0.1.0.0"
>     exit    = System.Exit.exitWith System.Exit.ExitSuccess
>     die     = System.Exit.exitWith (System.Exit.ExitFailure 1)
>
> #ifndef MAIN_FUNCTION
> #define MAIN_FUNCTION exeMain
> #endif
> main = MAIN_FUNCTION
>
> On Jan 20, 2015, at 9:00 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> > My guess would be that either
> > - a thread is in a non-allocating loop
> > - a long-running foreign call is marked unsafe
> >
> > Either of these would block the other threads.  ThreadScope together
> with some traceEventIO calls might help you identify the culprit.
> >
> > Cheers,
> > Simon
> >
> > On 20/01/2015 15:49, Michael Jones wrote:
> >> Simon,
> >>
> >> This was fixed some time back. I combed the code base looking for other
> busy loops and there are no more. I commented out the code that runs the
> I2C + Machines + IO stuff, and only left the GUI code. It appears that just
> the wxhaskell part of the program fails to start. This matches a previous
> observation based on printing.
> >>
> >> I?ll see if I can hack up the code to a minimal set that I can publish.
> All the IP is in the I2C code, so I might be able to get it down to one
> file.
> >>
> >> Mike
> >>
> >> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> >>
> >>> Hi Michael,
> >>>
> >>> Previously in this thread it was pointed out that your code was doing
> busy waiting, and so the problem can be fixed by modifying your code to not
> do busy waiting.  Did you do this?  The -C flag is just a workaround which
> will make the RTS reschedule more often, it won't fix the underlying
> problem.
> >>>
> >>> The code you showed us was:
> >>>
> >>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool
> -> ProcessT m (Spec, String) ()
> >>> sendTransactions dev dts = repeatedly $ do
> >>>  dts' <- liftIO $ atomically $ readTVar dts
> >>>  when (dts' == True) (do
> >>>      (_, transactions) <- await
> >>>      liftIO $ sendOut dev transactions)
> >>>
> >>> This loops when the contents of the TVar is False.
> >>>
> >>> Cheers,
> >>> Simon
> >>>
> >>> On 18/01/2015 01:15, Michael Jones wrote:
> >>>> I have narrowed down the problem a bit. It turns out that many times
> if
> >>>> I run the program and wait long enough, it will start. Given an event
> >>>> log, it may take from 1000-10000 entries sometimes.
> >>>>
> >>>> When I look at a good start vs. slow start, I see that in both cases
> >>>> things startup and there is some thread activity for thread 2 and 3,
> >>>> then the application starts creating other threads, which is when the
> >>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
> >>>> it just gets stuck on thread 2/3 activity for a very long time.
> >>>>
> >>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
> >>>> that most starts result in an immediate GUI and i2c IO.
> >>>>
> >>>> The behavior suggests to me that some initial threads are starving the
> >>>> ability for other threads to start, and perhaps on a dual core machine
> >>>> it is more of a problem than single or quad core machines. For
> certain,
> >>>> due to some printing, I know that the main thread is starting, and
> that
> >>>> a print just before the first fork is not printing. Code between them
> is
> >>>> evaluating wxhaskell functions, but the main frame is not yet asked to
> >>>> become visible. From last week, I know that an non-gui version of the
> >>>> app is getting stuck, but I do not know if it eventually runs like
> this
> >>>> case.
> >>>>
> >>>> Is there some convention that when I look at an event log you can tell
> >>>> which threads are OS threads vs threads from fork?
> >>>>
> >>>> Perhaps someone that knows the scheduler might have some advice. It
> >>>> seems odd that a scheduler could behave this way. The scheduler should
> >>>> have some built in notion of fairness.
> >>>>
> >>>>
> >>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
> >>>> <mailto:mike at proclivis.com>> wrote:
> >>>>
> >>>>> Sorry I am reviving an old problem, but it has resurfaced, such that
> >>>>> one system behaves different than another.
> >>>>>
> >>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
> >>>>> a single core 32 bit Atom NUC. But on a dual core Atom
> MinnowBoardMax,
> >>>>> something bad is going on. In summary, the same code that runs on two
> >>>>> machines does not run on a third machine. So this indicates I have
> not
> >>>>> made any breaking changes to the code or cabal files. Compiling with
> >>>>> GHC 7.8.3.
> >>>>>
> >>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
> >>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
> >>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
> >>>>> the application runs. It has bad timing properties, but it does at
> >>>>> least run. Note that a hang hangs an IO thread talking USB, and the
> >>>>> GUI thread.
> >>>>>
> >>>>> When testing with the -C0.00N option, it did run 2 times out of 20
> >>>>> tries, so fail means fail most but not all of the time. When it did
> >>>>> run, it continued to run properly. This perhaps indicates some kind
> of
> >>>>> internal race condition.
> >>>>>
> >>>>> In the fail to run case, it does some printing up to the point where
> >>>>> it tries to create a wxHaskell frame. In another non-UI version of
> the
> >>>>> program it also fails to run. Logging to a file gives a similar
> >>>>> indication. It is clear that the program starts up, then fails during
> >>>>> the run in some form of lockup, well after the initial startup code.
> >>>>>
> >>>>> If I run with the strace command, it always runs with -C0.00N.
> >>>>>
> >>>>> All the above was done with profiling enabled, so I removed that and
> >>>>> instead enabled eventlog to look for clues.
> >>>>>
> >>>>> In this case it lies between good and bad, in that IO to my USB is
> >>>>> working, but the GUI comes up blank and never paints. Running this
> >>>>> case without -v0 (event log) the gui partially paints and stops, but
> >>>>> USB continues.
> >>>>>
> >>>>> Questions:
> >>>>>
> >>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
> >>>>> kinds of scheduling/thread problems?
> >>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
> >>>>> wxHaskell IO that leads to problems that a pure calculation app would
> >>>>> not have?
> >>>>> 3) Any ideas how to track down the problem when changing conditions
> >>>>> (compiler or runtime options) affects behavior?
> >>>>> 4) Are there other options besides -V and -C for the runtime that
> >>>>> might apply?
> >>>>> 5) What does -V0 do that makes a problem program run?
> >>>>>
> >>>>> Mike
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
> >>>>> <mailto:mike at proclivis.com>> wrote:
> >>>>>
> >>>>>> John,
> >>>>>>
> >>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
> >>>>>> more like -N4.
> >>>>>>
> >>>>>> Thanks. This saves my project, as I need to deploy on a single core
> >>>>>> Atom and was stuck.
> >>>>>>
> >>>>>> Mike
> >>>>>>
> >>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
> >>>>>> <mailto:jwlato at gmail.com>> wrote:
> >>>>>>
> >>>>>>> By any chance do the delays get shorter if you run your program
> with
> >>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
> >>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
> >>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
> >>>>>>> thread scheduler.
> >>>>>>>
> >>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
> >>>>>>> <mailto:mike at proclivis.com>> wrote:
> >>>>>>>
> >>>>>>>    I have a general question about thread behavior in 7.8.3 vs
> 7.6.X
> >>>>>>>
> >>>>>>>    I moved from 7.6 to 7.8 and my application behaves very
> >>>>>>>    differently. I have three threads, an application thread that
> >>>>>>>    plots data with wxhaskell or sends it over a network (depends on
> >>>>>>>    settings), a thread doing usb bulk writes, and a thread doing
> >>>>>>>    usb bulk reads. Data is moved around with TChan, and TVar is
> >>>>>>>    used for coordination.
> >>>>>>>
> >>>>>>>    When the application was compiled with 7.6, my stream of usb
> >>>>>>>    traffic was smooth. With 7.8, there are lots of delays where
> >>>>>>>    nothing seems to be running. These delays are up to 40ms,
> >>>>>>>    whereas with 7.6 delays were a 1ms or so.
> >>>>>>>
> >>>>>>>    When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
> >>>>>>>    runs fine without with -N2/4.
> >>>>>>>
> >>>>>>>    The program is compiled -O2 with profiling. The -N2/4 version
> >>>>>>>    uses more memory,  but in both cases with 7.8 and with 7.6 there
> >>>>>>>    is no space leak.
> >>>>>>>
> >>>>>>>    I tired to compile and use -ls so I could take a look with
> >>>>>>>    threadscope, but the application hangs and writes no data to the
> >>>>>>>    file. The CPU fans run wild like it is in an infinite loop. It
> >>>>>>>    at least pops an unpainted wxhaskell window, so it got partially
> >>>>>>>    running.
> >>>>>>>
> >>>>>>>    One of my libraries uses option -fsimpl-tick-factor=200 to get
> >>>>>>>    around the compiler.
> >>>>>>>
> >>>>>>>    What do I need to know about changes to threading and event
> >>>>>>>    logging between 7.6 and 7.8? Is there some general documentation
> >>>>>>>    somewhere that might help?
> >>>>>>>
> >>>>>>>    I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
> >>>>>>>    ball and installed myself, after removing 7.6 with apt-get.
> >>>>>>>
> >>>>>>>    Any hints appreciated.
> >>>>>>>
> >>>>>>>    Mike
> >>>>>>>
> >>>>>>>
> >>>>>>>    _______________________________________________
> >>>>>>>    Glasgow-haskell-users mailing list
> >>>>>>>    Glasgow-haskell-users at haskell.org
> >>>>>>>    <mailto:Glasgow-haskell-users at haskell.org>
> >>>>>>>    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Glasgow-haskell-users mailing list
> >>>>> Glasgow-haskell-users at haskell.org
> >>>>> <mailto:Glasgow-haskell-users at haskell.org>
> >>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Glasgow-haskell-users mailing list
> >>>> Glasgow-haskell-users at haskell.org
> >>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>>>
> >>> _______________________________________________
> >>> Glasgow-haskell-users mailing list
> >>> Glasgow-haskell-users at haskell.org
> >>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >>
> >>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/7da058f4/attachment-0001.html>

From verteiler at volker-wysk.de  Wed Jan 21 07:20:47 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Wed, 21 Jan 2015 08:20:47 +0100
Subject: [solved] Re: "Found hole"
In-Reply-To: <4314332.VFU07dKVqU@debian>
References: <4314332.VFU07dKVqU@debian>
Message-ID: <3415562.8X25miLgIf@debian>

Hello!

I've found what went wrong: "_exit" wasn't in scope, so it was interpreted to 
be a "typed hole". 

Thanks
Volker


From hvr at gnu.org  Wed Jan 21 07:46:33 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 21 Jan 2015 08:46:33 +0100
Subject: GHC 7.10 regression when using foldr
In-Reply-To: <1421796438-sup-4859@sabre> (Edward Z. Yang's message of "Tue, 20
 Jan 2015 15:27:39 -0800")
References: <54BE3A09.10201@informatik.uni-kiel.de>
 <CAJumaK_vfqbrBq6vUYsiV5r0Gv7TtpJVG+pZTph3FFP7ai4+5Q@mail.gmail.com>
 <CACw0ni+=UVP5FGtpcHPtDqkX-62z4evxoUvLEHaV50EeSanMhA@mail.gmail.com>
 <878ugxginb.fsf@gnu.org>
 <CACw0niJJK2uAXmjow7rgwcRA_C0iXHD-SiCabpgp=Cg0hxtpbw@mail.gmail.com>
 <CAJumaK9RR0fyf6H0X6Aj9JwVg2H8osOvgj9dwnrX5EXt+yQyaw@mail.gmail.com>
 <1421796438-sup-4859@sabre>
Message-ID: <87zj9cvana.fsf@gnu.org>

On 2015-01-21 at 00:27:39 +0100, Edward Z. Yang wrote:
> Hello Edward,
>
> Shouldn't we publicize this trick? Perhaps in the changelog?

Fwiw, I've added that workaround/recipe to

 https://ghc.haskell.org/trac/ghc/wiki/Migration/7.10#GHCsaysTheimportof...isredundant

feel free to improve the wording... :-)

From merijn at inconsistent.nl  Wed Jan 21 10:03:38 2015
From: merijn at inconsistent.nl (Merijn Verstraaten)
Date: Wed, 21 Jan 2015 11:03:38 +0100
Subject: "Found hole"
In-Reply-To: <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
Message-ID: <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>

Typed holes is not an extension, because it's considered a warning/error. The reason for this is that code with typed holes is NOT valid haskell to begin with, therefore the behaviour doesn't conflict with any description in the report.

Additionally, the ability to disable the typed holes warning is disappearing in 7.10 (well, sorta, you can silence them, but you can't get the "old" error message back). If there's any comments on how to improve the warning message to be less confusing I'd be interested to hear them.

Cheers,
Merijn

> On 20 Jan 2015, at 19:44, Brandon Allbery <allbery.b at gmail.com> wrote:
> 
> On Tue, Jan 20, 2015 at 1:36 PM, Volker Wysk <verteiler at volker-wysk.de> wrote:
> What is a "hole"?
> 
> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/typed-holes.html
> 
> When I replace "_exit" with "foo", it produces a "not in scope" error, as
> expected. What is special about "_exit"? It doesn't occur in the Haskell
> Hierarchical Libraries.
> 
> The leading underscore invokes the typed holes extension. If you want to use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line of the source file. (I am not sure why this extension was enabled by default.)
> 
> --
> brandon s allbery kf8nh                               sine nomine associates
> allbery.b at gmail.com                                  ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/e985e0e6/attachment.sig>

From marlowsd at gmail.com  Wed Jan 21 10:18:02 2015
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 21 Jan 2015 10:18:02 +0000
Subject: Thread behavior in 7.8.3
In-Reply-To: <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
Message-ID: <54BF7CDA.2080600@gmail.com>

On 21/01/2015 03:43, Michael Jones wrote:
> Simon,
>
> The code below hangs on the frameEx function.
>
> But, if I change it to:
>
>         f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool" rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>
> it will progress, but no frame pops up, except once in many tries. Still hangs, but progresses through all the setup code.
>
> However, I did make past statements that a non-GUI version was hanging. So I am not blaming wxHaskell. Just noting that in this case it is where things go wrong.
>
> Anyone,
>
> Are there any wxHaskell experts around that might have some insight?
>
> (Remember, works on single core 32 bit, works on quad core 64 bit,
> fails on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the
> code base to fix problems like this?)

No, there are no recently fixed or outstanding bugs in this area that 
I'm aware of.

 From the symptoms I strongly suspect there's an unsafe foreign call 
somewhere causing problems, or another busy-wait loop.

Cheers,
Simon


>
> ? CODE SAMPLE --------
>
> gui :: IO ()
> gui
>    = do
>         values <- varCreate []                            -- Values to be painted
>         timeLine <- varCreate 0                           -- Line time
>         sample <- varCreate 0                             -- Sample Number
>         running <- varCreate True                         -- True when telemetry is active
>
> <<HANG HERE>>
>
>         f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope Tool"] objectNull
>
> Setup GUI components code was here
>
>         return ()
>
> go :: IO ()
> go = do
>      putStrLn "Start GUI"
>      start $ gui
>
> exeMain :: IO ()
> exeMain = do
>    hSetBuffering stdout NoBuffering
>    getArgs >>= parse
>    where
>      parse ["-h"] = usage   >> exit
>      parse ["-v"] = version >> exit
>      parse []     = go
>      parse [url, port, session, target] = goServer url port (read session) (read target)
>
>      usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
>      version = putStrLn "Haskell linti-scope 0.1.0.0"
>      exit    = System.Exit.exitWith System.Exit.ExitSuccess
>      die     = System.Exit.exitWith (System.Exit.ExitFailure 1)
>
> #ifndef MAIN_FUNCTION
> #define MAIN_FUNCTION exeMain
> #endif
> main = MAIN_FUNCTION
>
> On Jan 20, 2015, at 9:00 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> My guess would be that either
>> - a thread is in a non-allocating loop
>> - a long-running foreign call is marked unsafe
>>
>> Either of these would block the other threads.  ThreadScope together with some traceEventIO calls might help you identify the culprit.
>>
>> Cheers,
>> Simon
>>
>> On 20/01/2015 15:49, Michael Jones wrote:
>>> Simon,
>>>
>>> This was fixed some time back. I combed the code base looking for other busy loops and there are no more. I commented out the code that runs the I2C + Machines + IO stuff, and only left the GUI code. It appears that just the wxhaskell part of the program fails to start. This matches a previous observation based on printing.
>>>
>>> I?ll see if I can hack up the code to a minimal set that I can publish. All the IP is in the I2C code, so I might be able to get it down to one file.
>>>
>>> Mike
>>>
>>> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>>
>>>> Hi Michael,
>>>>
>>>> Previously in this thread it was pointed out that your code was doing busy waiting, and so the problem can be fixed by modifying your code to not do busy waiting.  Did you do this?  The -C flag is just a workaround which will make the RTS reschedule more often, it won't fix the underlying problem.
>>>>
>>>> The code you showed us was:
>>>>
>>>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
>>>> sendTransactions dev dts = repeatedly $ do
>>>>   dts' <- liftIO $ atomically $ readTVar dts
>>>>   when (dts' == True) (do
>>>>       (_, transactions) <- await
>>>>       liftIO $ sendOut dev transactions)
>>>>
>>>> This loops when the contents of the TVar is False.
>>>>
>>>> Cheers,
>>>> Simon
>>>>
>>>> On 18/01/2015 01:15, Michael Jones wrote:
>>>>> I have narrowed down the problem a bit. It turns out that many times if
>>>>> I run the program and wait long enough, it will start. Given an event
>>>>> log, it may take from 1000-10000 entries sometimes.
>>>>>
>>>>> When I look at a good start vs. slow start, I see that in both cases
>>>>> things startup and there is some thread activity for thread 2 and 3,
>>>>> then the application starts creating other threads, which is when the
>>>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>>>>> it just gets stuck on thread 2/3 activity for a very long time.
>>>>>
>>>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>>>>> that most starts result in an immediate GUI and i2c IO.
>>>>>
>>>>> The behavior suggests to me that some initial threads are starving the
>>>>> ability for other threads to start, and perhaps on a dual core machine
>>>>> it is more of a problem than single or quad core machines. For certain,
>>>>> due to some printing, I know that the main thread is starting, and that
>>>>> a print just before the first fork is not printing. Code between them is
>>>>> evaluating wxhaskell functions, but the main frame is not yet asked to
>>>>> become visible. From last week, I know that an non-gui version of the
>>>>> app is getting stuck, but I do not know if it eventually runs like this
>>>>> case.
>>>>>
>>>>> Is there some convention that when I look at an event log you can tell
>>>>> which threads are OS threads vs threads from fork?
>>>>>
>>>>> Perhaps someone that knows the scheduler might have some advice. It
>>>>> seems odd that a scheduler could behave this way. The scheduler should
>>>>> have some built in notion of fairness.
>>>>>
>>>>>
>>>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>
>>>>>> Sorry I am reviving an old problem, but it has resurfaced, such that
>>>>>> one system behaves different than another.
>>>>>>
>>>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>>>>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>>>>>> something bad is going on. In summary, the same code that runs on two
>>>>>> machines does not run on a third machine. So this indicates I have not
>>>>>> made any breaking changes to the code or cabal files. Compiling with
>>>>>> GHC 7.8.3.
>>>>>>
>>>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>>>>> the application runs. It has bad timing properties, but it does at
>>>>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>>>>> GUI thread.
>>>>>>
>>>>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>>>>> tries, so fail means fail most but not all of the time. When it did
>>>>>> run, it continued to run properly. This perhaps indicates some kind of
>>>>>> internal race condition.
>>>>>>
>>>>>> In the fail to run case, it does some printing up to the point where
>>>>>> it tries to create a wxHaskell frame. In another non-UI version of the
>>>>>> program it also fails to run. Logging to a file gives a similar
>>>>>> indication. It is clear that the program starts up, then fails during
>>>>>> the run in some form of lockup, well after the initial startup code.
>>>>>>
>>>>>> If I run with the strace command, it always runs with -C0.00N.
>>>>>>
>>>>>> All the above was done with profiling enabled, so I removed that and
>>>>>> instead enabled eventlog to look for clues.
>>>>>>
>>>>>> In this case it lies between good and bad, in that IO to my USB is
>>>>>> working, but the GUI comes up blank and never paints. Running this
>>>>>> case without -v0 (event log) the gui partially paints and stops, but
>>>>>> USB continues.
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>>>>> kinds of scheduling/thread problems?
>>>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>>>>> wxHaskell IO that leads to problems that a pure calculation app would
>>>>>> not have?
>>>>>> 3) Any ideas how to track down the problem when changing conditions
>>>>>> (compiler or runtime options) affects behavior?
>>>>>> 4) Are there other options besides -V and -C for the runtime that
>>>>>> might apply?
>>>>>> 5) What does -V0 do that makes a problem program run?
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>
>>>>>>> John,
>>>>>>>
>>>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>>>>> more like -N4.
>>>>>>>
>>>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>>>>> Atom and was stuck.
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>>>>> <mailto:jwlato at gmail.com>> wrote:
>>>>>>>
>>>>>>>> By any chance do the delays get shorter if you run your program with
>>>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>>>>> thread scheduler.
>>>>>>>>
>>>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>>>
>>>>>>>>     I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>>>>>
>>>>>>>>     I moved from 7.6 to 7.8 and my application behaves very
>>>>>>>>     differently. I have three threads, an application thread that
>>>>>>>>     plots data with wxhaskell or sends it over a network (depends on
>>>>>>>>     settings), a thread doing usb bulk writes, and a thread doing
>>>>>>>>     usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>>>>     used for coordination.
>>>>>>>>
>>>>>>>>     When the application was compiled with 7.6, my stream of usb
>>>>>>>>     traffic was smooth. With 7.8, there are lots of delays where
>>>>>>>>     nothing seems to be running. These delays are up to 40ms,
>>>>>>>>     whereas with 7.6 delays were a 1ms or so.
>>>>>>>>
>>>>>>>>     When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>>>>     runs fine without with -N2/4.
>>>>>>>>
>>>>>>>>     The program is compiled -O2 with profiling. The -N2/4 version
>>>>>>>>     uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>>>>>     is no space leak.
>>>>>>>>
>>>>>>>>     I tired to compile and use -ls so I could take a look with
>>>>>>>>     threadscope, but the application hangs and writes no data to the
>>>>>>>>     file. The CPU fans run wild like it is in an infinite loop. It
>>>>>>>>     at least pops an unpainted wxhaskell window, so it got partially
>>>>>>>>     running.
>>>>>>>>
>>>>>>>>     One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>>>>     around the compiler.
>>>>>>>>
>>>>>>>>     What do I need to know about changes to threading and event
>>>>>>>>     logging between 7.6 and 7.8? Is there some general documentation
>>>>>>>>     somewhere that might help?
>>>>>>>>
>>>>>>>>     I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>>>>     ball and installed myself, after removing 7.6 with apt-get.
>>>>>>>>
>>>>>>>>     Any hints appreciated.
>>>>>>>>
>>>>>>>>     Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     Glasgow-haskell-users mailing list
>>>>>>>>     Glasgow-haskell-users at haskell.org
>>>>>>>>     <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Glasgow-haskell-users mailing list
>>>>>> Glasgow-haskell-users at haskell.org
>>>>>> <mailto:Glasgow-haskell-users at haskell.org>
>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>
>>>> _______________________________________________
>>>> Glasgow-haskell-users mailing list
>>>> Glasgow-haskell-users at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>
>

From carter.schonwald at gmail.com  Wed Jan 21 12:57:41 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 21 Jan 2015 07:57:41 -0500
Subject: Thread behavior in 7.8.3
In-Reply-To: <54BF7CDA.2080600@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
 <54BF7CDA.2080600@gmail.com>
Message-ID: <CAHYVw0xFDZwjZiJ1OaOcs+WcMECVs-xz=iC8R=HCaPEd7DJVgw@mail.gmail.com>

woops, forgot to attach the relevant links, (i shouldn't email late at
night :) )

https://github.com/basvandijk/usb/issues/7 is the lib usb matter
https://phabricator.haskell.org/D347

point being: on ghc 7.8, certain hanging behavior from libusb (at least as
of a few months ago) was due to one shotedness

On Wed, Jan 21, 2015 at 5:18 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 21/01/2015 03:43, Michael Jones wrote:
>
>> Simon,
>>
>> The code below hangs on the frameEx function.
>>
>> But, if I change it to:
>>
>>         f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool"
>> rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>>
>> it will progress, but no frame pops up, except once in many tries. Still
>> hangs, but progresses through all the setup code.
>>
>> However, I did make past statements that a non-GUI version was hanging.
>> So I am not blaming wxHaskell. Just noting that in this case it is where
>> things go wrong.
>>
>> Anyone,
>>
>> Are there any wxHaskell experts around that might have some insight?
>>
>> (Remember, works on single core 32 bit, works on quad core 64 bit,
>> fails on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the
>> code base to fix problems like this?)
>>
>
> No, there are no recently fixed or outstanding bugs in this area that I'm
> aware of.
>
> From the symptoms I strongly suspect there's an unsafe foreign call
> somewhere causing problems, or another busy-wait loop.
>
> Cheers,
> Simon
>
>
>
>
>> ? CODE SAMPLE --------
>>
>> gui :: IO ()
>> gui
>>    = do
>>         values <- varCreate []                            -- Values to be
>> painted
>>         timeLine <- varCreate 0                           -- Line time
>>         sample <- varCreate 0                             -- Sample Number
>>         running <- varCreate True                         -- True when
>> telemetry is active
>>
>> <<HANG HERE>>
>>
>>         f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope
>> Tool"] objectNull
>>
>> Setup GUI components code was here
>>
>>         return ()
>>
>> go :: IO ()
>> go = do
>>      putStrLn "Start GUI"
>>      start $ gui
>>
>> exeMain :: IO ()
>> exeMain = do
>>    hSetBuffering stdout NoBuffering
>>    getArgs >>= parse
>>    where
>>      parse ["-h"] = usage   >> exit
>>      parse ["-v"] = version >> exit
>>      parse []     = go
>>      parse [url, port, session, target] = goServer url port (read
>> session) (read target)
>>
>>      usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
>>      version = putStrLn "Haskell linti-scope 0.1.0.0"
>>      exit    = System.Exit.exitWith System.Exit.ExitSuccess
>>      die     = System.Exit.exitWith (System.Exit.ExitFailure 1)
>>
>> #ifndef MAIN_FUNCTION
>> #define MAIN_FUNCTION exeMain
>> #endif
>> main = MAIN_FUNCTION
>>
>> On Jan 20, 2015, at 9:00 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>  My guess would be that either
>>> - a thread is in a non-allocating loop
>>> - a long-running foreign call is marked unsafe
>>>
>>> Either of these would block the other threads.  ThreadScope together
>>> with some traceEventIO calls might help you identify the culprit.
>>>
>>> Cheers,
>>> Simon
>>>
>>> On 20/01/2015 15:49, Michael Jones wrote:
>>>
>>>> Simon,
>>>>
>>>> This was fixed some time back. I combed the code base looking for other
>>>> busy loops and there are no more. I commented out the code that runs the
>>>> I2C + Machines + IO stuff, and only left the GUI code. It appears that just
>>>> the wxhaskell part of the program fails to start. This matches a previous
>>>> observation based on printing.
>>>>
>>>> I?ll see if I can hack up the code to a minimal set that I can publish.
>>>> All the IP is in the I2C code, so I might be able to get it down to one
>>>> file.
>>>>
>>>> Mike
>>>>
>>>> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>>>
>>>>  Hi Michael,
>>>>>
>>>>> Previously in this thread it was pointed out that your code was doing
>>>>> busy waiting, and so the problem can be fixed by modifying your code to not
>>>>> do busy waiting.  Did you do this?  The -C flag is just a workaround which
>>>>> will make the RTS reschedule more often, it won't fix the underlying
>>>>> problem.
>>>>>
>>>>> The code you showed us was:
>>>>>
>>>>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool
>>>>> -> ProcessT m (Spec, String) ()
>>>>> sendTransactions dev dts = repeatedly $ do
>>>>>   dts' <- liftIO $ atomically $ readTVar dts
>>>>>   when (dts' == True) (do
>>>>>       (_, transactions) <- await
>>>>>       liftIO $ sendOut dev transactions)
>>>>>
>>>>> This loops when the contents of the TVar is False.
>>>>>
>>>>> Cheers,
>>>>> Simon
>>>>>
>>>>> On 18/01/2015 01:15, Michael Jones wrote:
>>>>>
>>>>>> I have narrowed down the problem a bit. It turns out that many times
>>>>>> if
>>>>>> I run the program and wait long enough, it will start. Given an event
>>>>>> log, it may take from 1000-10000 entries sometimes.
>>>>>>
>>>>>> When I look at a good start vs. slow start, I see that in both cases
>>>>>> things startup and there is some thread activity for thread 2 and 3,
>>>>>> then the application starts creating other threads, which is when the
>>>>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>>>>>> it just gets stuck on thread 2/3 activity for a very long time.
>>>>>>
>>>>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>>>>>> that most starts result in an immediate GUI and i2c IO.
>>>>>>
>>>>>> The behavior suggests to me that some initial threads are starving the
>>>>>> ability for other threads to start, and perhaps on a dual core machine
>>>>>> it is more of a problem than single or quad core machines. For
>>>>>> certain,
>>>>>> due to some printing, I know that the main thread is starting, and
>>>>>> that
>>>>>> a print just before the first fork is not printing. Code between them
>>>>>> is
>>>>>> evaluating wxhaskell functions, but the main frame is not yet asked to
>>>>>> become visible. From last week, I know that an non-gui version of the
>>>>>> app is getting stuck, but I do not know if it eventually runs like
>>>>>> this
>>>>>> case.
>>>>>>
>>>>>> Is there some convention that when I look at an event log you can tell
>>>>>> which threads are OS threads vs threads from fork?
>>>>>>
>>>>>> Perhaps someone that knows the scheduler might have some advice. It
>>>>>> seems odd that a scheduler could behave this way. The scheduler should
>>>>>> have some built in notion of fairness.
>>>>>>
>>>>>>
>>>>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>
>>>>>>  Sorry I am reviving an old problem, but it has resurfaced, such that
>>>>>>> one system behaves different than another.
>>>>>>>
>>>>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>>>>>> a single core 32 bit Atom NUC. But on a dual core Atom
>>>>>>> MinnowBoardMax,
>>>>>>> something bad is going on. In summary, the same code that runs on two
>>>>>>> machines does not run on a third machine. So this indicates I have
>>>>>>> not
>>>>>>> made any breaking changes to the code or cabal files. Compiling with
>>>>>>> GHC 7.8.3.
>>>>>>>
>>>>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>>>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>>>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>>>>>> the application runs. It has bad timing properties, but it does at
>>>>>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>>>>>> GUI thread.
>>>>>>>
>>>>>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>>>>>> tries, so fail means fail most but not all of the time. When it did
>>>>>>> run, it continued to run properly. This perhaps indicates some kind
>>>>>>> of
>>>>>>> internal race condition.
>>>>>>>
>>>>>>> In the fail to run case, it does some printing up to the point where
>>>>>>> it tries to create a wxHaskell frame. In another non-UI version of
>>>>>>> the
>>>>>>> program it also fails to run. Logging to a file gives a similar
>>>>>>> indication. It is clear that the program starts up, then fails during
>>>>>>> the run in some form of lockup, well after the initial startup code.
>>>>>>>
>>>>>>> If I run with the strace command, it always runs with -C0.00N.
>>>>>>>
>>>>>>> All the above was done with profiling enabled, so I removed that and
>>>>>>> instead enabled eventlog to look for clues.
>>>>>>>
>>>>>>> In this case it lies between good and bad, in that IO to my USB is
>>>>>>> working, but the GUI comes up blank and never paints. Running this
>>>>>>> case without -v0 (event log) the gui partially paints and stops, but
>>>>>>> USB continues.
>>>>>>>
>>>>>>> Questions:
>>>>>>>
>>>>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>>>>>> kinds of scheduling/thread problems?
>>>>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>>>>>> wxHaskell IO that leads to problems that a pure calculation app would
>>>>>>> not have?
>>>>>>> 3) Any ideas how to track down the problem when changing conditions
>>>>>>> (compiler or runtime options) affects behavior?
>>>>>>> 4) Are there other options besides -V and -C for the runtime that
>>>>>>> might apply?
>>>>>>> 5) What does -V0 do that makes a problem program run?
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>>
>>>>>>>  John,
>>>>>>>>
>>>>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>>>>>> more like -N4.
>>>>>>>>
>>>>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>>>>>> Atom and was stuck.
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>>>>>> <mailto:jwlato at gmail.com>> wrote:
>>>>>>>>
>>>>>>>>  By any chance do the delays get shorter if you run your program
>>>>>>>>> with
>>>>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>>>>>> thread scheduler.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>>>>
>>>>>>>>>     I have a general question about thread behavior in 7.8.3 vs
>>>>>>>>> 7.6.X
>>>>>>>>>
>>>>>>>>>     I moved from 7.6 to 7.8 and my application behaves very
>>>>>>>>>     differently. I have three threads, an application thread that
>>>>>>>>>     plots data with wxhaskell or sends it over a network (depends
>>>>>>>>> on
>>>>>>>>>     settings), a thread doing usb bulk writes, and a thread doing
>>>>>>>>>     usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>>>>>     used for coordination.
>>>>>>>>>
>>>>>>>>>     When the application was compiled with 7.6, my stream of usb
>>>>>>>>>     traffic was smooth. With 7.8, there are lots of delays where
>>>>>>>>>     nothing seems to be running. These delays are up to 40ms,
>>>>>>>>>     whereas with 7.6 delays were a 1ms or so.
>>>>>>>>>
>>>>>>>>>     When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>>>>>     runs fine without with -N2/4.
>>>>>>>>>
>>>>>>>>>     The program is compiled -O2 with profiling. The -N2/4 version
>>>>>>>>>     uses more memory,  but in both cases with 7.8 and with 7.6
>>>>>>>>> there
>>>>>>>>>     is no space leak.
>>>>>>>>>
>>>>>>>>>     I tired to compile and use -ls so I could take a look with
>>>>>>>>>     threadscope, but the application hangs and writes no data to
>>>>>>>>> the
>>>>>>>>>     file. The CPU fans run wild like it is in an infinite loop. It
>>>>>>>>>     at least pops an unpainted wxhaskell window, so it got
>>>>>>>>> partially
>>>>>>>>>     running.
>>>>>>>>>
>>>>>>>>>     One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>>>>>     around the compiler.
>>>>>>>>>
>>>>>>>>>     What do I need to know about changes to threading and event
>>>>>>>>>     logging between 7.6 and 7.8? Is there some general
>>>>>>>>> documentation
>>>>>>>>>     somewhere that might help?
>>>>>>>>>
>>>>>>>>>     I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>>>>>     ball and installed myself, after removing 7.6 with apt-get.
>>>>>>>>>
>>>>>>>>>     Any hints appreciated.
>>>>>>>>>
>>>>>>>>>     Mike
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     _______________________________________________
>>>>>>>>>     Glasgow-haskell-users mailing list
>>>>>>>>>     Glasgow-haskell-users at haskell.org
>>>>>>>>>     <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>>>>     http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Glasgow-haskell-users mailing list
>>>>>>> Glasgow-haskell-users at haskell.org
>>>>>>> <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Glasgow-haskell-users mailing list
>>>>>> Glasgow-haskell-users at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>
>>>>>>  _______________________________________________
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>
>>>>
>>>>
>>>>
>>
>>  _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/c3075b08/attachment-0001.html>

From verteiler at volker-wysk.de  Wed Jan 21 14:11:14 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Wed, 21 Jan 2015 15:11:14 +0100
Subject: "Found hole"
In-Reply-To: <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>
Message-ID: <3661051.MvIqtDsbpP@debian>

Am Mittwoch, 21. Januar 2015, 11:03:38 schrieben Sie:

> If there's any comments on how to improve the warning
> message to be less confusing I'd be interested to hear them.

What about "Found hole _foo with type: bar. This can also mean that _foo is 
not in scope".

Bye
V.W.

From david.feuer at gmail.com  Wed Jan 21 14:42:05 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 21 Jan 2015 09:42:05 -0500
Subject: "Found hole"
In-Reply-To: <3661051.MvIqtDsbpP@debian>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>
 <3661051.MvIqtDsbpP@debian>
Message-ID: <CAMgWh9stq0tpR3w8evfy+sTw08+q9XZ72fq0KX5Jo7pGsTNN-g@mail.gmail.com>

If such verbiage is added, it should probably read more like "If you did
not intend to insert a typed hole, _foo may have been misspelled."
On Jan 21, 2015 9:11 AM, "Volker Wysk" <verteiler at volker-wysk.de> wrote:

> Am Mittwoch, 21. Januar 2015, 11:03:38 schrieben Sie:
>
> > If there's any comments on how to improve the warning
> > message to be less confusing I'd be interested to hear them.
>
> What about "Found hole _foo with type: bar. This can also mean that _foo is
> not in scope".
>
> Bye
> V.W.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/b7e1317c/attachment.html>

From singpolyma at singpolyma.net  Wed Jan 21 14:53:50 2015
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Wed, 21 Jan 2015 09:53:50 -0500
Subject: "Found hole"
In-Reply-To: <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
Message-ID: <20150121145350.GB4848@singpolyma-liberty>

>The leading underscore invokes the typed holes extension. If you want to
>use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line
>of the source file. (I am not sure why this extension was enabled by
>default.)

This is very concening for me.  Extensions should *never* be enabled by 
default!  When the TypedHoles discussion originally came up there was 
definitely talk of using a switch to enable them (in fact, IIRC, they 
weren't originally really quite an extension, just a compiler mode, but that 
may have been a misinterpretation on my part).

Having them on by default mean that valid Haskell2010 programs might get 
rejected by GHC by default, which is a pretty bad state of affairs.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/24656ebc/attachment.sig>

From singpolyma at singpolyma.net  Wed Jan 21 14:55:49 2015
From: singpolyma at singpolyma.net (Stephen Paul Weber)
Date: Wed, 21 Jan 2015 09:55:49 -0500
Subject: "Found hole"
In-Reply-To: <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <4837C93F-65FA-4A58-88C2-CDD5856C35FB@inconsistent.nl>
Message-ID: <20150121145549.GC4848@singpolyma-liberty>

>Typed holes is not an extension, because it's considered a warning/error. 
>The reason for this is that code with typed holes is NOT valid haskell to 
>begin with, therefore the behaviour doesn't conflict with any description 
>in the report.

Well, now I feel very silly about my last email to this list.  This is what 
I understood.  I'm glad to see this is indeed the case.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/452bb1d0/attachment.sig>

From mike at proclivis.com  Wed Jan 21 14:56:16 2015
From: mike at proclivis.com (Michael Jones)
Date: Wed, 21 Jan 2015 07:56:16 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <54BF7CDA.2080600@gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
 <54BF7CDA.2080600@gmail.com>
Message-ID: <CC68AB10-2C05-4197-BE48-E76A3B62569E@proclivis.com>

Simon,

I went back and retested my non-GUI version and it seems to work fine. But here is what is strange, the non-GUI version is really just a client server version of what I have problems with. I have a non-GUI app running the USB and streaming data to a server. The client app (the one that has the lockup), works fine when in the client server mode. In this mode, it executes the very same code I listed below that locked up. The main difference is where in the code below it says: "Setup GUI components code was here?. The client server version just connects to the server rather than start up the USB IO. Strange that the behavior is so sensitive.

Is there any plans to make the scheduling more pre-emptive so that rogue threads can?t derail an application? Seems to open up lots of difficulties when you are reusing lots of libraries you are not familiar with to build a large application. The more libraries you use, the more unknown risk you are taking that you project is killed because you can?t meet a deadline.

I think I?ll let 7.10 settling down with one maintenance release and then give it a try just to see if it is any different. If that fails, I?ll scratch my head some more. What I don?t want to do is dig into wxHaskell?s FFI. I have a Python GUI started and I can just use that. The motivation for that was the inability to get wxHaskell to work on all three platforms (Windows, Linux, Mac), and getting python GUIs to work on all three was not too hard. Granted, I would prefer Haskell, but it is an enormous task to make a GUI work on all platforms. Unlike non-GUI libraries, it is not ?just works?, at least it wasn?t for me.

Mike

On Jan 21, 2015, at 3:18 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 21/01/2015 03:43, Michael Jones wrote:
>> Simon,
>> 
>> The code below hangs on the frameEx function.
>> 
>> But, if I change it to:
>> 
>>        f  <- frameCreate objectNull idAny "linti-scope PMBus Scope Tool" rectZero (frameDefaultStyle .|. wxMAXIMIZE)
>> 
>> it will progress, but no frame pops up, except once in many tries. Still hangs, but progresses through all the setup code.
>> 
>> However, I did make past statements that a non-GUI version was hanging. So I am not blaming wxHaskell. Just noting that in this case it is where things go wrong.
>> 
>> Anyone,
>> 
>> Are there any wxHaskell experts around that might have some insight?
>> 
>> (Remember, works on single core 32 bit, works on quad core 64 bit,
>> fails on 2 core 64 bit. Using GHC 7.8.3. Any recent updates to the
>> code base to fix problems like this?)
> 
> No, there are no recently fixed or outstanding bugs in this area that I'm aware of.
> 
> From the symptoms I strongly suspect there's an unsafe foreign call somewhere causing problems, or another busy-wait loop.
> 
> Cheers,
> Simon
> 
> 
>> 
>> ? CODE SAMPLE --------
>> 
>> gui :: IO ()
>> gui
>>   = do
>>        values <- varCreate []                            -- Values to be painted
>>        timeLine <- varCreate 0                           -- Line time
>>        sample <- varCreate 0                             -- Sample Number
>>        running <- varCreate True                         -- True when telemetry is active
>> 
>> <<HANG HERE>>
>> 
>>        f <- frameEx frameDefaultStyle [ text := "linti-scope PMBus Scope Tool"] objectNull
>> 
>> Setup GUI components code was here
>> 
>>        return ()
>> 
>> go :: IO ()
>> go = do
>>     putStrLn "Start GUI"
>>     start $ gui
>> 
>> exeMain :: IO ()
>> exeMain = do
>>   hSetBuffering stdout NoBuffering
>>   getArgs >>= parse
>>   where
>>     parse ["-h"] = usage   >> exit
>>     parse ["-v"] = version >> exit
>>     parse []     = go
>>     parse [url, port, session, target] = goServer url port (read session) (read target)
>> 
>>     usage   = putStrLn "Usage: linti-scope [url, port, session, target]"
>>     version = putStrLn "Haskell linti-scope 0.1.0.0"
>>     exit    = System.Exit.exitWith System.Exit.ExitSuccess
>>     die     = System.Exit.exitWith (System.Exit.ExitFailure 1)
>> 
>> #ifndef MAIN_FUNCTION
>> #define MAIN_FUNCTION exeMain
>> #endif
>> main = MAIN_FUNCTION
>> 
>> On Jan 20, 2015, at 9:00 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>>> My guess would be that either
>>> - a thread is in a non-allocating loop
>>> - a long-running foreign call is marked unsafe
>>> 
>>> Either of these would block the other threads.  ThreadScope together with some traceEventIO calls might help you identify the culprit.
>>> 
>>> Cheers,
>>> Simon
>>> 
>>> On 20/01/2015 15:49, Michael Jones wrote:
>>>> Simon,
>>>> 
>>>> This was fixed some time back. I combed the code base looking for other busy loops and there are no more. I commented out the code that runs the I2C + Machines + IO stuff, and only left the GUI code. It appears that just the wxhaskell part of the program fails to start. This matches a previous observation based on printing.
>>>> 
>>>> I?ll see if I can hack up the code to a minimal set that I can publish. All the IP is in the I2C code, so I might be able to get it down to one file.
>>>> 
>>>> Mike
>>>> 
>>>> On Jan 19, 2015, at 3:37 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>>> 
>>>>> Hi Michael,
>>>>> 
>>>>> Previously in this thread it was pointed out that your code was doing busy waiting, and so the problem can be fixed by modifying your code to not do busy waiting.  Did you do this?  The -C flag is just a workaround which will make the RTS reschedule more often, it won't fix the underlying problem.
>>>>> 
>>>>> The code you showed us was:
>>>>> 
>>>>> sendTransactions :: MonadIO m => SMBusDevice DeviceDC590 -> TVar Bool -> ProcessT m (Spec, String) ()
>>>>> sendTransactions dev dts = repeatedly $ do
>>>>>  dts' <- liftIO $ atomically $ readTVar dts
>>>>>  when (dts' == True) (do
>>>>>      (_, transactions) <- await
>>>>>      liftIO $ sendOut dev transactions)
>>>>> 
>>>>> This loops when the contents of the TVar is False.
>>>>> 
>>>>> Cheers,
>>>>> Simon
>>>>> 
>>>>> On 18/01/2015 01:15, Michael Jones wrote:
>>>>>> I have narrowed down the problem a bit. It turns out that many times if
>>>>>> I run the program and wait long enough, it will start. Given an event
>>>>>> log, it may take from 1000-10000 entries sometimes.
>>>>>> 
>>>>>> When I look at a good start vs. slow start, I see that in both cases
>>>>>> things startup and there is some thread activity for thread 2 and 3,
>>>>>> then the application starts creating other threads, which is when the
>>>>>> wxhaskell GUI pops up and IO out my /dev/i2c begins. In the slow case,
>>>>>> it just gets stuck on thread 2/3 activity for a very long time.
>>>>>> 
>>>>>> If I switch from -C0.001 to -C0.010, the startup is more reliable, in
>>>>>> that most starts result in an immediate GUI and i2c IO.
>>>>>> 
>>>>>> The behavior suggests to me that some initial threads are starving the
>>>>>> ability for other threads to start, and perhaps on a dual core machine
>>>>>> it is more of a problem than single or quad core machines. For certain,
>>>>>> due to some printing, I know that the main thread is starting, and that
>>>>>> a print just before the first fork is not printing. Code between them is
>>>>>> evaluating wxhaskell functions, but the main frame is not yet asked to
>>>>>> become visible. From last week, I know that an non-gui version of the
>>>>>> app is getting stuck, but I do not know if it eventually runs like this
>>>>>> case.
>>>>>> 
>>>>>> Is there some convention that when I look at an event log you can tell
>>>>>> which threads are OS threads vs threads from fork?
>>>>>> 
>>>>>> Perhaps someone that knows the scheduler might have some advice. It
>>>>>> seems odd that a scheduler could behave this way. The scheduler should
>>>>>> have some built in notion of fairness.
>>>>>> 
>>>>>> 
>>>>>> On Jan 12, 2015, at 11:02 PM, Michael Jones <mike at proclivis.com
>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>> 
>>>>>>> Sorry I am reviving an old problem, but it has resurfaced, such that
>>>>>>> one system behaves different than another.
>>>>>>> 
>>>>>>> Using -C0.001 solved problems on a Mac + VM + Ubuntu 14. It worked on
>>>>>>> a single core 32 bit Atom NUC. But on a dual core Atom MinnowBoardMax,
>>>>>>> something bad is going on. In summary, the same code that runs on two
>>>>>>> machines does not run on a third machine. So this indicates I have not
>>>>>>> made any breaking changes to the code or cabal files. Compiling with
>>>>>>> GHC 7.8.3.
>>>>>>> 
>>>>>>> This bad system has Ubuntu 14 installed, with an updated Linux 3.18.1
>>>>>>> kernel. It is a dual core 64 bit I86 Atom processor. The application
>>>>>>> hangs at startup. If I remove the -C0.00N option and instead use -V0,
>>>>>>> the application runs. It has bad timing properties, but it does at
>>>>>>> least run. Note that a hang hangs an IO thread talking USB, and the
>>>>>>> GUI thread.
>>>>>>> 
>>>>>>> When testing with the -C0.00N option, it did run 2 times out of 20
>>>>>>> tries, so fail means fail most but not all of the time. When it did
>>>>>>> run, it continued to run properly. This perhaps indicates some kind of
>>>>>>> internal race condition.
>>>>>>> 
>>>>>>> In the fail to run case, it does some printing up to the point where
>>>>>>> it tries to create a wxHaskell frame. In another non-UI version of the
>>>>>>> program it also fails to run. Logging to a file gives a similar
>>>>>>> indication. It is clear that the program starts up, then fails during
>>>>>>> the run in some form of lockup, well after the initial startup code.
>>>>>>> 
>>>>>>> If I run with the strace command, it always runs with -C0.00N.
>>>>>>> 
>>>>>>> All the above was done with profiling enabled, so I removed that and
>>>>>>> instead enabled eventlog to look for clues.
>>>>>>> 
>>>>>>> In this case it lies between good and bad, in that IO to my USB is
>>>>>>> working, but the GUI comes up blank and never paints. Running this
>>>>>>> case without -v0 (event log) the gui partially paints and stops, but
>>>>>>> USB continues.
>>>>>>> 
>>>>>>> Questions:
>>>>>>> 
>>>>>>> 1) Does ghc 7.8.4 have any improvements that might pertain to these
>>>>>>> kinds of scheduling/thread problems?
>>>>>>> 2) Is there anything about the nature of a thread using USB, I2C, or
>>>>>>> wxHaskell IO that leads to problems that a pure calculation app would
>>>>>>> not have?
>>>>>>> 3) Any ideas how to track down the problem when changing conditions
>>>>>>> (compiler or runtime options) affects behavior?
>>>>>>> 4) Are there other options besides -V and -C for the runtime that
>>>>>>> might apply?
>>>>>>> 5) What does -V0 do that makes a problem program run?
>>>>>>> 
>>>>>>> Mike
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Oct 29, 2014, at 6:02 PM, Michael Jones <mike at proclivis.com
>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>> 
>>>>>>>> John,
>>>>>>>> 
>>>>>>>> Adding -C0.005 makes it much better. Using -C0.001 makes it behave
>>>>>>>> more like -N4.
>>>>>>>> 
>>>>>>>> Thanks. This saves my project, as I need to deploy on a single core
>>>>>>>> Atom and was stuck.
>>>>>>>> 
>>>>>>>> Mike
>>>>>>>> 
>>>>>>>> On Oct 29, 2014, at 5:12 PM, John Lato <jwlato at gmail.com
>>>>>>>> <mailto:jwlato at gmail.com>> wrote:
>>>>>>>> 
>>>>>>>>> By any chance do the delays get shorter if you run your program with
>>>>>>>>> `+RTS -C0.005` ?  If so, I suspect you're having a problem very
>>>>>>>>> similar to one that we had with ghc-7.8 (7.6 too, but it's worse on
>>>>>>>>> ghc-7.8 for some reason), involving possible misbehavior of the
>>>>>>>>> thread scheduler.
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 29, 2014 at 2:18 PM, Michael Jones <mike at proclivis.com
>>>>>>>>> <mailto:mike at proclivis.com>> wrote:
>>>>>>>>> 
>>>>>>>>>    I have a general question about thread behavior in 7.8.3 vs 7.6.X
>>>>>>>>> 
>>>>>>>>>    I moved from 7.6 to 7.8 and my application behaves very
>>>>>>>>>    differently. I have three threads, an application thread that
>>>>>>>>>    plots data with wxhaskell or sends it over a network (depends on
>>>>>>>>>    settings), a thread doing usb bulk writes, and a thread doing
>>>>>>>>>    usb bulk reads. Data is moved around with TChan, and TVar is
>>>>>>>>>    used for coordination.
>>>>>>>>> 
>>>>>>>>>    When the application was compiled with 7.6, my stream of usb
>>>>>>>>>    traffic was smooth. With 7.8, there are lots of delays where
>>>>>>>>>    nothing seems to be running. These delays are up to 40ms,
>>>>>>>>>    whereas with 7.6 delays were a 1ms or so.
>>>>>>>>> 
>>>>>>>>>    When I add -N2 or -N4, the 7.8 program runs fine. But on 7.6 it
>>>>>>>>>    runs fine without with -N2/4.
>>>>>>>>> 
>>>>>>>>>    The program is compiled -O2 with profiling. The -N2/4 version
>>>>>>>>>    uses more memory,  but in both cases with 7.8 and with 7.6 there
>>>>>>>>>    is no space leak.
>>>>>>>>> 
>>>>>>>>>    I tired to compile and use -ls so I could take a look with
>>>>>>>>>    threadscope, but the application hangs and writes no data to the
>>>>>>>>>    file. The CPU fans run wild like it is in an infinite loop. It
>>>>>>>>>    at least pops an unpainted wxhaskell window, so it got partially
>>>>>>>>>    running.
>>>>>>>>> 
>>>>>>>>>    One of my libraries uses option -fsimpl-tick-factor=200 to get
>>>>>>>>>    around the compiler.
>>>>>>>>> 
>>>>>>>>>    What do I need to know about changes to threading and event
>>>>>>>>>    logging between 7.6 and 7.8? Is there some general documentation
>>>>>>>>>    somewhere that might help?
>>>>>>>>> 
>>>>>>>>>    I am on Ubuntu 14.04 LTS. I downloaded the 7.8 tool chain tar
>>>>>>>>>    ball and installed myself, after removing 7.6 with apt-get.
>>>>>>>>> 
>>>>>>>>>    Any hints appreciated.
>>>>>>>>> 
>>>>>>>>>    Mike
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>    _______________________________________________
>>>>>>>>>    Glasgow-haskell-users mailing list
>>>>>>>>>    Glasgow-haskell-users at haskell.org
>>>>>>>>>    <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>>>>    http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Glasgow-haskell-users mailing list
>>>>>>> Glasgow-haskell-users at haskell.org
>>>>>>> <mailto:Glasgow-haskell-users at haskell.org>
>>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Glasgow-haskell-users mailing list
>>>>>> Glasgow-haskell-users at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>>>> 
>>>>> _______________________________________________
>>>>> Glasgow-haskell-users mailing list
>>>>> Glasgow-haskell-users at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>> 
>>>> 
>> 
>> 



From david.feuer at gmail.com  Wed Jan 21 15:11:05 2015
From: david.feuer at gmail.com (David Feuer)
Date: Wed, 21 Jan 2015 10:11:05 -0500
Subject: "Found hole"
In-Reply-To: <20150121145350.GB4848@singpolyma-liberty>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <20150121145350.GB4848@singpolyma-liberty>
Message-ID: <CAMgWh9t2Wd+WpMJe8HYSg5g4=CJpzBu13iAe8609SD5FWQycrA@mail.gmail.com>

On Jan 21, 2015 9:53 AM, "Stephen Paul Weber" <singpolyma at singpolyma.net>
wrote:

> Having them on by default mean that valid Haskell2010 programs might get
rejected by GHC by default, which is a pretty bad state of affairs.

It would be if it were true. But it's not. All that changes is that you get
different error messages in some cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/03a2570d/attachment.html>

From verteiler at volker-wysk.de  Wed Jan 21 15:25:24 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Wed, 21 Jan 2015 16:25:24 +0100
Subject: "Found hole"
In-Reply-To: <CAMgWh9stq0tpR3w8evfy+sTw08+q9XZ72fq0KX5Jo7pGsTNN-g@mail.gmail.com>
References: <4314332.VFU07dKVqU@debian> <3661051.MvIqtDsbpP@debian>
 <CAMgWh9stq0tpR3w8evfy+sTw08+q9XZ72fq0KX5Jo7pGsTNN-g@mail.gmail.com>
Message-ID: <4592536.AcuszVuQNN@debian>

Am Mittwoch, 21. Januar 2015, 09:42:05 schrieben Sie:
> If such verbiage is added, it should probably read more like "If you did
> not intend to insert a typed hole, _foo may have been misspelled."

What about "If you did not intend to insert a typed hole, _foo may have been 
misspelled or out of scope." In my case, it has been out of scope, but not 
misspelled.

I think verbiage is a good thing in this case.

Bye
V.W.

From verteiler at volker-wysk.de  Wed Jan 21 15:36:08 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Wed, 21 Jan 2015 16:36:08 +0100
Subject: How to remove a cabal package from the local system?
Message-ID: <1432043.CqTmocIONc@debian>

Hi!

I have installed/registered a new version of a package with cabal by accident. 
How can I remove it again?

There is something in ~/.cabal/packages/hackage.haskell.org, but the defective 
version isn't included. 

bye
V.W.

From qdunkan at gmail.com  Wed Jan 21 15:56:53 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 21 Jan 2015 23:56:53 +0800
Subject: How to remove a cabal package from the local system?
In-Reply-To: <1432043.CqTmocIONc@debian>
References: <1432043.CqTmocIONc@debian>
Message-ID: <CACbaDy54iHLb_48O7SHxDa83W2w1HJHv7Si9EYya28j0k4oawg@mail.gmail.com>

I use a shell script.  It's really useful, surely there's some
official way to do this?

#!/bin/zsh

package=$1

if ! ghc-pkg describe $package >/dev/null; then
    echo no such package: $package
    exit 1
fi

ghcdir=$(ghc --print-libdir)

function field() {
    ghc-pkg field $package $1 | cut -d' ' -f2-
    return $?
}

libdir=$(field library-dirs)
hidir=$(field import-dirs)
html=$(dirname $(field haddock-html))

echo rm -rf $libdir $hidir $html
echo -n 'remove? '
read response
if [[ $response = y ]]; then
    # ghc-pkg unregister will complain if this will break other packages
    if ! ghc-pkg unregister $package; then
        exit 1
    fi
    rm -rf $libdir $hidir $html
fi

On Wed, Jan 21, 2015 at 11:36 PM, Volker Wysk <verteiler at volker-wysk.de> wrote:
> Hi!
>
> I have installed/registered a new version of a package with cabal by accident.
> How can I remove it again?
>
> There is something in ~/.cabal/packages/hackage.haskell.org, but the defective
> version isn't included.
>
> bye
> V.W.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

From verteiler at volker-wysk.de  Wed Jan 21 16:19:34 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Wed, 21 Jan 2015 17:19:34 +0100
Subject: How to remove a cabal package from the local system?
In-Reply-To: <CACbaDy54iHLb_48O7SHxDa83W2w1HJHv7Si9EYya28j0k4oawg@mail.gmail.com>
References: <1432043.CqTmocIONc@debian>
 <CACbaDy54iHLb_48O7SHxDa83W2w1HJHv7Si9EYya28j0k4oawg@mail.gmail.com>
Message-ID: <1772252.4rgispvlCs@debian>

Am Mittwoch, 21. Januar 2015, 23:56:53 schrieben Sie:
> I use a shell script.  It's really useful, surely there's some
> official way to do this?

It looks like a "remove" command to "cabal" has been forgotten... This would 
be a feature request.

I'm also missing a command to set the "Default available version".

Thanks for the script!

Volker


From allbery.b at gmail.com  Wed Jan 21 16:33:57 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 21 Jan 2015 11:33:57 -0500
Subject: How to remove a cabal package from the local system?
In-Reply-To: <1772252.4rgispvlCs@debian>
References: <1432043.CqTmocIONc@debian>
 <CACbaDy54iHLb_48O7SHxDa83W2w1HJHv7Si9EYya28j0k4oawg@mail.gmail.com>
 <1772252.4rgispvlCs@debian>
Message-ID: <CAKFCL4V9rgsiYSM_Uf=Dm1KT8zR3Kb1sp5u+SgYso60gHjNGyQ@mail.gmail.com>

On Wed, Jan 21, 2015 at 11:19 AM, Volker Wysk <verteiler at volker-wysk.de>
wrote:

> I'm also missing a command to set the "Default available version".
>

You don't set that; it's specified in the downloaded package index in the
package repo.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/148fb8ce/attachment.html>

From allbery.b at gmail.com  Wed Jan 21 16:42:49 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 21 Jan 2015 11:42:49 -0500
Subject: "Found hole"
In-Reply-To: <20150121145350.GB4848@singpolyma-liberty>
References: <4314332.VFU07dKVqU@debian>
 <CAKFCL4Xi-nKvkGpeZTFEPH-OuvQtmDt7feQBNvhhUh8ZFP52Qg@mail.gmail.com>
 <20150121145350.GB4848@singpolyma-liberty>
Message-ID: <CAKFCL4W3B_U+ZGjhRGoySaobL9F9tuH53gJtUeR5CqS7EYGpyA@mail.gmail.com>

On Wed, Jan 21, 2015 at 9:53 AM, Stephen Paul Weber <
singpolyma at singpolyma.net> wrote:

> This is very concening for me.  Extensions should *never* be enabled by
> default!


If you read on, you'll find that I was working from an older proposal that
was never implemented. It is instead a modified version of a normal error
message, and the syntax used ensures that it is always an error anyway,
since it can only be invoked with either illegal expression syntax "_" or
an *undefined* name "_foo").

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150121/52294ef1/attachment.html>

From hvr at gnu.org  Wed Jan 21 18:39:50 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Wed, 21 Jan 2015 19:39:50 +0100
Subject: How to remove a cabal package from the local system?
In-Reply-To: <1432043.CqTmocIONc@debian> (Volker Wysk's message of "Wed, 21
 Jan 2015 16:36:08 +0100")
References: <1432043.CqTmocIONc@debian>
Message-ID: <87egqougeh.fsf@gnu.org>

On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote:
> I have installed/registered a new version of a package with cabal by accident. 
> How can I remove it again?

Not sure if this is what you want, but the `cab` tool has an `uninstall`
sub-command to unregister and remove installed packages.

 [1]: http://hackage.haskell.org/package/cab


From v.dijk.bas at gmail.com  Wed Jan 21 19:52:15 2015
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed, 21 Jan 2015 20:52:15 +0100
Subject: Thread behavior in 7.8.3
In-Reply-To: <CC68AB10-2C05-4197-BE48-E76A3B62569E@proclivis.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
 <54BF7CDA.2080600@gmail.com>
 <CC68AB10-2C05-4197-BE48-E76A3B62569E@proclivis.com>
Message-ID: <CADLz5wW2bPvYur+1awo-WRv_ukoZJ94pj-8=0UmgaWg50s8YRg@mail.gmail.com>

Hi Michael,

Are you already using usb-1.3.0.0? If not, could you upgrade and test
again? That release fixed the deadlock that Ben and Carter where
talking about.

Good luck,

Bas

From mike at proclivis.com  Wed Jan 21 21:02:21 2015
From: mike at proclivis.com (Michael Jones)
Date: Wed, 21 Jan 2015 14:02:21 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <CADLz5wW2bPvYur+1awo-WRv_ukoZJ94pj-8=0UmgaWg50s8YRg@mail.gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
 <54BF7CDA.2080600@gmail.com>
 <CC68AB10-2C05-4197-BE48-E76A3B62569E@proclivis.com>
 <CADLz5wW2bPvYur+1awo-WRv_ukoZJ94pj-8=0UmgaWg50s8YRg@mail.gmail.com>
Message-ID: <F4816BEC-471B-4C7B-8BC0-C091FD355387@proclivis.com>

Bas,

I have not upgraded, mainly because my problems manifest without enabling USB. However, I think I can upgrade in a few days and move forward.

Are you using ghc 7.8.10 these days or something older?

Mike

On Jan 21, 2015, at 12:52 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:

> Hi Michael,
> 
> Are you already using usb-1.3.0.0? If not, could you upgrade and test
> again? That release fixed the deadlock that Ben and Carter where
> talking about.
> 
> Good luck,
> 
> Bas



From mike at proclivis.com  Thu Jan 22 01:30:15 2015
From: mike at proclivis.com (Michael Jones)
Date: Wed, 21 Jan 2015 18:30:15 -0700
Subject: Thread behavior in 7.8.3
In-Reply-To: <CADLz5wW2bPvYur+1awo-WRv_ukoZJ94pj-8=0UmgaWg50s8YRg@mail.gmail.com>
References: <A36A6C7B-0983-4398-AD7F-FEC2A95F0CA8@proclivis.com>
 <CAJ727Gjg8pYjVx8BmicrGGF-NLBXKowxHRLJCUo=OkhVv5ZePQ@mail.gmail.com>
 <D9602CC7-5756-413E-A502-8FF13F9CDE8B@proclivis.com>
 <69D441DE-5184-4C3A-B36E-F30F42322696@proclivis.com>
 <6F33868F-D58B-4522-9098-4FEE19BEBC7F@proclivis.com>
 <54BCDE7F.6050908@gmail.com>
 <5BF325B7-EE64-408B-A658-575D9E65B7F2@proclivis.com>
 <54BE7B88.5000209@gmail.com>
 <D402788D-955C-476D-8B38-7B1CCC15F45B@proclivis.com>
 <54BF7CDA.2080600@gmail.com>
 <CC68AB10-2C05-4197-BE48-E76A3B62569E@proclivis.com>
 <CADLz5wW2bPvYur+1awo-WRv_ukoZJ94pj-8=0UmgaWg50s8YRg@mail.gmail.com>
Message-ID: <89915CF4-7C95-49E3-B1EC-96645B0987C8@proclivis.com>

Bas,

I checked my cabal file and I was already using 1.3.0.0.

Mike

On Jan 21, 2015, at 12:52 PM, Bas van Dijk <v.dijk.bas at gmail.com> wrote:

> Hi Michael,
> 
> Are you already using usb-1.3.0.0? If not, could you upgrade and test
> again? That release fixed the deadlock that Ben and Carter where
> talking about.
> 
> Good luck,
> 
> Bas



From verteiler at volker-wysk.de  Thu Jan 22 08:04:30 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Thu, 22 Jan 2015 09:04:30 +0100
Subject: How to remove a cabal package from the local system?
In-Reply-To: <87egqougeh.fsf@gnu.org>
References: <1432043.CqTmocIONc@debian> <87egqougeh.fsf@gnu.org>
Message-ID: <2531011.4dVXmujz0B@debian>

Am Mittwoch, 21. Januar 2015, 19:39:50 schrieben Sie:
> On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote:
> > I have installed/registered a new version of a package with cabal by
> > accident. How can I remove it again?
> 
> Not sure if this is what you want, but the `cab` tool has an `uninstall`
> sub-command to unregister and remove installed packages.
> 
>  [1]: http://hackage.haskell.org/package/cab

Yes, this is what I want. But Evan's script works fine. I think I will stick to 
it.

Greeting
Volker

From hvr at gnu.org  Thu Jan 22 09:01:04 2015
From: hvr at gnu.org (Herbert Valerio Riedel)
Date: Thu, 22 Jan 2015 10:01:04 +0100
Subject: How to remove a cabal package from the local system?
In-Reply-To: <2531011.4dVXmujz0B@debian> (Volker Wysk's message of "Thu, 22
 Jan 2015 09:04:30 +0100")
References: <1432043.CqTmocIONc@debian> <87egqougeh.fsf@gnu.org>
 <2531011.4dVXmujz0B@debian>
Message-ID: <873873qje7.fsf@gnu.org>

On 2015-01-22 at 09:04:30 +0100, Volker Wysk wrote:
>> > I have installed/registered a new version of a package with cabal by
>> > accident. How can I remove it again?
>> 
>> Not sure if this is what you want, but the `cab` tool has an `uninstall`
>> sub-command to unregister and remove installed packages.
>> 
>>  [1]: http://hackage.haskell.org/package/cab
>
> Yes, this is what I want. But Evan's script works fine. I think I will stick to 
> it.

There's one thing though that Evan's script doesn't handle afaics:
recursive de-installation of packages that depend upon the package
version you're uninstalling...

Hopefully at some point `cabal` will provide a `uninstall` command out
of the box, you can subscribe to the respective GitHub issue if you want
to follow that discussion:

  https://github.com/haskell/cabal/issues/227

Cheers,
  hvr

From trebla at vex.net  Thu Jan 22 16:19:37 2015
From: trebla at vex.net (Albert Y. C. Lai)
Date: Thu, 22 Jan 2015 11:19:37 -0500
Subject: How to remove a cabal package from the local system?
In-Reply-To: <1432043.CqTmocIONc@debian>
References: <1432043.CqTmocIONc@debian>
Message-ID: <54C12319.3080605@vex.net>

On 2015-01-21 10:36 AM, Volker Wysk wrote:
> I have installed/registered a new version of a package with cabal by accident.
> How can I remove it again?

See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact, 
read the whole thing.

From johnw at newartisans.com  Thu Jan 22 18:41:49 2015
From: johnw at newartisans.com (John Wiegley)
Date: Thu, 22 Jan 2015 12:41:49 -0600
Subject: ANN: git-monitor
Message-ID: <m2bnlqhd3m.fsf@newartisans.com>

git-monitor auto-commits all changes to a Git working tree, within a special
branch named "refs/snapshots/refs/heads/<branch>".  It has no impact on the
Git repository otherwise, and will not effect your real branches.

It has the following features:

  - It is designed to be extremely resource efficient, both in CPU cost and
    memory.  I wanted something I could run several instances of on my laptop,
    without paying much of a battery cost.

    This efficiency is achieved by using gitlib with the libgit2 backend.  The
    current state of the working tree is maintained as a Git object in memory,
    and is updated in place before being written back out to disk.  Thus, the
    amount of computation done remains minimal, as we do not need to rebuild
    the Git tree at each iteration (as "git-commit" would do).

  - Whenever git-monitor is exited and restarted, the previous snapshot
    "branch" is discarded.  These are only intended to be viable during and
    between runs.

  - By having such a branch, you can easily browse through the diffs of your
    changes throughout the day.

By default, every action taken is printed to the console where git-monitor is
run, but it can also be run in silent mode, for example if you choose to
background it for the rest of the day.

    http://hackage.haskell.org/package/git-monitor

    https://github.com/jwiegley/git-monitor

Please report issues to the GitHub page.  I have been using git-monitor on a
regular basis for more than a year now, so I felt it finally deserved an
announcement here.

Thank you,
  John Wiegley (johnw on IRC/freenode)

From alexander.vershilov at gmail.com  Fri Jan 23 08:45:02 2015
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Fri, 23 Jan 2015 12:45:02 +0400
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <54BE67A8.5050108@ro-che.info>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
 <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
 <54BE67A8.5050108@ro-che.info>
Message-ID: <CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>

Hi.

As far as I understand  it was fixed as:

commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Mon Dec 1 17:07:48 2014 +0000

    Fix parser for UNPACK pragmas

       {-# NOUNPACK #-}
       {-# NOUNPACK #-} !
    were being parsed the same way.  The former was wrong.

    Thanks to Alan Zimmerman for pointing this out


So it will fix is in 7.10. And I can't reproduce this anymore on
ghc-HEAD.


On 20 January 2015 at 17:35, Roman Cheplyaka <roma at ro-che.info> wrote:
> Interesting question. I managed to trace this to:
>
> compiler/basicTypes/MkId.hs:699
>
> isUnpackableType fam_envs ty
>   | Just (tc, _) <- splitTyConApp_maybe ty
>   , Just con <- tyConSingleAlgDataCon_maybe tc
>   , isVanillaDataCon con
>   = ok_con_args (unitNameSet (getName tc)) con
>   | otherwise
>   = False
>
> where isVanillaDataCon is defined as:
>
> dcVanilla :: Bool,
> -- True <=> This is a vanilla Haskell 98 data constructor
> --          Its type is of form
> --              forall a1..an . t1 -> ... tm -> T a1..an
> --          No existentials, no coercions, nothing.
>
> There's no explanation why this limitation is introduced; it might be
> just a conservative one.
>
> On 20/01/15 15:08, Nicholas Clarke wrote:
>> I'd like to be able to use the UNPACK pragma on an existentially
>> quantified datatype. So as in the below example:
>>
>> {-# LANGUAGE ExistentialQuantification #-}
>>
>> data Foo = forall a. Show a => Foo !a
>> instance Show Foo where
>>   show (Foo a) = "Foo! " ++ show a
>>
>> data Bar =
>>     Bar {-# UNPACK #-} !Foo
>>   deriving (Show)
>>
>> main :: IO ()
>> main = do
>>   let foo = Foo "Hello"
>>       bar = Bar foo
>>   print bar
>>
>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
>> had written:
>>
>> data Bar = forall a. Show a => Bar !a
>>
>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
>> argument of ?Bar?' warning. Is there a reason this shouldn't work, or a
>> workaround to get it to do so?
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users



-- 
Alexander

From roma at ro-che.info  Fri Jan 23 08:49:21 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 23 Jan 2015 10:49:21 +0200
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>	<CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>	<54BE67A8.5050108@ro-che.info>
 <CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>
Message-ID: <54C20B11.4070205@ro-che.info>

How is parsing of the *NOUNPACK* pragma relevant here?

On 23/01/15 10:45, Alexander V Vershilov wrote:
> Hi.
> 
> As far as I understand  it was fixed as:
> 
> commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
> Author: Simon Peyton Jones <simonpj at microsoft.com>
> Date:   Mon Dec 1 17:07:48 2014 +0000
> 
>     Fix parser for UNPACK pragmas
> 
>        {-# NOUNPACK #-}
>        {-# NOUNPACK #-} !
>     were being parsed the same way.  The former was wrong.
> 
>     Thanks to Alan Zimmerman for pointing this out
> 
> 
> So it will fix is in 7.10. And I can't reproduce this anymore on
> ghc-HEAD.
> 
> 
> On 20 January 2015 at 17:35, Roman Cheplyaka <roma at ro-che.info> wrote:
>> Interesting question. I managed to trace this to:
>>
>> compiler/basicTypes/MkId.hs:699
>>
>> isUnpackableType fam_envs ty
>>   | Just (tc, _) <- splitTyConApp_maybe ty
>>   , Just con <- tyConSingleAlgDataCon_maybe tc
>>   , isVanillaDataCon con
>>   = ok_con_args (unitNameSet (getName tc)) con
>>   | otherwise
>>   = False
>>
>> where isVanillaDataCon is defined as:
>>
>> dcVanilla :: Bool,
>> -- True <=> This is a vanilla Haskell 98 data constructor
>> --          Its type is of form
>> --              forall a1..an . t1 -> ... tm -> T a1..an
>> --          No existentials, no coercions, nothing.
>>
>> There's no explanation why this limitation is introduced; it might be
>> just a conservative one.
>>
>> On 20/01/15 15:08, Nicholas Clarke wrote:
>>> I'd like to be able to use the UNPACK pragma on an existentially
>>> quantified datatype. So as in the below example:
>>>
>>> {-# LANGUAGE ExistentialQuantification #-}
>>>
>>> data Foo = forall a. Show a => Foo !a
>>> instance Show Foo where
>>>   show (Foo a) = "Foo! " ++ show a
>>>
>>> data Bar =
>>>     Bar {-# UNPACK #-} !Foo
>>>   deriving (Show)
>>>
>>> main :: IO ()
>>> main = do
>>>   let foo = Foo "Hello"
>>>       bar = Bar foo
>>>   print bar
>>>
>>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
>>> had written:
>>>
>>> data Bar = forall a. Show a => Bar !a
>>>
>>> However, instead I get the 'Ignoring unusable UNPACK pragma on the first
>>> argument of ?Bar?' warning. Is there a reason this shouldn't work, or a
>>> workaround to get it to do so?
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> 
> 
> 


From alexander.vershilov at gmail.com  Fri Jan 23 08:53:24 2015
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Fri, 23 Jan 2015 12:53:24 +0400
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <54C20B11.4070205@ro-che.info>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
 <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
 <54BE67A8.5050108@ro-che.info>
 <CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>
 <54C20B11.4070205@ro-che.info>
Message-ID: <CAO-1Pb5zhO2=qMwqVJayLexQBFUeU+DYXCQGMfd-Wq2FRXbA2Q@mail.gmail.com>

Please take a took at that commit, UNPACK was also handled there, despite
commit message do not explicitly state this.
On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <roma at ro-che.info> wrote:

> How is parsing of the *NOUNPACK* pragma relevant here?
>
> On 23/01/15 10:45, Alexander V Vershilov wrote:
> > Hi.
> >
> > As far as I understand  it was fixed as:
> >
> > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
> > Author: Simon Peyton Jones <simonpj at microsoft.com>
> > Date:   Mon Dec 1 17:07:48 2014 +0000
> >
> >     Fix parser for UNPACK pragmas
> >
> >        {-# NOUNPACK #-}
> >        {-# NOUNPACK #-} !
> >     were being parsed the same way.  The former was wrong.
> >
> >     Thanks to Alan Zimmerman for pointing this out
> >
> >
> > So it will fix is in 7.10. And I can't reproduce this anymore on
> > ghc-HEAD.
> >
> >
> > On 20 January 2015 at 17:35, Roman Cheplyaka <roma at ro-che.info> wrote:
> >> Interesting question. I managed to trace this to:
> >>
> >> compiler/basicTypes/MkId.hs:699
> >>
> >> isUnpackableType fam_envs ty
> >>   | Just (tc, _) <- splitTyConApp_maybe ty
> >>   , Just con <- tyConSingleAlgDataCon_maybe tc
> >>   , isVanillaDataCon con
> >>   = ok_con_args (unitNameSet (getName tc)) con
> >>   | otherwise
> >>   = False
> >>
> >> where isVanillaDataCon is defined as:
> >>
> >> dcVanilla :: Bool,
> >> -- True <=> This is a vanilla Haskell 98 data constructor
> >> --          Its type is of form
> >> --              forall a1..an . t1 -> ... tm -> T a1..an
> >> --          No existentials, no coercions, nothing.
> >>
> >> There's no explanation why this limitation is introduced; it might be
> >> just a conservative one.
> >>
> >> On 20/01/15 15:08, Nicholas Clarke wrote:
> >>> I'd like to be able to use the UNPACK pragma on an existentially
> >>> quantified datatype. So as in the below example:
> >>>
> >>> {-# LANGUAGE ExistentialQuantification #-}
> >>>
> >>> data Foo = forall a. Show a => Foo !a
> >>> instance Show Foo where
> >>>   show (Foo a) = "Foo! " ++ show a
> >>>
> >>> data Bar =
> >>>     Bar {-# UNPACK #-} !Foo
> >>>   deriving (Show)
> >>>
> >>> main :: IO ()
> >>> main = do
> >>>   let foo = Foo "Hello"
> >>>       bar = Bar foo
> >>>   print bar
> >>>
> >>> I would expect the `Foo` constructor to be unpacked into Bar, as if I
> >>> had written:
> >>>
> >>> data Bar = forall a. Show a => Bar !a
> >>>
> >>> However, instead I get the 'Ignoring unusable UNPACK pragma on the
> first
> >>> argument of ?Bar?' warning. Is there a reason this shouldn't work, or a
> >>> workaround to get it to do so?
> >>
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users at haskell.org
> >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150123/d075478b/attachment.html>

From roma at ro-che.info  Fri Jan 23 08:59:35 2015
From: roma at ro-che.info (Roman Cheplyaka)
Date: Fri, 23 Jan 2015 10:59:35 +0200
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <CAO-1Pb5zhO2=qMwqVJayLexQBFUeU+DYXCQGMfd-Wq2FRXbA2Q@mail.gmail.com>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>	<CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>	<54BE67A8.5050108@ro-che.info>	<CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>	<54C20B11.4070205@ro-che.info>
 <CAO-1Pb5zhO2=qMwqVJayLexQBFUeU+DYXCQGMfd-Wq2FRXbA2Q@mail.gmail.com>
Message-ID: <54C20D77.7020303@ro-che.info>

I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
changed line (NOUNPACK).

On 23/01/15 10:53, Alexander V Vershilov wrote:
> Please take a took at that commit, UNPACK was also handled there,
> despite commit message do not explicitly state this.
> 
> On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <roma at ro-che.info
> <mailto:roma at ro-che.info>> wrote:
> 
>     How is parsing of the *NOUNPACK* pragma relevant here?
> 
>     On 23/01/15 10:45, Alexander V Vershilov wrote:
>     > Hi.
>     >
>     > As far as I understand  it was fixed as:
>     >
>     > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
>     > Author: Simon Peyton Jones <simonpj at microsoft.com
>     <mailto:simonpj at microsoft.com>>
>     > Date:   Mon Dec 1 17:07:48 2014 +0000
>     >
>     >     Fix parser for UNPACK pragmas
>     >
>     >        {-# NOUNPACK #-}
>     >        {-# NOUNPACK #-} !
>     >     were being parsed the same way.  The former was wrong.
>     >
>     >     Thanks to Alan Zimmerman for pointing this out
>     >
>     >
>     > So it will fix is in 7.10. And I can't reproduce this anymore on
>     > ghc-HEAD.
>     >
>     >
>     > On 20 January 2015 at 17:35, Roman Cheplyaka <roma at ro-che.info
>     <mailto:roma at ro-che.info>> wrote:
>     >> Interesting question. I managed to trace this to:
>     >>
>     >> compiler/basicTypes/MkId.hs:699
>     >>
>     >> isUnpackableType fam_envs ty
>     >>   | Just (tc, _) <- splitTyConApp_maybe ty
>     >>   , Just con <- tyConSingleAlgDataCon_maybe tc
>     >>   , isVanillaDataCon con
>     >>   = ok_con_args (unitNameSet (getName tc)) con
>     >>   | otherwise
>     >>   = False
>     >>
>     >> where isVanillaDataCon is defined as:
>     >>
>     >> dcVanilla :: Bool,
>     >> -- True <=> This is a vanilla Haskell 98 data constructor
>     >> --          Its type is of form
>     >> --              forall a1..an . t1 -> ... tm -> T a1..an
>     >> --          No existentials, no coercions, nothing.
>     >>
>     >> There's no explanation why this limitation is introduced; it might be
>     >> just a conservative one.
>     >>
>     >> On 20/01/15 15:08, Nicholas Clarke wrote:
>     >>> I'd like to be able to use the UNPACK pragma on an existentially
>     >>> quantified datatype. So as in the below example:
>     >>>
>     >>> {-# LANGUAGE ExistentialQuantification #-}
>     >>>
>     >>> data Foo = forall a. Show a => Foo !a
>     >>> instance Show Foo where
>     >>>   show (Foo a) = "Foo! " ++ show a
>     >>>
>     >>> data Bar =
>     >>>     Bar {-# UNPACK #-} !Foo
>     >>>   deriving (Show)
>     >>>
>     >>> main :: IO ()
>     >>> main = do
>     >>>   let foo = Foo "Hello"
>     >>>       bar = Bar foo
>     >>>   print bar
>     >>>
>     >>> I would expect the `Foo` constructor to be unpacked into Bar, as
>     if I
>     >>> had written:
>     >>>
>     >>> data Bar = forall a. Show a => Bar !a
>     >>>
>     >>> However, instead I get the 'Ignoring unusable UNPACK pragma on
>     the first
>     >>> argument of ?Bar?' warning. Is there a reason this shouldn't
>     work, or a
>     >>> workaround to get it to do so?
>     >>
>     >> _______________________________________________
>     >> Glasgow-haskell-users mailing list
>     >> Glasgow-haskell-users at haskell.org
>     <mailto:Glasgow-haskell-users at haskell.org>
>     >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>     >
>     >
>     >
> 


From alexander.vershilov at gmail.com  Fri Jan 23 09:35:21 2015
From: alexander.vershilov at gmail.com (Alexander V Vershilov)
Date: Fri, 23 Jan 2015 13:35:21 +0400
Subject: Fwd: UNPACK Existential datatype
In-Reply-To: <54C20D77.7020303@ro-che.info>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
 <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
 <54BE67A8.5050108@ro-che.info>
 <CAO-1Pb6HkBsGuD-JJw14pm7qgSqh797i0oGvF1MXi64QMG-Tew@mail.gmail.com>
 <54C20B11.4070205@ro-che.info>
 <CAO-1Pb5zhO2=qMwqVJayLexQBFUeU+DYXCQGMfd-Wq2FRXbA2Q@mail.gmail.com>
 <54C20D77.7020303@ro-che.info>
Message-ID: <CAO-1Pb5kMYJ7wrG_qsiW2+CX1dvFZ6hypBN_H6hV5-awkLVPhQ@mail.gmail.com>

Very strange, I was referring to:

git show 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27

commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Mon Dec 1 17:07:48 2014 +0000

    Fix parser for UNPACK pragmas

       {-# NOUNPACK #-}
       {-# NOUNPACK #-} !
    were being parsed the same way.  The former was wrong.

    Thanks to Alan Zimmerman for pointing this out

diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
index e3f82ce..c7143ae 100644
--- a/compiler/parser/Parser.y
+++ b/compiler/parser/Parser.y
@@ -1350,11 +1350,11 @@ sigtypes1 :: { (OrdList (LHsType RdrName)) }
   -- Always HsForAllTys
 -- Types

 strict_mark :: { Located ([AddAnn],HsBang) }
-        : '!'                        { sL1 $1 ([],HsUserBang Nothing
    True) }
-        | '{-# UNPACK' '#-}'         { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just True)  False) }
-        | '{-# NOUNPACK' '#-}'       { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just False) True) }
-        | '{-# UNPACK' '#-}' '!'     { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just True)  True) }
-        | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc
$2],HsUserBang (Just False) True) }
+        : '!'                        { sL1 $1    ([],
HsUserBang Nothing      True) }
+        | '{-# UNPACK' '#-}'         { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just True)  False) }
+        | '{-# NOUNPACK' '#-}'       { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just False) False) }
+        | '{-# UNPACK' '#-}' '!'     { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just True)  True) }
+        | '{-# NOUNPACK' '#-}' '!'   { sLL $1 $> ([mo $1,mc $2],
HsUserBang (Just False) True) }
         -- Although UNPACK with no '!' is illegal, we get a
         -- better error message if we parse it here

I'm not sure that is there were no other commits that that are
related to the issue. TBH, I can't see warnings for this example
program  that was mentioned in this thread using GHC-HEAD,
but having either `{-# UNPACK #-} !` or `!` or `{-# UNPACK #-}`
do not change core output, regardless whether -fno-unbox-small-strict-fields
or -fno-unbox-strict-fields provided or not.


On 23 January 2015 at 11:59, Roman Cheplyaka <roma at ro-che.info> wrote:
> I did. The rest is whitespace; @git show -w 1d32a85@ shows only one
> changed line (NOUNPACK).
>
> On 23/01/15 10:53, Alexander V Vershilov wrote:
>> Please take a took at that commit, UNPACK was also handled there,
>> despite commit message do not explicitly state this.
>>
>> On Jan 23, 2015 11:49 AM, "Roman Cheplyaka" <roma at ro-che.info
>> <mailto:roma at ro-che.info>> wrote:
>>
>>     How is parsing of the *NOUNPACK* pragma relevant here?
>>
>>     On 23/01/15 10:45, Alexander V Vershilov wrote:
>>     > Hi.
>>     >
>>     > As far as I understand  it was fixed as:
>>     >
>>     > commit 1d32a8503c2ebfab2bbdb696fe65dd0823d1ed27
>>     > Author: Simon Peyton Jones <simonpj at microsoft.com
>>     <mailto:simonpj at microsoft.com>>
>>     > Date:   Mon Dec 1 17:07:48 2014 +0000
>>     >
>>     >     Fix parser for UNPACK pragmas
>>     >
>>     >        {-# NOUNPACK #-}
>>     >        {-# NOUNPACK #-} !
>>     >     were being parsed the same way.  The former was wrong.
>>     >
>>     >     Thanks to Alan Zimmerman for pointing this out
>>     >
>>     >
>>     > So it will fix is in 7.10. And I can't reproduce this anymore on
>>     > ghc-HEAD.
>>     >
>>     >
>>     > On 20 January 2015 at 17:35, Roman Cheplyaka <roma at ro-che.info
>>     <mailto:roma at ro-che.info>> wrote:
>>     >> Interesting question. I managed to trace this to:
>>     >>
>>     >> compiler/basicTypes/MkId.hs:699
>>     >>
>>     >> isUnpackableType fam_envs ty
>>     >>   | Just (tc, _) <- splitTyConApp_maybe ty
>>     >>   , Just con <- tyConSingleAlgDataCon_maybe tc
>>     >>   , isVanillaDataCon con
>>     >>   = ok_con_args (unitNameSet (getName tc)) con
>>     >>   | otherwise
>>     >>   = False
>>     >>
>>     >> where isVanillaDataCon is defined as:
>>     >>
>>     >> dcVanilla :: Bool,
>>     >> -- True <=> This is a vanilla Haskell 98 data constructor
>>     >> --          Its type is of form
>>     >> --              forall a1..an . t1 -> ... tm -> T a1..an
>>     >> --          No existentials, no coercions, nothing.
>>     >>
>>     >> There's no explanation why this limitation is introduced; it might be
>>     >> just a conservative one.
>>     >>
>>     >> On 20/01/15 15:08, Nicholas Clarke wrote:
>>     >>> I'd like to be able to use the UNPACK pragma on an existentially
>>     >>> quantified datatype. So as in the below example:
>>     >>>
>>     >>> {-# LANGUAGE ExistentialQuantification #-}
>>     >>>
>>     >>> data Foo = forall a. Show a => Foo !a
>>     >>> instance Show Foo where
>>     >>>   show (Foo a) = "Foo! " ++ show a
>>     >>>
>>     >>> data Bar =
>>     >>>     Bar {-# UNPACK #-} !Foo
>>     >>>   deriving (Show)
>>     >>>
>>     >>> main :: IO ()
>>     >>> main = do
>>     >>>   let foo = Foo "Hello"
>>     >>>       bar = Bar foo
>>     >>>   print bar
>>     >>>
>>     >>> I would expect the `Foo` constructor to be unpacked into Bar, as
>>     if I
>>     >>> had written:
>>     >>>
>>     >>> data Bar = forall a. Show a => Bar !a
>>     >>>
>>     >>> However, instead I get the 'Ignoring unusable UNPACK pragma on
>>     the first
>>     >>> argument of ?Bar?' warning. Is there a reason this shouldn't
>>     work, or a
>>     >>> workaround to get it to do so?
>>     >>
>>     >> _______________________________________________
>>     >> Glasgow-haskell-users mailing list
>>     >> Glasgow-haskell-users at haskell.org
>>     <mailto:Glasgow-haskell-users at haskell.org>
>>     >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>     >
>>     >
>>     >
>>
>



-- 
Alexander

From verteiler at volker-wysk.de  Fri Jan 23 12:46:41 2015
From: verteiler at volker-wysk.de (Volker Wysk)
Date: Fri, 23 Jan 2015 13:46:41 +0100
Subject: How to remove a cabal package from the local system?
In-Reply-To: <54C12319.3080605@vex.net>
References: <1432043.CqTmocIONc@debian> <54C12319.3080605@vex.net>
Message-ID: <1677621.YSehOVSVrP@debian>

Am Donnerstag, 22. Januar 2015, 11:19:37 schrieb Albert Y. C. Lai:
> On 2015-01-21 10:36 AM, Volker Wysk wrote:
> > I have installed/registered a new version of a package with cabal by
> > accident. How can I remove it again?
> 
> See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact,
> read the whole thing.

This describes what Evan is doing in his script. 

Bye
Volker

From simonpj at microsoft.com  Fri Jan 23 14:14:56 2015
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 23 Jan 2015 14:14:56 +0000
Subject: UNPACK Existential datatype
In-Reply-To: <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
References: <mailman.17340.1421758426.16281.glasgow-haskell-users@haskell.org>
 <CAGBDWB846eY5-PGoy_CoRyYZH6vFQq9OXFbLxxmvwGivnAc4GQ@mail.gmail.com>
Message-ID: <618BE556AADD624C9C918AA5D5911BEF562B355E@DB3PRD3001MB020.064d.mgd.msft.net>

I think this is a very reasonable suggestion.  It would take some work to implement, but nothing fundamental.

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Nicholas Clarke
Sent: 20 January 2015 13:08
To: glasgow-haskell-users at haskell.org
Subject: Fwd: UNPACK Existential datatype

I'd like to be able to use the UNPACK pragma on an existentially quantified datatype. So as in the below example:

{-# LANGUAGE ExistentialQuantification #-}

data Foo = forall a. Show a => Foo !a
instance Show Foo where
  show (Foo a) = "Foo! " ++ show a

data Bar =
    Bar {-# UNPACK #-} !Foo
  deriving (Show)

main :: IO ()
main = do
  let foo = Foo "Hello"
      bar = Bar foo
  print bar

I would expect the `Foo` constructor to be unpacked into Bar, as if I had written:

data Bar = forall a. Show a => Bar !a

However, instead I get the 'Ignoring unusable UNPACK pragma on the first argument of ?Bar?' warning. Is there a reason this shouldn't work, or a workaround to get it to do so?

Cheers,

Nick


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150123/29d07711/attachment.html>

From qdunkan at gmail.com  Fri Jan 23 14:16:23 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Fri, 23 Jan 2015 22:16:23 +0800
Subject: template haskell vs. -prof
Message-ID: <CACbaDy5dxgTcF85kLVCUngjSda=KLsGhG8YwXoUFORH982Fnyw@mail.gmail.com>

I ran into trouble compiling template haskell with -prof, and came
across the ghc manual "7.9.4. Using Template Haskell with Profiling".
Unfortunately I can't use its advice directly since I put profiling
and non-profiling .o files into different directories.  But in
principle it seems it should work, I just have to get ghc to load TH
from the debug build directory, which is built with -dynamic, while
continuing to load from the profile build directory.

But are there flags to get it to do that?  I'm using "-osuf .hs.o
-ibuild/profile/obj".  If I put ":build/debug/obj" on the -i line, it
still seems to find the profiling one.  The ghc manual advice probably
gets around it by using different -osufs... I guess TH somehow ignores
-osuf?  Except when I compile the debug version with osuf, if finds
them fine, so I don't really know how it works.

Is there a way I can directly tell TH where to look?  It seems awkward
to rely on all these implicit and seemingly undocumented heuristics.

And, this is somewhat beside the point, but shouldn't TH theoretically
be able to load directly from .hs and compile to bytecode like ghci
can do if it doesn't find the .o file?

And, even more beside the point, the only reason I'm messing with TH
is for a really simple (one line) multi-line string literal
quasiquote.  Surely I'm not the only person who would enjoy a
-XMultiLineStringLiteral extension?  The alternative seems to be a
program to add or strip all of the "\n\"s, and when I want to edit,
copy out, strip, edit, paste back in, add back.  At that point maybe
it's easier to just get used to all the \s... but then indentation is
all a bit off due to the leading \.

From jwlato at gmail.com  Fri Jan 23 18:38:40 2015
From: jwlato at gmail.com (John Lato)
Date: Fri, 23 Jan 2015 18:38:40 +0000
Subject: template haskell vs. -prof
References: <CACbaDy5dxgTcF85kLVCUngjSda=KLsGhG8YwXoUFORH982Fnyw@mail.gmail.com>
Message-ID: <CAJ727Gj2RNqR98oogTSR9kpY=zN9m2Og-inggv_ofSJvwUbgug@mail.gmail.com>

I agree that mixing template haskell with -prof can be tricky.  It's easier
if you turn off dynamic linking entirely.

As for multi-line string literals, I also think that an explicit syntax
would be nice.  Until then, I usually use:

    unlines
      [ "Line 1"
      , "Line 2"
      ]

which ends up being pretty maintainable and easy to read.

On Fri Jan 23 2015 at 6:16:46 AM Evan Laforge <qdunkan at gmail.com> wrote:

> I ran into trouble compiling template haskell with -prof, and came
> across the ghc manual "7.9.4. Using Template Haskell with Profiling".
> Unfortunately I can't use its advice directly since I put profiling
> and non-profiling .o files into different directories.  But in
> principle it seems it should work, I just have to get ghc to load TH
> from the debug build directory, which is built with -dynamic, while
> continuing to load from the profile build directory.
>
> But are there flags to get it to do that?  I'm using "-osuf .hs.o
> -ibuild/profile/obj".  If I put ":build/debug/obj" on the -i line, it
> still seems to find the profiling one.  The ghc manual advice probably
> gets around it by using different -osufs... I guess TH somehow ignores
> -osuf?  Except when I compile the debug version with osuf, if finds
> them fine, so I don't really know how it works.
>
> Is there a way I can directly tell TH where to look?  It seems awkward
> to rely on all these implicit and seemingly undocumented heuristics.
>
> And, this is somewhat beside the point, but shouldn't TH theoretically
> be able to load directly from .hs and compile to bytecode like ghci
> can do if it doesn't find the .o file?
>
> And, even more beside the point, the only reason I'm messing with TH
> is for a really simple (one line) multi-line string literal
> quasiquote.  Surely I'm not the only person who would enjoy a
> -XMultiLineStringLiteral extension?  The alternative seems to be a
> program to add or strip all of the "\n\"s, and when I want to edit,
> copy out, strip, edit, paste back in, add back.  At that point maybe
> it's easier to just get used to all the \s... but then indentation is
> all a bit off due to the leading \.
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150123/ec00563e/attachment-0001.html>

From qdunkan at gmail.com  Sat Jan 24 05:23:05 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 24 Jan 2015 13:23:05 +0800
Subject: template haskell vs. -prof
In-Reply-To: <CAJ727Gj2RNqR98oogTSR9kpY=zN9m2Og-inggv_ofSJvwUbgug@mail.gmail.com>
References: <CACbaDy5dxgTcF85kLVCUngjSda=KLsGhG8YwXoUFORH982Fnyw@mail.gmail.com>
 <CAJ727Gj2RNqR98oogTSR9kpY=zN9m2Og-inggv_ofSJvwUbgug@mail.gmail.com>
Message-ID: <CACbaDy433bzDAeJBcLCHc1EKugQqwFduoREh9my-b9Jo-_VTbg@mail.gmail.com>

On Sat, Jan 24, 2015 at 2:38 AM, John Lato <jwlato at gmail.com> wrote:
> I agree that mixing template haskell with -prof can be tricky.  It's easier if you turn
> off dynamic linking entirely.

But that's the thing, I do turn of dynamic linking because I have to
for -prof, but TH seems to require it.

>     unlines
>       [ "Line 1"
>       , "Line 2"
>       ]
>
> which ends up being pretty maintainable and easy to read.

Yeah, I use this one too.  It's ok for short things, but it can still
be annoying to edit.  My editor doesn't know how to do line wrapping
for it.  Then you can't just copy paste in and out.  And tabs get
messed up because you're already indented, and probably not in a
tabstop multiple... though I guess I could align it so it was.  And of
course since there's prefix gunk, folding doesn't work inside.

Actually, if anyone knows about a vim hack to make 'gq' handle either
this style or the backslash style, it would be much appreciated...
maybe I should try to create one.

From jwlato at gmail.com  Sat Jan 24 05:29:42 2015
From: jwlato at gmail.com (John Lato)
Date: Sat, 24 Jan 2015 05:29:42 +0000
Subject: template haskell vs. -prof
References: <CACbaDy5dxgTcF85kLVCUngjSda=KLsGhG8YwXoUFORH982Fnyw@mail.gmail.com>
 <CAJ727Gj2RNqR98oogTSR9kpY=zN9m2Og-inggv_ofSJvwUbgug@mail.gmail.com>
 <CACbaDy433bzDAeJBcLCHc1EKugQqwFduoREh9my-b9Jo-_VTbg@mail.gmail.com>
Message-ID: <CAJ727Gj2T6YrxkiKJ6jJXo7kdCYEbYBK68fcidU-cvDGp84uYg@mail.gmail.com>

On 21:23, Fri, Jan 23, 2015 Evan Laforge <qdunkan at gmail.com> wrote:

On Sat, Jan 24, 2015 at 2:38 AM, John Lato <jwlato at gmail.com> wrote:
> I agree that mixing template haskell with -prof can be tricky.  It's
easier if you turn
> off dynamic linking entirely.

But that's the thing, I do turn of dynamic linking because I have to
for -prof, but TH seems to require it.

 I mean to use a ghc that's been built without dynamic support.

 >     unlines
>       [ "Line 1"
>       , "Line 2"
>       ]
>
> which ends up being pretty maintainable and easy to read.

Yeah, I use this one too.  It's ok for short things, but it can still
be annoying to edit.  My editor doesn't know how to do line wrapping
for it.  Then you can't just copy paste in and out.  And tabs get
messed up because you're already indented, and probably not in a
tabstop multiple... though I guess I could align it so it was.  And of
course since there's prefix gunk, folding doesn't work inside.

 Yeah, those are all problematic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150124/5db0cfff/attachment.html>

From qdunkan at gmail.com  Sat Jan 24 05:50:58 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Sat, 24 Jan 2015 13:50:58 +0800
Subject: template haskell vs. -prof
In-Reply-To: <CAJ727Gj2T6YrxkiKJ6jJXo7kdCYEbYBK68fcidU-cvDGp84uYg@mail.gmail.com>
References: <CACbaDy5dxgTcF85kLVCUngjSda=KLsGhG8YwXoUFORH982Fnyw@mail.gmail.com>
 <CAJ727Gj2RNqR98oogTSR9kpY=zN9m2Og-inggv_ofSJvwUbgug@mail.gmail.com>
 <CACbaDy433bzDAeJBcLCHc1EKugQqwFduoREh9my-b9Jo-_VTbg@mail.gmail.com>
 <CAJ727Gj2T6YrxkiKJ6jJXo7kdCYEbYBK68fcidU-cvDGp84uYg@mail.gmail.com>
Message-ID: <CACbaDy6f17LoFRmccWVRs6nhQxECqJO=Bz7=q+_dKVwwaNT9fA@mail.gmail.com>

On Sat, Jan 24, 2015 at 1:29 PM, John Lato <jwlato at gmail.com> wrote:
> I mean to use a ghc that's been built without dynamic support.

Oh, so if the whole compiler is not dynamic then TH no longer requires
.dyn_o files?  Interesting.

I know they've put a lot of work into this and staging is hard, so I
assume there are good reasons for it :)

From voldermort at hotmail.com  Sun Jan 25 10:18:16 2015
From: voldermort at hotmail.com (harry)
Date: Sun, 25 Jan 2015 03:18:16 -0700 (MST)
Subject: Unable to build 7.10.1 RC1 on Jessie
Message-ID: <1422181096521-5764254.post@n5.nabble.com>

I'm trying to build 7.10.1 RC on Debian Jessie. I get an error:

configure: error: in
`/ghc-7.10.0.20141222/libffi/build/x86_64-unknown-linux-gnu':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check

config.log shows:

configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libffi"
| #define PACKAGE_TARNAME "libffi"
| #define PACKAGE_VERSION "3.1"
| #define PACKAGE_STRING "libffi 3.1"
| #define PACKAGE_BUGREPORT "http://github.com/atgreen/libffi/issues"
| #define PACKAGE_URL ""
| #define PACKAGE "libffi"
| #define VERSION "3.1"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include <limits.h>
| #else
| # include <assert.h>
| #endif
|                    Syntax error
configure:12860: error: in
`/ghc-7.10.0.20141222/libffi/build/x86_64-unknown-linux-gnu':
configure:12862: error: C++ preprocessor "/lib/cpp" fails sanity check

This can be reproduced by running the following commands in the
debian:jessie docker image:

apt-get update
apt-get install ncurses-dev curl gcc ghc make libgmp-dev xz-utils
curl
http://downloads.haskell.org/~ghc/7.10.1-rc1/ghc-7.10.0.20141222-src.tar.xz
| tar xJ
cd ghc-*
./configure
make

Any suggestions for someone who knows nothing about c or cpp?



--
View this message in context: http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From svenpanne at gmail.com  Sun Jan 25 11:22:45 2015
From: svenpanne at gmail.com (Sven Panne)
Date: Sun, 25 Jan 2015 12:22:45 +0100
Subject: Unable to build 7.10.1 RC1 on Jessie
In-Reply-To: <1422181096521-5764254.post@n5.nabble.com>
References: <1422181096521-5764254.post@n5.nabble.com>
Message-ID: <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>

2015-01-25 11:18 GMT+01:00 harry <voldermort at hotmail.com>:
> [..] This can be reproduced by running the following commands in the
> debian:jessie docker image:
>
> apt-get update
> apt-get install ncurses-dev curl gcc ghc make libgmp-dev xz-utils
> curl
> http://downloads.haskell.org/~ghc/7.10.1-rc1/ghc-7.10.0.20141222-src.tar.xz
> | tar xJ
> cd ghc-*
> ./configure
> make
>
> Any suggestions for someone who knows nothing about c or cpp?

Perhaps there is no C++ compiler installed? Try to add "g++" to your
"apt-get install" command line.

From voldermort at hotmail.com  Sun Jan 25 13:23:18 2015
From: voldermort at hotmail.com (harry)
Date: Sun, 25 Jan 2015 06:23:18 -0700 (MST)
Subject: Unable to build 7.10.1 RC1 on Jessie
In-Reply-To: <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
References: <1422181096521-5764254.post@n5.nabble.com>
 <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
Message-ID: <1422192198302-5764256.post@n5.nabble.com>

Sven Panne-2 wrote
> Perhaps there is no C++ compiler installed? Try to add "g++" to your
> "apt-get install" command line.

Is g++ a new requirement? I didn't need it for building 7.8.4.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254p5764256.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From voldermort at hotmail.com  Sun Jan 25 14:43:24 2015
From: voldermort at hotmail.com (harry)
Date: Sun, 25 Jan 2015 07:43:24 -0700 (MST)
Subject: Unable to build 7.10.1 RC1 on Jessie
In-Reply-To: <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
References: <1422181096521-5764254.post@n5.nabble.com>
 <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
Message-ID: <1422197004396-5764257.post@n5.nabble.com>

According to https://ghc.haskell.org/trac/ghc/ticket/9720, g++ isn't even
used for building. and "passing in gcc for CXX seems to work fine." Wonder
if that's changed.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254p5764257.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From allbery.b at gmail.com  Sun Jan 25 14:48:21 2015
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 25 Jan 2015 09:48:21 -0500
Subject: Unable to build 7.10.1 RC1 on Jessie
In-Reply-To: <1422197004396-5764257.post@n5.nabble.com>
References: <1422181096521-5764254.post@n5.nabble.com>
 <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
 <1422197004396-5764257.post@n5.nabble.com>
Message-ID: <CAKFCL4Xg33PnMwWOkbBbhOQL4UCuEsQ+HaTujcOrRy-=G05OBw@mail.gmail.com>

On Sun, Jan 25, 2015 at 9:43 AM, harry <voldermort at hotmail.com> wrote:

> According to https://ghc.haskell.org/trac/ghc/ticket/9720
>
> , g++ isn't even
> used for building. and "passing in gcc for CXX seems to work fine." Wonder
> if that's changed.
>

It may be that some minimal amount of C++ support was added just to make it
easier to link C++-generated objects into a Haskell program, but autoconf
took that (perhaps with reason) as meaning do the full C++ testing bit so
now you *must* have it around at configure time.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150125/de8c924b/attachment.html>

From voldermort at hotmail.com  Sun Jan 25 15:04:05 2015
From: voldermort at hotmail.com (harry)
Date: Sun, 25 Jan 2015 08:04:05 -0700 (MST)
Subject: Unable to build 7.10.1 RC1 on Jessie
In-Reply-To: <CAKFCL4Xg33PnMwWOkbBbhOQL4UCuEsQ+HaTujcOrRy-=G05OBw@mail.gmail.com>
References: <1422181096521-5764254.post@n5.nabble.com>
 <CANBN=msFTyS4xT3tVBeOZd_Ebiui7w6d4M1e5u-goC1Y1KQ_uw@mail.gmail.com>
 <1422197004396-5764257.post@n5.nabble.com>
 <CAKFCL4Xg33PnMwWOkbBbhOQL4UCuEsQ+HaTujcOrRy-=G05OBw@mail.gmail.com>
Message-ID: <1422198245864-5764259.post@n5.nabble.com>

Thank you Sven and Brandon for your help. I'm now able to build 7.10.



--
View this message in context: http://haskell.1045720.n5.nabble.com/Unable-to-build-7-10-1-RC1-on-Jessie-tp5764254p5764259.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

From rasfar at gmail.com  Sun Jan 25 23:40:03 2015
From: rasfar at gmail.com (Andrew Seniuk)
Date: Sun, 25 Jan 2015 17:40:03 -0600
Subject: ANN: deepseq-bounded 0.5 -> 0.6
Message-ID: <CAGLfSE0A=mEV-QKous89Rh3JOHBgignXNn5ssE8FZetKBpbkzA@mail.gmail.com>

This may affect depending code. Please consult the distro changelog
for specific information about how your code might be affected, or
better yet, refer to

  http://www.fremissant.net/deepseq-bounded/transition-5-6-7.html

and

  http://www.fremissant.net/deepseq-bounded/grammar.html

This is a transitional version of deepseq-bounded, with stability
of the grammar expected in early March for version 0.7.

This also causes major version bumps to the seqaid and leaky packages.
To update everything, issue

  cabal update
  cabal install --reinstall --force-reinstalls seqaid

which reinstalls the latest deepseq-bounded in passing. And also
if you were to run "seqaid demo" it will use the updated version
of leaky, so everything's up to date.

The homepage for these projects starts at

  http://www.fremissant.net/deepseq-bounded-seqaid-leaky.html

Kind Regards,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150125/23413d76/attachment.html>

From austin at well-typed.com  Tue Jan 27 00:13:39 2015
From: austin at well-typed.com (Austin Seipp)
Date: Mon, 26 Jan 2015 18:13:39 -0600
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 2
Message-ID: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>

We are pleased to announce the second release candidate for GHC 7.10.1:

    https://downloads.haskell.org/~ghc/7.10.1-rc2/

This includes the source tarball and bindists for 64bit/32bit Linux
and Windows. Binary builds for other platforms will be available
shortly. (CentOS 6.5 binaries are not available at this time like they
were for 7.8.x). These binaries and tarballs have an accompanying
SHA256SUMS file signed by my GPG key id (0x3B58D86F).

We plan to make the 7.10.1 release sometime in February of 2015.

Please test as much as possible; bugs are much cheaper if we find them
before the release!

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/

From mietek at bak.io  Tue Jan 27 06:26:33 2015
From: mietek at bak.io (=?iso-8859-1?Q?Mi=EBtek_Bak?=)
Date: Tue, 27 Jan 2015 06:26:33 +0000
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 2
In-Reply-To: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
References: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
Message-ID: <6650493F-F6BD-4352-B4F1-5EA0CAE9D868@bak.io>

It appears GHC 7.10.1-rc2 doesn?t support glibc 2.11 ? specifically, 2.11.1 (Ubuntu 10.04 LTS) and 2.11.3 (Debian 6).  glibc 2.12 (CentOS 6) seems to work fine.  Symptoms include:

   Installing library in
   /app/ghc/lib/ghc-7.10.0.20150123/ghc_0kOYffGYd794400D7yvIjm
   "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" --force --global-package-db "/app/ghc/lib/ghc-7.10.0.20150123/package.conf.d" update rts/dist/package.conf.install
   Reading package info from "rts/dist/package.conf.install" ... done.
   "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" register libraries/ghc-prim dist-install "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc" "/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc-pkg" "/app/ghc/lib/ghc-7.10.0.20150123" '' '/app/ghc' '/app/ghc/lib/ghc-7.10.0.20150123' '/app/ghc/share/doc/ghc/html/libraries' NO  
   Warning: cannot determine version of /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc
   :
   ""
   ghc-cabal: '/app/ghc/lib/ghc-7.10.0.20150123/bin/ghc' exited with an error:
   /app/ghc/lib/ghc-7.10.0.20150123/bin/ghc: symbol lookup error:
   /app/ghc/lib/ghc-7.10.0.20150123/bin/../rts/libHSrts_thr-ghc7.10.0.20150123.so:
   undefined symbol: pthread_setname_np

The bindist name does mention 'deb7', so perhaps this is all working as intended.  However, similarly named bindists for GHC 7.8.* work fine with glibc 2.11.


In other news, I?m happy to say Halcyon now supports GHC 7.10.1-rc2 on CentOS 6 and 7, Debian 7, Fedora 19, 20, and 21, and Ubuntu 12 and 14.
https://halcyon.sh/

   $ halcyon install --ghc-version=7.10.1-rc2 --cabal-version=1.22.0.0


Best,

-- 
Mi?tek




On 2015-01-27, at 00:13, Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the second release candidate for GHC 7.10.1:
> 
>   https://downloads.haskell.org/~ghc/7.10.1-rc2/
> 
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
> 
> We plan to make the 7.10.1 release sometime in February of 2015.
> 
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
> 
> -- 
> Regards,
> 
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4203 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150127/d3598ff3/attachment.bin>

From george.colpitts at gmail.com  Wed Jan 28 01:39:26 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 27 Jan 2015 21:39:26 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 2
In-Reply-To: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
References: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
Message-ID: <CAB-d4A5VKTeM1A-ff=LguPRcr98y5Mknf5j1V5H3FDDNJqsqzA@mail.gmail.com>

Has anybody successfully build and used this on the Mac on 10.10 using the
latest XCode? While it is better than RC1 I am still seeing the following
two issues:


   - programs compiled with llvm fail at runtime with illegal instruction
   - calling main from the ghci inerpreter after loading compiled code
   results in
   - Prelude Main> main
      Too late for parseStaticFlags: call it before runGhc or runGhcT
      *** Exception: ExitFailure 1

Instead of solving the above, I'd be happy to switch to a Mac OS bindist
and see if I have the same problems there. Do we have an ETA for a Mac OS
bindist?


Thanks

George


On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp <austin at well-typed.com> wrote:

> We are pleased to announce the second release candidate for GHC 7.10.1:
>
>     https://downloads.haskell.org/~ghc/7.10.1-rc2/
>
> This includes the source tarball and bindists for 64bit/32bit Linux
> and Windows. Binary builds for other platforms will be available
> shortly. (CentOS 6.5 binaries are not available at this time like they
> were for 7.8.x). These binaries and tarballs have an accompanying
> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>
> We plan to make the 7.10.1 release sometime in February of 2015.
>
> Please test as much as possible; bugs are much cheaper if we find them
> before the release!
>
> --
> Regards,
>
> Austin Seipp, Haskell Consultant
> Well-Typed LLP, http://www.well-typed.com/
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150127/e4f10762/attachment.html>

From carter.schonwald at gmail.com  Wed Jan 28 01:52:12 2015
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Tue, 27 Jan 2015 20:52:12 -0500
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 2
In-Reply-To: <CAB-d4A5VKTeM1A-ff=LguPRcr98y5Mknf5j1V5H3FDDNJqsqzA@mail.gmail.com>
References: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
 <CAB-d4A5VKTeM1A-ff=LguPRcr98y5Mknf5j1V5H3FDDNJqsqzA@mail.gmail.com>
Message-ID: <CAHYVw0yah_oUUzMb86XUSJTpMpryGR0MbGHSPSLKc8hbQA6jYQ@mail.gmail.com>

George, what version of llvm are you using? afaik, only llvm 3.5 is
supported for 7.10 (though I could be wrong)

On Tue, Jan 27, 2015 at 8:39 PM, George Colpitts <george.colpitts at gmail.com>
wrote:

> Has anybody successfully build and used this on the Mac on 10.10 using the
> latest XCode? While it is better than RC1 I am still seeing the following
> two issues:
>
>
>    - programs compiled with llvm fail at runtime with illegal instruction
>    - calling main from the ghci inerpreter after loading compiled code
>    results in
>    - Prelude Main> main
>       Too late for parseStaticFlags: call it before runGhc or runGhcT
>       *** Exception: ExitFailure 1
>
> Instead of solving the above, I'd be happy to switch to a Mac OS bindist
> and see if I have the same problems there. Do we have an ETA for a Mac OS
> bindist?
>
>
> Thanks
>
> George
>
>
> On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp <austin at well-typed.com>
> wrote:
>
>> We are pleased to announce the second release candidate for GHC 7.10.1:
>>
>>     https://downloads.haskell.org/~ghc/7.10.1-rc2/
>>
>> This includes the source tarball and bindists for 64bit/32bit Linux
>> and Windows. Binary builds for other platforms will be available
>> shortly. (CentOS 6.5 binaries are not available at this time like they
>> were for 7.8.x). These binaries and tarballs have an accompanying
>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>
>> We plan to make the 7.10.1 release sometime in February of 2015.
>>
>> Please test as much as possible; bugs are much cheaper if we find them
>> before the release!
>>
>> --
>> Regards,
>>
>> Austin Seipp, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150127/3ca9cbaf/attachment.html>

From george.colpitts at gmail.com  Wed Jan 28 02:11:06 2015
From: george.colpitts at gmail.com (George Colpitts)
Date: Tue, 27 Jan 2015 22:11:06 -0400
Subject: ANNOUNCE: GHC 7.10.1 Release Candidate 2
In-Reply-To: <CAHYVw0yah_oUUzMb86XUSJTpMpryGR0MbGHSPSLKc8hbQA6jYQ@mail.gmail.com>
References: <CAEs96n12PydzEaWTVYvkVn+J10zWOZ+aXzEge5R+3Widh6xjaQ@mail.gmail.com>
 <CAB-d4A5VKTeM1A-ff=LguPRcr98y5Mknf5j1V5H3FDDNJqsqzA@mail.gmail.com>
 <CAHYVw0yah_oUUzMb86XUSJTpMpryGR0MbGHSPSLKc8hbQA6jYQ@mail.gmail.com>
Message-ID: <CAB-d4A6CxZghJqED+iwUR_6u2RtKpE9LGMyGJ=+n1y8=vu+y+Q@mail.gmail.com>

I have llvm 3.4.2. Not sure why I thought that was the supported version.
Where would that be documented? There doesn't seem to be anything on this
in
https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html

There is lots of mail about llvm. I guess the following from Ben Gamari on
11/28 implies llvm 3.5. I couldn't find anything more definitive.

Once I get a definitive answer I will try again assuming the answer is not
3.4.2

To summarize,

  * it seems like LLVM 3.4 chokes on the code produced by my 3.5 rework
    when the `$def` symbols are marked as internal

  * ARM is broken (again) due to a bug in the GHC calling convention
    implementation; an LLVM fix is waiting to be merged

  * I have code reworking TNTC for LLVM 3.6; unfortunately LLVM 3.6
    support will likely need to wait until 7.12

  * Austin's LLVM packaging proposal seems very much like the right way
    forward

  * Anticipating this proposal, I have started collecting [2]
    optimization passes

Cheers,



On Tue, Jan 27, 2015 at 9:52 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> George, what version of llvm are you using? afaik, only llvm 3.5 is
> supported for 7.10 (though I could be wrong)
>
> On Tue, Jan 27, 2015 at 8:39 PM, George Colpitts <
> george.colpitts at gmail.com> wrote:
>
>> Has anybody successfully build and used this on the Mac on 10.10 using
>> the latest XCode? While it is better than RC1 I am still seeing the
>> following two issues:
>>
>>
>>    - programs compiled with llvm fail at runtime with illegal instruction
>>    - calling main from the ghci inerpreter after loading compiled code
>>    results in
>>    - Prelude Main> main
>>       Too late for parseStaticFlags: call it before runGhc or runGhcT
>>       *** Exception: ExitFailure 1
>>
>> Instead of solving the above, I'd be happy to switch to a Mac OS bindist
>> and see if I have the same problems there. Do we have an ETA for a Mac OS
>> bindist?
>>
>>
>> Thanks
>>
>> George
>>
>>
>> On Mon, Jan 26, 2015 at 8:13 PM, Austin Seipp <austin at well-typed.com>
>> wrote:
>>
>>> We are pleased to announce the second release candidate for GHC 7.10.1:
>>>
>>>     https://downloads.haskell.org/~ghc/7.10.1-rc2/
>>>
>>> This includes the source tarball and bindists for 64bit/32bit Linux
>>> and Windows. Binary builds for other platforms will be available
>>> shortly. (CentOS 6.5 binaries are not available at this time like they
>>> were for 7.8.x). These binaries and tarballs have an accompanying
>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F).
>>>
>>> We plan to make the 7.10.1 release sometime in February of 2015.
>>>
>>> Please test as much as possible; bugs are much cheaper if we find them
>>> before the release!
>>>
>>> --
>>> Regards,
>>>
>>> Austin Seipp, Haskell Consultant
>>> Well-Typed LLP, http://www.well-typed.com/
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150127/a6edb260/attachment.html>

From greg at gregweber.info  Fri Jan 30 23:39:27 2015
From: greg at gregweber.info (Greg Weber)
Date: Fri, 30 Jan 2015 15:39:27 -0800
Subject: Restricted Template Haskell
Message-ID: <CAKRanND4n=qdDqNozHd109WP8dnQ2_rTiaNbVUg3mLxBf=VhRg@mail.gmail.com>

Hello GHC friends!

I am starting up a proposal for variants of Template Haskell that restrict
what operations are available. The goal is to make TH easier for users to
reason about and to allow for an easier compilation story.

Here is the proposal page:
https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted

Right now the proposal does not have any details and the goal is to write
out a clear specification.
If this sounds interesting to you, let me know or leave some feedback on
the wiki.


Thanks,
Greg Weber
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150130/538c47af/attachment.html>

From vogt.adam at gmail.com  Sat Jan 31 03:05:13 2015
From: vogt.adam at gmail.com (adam vogt)
Date: Fri, 30 Jan 2015 22:05:13 -0500
Subject: Restricted Template Haskell
In-Reply-To: <CAKRanND4n=qdDqNozHd109WP8dnQ2_rTiaNbVUg3mLxBf=VhRg@mail.gmail.com>
References: <CAKRanND4n=qdDqNozHd109WP8dnQ2_rTiaNbVUg3mLxBf=VhRg@mail.gmail.com>
Message-ID: <CAHfjoWkpiMfB_q8D2xoai+q=i_o-6AfCBTzf+SckBu1bkcLQbA@mail.gmail.com>

Hi Greg,

Perhaps a less-invasive way to implement the -XSafe part of your
proposal would be to provide a module like:

module Language.Haskell.TH.Safe (
  module Language.Haskell.TH,
  reifyWithoutNameG,
 )  where
import Language.Haskell.TH hiding (runIO, reify*)

where reifyWithoutNameG is the same as reify, except definitions that
are out of scope are either missing or modified such that they use
NameQ instead of NameG for out-of-scope names.

That way there is no new syntax needed, and safe TH can be called by
unsafe TH without any conversions.

I think defining another monad like Q that can do less is too
inconvenient because you have to disambiguate between Safe.listE and
Unsafe.listE, or make those functions more polymorphic (which makes
type errors worse). Another option would be if there were

newtype QThat (canIO :: Bool) (canReify :: Bool) (canNewName :: Bool)
   = QThat (TheRealQImplementation)

type Q = QThat True True True

listE :: Monad m => [m Exp] -> m Exp
listE = liftM ListE . sequence

reify :: Name -> QThat a True b Info
runIO :: IO a -> QThat True b c a

runQFFF :: QThat False False False a -> a
runQTFF :: QThat True False False a -> IO a


But I think that design would be a step in the direction of "harder to
reason about"

Regards,
Adam


On Fri, Jan 30, 2015 at 6:39 PM, Greg Weber <greg at gregweber.info> wrote:
> Hello GHC friends!
>
> I am starting up a proposal for variants of Template Haskell that restrict
> what operations are available. The goal is to make TH easier for users to
> reason about and to allow for an easier compilation story.
>
> Here is the proposal page:
> https://ghc.haskell.org/trac/ghc/wiki/TemplateHaskell/Restricted
>
> Right now the proposal does not have any details and the goal is to write
> out a clear specification.
> If this sounds interesting to you, let me know or leave some feedback on the
> wiki.
>
>
> Thanks,
> Greg Weber
>
>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

From greg at gregweber.info  Sat Jan 31 16:33:49 2015
From: greg at gregweber.info (Greg Weber)
Date: Sat, 31 Jan 2015 08:33:49 -0800
Subject: Restricted Template Haskell
In-Reply-To: <CAHfjoWkpiMfB_q8D2xoai+q=i_o-6AfCBTzf+SckBu1bkcLQbA@mail.gmail.com>
References: <CAKRanND4n=qdDqNozHd109WP8dnQ2_rTiaNbVUg3mLxBf=VhRg@mail.gmail.com>
 <CAHfjoWkpiMfB_q8D2xoai+q=i_o-6AfCBTzf+SckBu1bkcLQbA@mail.gmail.com>
Message-ID: <CAKRanNCG4TwH2UajAH3htvsT9vyb+Vppp6-fmrXHkWMtNz9zsQ@mail.gmail.com>

On Fri, Jan 30, 2015 at 7:05 PM, adam vogt <vogt.adam at gmail.com> wrote:

> Hi Greg,
>
> Perhaps a less-invasive way to implement the -XSafe part of your
> proposal would be to provide a module like:
>
> module Language.Haskell.TH.Safe (
>   module Language.Haskell.TH,
>   reifyWithoutNameG,
>  )  where
> import Language.Haskell.TH hiding (runIO, reify*)
>
> where reifyWithoutNameG is the same as reify, except definitions that
> are out of scope are either missing or modified such that they use
> NameQ instead of NameG for out-of-scope names.
>

Thanks, I added this concept to the wiki.


> That way there is no new syntax needed, and safe TH can be called by
> unsafe TH without any conversions.
>
> I think defining another monad like Q that can do less is too
> inconvenient because you have to disambiguate between Safe.listE and
> Unsafe.listE, or make those functions more polymorphic (which makes
> type errors worse). Another option would be if there were
>

Oh, you are getting into more concrete details now than I have even thought
about!
For the restricted monad route, we might look into a more capable method of
using capabilities that would end up looking like this:

reify :: Name -> Restrict (TH :+: Reify) Info
runIO :: IO a -> Restrict (TH :+: RunIO) a

There are still a lot of details to work out, thanks for getting things
started.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20150131/a6927fe9/attachment.html>