Re: [ANNOUNCE] 7.10.3 release candidate 2

2015-11-08 Thread Ben Gamari
Ben Gamari  writes:

> Ben Gamari  writes:
>
>> Hello everyone,
>>
>> We are pleased to announce the second release candidate for GHC 7.10.3:
>>
>> https://downloads.haskell.org/~ghc/7.10.3-rc2/
>>
> It has been brought to my attention that the configure script in this
> source tarballs is out of date. Because of this `configure` will
> still fail on OS X. Reports suggest that there may be other issues
> unrelated to the configure issue on OS X as well.
>
Further testing suggests that perhaps the only issue is the out-of-date
`configure` script. Mac OS X users with `autotools` installed should be
able to run `./boot` in the source tree to bring `configure` up-to-date,
at which point this release candidate should be buildable.

I'll cut an -rc3 with a fixed `configure` script today.

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: [ANNOUNCE] 7.10.3 release candidate 2

2015-11-08 Thread Carter Schonwald
I'm having trouble setting the make file flags to make the Mac build use
the intree gmp.  I'm going to dig into this a bit more this evening.

On Sunday, November 8, 2015, Ben Gamari  wrote:

> Ben Gamari > writes:
>
> > Ben Gamari > writes:
> >
> >> Hello everyone,
> >>
> >> We are pleased to announce the second release candidate for GHC 7.10.3:
> >>
> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/
> >>
> > It has been brought to my attention that the configure script in this
> > source tarballs is out of date. Because of this `configure` will
> > still fail on OS X. Reports suggest that there may be other issues
> > unrelated to the configure issue on OS X as well.
> >
> Further testing suggests that perhaps the only issue is the out-of-date
> `configure` script. Mac OS X users with `autotools` installed should be
> able to run `./boot` in the source tree to bring `configure` up-to-date,
> at which point this release candidate should be buildable.
>
> I'll cut an -rc3 with a fixed `configure` script today.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Questions on the RTS C API regarding threads and tasks

2015-11-08 Thread Edward Z. Yang
Excerpts from Nicola Gigante's message of 2015-11-04 23:13:51 -0800:
> We don't have measurements, but we ruled out this possibility for
> performance reasons. Our idea is to make a thin Haskell wrapper 
> around a tiny bit of highly optimized C code. What's the performance
> of locking on MVars?

I still don't know what it is you're trying to do.  If you have a tiny
bit of optimized C code that runs quickly, then you should just make
an unsafe FFI call to it (as for as Haskell's runtime is concerned,
it's just a "fat instruction").

> While we are at it: are primops callable directly from C? I suppose
> calling conventions are different.

Anything is "callable" from C, but yes, you have to do the right
calling convention.  Primops are not easily callable from C.

> A question comes to mind: you mentioned "safe" calls. 
> Are unsafe calls different regarding the detaching of the capability?

An unsafe call does not detach the capability.

> Also: would a patch to make this possible be accepted?
> In particular:
> - add a way to make a "ultraunsafe" foreign call that do not loose the
>   ownership of the calling thread. 

I don't see what the difference between this and an unsafe foreign call
is.

> - add a BlockedOnExplicitSleep flag for tso->why_blocked
>   (And in turn this means managing a different blocking queue, right?)
> - export something to reliably put in sleep and resume threads
>   in this way.
> 
> Is this feasible? Would it be a good idea?

I still don't see why you can't just block the thread on an MVar
(removing it from the main run queues), and then when you want to
resume it write to the MVar.  It'll have an added bonus that you'll
automatically handle masking/async exceptions correctly.

If you find the MVar implementation is too slow, then maybe you
can think about making an optimized implementation which doesn't
use any synchronization / is inline in the TSO so no allocation
is necessary.  But in my opinion this is putting the cart before
the horse.

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


Re: [ANNOUNCE] 7.10.3 release candidate 2

2015-11-08 Thread George Colpitts
I get

make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
make[1]: *** Waiting for unfinished jobs
checking whether byte ordering is bigendian... no
checking assembler .cfi pseudo-op support... yes
checking for _ prefix in compiled symbols... yes
checking whether .eh_frame section should be read-only... expr: syntax error
no
checking for __attribute__((visibility("hidden")))... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating include/Makefile
config.status: creating include/ffi.h
config.status: creating Makefile
config.status: creating testsuite/Makefile
config.status: creating man/Makefile
config.status: creating libffi.pc
config.status: creating fficonfig.h
config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
config.status: executing buildir commands
config.status: create top_srcdir/Makefile guessed from local Makefile
config.status: build in x86_64-apple-darwin (HOST=)
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing include commands
config.status: executing src commands
# wc on OS X has spaces in its output, which libffi's Makefile
# doesn't expect, so we tweak it to sed them out
mv libffi/build/Makefile libffi/build/Makefile.orig
sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig >
libffi/build/Makefile
"touch" libffi/stamp.ffi.static-shared.configure
make: *** [all] Error 2

Is that the same error you are getting?


On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald  wrote:

> I'm having trouble setting the make file flags to make the Mac build use
> the intree gmp.  I'm going to dig into this a bit more this evening.
>
>
> On Sunday, November 8, 2015, Ben Gamari  wrote:
>
>> Ben Gamari  writes:
>>
>> > Ben Gamari  writes:
>> >
>> >> Hello everyone,
>> >>
>> >> We are pleased to announce the second release candidate for GHC 7.10.3:
>> >>
>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/
>> >>
>> > It has been brought to my attention that the configure script in this
>> > source tarballs is out of date. Because of this `configure` will
>> > still fail on OS X. Reports suggest that there may be other issues
>> > unrelated to the configure issue on OS X as well.
>> >
>> Further testing suggests that perhaps the only issue is the out-of-date
>> `configure` script. Mac OS X users with `autotools` installed should be
>> able to run `./boot` in the source tree to bring `configure` up-to-date,
>> at which point this release candidate should be buildable.
>>
>> I'll cut an -rc3 with a fixed `configure` script today.
>>
>> Cheers,
>>
>> - Ben
>>
>>
> ___
> 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: [ANNOUNCE] 7.10.3 release candidate 2

2015-11-08 Thread Carter Schonwald
nope, my error was a bad copy and paste :)

heres a link to my build (uses the GCC style rts build, which should be
more performant than the default clang one last i checked, also has html
docs and should work OS X >= 10.7)

https://www.wellposed.com.s3.amazonaws.com/opensource/ghc/releasebuild-unofficial/ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2

(http:// also works)


shasum -a512 ghc-7.10.2.20151105-x86_64-apple-darwin.tar.bz2
003a23929a17e9d01f52ef0a9388b6af51d409eda12627b20500c820f44da1e21976a46da7a50d040072cf5243a05d8f6a4344899fe3c2d8fb3f4f101ef29dce


for those who want to check the check the sha sum



On Sun, Nov 8, 2015 at 9:36 PM, George Colpitts 
wrote:

> I get
>
> make[1]: *** [libraries/integer-gmp2/gmp/gmp.h] Error 1
> make[1]: *** Waiting for unfinished jobs
> checking whether byte ordering is bigendian... no
> checking assembler .cfi pseudo-op support... yes
> checking for _ prefix in compiled symbols... yes
> checking whether .eh_frame section should be read-only... expr: syntax
> error
> no
> checking for __attribute__((visibility("hidden")))... no
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating include/Makefile
> config.status: creating include/ffi.h
> config.status: creating Makefile
> config.status: creating testsuite/Makefile
> config.status: creating man/Makefile
> config.status: creating libffi.pc
> config.status: creating fficonfig.h
> config.status: linking ../src/x86/ffitarget.h to include/ffitarget.h
> config.status: executing buildir commands
> config.status: create top_srcdir/Makefile guessed from local Makefile
> config.status: build in x86_64-apple-darwin (HOST=)
> config.status: executing depfiles commands
> config.status: executing libtool commands
> config.status: executing include commands
> config.status: executing src commands
> # wc on OS X has spaces in its output, which libffi's Makefile
> # doesn't expect, so we tweak it to sed them out
> mv libffi/build/Makefile libffi/build/Makefile.orig
> sed "s#wc -w#wc -w | sed 's/ //g'#" < libffi/build/Makefile.orig >
> libffi/build/Makefile
> "touch" libffi/stamp.ffi.static-shared.configure
> make: *** [all] Error 2
>
> Is that the same error you are getting?
>
>
> On Sun, Nov 8, 2015 at 9:34 PM, Carter Schonwald <
> carter.schonw...@gmail.com> wrote:
>
>> I'm having trouble setting the make file flags to make the Mac build use
>> the intree gmp.  I'm going to dig into this a bit more this evening.
>>
>>
>> On Sunday, November 8, 2015, Ben Gamari  wrote:
>>
>>> Ben Gamari  writes:
>>>
>>> > Ben Gamari  writes:
>>> >
>>> >> Hello everyone,
>>> >>
>>> >> We are pleased to announce the second release candidate for GHC
>>> 7.10.3:
>>> >>
>>> >> https://downloads.haskell.org/~ghc/7.10.3-rc2/
>>> >>
>>> > It has been brought to my attention that the configure script in this
>>> > source tarballs is out of date. Because of this `configure` will
>>> > still fail on OS X. Reports suggest that there may be other issues
>>> > unrelated to the configure issue on OS X as well.
>>> >
>>> Further testing suggests that perhaps the only issue is the out-of-date
>>> `configure` script. Mac OS X users with `autotools` installed should be
>>> able to run `./boot` in the source tree to bring `configure` up-to-date,
>>> at which point this release candidate should be buildable.
>>>
>>> I'll cut an -rc3 with a fixed `configure` script today.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>> ___
>> 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: [ANNOUNCE] 7.10.3 release candidate 2

2015-11-08 Thread Jens Petersen
I haven't looked but I note for the record that the size of the tar.xz
is increasing:

10547868 Mar 30  2015 ghc-7.10.1-src.tar.xz
3204 Jul 31 15:50 ghc-7.10.2-src.tar.xz
13270576 Nov  9 13:12 ghc-7.10.2.20151105-src.tar.xz

Jens

On 8 November 2015 at 07:28, Ben Gamari  wrote:
> We are pleased to announce the second release candidate for GHC 7.10.3:

Thanks!  I am building it now in Fedora Copr:
https://copr.fedoraproject.org/coprs/petersen/ghc-7.10.3/build/138255/

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