Re: Proposal process status
On Thu, 2016-07-21 at 14:38 -0400, Richard Eisenberg wrote: > > > > On Jul 21, 2016, at 2:25 PM, Yuras Shumovich <shumovi...@gmail.com> > > wrote: > > > > It is hopeless. Haskell2020 will not include TemplateHaskell, > > GADTs, > > etc. > > Why do you say this? I don't think this is a forgone conclusion. I'd > love to see these standardized. Because I'm a pessimist :) We even can't agree to add `text` to the standard library. > > My own 2¢ on these are that we can standardize some subset of > TemplateHaskell quite easily. GADTs are harder because (to my > knowledge) no one has ever written a specification of type inference > for GADTs. (Note that the OutsideIn paper admits to failing at this.) > Perhaps we can nail it, but perhaps not. Even so, we can perhaps > standardize much of the behavior around GADTs (but with pattern > matches requiring lots of type annotations) and say that an > implementation is free to do better. Maybe we can do even better than > this, but I doubt we'll totally ignore this issue. > > > Haskell Prime committee will never catch up if GHC will continue > > adding new extensions. > > Of course not. But I believe some libraries also refrain from using > new extensions for precisely the same reason -- that the new > extensions have yet to fully gel. And you are an optimist. We are lazy, so we'll use whatever is convenient. There are three ways to force people to refrain from using new extensions: - mature alternative compiler exists, so nobody will use your library unless it uses only the common subset of features; - the standard covers all usual needs (I don't think it will be possible in near future, and existence of this email thread proves that.) - new features are not first class citizens; e.g. `cabal check` issues an error (or warning) when you are uploading a package with immature extension used. > > > In 2020 everybody will use pattern synonyms, > > overloaded record fields and TypeInType, so the standard will be as > > far > > from practice as it is now. > > Pattern synonyms, now with a published paper behind them, may > actually be in good enough shape to standardize by 2020. I don't know > anything about overloaded record fields. I'd be shocked if TypeInType > is ready to standardize by 2020. But hopefully we'll get to it. > > > > > The whole idea of language extensions, as it is right now, works > > against Haskell Prime. > > I heartily disagree here. Ideas that are now standard had to have > started somewhere, and I really like (in theory) the way GHC/Haskell > does this. I'm not against language extensions completely. But using them should be a real pain to prevent people from using then everywhere. Ideally you should have to compile GHC manually to get a particular extension enabled :) > > The (in theory) parenthetical is because the standardization process > has been too, well, dead to be useful. Is that changing? Perhaps. I'd > love to see more action on that front. I'm hoping to take on a more > active role in the committee after my dissertation is out the door (2 > more weeks!). > > > > I see only one real way to change the situation -- standardize all > > widely used extensions and declare anything new as experimental > > unless > > accepted by the Haskell Prime Committee. > > Agreed here. Great. So I propose to split section "9. GHC Language Features" of the user manual into "Stable language extensions" and "Experimental language extensions", move all the recently added extensions into the latter one, explicitly state in the proposed process that all new extensions go to the "Experimental" subsection initially and specify when they go to the "Stable" subsection. > I think that's what we're trying to do. If you have a good > specification for GADT type inference, that would help us. :) I'd personally prefer to mark GADT and TH as experimental. The difficulties with their standardizing is a sign of immaturity. I regret about each time I used them in production code. > > Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal process status
On Thu, 2016-07-21 at 13:25 -0400, Richard Eisenberg wrote: > > > > On Jul 21, 2016, at 11:29 AM, Yuras Shumovich <shumovi...@gmail.com > > > wrote: > > > > Unfortunately Haskell *is* implementation-defined language. You > > can't > > compile any nontrivial package from Hackage using Haskell2010 GHC. > > Sadly, I agree with this statement. And I think this is what we're > trying to change. And I'd like it to be changed too. I'm paid for writing SW in Haskell, and I want to have a standard. At the same time I'm (probably unusual) Haskell fan, so I want new cool features. Don't you see a conflict of interests? https://www.reddit.com/r/haskell/comments/4oyxo2/blog_contributing_to_ghc/d4iaz5t > > > And > > the same will be true for Haskell2020. We rely on GHC-specific > > extensions everywhere, directly or indirectly. If the goal of the > > Haskell Prime is to change that, then the GHC-specific extensions > > should not be first class citizens in the ecosystem. > > My hope is that Haskell2020 will allow us to differentiate between > standardized extensions and implementation-defined ones. A key part > of this hope is that we'll get enough extensions in the first set to > allow a sizeable portion of our ecosystem to used only standardized > extensions. It is hopeless. Haskell2020 will not include TemplateHaskell, GADTs, etc. Haskell Prime committee will never catch up if GHC will continue adding new extensions. In 2020 everybody will use pattern synonyms, overloaded record fields and TypeInType, so the standard will be as far from practice as it is now. The whole idea of language extensions, as it is right now, works against Haskell Prime. https://www.reddit.com/r/haskell/comments/46jq4i/what_is_the_eventual_fate_of_all_of_these_ghc/d05q9no I abandoned my CStructures proposal because of that. I don't want to increase entropy. https://phabricator.haskell.org/D252 > > > > We can continue pretending that Haskell is standard-defined > > language, > > but it will not help to change the situation. > > But writing a new standard that encompasses prevalent usage will help > to change the situation. And that's the process I'm hoping to > contribute to. I see only one real way to change the situation -- standardize all widely used extensions and declare anything new as experimental unless accepted by the Haskell Prime Committee. Probably there are other ways, but we need to cleanup the mess ASAP. New extensions only contribute to the mess -- that is my point. > > Richard ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal process status
On Thu, 2016-07-21 at 10:32 -0400, Gershom B wrote: > On July 21, 2016 at 8:51:15 AM, Yuras Shumovich (shumovi...@gmail.com > ) wrote: > > > > I think it is what the process should change. It makes sense to > > have > > two committees only if we have multiple language implementations, > > but > > it is not the case. Prime committee may accept or reject e.g. > > GADTs, > > but it will change nothing because people will continue using GADTs > > regardless, and any feature accepted by the Prime committee will > > necessary be compatible with GADTs extension. > > I disagree. By the stated goals of the H2020 Committee, if it is > successful, then by 2020 it will still for the most part have only > standardized ony a _portion_ of the extentions that now exist today. Yes, I know. But don't you see how narrow the responsibility of the H2020 Committee is? GHC Committee makes all important decisions, and H2020 just collects some of GHC extensions into a set of "standard" ones. It is useful only when "nonstandard" extensions are not widely used (e.g. marked as experimental, and are not recommended for day-to- day use). > > There’s always been a barrier between implementation and standard in > the Haskell language, that’s precisely one of the things that _keeps_ > it from having become entirely implementation-defined despite the > prevelance of extensions. Unfortunately Haskell *is* implementation-defined language. You can't compile any nontrivial package from Hackage using Haskell2010 GHC. And the same will be true for Haskell2020. We rely on GHC-specific extensions everywhere, directly or indirectly. If the goal of the Haskell Prime is to change that, then the GHC-specific extensions should not be first class citizens in the ecosystem. Otherwise there is no sense in two committees. We can continue pretending that Haskell is standard-defined language, but it will not help to change the situation. > > Having two entirely different processes here (though obviously not > without communication between the individuals involved) helps > maintain that. > > —Gershom > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal process status
On Wed, 2016-07-20 at 18:37 +0200, Ben Gamari wrote: > Yuras Shumovich <shumovi...@gmail.com> writes: > > > Looks like reddit is a wrong place, so I'm replicating my comment > > here: > > > Thanks for your comments Yuras! > > > > * Do you feel the proposed process is an improvement over the > > > status quo? > > > > Yes, definitely. The existing process is too vague, so formalizing > > it > > is a win in any case. > > > Good to hear. > > > > * What would you like to see changed in the proposed process, > > > if > > > anything? > > > > The proposed process overlaps with the Language Committee powers. > > In > > theory the Committee works on language standard, but de facto > > Haskell > > is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to > > GHC > > adds new extension to Haskell. So I'd like the process to enforce > > separation between experimental extensions (not recommended in > > production code) and language improvements. I'd like the process to > > specify how the GHC Committee is going to communicate and share > > powers > > with the Language Committee. > > > To clarify I think Language Committee here refers to the Haskell > Prime > committee, right? Yes, Herbert used "Haskell Prime 2020 committee" and "Haskell Language committee" interchangeable in the original announcement https://mail.ha skell.org/pipermail/haskell-prime/2016-April/004050.html > > I think these two bodies really do serve different purposes. > Historically the Haskell Prime committee has been quite conservative > in > the sorts of changes that they standardized; as far as I know almost > all > of them come from a compiler. I would imagine that the GHC Committee > would be a gate-keeper for proposals entering GHC and only some time > later, when the semantics and utility of the extension are > well-understood, would the Haskell Prime committee consider > introducing > it to the Report. As far as I understand it, this is historically how > things have worked in the past, and I don't think this new process > would > change that. I think it is what the process should change. It makes sense to have two committees only if we have multiple language implementations, but it is not the case. Prime committee may accept or reject e.g. GADTs, but it will change nothing because people will continue using GADTs regardless, and any feature accepted by the Prime committee will necessary be compatible with GADTs extension. The difference between standard and GHC-specific extensions is just a question of formal specification, interesting mostly for language lawyer. (But it is good to have such formal specification even for GHC- specific extensions, right?) Probably it is time to return -fglasgow-exts back to separate standard feature from experimental GHC-specific ones. > > Of course, let me know if I'm off-base here. > > Cheers, > > - Ben ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal process status
Looks like reddit is a wrong place, so I'm replicating my comment here: On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote: > Hello everyone, > > As you hopefully know, a few weeks ago we proposed a new process [1] > for > collecting, discussing, and deciding upon changes to GHC and its > Haskell > superset. While we have been happy to see a small contingent of > contributors join the discussion, the number is significantly smaller > than the set who took part in the earlier Reddit discussions. > > In light of this, we are left a bit uncertain of how to proceed. So, > we would like to ask you to let us know your feelings regarding the > proposed process: > > * Do you feel the proposed process is an improvement over the > status > quo? Yes, definitely. The existing process is too vague, so formalizing it is a win in any case. > > * Why? (this needn't be long, just a sentence hitting the major > points) > > * What would you like to see changed in the proposed process, if > anything? The proposed process overlaps with the Language Committee powers. In theory the Committee works on language standard, but de facto Haskell is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC adds new extension to Haskell. So I'd like the process to enforce separation between experimental extensions (not recommended in production code) and language improvements. I'd like the process to specify how the GHC Committee is going to communicate and share powers with the Language Committee. Thanks, Yuras. > > That's all. Again, feel free to reply either on the GitHub pull > request > [1] or this thread if you would prefer. Your response needn't be > long; > we just want to get a sense of how much of the community feels that > 1) > this effort is worth undertaking, and 2) that the proposal before us > is > in fact an improvement over the current state of affairs. > > Thanks for your help! > > Cheers, > > - Ben > > > [1] https://github.com/ghc-proposals/ghc-proposals/pull/1 > ___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user > s ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: -staticlib flag for building standalone static libraries producing very large libraries
On Sat, 2015-03-07 at 22:18 +1100, Sean Seefried wrote: Hi all, Can anyone explain the following problem I'm having? I'm currently writing a game in Haskell. When I produce a plain old executable (for local testing) it's about 23M. However, when I create a static lib using the -staticlib flag it is 54M. Most likely that is because executable contains only necessary/used definitions, while static lib is just an archive of all object files, including all dependencies. Note also that by default core libs are compiled using --split-objs, so when linking executable, all unused top level definitions are filtered out. (And you can decrease size of the executable even more by compiling it and all its dependencies using --split-objs if you are not using it already.) Without the flag, unused definitions are filtered out on per module basis. (I'm not an expert here, so the above description can be partially or totally wrong :) ) Thanks, Yuras Why the discrepancy? Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: confusing type error
It seems to be an instance of https://ghc.haskell.org/trac/ghc/ticket/7869 But it is fixed (both in HEAD and 7.8). Probably the fix is partial? On Thu, 2014-12-04 at 14:53 -0500, Richard Eisenberg wrote: This seems straightforwardly to be a bug, to me. HEAD gives the same behavior you report below. Please post on the bug tracker at https://ghc.haskell.org/trac/ghc/newticket Thanks! Richard On Dec 4, 2014, at 1:50 PM, Evan Laforge qdun...@gmail.com wrote: I recently got a confusing error msg, and reduced it to a small case: f1 :: Monad m = m Bool f1 = f2 0 0 'a' f2 :: Monad m = Int - Float - m Bool f2 = undefined From this, it's clear that f2 is being given an extra Char argument it didn't ask for. However, the error msg (ghc 7.8.3) is: Couldn't match type ‘m Bool’ with ‘Bool’ Expected type: Char - m Bool Actual type: Char - Bool Relevant bindings include f1 :: m Bool (bound at Bug.hs:4:1) The function ‘f2’ is applied to three arguments, but its type ‘Int - Float - Char - Bool’ has only three In the expression: f2 0 0 'a' In an equation for ‘f1’: f1 = f2 0 0 'a' The confusing part is that 'f2' was applied to three arguments, but it's type has only three. It includes the Char in expected and actual types, and implies that the type of 'f2' includes the Char. So I took quite a while to realize that the type of 'f2' in fact *didn't* expect a Char (and had an 'm'), so that the but its type is *not* in fact its declared type. I suppose it infers a type for 'f2' based on its use, and that then becomes the actual type, but it seems less confusing if it picked the declared type of 'f2' as its actual type. Perhaps this is working as intended, but it it is confusing! Especially the part about expected three but got three. Ideally I'd like to see too many arguments or at least expected (Char - m Bool) but actually 'm Bool'. Actually I'd expect the other way: expected 'm Bool' but got (Char - m Bool)' but I think ghc has always done it backwards from how I expect. It looks like it's substituting (-) for 'm', so maybe it's one of those things where ((-) a) is also a monad. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.4.2 on Ubuntu Trusty
On Wed, 2014-10-22 at 13:48 +0300, Yitzchak Gale wrote: In order support some older software that we released, we need to get a working GHC 7.4.2 on Ubuntu Trusty. We currently have GHC 7.8.3. The binary tarball for GHC 7.4.2 does not install on Trusty due to multiple incompatibilities. For example, GHC requires GMP 3, but Trusty only provides GMP = 4. Etc. You can try to make a symlink from libgmp.so.10 to libgmp.so.3 AFAIK ghc doesn't use anything specific to new gmp. Then you can recompile with ghc from sources and link it with gmp10. Also precise provides both gmp3 and gmp10, so you can bootstrap on precise using 7.4.2/gmp3 to get 7.4.2/gmp10 binary. I tried building GHC 7.4.2. from source on Trusty. But the process won't boot from our currently installed GHC 7.8.3. The oldest GHC binary I can get is GHC 7.6.3, which happens to be still available from the Ubuntu distribution itself (neither the binary tarball nor compiling from source work for GHC 7.6.3 on Trusty either). But booting from GHC 7.6.3 won't work either. How do I get a working GHC 7.4.2 on Trusty? Thanks, Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Dependencies missing when building ghc.
Hello, It is recommended to checkout 7.8 in special way, see https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources#checkout-old-branch That is because repo structure was changed after 7.8 Thanks, Yuras 13 Окт 2014 г. 4:03 пользователь Magicloud Magiclouds magicloud.magiclo...@gmail.com написал: Hi, I am with my new Ubuntu Trusty box. I have installed ghc by apt-get. Then I wanted to build ghc from git to upgrade to 7.8.3. I did following commands. I tried 'make clean', or reget the source. No luck yet. $ git clone --recursive git://git.haskell.org/ghc.git $ ./sync-all -r git://git.haskell.org remote set-url origin $ git checkout ghc-7.8.3-release $ ./sync-all get $ rm -r libraries/time # as prompted by sync-all $ ./sync-all get $ ./boot $ ./configure $ make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds inplace/bin/ghc-cabal check libraries/haskell98 inplace/bin/ghc-cabal configure libraries/haskell98 dist-install --with-ghc=/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-stage1 --with-ghc-pkg=/home/local/ANT/shida/src/git/ghc/inplace/bin/ghc-pkg --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --configure-option=CFLAGS= -fno-stack-protector--configure-option=LDFLAGS= --configure-option=CPPFLAGS=--gcc-options= -fno-stack-protector --with-gcc=/usr/bin/gcc --with-ld=/usr/bin/ld --configure-option=--with-cc=/usr/bin/gcc --with-ar=/usr/bin/ar --with-ranlib=/usr/bin/ranlib --with-alex=/usr/bin/alex --with-happy=/usr/bin/happy Configuring haskell98-2.0.0.4... ghc-cabal: At least the following dependencies are missing: base ==4.8.* make[1]: *** [libraries/haskell98/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-optl behavior in ghc-7.8.1
Hi, I found that -optl behavior was changed in ghc-7.8.1 ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite. $ /opt/ghc-7.6.3/bin/ghc --make main.hs -optl=hello -v ... '/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' '-o' 'main' 'main.o' 'hello' ... ... $ /opt/ghc-7.8.1/bin/ghc --make main.hs -optl=hello -v ... /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE hello -o main main.o ... ... Is it intentional change? I want to compile in a number of static libraries. I have the next line in my cabal file: ld-options: ./path/to/libsomething.a It works ok on linux and mac os with ghc-7.6.3, but with ghc-7.8.1 I get undefined references for symbols from the libsomething.a Thanks, Yuras ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -optl behavior in ghc-7.8.1
On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich shumovi...@gmail.comwrote: ghc-7.6.3 passes additional linker options after all the haskell object files, while ghc-7.8.1 does the opposite. (...) Is it intentional change? Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be. Yes, I understand. But how the new behavior is better then the old one? I want to compile in a number of static libraries. I have the next line in my cabal file: ld-options: ./path/to/libsomething.a You're abusing ld-options. Use extra-libraries for this; if it doesn't work then you have found another bug and should file it as such. extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -optl behavior in ghc-7.8.1
On Thu, 2014-04-10 at 12:13 -0400, Brandon Allbery wrote: On Thu, Apr 10, 2014 at 12:02 PM, Yuras Shumovich shumovi...@gmail.comwrote: On Thu, 2014-04-10 at 11:54 -0400, Brandon Allbery wrote: On Thu, Apr 10, 2014 at 11:44 AM, Yuras Shumovich shumovi...@gmail.com wrote: Is it intentional change? Pretty sure it is intentional, because it's necessary for some options. ld options are not in general position independent, and can't be. Yes, I understand. But how the new behavior is better then the old one? If it was not clear from what I said that some linker options must come before objects/libraries to have any effect then I am not sure what will clarify it for you. ...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed. ld-options: ./path/to/libsomething.a You're abusing ld-options. Use extra-libraries for this; if it doesn't work then you have found another bug and should file it as such. extra-libraries doesn't work because it links with libsomething.so instead of libsomething.a Don't specify it using -l..., specify the .a file just as you were with ld-options. Are you kidding me? cabal unconditionally adds -l to extra-libraries. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -optl behavior in ghc-7.8.1
On Thu, 2014-04-10 at 18:49 +0200, Karel Gardas wrote: On 04/10/14 06:39 PM, Yuras Shumovich wrote: ...and other linker options must come after, like in my case. So what? Are there any ticket where people complain about the old behavior? I'm not advocating any specific behavior, I'm just asking why it was changed. Hmm, I'm not sure if I'm the patch provider, but at least I provided patch which was merged into HEAD (don't have 7.8 branch here so check yourself) which fixes linking of binaries failure on Solaris. Please see b9b94ec82d9125da47c619c69e626120b3e60457 The core of the change is: -else package_hs_libs ++ extra_libs ++ other_flags +else other_flags ++ package_hs_libs ++ extra_libs Thank you for pointing to the commit. I hoped it was incidental change, but now I see the reason. Thanks, Yuras the patch contains full explanation in comment so see it for more information. If this is not what bugs you, then please ignore me. Thanks, Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to start with GHC development?
On Thu, 2012-12-13 at 09:41 +, Chris Nicholls wrote: What's the best way to get started? Bug fixes? Writing a toy plugin? I don't have a huge amount of time to offer, but I would like to learn to help! GHC bug sweep is the way I'm trying to start with: http://hackage.haskell.org/trac/ghc/wiki/BugSweep (have no idea whether it is the best way or not :) ) Thanks, Yuras ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use C-land variable from Cmm-land?
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) = ccall lockClosure(mvar ptr);
}
You should use n_capabilities, not enabled_capabilities. The latter
might be 1, even when there are multiple capabilities actually in use,
while the RTS is in the process of migrating threads.
Could you please elaborate? setNumCapabilities is guarded with
asquireAllCapabilities, so all threads are in scheduler. And threads
will be migrated from disabled capabilities before they get a chance to
put/take mvar.
I changed my mind re enabled_capabilities/n_capabilities a number of
times during the weekend. Most likely you are right, and I should use
n_capabilities. But I'll appreciate if you find time to explain it for
me.
But got no speedup at all.
The generated asm (amd64):
movl $enabled_capabilities,%eax
cmpq $1,%rax
je .Lcgq
.Lcgp:
movq %rbx,%rdi
subq $8,%rsp
movl $0,%eax
call lockClosure
addq $8,%rsp
.Lcgr:
cmpq $stg_MVAR_CLEAN_info,%rax
jne .Lcgu
{...}
.Lcgq:
movq (%rbx),%rax
jmp .Lcgr
It moves enabled_capabilities into %eax and then compares 1 with %rax.
It looks wrong for me: the highest part of %rax remains uninitialized.
As Axel noted, this is correct.
The problem was that movl $enabled_capabilities,%eax loaded the
address of enabled_capabilities, not a value. (Again, why does it use
32bit register? The value is 32bit on linux, but the address is 64bit,
isn't it?) So the correct way to use C-land variable is:
if (CInt[enabled_capabilities]) {...}
Not very intuitive, but at least it works.
Thanks,
Yuras
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to use C-land variable from Cmm-land?
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
First I tried just to replace ccall lockClosure(mvar ptr) with
GET_INFO(mvar) in stg_takeMVarzh and stg_putMVarzh and got 60% speedup
(see the test case at the end.)
Then I changed lockClosure to read header info directly when
enabled_capabilities == 1. The speedup was significantly lower, 20%
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) = ccall lockClosure(mvar ptr);
}
But got no speedup at all.
The generated asm (amd64):
movl $enabled_capabilities,%eax
cmpq $1,%rax
je .Lcgq
.Lcgp:
movq %rbx,%rdi
subq $8,%rsp
movl $0,%eax
call lockClosure
addq $8,%rsp
.Lcgr:
cmpq $stg_MVAR_CLEAN_info,%rax
jne .Lcgu
{...}
.Lcgq:
movq (%rbx),%rax
jmp .Lcgr
It moves enabled_capabilities into %eax and then compares 1 with %rax.
It looks wrong for me: the highest part of %rax remains uninitialized.
(And actually it ignores the highest 32 bits of enabled_capabilities.
That is ok here, but generally wrong.)
The compiler knows that enabled_capabilities is 64bit
(it complains when trying to assign it to bits32 register.)
What do I miss? Any help?
Thanks,
Yuras
-- The test case
import Control.Concurrent
import Control.Monad
main :: IO ()
main = do
var - newMVar ()
replicateM_ 1 $ do
takeMVar var
putMVar var ()
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
