Re: Question about Gitlab MR workflow.

[Ömer Sinan Ağacan]

Hi,

>  About 4:  I really don't understand how this rebasing business is intended to
>  work: every time I rebase, I new CI job is fired up.  But, presumably, while
>  this is going, other things are going to be merged with `master`, so I'd need
>  to rebase again.   So, when would I ever stop rebasing?

Rebasing is actually not necessary. Marge adds your MR to the batch MR when it's
approved and passed the tests. It doesn't have to be based on HEAD. So just
don't bother with it.

Only time I needed a rebase was when there was a failing test in HEAD and a
commit that disabled it had just landed. My MR was not passing the tests because
of the test so I had to rebase.

Ömer

Iavor Diatchki , 9 May 2019 Per, 02:19
tarihinde şunu yazdı:
>
> Hello,
>
> I've just had a go at making a small MR on our new Gitlab system, and
> I am a bit confused about the intended workflow.  I was following
> these instructions :
>
> https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs
>
> My question is about the steps after 2 (i.e., 3 and 4).  Step 5 about
> the beer I already did :-)  Here was my experience so far:
>
> 1.  I made the changes I wanted yesterday over lunch: the change was
> quite trivial, I added a NOINLINE pragma and some comments and I mage
> the MR.
>
> 2. Sometime in the evening (half a day later!)  I got an e-mail from
> the CI system that something had failed.  It was quite hard to tell
> what had failed, and after poking around at the logs, it seemed like
> it was some sort of spurious failures because things had timed out, I
> think?
>
> 3. Today I got some feedback from a reviewer about some changes I
> should make to the MR.  As I was working on those, I noticed that
> every time I push to the MR, the CI is forking a new job.  I cancelled
> some of those manually, to save on resources, as they already seem to
> be taking half a day.
>
> 4. After making the changes, I noticed that Gitlab is asking me to
> rebase my changes because, presumably, some other things have already
> been merged.   It is easy enough to rebase my MR, but every time I do
> so, this fires up a new CI job.   And, of course, this is going to
> keep happening, until I am lucky enough to rebase just at the right
> time?  This doesn't seem right.
>
> So my questions are specifically about step 3 and 4:
>
>About 3:  wouldn't it make more sense to start firing up CI jobs
> only after an MR has been approved for merging?
>
>About 4:  I really don't understand how this rebasing business is
> intended to work: every time I rebase, I new CI job is fired up.  But,
> presumably, while this is going, other things are going to be merged
> with `master`, so I'd need to rebase again.   So, when would I ever
> stop rebasing?
> Furthermore, in my case the rebase is trivial, but with a larger
> patch, doing multiple rebases seems like a lot of wasted work.
>
> Any help would be appreciated!
>
> -Iavor
> ___
> 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: Old build system broken

[Ömer Sinan Ağacan]

> If you do a fresh checkout and build, the problem should go away.

You can also do `git clean -xfd`.

Ömer

Richard Eisenberg , 8 May 2019 Çar, 23:33 tarihinde
şunu yazdı:
>
> Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean 
> is not deleting settings files, which cause this bug. If you do a fresh 
> checkout and build, the problem should go away. It's also possible that 
> deleting inplace/lib/settings manually (and then running ./configure) may 
> also fix it.
>
> Richard
>
> > On May 8, 2019, at 3:51 PM, Richard Eisenberg  wrote:
> >
> > Me too. I'm on a Mac. Deepest apologies (because I know this makes me 
> > useless), but I don't have the error message any more. It mentioned "Tables 
> > next to code" and the settings file, so I'm confident that it's related.
> >
> > Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem 
> > for me.
> >
> > Richard
> >
> >> On May 8, 2019, at 3:48 PM, Karel Gardas  wrote:
> >>
> >>
> >> Sorry to hijack the thread, I get something very similar on ppc64le linux:
> >>
> >> Configuring ghc-prim-0.6.1...
> >> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
> >> No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"
> >>
> >> libraries/ghc-prim/ghc.mk:4: recipe for target 
> >> 'libraries/ghc-prim/dist-install/package-data.mk' failed
> >> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
> >> Makefile:123: recipe for target 'all' failed
> >> make: *** [all] Error 2
> >>
> >> this is from today's HEAD.
> >>
> >> Thanks,
> >> Karel
> >>
> >> On 05/ 8/19 09:28 PM, Phyx wrote:
> >>> That looks like stage1 has been improperly configured.
> >>>
> >>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
> >>> *
> >>> *
> >>> *Return anything sensible for target arch? *
> >>> *
> >>> *
> >>> *I still use the make system exclusively and haven't noticed a failure. *
> >>> *
> >>> *
> >>> *But my nightlies haven't kicked off yet today. *
> >>> *
> >>> *
> >>> *Thanks, *
> >>> *Tamar
> >>> *
> >>> Sent from my Mobile
> >>>
> >>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
> >>> mailto:ghc-devs@haskell.org>> wrote:
> >>>
> >>>   I know we are supposed to be using Hadrian now, but is the old build
> >>>   system supposed to be broken? 
> >>>
> >>>   A clean build fails with
> >>>
> >>>   "inplace/bin/ghc-cabal" check libraries/ghc-prim
> >>>
> >>>   "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
> >>>   --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
> >>>   --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
> >>>   --disable-library-for-ghci --enable-library-vanilla
> >>>   --enable-library-for-ghci --disable-library-profiling
> >>>   --enable-shared --configure-option=CFLAGS="-Wall
> >>>   -Werror=unused-but-set-variable -Wno-error=inline"
> >>>   --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
> >>>   --gcc-options="-Wall -Werror=unused-but-set-variable
> >>>   -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
> >>>   --with-ar="ar" --with-alex="/usr/bin/alex"
> >>>   --with-happy="/usr/bin/happy"
> >>>
> >>>   Configuring ghc-prim-0.6.1...
> >>>
> >>>   ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
> >>>   with an
> >>>
> >>>   error:
> >>>
> >>>   Failed to read "target arch" value ""
> >>>
> >>>   __ __
> >>>
> >>>   libraries/ghc-prim/ghc.mk:4 : recipe for target
> >>>   'libraries/ghc-prim/dist-install/package-data.mk
> >>>   ' failed
> >>>
> >>>   make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
> >>>   ] Error 1
> >>>
> >>>   Makefile:123: recipe for target 'all' failed
> >>>
> >>>   make: *** [all] Error 2
> >>>
> >>>   simonpj@MSRC-3645512:~/code/HEAD$
> >>>
> >>>   ___
> >>>   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
> >
> > ___
> > 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

Question about Gitlab MR workflow.

[Iavor Diatchki]

Hello,

I've just had a go at making a small MR on our new Gitlab system, and
I am a bit confused about the intended workflow.  I was following
these instructions :

https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs

My question is about the steps after 2 (i.e., 3 and 4).  Step 5 about
the beer I already did :-)  Here was my experience so far:

1.  I made the changes I wanted yesterday over lunch: the change was
quite trivial, I added a NOINLINE pragma and some comments and I mage
the MR.

2. Sometime in the evening (half a day later!)  I got an e-mail from
the CI system that something had failed.  It was quite hard to tell
what had failed, and after poking around at the logs, it seemed like
it was some sort of spurious failures because things had timed out, I
think?

3. Today I got some feedback from a reviewer about some changes I
should make to the MR.  As I was working on those, I noticed that
every time I push to the MR, the CI is forking a new job.  I cancelled
some of those manually, to save on resources, as they already seem to
be taking half a day.

4. After making the changes, I noticed that Gitlab is asking me to
rebase my changes because, presumably, some other things have already
been merged.   It is easy enough to rebase my MR, but every time I do
so, this fires up a new CI job.   And, of course, this is going to
keep happening, until I am lucky enough to rebase just at the right
time?  This doesn't seem right.

So my questions are specifically about step 3 and 4:

   About 3:  wouldn't it make more sense to start firing up CI jobs
only after an MR has been approved for merging?

   About 4:  I really don't understand how this rebasing business is
intended to work: every time I rebase, I new CI job is fired up.  But,
presumably, while this is going, other things are going to be merged
with `master`, so I'd need to rebase again.   So, when would I ever
stop rebasing?
Furthermore, in my case the rebase is trivial, but with a larger
patch, doing multiple rebases seems like a lot of wasted work.

Any help would be appreciated!

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

Re: Old build system broken

[John Cotton Ericson]

Yeah so what I did is making settings no longer be created directly by 
configure, but by make and hadrian. I did this because I'm moving 
configurations options from Config.hs to there, Config.hs was generated 
by make and hadrian, and the whole thing will become stage-specific.


I tried do mimic what hadrian/make for `Config.hs` and the various 
header files like `ghcplatform.h`, but evidently I missed how those are 
invalidated / cleaned up (unless they change so infrequently that 
cleaning up never worked).


I'm happy to make the fix (especially as I hope to change `settings` 
some more), but I would appreciate some advise from people in the know 
about how the cleaning ought to work. I suspect the cleaning with both 
build systems is broken.


Sorry for the disruption,

John

On 5/8/19 4:33 PM, Richard Eisenberg wrote:

Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is 
not deleting settings files, which cause this bug. If you do a fresh checkout 
and build, the problem should go away. It's also possible that deleting 
inplace/lib/settings manually (and then running ./configure) may also fix it.

Richard


On May 8, 2019, at 3:51 PM, Richard Eisenberg  wrote:

Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), but I 
don't have the error message any more. It mentioned "Tables next to code" and 
the settings file, so I'm confident that it's related.

Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for 
me.

Richard


On May 8, 2019, at 3:48 PM, Karel Gardas  wrote:


Sorry to hijack the thread, I get something very similar on ppc64le linux:

Configuring ghc-prim-0.6.1...
ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"

libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/package-data.mk' failed
make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2

this is from today's HEAD.

Thanks,
Karel

On 05/ 8/19 09:28 PM, Phyx wrote:

That looks like stage1 has been improperly configured.

Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
*
*
*Return anything sensible for target arch? *
*
*
*I still use the make system exclusively and haven't noticed a failure. *
*
*
*But my nightlies haven't kicked off yet today. *
*
*
*Thanks, *
*Tamar
*
Sent from my Mobile

On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:

   I know we are supposed to be using Hadrian now, but is the old build
   system supposed to be broken? 

   A clean build fails with

   "inplace/bin/ghc-cabal" check libraries/ghc-prim

   "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
   --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
   --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
   --disable-library-for-ghci --enable-library-vanilla
   --enable-library-for-ghci --disable-library-profiling
   --enable-shared --configure-option=CFLAGS="-Wall
   -Werror=unused-but-set-variable -Wno-error=inline"
   --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
   --gcc-options="-Wall -Werror=unused-but-set-variable
   -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
   --with-ar="ar" --with-alex="/usr/bin/alex"
   --with-happy="/usr/bin/happy"

   Configuring ghc-prim-0.6.1...

   ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
   with an

   error:

   Failed to read "target arch" value ""

   __ __

   libraries/ghc-prim/ghc.mk:4 : recipe for target
   'libraries/ghc-prim/dist-install/package-data.mk
   ' failed

   make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
   ] Error 1

   Makefile:123: recipe for target 'all' failed

   make: *** [all] Error 2

   simonpj@MSRC-3645512:~/code/HEAD$

   ___
   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

___
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: Old build system broken

[Richard Eisenberg]

Some discussion on IRC with @Ericson2314 reveals that make maintainer-clean is 
not deleting settings files, which cause this bug. If you do a fresh checkout 
and build, the problem should go away. It's also possible that deleting 
inplace/lib/settings manually (and then running ./configure) may also fix it.

Richard

> On May 8, 2019, at 3:51 PM, Richard Eisenberg  wrote:
> 
> Me too. I'm on a Mac. Deepest apologies (because I know this makes me 
> useless), but I don't have the error message any more. It mentioned "Tables 
> next to code" and the settings file, so I'm confident that it's related.
> 
> Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem 
> for me.
> 
> Richard
> 
>> On May 8, 2019, at 3:48 PM, Karel Gardas  wrote:
>> 
>> 
>> Sorry to hijack the thread, I get something very similar on ppc64le linux:
>> 
>> Configuring ghc-prim-0.6.1...
>> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
>> No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"
>> 
>> libraries/ghc-prim/ghc.mk:4: recipe for target 
>> 'libraries/ghc-prim/dist-install/package-data.mk' failed
>> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
>> Makefile:123: recipe for target 'all' failed
>> make: *** [all] Error 2
>> 
>> this is from today's HEAD.
>> 
>> Thanks,
>> Karel
>> 
>> On 05/ 8/19 09:28 PM, Phyx wrote:
>>> That looks like stage1 has been improperly configured.
>>> 
>>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
>>> *
>>> *
>>> *Return anything sensible for target arch? *
>>> *
>>> *
>>> *I still use the make system exclusively and haven't noticed a failure. *
>>> *
>>> *
>>> *But my nightlies haven't kicked off yet today. *
>>> *
>>> *
>>> *Thanks, *
>>> *Tamar
>>> *
>>> Sent from my Mobile
>>> 
>>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
>>> mailto:ghc-devs@haskell.org>> wrote:
>>> 
>>>   I know we are supposed to be using Hadrian now, but is the old build
>>>   system supposed to be broken? 
>>> 
>>>   A clean build fails with
>>> 
>>>   "inplace/bin/ghc-cabal" check libraries/ghc-prim
>>> 
>>>   "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
>>>   --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
>>>   --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
>>>   --disable-library-for-ghci --enable-library-vanilla
>>>   --enable-library-for-ghci --disable-library-profiling
>>>   --enable-shared --configure-option=CFLAGS="-Wall
>>>   -Werror=unused-but-set-variable -Wno-error=inline"
>>>   --configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
>>>   --gcc-options="-Wall -Werror=unused-but-set-variable
>>>   -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
>>>   --with-ar="ar" --with-alex="/usr/bin/alex"
>>>   --with-happy="/usr/bin/happy"
>>> 
>>>   Configuring ghc-prim-0.6.1...
>>> 
>>>   ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
>>>   with an
>>> 
>>>   error:
>>> 
>>>   Failed to read "target arch" value ""
>>> 
>>>   __ __
>>> 
>>>   libraries/ghc-prim/ghc.mk:4 : recipe for target
>>>   'libraries/ghc-prim/dist-install/package-data.mk
>>>   ' failed
>>> 
>>>   make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
>>>   ] Error 1
>>> 
>>>   Makefile:123: recipe for target 'all' failed
>>> 
>>>   make: *** [all] Error 2
>>> 
>>>   simonpj@MSRC-3645512:~/code/HEAD$
>>> 
>>>   ___
>>>   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
> 
> ___
> 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: Old build system broken

[Richard Eisenberg]

Me too. I'm on a Mac. Deepest apologies (because I know this makes me useless), 
but I don't have the error message any more. It mentioned "Tables next to code" 
and the settings file, so I'm confident that it's related.

Also, reverting 1aad97887747c351727ebd7b85217f2666f5b835 fixed the problem for 
me.

Richard

> On May 8, 2019, at 3:48 PM, Karel Gardas  wrote:
> 
> 
> Sorry to hijack the thread, I get something very similar on ppc64le linux:
> 
> Configuring ghc-prim-0.6.1...
> ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
> No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"
> 
> libraries/ghc-prim/ghc.mk:4: recipe for target 
> 'libraries/ghc-prim/dist-install/package-data.mk' failed
> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
> Makefile:123: recipe for target 'all' failed
> make: *** [all] Error 2
> 
> this is from today's HEAD.
> 
> Thanks,
> Karel
> 
> On 05/ 8/19 09:28 PM, Phyx wrote:
>> That looks like stage1 has been improperly configured.
>> 
>> Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
>> *
>> *
>> *Return anything sensible for target arch? *
>> *
>> *
>> *I still use the make system exclusively and haven't noticed a failure. *
>> *
>> *
>> *But my nightlies haven't kicked off yet today. *
>> *
>> *
>> *Thanks, *
>> *Tamar
>> *
>> Sent from my Mobile
>> 
>> On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
>> mailto:ghc-devs@haskell.org>> wrote:
>> 
>>I know we are supposed to be using Hadrian now, but is the old build
>>system supposed to be broken? 
>> 
>>A clean build fails with
>> 
>>"inplace/bin/ghc-cabal" check libraries/ghc-prim
>> 
>>"inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
>>--with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
>>--with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
>>--disable-library-for-ghci --enable-library-vanilla
>>--enable-library-for-ghci --disable-library-profiling
>>--enable-shared --configure-option=CFLAGS="-Wall
>>-Werror=unused-but-set-variable -Wno-error=inline"
>>--configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
>>--gcc-options="-Wall -Werror=unused-but-set-variable
>>-Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
>>--with-ar="ar" --with-alex="/usr/bin/alex"
>>--with-happy="/usr/bin/happy"
>> 
>>Configuring ghc-prim-0.6.1...
>> 
>>ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
>>with an
>> 
>>error:
>> 
>>Failed to read "target arch" value ""
>> 
>>__ __
>> 
>>libraries/ghc-prim/ghc.mk:4 : recipe for target
>>'libraries/ghc-prim/dist-install/package-data.mk
>>' failed
>> 
>>make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
>>] Error 1
>> 
>>Makefile:123: recipe for target 'all' failed
>> 
>>make: *** [all] Error 2
>> 
>>simonpj@MSRC-3645512:~/code/HEAD$
>> 
>>___
>>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

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

Re: Old build system broken

[Karel Gardas]

Sorry to hijack the thread, I get something very similar on ppc64le linux:

Configuring ghc-prim-0.6.1...
ghc-cabal: '/tmpram/ghc/inplace/bin/ghc-stage1' exited with an error:
No entry for "Tables next to code" in "/tmpram/ghc/inplace/lib/settings"

libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/package-data.mk' failed

make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
Makefile:123: recipe for target 'all' failed
make: *** [all] Error 2

this is from today's HEAD.

Thanks,
Karel

On 05/ 8/19 09:28 PM, Phyx wrote:

That looks like stage1 has been improperly configured.

Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info
*
*
*Return anything sensible for target arch? *
*
*
*I still use the make system exclusively and haven't noticed a failure. *
*
*
*But my nightlies haven't kicked off yet today. *
*
*
*Thanks, *
*Tamar
*
Sent from my Mobile

On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs
mailto:ghc-devs@haskell.org>> wrote:

I know we are supposed to be using Hadrian now, but is the old build
system supposed to be broken? 

A clean build fails with

"inplace/bin/ghc-cabal" check libraries/ghc-prim

"inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
--with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
--with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
--disable-library-for-ghci --enable-library-vanilla
--enable-library-for-ghci --disable-library-profiling
--enable-shared --configure-option=CFLAGS="-Wall
-Werror=unused-but-set-variable -Wno-error=inline"
--configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   "
--gcc-options="-Wall -Werror=unused-but-set-variable
-Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold"
--with-ar="ar" --with-alex="/usr/bin/alex"
--with-happy="/usr/bin/happy"

Configuring ghc-prim-0.6.1...

ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited
with an

error:

Failed to read "target arch" value ""

__ __

libraries/ghc-prim/ghc.mk:4 : recipe for target
'libraries/ghc-prim/dist-install/package-data.mk
' failed

make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk
] Error 1

Makefile:123: recipe for target 'all' failed

make: *** [all] Error 2

simonpj@MSRC-3645512:~/code/HEAD$

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



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



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

Re: Old build system broken

[Phyx]

That looks like stage1 has been improperly configured.

Does /home/simonpj/code/HEAD/inplace/bin/ghc-stage1 --info

*Return anything sensible for target arch? *

*I still use the make system exclusively and haven't noticed a failure. *

*But my nightlies haven't kicked off yet today. *

*Thanks, *

*Tamar *
Sent from my Mobile

On Wed, May 8, 2019, 16:24 Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> I know we are supposed to be using Hadrian now, but is the old build
> system supposed to be broken?
>
> A clean build fails with
>
> "inplace/bin/ghc-cabal" check libraries/ghc-prim
>
> "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install
> --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1"
> --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"
> --disable-library-for-ghci --enable-library-vanilla
> --enable-library-for-ghci --disable-library-profiling --enable-shared
> --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable
> -Wno-error=inline" --configure-option=LDFLAGS="  "
> --configure-option=CPPFLAGS="   " --gcc-options="-Wall
> -Werror=unused-but-set-variable -Wno-error=inline   " --with-gcc="gcc"
> --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex"
> --with-happy="/usr/bin/happy"
>
> Configuring ghc-prim-0.6.1...
>
> ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an
>
> error:
>
> Failed to read "target arch" value ""
>
>
>
> libraries/ghc-prim/ghc.mk:4: recipe for target
> 'libraries/ghc-prim/dist-install/package-data.mk' failed
>
> make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1
>
> Makefile:123: recipe for target 'all' failed
>
> make: *** [all] Error 2
>
> simonpj@MSRC-3645512:~/code/HEAD$
> ___
> 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: CI on forked projects: Darwin woes

[Iavor Diatchki]

I think there was the ghc-devops-group list, but I don't know if it is
still active, and I kind of like to not have to follow too many lists.

For example, I had also not realized that it is an option to push to
branches on the main project, and have been using my own fork,
so thanks for posting this here!

-Iavor


On Wed, May 8, 2019 at 11:40 AM Kevin Buhr  wrote:
>
> Over the past few days, I've submitted several merge requests from
> branches on my forked project (mostly because I didn't even realize
> pushing to a branch on the main project was an alternative).
>
> When those MRs run under CI, I've had a bunch of failures due to
> timeouts waiting on a darwin-x86_64 runner.  I was a little mystified
> that no other pipelines besides mine seemed to be having this problem,
> but I've come to understand that MRs submitted from branches on the main
> project use a different, larger set of runners than the shared runners
> used by MRs from branches on forked projects.
>
> Under my project, I can view the available shared runners under the
> "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that
> there's only one darwin runner ("b4bc6410" /
> mac-mini-x86_64-darwin-davxkc).  This machine is a trooper, but it
> unfortunately shares a circuit breaker with a toaster oven, so it goes
> offline every time someone wants a bagel, and the rest of the time it
> must be running CI for a few hundred GHC forks.
>
> I ended up deleting an (unreviewed) MR sourced from my branch, and
> pushing it to the main project and resubmitting just to get the CI to
> run.  (Admittedly, it failed, but at least not on darwin!)  I obviously
> don't want to do this with the merge requests that have already been
> reviewed.
>
> Is this a temporary problem?  Is there anything I can do other than keep
> retrying the darwin jobs every couple days?
>
> Also, is there a better place than "ghc-dev" to send these sorts of
> GitLab/CI issues?  I thought there might be a project dedicated to it,
> but if so I couldn't find it.
>
>
> --
> Kevin Buhr 
>
> ___
> 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

CI on forked projects: Darwin woes

[Kevin Buhr]

Over the past few days, I've submitted several merge requests from 
branches on my forked project (mostly because I didn't even realize 
pushing to a branch on the main project was an alternative).


When those MRs run under CI, I've had a bunch of failures due to 
timeouts waiting on a darwin-x86_64 runner.  I was a little mystified 
that no other pipelines besides mine seemed to be having this problem, 
but I've come to understand that MRs submitted from branches on the main 
project use a different, larger set of runners than the shared runners 
used by MRs from branches on forked projects.


Under my project, I can view the available shared runners under the 
"Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that 
there's only one darwin runner ("b4bc6410" / 
mac-mini-x86_64-darwin-davxkc).  This machine is a trooper, but it 
unfortunately shares a circuit breaker with a toaster oven, so it goes 
offline every time someone wants a bagel, and the rest of the time it 
must be running CI for a few hundred GHC forks.


I ended up deleting an (unreviewed) MR sourced from my branch, and 
pushing it to the main project and resubmitting just to get the CI to 
run.  (Admittedly, it failed, but at least not on darwin!)  I obviously 
don't want to do this with the merge requests that have already been 
reviewed.


Is this a temporary problem?  Is there anything I can do other than keep 
retrying the darwin jobs every couple days?


Also, is there a better place than "ghc-dev" to send these sorts of 
GitLab/CI issues?  I thought there might be a project dedicated to it, 
but if so I couldn't find it.



--
Kevin Buhr 

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

Re: Is cleaning up old issues worthwhile?

[Jacques Carette]

In my time working on an old system, I found the statement "they are so 
old that if the bug still exists there is probably a newer ticket" to be 
false multiple times.  Large systems hide many obscure bugs, some of 
which are rarely encountered. And sometimes the oldest symptom is the 
clearest one. I have always found that more tests is best; so even when 
I closed old bugs as 'magically fixed' in Maple, I still created a 
regression test for it.


Jacques

On 2019-05-04 5:56 p.m., Matthew Pickering wrote:

I'm not sure the benefit of marking these tickets obsolete is. You may
as well just close them. Someone can reopen them if they disagree.

There could be some arguent for adding tests from these old tickets
but tbh they are so old that if the bug still exists there is probably
a newer ticket.

On Sat, May 4, 2019 at 10:31 PM Kevin Buhr  wrote:

Okay, I've added a new "obsolete" label:  "Old issues that no longer
apply and are in a short waiting period before closing."  I'll start
going through the low-hanging fruit adding comments and sticking this
label on them, with the idea of going back and closing them after, say,
4 weeks with no complaints.  After I've gone through a few of these and
gained some experience with it, I'll try to draft some guidelines for
handling old tickets.

Anyway, please let me know if this process starts to get irritating.

--
Kevin Buhr 

___
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

Old build system broken

[Simon Peyton Jones via ghc-devs]

I know we are supposed to be using Hadrian now, but is the old build system 
supposed to be broken?
A clean build fails with

"inplace/bin/ghc-cabal" check libraries/ghc-prim

"inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install 
--with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" 
--with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg"  
--disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci 
--disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall
 -Werror=unused-but-set-variable -Wno-error=inline" 
--configure-option=LDFLAGS="  " --configure-option=CPPFLAGS="   " 
--gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline   " 
--with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" 
--with-happy="/usr/bin/happy"

Configuring ghc-prim-0.6.1...

ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an

error:

Failed to read "target arch" value ""



libraries/ghc-prim/ghc.mk:4: recipe for target 
'libraries/ghc-prim/dist-install/package-data.mk' failed

make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1

Makefile:123: recipe for target 'all' failed

make: *** [all] Error 2

simonpj@MSRC-3645512:~/code/HEAD$
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MR titles

[Richard Eisenberg]

Might I also suggest that we put a very brief summary of the area of GHC that 
the MR fixes in the title? With the way that GitLab puts numbers at the end of 
subject lines, it's harder to recognize tickets by number now. By including a 
few keywords in the MR title, I can find ones of interest more easily.

Regardless, putting the ticket number in the title should be a higher priority.

Richard

> On May 8, 2019, at 4:51 AM, Simon Peyton Jones via ghc-devs 
>  wrote:
> 
> Friends
> 
> In this MR , Vlad 
> includes the number of the ticket it fixes in the title of the MR.
> 
> That is so helpful:
> 
> It links the MR back to the issue
> And does so in large font (screen shot below)
> And the link is clickable, even in the title.
> I suggest we document this in our GHC-best-practice guide, and get everyone 
> to do it.
> 
> Would you agree
> 
> Simon
> 
>  
> 
> 
> 
> ___
> 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: MR titles

[Simon Peyton Jones via ghc-devs]

This is part of our contributing guide at work

Do you have other advice from your contributing guide that we could learn from?

Simon

From: chessai . 
Sent: 08 May 2019 12:29
To: Simon Peyton Jones 
Cc: GHC developers 
Subject: Re: MR titles

I agree that this is the way to go. This is part of our contributing guide at 
work, for the reasons you mentioned. Additionally it helps avoid the need to 
read the MR's contents (comments/code) before going into it, since reading 
relevant tickets is almost always something you want to do.

Thanks
On Wed, May 8, 2019, 4:51 AM Simon Peyton Jones via ghc-devs 
mailto:ghc-devs@haskell.org>> wrote:
Friends
In this 
MR,
 Vlad includes the number of the ticket it fixes in the title of the MR.
That is so helpful:

  *   It links the MR back to the issue
  *   And does so in large font (screen shot below)
  *   And the link is clickable, even in the title.
I suggest we document this in our GHC-best-practice guide, and get everyone to 
do it.
Would you agree
Simon

[cid:image001.jpg@01D50583.988DEB70]
___
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: MR titles

[chessai .]

I agree that this is the way to go. This is part of our contributing guide
at work, for the reasons you mentioned. Additionally it helps avoid the
need to read the MR's contents (comments/code) before going into it, since
reading relevant tickets is almost always something you want to do.

Thanks

On Wed, May 8, 2019, 4:51 AM Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Friends
>
> In this MR , Vlad
> includes the number of the ticket it fixes *in the title of the MR.*
>
> That is so helpful:
>
>- It links the MR back to the issue
>- And does so in large font (screen shot below)
>- And the link is clickable, even in the title.
>
> I suggest we document this in our GHC-best-practice guide, and get
> everyone to do it.
>
> Would you agree
>
> Simon
>
>
>
> ___
> 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

Parser performance: 10% regression in 8.8

[Vladislav Zavialov]

Hello ghc-devs,

This February I did some changes to the parser that require higher rank types 
support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is 
severely broken in the presence of higher rank types, so I had to disable it. 
My benchmarks have shown a 10% slowdown from disabling --coerce 
(https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4 
).

Alongside my changes I submitted a pull request to happy which fixes the issue 
(https://github.com/simonmar/happy/pull/134 
), in the hope that it would get 
merged, released, and I could re-enable --coerce in GHC ‘happy' configuration.

Unfortunately, my patch has been ignored to this day (for 3 months now), and 
the performance regression reached 8.8-alpha. We need to act swiftly if we want 
to avoid a performance regression in the actual release. Here’s what needs to 
be done:

1. Merge https://github.com/simonmar/happy/pull/134 

2. Release a new ‘happy’
3. (Optional) Specify in GHC’s build system that it builds only with the latest 
'happy' release
4. Restore the --coerce option in GHC’s build system ‘happy’ configuration
5. Backport it to the ghc-8.8 branch

I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if 
someone took care of 3, currently the build system does not install ‘happy’ and 
assumes a system-wide installation without checking its version. This means 
that users of all but the newly released version will encounter obscure error 
messages. We need a version check. Then I will do 4, as planned, and create a 
merge request for 5.

All the best,
- Vladislav___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

MR titles

[Simon Peyton Jones via ghc-devs]

Friends
In this MR, Vlad 
includes the number of the ticket it fixes in the title of the MR.
That is so helpful:

  *   It links the MR back to the issue
  *   And does so in large font (screen shot below)
  *   And the link is clickable, even in the title.
I suggest we document this in our GHC-best-practice guide, and get everyone to 
do it.
Would you agree
Simon

[cid:image001.jpg@01D50583.988DEB70]
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs