RE: Specialization plugin

I’d really like to know why INLINABLE pragmas don’t work. Perhaps an example? Only the type checker currently can conjure up dictionaries. It would presumably not be impossible to do so later, but it’d be quite a new thing, involving invoking the constraint solver. The pattern-match overlap

RE: Dynamic Linking help

> > > > 2) The other problem is that the paths specified have to be relative to the > > application. > >(Of the top of my head) It doesn't support absolute paths. Which > >means I can't have GHC generate the entry because I have no idea > >where the testsuite intends to run

RE: Dynamic Linking help

loneti...@gmail.com writes: > Hi Ben, > > Thanks for the reply! > Sure. >> > Hi *, >> > >> > I’ve been working the past 4 or so months on reviving dynamic linking >> > support for Windows in a way that has the most chance of working. >> > >> > My first patch in the series is up on Phabricator

RE: Linker reorganization

> Simon Marlow writes: > > >> One concern that I have is that the RTS's header file structure (where > >> everything is #include'd via Rts.h) doesn't work very well for this > >> particular use, where we have a group of headers specific to a > >> particular subsystem (e.g.

RE: Dynamic Linking help

Hi Ben, Thanks for the reply! > > > Hi *, > > > > I’ve been working the past 4 or so months on reviving dynamic linking > > support for Windows in a way that has the most chance of working. > > > > My first patch in the series is up on Phabricator and with this patch > > dynamic linking work

Re: simple pictures about GHC development flow

Joachim Breitner writes: > Hi, > > Am Freitag, den 28.10.2016, 21:19 +0900 schrieb Takenobu Tani: >> For myself and new contributors, I drew overview pictures about GHC >> development flow. >> >>   GHC development flow >>    

Re: simple pictures about GHC development flow

Hi Ben, Joachim, Thank you for your checking and reply! After I'll be carefully considered, and then reply. I'll reflect your feedback. Please wait for a little while. Thank you very much :) , Takenobu 2016-10-28 22:01 GMT+09:00 Ben Gamari : > Takenobu Tani

Re: simple pictures about GHC development flow

Hi, Am Freitag, den 28.10.2016, 21:19 +0900 schrieb Takenobu Tani: > For myself and new contributors, I drew overview pictures about GHC > development flow. > >   GHC development flow >     http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf >    

Re: setnumcapabilities001 failure

I see, but the compiler has no business caching things across requestSync(), which can in principle change anything: even if the compiler could see all the code, it would find a pthread_condwait() in there. Anyway I've found the problem - it was caused by a subsequent GC overwriting the values of

Re: Linker reorganization

Simon Marlow writes: >> One concern that I have is that the RTS's header file structure (where >> everything is #include'd via Rts.h) doesn't work very well for this >> particular use, where we have a group of headers specific to a >> particular subsystem (e.g. linker/*.h).

Re: setnumcapabilities001 failure

Right, it is compiler effects at this boundary that I'm worried about, values that are not read from memory after the changes have been made, not memory effects or data races. On Fri, Oct 28, 2016 at 3:02 AM, Simon Marlow wrote: > Hi Ryan, I don't think that's the issue.

Re: setnumcapabilities001 failure

Hi Ryan, I don't think that's the issue. Those variables can only be modified in setNumCapabilities, which acquires *all* the capabilities before it makes any changes. There should be no other threads running RTS code(*) while we change the number of capabilities. In particular we shouldn't be

Re: Linker reorganization

On 28 October 2016 at 02:33, Ben Gamari wrote: > Hello RTS people, > > Today I finally grew frustrated enough with my constant battle with the > 7000 line tangle of CPP that is rts/Linker.c to do something about it. > The result is D2643 through D2650. In short, I took the