- ghc-devs - Haskell.org

11 Sep '13

1 0

RE: [core libraries] RE: Alex and new Bool primops
by Simon Peyton-Jones 11 Sep '13

11 Sep '13

(Simon M: are you ok with updating Alex? You were the one of those who argued strongly for using the old names for the new primops.) The difficulty is this. · Alex generates Haskell code, by transforming Foo.x into Foo.hs · The generated Foo.hs contains references to comparison primops, say (>#) :: Int# -> Int# -> Bool · Therefore Foo.hs will not work with GHC 7.8 if we have changed the type of (>#), which is what I think we have agreed to do. · The solution is to make Alex generates a Foo.hs that is compilable either with GHC 7.8 or 7.6, by including enough CPP directives. Alex already does this for compatibility with earlier GHCs · However, until there is a new version of Alex, you simply won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD). That’s all there is to it. It’s tiresome and trivial in a sense, but it’s a choice we have to make. It might be perfectly reasonable to say · You can’t build GHC 7.8 from source with the Haskell Platform until a new HP comes out with the new Alex (which will be soon). · Unless you install the new Alex manually This seems not too bad; people who build GHC from source are generally pretty savvy. The choice between the two is what we seek your guidance on. (Incidentally, a very similar situation has arisen for Happy: see http://ghc.haskell.org/trac/ghc/ticket/8022. But there the cost of perpetuating the status quo for another release cycle seems minimal.) Simon From: michael.snoyman(a)gmail.com [mailto:michael.snoyman@gmail.com] On Behalf Of Michael Snoyman Sent: 10 September 2013 05:28 To: Simon Peyton-Jones Cc: core-libraries-committee(a)haskell.org; ghc-devs; Geoffrey Mainland; Jan Stolarek Subject: Re: [core libraries] RE: Alex and new Bool primops I'll admit a fair amount of ignorance of the GHC build process. But wouldn't it be standard that any tool used in the GHC build process itself, and built by GHC itself, would need to have some conditional compilation in place to handle API changes? It seems like the questions here are whether we should ever allow breaking changes in the API, and in this case whether the changes are coming too late in the development cycle. It seems like we've agreed on the first count that it's beneficial to allow breaking API changes. It could be that in this case we're too late in the dev cycle. In this case, it sounds like including the compatibility module in Alex would be most expedient, but I'd defer to those who understand the process better than me. On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Dear Core Libraries Committee I think we need your advice. This thread (mostly on ghc-devs) shows that if the shim-package and boolean-primop decision goes as currently proposed, then we'll need a new release of Alex * Either to generate an import of GHC.Exts.Compat (ie depend on the shim package) * Or to make its own local tiny shim module for the primops it uses * Or maybe some other plan (Alex already has quite a bit of stuff designed to make it generate code that will be compilable with a variety of GHCs.) Moreover this new release of Alex will be necessary simply in order to allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current HP could not be used to build GHC. How would you like us to proceed? Thanks! Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org<mailto:ghc-devs-bounces@haskell.org>] On Behalf Of | Geoffrey Mainland | Sent: 09 September 2013 16:14 | To: Jan Stolarek | Cc: ghc-devs | Subject: Re: Alex and new Bool primops | | I say this only somewhat facetiously, but this is *exactly* the sort of | problem that the pro-backwards compatibility camp anticipates, and I | mean the "pro-backwards compatibility camp" in the most general possible | way :) The point is that you can never anticipate all the ways in which | breaking backwards compatibility breaks things. How much "technical | debt" is really accrued with backwards compatible primops? What is | preventing us from doing the so-called "Right Thing" *after* the 7.8 | release? | | Anyway, the one solution I can think of off the top of my head is to | patch Alex's templates to use an #ifdef to pick primops based on the | version of GHC being used for compilation. That will need to be done | anyway. | | As an aside, I think any discussion that involves making decisions that | effect the community as a whole should have a public mail archive. | | Geoff | | On 09/09/2013 11:02 AM, Jan Stolarek wrote: | > I think the there was a general agreement in the committee that we | should follow the best long-term solution, not the best short-term one. | Here are two arguments (Plan B = break backwards compatibility): | > | > > I'd rather not hamstring GHC.* with a rats nest of backwards | compatibility decisions, | > > which all come at accreted costs, the mortgage for which is to be | paid down forever | > > by future development efforts. | > | > > I vote for plan B on the grounds that it's the Right Thing and the | > > group that it breaks is both small and savvy. | > | > > [implementing backwards compatibility solution] only works once, | though. We're in exactly the same boat on all future primop redesigns. | > | > There was also a decision of providing a backwards compatibility | package that would make it easy for library authors to create packages | that are compatible both with 7.6 and 7.8 (summarized here: | http://www.haskell.org/haskellwiki/Compatibility_Modules) Sadly, | there's no web archive for that list so I can't point you to the | discussion. | > | > Anyway, this is clearly something no one has anticipated and the | question is whether we have a good way to solve that problem? | > | > Janek | > | > ----- Oryginalna wiadomość ----- | > Od: "Geoffrey Mainland" <mainland(a)apeiron.net<mailto:mainland@apeiron.net>> | > Do: "Jan Stolarek" <jan.stolarek(a)p.lodz.pl<mailto:jan.stolarek@p.lodz.pl>> | > DW: "ghc-devs" <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> | > Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09 | > Temat: Re: Alex and new Bool primops | > | > Perhaps the core libraries committee should reconsider their decision? | > :) Backwards compatibility is good. If HEAD implements the backwards | > compatibility plan that Simon PJ and I suggested and said plan is | > working, there should be a compelling reason to break compatibility | and | > have to go chasing down all the follow-on breakage (in, e.g., Alex) so | > close to release. | > | > What was the committee's reasoning? | > | > Geoff | > | > On 09/09/2013 10:08 AM, Jan Stolarek wrote: | >> I am refactoring new Bool primops (#6135). There was a discussion on | core-libraries-commitee list and the decision was made that we should | keep names of primops we used so far and change their type signature | (right now HEAD has different names for new primops and reuses old names | for compatibility wrappers). I've changed names of the primops and | removed the wrappers but I can't bootstrap GHC because old primops are | hardwired into Alex. I get this build error when attempting to build | stage 2 compiler: | >> | >> compiler/stage2/build/Lexer.hs:2348:34: | >> Couldn't match expected type 'Bool' with actual type 'Int#' | >> In the first argument of '(&&)', namely '(offset >=# 0#)' | >> In the expression: (offset >=# 0#) && (check ==# ord_c) | >> In the expression: | >> if (offset >=# 0#) && (check ==# ord_c) then | >> alexIndexInt16OffAddr alex_table offset | >> else | >> alexIndexInt16OffAddr alex_deflt s | >> | >> compiler/stage2/build/Lexer.hs:2348:53: | >> Couldn't match expected type 'Bool' with actual type 'Int#' | >> In the second argument of '(&&)', namely '(check ==# ord_c)' | >> In the expression: (offset >=# 0#) && (check ==# ord_c) | >> In the expression: | >> if (offset >=# 0#) && (check ==# ord_c) then | >> alexIndexInt16OffAddr alex_table offset | >> else | >> alexIndexInt16OffAddr alex_deflt s | >> | >> And indeed, looking at Lexer.hs I see: | >> | >> alex_scan_tkn user orig_input len input s last_acc = | >> (...) -- some irrelevant code here | >> (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) | >> then alexIndexInt16OffAddr alex_table | offset | >> else alexIndexInt16OffAddr alex_deflt s | >> | >> So to compile GHC, Alex would need to generate different code for GHC | 7.6.3 and below, and different for GHC 7.7 and above (or alternatively | it could generate #if pragmas), but this means we'd need to update Alex. | I created compatibility module within GHC called ExtsCompat46 and tried | adding it to list of imported modules, but in generated Lexer.hs Alex | adds a bunch of other modules among which is GHC.Exts, which conflicts | with import of ExtsCompat46: | >> | >> compiler/stage1/build/Lexer.hs:2349:41: | >> Ambiguous occurrence `>=#' | >> It could refer to either `ExtsCompat46.>=#', | >> imported from `ExtsCompat46' at | compiler/parser/Lexer.x:79:1-19 | >> or `GHC.Exts.>=#', | >> imported from `GHC.Exts' at | compiler/stage1/build/Lexer.hs:75:1-15 | >> (and originally defined in `ghc- | prim:GHC.Prim') | >> | >> Again, we would need updated version of Alex to generate correct code | (also, this would break in the future after removing that compatibility | module). I don't see a way out of this. Help? | >> | >> Janek | >> | >> _______________________________________________ | >> ghc-devs mailing list | >> ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> | >> http://www.haskell.org/mailman/listinfo/ghc-devs | > | | | _______________________________________________ | ghc-devs mailing list | ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> | http://www.haskell.org/mailman/listinfo/ghc-devs -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com<mailto:haskell-core-libraries%2Bunsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/groups/opt_out.

5 4

RE: GHC 7.8 release status
by Simon Peyton-Jones 11 Sep '13

11 Sep '13

I do need more than a patch, please, please. A wiki page explaining the design, as seen by the user (of the GHC API), the problems it solves, and the use-cases it enables, would be most helpful. Simon | -----Original Message----- | From: Thomas Schilling [mailto:nominolo@googlemail.com] | Sent: 04 September 2013 17:26 | To: Simon Peyton-Jones; Luite Stegeman | Cc: Nicolas Frisby; "Pedro Magalhães (dreixel(a)gmail.com)"; Richard | Eisenberg (eir(a)cis.upenn.edu) Geoffrey Mainland | (mainland(a)cs.drexel.edu) Iavor Diatchki; Austin Seipp; Edsko de Vries; | Ryan Newton (rrnewton(a)gmail.com) David Luposchainsky; ghc- | devs(a)haskell.org | Subject: Re: GHC 7.8 release status | | | On 4 Sep 2013, at 15:52, Simon Peyton-Jones <simonpj(a)microsoft.com> | wrote: | | > Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be | jolly soon. At the moment I don't even know the motivation or design, | let alone implementation. Could you make a wiki page explaining the | proposed design? Is it really important to do this for 7.8? | | Yes, it is quite important to get this into 7.8. Not having these | features in GHC makes it very difficult for people to adopt GHCJS. One | could argue that GHCJS is not yet production-ready anyway and users that | want to try it can figure out building GHC from source to use it, but | this doesn't quite apply. | | 1. GHCJS targets a wider audience than users brave enough to compile | GHC from source. In addition, the next chance to get these features into | GHC is in a year from now, so when GHCJS becomes more mature then this | will be a major hurdle for adoption. | | 2. These changes are also required for IDE tools which really mustn't | require users to build a custom version of GHC. | | | Luite's design is actually very flexible. It simply allows GHC API | users to provide functions that are called instead of (or in addition | to) existing functions in GHC. Instead of calling, say, "genHardCode", | the driver now looks up whether the user has specified a hook for | genHardCode and calls that instead. | | Currently we only specify a small number of hooks that are sufficient | for our use cases. Future releases of GHC can be extended to include | more hooks, if that is needed. | | Hooks are stored as an untyped map inside the DynFlags (to avoid issues | with circular dependencies). Each hook is looked up using a single- | constructor type and type families are used to make this type safe. | There is one use of unsafeCoerce to avoid having to make every hook | function an instance of Typeable. | | Unlike CorePlugins, it is only a GHC API feature, and users cannot | specify plugins to be added via command line options. If we can come up | with a good design, then we could add this in GHC 7.10, but it is not | necessary at this point. | | Luite: Do you have a link to your latest patch?

6 12

extending GHC plugins with Hooks
by Luite Stegeman 11 Sep '13

11 Sep '13

hi all, Sorry for taking so long to get back with this. I'm proposing a somewhat general way for adding 'hooks' to the GHC API, where users can override parts of the default compiling pipeline. Hooks are simply functions or actions that replace existing compiler functionality. This means that usually only one application can use a specific hook at a time. The obvious data structure to store the hooks is DynFlags. Unfortunately defining hooks in DynFlags directly would give birth to the mother of all import cycles, and it would also break the split-dll scheme on Windows. So here's the idea: - Define each hook in the module where it's exported - For each hook make a 'phantom' DataType and an instance for the Hook type familiy - Add a TypeRep based map in DynFlags [0] - For each hooked function, check for existence of a hook in DynFlags, otherwise run the default. Example: https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… Now this approach does have some disadvantages: - No clear integration with existing plugins (I've tried adding an onLoadPlugin field to Plugin, where the Plugin could update DynFlags when it's loaded, but it was a bit messy, and plugins would not be loaded in time for some hooks, particularly what Edsko needs) - More of GHC depends on type families - Decentralized hooks definitions feel a bit messy So I'm open to suggestions for improvements (or replacements) of this scheme. I have some time the coming weeks to clean up or change the patch. We've been testing some hooks with GHCJS for a while, and so far they seem to provide what we need (but I'm going to doublecheck the coming weeks that we don't have missing functionality): - Customizations for linking JavaScript code with our own library locations [1] - Hooking into the DriverPipeline so we can use the compilation manager [2] - Desugaring customizations to remove some C-isms from the FFI code [3] - Typechecking foreign import javascript imports [4] - Override the built-in GHC.Prim so we can customize primop types [5] I think it's easy to add those for Edsko and Thomas as well. luite [0] https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [1] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L44 [2] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L192 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [3] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L67 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [4] https://github.com/ghcjs/ghcjs/blob/master/src/Gen2/Foreign.hs#L68 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… [5] https://github.com/ghcjs/ghcjs/blob/master/src/Compiler/GhcjsHooks.hs#L191 https://github.com/ghcjs/ghcjs-build/blob/master/refs/patches/ghc-ghcjs.pat… (sorry the linked patch also contains other modifications required for GHCJS, that i'm going to submit separately)

6 9

Re: [core libraries] RE: Alex and new Bool primops
by Jan Stolarek 11 Sep '13

11 Sep '13

Also got email error for my last message, so I'm reposting it below with some more information. From a technical point of view changes to Alex and Happy are simple and already implemented on my branch: https://github.com/jstolarek/alex/commit/32d4244894ae2702d965415483d0479d91… https://github.com/jstolarek/happy/commit/430ebe1f82744818cc488cd45fee0effa… I say we bite the bullet - this moment is as good as any other. There is one important thing to point out. After updating Alex and Happy you will need to update HEAD and rebase your older branches on top of HEAD containing new primops. Again, this is unavoidable no matter when we decide to make the change. Given that my changes affect 7 libraries (and only one of them is a submodule) you would need to rebase anyway. Janek ----- Oryginalna wiadomość ----- Od: "Michael Snoyman" <michael(a)snoyman.com> Do: "Simon Peyton-Jones" <simonpj(a)microsoft.com> DW: core-libraries-committee(a)haskell.org, "ghc-devs" <ghc-devs(a)haskell.org>, "Geoffrey Mainland" <mainland(a)apeiron.net>, "Jan Stolarek" <jan.stolarek(a)p.lodz.pl>, "Simon Marlow" <marlowsd(a)gmail.com> Wysłane: środa, 11 wrzesień 2013 5:04:24 Temat: Re: [core libraries] RE: Alex and new Bool primops I got a mail delivery error on this, so I'm going to resend. Apologies to those who get this twice. On Tue, Sep 10, 2013 at 6:37 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > Having a requirement to manually install a newer Alex doesn't seem too > onerous to me. That would be my recommendation. > > > On Tue, Sep 10, 2013 at 11:53 AM, Simon Peyton-Jones < > simonpj(a)microsoft.com> wrote: > >> (Simon M: are you ok with updating Alex? You were the one of those who >> argued strongly for using the old names for the new primops.)**** >> >> ** ** >> >> The difficulty is this. **** >> >> **· **Alex generates Haskell code, by transforming Foo.x into >> Foo.hs**** >> >> **· **The generated Foo.hs contains references to comparison >> primops, say (>#) :: Int# -> Int# -> Bool**** >> >> **· **Therefore Foo.hs will not work with GHC 7.8 if we have >> changed the type of (>#), which is what I think we have agreed to do.**** >> >> **· **The solution is to make Alex generates a Foo.hs that is >> compilable either with GHC 7.8 or 7.6, by including enough CPP directives. >> Alex already does this for compatibility with earlier GHCs**** >> >> **· **However, until there is a new version of Alex, you simply >> won’t be able to bootstrap GHC 7.8 (or indeed the current HEAD).**** >> >> ** ** >> >> That’s all there is to it. It’s tiresome and trivial in a sense, but >> it’s a choice we have to make.**** >> >> ** ** >> >> It might be perfectly reasonable to say **** >> >> **· **You can’t build GHC 7.8 from source with the Haskell >> Platform until a new HP comes out with the new Alex (which will be soon). >> **** >> >> **· **Unless you install the new Alex manually**** >> >> ** ** >> >> This seems not too bad; people who build GHC from source are generally >> pretty savvy. The choice between the two is what we seek your guidance on. >> **** >> >> ** ** >> >> (Incidentally, a very similar situation has arisen for Happy: see >> http://ghc.haskell.org/trac/ghc/ticket/8022. But there the cost of >> perpetuating the status quo for another release cycle seems minimal.)**** >> >> ** ** >> >> Simon**** >> >> ** ** >> >> *From:* michael.snoyman(a)gmail.com [mailto:michael.snoyman@gmail.com] *On >> Behalf Of *Michael Snoyman >> *Sent:* 10 September 2013 05:28 >> *To:* Simon Peyton-Jones >> *Cc:* core-libraries-committee(a)haskell.org; ghc-devs; Geoffrey Mainland; >> Jan Stolarek >> *Subject:* Re: [core libraries] RE: Alex and new Bool primops**** >> >> ** ** >> >> I'll admit a fair amount of ignorance of the GHC build process. But >> wouldn't it be standard that any tool used in the GHC build process itself, >> and built by GHC itself, would need to have some conditional compilation in >> place to handle API changes? It seems like the questions here are whether >> we should ever allow breaking changes in the API, and in this case whether >> the changes are coming too late in the development cycle. It seems like >> we've agreed on the first count that it's beneficial to allow breaking API >> changes. It could be that in this case we're too late in the dev cycle.** >> ** >> >> ** ** >> >> In this case, it sounds like including the compatibility module in Alex >> would be most expedient, but I'd defer to those who understand the process >> better than me.**** >> >> ** ** >> >> On Mon, Sep 9, 2013 at 5:38 PM, Simon Peyton-Jones <simonpj(a)microsoft.com> >> wrote:**** >> >> Dear Core Libraries Committee >> >> I think we need your advice. >> >> This thread (mostly on ghc-devs) shows that if the shim-package and >> boolean-primop decision goes as currently proposed, then we'll need a new >> release of Alex >> * Either to generate an import of GHC.Exts.Compat >> (ie depend on the shim package) >> * Or to make its own local tiny shim module for the primops it uses >> * Or maybe some other plan >> (Alex already has quite a bit of stuff designed to make it generate code >> that will be compilable with a variety of GHCs.) >> >> Moreover this new release of Alex will be necessary simply in order to >> allow 7.8 (or indeed 7.7) to be bootstrapped. So, for example, the current >> HP could not be used to build GHC. >> >> How would you like us to proceed? Thanks!**** >> >> >> Simon >> >> | -----Original Message----- >> | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> | Geoffrey Mainland**** >> >> | Sent: 09 September 2013 16:14 >> | To: Jan Stolarek >> | Cc: ghc-devs >> | Subject: Re: Alex and new Bool primops >> |**** >> >> | I say this only somewhat facetiously, but this is *exactly* the sort of >> | problem that the pro-backwards compatibility camp anticipates, and I >> | mean the "pro-backwards compatibility camp" in the most general possible >> | way :) The point is that you can never anticipate all the ways in which >> | breaking backwards compatibility breaks things. How much "technical >> | debt" is really accrued with backwards compatible primops? What is >> | preventing us from doing the so-called "Right Thing" *after* the 7.8 >> | release? >> | >> | Anyway, the one solution I can think of off the top of my head is to >> | patch Alex's templates to use an #ifdef to pick primops based on the >> | version of GHC being used for compilation. That will need to be done >> | anyway. >> | >> | As an aside, I think any discussion that involves making decisions that >> | effect the community as a whole should have a public mail archive. >> | >> | Geoff >> | >> | On 09/09/2013 11:02 AM, Jan Stolarek wrote: >> | > I think the there was a general agreement in the committee that we >> | should follow the best long-term solution, not the best short-term one. >> | Here are two arguments (Plan B = break backwards compatibility): >> | > >> | > > I'd rather not hamstring GHC.* with a rats nest of backwards >> | compatibility decisions, >> | > > which all come at accreted costs, the mortgage for which is to be >> | paid down forever >> | > > by future development efforts. >> | > >> | > > I vote for plan B on the grounds that it's the Right Thing and the >> | > > group that it breaks is both small and savvy. >> | > >> | > > [implementing backwards compatibility solution] only works once, >> | though. We're in exactly the same boat on all future primop redesigns. >> | > >> | > There was also a decision of providing a backwards compatibility >> | package that would make it easy for library authors to create packages >> | that are compatible both with 7.6 and 7.8 (summarized here: >> | http://www.haskell.org/haskellwiki/Compatibility_Modules) Sadly, >> | there's no web archive for that list so I can't point you to the >> | discussion. >> | > >> | > Anyway, this is clearly something no one has anticipated and the >> | question is whether we have a good way to solve that problem? >> | > >> | > Janek >> | > >> | > ----- Oryginalna wiadomość ----- >> | > Od: "Geoffrey Mainland" <mainland(a)apeiron.net> >> | > Do: "Jan Stolarek" <jan.stolarek(a)p.lodz.pl> >> | > DW: "ghc-devs" <ghc-devs(a)haskell.org> >> | > Wysłane: poniedziałek, 9 wrzesień 2013 15:40:09 >> | > Temat: Re: Alex and new Bool primops**** >> >> | > >> | > Perhaps the core libraries committee should reconsider their decision? >> | > :) Backwards compatibility is good. If HEAD implements the backwards >> | > compatibility plan that Simon PJ and I suggested and said plan is >> | > working, there should be a compelling reason to break compatibility >> | and >> | > have to go chasing down all the follow-on breakage (in, e.g., Alex) so >> | > close to release. >> | > >> | > What was the committee's reasoning? >> | > >> | > Geoff >> | > >> | > On 09/09/2013 10:08 AM, Jan Stolarek wrote: >> | >> I am refactoring new Bool primops (#6135). There was a discussion on >> | core-libraries-commitee list and the decision was made that we should >> | keep names of primops we used so far and change their type signature >> | (right now HEAD has different names for new primops and reuses old names >> | for compatibility wrappers). I've changed names of the primops and >> | removed the wrappers but I can't bootstrap GHC because old primops are >> | hardwired into Alex. I get this build error when attempting to build >> | stage 2 compiler: >> | >> >> | >> compiler/stage2/build/Lexer.hs:2348:34: >> | >> Couldn't match expected type 'Bool' with actual type 'Int#' >> | >> In the first argument of '(&&)', namely '(offset >=# 0#)' >> | >> In the expression: (offset >=# 0#) && (check ==# ord_c) >> | >> In the expression: >> | >> if (offset >=# 0#) && (check ==# ord_c) then >> | >> alexIndexInt16OffAddr alex_table offset >> | >> else >> | >> alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> compiler/stage2/build/Lexer.hs:2348:53: >> | >> Couldn't match expected type 'Bool' with actual type 'Int#' >> | >> In the second argument of '(&&)', namely '(check ==# ord_c)' >> | >> In the expression: (offset >=# 0#) && (check ==# ord_c) >> | >> In the expression: >> | >> if (offset >=# 0#) && (check ==# ord_c) then >> | >> alexIndexInt16OffAddr alex_table offset >> | >> else >> | >> alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> And indeed, looking at Lexer.hs I see: >> | >> >> | >> alex_scan_tkn user orig_input len input s last_acc = >> | >> (...) -- some irrelevant code here >> | >> (!(new_s)) = if (offset >=# 0#) && (check ==# ord_c) >> | >> then alexIndexInt16OffAddr alex_table >> | offset >> | >> else alexIndexInt16OffAddr alex_deflt s >> | >> >> | >> So to compile GHC, Alex would need to generate different code for GHC >> | 7.6.3 and below, and different for GHC 7.7 and above (or alternatively >> | it could generate #if pragmas), but this means we'd need to update Alex. >> | I created compatibility module within GHC called ExtsCompat46 and tried >> | adding it to list of imported modules, but in generated Lexer.hs Alex >> | adds a bunch of other modules among which is GHC.Exts, which conflicts >> | with import of ExtsCompat46: >> | >> >> | >> compiler/stage1/build/Lexer.hs:2349:41: >> | >> Ambiguous occurrence `>=#' >> | >> It could refer to either `ExtsCompat46.>=#', >> | >> imported from `ExtsCompat46' at >> | compiler/parser/Lexer.x:79:1-19 >> | >> or `GHC.Exts.>=#', >> | >> imported from `GHC.Exts' at >> | compiler/stage1/build/Lexer.hs:75:1-15 >> | >> (and originally defined in `ghc- >> | prim:GHC.Prim') >> | >> >> | >> Again, we would need updated version of Alex to generate correct code >> | (also, this would break in the future after removing that compatibility >> | module). I don't see a way out of this. Help? >> | >> >> | >> Janek >> | >> >> | >> _______________________________________________ >> | >> ghc-devs mailing list >> | >> ghc-devs(a)haskell.org >> | >> http://www.haskell.org/mailman/listinfo/ghc-devs >> | > >> | >> | >> | _______________________________________________ >> | ghc-devs mailing list >> | ghc-devs(a)haskell.org >> | http://www.haskell.org/mailman/listinfo/ghc-devs >> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out.**** >> >> ** ** >> > >

1 0

A bug of linebuffering
by Kazu Yamamoto 11 Sep '13

11 Sep '13

Hi, While I support GHC head for "doctest", I encountered the following bug. "doctest" uses a GHCi subprocess to evaluate an expression represented in String. Stderr from GHCi is merged into stdout by hDuplicateTo in the GHCi side. Even evaluating an error expression, for instance "1 `div` 0", the line buffering does not work. "doctest" waits for output from GHCi forever. This does not happen if stderr is not merged into stdout. The following code demonstrates this bug. Running it with GHC head waits forever. Running it with GHC 7.6.3 prints: "*** Exception: divide by zero" "3" If you change "1 `div` 0" into "1 `div` 0\nprint 10", this code run by GHC head prints: "*** Exception: divide by zero" "10" This is a serious behavior change for "doctest". I hope this will be fixed. --Kazu module Main where import System.Process import System.IO myProc :: CreateProcess myProc = (proc "ghc" ["-v0", "--interactive", "-ignore-dot-ghci"]) { std_in = CreatePipe , std_out = CreatePipe , std_err = Inherit } setMode :: Handle -> IO () setMode hdl = do hSetBinaryMode hdl False hSetBuffering hdl LineBuffering newInterpreter :: IO (Handle, Handle) newInterpreter = do (Just stdin_, Just stdout_, _, _) <- createProcess myProc setMode stdin_ setMode stdout_ hPutStrLn stdin_ "import System.IO" hPutStrLn stdin_ "import GHC.IO.Handle" hPutStrLn stdin_ "hDuplicateTo stdout stderr" hFlush stdin_ return (stdin_, stdout_) eval :: Handle -> Handle -> String -> IO String eval hin hout expr = do hPutStrLn hin expr hFlush hin hGetLine hout main :: IO () main = do (stdin_, stdout_) <- newInterpreter eval stdin_ stdout_ "1 `div` 0" >>= print eval stdin_ stdout_ "1 + 2" >>= print return ()

1 1

the spam should stop now
by Carter Schonwald 10 Sep '13

10 Sep '13

I pingged the haskell infrastructure folks, and they've hopefully fixed it up properly.

1 0

如何构建人力资源管理系统
by 沛菡姐 10 Sep '13

10 Sep '13

4 3

Re：劳-动法律法规、政策如何渗透
by 祁烟芷 10 Sep '13

10 Sep '13

1 0

不同发展阶段中试管理模式与实践
by ytzkqmho＠jxda.com 10 Sep '13

10 Sep '13

　产品中试管理——从样品到量产 ======================================================================================　培训时间：2013年9月22-23上海、9月25-26深圳、9月28-29北京培训对象：企业CEO/总经理、研发总经理/副总、测试部经理、中试/试产部经理、制造部经理、工艺/工程部经理、质量部经理、项目经理/产品经理、高级制造工程师等培训费用：2800元/1人| 4300元/2人（含资料费、午餐、茶点、发票等) 　热线电话：400-633-0030 深圳/市场部：0755-61282649 刘小姐上海/市场部：021-31200290 金小姐　课程背景：我们在为企业提供研发管理咨询服务的过程中发现，很多企业的新产品开发从样机到量产的过程中（产品化过程）存在着共同的问题： 1.新品没有经过中试或中试的时间很短，制造部门戏称研发的新品是“三无”产品，没有生产文件、没有工装、生产现场出了问题没人管； 2.转产没有标准，研发想快点转产，生产对有问题的产品又不愿接收，希望研发把问题都解决了才转过来，而市场又催得急，经常被迫接收，长此以往，导致研发与生产的矛盾激化； 3.有些企业开始成立中试部门，希望在中试阶段把产品质量问题解决掉，但中试的定位与运作也很困惑，发生质量与进度的冲突时，如何取舍与平衡，以前研发与制造的矛盾转化为研发与中试、中试与生产的矛盾，中试成了矛盾集散中心； 4.市场的压力并不因中试的产生而减少，中试需要从哪些方面努力才能满足产品的质量、进度的要求？中试的业务是面向研发还是面向制造，还是兼而有之？ 5.量产后才发现产品可制造性差、成品率低、经常返工，影响发货； 6.产品到了生产后还发生大量的设计变更； 7.产品到了客户手中还冒出各种各样的问题以致要研发人员到处去“救火”。。。。。。本课程将基于多年的实践、长期的研发咨询积累，总结出一套理论与实践相结合的可操作的方法，配以大量实际案例，以指导研发/试产/制造部门主管如何高效的实现产品从样品走向量产。　课程收益： 1.了解业界公司在不同发展阶段的产品中试管理模式与实践 2.掌握面向制造系统的产品设计（DFM）的方法与实施过程 3.掌握面向生产测试的产品设计（DFT）的方法与实施过程 4.掌握面向制造系统的新产品验证的过程与方法 5.掌握在满足质量标准的前提下缩短产品试制周期的方法和技巧 6.了解如何建立从样品到量产的管理机制　导师简介：[Charles] 　　研发咨询品牌资深顾问　　INCOSE 国际系统工程师联合会会员　　16年的高科技企业从业背景，具有丰富的产品研发、新产品导入、工艺工程、售前与售后等领域的实践与管理经验。曾在多家高科技企业中担任产品开发工程师（电子）、工艺工程师、售后服务工程师、项目经理、产品经理、设计工程部经理、工艺工程部经理、新产品导入部经理、技术管理部经理、企业管理顾问等职务；　　在某著名通信公司工作7年（97~03），期间长期与国际顶尖咨询顾问一起工作，全程参与推动该公司研发管理体系的变革工作，并成功主导了新产品导入平台的建设工作，作为产品经理主导了某产品线多个大型项目的产品研发工作。　研发管理咨询经验：　　从事研发管理咨询工作以来，作为项目总监成功的主持了格林威尔、广州威创日新、某电子科技集团研究所、国人通信等数十家企业的产品规划流程体系设计、试验局流程设计、知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KPI 体系设计等方面的管理咨询项目。　　　曾在各地多次举办研发质量管理、研发项目管理、新产品开发流程优化与管理、从样品走向量产等公开课，为数千家企业提供了研发管理公开课的培训，为数百家企业进行了研发管理的内训；从事研发管理咨询工作以来，作为项目总监成功的主持完成了数十个研发管理咨询项目体系的建设 <产品规划流程体系设计、试验局流程设计、知识管理体系设计、中试业务管理体系梳理、研发IT规划、研发项目管理体系设计、研发质量管理体系、研发绩效管理体系设计、研发KPI体系设计等方面>，有着丰富的研发管理咨询经验，涉及的行业包括通信、软件、家电、电信运营商、芯片、医疗器械、交通运输等，帮助这些企业建立高效、完备的研发管理体系，对中国企业研发管理体系及创新体制有着深刻的研究和理解，受到客户的高度评价。曾为科达通信、中电集团、TCL集团、威创、和记奥普泰、国人通信、京信科技、天碁科技、格林威尔、兴大豪科技、星星集团、山特电子、富港电子、宇龙通信、聚光科技、绿盟科技、天津内燃机研究所、同方威视、中集集团、高斯贝尔、星网锐捷、OPPO电子、特变电工、思源电器、海格客车、美的集团、国光电子、雷沃重汽、上汽五凌、东风汽车、威科姆、同洲电子、科立讯、新北洋、光迅科技、沈阳机床等近300家企业提供了专业的研发管理培训。　课程大纲：　一、案例研讨　二、从样品到量产概述 1.企业在追求什么：技术？样品？产品？商品？ 2.研发与制造的矛盾： 1）.制造系统如何面对研发的三无产品？ 2）.研发如何面对制造系统越来越高的门槛？ 3.研发与制造矛盾的激化：中试的产生成为必然 4.中试的定位与发展： 1）.研发（RD）、中试（D&P）、生产（P）的关系 2）.中试的使命是什么？ 3）.中试如何定位？ 4）.中试的发展问题： a 大而全？ b 专业化分工？ c 产品线划分与共享平台 d 中试人员的发展定位：广度与深度问题 5.中试的业务范围 1）.中试业务：新产品导入（NPI） 2）.承上：如何面向产品的研发？ 3）.启下：如何面向产品的制造？ 4）.桥梁：中试作为连接研发与制造的桥梁，独木桥还是阳关道？ 6.演练与问题讨论 1）.根据企业的实际情况，是否需要建立并发展中试的职能? 　三、新产品导入团队 1.新产品导入团队的构成 1）.工艺工程 2）.设备工程 3）.测试工程 4）.工业工程 5）.产品验证 6）.试生产（计划、生产、质量） 2.新产品导入团队的职责 3.新产品导入团队与产品开发团队的关系 1）.开发模式的演变：串行变并行 2）.并行工程在产品开发中如何体现？ 3）.新产品导入团队如何提前介入研发？ a 为什么要提前介入？ b 提前到什么时候介入？ c 提前介入做什么？ 4）.新产品导入团队的管理 a 新产品导入团队与产品开发团队、职能部门的沟通 b 新产品导入团队成员的汇报、考核和管理机制 4.演练与问题讨论 1）.根据企业的实际情况，研讨建立新产品导入团队的时机　四、面向制造系统的产品设计（DFM） 1.如何在产品设计与开发过程中进行可制造性设计 1）.从制造的角度来看产品设计 2）.工艺人员介入产品开发过程的切入点：从立项就开始 3）.工艺管理的三个阶段：工艺设计、工艺调制与验证、工艺管制 4）.工艺设计： a 如何提出可制造性需求？ b 需要哪些典型的工艺规范？ c 可制造性需求如何落实到产品设计方案中？ d工艺设计与产品设计如何并行？ e 产品工艺流程设计 f 电装、整装、包装与物流的可制造性设计分析 g 如何确保可制造性需求在产品开发中已被实现？ h 工艺评审如何操作？ i 什么时候考虑工装？ j 如何在开发过程中同步输出工艺文件与生产操作指导文件 5）.工艺调制与验证 a 工艺验证的时机 b 工艺验证方案包括哪些内容？ c 如何实施工艺验证？ d 工艺验证报告的内容 e 如何推动工艺验证的问题解决？ f 研发人员如何配合新产品的工艺验证？ g 制造外包模式下的工艺如何验证？ 6）.工艺管制 a 工艺管制的困惑：救火何时是尽头？ b 工艺转产评审（标准、流程、责任） c 量产过程中的例行监控与异常管理 2.演练与问题讨论 1）.分析学员企业的工艺管理工作做到什么程度？存在哪些差距？ 3.工艺管理平台建设 1）.谁负责工艺平台的建设？ 2）.工艺委员会的产生：责任与运作模式 3）.如何进行工艺规划？ 4）.基础工艺研究与应用 5）.支撑工艺管理平台的四大规范： a 品质规范 b 设备规范 c 工艺规范 d 设计规划 6）.工艺管理部门如何推动DFM业务的开展？ 7）.工艺体系的组织构成、发展与演变 8）.工艺人员的培养与技能提升 4.演练与问题讨论 1）.分析学员企业的工艺平台建设工作做到什么程度？存在哪些差距？如何改进？　五、面向生产测试的产品设计（DFT） 1.基于产品生命周期全流程的测试策略 1）.研发测试（Alpha）、试验局测试（Beta）、生产测试 2.研发测试（Alpha）与BETA测试 1）.测试人员介入产品开发过程的时机（提可测试性需求的时机） 2）.可测试性需求需要考虑的内容（示例） 3）.单元测试、模块测试、系统集成测试、专业化测试、BETA测试的重点分析 4）.产品开发过程中测试业务流程分析 5）.企业在不同的发展阶段如何开展测试的相关工作（短平快的项目测试工作如何开展） 3.面向生产测试业务的产品设计与开发 1）.生产测试业务流程分析 2）.典型的部品测试、整机测试方法介绍 3）.开发专门的生产测试工装的条件分析 4）.生产测试工装的开发管理 5）.在产品开发过程中如何实施面向生产测试的产品设计？ a 如何提出可测试性需求？ b 可测试性需求如何落实到产品设计方案中？ c 研发面对众多的需求如何取舍？可测试性需求的优先级分析 d 如何在产品开发过程中同步开发生产测试工装？ e 如何在产品开发过程中同步输出生产测试所需的操作指导文件？ f 如何进行测试工装的验证？ g 如何推动测试验证问题的解决？ 6）.如何推动可测试性设计（DFT）业务的开展 7）.如何进行测试平台的建设？ 4.演练与问题讨论 1）.分析学员企业的DFT工作做到什么程度？存在哪些差距？如何改进？　六、产品试制验证管理 1.影响产品试制周期的因素分析 2.研发人员对试制准备提供的支持 3.试制团队的构成、职责与定位（设置试制部门的时机与优缺点分析） 4.试制人员介入产品开发过程的时机 1）.如何进行试制准备（准备要素示例） 5.面向制造系统的验证 1）.研发人员如何在试制过程中进行产品设计的优化 2）.制造系统的验证策略与计划 3）.制造系统的验证方案 4）.如何实施制造系统的验证： a 工艺验证（工艺流程、工艺路线、单板工艺、整机工艺、包装工艺、物流工艺） b 工装验证（装配工装、测试工装、生产设备） c 结构验证 d 产品数据验证（BOM验证、制造文档验证） e 产品试制验证（质量、效率、成本） 5）.批次验证报告，验证多少批才合适？ 6）.如何推动验证问题的解决？ 6.转产评审 1）.研发人员如何支持新产品的转产工作 2）.转产评审的评审组织如何构成？ 3）.评审标准是什么？ 4）.如何判定是否转产？ 5）.评审流程与运作机制 7.产品转产后的管理 1）.新产品的试制效果评价 2）.新产品的质量目标达成情况 3）.工程变更管理 4）.缺陷与问题管理 5）.质量审计 8.演练与问题讨论 1）.分析学员企业的产品试制验证过程，分析差距，提出改进建议。　七、总结　本课程可针对企业需求，上门服务，组织内训，欢迎咨询。　

1 0