Re: 8.5 build failure

[John Leo]

Thanks everyone. I didn't expect just continuing "make" would work, but it
does, so that's a workaround for now. I'll look forward to the real fix, of
course.

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

Re: 8.5 build failure

[John Leo]

One thing I should note is that I believe since the last time I'd built I
updated Mac OS to 10.13.4, if that is relevant. Note that stage 1 built
fine; the failure occurs about 22 minutes into a build that typically takes
30 minute on my machine.

John

On Tue, Apr 3, 2018 at 8:06 AM, John Leo <l...@halfaya.org> wrote:

> Hi everyone,
>
> I pulled from head this morning and rebased my current work on it, and am
> getting a build error I've never seen before. I don't think it's due to any
> of my own changes, and everything built fine last time I tried just a
> couple days ago . I'd pulled both code and submodules. I did make clean,
> ./boot, ./configure, and then make. The last few lines of the output are
> below. This is on a Mac using GHC 8.2.2. Let me know if you need any more
> info.
>
> John
>
> "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload
> deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath
> -optl-Wl,@loader_path `cat rts/dist/libs.depend`
> rts/dist/build/Adjustor.thr_debug_dyn_o rts/dist/build/Arena.thr_debug_dyn_o
> rts/dist/build/Capability.thr_debug_dyn_o 
> rts/dist/build/CheckUnload.thr_debug_dyn_o
> rts/dist/build/ClosureFlags.thr_debug_dyn_o 
> rts/dist/build/Disassembler.thr_debug_dyn_o
> rts/dist/build/FileLock.thr_debug_dyn_o rts/dist/build/Globals.thr_debug_dyn_o
> rts/dist/build/Hash.thr_debug_dyn_o rts/dist/build/Hpc.thr_debug_dyn_o
> rts/dist/build/HsFFI.thr_debug_dyn_o rts/dist/build/Inlines.thr_debug_dyn_o
> rts/dist/build/Interpreter.thr_debug_dyn_o 
> rts/dist/build/LdvProfile.thr_debug_dyn_o
> rts/dist/build/Libdw.thr_debug_dyn_o rts/dist/build/LibdwPool.thr_debug_dyn_o
> rts/dist/build/Linker.thr_debug_dyn_o rts/dist/build/Messages.thr_debug_dyn_o
> rts/dist/build/OldARMAtomic.thr_debug_dyn_o 
> rts/dist/build/PathUtils.thr_debug_dyn_o
> rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o
> rts/dist/build/ProfHeap.thr_debug_dyn_o 
> rts/dist/build/ProfilerReport.thr_debug_dyn_o
> rts/dist/build/ProfilerReportJson.thr_debug_dyn_o
> rts/dist/build/Profiling.thr_debug_dyn_o 
> rts/dist/build/Proftimer.thr_debug_dyn_o
> rts/dist/build/RaiseAsync.thr_debug_dyn_o rts/dist/build/
> RetainerProfile.thr_debug_dyn_o rts/dist/build/RetainerSet.thr_debug_dyn_o
> rts/dist/build/RtsAPI.thr_debug_dyn_o 
> rts/dist/build/RtsDllMain.thr_debug_dyn_o
> rts/dist/build/RtsFlags.thr_debug_dyn_o rts/dist/build/RtsMain.thr_debug_dyn_o
> rts/dist/build/RtsMessages.thr_debug_dyn_o 
> rts/dist/build/RtsStartup.thr_debug_dyn_o
> rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o
> rts/dist/build/RtsSymbols.thr_debug_dyn_o 
> rts/dist/build/RtsUtils.thr_debug_dyn_o
> rts/dist/build/STM.thr_debug_dyn_o rts/dist/build/Schedule.thr_debug_dyn_o
> rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o
> rts/dist/build/StaticPtrTable.thr_debug_dyn_o 
> rts/dist/build/Stats.thr_debug_dyn_o
> rts/dist/build/StgCRun.thr_debug_dyn_o 
> rts/dist/build/StgPrimFloat.thr_debug_dyn_o
> rts/dist/build/Task.thr_debug_dyn_o 
> rts/dist/build/ThreadLabels.thr_debug_dyn_o
> rts/dist/build/ThreadPaused.thr_debug_dyn_o 
> rts/dist/build/Threads.thr_debug_dyn_o
> rts/dist/build/Ticky.thr_debug_dyn_o rts/dist/build/Timer.thr_debug_dyn_o
> rts/dist/build/TopHandler.thr_debug_dyn_o rts/dist/build/Trace.thr_debug_dyn_o
> rts/dist/build/WSDeque.thr_debug_dyn_o rts/dist/build/Weak.thr_debug_dyn_o
> rts/dist/build/fs.thr_debug_dyn_o rts/dist/build/xxhash.thr_debug_dyn_o
> rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o 
> rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o
> rts/dist/build/hooks/MallocFail.thr_debug_dyn_o
> rts/dist/build/hooks/OnExit.thr_debug_dyn_o 
> rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o
> rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o
> rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o 
> rts/dist/build/sm/CNF.thr_debug_dyn_o
> rts/dist/build/sm/Compact.thr_debug_dyn_o 
> rts/dist/build/sm/Evac.thr_debug_dyn_o
> rts/dist/build/sm/Evac_thr.thr_debug_dyn_o 
> rts/dist/build/sm/GC.thr_debug_dyn_o
> rts/dist/build/sm/GCAux.thr_debug_dyn_o 
> rts/dist/build/sm/GCUtils.thr_debug_dyn_o
> rts/dist/build/sm/MBlock.thr_debug_dyn_o 
> rts/dist/build/sm/MarkWeak.thr_debug_dyn_o
> rts/dist/build/sm/Sanity.thr_debug_dyn_o 
> rts/dist/build/sm/Scav.thr_debug_dyn_o
> rts/dist/build/sm/Scav_thr.thr_debug_dyn_o 
> rts/dist/build/sm/Storage.thr_debug_dyn_o
> rts/dist/build/sm/Sweep.thr_debug_dyn_o 
> rts/dist/build/eventlog/EventLog.thr_debug_dyn_o
> rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o
> rts/dist/build/linker/CacheFlush.thr_debug_dyn_o
> rts/dist/build/linker/Elf.thr_debug_dyn_o 
> rts/dist/build/linker/LoadArchive.thr_debug_dyn_o
> rts/dist/build/linker/M32A

8.5 build failure

[John Leo]

Hi everyone,

I pulled from head this morning and rebased my current work on it, and am
getting a build error I've never seen before. I don't think it's due to any
of my own changes, and everything built fine last time I tried just a
couple days ago . I'd pulled both code and submodules. I did make clean,
./boot, ./configure, and then make. The last few lines of the output are
below. This is on a Mac using GHC 8.2.2. Let me know if you need any more
info.

John

"inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy
-no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath
-optl-Wl,@loader_path `cat rts/dist/libs.depend`
rts/dist/build/Adjustor.thr_debug_dyn_o
rts/dist/build/Arena.thr_debug_dyn_o
rts/dist/build/Capability.thr_debug_dyn_o
rts/dist/build/CheckUnload.thr_debug_dyn_o
rts/dist/build/ClosureFlags.thr_debug_dyn_o
rts/dist/build/Disassembler.thr_debug_dyn_o
rts/dist/build/FileLock.thr_debug_dyn_o
rts/dist/build/Globals.thr_debug_dyn_o rts/dist/build/Hash.thr_debug_dyn_o
rts/dist/build/Hpc.thr_debug_dyn_o rts/dist/build/HsFFI.thr_debug_dyn_o
rts/dist/build/Inlines.thr_debug_dyn_o
rts/dist/build/Interpreter.thr_debug_dyn_o
rts/dist/build/LdvProfile.thr_debug_dyn_o
rts/dist/build/Libdw.thr_debug_dyn_o
rts/dist/build/LibdwPool.thr_debug_dyn_o
rts/dist/build/Linker.thr_debug_dyn_o
rts/dist/build/Messages.thr_debug_dyn_o
rts/dist/build/OldARMAtomic.thr_debug_dyn_o
rts/dist/build/PathUtils.thr_debug_dyn_o
rts/dist/build/Pool.thr_debug_dyn_o rts/dist/build/Printer.thr_debug_dyn_o
rts/dist/build/ProfHeap.thr_debug_dyn_o
rts/dist/build/ProfilerReport.thr_debug_dyn_o
rts/dist/build/ProfilerReportJson.thr_debug_dyn_o
rts/dist/build/Profiling.thr_debug_dyn_o
rts/dist/build/Proftimer.thr_debug_dyn_o
rts/dist/build/RaiseAsync.thr_debug_dyn_o
rts/dist/build/RetainerProfile.thr_debug_dyn_o
rts/dist/build/RetainerSet.thr_debug_dyn_o
rts/dist/build/RtsAPI.thr_debug_dyn_o
rts/dist/build/RtsDllMain.thr_debug_dyn_o
rts/dist/build/RtsFlags.thr_debug_dyn_o
rts/dist/build/RtsMain.thr_debug_dyn_o
rts/dist/build/RtsMessages.thr_debug_dyn_o
rts/dist/build/RtsStartup.thr_debug_dyn_o
rts/dist/build/RtsSymbolInfo.thr_debug_dyn_o
rts/dist/build/RtsSymbols.thr_debug_dyn_o
rts/dist/build/RtsUtils.thr_debug_dyn_o rts/dist/build/STM.thr_debug_dyn_o
rts/dist/build/Schedule.thr_debug_dyn_o
rts/dist/build/Sparks.thr_debug_dyn_o rts/dist/build/Stable.thr_debug_dyn_o
rts/dist/build/StaticPtrTable.thr_debug_dyn_o
rts/dist/build/Stats.thr_debug_dyn_o rts/dist/build/StgCRun.thr_debug_dyn_o
rts/dist/build/StgPrimFloat.thr_debug_dyn_o
rts/dist/build/Task.thr_debug_dyn_o
rts/dist/build/ThreadLabels.thr_debug_dyn_o
rts/dist/build/ThreadPaused.thr_debug_dyn_o
rts/dist/build/Threads.thr_debug_dyn_o rts/dist/build/Ticky.thr_debug_dyn_o
rts/dist/build/Timer.thr_debug_dyn_o
rts/dist/build/TopHandler.thr_debug_dyn_o
rts/dist/build/Trace.thr_debug_dyn_o rts/dist/build/WSDeque.thr_debug_dyn_o
rts/dist/build/Weak.thr_debug_dyn_o rts/dist/build/fs.thr_debug_dyn_o
rts/dist/build/xxhash.thr_debug_dyn_o
rts/dist/build/hooks/FlagDefaults.thr_debug_dyn_o
rts/dist/build/hooks/LongGCSync.thr_debug_dyn_o
rts/dist/build/hooks/MallocFail.thr_debug_dyn_o
rts/dist/build/hooks/OnExit.thr_debug_dyn_o
rts/dist/build/hooks/OutOfHeap.thr_debug_dyn_o
rts/dist/build/hooks/StackOverflow.thr_debug_dyn_o
rts/dist/build/sm/BlockAlloc.thr_debug_dyn_o
rts/dist/build/sm/CNF.thr_debug_dyn_o
rts/dist/build/sm/Compact.thr_debug_dyn_o
rts/dist/build/sm/Evac.thr_debug_dyn_o
rts/dist/build/sm/Evac_thr.thr_debug_dyn_o
rts/dist/build/sm/GC.thr_debug_dyn_o
rts/dist/build/sm/GCAux.thr_debug_dyn_o
rts/dist/build/sm/GCUtils.thr_debug_dyn_o
rts/dist/build/sm/MBlock.thr_debug_dyn_o
rts/dist/build/sm/MarkWeak.thr_debug_dyn_o
rts/dist/build/sm/Sanity.thr_debug_dyn_o
rts/dist/build/sm/Scav.thr_debug_dyn_o
rts/dist/build/sm/Scav_thr.thr_debug_dyn_o
rts/dist/build/sm/Storage.thr_debug_dyn_o
rts/dist/build/sm/Sweep.thr_debug_dyn_o
rts/dist/build/eventlog/EventLog.thr_debug_dyn_o
rts/dist/build/eventlog/EventLogWriter.thr_debug_dyn_o
rts/dist/build/linker/CacheFlush.thr_debug_dyn_o
rts/dist/build/linker/Elf.thr_debug_dyn_o
rts/dist/build/linker/LoadArchive.thr_debug_dyn_o
rts/dist/build/linker/M32Alloc.thr_debug_dyn_o
rts/dist/build/linker/MachO.thr_debug_dyn_o
rts/dist/build/linker/PEi386.thr_debug_dyn_o
rts/dist/build/linker/SymbolExtras.thr_debug_dyn_o
rts/dist/build/linker/elf_got.thr_debug_dyn_o
rts/dist/build/linker/elf_plt.thr_debug_dyn_o
rts/dist/build/linker/elf_plt_aarch64.thr_debug_dyn_o
rts/dist/build/linker/elf_plt_arm.thr_debug_dyn_o
rts/dist/build/linker/elf_reloc.thr_debug_dyn_o
rts/dist/build/linker/elf_reloc_aarch64.thr_debug_dyn_o
rts/dist/build/linker/elf_util.thr_debug_dyn_o
rts/dist/build/posix/GetEnv.thr_debug_dyn_o
rts/dist/build/posix/GetTime.thr_debug_dyn_o
rts/dist/build/posix/Itimer.thr_debug_dyn_o
rts/dist/build/posix/OSMem.thr_debug_dyn_o
rts/dist/build/posix/OSThreads.thr_debug_dyn_o
rts/dist/build/posix/Select.thr_debug_dyn_o

Haskell Colonectomy

[John Leo]

A serious proposal:
https://github.com/halfaya/ghc-proposals/blob/master/proposals/-colonectomy.rst

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

merge issues with new field for FamEqn

[John Leo]

Hi everyone,

Today I'm trying to merge the latest HEAD into my work on the explicit
forall proposal, and I'm running into a problem I'd like help with. The
changes that are affecting me seem to come from the latest Trees that Grow
checkins.

I had added a field to FamEqn, namely feqn_bndrs:

data FamEqn pass pats rhs
  = FamEqn
   { feqn_tycon  :: Located (IdP pass)
   , feqn_bndrs  :: Maybe [LHsTyVarBndr pass]
-- ^ Explicit user-provided binders
   , feqn_pats   :: pats
   , feqn_fixity :: LexicalFixity -- ^ Fixity used in the declaration
   , feqn_rhs:: rhs
   }
-- ^
--  - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnEqual',
--   'ApiAnnotation.AnnForall','ApiAnnotation.AnnDot'

-- For details on above see note [Api annotations] in ApiAnnotation
deriving instance (DataId pass, Data pats, Data rhs)
=> Data (FamEqn pass pats rhs)

When I try to compile now, I get the following errors that I cannot
understand.  I assume I need to do something else, but I'm not sure what it
is, so I'd appreciate any guidance.

compiler/hsSyn/HsDecls.hs:1441:1: error:
• Could not deduce (Data (XValBinds pass pass),
Data (XXValBindsLR pass pass))
arising from a use of ‘k’
  from the context: (DataId pass, Data pats, Data rhs)
bound by the instance declaration
at compiler/hsSyn/HsDecls.hs:(1441,1)-(1442,46)
• In the first argument of ‘k’, namely ‘((z FamEqn `k` a1) `k` a2)’
  In the first argument of ‘k’, namely
‘(((z FamEqn `k` a1) `k` a2) `k` a3)’
  In the first argument of ‘k’, namely
‘z FamEqn `k` a1) `k` a2) `k` a3) `k` a4)’
  When typechecking the code for ‘gfoldl’
in a derived instance for ‘Data (FamEqn pass pats rhs)’:
To see the code I am typechecking, use -ddump-deriv
 |
1441 | deriving instance (DataId pass, Data pats, Data rhs)
 | ...

compiler/hsSyn/HsDecls.hs:1441:1: error:
• Could not deduce (Data (XValBinds pass pass),
Data (XXValBindsLR pass pass))
arising from a use of ‘k’
  from the context: (DataId pass, Data pats, Data rhs)
bound by the instance declaration
at compiler/hsSyn/HsDecls.hs:(1441,1)-(1442,46)
• In the first argument of ‘k’, namely ‘(k (k (z FamEqn)))’
  In the first argument of ‘k’, namely ‘(k (k (k (z FamEqn’
  In the first argument of ‘k’, namely ‘(k (k (k (k (z FamEqn)’
  When typechecking the code for ‘gunfold’
in a derived instance for ‘Data (FamEqn pass pats rhs)’:
To see the code I am typechecking, use -ddump-deriv
 |
1441 | deriving instance (DataId pass, Data pats, Data rhs)
 | 

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

Re: GHC HEAD now needs extra tools to build libffi?

[John Leo]

I pulled head this morning and built with no problems on a Mac.  I wonder
if you need to pull submodules as well (which I did) or if you're missing
some newly required dependency.

John

On Tue, Oct 3, 2017 at 10:55 AM, Thomas Jakway  wrote:

> Anyone else getting linker errors?
>
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint64'
> chmod +x
> inplace/bin/runghc
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint32'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint16'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_uint8'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint64'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint32'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint16'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_sint8'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_double'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_float'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_pointer'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_type_void'
> /home/thomas/git/ghc-new/libraries/ghci/dist-install/
> build/libHSghci-8.3-ghc8.3.
> 20171003.so: error: undefined reference to 'ffi_prep_cif'
> collect2: error: ld returned 1 exit status
> `gcc' failed in phase `Linker'. (Exit code: 1)
> iserv/ghc.mk:108: recipe for target 'iserv/stage2_dyn/build/tmp/ghc-iserv-dyn'
> f
> ailed
> make[1]: *** [iserv/stage2_dyn/build/tmp/ghc-iserv-dyn] Error 1
> make[1]: *** Waiting for unfinished jobs
> < bytes, 225 GCs, 21703308/57027464
> avg/max bytes residency (8 s
> amples), 150M in use, 0.000 INIT (0.000 elapsed), 1.432 MUT (1.681
> elapsed), 0.5
> 76 GC (0.651 elapsed) :ghc>>
> Makefile:122: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
> This is after running
>
> make clean && make distclean && find . -name "*.o" -type f -delete && find
> . -name "*.hi" -type f -delete
>
> then
>
> ./boot && ./configure && make -j5
>
> (ghc-new is not a new checkout, this error is happening on a branch I'm
> working on, but one that doesn't touch the FFI)
>
> On 10/01/2017 07:09 PM, Moritz Angermann wrote:
>
> I hope this will be fixed with:
> https://phabricator.haskell.org/D4053 and https://
> phabricator.haskell.org/D4054
>
> Sent from my iPhone
>
> On 2 Oct 2017, at 6:33 AM, Ryan Scott  wrote:
>
> Trying to build a fresh copy of GHC HEAD (at commit [1]) today failed
> for me with this error: [2]
>
>/u/rgscott/Software/ghc4/libffi/build/missing: line 81: makeinfo:
> command not found
>WARNING: 'makeinfo' is missing on your system.
> You should only need it if you modified a '.texi' file, or
> any other file indirectly affecting the aspect of the manual.
> You might want to install the Texinfo package:
> 
> The spurious makeinfo call might also be the consequence of
> using a buggy 'make' (AIX, DU, IRIX), in which case you might
> want to install GNU make:
> 
>
> On my Ubuntu machine, I was able to work around the issue by running:
>
>apt-get install texinfo
>
> But I'm not sure if the texinfo requirement was expected or an
> unintended side effect of recent libffi changes. Do you know what's
> happening here Moritz?
>
> Best,
> Ryan S.
> -
> [1] http://git.haskell.org/ghc.git/commit/e515c7f37be97e1c2ccc497ddd0a73
> 0e63ddfa82
> [2] http://lpaste.net/6716863452582772736
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> 

Re: build fail with latest 8.1 sources

[John Leo]

I just pulled again and picked up a more recent patch by Ben Gamari:
https://github.com/ghc/ghc/commit/ca1b986074757efff755c33c7f9a62c7eae43c7f

This seems to have fixed the problem.  The commit says 8 hours ago but for
some reason I didn't pick it up 2 or 3 hours ago when I last pulled.

John

On Sat, Nov 12, 2016 at 3:19 PM, John Leo <l...@halfaya.org> wrote:

> That's exactly what I did--in fact clone a fresh GHC and try again, but no
> luck.  I attached the full logs in my second message, which have the
> details--let me know if the attachment is not readable.  Thanks very much
> for your help.
>
> John
>
> On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones <simo...@microsoft.com
> > wrote:
>
>> I’ve seen a very recent commit that mentioned bumping a TH bound.  Maybe
>> pull, make clean and try again?
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *John
>> Leo
>> *Sent:* 12 November 2016 22:48
>> *To:* ghc-devs <ghc-devs@haskell.org>
>> *Subject:* build fail with latest 8.1 sources
>>
>>
>>
>> Hi everyone,
>>
>>
>>
>> I'm trying to build the latest 8.1 sources on a Mac running El Capitan.
>> I'm getting an error I'd never seen before and wonder if anyone has any
>> pointers of how I might fix things.  I blew away my GHC, re-cloned from
>> github, reconfigured and I still get the same error.
>>
>>
>>
>> The following are the relevant output lines; the problem is that the
>> template-haskell version doesn't seem to match.  I'm not sure whether this
>> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to
>> build 8.1), but checking the latter I have version 2.11.0.0 which I assume
>> should be sufficient.
>>
>>
>>
>> John
>>
>>
>>
>> 
>>
>>
>>
>> Configuring ghc-pkg-6.9...
>>
>> Configuring ghc-8.1...
>>
>> ghc-cabal: Encountered missing dependencies:
>>
>> template-haskell ==2.11.* && ==2.12.0.0
>>
>> make[1]: *** [compiler/stage1/package-data.mk
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C7b7ee9373fa64fc1ac2808d40b4dfac0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636145876931712578=5iOJpziGOFYjoBCfwjB7UQ%2BmxFV5DRsiYmjYEANVXrM%3D=0>]
>> Error 1
>>
>> make[1]: *** Waiting for unfinished jobs
>>
>> make: *** [all] Error 2
>>
>>
>>
>> 
>>
>>
>>
>> internal-229:~/haskell/ghc> cabal update
>>
>> (git)-[master]
>>
>> Downloading the latest package list from hackage.haskell.org
>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackage.haskell.org=02%7C01%7Csimonpj%40microsoft.com%7C7b7ee9373fa64fc1ac2808d40b4dfac0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636145876931722586=aCtA6QCLlh%2BE1mus%2B1xJobpNi7K4DLZ8wYckmfEryLU%3D=0>
>>
>> Skipping download: local and remote files match.
>>
>> internal-229:~/haskell/ghc> cabal install template-haskell
>>
>> (git)-[master]
>>
>> Resolving dependencies...
>>
>> All the requested packages are already installed:
>>
>> template-haskell-2.11.0.0
>>
>> Use --reinstall if you want to reinstall anyway.
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: build fail with latest 8.1 sources

[John Leo]

That's exactly what I did--in fact clone a fresh GHC and try again, but no
luck.  I attached the full logs in my second message, which have the
details--let me know if the attachment is not readable.  Thanks very much
for your help.

John

On Sat, Nov 12, 2016 at 3:16 PM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> I’ve seen a very recent commit that mentioned bumping a TH bound.  Maybe
> pull, make clean and try again?
>
>
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *John
> Leo
> *Sent:* 12 November 2016 22:48
> *To:* ghc-devs <ghc-devs@haskell.org>
> *Subject:* build fail with latest 8.1 sources
>
>
>
> Hi everyone,
>
>
>
> I'm trying to build the latest 8.1 sources on a Mac running El Capitan.
> I'm getting an error I'd never seen before and wonder if anyone has any
> pointers of how I might fix things.  I blew away my GHC, re-cloned from
> github, reconfigured and I still get the same error.
>
>
>
> The following are the relevant output lines; the problem is that the
> template-haskell version doesn't seem to match.  I'm not sure whether this
> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to
> build 8.1), but checking the latter I have version 2.11.0.0 which I assume
> should be sufficient.
>
>
>
> John
>
>
>
> 
>
>
>
> Configuring ghc-pkg-6.9...
>
> Configuring ghc-8.1...
>
> ghc-cabal: Encountered missing dependencies:
>
> template-haskell ==2.11.* && ==2.12.0.0
>
> make[1]: *** [compiler/stage1/package-data.mk
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpackage-data.mk=02%7C01%7Csimonpj%40microsoft.com%7C7b7ee9373fa64fc1ac2808d40b4dfac0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636145876931712578=5iOJpziGOFYjoBCfwjB7UQ%2BmxFV5DRsiYmjYEANVXrM%3D=0>]
> Error 1
>
> make[1]: *** Waiting for unfinished jobs
>
> make: *** [all] Error 2
>
>
>
> 
>
>
>
> internal-229:~/haskell/ghc> cabal update
>
>   (git)-[master]
>
> Downloading the latest package list from hackage.haskell.org
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhackage.haskell.org=02%7C01%7Csimonpj%40microsoft.com%7C7b7ee9373fa64fc1ac2808d40b4dfac0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636145876931722586=aCtA6QCLlh%2BE1mus%2B1xJobpNi7K4DLZ8wYckmfEryLU%3D=0>
>
> Skipping download: local and remote files match.
>
> internal-229:~/haskell/ghc> cabal install template-haskell
>
>   (git)-[master]
>
> Resolving dependencies...
>
> All the requested packages are already installed:
>
> template-haskell-2.11.0.0
>
> Use --reinstall if you want to reinstall anyway.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: build fail with latest 8.1 sources

[John Leo]

Looking more closely at the log output it appears there were some errors or
at least warnings earlier in the output, including for template haskell, so
I've attached the full output.  I'll continue to investigate on my machine,
but again if anyone has pointers I'd appreciate it.  I've build 8.1 many
times and never seen this problem before.

John


On Sat, Nov 12, 2016 at 2:48 PM, John Leo <l...@halfaya.org> wrote:

> Hi everyone,
>
> I'm trying to build the latest 8.1 sources on a Mac running El Capitan.
> I'm getting an error I'd never seen before and wonder if anyone has any
> pointers of how I might fix things.  I blew away my GHC, re-cloned from
> github, reconfigured and I still get the same error.
>
> The following are the relevant output lines; the problem is that the
> template-haskell version doesn't seem to match.  I'm not sure whether this
> is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to
> build 8.1), but checking the latter I have version 2.11.0.0 which I assume
> should be sufficient.
>
> John
>
> 
>
> Configuring ghc-pkg-6.9...
> Configuring ghc-8.1...
> ghc-cabal: Encountered missing dependencies:
> template-haskell ==2.11.* && ==2.12.0.0
> make[1]: *** [compiler/stage1/package-data.mk] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [all] Error 2
>
> 
>
> internal-229:~/haskell/ghc> cabal update
>
>   (git)-[master]
> Downloading the latest package list from hackage.haskell.org
> Skipping download: local and remote files match.
> internal-229:~/haskell/ghc> cabal install template-haskell
>
>   (git)-[master]
> Resolving dependencies...
> All the requested packages are already installed:
> template-haskell-2.11.0.0
> Use --reinstall if you want to reinstall anyway.
>


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

build fail with latest 8.1 sources

[John Leo]

Hi everyone,

I'm trying to build the latest 8.1 sources on a Mac running El Capitan.
I'm getting an error I'd never seen before and wonder if anyone has any
pointers of how I might fix things.  I blew away my GHC, re-cloned from
github, reconfigured and I still get the same error.

The following are the relevant output lines; the problem is that the
template-haskell version doesn't seem to match.  I'm not sure whether this
is coming from the template-haskell in 8.1 or in 8.0.1 (which I'm using to
build 8.1), but checking the latter I have version 2.11.0.0 which I assume
should be sufficient.

John



Configuring ghc-pkg-6.9...
Configuring ghc-8.1...
ghc-cabal: Encountered missing dependencies:
template-haskell ==2.11.* && ==2.12.0.0
make[1]: *** [compiler/stage1/package-data.mk] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 2



internal-229:~/haskell/ghc> cabal update

  (git)-[master]
Downloading the latest package list from hackage.haskell.org
Skipping download: local and remote files match.
internal-229:~/haskell/ghc> cabal install template-haskell

  (git)-[master]
Resolving dependencies...
All the requested packages are already installed:
template-haskell-2.11.0.0
Use --reinstall if you want to reinstall anyway.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: when building latest GHC on Mac with Xcode 8: Symbol not found: _clock_gettime

[John Leo]

Thanks very much Brandon for your fast reply!  That did the trick.  I had
to rerun configure as well since when I didn't do that I got a different
but seemingly related error.  But after clean, configure and make
everything seems to work again.

John

On Mon, Oct 10, 2016 at 8:27 PM, Brandon Allbery <allber...@gmail.com>
wrote:

>
> On Mon, Oct 10, 2016 at 11:22 PM, John Leo <l...@halfaya.org> wrote:
>
>> I'm trying to compile ghc from the latest source and am hitting an error
>> "Symbol not found: _clock_gettime".  I'm on Mac El Capitan and recently
>> installed Xcode 8 which I'm sure is what caused the problem.  Using Google
>> I found some relevant pages including this one
>> https://mail.haskell.org/pipermail/ghc-devs/2016-July/012511.html
>>
>>
>> but I've been unable to figure out what I can do to fix the problem.  Any
>> help would be appreciated.
>>
>
> You need to download the 10.11 Command Line Tools from download.apple.com
> and reinstall them over the Xcode 8 command line tools, which are for 10.12
> and will have problems like this. (Apple intends to correct this in Xcode
> 8.1.) You need a free Mac Developer account for this, or maybe you can find
> the 10.11 tools elsewhere. You will then need to clean and rebuild ghc.
>
> --
> brandon s allbery kf8nh   sine nomine
> associates
> allber...@gmail.com
> ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Bikeshedding request for GHCi's :type

[John Leo]

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

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

John

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

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

type operators and colon in GHC

[John Leo]

I sent this to haskell-cafe a little while ago but didn't get a response,
so I thought I'd try here.  I'd guess this is a case of the GHC user guide
needing an update, but I'd like an expert opinion.

---

According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
you can define (7.4.3) an infix type constructor as long as it begins with
a colon, for example
data a :*: b = Foo a b

and furthermore (7.4.4) you can define an infix operator without having to
use a colon if you enable the TypeOperators extension:
data a * b = Foo a b

However if I try the former without using TypeOperators I get this compiler
error in 7.10.2:
Illegal declaration of a type or class operator ‘:*:’
  Use TypeOperators to declare operators in type and declarations

Using TypeOperators fixes this, but then * without colon also works so I
don't see the point of using colon anymore.

My guess is this was some some kind of historical distinction which is no
longer valid and the documentation needs to be updated.  Is this true, or
am I missing something?

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

Re: type operators and colon in GHC

[John Leo]

Thanks, that's helpful.  Sounds like the situation is even more complicated
than I realized.  It will be great if the documentation can be updated once
the behavior stabilizes.

John

On Thu, Dec 10, 2015 at 7:54 AM, Alexey Vagarenko <vagare...@gmail.com>
wrote:

> This ticket might be relevant
> https://ghc.haskell.org/trac/ghc/ticket/11046
>
> 2015-12-10 20:51 GMT+05:00 John Leo <l...@halfaya.org>:
>
>> I sent this to haskell-cafe a little while ago but didn't get a response,
>> so I thought I'd try here.  I'd guess this is a case of the GHC user guide
>> needing an update, but I'd like an expert opinion.
>>
>> ---
>>
>> According to sections 7.4.3 and 7.4.4 of the latest GHC documentation
>>
>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/data-type-extensions.html
>> you can define (7.4.3) an infix type constructor as long as it begins
>> with a colon, for example
>> data a :*: b = Foo a b
>>
>> and furthermore (7.4.4) you can define an infix operator without having
>> to use a colon if you enable the TypeOperators extension:
>> data a * b = Foo a b
>>
>> However if I try the former without using TypeOperators I get this
>> compiler error in 7.10.2:
>> Illegal declaration of a type or class operator ‘:*:’
>>   Use TypeOperators to declare operators in type and declarations
>>
>> Using TypeOperators fixes this, but then * without colon also works so I
>> don't see the point of using colon anymore.
>>
>> My guess is this was some some kind of historical distinction which is no
>> longer valid and the documentation needs to be updated.  Is this true, or
>> am I missing something?
>>
>> John
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs