RE: splitting metavariables

[Simon Peyton Jones via ghc-devs]

|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.

Yes, that's right. Maybe that makes a useful distinction between coreView and 
tcView; the former should never see a meta-variable.

I'm not sure we are fully consistent on when we call each, but it'd be a good 
start.

Go for it

Simon

|  -Original Message-
|  From: Richard Eisenberg [mailto:r...@cs.brynmawr.edu]
|  Sent: 20 October 2017 22:44
|  To: Simon Peyton Jones 
|  Cc: ghc-devs 
|  Subject: splitting metavariables
|  
|  Hi Simon,
|  
|  I just commented
|  (https://ghc.haskell.org/trac/ghc/ticket/14331#comment:35) about a
|  situation where we call splitFunTys on a type that might be a
|  metavariable. (You don't have to read the comment -- that's just to
|  set the context.) Now that I think of it, we should never call the
|  splitXXX functions on metavariables -- any time we do so is wrong. I
|  suppose it's OK if we, say, call splitTyConApp_maybe on (T alpha beta
|  gamma), because we never look through the metavariables there. But it
|  can't possible be write to call splitTyConApp_maybe on alpha.
|  
|  Do you agree? Should we ASSERT that we don't do this?
|  
|  The tcXXX variants are no different in this regard.
|  
|  Actually, I wonder if we can put the check in just one spot: coreView.
|  Whenever we use coreView, we're about to inspect a type. And we should
|  never be inspecting a metavariable in this way.
|  
|  Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Relocatable dist

[Joachim Breitner]

Hi,

Am Montag, den 23.10.2017, 14:04 +0800 schrieb Moritz Angermann:
> I've come wonder, how hard it could be to
> make GHC relocatable. (e.g. just unpack the distribution, 
> and use the compiler from the `bin` folder within).

Yes yes yes please!

(Sorry for not contributing anything but motivation.)

Joachim


-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


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

Re: Is stage-1 sufficient to run nofib

[Joachim Breitner]

Hi,

Am Sonntag, den 22.10.2017, 23:14 -0400 schrieb Joachim Breitner:
> Am Sonntag, den 22.10.2017, 22:23 -0400 schrieb Edward Z. Yang:
> > Yes, but you still need to build the libraries, so the speed up
> > will not be as much as you might hope.
> 
> sure, but when you build every GHC commit, then even a small
> improvement is nice.
> 
> Do you know the proper way of building only libraries + ghc-stage1?

nevermind, perf.haskell.org also measures compiler performances (in the
test suite), so I need stage2.

Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


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

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

[Joachim Breitner]

Hi,

JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes
the issue for perf.haskell.org.

Greetings,
Joachim

Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann:
> Hi,
> 
> As it turns out this might be linker madness. I do not yet understand why 
> this did work with
> the "old" libffi though.
> 
> The command that fails is a rather long gcc invocation asking it to link a 
> bunch of libraries together.
> 
> $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] 
> -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...]
> 
> From the error message, we know taht ghci depends on libffi. E.g.
> 
> > libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 
> > 'ffi_prep_cif'
> 
> Now there are two possible configurations that do (successfully) link on my 
> test machine:
> 
> 1.) Droppping `-fuse-ld=gold`.
> 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`.
> 
> I guess we could also add the libffi symbols the the other -Wl,-u,... symbols.
> 
> Obviously I would not see this on macOS, as there is no go.ld on macOS. On my 
> ubuntu system, gold is
> > GNU gold (GNU Binutils for Ubuntu 2.27) 1.12
> 
> Again, as I stated in the beginning, I fail to understand why this should 
> related to the new libffi version.
> 
> As such running `LD=ld ./configure && make -j` does indeed complete 
> successfully on my machine.
> 
> If someone has any idea what the core issue between the libffi update and 
> these build failures is, I'd be happy
> to know!
> 
> Cheers,
>  Moritz
> 
> > On Oct 18, 2017, at 11:38 PM, Joachim Breitner  
> > wrote:
> > 
> > Hi,
> > 
> > it’s an Arch linux (generously sponsored by Richard’s university). I
> > have not idea how to give more precise information about the distro
> > release version or such :-)
> > 
> > Greetings,
> > Joachim
> > 
> > Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
> > > Hi,
> > > 
> > > so this somehow looks like for a not yet absolutely clear reason to me,
> > > when building ghci, we fail to link in libffi, for some configurations.
> > > 
> > > Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
> > > compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
> > > I assume Ben bootstraps wit 8.2.1.
> > > 
> > > I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
> > > 
> > > Joachim, is perf.haskell.org running Ubuntu as well?
> > > 
> > > Cheers,
> > > Moritz
> > > 
> > > > On Oct 11, 2017, at 1:43 AM, Thomas Jakway  wrote:
> > > > 
> > > > Thanks for getting back to me.
> > > > 
> > > > (I think you mean `git clean -x -f -d`): I usually omit -x but I'll 
> > > > give it a go and report back.
> > > > 
> > > > Before I got the issue on a clean checkout I thought it was something I 
> > > > did to the build files.
> > > > 
> > > > I also tried building the latest release of libffi (v3.2.1) and using 
> > > > it in configure with --with-ffi-includes and --with-ffi-libraries but 
> > > > got the same error.
> > > > 
> > > > 
> > > > On 10/09/2017 02:40 AM, Moritz Angermann wrote:
> > > > > Yes, this commit indeed introduced the need for makeinfo, however 
> > > > > after some debugging and improved packaging of the external libffi 
> > > > > library, this dependency was removed again, and should not be 
> > > > > required with the latest head anymore.
> > > > > 
> > > > > Then again this should not result in link issues but rather in build 
> > > > > time issues.
> > > > > 
> > > > > The key to libffi is the libffi-tarballs git submodule, which 
> > > > > contains the packaged libffi-tarballs. Make sure all your submodules 
> > > > > are also updated.
> > > > > 
> > > > > I usually use `git -x -f -d` (read the documentation first) to ensure 
> > > > > a clean working tree. Especially as you say you can’t reproduce it on 
> > > > > other machines, maybe there is a file in your tree that the cleaning 
> > > > > did not catch?
> > > > > 
> > > > > Sent from my iPhone
> > > > > 
> > > > > > On 9 Oct 2017, at 4:31 AM, Thomas Jakway  wrote:
> > > > > > 
> > > > > > I'm on Ubuntu 16.10.
> > > > > > 
> > > > > > I ran git bisect:
> > > > > > 
> > > > > > --
> > > > > > 
> > > > > > e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
> > > > > > commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
> > > > > > Author: Moritz Angermann 
> > > > > > Date:   Sat Sep 30 09:31:12 2017 -0400
> > > > > > 
> > > > > > Allow libffi snapshots
> > > > > > 
> > > > > > This is rather annoying. I'd prefer to have a stable release to
> > > > > > use. However libffi-3.2.1 has been released November 12, 2014, and
> > > > > > libffi-4 is TBD. See also 
> > > > > > https://github.com/libffi/libffi/issues/296
> > > > > > 
> > > > > > The core reason for this change is that llvm changed the supported
> > > > > > assembly to unified syntax, which libffi-3.2.1 does not use, and 
> > > > > > hence
> > > > > > fails to compile for arm with llvm

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

[Moritz Angermann]

I still can’t make sense of this. Is your gold a different version now as well?

Sent from my iPhone

> On 23 Oct 2017, at 8:45 PM, Joachim Breitner  wrote:
> 
> Hi,
> 
> JFTR, upgrading the Arch installation, including ghc to 8.2.1, fixes
> the issue for perf.haskell.org.
> 
> Greetings,
> Joachim
> 
> Am Donnerstag, den 19.10.2017, 16:28 +0800 schrieb Moritz Angermann:
>> Hi,
>> 
>> As it turns out this might be linker madness. I do not yet understand why 
>> this did work with
>> the "old" libffi though.
>> 
>> The command that fails is a rather long gcc invocation asking it to link a 
>> bunch of libraries together.
>> 
>> $ gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE '-fuse-ld=gold' [...] 
>> -lHSghci-8.3-ghc8.3.20171018 [...] -lffi [...]
>> 
>> From the error message, we know taht ghci depends on libffi. E.g.
>> 
>>> libHSghci-8.3-ghc8.3.20171018.so: error: undefined reference to 
>>> 'ffi_prep_cif'
>> 
>> Now there are two possible configurations that do (successfully) link on my 
>> test machine:
>> 
>> 1.) Droppping `-fuse-ld=gold`.
>> 2.) Moving `-lffi` prior to `-lHSghci-8.3-ghc8.3.20171018`.
>> 
>> I guess we could also add the libffi symbols the the other -Wl,-u,... 
>> symbols.
>> 
>> Obviously I would not see this on macOS, as there is no go.ld on macOS. On 
>> my ubuntu system, gold is
>>> GNU gold (GNU Binutils for Ubuntu 2.27) 1.12
>> 
>> Again, as I stated in the beginning, I fail to understand why this should 
>> related to the new libffi version.
>> 
>> As such running `LD=ld ./configure && make -j` does indeed complete 
>> successfully on my machine.
>> 
>> If someone has any idea what the core issue between the libffi update and 
>> these build failures is, I'd be happy
>> to know!
>> 
>> Cheers,
>> Moritz
>> 
>>> On Oct 18, 2017, at 11:38 PM, Joachim Breitner  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> it’s an Arch linux (generously sponsored by Richard’s university). I
>>> have not idea how to give more precise information about the distro
>>> release version or such :-)
>>> 
>>> Greetings,
>>> Joachim
>>> 
>>> Am Mittwoch, den 18.10.2017, 22:02 +0800 schrieb Moritz Angermann:
 Hi,
 
 so this somehow looks like for a not yet absolutely clear reason to me,
 when building ghci, we fail to link in libffi, for some configurations.
 
 Joachim, as far as I could see, you are using ghc 8.0.1 to boostrap the
 compiler. Thomas are you by any chance bootstrapping with 8.0.1 as well?
 I assume Ben bootstraps wit 8.2.1.
 
 I'll set up a Ubuntu 16.10 machine tomorrow and try to reproduce this.
 
 Joachim, is perf.haskell.org running Ubuntu as well?
 
 Cheers,
 Moritz
 
> On Oct 11, 2017, at 1:43 AM, Thomas Jakway  wrote:
> 
> Thanks for getting back to me.
> 
> (I think you mean `git clean -x -f -d`): I usually omit -x but I'll give 
> it a go and report back.
> 
> Before I got the issue on a clean checkout I thought it was something I 
> did to the build files.
> 
> I also tried building the latest release of libffi (v3.2.1) and using it 
> in configure with --with-ffi-includes and --with-ffi-libraries but got 
> the same error.
> 
> 
>> On 10/09/2017 02:40 AM, Moritz Angermann wrote:
>> Yes, this commit indeed introduced the need for makeinfo, however after 
>> some debugging and improved packaging of the external libffi library, 
>> this dependency was removed again, and should not be required with the 
>> latest head anymore.
>> 
>> Then again this should not result in link issues but rather in build 
>> time issues.
>> 
>> The key to libffi is the libffi-tarballs git submodule, which contains 
>> the packaged libffi-tarballs. Make sure all your submodules are also 
>> updated.
>> 
>> I usually use `git -x -f -d` (read the documentation first) to ensure a 
>> clean working tree. Especially as you say you can’t reproduce it on 
>> other machines, maybe there is a file in your tree that the cleaning did 
>> not catch?
>> 
>> Sent from my iPhone
>> 
>>> On 9 Oct 2017, at 4:31 AM, Thomas Jakway  wrote:
>>> 
>>> I'm on Ubuntu 16.10.
>>> 
>>> I ran git bisect:
>>> 
>>> --
>>> 
>>> e515c7f37be97e1c2ccc497ddd0a730e63ddfa82 is the first bad commit
>>> commit e515c7f37be97e1c2ccc497ddd0a730e63ddfa82
>>> Author: Moritz Angermann 
>>> Date:   Sat Sep 30 09:31:12 2017 -0400
>>> 
>>> Allow libffi snapshots
>>> 
>>> This is rather annoying. I'd prefer to have a stable release to
>>> use. However libffi-3.2.1 has been released November 12, 2014, and
>>> libffi-4 is TBD. See also https://github.com/libffi/libffi/issues/296
>>> 
>>> The core reason for this change is that llvm changed the supported
>>> assembly to unified syntax, which libffi-3.2.1 does not use, and hence
>>> fails to compile for arm with ll

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

[Joachim Breitner]

Hi,

Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann:
> I still can’t make sense of this. Is your gold a different version now as 
> well?

It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was
upgraded:
[2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 -> 2.29.1-1)

Here is the full build log:
https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/052ec24412e285aa34911d6187cc2227fc7d86d9.log

Joachim
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


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

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

[Sylvain Henry]

I don't know if it helps, but upgrading my ArchLinux installation 
yesterday broke my builds because of linker issues with stack. I now 
have to specify "ghc-build: nopie" in stack.yaml file. (cf 
https://github.com/commercialhaskell/stack/issues/2712)


Could your error be related to PIE too?


On 23/10/2017 14:57, Joachim Breitner wrote:

Hi,

Am Montag, den 23.10.2017, 20:49 +0800 schrieb Moritz Angermann:

I still can’t make sense of this. Is your gold a different version now as well?

It is “GNU gold (GNU Binutils 2.29.1) 1.14” now, and it seems it was
upgraded:
[2017-10-22 16:58] [ALPM] upgraded binutils (2.27-1 -> 2.29.1-1)

Here is the full build log:
https://raw.githubusercontent.com/nomeata/ghc-speed-logs/master/052ec24412e285aa34911d6187cc2227fc7d86d9.log

Joachim


___
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

Can't build docs

[Simon Peyton Jones via ghc-devs]

On Linux I can't build the docs.  Log below
Simon


"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,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` 
rts/dist/build/Adjustor.l_dyn_o rts/dist/build/Arena.l_dyn_o 
rts/dist/build/Capability.l_dyn_o rts/dist/build/CheckUnload.l_dyn_o 
rts/dist/build/ClosureFlags.l_dyn_o rts/dist/build/Disassembler.l_dyn_o 
rts/dist/build/FileLock.l_dyn_o rts/dist/build/Globals.l_dyn_o 
rts/dist/build/Hash.l_dyn_o rts/dist/build/Hpc.l_dyn_o 
rts/dist/build/HsFFI.l_dyn_o rts/dist/build/Inlines.l_dyn_o 
rts/dist/build/Interpreter.l_dyn_o rts/dist/build/LdvProfile.l_dyn_o 
rts/dist/build/Libdw.l_dyn_o rts/dist/build/LibdwPool.l_dyn_o 
rts/dist/build/Linker.l_dyn_o rts/dist/build/Messages.l_dyn_o 
rts/dist/build/OldARMAtomic.l_dyn_o rts/dist/build/PathUtils.l_dyn_o 
rts/dist/build/Pool.l_dyn_o rts/dist/build/Printer.l_dyn_o 
rts/dist/build/ProfHeap.l_dyn_o rts/dist/build/ProfilerReport.l_dyn_o 
rts/dist/build/ProfilerReportJson.l_dyn_o rts/dist/build/Profiling.l_dyn_o 
rts/dist/build/Proftimer.l_dyn_o rts/dist/build/RaiseAsync.l_dyn_o 
rts/dist/build/RetainerProfile.l_dyn_o rts/dist/build/RetainerSet.l_dyn_o 
rts/dist/build/RtsAPI.l_dyn_o rts/dist/build/RtsDllMain.l_dyn_o 
rts/dist/build/RtsFlags.l_dyn_o rts/dist/build/RtsMain.l_dyn_o 
rts/dist/build/RtsMessages.l_dyn_o rts/dist/build/RtsStartup.l_dyn_o 
rts/dist/build/RtsSymbolInfo.l_dyn_o rts/dist/build/RtsSymbols.l_dyn_o 
rts/dist/build/RtsUtils.l_dyn_o rts/dist/build/Schedule.l_dyn_o 
rts/dist/build/Sparks.l_dyn_o rts/dist/build/Stable.l_dyn_o 
rts/dist/build/StaticPtrTable.l_dyn_o rts/dist/build/Stats.l_dyn_o 
rts/dist/build/StgCRun.l_dyn_o rts/dist/build/StgPrimFloat.l_dyn_o 
rts/dist/build/STM.l_dyn_o rts/dist/build/Task.l_dyn_o 
rts/dist/build/ThreadLabels.l_dyn_o rts/dist/build/ThreadPaused.l_dyn_o 
rts/dist/build/Threads.l_dyn_o rts/dist/build/Ticky.l_dyn_o 
rts/dist/build/Timer.l_dyn_o rts/dist/build/TopHandler.l_dyn_o 
rts/dist/build/Trace.l_dyn_o rts/dist/build/Weak.l_dyn_o 
rts/dist/build/WSDeque.l_dyn_o rts/dist/build/xxhash.l_dyn_o 
rts/dist/build/hooks/FlagDefaults.l_dyn_o 
rts/dist/build/hooks/MallocFail.l_dyn_o rts/dist/build/hooks/OnExit.l_dyn_o 
rts/dist/build/hooks/OutOfHeap.l_dyn_o 
rts/dist/build/hooks/StackOverflow.l_dyn_o rts/dist/build/sm/BlockAlloc.l_dyn_o 
rts/dist/build/sm/CNF.l_dyn_o rts/dist/build/sm/Compact.l_dyn_o 
rts/dist/build/sm/Evac.l_dyn_o rts/dist/build/sm/Evac_thr.l_dyn_o 
rts/dist/build/sm/GCAux.l_dyn_o rts/dist/build/sm/GC.l_dyn_o 
rts/dist/build/sm/GCUtils.l_dyn_o rts/dist/build/sm/MarkWeak.l_dyn_o 
rts/dist/build/sm/MBlock.l_dyn_o rts/dist/build/sm/Sanity.l_dyn_o 
rts/dist/build/sm/Scav.l_dyn_o rts/dist/build/sm/Scav_thr.l_dyn_o 
rts/dist/build/sm/Storage.l_dyn_o rts/dist/build/sm/Sweep.l_dyn_o 
rts/dist/build/eventlog/EventLog.l_dyn_o 
rts/dist/build/eventlog/EventLogWriter.l_dyn_o 
rts/dist/build/linker/CacheFlush.l_dyn_o rts/dist/build/linker/Elf.l_dyn_o 
rts/dist/build/linker/elf_got.l_dyn_o 
rts/dist/build/linker/elf_plt_aarch64.l_dyn_o 
rts/dist/build/linker/elf_plt_arm.l_dyn_o rts/dist/build/linker/elf_plt.l_dyn_o 
rts/dist/build/linker/elf_reloc_aarch64.l_dyn_o 
rts/dist/build/linker/elf_reloc.l_dyn_o rts/dist/build/linker/elf_util.l_dyn_o 
rts/dist/build/linker/LoadArchive.l_dyn_o 
rts/dist/build/linker/M32Alloc.l_dyn_o rts/dist/build/linker/MachO.l_dyn_o 
rts/dist/build/linker/PEi386.l_dyn_o rts/dist/build/linker/SymbolExtras.l_dyn_o 
rts/dist/build/posix/GetEnv.l_dyn_o rts/dist/build/posix/GetTime.l_dyn_o 
rts/dist/build/posix/Itimer.l_dyn_o rts/dist/build/posix/OSMem.l_dyn_o 
rts/dist/build/posix/OSThreads.l_dyn_o rts/dist/build/posix/Select.l_dyn_o 
rts/dist/build/posix/Signals.l_dyn_o rts/dist/build/posix/TTY.l_dyn_o   
rts/dist/build/Apply.l_dyn_o rts/dist/build/Compact.l_dyn_o 
rts/dist/build/Exception.l_dyn_o rts/dist/build/HeapStackCheck.l_dyn_o 
rts/dist/build/PrimOps.l_dyn_o rts/dist/build/StgMiscClosures.l_dyn_o 
rts/dist/build/StgStartup.l_dyn_o rts/dist/build/StgStdThunks.l_dyn_o 
rts/dist/build/Updates.l_dyn_o rts/dist/build/AutoApply.l_dyn_o  -fPIC -dynamic 
-eventlog  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage-Werror -Iincludes 
-Iincludes/dist -Iincludes/dist-derivedconstants/header 
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS 
-this-unit-id rts -dcmm-lint  -i -irts -irts/dist/build -Irts/dist/build 
-irts/dist/build/./autogen -Irts/dist/build/./autogen-O2 
-Wcpp-undef-Wnoncanonical-monad-instances   -o 
rts/dist/build/libHSrts_l-ghc8.3.20171020.so
"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,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` 
rts/dist/build/Adjustor.thr_l_dyn_o rts/dist/build/Arena.thr_l_dyn_o 
rts/dist/build/Capability.thr_l_dyn_o rts/dist/build/CheckUnload.thr_l_dyn_o 
rt

RE: haddock specializeInstHead

[Simon Peyton Jones via ghc-devs]

I don’t know, but my instinct is to stick to the monomorphic version for now, 
it that’s all you need.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 20 October 2017 18:33
To: ghc-devs@haskell.org
Subject: haddock specializeInstHead

I am working the next stage of Trees that Grow into GHC [1], and need to update 
Haddock.
The `Specialize` module[2] exports a single function, `specializeInstHead` 
which is called once, specialised to `GhcRn`.
So all it needs to be for haddock use is

specializeInstHead :: InstHead GhcRn -> InstHead GhcRn
But the entire module is polymorphic in the AST parameter, so it has the 
following instead

specializeInstHead :: (Ord (IdP name), DataId name, SetName (IdP name),
NamedThing (IdP name))
   => InstHead name -> InstHead name

Question: does it need to be so polymorphic?

I am hitting issues getting the type parameter change worked through, and it 
seems a bit pointless to slog on with it if it is unnecessary.

Alan

[1] 
https://github.com/ghc/ghc/tree/wip/ttg-2017-10-13
[2] 
https://github.com/haskell/haddock/blob/a5bdb46185b7c0b3fced9a7fac9a62883d9d57b7/haddock-api/src/Haddock/Interface/Specialize.hs#L87
___
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?

[Ben Gamari]

Sylvain Henry  writes:

> I don't know if it helps, but upgrading my ArchLinux installation 
> yesterday broke my builds because of linker issues with stack. I now 
> have to specify "ghc-build: nopie" in stack.yaml file. (cf 
> https://github.com/commercialhaskell/stack/issues/2712)
>
> Could your error be related to PIE too?
>
Note that this (Trac #12759) was worked around in GHC 8.0.2 via a
autoconf check. Consequently, upgrading the your C toolchain may
require that you reinstall GHC.

Cheers,

- Ben


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

Re: Can't build docs

[Ben Gamari]

Simon Peyton Jones via ghc-devs  writes:

> On Linux I can't build the docs.  Log below
> Simon
>

[snip]

> processing users_guide.tex... index license intro 8.2.1-notes 8.4.1-notes 
> ghci runghc usage using using-warnings using-optimisation
> Exception occurred:
>   File "/usr/lib/python2.7/dist-packages/docutils/writers/__init__.py", line 
> 77, in write
> self.translate()
>   File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 35, 
> in translate
> self.document.walkabout(visitor)
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 173, in 
> walkabout
> if child.walkabout(visitor):
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 165, in 
> walkabout
> visitor.dispatch_visit(self)
>   File "/usr/lib/python2.7/dist-packages/docutils/nodes.py", line 1604, in 
> dispatch_visit
> return method(node)
>   File "/usr/lib/python2.7/dist-packages/sphinx/writers/manpage.py", line 
> 345, in unknown_visit
> raise NotImplementedError('Unknown node: ' + node.__class__.__name__)
> NotImplementedError: Unknown node: inline

Hmm, it sounds like this might be a real version incompatibility.
Perhaps we should have autoconf do a more strict version check of sphinx
and disable BUILD_SPHINX_{PDF,HTML} if too old a version is found.

Cheers,

- Ben



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

forall in constraint

[Alan & Kim Zimmerman]

I am working on the Trees that Grow stuff, and hit a small problem

I have

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )

and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )

But the problem is I do not have `thing` at this point, and to get it in
the code will involve some hs-boot nastiness.

Is there any way to require "forall thing. Data thing" inside the DataId
constraint?

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

Re: forall in constraint

[Li-yao Xia]

Hi Alan,

One way is to define a new typeclass.


type ImplicitBndrs c x thing
  = (c (XIB x thing), c (XNewImplicitBndrs x thing))

class ForallImplicitBndrs c x where
  withImplicitBndrs
:: forall thing. (ImplicitBndrs c x thing => t) -> t


Although that requires you to write one instance for every combination 
of (c, x).
The "universal instance" of ImplicitBndrs can also be wrapped in the 
Dict type in the constraints library. In fact, constraints has an even 
more general mechanism for all of this in Data.Constraint.Forall. Pro: 
no extra instances are necessary, so it is more easily extensible. Con: 
internally relies heavily on unsafeCoerce, although the above is already 
stretching the language a lot.


We start by defining a "class synonym" instead of a type synonym, to 
enable partial application.



class (c (XIB x thing), c (XNewImplicitBndrs x thing))
  => ImplicitBndrs c x thing
instance (c (XIB x thing), c (XNewImplicitBndrs x thing))
  => ImplicitBndrs c x thing


-- "forall thing. ImplicitBndrs c x thing"
type ForallImplicitBndrs c x = Forall (ImplicitBndrs c x)

withImplicitBndrs
  :: forall c x thing
  .  ForallImplicitBndrs c x
  => (ImplicitBndrs c x thing => t) -> t
withImplicitBndrs t = case inst @(ImplicitBndrs c x) @thing of
  Sub Dict -> t


I think the ICFP paper "Quantified class constraints" talks about a more 
principled future solution, and there is an old GHC ticket or two about it.


Cheers,
Li-yao


On 10/23/2017 11:06 AM, Alan & Kim Zimmerman wrote:

I am working on the Trees that Grow stuff, and hit a small problem

I have

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
( c (XIB   x thing)
, c (XNewImplicitBndrs x thing)
)

and I want to extend the DataId constraint

type DataId p =
   ( Data p

   , ForallXImplicitBndrs Data p thing
   )

But the problem is I do not have `thing` at this point, and to get it in
the code will involve some hs-boot nastiness.

Is there any way to require "forall thing. Data thing" inside the DataId
constraint?

Alan
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://mail.haskell.org/pipermail/ghc-devs/attachments/20171023/77c963b5/attachment.html>


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

RE: forall in constraint

[Simon Peyton Jones via ghc-devs]

I’m lost. Could you give me a bit more context?

I’m deeply suspicious about that ForallXImplicitBndrs thing with strange higher 
kinded parameters.   Smells all wrong to me.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Alan & Kim 
Zimmerman
Sent: 23 October 2017 16:07
To: ghc-devs@haskell.org
Subject: forall in constraint

I am working on the Trees that Grow stuff, and hit a small problem
I have

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )
and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )
But the problem is I do not have `thing` at this point, and to get it in the 
code will involve some hs-boot nastiness.
Is there any way to require "forall thing. Data thing" inside the DataId 
constraint?
Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: forall in constraint

[Alan & Kim Zimmerman]

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
  (XIB x thing)
  thing

  | NewImplicitBndrs
  (XNewImplicitBndrs x thing)

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )

This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)

where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the
existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to
capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which
means I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter
completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1]
https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475
[2] https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21
[3]
https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439



On 23 October 2017 at 23:04, Simon Peyton Jones 
wrote:

> I’m lost. Could you give me a bit more context?
>
>
>
> I’m deeply suspicious about that ForallXImplicitBndrs thing with strange
> higher kinded parameters.   Smells all wrong to me.
>
>
>
> Simon
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: forall in constraint

[Simon Peyton Jones via ghc-devs]

  *   Like I say I am DEEPLY suspicious of ForallXImplicitBndrs.  I can’t make 
head or tail of it.  Is see in you patch you define



type ForallXPat (c :: * -> Constraint) (x :: *) =…

   What is this?  Why do we need it? What goes wrong if we remove 
it altogether?



  *   Likewise `forall thing. Data thing` makes no sense to me as a constraint, 
 even with quantified context. Shayan and I discussed this at ICFP and agreed 
it made no sense.  The hoped-for quantified-context extension is NOT a solution.

Overall I’ve lost track of these enormous constraint tuples that seem to be 
associated with Data instances. Can you give a small artificial (ie not full 
GHC) example of why they are necessary?   Perhaps it’s this

data T p = T1 (XT1 p) Int
| T1 (XT2 p) (IdP p)

I suppose that a Data instance would need to have
   instance (Data (XT1 p), Data (XT2p), Data (IdP p)) => Data IT p) 
where…
Is that right?  In which case why do you have all this PostRn stuff in the 
DataId type?  (And why is it called DataId?)


  *   “The first approach leads to a spread of the constraint throughout the 
AST, which gets very messy.”  I don’t understand what the first approach is, or 
why it gets messy.  Could you be more concrete?
  *   “Perhaps the simplest way forward is to get rid of the `thing` parameter 
completely, and introduce the three or so ImplicitBinders variants that are 
used.”   I don’t’ think it could possibly make anything simpler to have three 
separate data types.   Can you illustrate concretely?
It’d be great to explore these issues with small, concrete examples, rather 
than the full glory of GHC, both for our own benefit and the benefit of those 
who will review the patch and (in future) understand the code.

Sorry to be slow

Simon


From: Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 23 October 2017 22:36
To: Simon Peyton Jones 
Cc: ghc-devs@haskell.org
Subject: Re: forall in constraint

In Shayan's implementation he has [1]

data ImplicitBndrs x thing
  = IB
  (XIB x thing)
  thing

  | NewImplicitBndrs
  (XNewImplicitBndrs x thing)

type family XIB   x thing
type family XNewImplicitBndrs x thing

type ForallXImplicitBndrs c x thing =
   ( c (XIB   x thing)
   , c (XNewImplicitBndrs x thing)
   )
This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)
where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to 
capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which means 
I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter 
completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1] 
https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475
[2] 
https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21
[3] 
https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439



On 23 October 

perf.haskell.org functional again

[Joachim Breitner]

Hi,

after a system upgrade to avoid weird linker errors, and after some fixes in 
the nofib submodule, http://perf.haskell.org/ghc is running again.

I am collecting instruction counts instead of runtime, because the latter was 
just too often varying too wildly. I hope this will yield less false alarms.

I am also running nofib with mode=fast. This way, building GHC, running the 
testsuite and nofib takes a bit over one hour. I hope this can keep up with 
y'all's commits (when it took 2h it couldn't).

Now nothing of the setup requires a quiet dedicated machine, so if there is a 
need, we could move these builds into the cloud or into some CI infrastructure 
- but no changes are immediately planned.

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

Re: perf.haskell.org functional again

[Moritz Angermann]

Hooray! Thanks for doing this!

Sent from my iPhone

> On 24 Oct 2017, at 8:02 AM, Joachim Breitner  wrote:
> 
> Hi,
> 
> after a system upgrade to avoid weird linker errors, and after some fixes in 
> the nofib submodule, http://perf.haskell.org/ghc is running again.
> 
> I am collecting instruction counts instead of runtime, because the latter was 
> just too often varying too wildly. I hope this will yield less false alarms.
> 
> I am also running nofib with mode=fast. This way, building GHC, running the 
> testsuite and nofib takes a bit over one hour. I hope this can keep up with 
> y'all's commits (when it took 2h it couldn't).
> 
> Now nothing of the setup requires a quiet dedicated machine, so if there is a 
> need, we could move these builds into the cloud or into some CI 
> infrastructure - but no changes are immediately planned.
> 
> Enjoy, Joachim 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: perf.haskell.org functional again

[Manuel M T Chakravarty]

Hi Joachim,

Great! Just because you mention CI infrastructure and our effort around GHC CI 
at the moment, do you think, it would make sense to move this to CircleCI 
eventually?

Cheers,
Manuel

> Am 24.10.2017 um 11:02 schrieb Joachim Breitner :
> 
> Hi,
> 
> after a system upgrade to avoid weird linker errors, and after some fixes in 
> the nofib submodule, http://perf.haskell.org/ghc is running again.
> 
> I am collecting instruction counts instead of runtime, because the latter was 
> just too often varying too wildly. I hope this will yield less false alarms.
> 
> I am also running nofib with mode=fast. This way, building GHC, running the 
> testsuite and nofib takes a bit over one hour. I hope this can keep up with 
> y'all's commits (when it took 2h it couldn't).
> 
> Now nothing of the setup requires a quiet dedicated machine, so if there is a 
> need, we could move these builds into the cloud or into some CI 
> infrastructure - but no changes are immediately planned.
> 
> Enjoy, Joachim 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Relocatable dist

[Manuel M T Chakravarty]

Hi Moritz,

Haskell for Mac is fully relocatable (as every Mac users expects this of a Mac 
app).

Unfortunately, it is not just the libdir in the wrapper scripts that’s in the 
way of a relocatable GHC. Additional problems are (1) the (at least, as of 8.0) 
still not macOS-friendly RPATHs in dynamic libraries and (2) the absolute paths 
in package .conf files.

In Haskell for Mac, I use two arguably hacky solutions to those two issues. I 
rewrite all RPATHs in .dylibs to be relative and I have got a little tool that 
relocates .conf files. I’d certainly prefer a cleaner solution!

Those aspects of Haskell for Mac are actually in a separate framework 
(GHC.framework) that wraps GHC and some other tools. This is all in a public 
repo if you like to have a look

  https://github.com/haskellformac/GHCframework 


I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of 
course all highly Mac specific and requires Xcode to build for all the code 
signing, sandboxing, etc.

Cheers,
Manuel

> Am 23.10.2017 um 17:04 schrieb Moritz Angermann :
> 
> Hi,
> 
> while trying to make the binary-distribution logic work for
> cross compilers.  I've come wonder, how hard it could be to
> make GHC relocatable. (e.g. just unpack the distribution, 
> and use the compiler from the `bin` folder within).
> 
> Right now this does not work due to the need for the path to
> package.conf, and this is hardcoded in the wrapper script to
> provide the proper libdir to ghc via -B[1]. Supposedly this
> is not an issue on Windows, as a relative path is common on
> windows and finding the location of the executable can be done
> safely. Or that's at least how I understand[1].
> 
> For macOS there is the haskell-platform, and ghc-dot-app[2]
> 
> From [3], it sounds like automake is a build, and not a packaging
> system, and the binary dist usecase with configure is not
> really a standard use case.
> 
> So why do I bring this up NOW? Apart from me trying to make
> cross compiler binary distributions working?  The reason is
> that we are also trying to move towards hadrian, and by "starting
> from scratch", maybe we have a chance to reconsider how we
> do things?
> 
> I must admit, I'm quite happy to use packages like llvm, by
> just downloading a package and adding the `bin` path to my
> $PATH.
> 
> There is however one thing that the current configure appraoch
> does, which I think is quite noteworthy (apart from setting
> $prefix).  That is, it does check for compilers and sets them
> accordingly, which might be desirable.
> 
> Cheers,
> Moritz
> 
> --
> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg5.html
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

Re: Relocatable dist

[Moritz Angermann]

Hi Manuel,

thanks for the link!  Ahh yes lovely RPATH (this reminds me, I should look
to verify if I can make GHC link recursively.)  The conf files came up on
#ghc yesterday as well. Maybe we need some $home, $sysroot or similar marker
to make them relocatable.

I'll probably take a crack at this today.  Not sure how far I get though.
The primary motivation is that packaging the cross compilers in a neat
way looks like layering patched upon patches onto the configure script. And
in light of Hadrian, we might just want to package up a directory and not
deal with the binary-dist logic where we can?

Cheers,
 Moritz

> On Oct 24, 2017, at 9:45 AM, Manuel M T Chakravarty  
> wrote:
> 
> Hi Moritz,
> 
> Haskell for Mac is fully relocatable (as every Mac users expects this of a 
> Mac app).
> 
> Unfortunately, it is not just the libdir in the wrapper scripts that’s in the 
> way of a relocatable GHC. Additional problems are (1) the (at least, as of 
> 8.0) still not macOS-friendly RPATHs in dynamic libraries and (2) the 
> absolute paths in package .conf files.
> 
> In Haskell for Mac, I use two arguably hacky solutions to those two issues. I 
> rewrite all RPATHs in .dylibs to be relative and I have got a little tool 
> that relocates .conf files. I’d certainly prefer a cleaner solution!
> 
> Those aspects of Haskell for Mac are actually in a separate framework 
> (GHC.framework) that wraps GHC and some other tools. This is all in a public 
> repo if you like to have a look
> 
>   https://github.com/haskellformac/GHCframework
> 
> I haven’t put a license on it, but I’d be happy to make it all BSD3. It is of 
> course all highly Mac specific and requires Xcode to build for all the code 
> signing, sandboxing, etc.
> 
> Cheers,
> Manuel
> 
>> Am 23.10.2017 um 17:04 schrieb Moritz Angermann :
>> 
>> Hi,
>> 
>> while trying to make the binary-distribution logic work for
>> cross compilers.  I've come wonder, how hard it could be to
>> make GHC relocatable. (e.g. just unpack the distribution, 
>> and use the compiler from the `bin` folder within).
>> 
>> Right now this does not work due to the need for the path to
>> package.conf, and this is hardcoded in the wrapper script to
>> provide the proper libdir to ghc via -B[1]. Supposedly this
>> is not an issue on Windows, as a relative path is common on
>> windows and finding the location of the executable can be done
>> safely. Or that's at least how I understand[1].
>> 
>> For macOS there is the haskell-platform, and ghc-dot-app[2]
>> 
>> From [3], it sounds like automake is a build, and not a packaging
>> system, and the binary dist usecase with configure is not
>> really a standard use case.
>> 
>> So why do I bring this up NOW? Apart from me trying to make
>> cross compiler binary distributions working?  The reason is
>> that we are also trying to move towards hadrian, and by "starting
>> from scratch", maybe we have a chance to reconsider how we
>> do things?
>> 
>> I must admit, I'm quite happy to use packages like llvm, by
>> just downloading a package and adding the `bin` path to my
>> $PATH.
>> 
>> There is however one thing that the current configure appraoch
>> does, which I think is quite noteworthy (apart from setting
>> $prefix).  That is, it does check for compilers and sets them
>> accordingly, which might be desirable.
>> 
>> Cheers,
>> Moritz
>> 
>> --
>> [1]: https://ghc.haskell.org/trac/ghc/wiki/Building/Installing
>> [2]: https://ghc.haskell.org/trac/ghc/wiki/Building/MacOSX/Installer
>> [3]: https://lists.gnu.org/archive/html/automake/2006-10/msg5.html
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

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

Re: perf.haskell.org functional again

[Joachim Breitner]

Hi,

Is CircleCI the future now?

In general, yes. But it’s running fine for now, so I would not
prematurely throw it over.

My requirements are: 

 * needs to run on every commit (not just every push), including 
   branches.
 * needs to be able to push to a repository¹, so it needs access to 
   some secret token for depolyment.
   Alternatively, the CI could simply keep track of the build log
   and the perf.haskell.org dashboard scrapes it from there.
 * Occasionally, I find that I want to rebuild a fair number of commits
   that are already in the repository. So a good way to trigger
   rebuilds would be nice.

Greetings,
Joachim

¹ https://github.com/nomeata/ghc-speed-logs/commits/master

Am Dienstag, den 24.10.2017, 12:18 +1100 schrieb Manuel M T
Chakravarty:
> Hi Joachim,
> 
> Great! Just because you mention CI infrastructure and our effort around GHC 
> CI at the moment, do you think, it would make sense to move this to CircleCI 
> eventually?
> 
> Cheers,
> Manuel
> 
> > Am 24.10.2017 um 11:02 schrieb Joachim Breitner :
> > 
> > Hi,
> > 
> > after a system upgrade to avoid weird linker errors, and after some fixes 
> > in the nofib submodule, http://perf.haskell.org/ghc is running again.
> > 
> > I am collecting instruction counts instead of runtime, because the latter 
> > was just too often varying too wildly. I hope this will yield less false 
> > alarms.
> > 
> > I am also running nofib with mode=fast. This way, building GHC, running the 
> > testsuite and nofib takes a bit over one hour. I hope this can keep up with 
> > y'all's commits (when it took 2h it couldn't).
> > 
> > Now nothing of the setup requires a quiet dedicated machine, so if there is 
> > a need, we could move these builds into the cloud or into some CI 
> > infrastructure - but no changes are immediately planned.
> > 
> > Enjoy, Joachim 
-- 
Joachim Breitner
  m...@joachim-breitner.de
  http://www.joachim-breitner.de/


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