Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Carter Schonwald]

i'm seeing that problem on my mac too. the RC is busted for mac :(,
unbuildable even

On Wed, Nov 4, 2015 at 11:35 AM, Peter Trommler  wrote:

> Sent from the wrong account the first time around.
>
> > On 04.11.2015, at 17:18, Richard Eisenberg  wrote:
> >
> >
> > On Nov 4, 2015, at 11:12 AM, Peter Trommler <
> peter.tromm...@th-nuernberg.de> wrote:
> >
> >> It looks like a bug to me.
> >
> > I'm taking your "it" here to mean the fact that GHC is looking for
> readelf on a Mac OS platform.
> Yes. That's correct.
>
> Peter
>
>
> ___
> 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: Questions on the RTS C API regarding threads and tasks

[Edward Z. Yang]

Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800:
> I’ve started delving into the ghc runtime API to understand
> if everything we need is exposed to the world or if we
> have to modify the runtime itself (which I would avoid if possible).

I agree with this goal in principle, but:

(1) Depending on what you want to do, it may be quite difficult to
do this, and

(2) The RTS is actually quite hackable (as long as you are not
changing any of the interfaces with generated Haskell code, you
could even build your own RTS and have users link against that.)

Something to keep in mind.

> I have a few questions about the functions that the runtime
> exports to the C world regarding the manipulation of tasks:
> 
> - Fundamentally, is there a way for a C function called by a foreign call
>   to suspend the haskell thread that called it, to be resumed later
>   when appropriate? I see that the runtime has a concept of
>   “blocking queue”, but I also see that the functions that work on
>   blocking queues are not exported. I can manage a queue of TSOs myself,
>   but then I need a way to put in sleep the task indefinitely up to a wake 
> signal.
>   In other words, can I sleep and awake haskell threads from a C function
>   called by a foreign call?

Not easily.  If you make a safe foreign call, the capability is given up
before the C code executes, so you actually lose ownership of the
capability and TSO by the time you're running C code.  The only
way to write a foreign call to properly suspend the thread that called
it is a primop function (e.g. stg_putMVar), and the operation is quite
delicate and you will probably want to use some existing (internal)
code in the RTS to do it.

But if you just need to sleep/awake threads, why not just use an MVar?

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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Peter Trommler]

I created #11061.

Peter
> On 05.11.2015, at 01:41, Carter Schonwald  wrote:
> 
> i'm seeing that problem on my mac too. the RC is busted for mac :(, 
> unbuildable even 
> 
> On Wed, Nov 4, 2015 at 11:35 AM, Peter Trommler  wrote:
> Sent from the wrong account the first time around.
> 
>> On 04.11.2015, at 17:18, Richard Eisenberg  wrote:
>> 
>> 
>> On Nov 4, 2015, at 11:12 AM, Peter Trommler  
>> wrote:
>> 
>>> It looks like a bug to me.
>> 
>> I'm taking your "it" here to mean the fact that GHC is looking for readelf 
>> on a Mac OS platform.
> Yes. That's correct.

___
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

[Nicola Gigante]

Il giorno 05 nov 2015, alle ore 05:27, Edward Z. Yang  ha 
scritto:
> 
> Excerpts from Nicola Gigante's message of 2015-11-04 11:12:39 -0800:
>> I’ve started delving into the ghc runtime API to understand
>> if everything we need is exposed to the world or if we
>> have to modify the runtime itself (which I would avoid if possible).
> 
> I agree with this goal in principle, but:
> 
>(1) Depending on what you want to do, it may be quite difficult to
>do this, and
> 
>(2) The RTS is actually quite hackable (as long as you are not
>changing any of the interfaces with generated Haskell code, you
>could even build your own RTS and have users link against that.)
> 
> Something to keep in mind.
> 

Edward, thanks for the quick reply!

Yes, I see that the source code is clear and well documented! :)
However, this project is something we would eventually want to publish
on hackage, not something of internal use. This means we'd have to
contribute the runtime changes upstream, which would be cool but
I assumed GHC as a project doesn't accept every experimental new feature
that come across, and we don't have the energy to guarantee maintenance 
of this eventual contribution. An external solution would be better.
> 
> Not easily.  If you make a safe foreign call, the capability is given up
> before the C code executes, so you actually lose ownership of the
> capability and TSO by the time you're running C code.  The only
> way to write a foreign call to properly suspend the thread that called
> it is a primop function (e.g. stg_putMVar), and the operation is quite
> delicate and you will probably want to use some existing (internal)
> code in the RTS to do it.
> 
> But if you just need to sleep/awake threads, why not just use an MVar?

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?

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

A question comes to mind: you mentioned "safe" calls. 
Are unsafe calls different regarding the detaching of 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. 
- 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?

> 
> Edward

Thank you again,
Greetings,
Nicola
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Questions on the RTS C API regarding threads and tasks

[Nicola Gigante]

Hi everybody,

I’m new on this list, congratulations to everyone for
the great work that you’re doing on GHC!

I apologize if this is not the right list where to ask the following
questions. Please point me to the correct list or IRC channel 
otherwise.

I’m part of a small group of people who is going to work
on a project that seems to need low-level handling of haskell 
threads.

I’ve started delving into the ghc runtime API to understand
if everything we need is exposed to the world or if we
have to modify the runtime itself (which I would avoid if possible).

I have a few questions about the functions that the runtime
exports to the C world regarding the manipulation of tasks:

- Fundamentally, is there a way for a C function called by a foreign call
  to suspend the haskell thread that called it, to be resumed later
  when appropriate? I see that the runtime has a concept of
  “blocking queue”, but I also see that the functions that work on
  blocking queues are not exported. I can manage a queue of TSOs myself,
  but then I need a way to put in sleep the task indefinitely up to a wake 
signal.
  In other words, can I sleep and awake haskell threads from a C function
  called by a foreign call?

- I see the “suspendThread” and “resumeThread” functions exist in 
include/rts/Threads.h
  Are these the functions that I need for the point above? My main concern is
  that the comments in the source code for suspendThread say that these
  functions are used in case of a CCall, and put the thread in a specific queue,
  so they seems to have more specific role than what the name might suggest.

- Also, I’m unable to find what a StgRegTable is 
  (which is taken as argument by suspendThread).


Thank you in advance for your help,

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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Richard Eisenberg]

On Nov 4, 2015, at 11:12 AM, Peter Trommler  
wrote:

> It looks like a bug to me.

I'm taking your "it" here to mean the fact that GHC is looking for readelf on a 
Mac OS platform. I tend to agree -- I was surprised to see this, but I'm 
almost-totally clueless about these things.

Thanks for the info,
Richard

PS: There's been much muttering about call stacks and DWARF. I haven't a clue 
what DWARF is, but I always assumed that this nice feature would not be 
available on Macs. What I realized today is that this assumption likely stems 
from the fact that ELF is not for Mac. ELFs and DWARFs tend to be found near 
one another in other settings, but perhaps this fact doesn't carry over to 
computer architectures. :)

> 
> Cheers,
> 
> Peter 
> 
>> On 04.11.2015, at 16:46, Richard Eisenberg  wrote:
>> 
>> I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this:
>> 
>>> checking for readelf... no
>>> configure: error: cannot find readelf in your PATH
>> 
>> A (very) quick search has turned up no help. I'm worried that my problem is 
>> that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track 
>> of all the animals... and now mountains.) I *really* don't want to upgrade, 
>> as I tried 10.9 once and it brought my system to its knees... had to 
>> reformat to downgrade back to 10.8.
>> 
>> Help?
>> 
>> Thanks!
>> Richard
>> 
> 
> 
> 
> --
> Prof. Dr. Peter Trommleremail: peter.tromm...@th-nuernberg.de
> Technische Hochschule Nuernberg phone: +49-911-58 80-16 63
> Faculty of Computer Science fax:   +49-911-58 80-56 66
> Postfach 31 03 20, 90121 Nuernberg  office: Hohfederstrasse 40, 90489 
> Nuernberg
> 
> 

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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Peter Trommler]

Sent from the wrong account the first time around.

> On 04.11.2015, at 17:18, Richard Eisenberg  wrote:
> 
> 
> On Nov 4, 2015, at 11:12 AM, Peter Trommler  
> wrote:
> 
>> It looks like a bug to me.
> 
> I'm taking your "it" here to mean the fact that GHC is looking for readelf on 
> a Mac OS platform.
Yes. That's correct.

Peter


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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Richard Eisenberg]

I can't build 7.10.3 RC1 because I don't have readelf. ./configure says this:

> checking for readelf... no
> configure: error: cannot find readelf in your PATH

A (very) quick search has turned up no help. I'm worried that my problem is 
that I'm still running Mac OS 10.8.5 (Snow Leopard? I never could keep track of 
all the animals... and now mountains.) I *really* don't want to upgrade, as I 
tried 10.9 once and it brought my system to its knees... had to reformat to 
downgrade back to 10.8.

Help?

Thanks!
Richard

On Nov 4, 2015, at 5:53 AM, Oleg Grenrus  wrote:

> Travis has whitelisted hvr/ppa ghc-7.10.3 package. Please update your
> travis build matrices!
> 
> Let’s make travis do its job!
> 
> Cheers,
> Oleg
> 
>> On 02 Nov 2015, at 18:03, Ben Gamari  wrote:
>> 
>> 
>> We are pleased to announce the first (and hopefully only) release
>> candidate for GHC 7.10.3:
>> 
>>   https://downloads.haskell.org/~ghc/7.10.3-rc1/
>> 
>> This includes the source tarball and bindists for 64-bit and 32-bit
>> modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs
>> have an accompanying SHA256SUMS file signed by my GPG key id
>> (0x97DB64AD). As always, our content delivery network tends to be a bit
>> slow on the uptake. If you see an empty directory at this URL just add a
>> few superfluous slashes to the end; this is typically enough to fool it.
>> 
>> The 7.10.2 release was well-behaved save a couple notable bugs; while we
>> have merged a good number of bug fixes in 7.10.3 they were were
>> largely low risk and so we expect that this release should be
>> similiarly stable.
>> 
>> The one exception to this is an upgrade of the Windows compiler
>> toolchain to GCC 5.2. Windows users have been long suffering at the hand
>> of our old toolchain (e.g. lack of response file support, #8596, and
>> lack of SEH support) so we expect that this change should fix far more
>> than breaks.
>> 
>> We plan to make the 7.10.3 release sometime next week.
>> 
>> Please test this as much as possible; bugs are much cheaper if we find
>> them before the release and this will ideally be the last release of the
>> 7.10 series.
>> 
>> Happy testing,
>> 
>> - 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

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

Re: [ANNOUNCE] GHC 7.10.3 release candidate 1

[Oleg Grenrus]

Travis has whitelisted hvr/ppa ghc-7.10.3 package. Please update your
travis build matrices!

Let’s make travis do its job!

Cheers,
Oleg

> On 02 Nov 2015, at 18:03, Ben Gamari  wrote:
> 
> 
> We are pleased to announce the first (and hopefully only) release
> candidate for GHC 7.10.3:
> 
>https://downloads.haskell.org/~ghc/7.10.3-rc1/
> 
> This includes the source tarball and bindists for 64-bit and 32-bit
> modern Linux (GMP 5.0 or later) and Windows. These binaries and tarballs
> have an accompanying SHA256SUMS file signed by my GPG key id
> (0x97DB64AD). As always, our content delivery network tends to be a bit
> slow on the uptake. If you see an empty directory at this URL just add a
> few superfluous slashes to the end; this is typically enough to fool it.
> 
> The 7.10.2 release was well-behaved save a couple notable bugs; while we
> have merged a good number of bug fixes in 7.10.3 they were were
> largely low risk and so we expect that this release should be
> similiarly stable.
> 
> The one exception to this is an upgrade of the Windows compiler
> toolchain to GCC 5.2. Windows users have been long suffering at the hand
> of our old toolchain (e.g. lack of response file support, #8596, and
> lack of SEH support) so we expect that this change should fix far more
> than breaks.
> 
> We plan to make the 7.10.3 release sometime next week.
> 
> Please test this as much as possible; bugs are much cheaper if we find
> them before the release and this will ideally be the last release of the
> 7.10 series.
> 
> Happy testing,
> 
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs