Re: Has ghc-9.0 for windows changed to require installation?
Hi Moritz, Tamar, Ben, Thank you for the detailed explaining. I understood the current status. Ben has opened this: https://gitlab.haskell.org/ghc/ghc/-/issues/19339 Always thanks a lot, Takenobu On Tue, Feb 9, 2021 at 4:24 AM Phyx wrote: > > No, there's no change at all in the portability. > This looks like a fallout from switching from Make to Hadrian. > > ghcii.sh was created as an artifact of make install. Hadrian seems to lack > this step. > > Note that this script is nothing magical, it's just a hack around how signal > handlers in Native windows and Cygwin processes are handled. > > I'm not entirely sure it's still needed with the new I/O manager, however > that's not on yet by default.. > > Anyways support should probably be added to Hadrian. > > Kind regards, > Tamar > > Sent from my Mobile > > On Mon, Feb 8, 2021, 14:43 Moritz Angermann > wrote: >> >> Thanks for flagging this. This would be the opposite direction of what I’ve >> been advocating for. That we get bindists for Linux and macOS that work by >> simply unpacking them. >> >> On Mon, 8 Feb 2021 at 10:05 PM, Takenobu Tani wrote: >>> >>> Hi devs, >>> >>> The ghc-binary for windows needs to `make install` since ghc-9.0 [1]. >>> Is this an intended change? >>> >>> Previously, ghc-8.10.4 binary for windows [2] doesn't need to `make >>> install`. >>> We only expand the tar-file and then we can execute `bin/ghcii.sh`. >>> >>> [1]: >>> https://downloads.haskell.org/ghc/9.0.1/ghc-9.0.1-x86_64-unknown-mingw32.tar.xz >>> [2]: >>> https://downloads.haskell.org/ghc/8.10.4/ghc-8.10.4-x86_64-unknown-mingw32.tar.xz >>> >>> Regards, >>> Takenobu >>> ___ >>> 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
Has ghc-9.0 for windows changed to require installation?
Hi devs, The ghc-binary for windows needs to `make install` since ghc-9.0 [1]. Is this an intended change? Previously, ghc-8.10.4 binary for windows [2] doesn't need to `make install`. We only expand the tar-file and then we can execute `bin/ghcii.sh`. [1]: https://downloads.haskell.org/ghc/9.0.1/ghc-9.0.1-x86_64-unknown-mingw32.tar.xz [2]: https://downloads.haskell.org/ghc/8.10.4/ghc-8.10.4-x86_64-unknown-mingw32.tar.xz Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Reading Guide
Hi Richard, Sebastian Thanks for your comments and advice! I'll try to update dump flags' pages :) Thanks a lot, Takenobu On Sat, Feb 6, 2021 at 12:29 AM Sebastian Graf wrote: > > Hi Takenobu, > > thanks for updating that resource! I know that it was helpful to a couple of > students of mine to get a big picture of GHC. > > I don't have anything to add. There are quite a few more -ddump-* flags for > the different Core passes, but I don't think it's interesting to list all of > them on that slide. > > Greetings, > Sebastian > > Am Fr., 5. Feb. 2021 um 16:09 Uhr schrieb Richard Eisenberg > : >> >> A quick scroll through didn't reveal anything incorrect in my areas of >> expertise. >> >> On the "Dump intermediate languages" slide, you might want to mention these >> flags: >> -fprint-explicit-kinds: print out kind applications >> -fprint-explicit-coercions: print out details of coercions >> -fprint-typechecker-elaboration: print out extra gubbins the type-checker >> inserts >> -fprint-explicit-runtime-reps: don't simplify away RuntimeRep arguments >> >> -ddump-ds-preopt: print out the desugared Core before the very first >> "simple" optimization pass >> >> Thanks for writing & sharing! >> Richard >> >> > On Feb 5, 2021, at 7:05 AM, Takenobu Tani wrote: >> > >> > Dear devs, >> > >> > I've written a simple document about "GHC source reading" for myself >> > and potential newcomers: >> > >> > * https://takenobu-hs.github.io/downloads/haskell_ghc_reading_guide.pdf >> >(https://github.com/takenobu-hs/haskell-ghc-reading-guide) >> > >> > Please teach me if something's wrong. I'll learn and correct them. >> > >> > Happy Haskelling :) >> > >> > Regards, >> > Takenobu >> > ___ >> > 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
GHC Reading Guide
Dear devs, I've written a simple document about "GHC source reading" for myself and potential newcomers: * https://takenobu-hs.github.io/downloads/haskell_ghc_reading_guide.pdf (https://github.com/takenobu-hs/haskell-ghc-reading-guide) Please teach me if something's wrong. I'll learn and correct them. Happy Haskelling :) Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Native Code Generator for AArch64
Steady and wonderful work! Regards, Takenobu On Sat, Sep 26, 2020 at 6:44 PM Moritz Angermann wrote: > > Hi there! > > As some may know I've been working on a native code generation backend for > aarch64[1]. When Ben initially wrote about The state of GHC on ARM[2], I was > quite skeptical if a native code generator would really be what we should be > doing. And the claim it would take a week or two, might have been > underestimating the complexity a bit; but also the time needed to debug > crashing programs. > > The idea of a NCG however intrigued me. I did work on an alternative llvm > backend once, so I did know a bit about the code gen backend. I also knew a > bit about aarch64 assembly from working on the rts linker for aarch64. > > So here we are today, with an aarch64 ncg for ghc[3], that has some basic > optimizations included, but does not beat the llvm codegen yet in runtime > performance. It is however substantially faster than the llvm codegen for > compile time performance. > > I have performed nofib benchmarks for: > - full llvm build vs full native build[4] > - llvm nofib, with native libraries, vs full native build[5] > to discriminate effects of compiling just the nofib programs vs. the impact > the libraries have. > > I've only had time to take a cursory look over the generated assembly for the > CSD test, and the llvm codegen seems to be able to produce quite different > assembly, thus there seem to be some good optimizations llvm manages to > exploit. I'll have to investigate this closer and probably look at the llvm > IR we generate and the intermediate optimization steps llvm manages to apply > to it, as the llvm assembly doesn't ressemble the ncg assembly much. > > I plan to look at aarch64/mach-o and performance over the coming weeks. > > I hope we can get this in for 9.2. > > Cheers, > Moritz > > -- > [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641 > [2]: https://www.haskell.org/ghc/blog/20200515-ghc-on-arm.html > [3]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3641 > [4]: https://gist.github.com/9d93454b832b769b5bdb4e731a10c068 > [5]: https://gist.github.com/acc4dab7836f1f509716ac398a94d949 > ___ > 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: Call for GHC Maintainers
Hi, I always appreciate maintainers' hard works. I'd like to support GHC releases and some tasks. Is there anything that I could do? PS My haskell time is limited to nights and weekends, so my works are slow. (I can't access to haskell community in the day job...) Regards, Takenobu On Tue, Aug 11, 2020 at 11:10 AM Moritz Angermann wrote: > > Hi there! > > As it stands right now, Ben is the one who works tirelessly trying to > cut releases. Not just for the most recent version, but also for > previous versions. Most recently 8.10.2, but we have 9.0 coming up as > well. > > I know that there are some people who deeply care for personal or > professional reasons for older releases, 8.4, 8.6, 8.8, ... Some of > them have stacks of patches applied, or proprietary extensions. I'd > argue that most of those applied patches are backports of bug fixes > and rarely language features, as language features will break > compatibility (due to ghc, base, and other library versions anyway). > > I would therefore like drum up a group of people who will take care > (ideally 2+ per release) of backporting and making minor partch > releases. This does not have to go on forever, but it would take much > needed load off of Ben to focus on what ever happens in ghc HEAD. > > So what would this work actually look like? It would consist of > - going through the list of MRs and tagging those which are relevant > for backporting to a certain release. > - backport MRs where the MR does not cleanly apply. > - fixup any test-suite failures. > - agree on a date to cut/make the release. > > This is not a permanent commitment. I hope we can attract more people > to the ghc release managers. > > I'm looking forward to great many responses. And I'm sure Ben will be > able to help mentor us through cutting the first releases. I'll > volunteer to be part of the 8.6 branch maintainers for now. > > Cheers, > Moritz > > PS: There is a slightly related discussion about release cadence and > versions and how other projects deal with this in this ticket: > https://gitlab.haskell.org/ghc/ghc/-/issues/18222 > ___ > 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: Async exceptions and delimited continuations
Hi Alexis, I prepared a framework page on ghc-wiki about this proposal: * https://gitlab.haskell.org/ghc/ghc/-/wikis/delimited-continuations If it helps, please use the page to share ideas with developers and users. It is a draft page. Please feel free to rewrite all contents as you like. You could also create sub pages. Some similar pages for proposals are here: * https://gitlab.haskell.org/ghc/ghc/-/wikis/linear-types * https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell Regards, Takenobu On Thu, Jul 2, 2020 at 4:13 AM Alexis King wrote: > > Hi all, > > As some of you are likely aware, I have an open GHC proposal[1] to add > native support for delimited continuations to the RTS. I also have an > incomplete implementation,[2] and the only major remaining obstacle > concerns async exceptions. The issue is subtle, so I’ve tried to > provide all the necessary context in this email. If you’re already > familiar with the ideas at play, you can skip the context about how > delimited continuations work. > > For those unfamiliar, delimited continuations allow capturing slices > of the call stack and restoring them later. For example, the program > > do y <- prompt $ do x <- control0 $ \k -> k (pure 10) > pure (x + 5) >print y > > will print 15. To understand what’s happening operationally, we can > imagine an abstract call stack made up of continuation frames: > > ┌──┐ > │ ● + 5 │redex: control0 $ \k -> k (pure 10) > ├──┤ > │ prompt ● │ > ├──┤ > │ print ● │ > ├──┤ > │ ...│ > ├──┤ > > Here, each ● represents the “hole” where the evaluated result of the > redex will be returned. `control0` moves all the frames between the > top of the stack and the first `prompt` into the heap and returns a > reference to them, so after a single reduction step, we have > > ┌──┐ > │ print ● │redex: k1 (pure 10) > ├──┤heap: k1 = ┌──┐ > │ ...││ ● + 5 │ > ├──┤└──┘ > > When a continuation is applied, its stored stack frames are copied > back onto the top of the current stack, and the argument becomes the > new redex: > > ┌──┐ > │ ● + 5 │redex: pure 10 > ├──┤ > │ print ● │ > ├──┤ > │ ...│ > ├──┤ > > Now it should hopefully be clear how we end up printing 15. > > With that context, consider the following expression: > > prompt $ mask_ $ do x <- control0 $ \k -> k (pure 10) > f x > > The call stack at the point of control0 looks very similar in this > program, but now we have a use of `mask_` in there as well: > > ┌──┐ > │ f ●│redex: control0 $ \k -> k (pure 10) > ├──┤exns: masked > │ mask_ ● │ > ├──┤ > │ prompt ● │ > ├──┤ > │ ...│ > ├──┤ > > When capturing the continuation, we’ll unwind the stack the same way > we did before. Because we’re popping mask_ off the stack, we’ll unmask > async exceptions: > > ┌──┐redex: k1 (pure 10) > │ ...│exns: not masked > ├──┤heap: k1 = ┌──┐ > │ f ●│ > ├──┤ > │ mask_ ● │ > └──┘ > > Now when we apply `k1`, we’ll copy the `mask_` frame back onto the > stack, and we must re-mask async exceptions. Otherwise, exceptions > will not be masked during the call to `f`, which would be wrong. > > Why is this a problem? The RTS applies an optimization: if you call > mask_ (actually maskAsyncExceptions#) while exceptions are already > masked, it doesn’t push a new stack frame at all. So, for example, if > you write > > mask_ $ mask_ $ foo bar > > you’ll end up with only one mask_ frame on the call stack, not two. > This tiny optimization actually allows not one but two savings: > > 1. The immediate benefit is that we save a stack frame. > > 2. The hidden benefit is that we never need to push the old >exception masking state onto the stack. > >If we had multiple mask_ frames on the stack simultaneously, we >wouldn’t know what to do when returning: should we unmask them, >or should they stay masked? We’d need to push that information >onto the stack in the same way we must push a return address >when calling a function. > >By skipping these redundant stack frames, we can always be >certain the right thing to do on return is to unmask async >exceptions. No need to store anything else. > > (This explanation is a slight simplification, especially once > maskUninterruptible comes into play, but it’s close enough.) > > Now you may see the looming problem: this strategy completely breaks > do
Re: gitlab.haskell.org spam issues
Thanks always, Ömer, Matthew, Ben :) Regards, Takenobu On Sun, Jan 12, 2020 at 9:10 PM Matthew Pickering wrote: > > There are still *a lot* of spam users though, i'm not sure what we can > do to tackle this. > > On Sun, Jan 12, 2020 at 12:09 PM Ben Gamari wrote: > > > > Takenobu Tani writes: > > > > > They are also in snippets: > > > > > > https://gitlab.haskell.org/explore/snippets > > > > > I have handled these. Thanks Takenobu! > > > > 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: gitlab.haskell.org spam issues
They are also in snippets: https://gitlab.haskell.org/explore/snippets Regards, Takenobu On Sun, Jan 12, 2020 at 7:08 AM Ryan Scott wrote: > > There appears to be an account [1] that is submitting spam as GitLab issues. > I've noticed the following spam issues so far: > > * https://gitlab.haskell.org/ghc/ghc/issues/17664 > * https://gitlab.haskell.org/ghc/ghc/issues/17666 > * https://gitlab.haskell.org/haskell/ghcup/issues/125 > * https://gitlab.haskell.org/haskell/ghcup/issues/127 > * https://gitlab.haskell.org/haskell/ghcup/issues/129 > > Best, > Ryan S. > - > [1] https://gitlab.haskell.org/nunikonaza88 > ___ > 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] Glasgow Haskell Compiler 8.10.1-alpha2 released
Thanks for the release. Will deb9-linux binary be released in the future? Or deb10-linux version only? Perhaps ubuntu18.04LTS users need deb9-linux binary. Regards, Takenobu On Thu, Dec 12, 2019 at 3:28 AM Ben Gamari wrote: > > Hello all, > > The GHC team is happy to announce the availability of the first alpha > release in the GHC 8.10 series. Source and binary distributions are > available at the usual place: > > https://downloads.haskell.org/ghc/8.10.1-alpha2/ > > GHC 8.10.1 will bring a number of new features including: > > * The new UnliftedNewtypes extension allowing newtypes around unlifted >types. > > * The new StandaloneKindSignatures extension allows users to give >top-level kind signatures to type, type family, and class >declarations. > > * A new warning, -Wderiving-defaults, to draw attention to ambiguous >deriving clauses > > * A number of improvements in code generation, including changes > > * A new GHCi command, :instances, for listing the class instances >available for a type. > > * An upgraded Windows toolchain lifting the MAX_PATH limitation > > * A new, low-latency garbage collector. > > * Improved support profiling, including support for sending profiler >samples to the eventlog, allowing correlation between the profile and >other program events > > This release is the second alpha of the 8.10 pre-release cycle. The > release will be a release candidate in roughly three weeks. If all goes > well the final release will be cut roughly two weeks after the > candidate, in mid-January. > > This being an alpha release, there are a few issues that are still > outstanding: > > * The new Alpine Linux binary distribution is not present due to an >apparent correctness issue [1]; any help Alpine users can offer here >would be greatly appreciated. > > * We have yet to sort out compliance with Apple's notarization >requirements [2] which will be likely be necessary for users of >macOS Catalina. > >However, until this has been sorted out Catalina users can exempt the >current macOS binary distribution from the notarization requirement >themselves by running `xattr -cr .` on the unpacked tree before >running `make install`. > > * There is one remaining non-regression correctness issue which we plan >to fix for the final 8.10.1 but that is not fixed in this release. > > Please do test this release and let us know if you encounter any other > issues. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/ghc/ghc/issues/17508 > [2] https://gitlab.haskell.org/ghc/ghc/issues/17418 > ___ > 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: users-guide page for master branch
Thanks for resolving this. The recent master document is displayed. It's useful :) https://ghc.gitlab.haskell.org/ghc/doc/users_guide/ Regards, Takenobu On Wed, Oct 30, 2019 at 10:57 PM Takenobu Tani wrote: > > Thanks for your explanation. > I'll check again after the Windows issue is fixed. > > Thanks, > Takenobu > > On Wed, Oct 30, 2019 at 10:27 PM Ben Gamari wrote: > > > > Indeed, this is because of the fact that the Windows build is currently > > failing due to hsc2hs issues. I have been ignoring the documentation build > > until the Windows issue has been resolved. > > > > Thanks for checking though. Don't hesitate to mention this again if you > > notice the build is still failing after the Windows issue is fixed. > > > > Cheers, > > > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: users-guide page for master branch
Thanks for your explanation. I'll check again after the Windows issue is fixed. Thanks, Takenobu On Wed, Oct 30, 2019 at 10:27 PM Ben Gamari wrote: > > Indeed, this is because of the fact that the Windows build is currently > failing due to hsc2hs issues. I have been ignoring the documentation build > until the Windows issue has been resolved. > > Thanks for checking though. Don't hesitate to mention this again if you > notice the build is still failing after the Windows issue is fixed. > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
users-guide page for master branch
Hi Ben, devs, This is not in hurry. It looks like the users-guide page for master branch [1] has not been updated recently. [1]: https://ghc.gitlab.haskell.org/ghc/doc/users_guide Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: SPAM snippets on GitLab
Thanks for explain me. Next time I'll do it :) Regards, Takenobu On Thu, Oct 3, 2019 at 10:37 PM Ben Gamari wrote: > > Takenobu Tani writes: > > > Hi Ben, devs, > > > > It looks like GHC gitlab snipeets [1] are exposed to spam. > > Could we control them? > > > > [1] https://gitlab.haskell.org/explore/snippets > > > Thanks Takenobu! > > In general feel free to use the "Report Spam" button in the top right > corner of the page when you see something like this. I do periodically > look through the spam report queue and deleting things as necessary > (although admittedly the last time was a few months ago). > > Cheers, > > - Ben ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
SPAM snippets on GitLab
Hi Ben, devs, It looks like GHC gitlab snipeets [1] are exposed to spam. Could we control them? [1] https://gitlab.haskell.org/explore/snippets Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Wiki markup
It may be solved already, but this is supplementary information. As Ryan says, you can adjust it with indents as follows:. * first bit of text ``` <--- Align the number of indent characters code ``` Second bit of text Here is an example of markdown: https://gitlab.haskell.org/ghc/ghc/wikis/sand-box This is the GitLab markdown specification: https://docs.gitlab.com/ee/user/markdown.html#lists Regards, Takenobu On Tue, Jun 4, 2019 at 2:15 AM Ryan Yates wrote: > > Hi Simon, > > I think you can just indent the code block to achieve this. > > Ryan > > On Mon, Jun 3, 2019 at 12:46 PM Simon Peyton Jones via ghc-devs > wrote: >> >> This is a GitLab wiki markup question. >> >> Suppose I want to have a bulleted list, in which a single item has some >> text, then some laid-out code, then more text. I want the second blob of >> text to be indented as part of the bullet. >> >> Absent the laid-out code, indenting the second para 2 spaces seems to do it: >> >> * first bit of text >> >> >> >> Second bit of text >> >> But if there is code in the middle, like this >> >> * first bit of text >> >> ``` >> >> code >> >> ``` >> >> Second bit of text >> >> the second bit of text is not indented. >> >> Does anyone know how to achieve the indentation? >> >> Simon >> >> ___ >> 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: Cmm syntax page on wiki
Thank you so much, I added mutual links about code-gen and rts. I'll tweak some more pages. Regards, Takenobu On Sat, Jun 1, 2019 at 5:20 AM Simon Peyton Jones wrote: > > Really good, thank you. > > Let's make sure it's discoverable. Perhaps from the commentary, in at least > two places: > > The description of code generation: > https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/code-gen > > The runtime system > https://gitlab.haskell.org/ghc/ghc/wikis/commentary/rts > > > And your new page could itself link back to those locations. > > Simon > > | -Original Message- > | From: ghc-devs On Behalf Of Takenobu Tani > | Sent: 31 May 2019 13:04 > | To: ghc-devs > | Subject: Cmm syntax page on wiki > | > | Hi devs, > | > | I wrote a wiki page for Cmm syntax [1] to improve readability for ghc > | developers. > | > | Could you tell me if there are any problems or errors? > | I'll update them or remove the page. > | > | [1]: > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fcommentary%2Fcompiler%2Fcmm- > | syntax&data=02%7C01%7Csimonpj%40microsoft.com%7Ce396859157a54a0567d908 > | d6e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542023339 > | &sdata=4DbAUYWd1bVM%2FDGuNctjBZgmYhCxazKnhGNN1CcLiJM%3D&reserved=0 > | > | Regards, > | Takenobu > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Ce396859157a54a0567d908d6 > | e5c018bc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636949010542033347&a > | mp;sdata=F6SDwM2XoZ3s58gWmzJu0OiMJshsxNxjGAT8AYzjgRI%3D&reserved=0 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Cmm syntax page on wiki
Hi devs, I wrote a wiki page for Cmm syntax [1] to improve readability for ghc developers. Could you tell me if there are any problems or errors? I'll update them or remove the page. [1]: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cmm-syntax Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Question about Gitlab MR workflow.
Hi everyone, Shall I change the link title of "Working conventions" on sidebar [1] to "How to contribute" or "Contributing to GHC" (or else) ? [1]: https://gitlab.haskell.org/ghc/ghc/wikis/home Regards, Takenobu On Fri, May 10, 2019 at 12:50 AM Simon Peyton Jones via ghc-devs wrote: > > Thanks. That page is one click from the "Working conventions" page which is > listed in the sidebar. (I wonder if "Working conventions" is the right > title?) > > The numbering of the "Contributing a patch" page is deeply strange. > 1,2,1,1,1,2,3,4. > > > > | -Original Message- > | From: ghc-devs On Behalf Of David Eichmann > | Sent: 09 May 2019 16:47 > | To: Ben Gamari ; ghc-devs@haskell.org > | Subject: Re: Question about Gitlab MR workflow. > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.h > | askell.org%2Fghc%2Fghc%2Fwikis%2Fworking-conventions%2Ffixing- > | bugs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=NYp8yLUc52uZZWRY > | cMISbebwx5frQBxXCSCHMbElm6s%3D&reserved=0 > | > | On 5/9/19 3:47 PM, Ben Gamari wrote: > | > David Eichmann writes: > | > > | >> I've added a blurb in the wiki page about rebasing MRs: > | >> > | > Which Wiki page specifically? > | > > | > - Ben > | > | -- > | David Eichmann, Haskell Consultant > | Well-Typed LLP, > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well- > | typed.com&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3 > | 008d6d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=aYW0kB6YAKF > | A6g2acauodtQ%2BIHnR5UuZuNQ7AW%2FNRvE%3D&reserved=0 > | > | Registered in England & Wales, OC335890 > | 118 Wymering Mansions, Wymering Road, London W9 2NF, England > | > | ___ > | ghc-devs mailing list > | ghc-devs@haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask > | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=01%7C01%7Csimonpj%40microsoft.com%7C7615e39c98f84ae42e3008d6 > | d495a26d%7C72f988bf86f141af91ab2d7cd011db47%7C1&sdata=37tW3oFiBnCz93Hp > | %2BblddDl35Ac83YpVNDJyk%2Fw9Rtg%3D&reserved=0 > ___ > 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: GHC HEAD documentation once again available
Hi, > The old downloads.haskell.org URL redirects to [2] and consequently should > now always be up-to-date. > [2] https://ghc.gitlab.haskell.org/ghc/doc/ For the following URL, CDN or something seems to be a problem: https://ghc.gitlab.haskell.org/ghc/doc/ It is displayed for the following: "502 Bad Gateway". The build of the document on gitlab seems to be successful. For instance: https://gitlab.haskell.org/ghc/ghc/-/jobs/72818 (I am not in a hurry.) Regards, Takenobu On Sun, Mar 31, 2019 at 9:56 AM Ben Gamari wrote: > > TL;DR. A snapshot of GHC's documentation from the master branch can >always be found at [2]. > > > Hi everyone, > > Quite a while ago I made it a habit of periodically pushing > documentation snapshots from GHC's master branch to > downloads.haskell.org [1]. Unfortunately, despite some attempts at > automating this process, this frequently grew out-of-date. > > I am happy to report that documentation snapshots are now generated > as a product of GHC's CI process and made available here [2]. The old > downloads.haskell.org URL redirects to [2] and consequently should now > always be up-to-date. > > Let me know if you notice anything amiss. > > Cheers, > > - Ben > > > [1] https://downloads.haskell.org/ghc/master/ > [2] https://ghc.gitlab.haskell.org/ghc/doc/ > ___ > 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: GHC user manual
> We might also want to have "GHC User's Guide (master branch)" to be the one > built last > night from master. Or, at least, to have this linked from > somewhere discoverable. I see. What you intend is the master (HEAD) document. I created the sub page for "GHC User's Guide" [1] and linked from the right side-bar on wiki [2]. From that page, I made it possible to find both latest and master. I will brush up this page. [1]: https://gitlab.haskell.org/ghc/ghc/wikis/ghc-users-guide [2]: https://gitlab.haskell.org/ghc/ghc/wikis/home Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC user manual
Hi Simon, > Where is the latest GHC user manual. I tried Here is the latest (ghc-8.6.5) GHC user manual: https://downloads.haskell.org/ghc/latest/docs/html/users_guide > It would be good if it was easy to find the link from the developers home page > https://gitlab.haskell.org/ghc/ghc/wikis/home I added the link to the wiki's right side bar. Could you tell me if your intention is different? P.S. Currently, the link to the HEAD (master) document seems broken. https://ghc.gitlab.haskell.org/ghc/doc/ Regards, Takenobu On Tue, Apr 30, 2019 at 8:20 PM Simon Peyton Jones via ghc-devs wrote: > > Where is the latest GHC user manual. I tried > >https://ghc.gitlab.haskell.org/ghc/doc/ > > but got a 502 failure. > > It would be good if it was easy to find the link from the developers home page > > https://gitlab.haskell.org/ghc/ghc/wikis/home > > Simon > > ___ > 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: Cannot fetch array @ 58a7ea
Hi, Did you clone from gitlab.haskell.org ? Both github.com and git.haskell.org are already old domains. There may be a better way, but I'm cloning like this: -- clone from gitlab $ git clone g...@gitlab.haskell.org:YOUR_NAME/ghc.git -- fix submodules $ mv .gitmodules .gitmodules.org $ sed -e 's/\.\./https:\/\/gitlab.haskell.org\/ghc/' .gitmodules.org > .gitmodules $ git submodule update --init $ git checkout .gitmodules Regards, Takenobu On Thu, Apr 4, 2019 at 8:23 AM autotaker wrote: > Hi devs, > > I pulled ghc gitlab repository by > ``` > git pull --recurse-submodules > ``` > > But it failed with the following error. > ``` > error: Server does not allow request for unadvertised object > 58a7ea0336363b29513164487190f6570b8ea834 > Fetched in submodule path 'libraries/array', but it did not contain > 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit > failed. > ``` > It seems the latest commit `58a7ea` of `array` library is not found on the > server. > Are there any help on this? > > Best, > Taku Terao > ___ > 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: GHC HEAD documentation once again available
Thanks for the explanation. I was able to access the URL. Thank you, Takenobu On Mon, Apr 1, 2019 at 2:55 AM Ben Gamari wrote: > Takenobu Tani writes: > > > Thank you for the useful link. > > > > It may not be related to this, but the following URL is not displayed > > correctly. > > > Thanks for pointing this out. This was due to a configuration mistake > which I had fixed, but apparently the CDN hadn't caught up. I have > purged the affected URL from the CDN so things should be fine now. > > Unfortunately there is no easy way to do a more comprehensive purge so > if there are any other affected URLs we will simply need to purge them > as we find them. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Can't build HEAD with the old build system
Hi, At least I was able to build with old build system in my Ubuntu on Friday. How about trying the following? : $ make maintainer-clean $ ./boot $ ./configure $ make Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC HEAD documentation once again available
Thank you for the useful link. It may not be related to this, but the following URL is not displayed correctly. NG URL: - https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html -> redirect to https://ghc.gitlab.haskell.org/ghc/doc/ OK URL: - https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html - https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?highlight=inline#inline-and-noinline-pragmas Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.6.4 is now available
> I've opened #16398 to track this. We'll try to fix this before 8.8.1. Thanks for doing that! Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.6.4 is now available
Hi, I always appreciate your hard work. Perhaps you may know, but the following html documents are not included in the windows tarball [1]: * doc/html/index.html * doc/html/users_guide/index.html * doc/html/libraries/index.html These files were included in ghc-8.6.3 tarball [2]. These are very useful in offline or slow network environment :) [1]: https://downloads.haskell.org/ghc/8.6.4/ghc-8.6.4-x86_64-unknown-mingw32.tar.xz [2]: https://downloads.haskell.org/ghc/8.6.3/ghc-8.6.3-x86_64-unknown-mingw32.tar.xz Regards, Takenobu On Wed, Mar 6, 2019 at 5:53 AM Ben Gamari wrote: > > Hello everyone, > > The GHC team is very happy to announce the availability of GHC 8.6.4, a > bugfix release in the GHC 8.6 series. The source distribution, binary > distributions, and documentation for this release are available at > > https://downloads.haskell.org/~ghc/8.6.4 > > The 8.6.4 release fixes several regressions present in 8.6.3 including: > > - A regression resulting in segmentation faults on Windows introduced >by the fix for #16071 backported in 8.6.3. This fix has been reverted, >meaning that 8.6.4 is once again susceptible to #16071. #16071 will >be fixed in GHC 8.8.1. > > - A bug resulting in incorrect locking on Darwin, potentially resulting >in hangs at shutdown (#16150) > > - A few bugs in the profiled runtime resulting in the potential for >memory unsafety has been fixed (#15508). > > - The `process` and `transformers` libraries shipped now properly >reflect released Hackage releases (#16199) > > - A bug where TH name resolution would break in a plugin context has >been fixed (#16104) > > - Compilers that do not support TemplateHaskell no longer advertise >such support in `--supported-languages` (#16331) > > As a few of these issues are rather serious users are strongly > encouraged to upgrade. See Trac [1] for a full list of issues resolved > in this release. > > Note that this release ships with one significant but long-standing bug > (#14251): Calls to functions taking both Float# and Double# may result > in incorrect code generation when compiled using the LLVM code generator. > This is not a new issue, it has existed as long as the LLVM code > generator has existed; however, changes in code generation in 8.6 made > it more likely that user code using only lifted types will trigger it. > > Note also that this is the first release cut from our (yet again) > revamped continuous integration infrastructure. While we have done a > great deal of checking to ensure that the build configuration reflects > that of previous releases, do let us know if something looks off. > > Happy compiling! > > Cheers, > > - Ben > > [1] > https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority > ___ > 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: Please update ghc user's guide for GHC 8.6
Despite being busy, thank you so much. P.S. The current version includes "3. Release notes for version 8.4.2" in the top page. Regards, Takenobu On Sat, Oct 6, 2018 at 8:47 AM Ben Gamari wrote: > Takenobu Tani writes: > > > Dear devs, > > > > Would you please update latest document [1] to GHC 8.6 ? > > > I did this earlier this week. Thanks for the ping Takenobu1 > > Cheers, > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Please update ghc user's guide for GHC 8.6
Dear devs, Would you please update latest document [1] to GHC 8.6 ? [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How to use ghc-heap-view of ghc-8.6
Hi, Oh, it's clear to me, ghc-heap and ghc-heap-view. I've misunderstood. Thank you very much, Takenobu 2018-07-07 22:35 GMT+09:00 Joachim Breitner : > Hi, > > Am Samstag, den 07.07.2018, 04:05 + schrieb Patrick Dougherty: > > P.S. Sorry about using [1] so many times. Both libraries are called > > heap-view which makes it a little difficult to distinguish. > > it seems that my hack on hackage is called ghc-heap-view, and the thing > landed in GHC just ghc-heap :-) > > Cheers, > Joachim > > -- > Joachim Breitner > m...@joachim-breitner.de > http://www.joachim-breitner.de/ > > ___ > 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: How to use ghc-heap-view of ghc-8.6
Hi Patrick, thanks. I'll start digging from your great resource. I'll try using ghc-heap-view on GHCi. Interactive usage is also useful. Thank you for your kind explanation, Takenobu 2018-07-07 13:05 GMT+09:00 Patrick Dougherty : > Hello, > > This effort mostly just brought the core of this [1] library into GHC. The > main function you will want to try is `getClosureData`, > which takes any value and returns the heap representation. There are some > tricky aspects about evaluation, but I will refer you to the comments about > `Box`s in [1]. > > As a shameless self-plug, I also wrote a bit about it. The first page is a > brief intro to the heap, and the second is an example demonstrating how to > track down a leaky accumulator. I also link to a few posts that sent me > down this path. > > This doesn't implement all of the functionality of [1], but it pulls in > enough that hopefully it should be a little more stable between GHC > versions. Also, you should be able to recreate many of the functions by > looking at the source of [1] on hackage. > > [1] http://hackage.haskell.org/package/ghc-heap-view-0.5.10/ > docs/GHC-HeapView.html > [2] https://patrickdoc.github.io/heap-view.html > > Best, > Patrick > > P.S. Sorry about using [1] so many times. Both libraries are called > heap-view which makes it a little difficult to distinguish. > > On Friday, July 6, 2018 10:10 PM, Takenobu Tani > wrote: > > > Dear devs, > > I'm interested in ghc-heap-view of ghc-8.6. [1] > Is there a document on how to use the ghc-heap-view of ghc-8.6? > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1# > Landedinmasterbranch > > Regards, > Takenobu > > > ___ > 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
How to use ghc-heap-view of ghc-8.6
Dear devs, I'm interested in ghc-heap-view of ghc-8.6. [1] Is there a document on how to use the ghc-heap-view of ghc-8.6? [1]: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1#Landedinmasterbranch Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Site of ghc.haskell.org is down?
Thank you very much. I can now access the site in both Firefox and Chrome. Regards, Takenobu 2018-04-16 6:32 GMT+09:00 Herbert Valerio Riedel : > Hi *, > > Should be fixed now. Please check. > > -- hvr > > On Sun, Apr 15, 2018 at 7:49 PM, Simon Peyton Jones via ghc-devs > wrote: > > I'm getting this too. > > > > -- > > The owner of ghc.haskell.org has configured their website improperly. > To protect your information from being stolen, Firefox has not connected to > this website. > > > > This site uses HTTP Strict Transport Security (HSTS) to specify that > Firefox may only connect to it securely. As a result, it is not possible to > add an exception for this certificate. > > > > ghc.haskell.org uses an invalid security certificate. The certificate > expired on 15 April 2018, 05:49. The current time is 15 April 2018, 18:48. > Error code: SEC_ERROR_EXPIRED_CERTIFICATE > > > > --- > > > > It'd be great to get this fixed, since it means no one can access GHC's > Trac. > > > > Simon > > > > | -Original Message- > > | From: ghc-devs On Behalf Of David > > | Kraeutmann > > | Sent: 15 April 2018 08:20 > > | To: ghc-devs@haskell.org > > | Subject: Re: Site of ghc.haskell.org is down? > > | > > | It's an issue with the site---the SSL certificate seems to have > expired. > > | > > | > > | On 04/15/2018 02:37 AM, Takenobu Tani wrote: > > | > Hi devs, > > | > > > | > When I accessed `https://ghc.haskell.org/` > > | > <https://ghc.haskell.org/%60>, the following message is displayed: > > | > > > | > Your connection is not secure > > | > > > | > I checked it with Firefox and Chrome. > > | > Is it a matter of site setting? > > | > > > | > Regards, > > | > Takenobu > > | > > > | > > > | > > > | > ___ > > | > 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 > ___ > 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
Site of ghc.haskell.org is down?
Hi devs, When I accessed `https://ghc.haskell.org/`, the following message is displayed: Your connection is not secure I checked it with Firefox and Chrome. Is it a matter of site setting? Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
NumericUnderscores extension was added to Cabal for ghc 8.6
Dear devs, The `NumericUnderscores` extension was added to Cabal for ghc 8.6. [1] I'm sending this mail referring to `BlockArguments`. [2] [1] https://github.com/haskell/cabal/pull/5130 [2] https://mail.haskell.org/pipermail/ghc-devs/2018-February/015341.html Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: The BlockArguments extension has been added to Cabal
Akio, thank you for telling me as well. I will also add `NumericUnderscores` extension to the Cabal library this weekend. Regards, Takenobu 2018-02-05 16:06 GMT+09:00 Akio Takano : > Dear GHC devs, > > The new `BlockArguments` extension has been added to the Cabal library. > > I'm sending out this notification because the Note [Adding a language > extension] in compiler/main/DynFlags.hs asks me to do so. > > Regards, > Takano Akio > ___ > 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 8.2.2 release candidate 1
Hi Ben, devs, Thanks for your hard work! Could you also include the following commits? These are about user's guide. * https://phabricator.haskell.org/D3850 * https://phabricator.haskell.org/D3852 Regards, Takenobu 2017-10-01 20:17 GMT+09:00 Ben Gamari : > > Hello everyone, > > The GHC team is very pleased to announce the first candidate of the > 8.2.2 release of the Glasgow Haskell Compiler. Source and binary > distributions are available at > > https://downloads.haskell.org/~ghc/8.2.2-rc1/ > > Currently there is a slightly reduced set of binary distributions > available; do let me know if there is a missing platform you would like > to see built. > > This is the first of two release candidates leading up the final 8.2.2 > release. This release fixes approximately fifty bugs present in 8.2.1. > See [1] for the full list. > > As always, please report any issues you encounter. > > Happy testing, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/query?status=closed&; > milestone=8.2.2&col=id&col=summary&col=status&col=type& > col=priority&col=milestone&col=component&order=priority > > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Underscore in binary literals
Dear devs, > Thank you very much for the response and kind explanation. > After studying, I will submit to ghc-proposals :) I submitted a ghc-proposal #76 [1]. Please feedback:) [1]: https://github.com/ghc-proposals/ghc-proposals/pull/76 Regards, Takenobu 2017-09-26 23:05 GMT+09:00 Takenobu Tani : > Dear all, > > Thank you very much for the response and kind explanation. > After studying, I will submit to ghc-proposals :) > > Regards, > Takenobu > > > > 2017-09-26 22:56 GMT+09:00 Merijn Verstraaten : > >> I, too, have wished for the ability to have a separator in large number >> literals. >> >> So a strong +1 from me. >> >> Cheers, >> Merijn >> >> > On 26 Sep 2017, at 15:43, Ben Gamari wrote: >> > >> > Takenobu Tani writes: >> > >> >> Hi Rahul, >> >> >> >> Thanks for the explanation. >> >> Hmm, Is not there much need... >> >> >> >> Thank you code example. >> >> I will also look at lexer for my study [1]. >> >> >> > If you do want to try pursuing a language change do feel free to submit >> > a proposal [1]. I would also like the ability to break up large >> > literals. However, why limit it to BinaryLiterals? I would like the same >> > syntax for deciaml and hexadecimal literals as well. >> > >> > Cheers, >> > >> > - Ben >> > >> > >> > [1] https://github.com/ghc-proposals/ghc-proposals >> > ___ >> > 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: Underscore in binary literals
Dear all, Thank you very much for the response and kind explanation. After studying, I will submit to ghc-proposals :) Regards, Takenobu 2017-09-26 22:56 GMT+09:00 Merijn Verstraaten : > I, too, have wished for the ability to have a separator in large number > literals. > > So a strong +1 from me. > > Cheers, > Merijn > > > On 26 Sep 2017, at 15:43, Ben Gamari wrote: > > > > Takenobu Tani writes: > > > >> Hi Rahul, > >> > >> Thanks for the explanation. > >> Hmm, Is not there much need... > >> > >> Thank you code example. > >> I will also look at lexer for my study [1]. > >> > > If you do want to try pursuing a language change do feel free to submit > > a proposal [1]. I would also like the ability to break up large > > literals. However, why limit it to BinaryLiterals? I would like the same > > syntax for deciaml and hexadecimal literals as well. > > > > Cheers, > > > > - Ben > > > > > > [1] https://github.com/ghc-proposals/ghc-proposals > > ___ > > 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: Underscore in binary literals
Hi Rahul, Thanks for the explanation. Hmm, Is not there much need... Thank you code example. I will also look at lexer for my study [1]. [1]: https://phabricator.haskell.org/D22 Thank you :) , Takenobu 2017-09-26 21:58 GMT+09:00 Rahul Muttineni : > Implementation-wise, it's no so difficult to include - the lexer needs to > be tweaked. But it seems like a specialised use-case that will only affect > a minority of users is probably not worthwhile as an extension to the > language/compiler. > > Maybe you can try using OverloadedStrings and implement this as a library? > > ``` > newtype Binary = Binary Integer > deriving Num > > instance IsString Binary where > fromString binaryLiteral = error "Code here to parse binary literal with > underscores" > > binaryVal :: Binary > binaryVal = "1101_1110_0101" > ``` > > Hope that helps, > Rahul > > On Tue, Sep 26, 2017 at 8:40 AM, Takenobu Tani > wrote: > >> Dear devs, >> >> GHC's BinaryLiterals extension is useful. >> (For example, x = 0b110111000101) >> >> Is it difficult to include underscore(_) in the format like >> Verilog-HDL[1] ? >> (For example, x = 0b1101_1100_0101) >> >> [1]: https://inst.eecs.berkeley.edu/~cs150/fa06/Labs/verilog-ieee >> .pdf#page=20 >> >> Regards, >> Takenobu >> >> >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > > > -- > Rahul Muttineni > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Underscore in binary literals
Dear devs, GHC's BinaryLiterals extension is useful. (For example, x = 0b110111000101) Is it difficult to include underscore(_) in the format like Verilog-HDL[1] ? (For example, x = 0b1101_1100_0101) [1]: https://inst.eecs.berkeley.edu/~cs150/fa06/Labs/verilog-ieee.pdf#page=20 Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: GHC Threads affinity
Hi, Here is a simple diagram of forkIO, forkOn and forkOS: https://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=69 Regards, Takenobu 2017-09-11 21:54 GMT+09:00 Michael Baikov : > > >> I'm developing a program that contains several kinds of threads - those > that do little work and sensitive to latency and those that can spend more > CPU time and less latency sensitive. I looked into several cases of > increased latency in those sensitive threads (using GHC eventlog) and in > all cases sensitive threads were waiting for non-sensitive threads to > finish working. I was able to reduce worst case latency by factor of 10 by > pinning all the threads in the program to specific capability but manually > distributing threads (60+ of them) between capabilities (several different > machines with different numbers of cores available) seems very fragile. > World stopping GC is still a problem but at least in my case is much less > frequently so. > > > > If you have a fixed set of threads you might just want to use > -N -qn, and then pin every thread to a different > capability. This gives you 1:1 scheduling at the GHC level, delegating the > scheduling job to the OS. You will also want to use nursery chunks with > something like -n2m, so you don't waste too much nursery space on the idle > capabilities. > > > > Even if your set of threads isn't fixed you might be able to use a > hybrid scheme with -N -qn and pin the high-priority threads > on their own capability, while putting all the low-priority threads on a > single capability, or a few separate ones. > > There's about 80 threads right now and some of them are very short lived. > Most of them are low priority and require lots of CPU which means having to > manually distribute them over several capabilities - this process I'd like > to avoid. > > >> It would be nice to be able to allow GHC runtime to migrate a thread > between a subset of capabilities using interface similar to this one: > >> > >> -- creates a thread that is allowed to migrate between capabilities > according to following rule: ghc is allowed to run this thread on Nth > capability if Nth `mod` size_of_word bit in mask is set. > >> forkOn' :: Int -> IO () -> IO ThreadId > >> forkOn' mask act = undefined > >> > >> This should allow to define up to 64 (32) distinct groups and allow > user to break down their threads into bigger number of potentially > intersecting groups by specifying things like capability 0 does latency > sensitive things, caps 1..5 - less sensitive things, caps 6-7 bulk things. > > > > > > We could do this, but it would add some complexity to the scheduler and > load balancer (which has already been quite hard to get right, I fixed a > handful of bugs there recently). I'd be happy review a patch if you want to > try it though. > > > I guess I'll start by studying the scheduler and load balancer in more > details. Thank you for your input Simon! > > ___ > 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: Status of ircbfowse
Hi Ben, Thank you very much for your kind explanation. I understood the situation. I hope there are people who can help in this field. Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Status of ircbfowse
Dear devs, Does anyone know about the operational status of ircbrowse[1]? Recently, it has been stopped all the time. Did that useful service end? [1]: http://ircbrowse.net/ Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Removing core-spec.pdf from repository?
Hi devs, How about putting it here every release? : https://downloads.haskell.org/~ghc/latest/docs/html/ or https://downloads.haskell.org/~ghc/latest/docs/ `core-spec.pdf` will be helpful. But generating it in Windows is a bit complicated :) Regards, Takenobu 2017-03-14 7:57 GMT+09:00 Ben Gamari : > Hello everyone, > > Currently there is a typeset copy of the Core specification in the GHC > repository. This means any time someone changes the specification the > repository grows by around 300kB. While this isn't the end of the > world, it's generally considered bad form to put generated files under > version control. > > Of course, the tools required to typeset the specification (ott and > LaTeX) are non-trivial to install, so there is considerable convenience > that comes from having a typeset version readily available. > > I suggest that we remove the PDF from the repository but instead I can > start including it in my nightly documentation builds. Any objections? > > 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: Is there a way to avoid time limit when using travis?
Hi Joachim, Thank you for the advice. I'll try to correspond as follows: * To use Travis for simple build check * To use Phab or (slow) local machine for validation * To use Phab for review * To use Github PR for getting advice and confirm I'll enjoy it carefully:) Regards, Takenobu 2017-02-04 12:45 GMT+09:00 Joachim Breitner : > Hi, > > ghc has an exception in place from travis; I fear it does not carry > over to forks. > > If you have commit rights to GHC, you can develop in a branch. > > Maybe a pull request works as well, not sure whether that uses the time > limit of the official repo or yours. Worth a try! Just write tin the PR > that you don not want this to be merged :-) > > Greetings, > Joachim > > > Am Samstag, den 04.02.2017, 11:07 +0900 schrieb Takenobu Tani: > > > > Hi Edward, devs, > > > > Thank you for kind explanation. > > I understood the situation. > > > > Is it common to use paid plans when building GHC [1]? > > > > [1]: https://travis-ci.org/ghc/ghc > > > > Regards, > > Takenobu > > > > > > 2017-02-04 10:41 GMT+09:00 Edward Z. Yang : > > > Even with a paid plan, you only have 120 min to run your build. > > > That might be enough in your case but in Cabal's Travis project > > > I've started playing tricks where I upload the build products > > > somewhere, and then redownload them in a new job before running > > > tests. > > > > > > Edward > > > > > > Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900: > > > > Dear devs, > > > > > > > > Is there a way to avoid time limit when using travis? > > > > > > > > I started using travis [1]. It is very convenient :) > > > > But timeout occurs [2]. > > > > The log messages are as follows: > > > > > > > > => InstEqContext2(normal) 1806 of 5700 [0, 0, 0] > > > > => InstEqContext3(normal) 1807 of 5700 [0, 0, 0] > > > > => InstContextNorm(normal) 1808 of 5700 [0, 0, 0] > > > > The job exceeded the maximum time limit for jobs, and has > > > been > > > > terminated. > > > > > > > > How do you avoid this? > > > > Paid plan or something? > > > > > > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis > > > > [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055 > > > > > > > > Regards, > > > > Takenobu > > > > > > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- > Joachim “nomeata” Breitner > m...@joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nome...@debian.org ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Is there a way to avoid time limit when using travis?
Hi Edward, devs, Thank you for kind explanation. I understood the situation. Is it common to use paid plans when building GHC [1]? [1]: https://travis-ci.org/ghc/ghc Regards, Takenobu 2017-02-04 10:41 GMT+09:00 Edward Z. Yang : > Even with a paid plan, you only have 120 min to run your build. > That might be enough in your case but in Cabal's Travis project > I've started playing tricks where I upload the build products > somewhere, and then redownload them in a new job before running tests. > > Edward > > Excerpts from Takenobu Tani's message of 2017-02-04 10:37:21 +0900: > > Dear devs, > > > > Is there a way to avoid time limit when using travis? > > > > I started using travis [1]. It is very convenient :) > > But timeout occurs [2]. > > The log messages are as follows: > > > > => InstEqContext2(normal) 1806 of 5700 [0, 0, 0] > > => InstEqContext3(normal) 1807 of 5700 [0, 0, 0] > > => InstContextNorm(normal) 1808 of 5700 [0, 0, 0] > > The job exceeded the maximum time limit for jobs, and has been > > terminated. > > > > How do you avoid this? > > Paid plan or something? > > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis > > [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055 > > > > Regards, > > Takenobu > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Is there a way to avoid time limit when using travis?
Dear devs, Is there a way to avoid time limit when using travis? I started using travis [1]. It is very convenient :) But timeout occurs [2]. The log messages are as follows: => InstEqContext2(normal) 1806 of 5700 [0, 0, 0] => InstEqContext3(normal) 1807 of 5700 [0, 0, 0] => InstContextNorm(normal) 1808 of 5700 [0, 0, 0] The job exceeded the maximum time limit for jobs, and has been terminated. How do you avoid this? Paid plan or something? [1]: https://ghc.haskell.org/trac/ghc/wiki/Travis [2]: https://travis-ci.org/takenobu-hs/ghc/builds/197987055 Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: quick building the user's guide
Hi Ben, I see, it is necessary to generate flags. (docs/users_guide/flags-*.rst) Thank you very much for the explanation. Regards, Takenobu 2017-01-29 8:56 GMT+09:00 Ben Gamari : > Takenobu Tani writes: > > > Dear devs, > > > > Can We build the user's guide without building the ghc binary? > > If so, new contributors can easily check the generated html. > > > Sadly no. I would like to make this possible, but currently we rely on > the stage1 ghc library to extract information about flags. > > Cheers, > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
quick building the user's guide
Dear devs, Can We build the user's guide without building the ghc binary? If so, new contributors can easily check the generated html. When I execute the following command, a binary build is always executed. # vi mk/build.mk (BuildFlavour = quick; BUILD_SPHINX_HTML = YES) # ./boot # ./configure # cd docs/users_guide/ # make html Is there a way to skip binary builds? Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Dear devs, I updated diagrams about "Github PR", especially page 11: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Please teach me if I have misunderstood. Regards, Takenobu 2016-11-04 7:36 GMT+09:00 Takenobu Tani : > Hi Ben, > > Thank you so much :) > After I remove "DRAFT" watermark, I'll introduce this PDF to cafe. > > Regards, > Takenobu > > > 2016-11-03 21:20 GMT+09:00 Ben Gamari : > >> Takenobu Tani writes: >> >> > Hi devs, >> > >> > 2016-10-31 20:02 GMT+09:00 Takenobu Tani : >> > >> >> > Also it might be good to add something about the process of fixing >> doc >> >> "bugs" and improving the doc. >> >> > >> >> > I think these are areas where less experienced Haskell developers can >> >> add value and contribute to the >> >> > ghc community. >> >> >> >> Indeed. It's good :) >> >> Update of documents is easy to contribute by new contributors. >> >> I'll understand the document process, then I'll try to draw the >> diagram. >> >> >> > >> > >> > I updated the following: >> > * page 11: add a link for test case >> > * page 12-15: add document flow >> > >> > Here is Rev.2016-Nov-03: >> > GHC development flow >> >http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf >> >https://github.com/takenobu-hs/ghc-development-flow >> > >> > Please teach me if I have misunderstood, especially page 12-15. >> > >> Thanks, this looks great Takenobu! >> >> Cheers, >> >> - Ben >> >> > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Kind page of trac wiki
Hi Simon, Thanks for the reply and explanation. I'll update the kind page and add explanation to refer to page of "LevityPolymorphism". Regards, Takenobu 2017-01-13 22:28 GMT+09:00 Simon Peyton Jones : > Yes, that looks right. But much is in flux with levity polymorphism! > > https://ghc.haskell.org/trac/ghc/wiki/LevityPolymorphism > > > > Thanks. We need people to keep improving the wiki; it tends to get out of > date > > > > Simon > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Takenobu > Tani > *Sent:* 13 January 2017 13:01 > *To:* ghc-devs@haskell.org > *Subject:* Kind page of trac wiki > > > > Dear devs, > > > > May I update Kind page of trac wiki [1] as following ? > > > > - "#" is the kind of unboxed values. Things like Int# have kind #. > > + "#" is the kind of unlifted values. Things like Int# have kind #. > > > > Is this correct? > > > > > > (These pages [2][3] are explained as "unlifted values".) > > > > [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Kinds > > [2]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes > > [3]: https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds > > > > Regards, > > Takenobu > > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Kind page of trac wiki
Dear devs, May I update Kind page of trac wiki [1] as following ? - "#" is the kind of unboxed values. Things like Int# have kind #. + "#" is the kind of unlifted values. Things like Int# have kind #. Is this correct? (These pages [2][3] are explained as "unlifted values".) [1]: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Kinds [2]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes [3]: https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] many haskell's mails are detected as spam on gmail
Hi Arian , Thank you for information. At least from about 11th December, detection of the spam have been increasing. I'll report them after I understand it. Regards, Takenobu 2016-12-25 18:34 GMT+09:00 Arian van Putten : > If I recall correctly it's being worked on. There is a plan to harden the > haskell.org domain during the holidays by introducing DKIM and setting up > DMARC. There is a thread in haskell-cafe titled "[Haskell-cafe] Work on > mail.haskell.org beginning, please report any problems" with more info. > > On Sun, 25 Dec 2016, 09:35 Takenobu Tani, wrote: > > Hi, > > I'm using gmail. > Recently, many haskell's mails are detected as spam on gmail. > (ghc-devs, haskell-cafe, ghc-commit, ...) > > Does anyone know why? > Do you know the workaround? > > Regards, > Takenobu > > ___ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
many haskell's mails are detected as spam on gmail
Hi, I'm using gmail. Recently, many haskell's mails are detected as spam on gmail. (ghc-devs, haskell-cafe, ghc-commit, ...) Does anyone know why? Do you know the workaround? Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
simple diagrams about GHC development flow
Hi cafe, For myself and new contributors, I drew overview diagrams about GHC development flow. GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Let's enjoy :) Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi Ben, Thank you so much :) After I remove "DRAFT" watermark, I'll introduce this PDF to cafe. Regards, Takenobu 2016-11-03 21:20 GMT+09:00 Ben Gamari : > Takenobu Tani writes: > > > Hi devs, > > > > 2016-10-31 20:02 GMT+09:00 Takenobu Tani : > > > >> > Also it might be good to add something about the process of fixing doc > >> "bugs" and improving the doc. > >> > > >> > I think these are areas where less experienced Haskell developers can > >> add value and contribute to the > >> > ghc community. > >> > >> Indeed. It's good :) > >> Update of documents is easy to contribute by new contributors. > >> I'll understand the document process, then I'll try to draw the diagram. > >> > > > > > > I updated the following: > > * page 11: add a link for test case > > * page 12-15: add document flow > > > > Here is Rev.2016-Nov-03: > > GHC development flow > >http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf > >https://github.com/takenobu-hs/ghc-development-flow > > > > Please teach me if I have misunderstood, especially page 12-15. > > > Thanks, this looks great Takenobu! > > Cheers, > > - Ben > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi devs, 2016-10-31 20:02 GMT+09:00 Takenobu Tani : > > Also it might be good to add something about the process of fixing doc > "bugs" and improving the doc. > > > > I think these are areas where less experienced Haskell developers can > add value and contribute to the > > ghc community. > > Indeed. It's good :) > Update of documents is easy to contribute by new contributors. > I'll understand the document process, then I'll try to draw the diagram. > I updated the following: * page 11: add a link for test case * page 12-15: add document flow Here is Rev.2016-Nov-03: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Please teach me if I have misunderstood, especially page 12-15. Thank you, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi George, 2016-10-30 21:49 GMT+09:00 George Colpitts : > Thanks for writing this up. A small suggestion, for the box "Add a test case" > it might be good to add a reference to > https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Adding Thank you for advice. A test case is important, but it is often forgotten. I'll add it to reference. > Also it might be good to add something about the process of fixing doc "bugs" and improving the doc. > > I think these are areas where less experienced Haskell developers can add value and contribute to the > ghc community. Indeed. It's good :) Update of documents is easy to contribute by new contributors. I'll understand the document process, then I'll try to draw the diagram. Thank you, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi Ben, Joachim and devs, I updated the following: * page 7: update "committer flow" to "direct commit" * page 9: add a simple diagram for the various ticket states * page 10: update ghc-proposals flow * page 13: correct "Arcanist" * page 13: add "travis" Here is Rev.2016-Oct-30: GHC development flow http://takenobu-hs.github.io/downloads/ghc_development_flow.pdf https://github.com/takenobu-hs/ghc-development-flow Please teach me if I have misunderstood, especially page 9. Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi Ben, Joachim, 2016-10-30 2:07 GMT+09:00 Ben Gamari : > Nope, that's exactly right. Unfortunately, even "trivial" fixes have a > tendency to break the tree (which has been happening too often recently) > so I'm trying to push contributors to use CI whenever possible. Thank you for explaining me. I understand the reason that you are talking about travis. 2016-10-30 2:59 GMT+09:00 Joachim Breitner : > I see. The term “flow” suggested something deeper or more structured > (which might be good, but is not the case). Maybe relabel it “direct > commit”. Thank you. I'll update the "committer flow" to "direct commit" on page 7. It is more clear about the current situation. Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: simple pictures about GHC development flow
Hi Ben, Joachim, 2016-10-29 1:36 GMT+09:00 Ben Gamari : > > There is a box „committer flow“. What exactly is meant by that? Is > > there more to be said about that? > > > I think this means someone with commit bits simply pushing a patch > without submitting to code review. Ideally we'd be able to deprecate > this workflow in favor of the "auto-validating push" that you've > proposed. I assumed that "committer flow" is simply pushing a patch without submitting to code review or without discussion. I thought committers [1] have the authority in case of typo or small modification. Do I misunderstand? [1]: https://ghc.haskell.org/trac/ghc/wiki/TeamGHC According to your advice, I will update the following: * page 12: correct "Arcanist" * page 9: update ghc-proposals flow * after page 8 (new page 9): add a simple diagram for the various ticket states * page 12: add "travis" Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
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 writes: > > > Hi devs, > > > > 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 > > https://github.com/takenobu-hs/ghc-development-flow > > > Thanks Takenobu! This is quite helpful. > > One minor inaccuracy I found was the spelling of "Arcanist" on page > 12. Another is in the description of the ghc-proposals process on > page 9. Specifically, I think the proposal process should look more > like, > > write the proposal >↓ > pull request >↓ >discussion ←┐ ←──┐ >↓││ > revise proposal ┘│ >↓ │ > request review │ > by steering committee │ >↓ │ >wait for approval ───┘ >↓ > create ticket > > Finally, I think it would be helpful if more attention could be given to > the bug reporting protocol depicted on page 8. In particular, users have > approached me in the past with questions about what the various ticket > states mean. Really, it's (fairly) simple, > > * New: The ticket is waiting for someone to look at it and/or >discussion is underway on how to fix the issue > > * Assigned: Someone has said they are working on fixing the issue. > > * Patch: There is a patch to fix the issue that is awaiting review (it >is typically listed in the "Differential Rev(s)" field of the ticket. > > * Merge: A patch fixing the issue is present in the `master` branch and >we are considering backporting it to the stable branch (e.g. >currently the `ghc-8.0` branch). > > * Closed: As of the release listed in the "Milestone" field the bug is >considered resolved. > > I think a diagram describing this workflow could be quite helpful. Let > me know if I can help. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
simple pictures about GHC development flow
Hi devs, 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 https://github.com/takenobu-hs/ghc-development-flow If I misunderstood something, please teach me. I'll correct or remove them. Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How, precisely, can we improve?
Hi Carter, Thank you, I'm glad to hear it :) Haskell community is beautiful and great. Regards, Takenobu 2016-10-02 3:41 GMT+09:00 Carter Schonwald : > Thank you so much. I know I've said it before. But the slides / notes > you've taken the time to write and circulate before have been truely great. > > How can I and others help encourage you and others to keep up the great > work on that side? > > Good synthesis notes that help orientate new and old contributors for > systems they don't know or have forgotten is a powerful resource. > > I hope my encouragement helps. But either way it's a skill / focus that > takes time to develop and is worth celebrating / thanking. > > As always, happy to be a resource to help, but 👍 to you Takenobu! :) > > > On Saturday, October 1, 2016, Takenobu Tani wrote: > >> Main discussion is here (https://github.com/ghc-propos >> als/ghc-proposals/pull/10). >> >> >> BTW, I prepared a conceptual web page about following. >> >> > Furthermore, we provide a simple search box for multiple wiki sites. >> > (Please wait for a while. I'll prepare simple-conceptual demonstration >> with web.) >> >> >> Here is a rapid prototyping for searching multiple wiki sites. [1] >> >> >> [1]: https://takenobu-hs.github.io/haskell-wiki-search >> >> Regards, >> Takenobu >> >> ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How, precisely, can we improve?
Main discussion is here ( https://github.com/ghc-proposals/ghc-proposals/pull/10). BTW, I prepared a conceptual web page about following. > Furthermore, we provide a simple search box for multiple wiki sites. > (Please wait for a while. I'll prepare simple-conceptual demonstration with web.) Here is a rapid prototyping for searching multiple wiki sites. [1] [1]: https://takenobu-hs.github.io/haskell-wiki-search Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: How, precisely, can we improve?
Dear Moritz, Oh, thank you for teaching me. I'll write to it. Thanks, Takenobu 2016-09-30 20:06 GMT+09:00 Moritz Angermann : > Dear Takenobu, > > may I politely direct you to https://github.com/ghc- > proposals/ghc-proposals/pull/10, > and ask you to add your comments there as well, as that proposal tries to > track these > changes in a central place through the new ghc-proposal process. > > Cheers, > Moritz > > > On Sep 30, 2016, at 6:56 PM, Takenobu Tani > wrote: > > > > Hi, > > > > Richard said: > > (1) search engines still find out-of-date documentation > > (2) the wiki is not discoverable > > > > I know trac is treasure house. > > And I realized old pages are valuable for decision. > > > > > > My concrete suggestion is here: > > > > For (1): > > When we find out-of-date documentation, we directly modify head of the > document. > > We manually insert a comment like "This content is out-of-date for > GHC8.0". > > (New contributors easy can do it.) > > > > For (2): > > We provide manually-written multiple indexes for different views on a > portal page of the wiki site. > > Contributors could maintain each index themselves. > > (New comers will choose his favorite index for his exploring.) > > > > Furthermore, we provide a simple search box for multiple wiki sites. > > (Please wait for a while. I'll prepare simple-conceptual demonstration > with web.) > > > > > > Diversity is strength of Haskell community, > > Takenobu > > > > > > 2016-09-30 4:14 GMT+09:00 Richard Eisenberg : > > I've spent some time thinking about how and what to synthesize from this > conversation. Moritz has captured much of these ideas in the proposal he > submitted. Thanks. > > > > But that proposal tackles only one part of the problem: what to do in > the future. It does not address the insufficiencies of the wiki as it now > stands, and these drawbacks seem to be the dangling fibers of this thread. > Two specific complaints are that (1) search engines still find out-of-date > documentation and (2) the wiki is not discoverable. I agree with both of > these, but I can't think of any (easy) way to help either one. > > > > For (1), the "obvious" solution is to pull old pages. However, old pages > still serve as useful documentary evidence when we need to revisit a > decision made in the past. I think simply deleting out-of-date pages may > lose useful info. Could we remove the pages from the wiki but keep them > somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? > I wouldn't want to keep it somewhere private, lest it be unavailable to the > person that needs it. I think clearly labeling out-of-date info as such is > the best compromise. > > > > For (2), there is an index to the wiki: https://ghc.haskell.org/trac/ > ghc/wiki/TitleIndex It's long and rambly, but may be of use. I agree > that grepping would be nice. Does anyone know if there is a way to extract > plaintext from a Trac wiki? I agree that making such a feature available > would be helpful. In the future, though, even a git-backed collection will > run into discoverability problems, unless someone continually keeps it > organized. (It will be greppable, though.) > > > > As to the point of shoring up existing infra vs. looking more broadly: I > suppose I am interesting in shoring up the existing infra, but I'm > considering "existing infra" to include all the platforms I'm aware of. > This explicitly includes the idea of dropping, say, Trac entirely and > moving exclusively to GitHub. I think that would be a terrible idea, but > it's in scope in my thinking. What's *not* in scope (in my thinking) is the > idea of creating new tools that do exactly what we want. We're all > developers and can imagine wonderful things, but wonderful things do not > come cheaply, and we are but poor. > > > > So I'm at a loss of what to do about these remaining fibers. Concrete > suggestions, anyone? > > > > Richard > > > > -=-=-=-=-=-=-=-=-=-=- > > Richard A. Eisenberg > > Asst. Prof. of Computer Science > > Bryn Mawr College > > Bryn Mawr, PA, USA > > cs.brynmawr.edu/~rae > > > >> On Sep 29, 2016, at 7:37 AM, Takenobu Tani > wrote: > >> > >> Hi Carter, > >> > >> Thank you very much :) > >> > >> We love haskell, > >> Takenobu > >> > >> > >> 2016-09-28 22:29 GMT+09:00 Carter Schonwald >: > >> I like your p
Re: How, precisely, can we improve?
Hi, Richard said: (1) search engines still find out-of-date documentation (2) the wiki is not discoverable I know trac is treasure house. And I realized old pages are valuable for decision. My concrete suggestion is here: For (1): When we find out-of-date documentation, we directly modify head of the document. We manually insert a comment like "This content is out-of-date for GHC8.0". (New contributors easy can do it.) For (2): We provide manually-written multiple indexes for different views on a portal page of the wiki site. Contributors could maintain each index themselves. (New comers will choose his favorite index for his exploring.) Furthermore, we provide a simple search box for multiple wiki sites. (Please wait for a while. I'll prepare simple-conceptual demonstration with web.) Diversity is strength of Haskell community, Takenobu 2016-09-30 4:14 GMT+09:00 Richard Eisenberg : > I've spent some time thinking about how and what to synthesize from this > conversation. Moritz has captured much of these ideas in the proposal he > submitted. Thanks. > > But that proposal tackles only one part of the problem: what to do in the > future. It does not address the insufficiencies of the wiki as it now > stands, and these drawbacks seem to be the dangling fibers of this thread. > Two specific complaints are that (1) search engines still find out-of-date > documentation and (2) the wiki is not discoverable. I agree with both of > these, but I can't think of any (easy) way to help either one. > > For (1), the "obvious" solution is to pull old pages. However, old pages > still serve as useful documentary evidence when we need to revisit a > decision made in the past. I think simply deleting out-of-date pages may > lose useful info. Could we remove the pages from the wiki but keep them > somewhere else, beyond the all-seeing eye of Google? Perhaps -- but where? > I wouldn't want to keep it somewhere private, lest it be unavailable to the > person that needs it. I think clearly labeling out-of-date info as such is > the best compromise. > > For (2), there is an index to the wiki: https://ghc.haskell.org/ > trac/ghc/wiki/TitleIndex It's long and rambly, but may be of use. I > agree that grepping would be nice. Does anyone know if there is a way to > extract plaintext from a Trac wiki? I agree that making such a feature > available would be helpful. In the future, though, even a git-backed > collection will run into discoverability problems, unless someone > continually keeps it organized. (It will be greppable, though.) > > As to the point of shoring up existing infra vs. looking more broadly: I > suppose I am interesting in shoring up the existing infra, but I'm > considering "existing infra" to include all the platforms I'm aware of. > This explicitly includes the idea of dropping, say, Trac entirely and > moving exclusively to GitHub. I think that would be a terrible idea, but > it's in scope in my thinking. What's *not* in scope (in my thinking) is the > idea of creating new tools that do exactly what we want. We're all > developers and can imagine wonderful things, but wonderful things do not > come cheaply, and we are but poor. > > So I'm at a loss of what to do about these remaining fibers. Concrete > suggestions, anyone? > > Richard > > -=-=-=-=-=-=-=-=-=-=- > Richard A. Eisenberg > Asst. Prof. of Computer Science > Bryn Mawr College > Bryn Mawr, PA, USA > cs.brynmawr.edu/~rae > > On Sep 29, 2016, at 7:37 AM, Takenobu Tani wrote: > > Hi Carter, > > Thank you very much :) > > We love haskell, > Takenobu > > > 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > >> I like your perspective on this >> >> >> On Wednesday, September 28, 2016, Takenobu Tani >> wrote: >> >>> Apologies if I’m missing context. >>> >>> >>> Potential contributors need information from wiki. >>> >>> I feel current wiki’s problems are following: >>> >>> >>> (a) reachability >>> >>> "Where is the page I need?" >>> >>> >>> (b) outdated pages >>> >>> "Is this page up-to-date?" >>> >>> >>> (c) update method >>> >>> "How Can I update the page?" >>> >>> >>> >>> About (a): >>> >>> >>> It's difficult to find pages they need. Maybe reasons are following: >>> >>> * We have multiple wiki sites. >>> >>> * Desired contents structure is different for each member. >>> >>> >&
Re: How, precisely, can we improve?
Hi Carter, Thank you very much :) We love haskell, Takenobu 2016-09-28 22:29 GMT+09:00 Carter Schonwald : > I like your perspective on this > > > On Wednesday, September 28, 2016, Takenobu Tani > wrote: > >> Apologies if I’m missing context. >> >> >> >> Potential contributors need information from wiki. >> >> I feel current wiki’s problems are following: >> >> >> >> (a) reachability >> >> "Where is the page I need?" >> >> >> >> (b) outdated pages >> >> "Is this page up-to-date?" >> >> >> >> (c) update method >> >> "How Can I update the page?" >> >> >> >> >> >> About (a): >> >> >> >> It's difficult to find pages they need. Maybe reasons are following: >> >> * We have multiple wiki sites. >> >> * Desired contents structure is different for each member. >> >> >> >> So single wiki site is not enough from latter. >> >> >> >> Therefore, what about "a search system for multiple wiki sites"? >> >> >> >> >> >> About (b): >> >> >> >> Haskell's evolution is fast. >> >> New contributor encounters sometimes outdated pages. >> >> But they don't still know how to correct them. >> >> >> >> Therefore, what about putting "outdated mark" to the page by them? >> >> >> >> They can easily contribute. >> >> And if possible, they send update request with any way. >> >> We’ll preferentially update many requested pages. >> >> >> >> >> >> About (c): >> >> >> >> We have multiple wiki sites. Someone is unfamiliar about them. >> >> Github is one of the solutions for new contents. >> >> But I don't have idea about this for current contents. >> >> >> >> Regards, >> >> Takenobu >> >> >> >> 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : >> >>> I'm quite leery of using a new site (readthedocs.org), as it creates >>> yet another platform for contributors to understand. Reducing the number of >>> platforms has been a fairly clearly-stated goal of these recent >>> conversations, as I've read it. >>> >>> Despite agreeing that wikis are sometimes wonky, I thought of a solid >>> reason against moving: we lose the Trac integration. A Trac wiki page can >>> easily link to tickets and individual comments, and can use dynamic >>> features such as lists of active tickets. These are useful and well-used >>> features. I don't know what's best here, but thinking about the real loss >>> associated with moving away from these features gives me pause. >>> >>> Richard >>> >>> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >>> > >>> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >>> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >>> >>> Yes, I agree with Michael’s observations in the blog post. However, >>> one >>> >>> thing that’s easier about a wiki is that the editing process is much >>> more >>> >>> lightweight than making a PR. >>> >>> >>> >>> But GitHub has a wonderful feature (that I have rarely used) that >>> >>> mitigates this problem. Viewing a file in GitHub offers a little >>> pencil >>> >>> icon in the top-right. It allows you to make arbitrary changes in the >>> >>> file and then automates the construction of a PR. The owner of the >>> file >>> >>> can then accept the PR very, very easily. If the editor has commit >>> >>> rights, you can make your edits into a commit right away. No need to >>> >>> fork, pull and push. >>> >> >>> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >>> >> rendered and inter-linked pages *and* have the option for web-based or >>> >> git-based editing. Though, based on my limited experience with GitHub >>> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >>> > >>> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >>> > tried using GitHub wikis, and found that they were clunkier than just >&
Re: How, precisely, can we improve?
> Therefore, what about "a search system for multiple wiki sites"? sorry, less information. I mean like this. Google search: "dependent haskell site:ghc.haskell.org/trac/ghc/wiki OR site: wiki.haskell.org" Regards, Takenobu 2016-09-28 21:29 GMT+09:00 Takenobu Tani : > Apologies if I’m missing context. > > > > Potential contributors need information from wiki. > > I feel current wiki’s problems are following: > > > > (a) reachability > > "Where is the page I need?" > > > > (b) outdated pages > > "Is this page up-to-date?" > > > > (c) update method > > "How Can I update the page?" > > > > > > About (a): > > > > It's difficult to find pages they need. Maybe reasons are following: > > * We have multiple wiki sites. > > * Desired contents structure is different for each member. > > > > So single wiki site is not enough from latter. > > > > Therefore, what about "a search system for multiple wiki sites"? > > > > > > About (b): > > > > Haskell's evolution is fast. > > New contributor encounters sometimes outdated pages. > > But they don't still know how to correct them. > > > > Therefore, what about putting "outdated mark" to the page by them? > > > > They can easily contribute. > > And if possible, they send update request with any way. > > We’ll preferentially update many requested pages. > > > > > > About (c): > > > > We have multiple wiki sites. Someone is unfamiliar about them. > > Github is one of the solutions for new contents. > > But I don't have idea about this for current contents. > > > > Regards, > > Takenobu > > > > 2016-09-28 10:51 GMT+09:00 Richard Eisenberg : > >> I'm quite leery of using a new site (readthedocs.org), as it creates yet >> another platform for contributors to understand. Reducing the number of >> platforms has been a fairly clearly-stated goal of these recent >> conversations, as I've read it. >> >> Despite agreeing that wikis are sometimes wonky, I thought of a solid >> reason against moving: we lose the Trac integration. A Trac wiki page can >> easily link to tickets and individual comments, and can use dynamic >> features such as lists of active tickets. These are useful and well-used >> features. I don't know what's best here, but thinking about the real loss >> associated with moving away from these features gives me pause. >> >> Richard >> >> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote: >> > >> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote: >> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote: >> >>> Yes, I agree with Michael’s observations in the blog post. However, >> one >> >>> thing that’s easier about a wiki is that the editing process is much >> more >> >>> lightweight than making a PR. >> >>> >> >>> But GitHub has a wonderful feature (that I have rarely used) that >> >>> mitigates this problem. Viewing a file in GitHub offers a little >> pencil >> >>> icon in the top-right. It allows you to make arbitrary changes in the >> >>> file and then automates the construction of a PR. The owner of the >> file >> >>> can then accept the PR very, very easily. If the editor has commit >> >>> rights, you can make your edits into a commit right away. No need to >> >>> fork, pull and push. >> >> >> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely >> >> rendered and inter-linked pages *and* have the option for web-based or >> >> git-based editing. Though, based on my limited experience with GitHub >> >> wikis, I wonder if they would scale to the size of GHC's wiki.. >> > >> > I agree, I don't think GitHub wikis are sufficient for GHC. We've >> > tried using GitHub wikis, and found that they were clunkier than just >> > having wiki / docs in your repo. GHC would probably want to have a >> > separate docs repo, as otherwise the commit history will get filled >> > with commits related to proposals, etc. >> > >> > It may be worth considering a similar approach with the GHC >> > documentation. We've had great success in stack with using >> > https://readthedocs.org/ . The way this works is that you have a >> > branch th
Re: How, precisely, can we improve?
Apologies if I’m missing context.
Potential contributors need information from wiki.
I feel current wiki’s problems are following:
(a) reachability
"Where is the page I need?"
(b) outdated pages
"Is this page up-to-date?"
(c) update method
"How Can I update the page?"
About (a):
It's difficult to find pages they need. Maybe reasons are following:
* We have multiple wiki sites.
* Desired contents structure is different for each member.
So single wiki site is not enough from latter.
Therefore, what about "a search system for multiple wiki sites"?
About (b):
Haskell's evolution is fast.
New contributor encounters sometimes outdated pages.
But they don't still know how to correct them.
Therefore, what about putting "outdated mark" to the page by them?
They can easily contribute.
And if possible, they send update request with any way.
We’ll preferentially update many requested pages.
About (c):
We have multiple wiki sites. Someone is unfamiliar about them.
Github is one of the solutions for new contents.
But I don't have idea about this for current contents.
Regards,
Takenobu
2016-09-28 10:51 GMT+09:00 Richard Eisenberg :
> I'm quite leery of using a new site (readthedocs.org), as it creates yet
> another platform for contributors to understand. Reducing the number of
> platforms has been a fairly clearly-stated goal of these recent
> conversations, as I've read it.
>
> Despite agreeing that wikis are sometimes wonky, I thought of a solid
> reason against moving: we lose the Trac integration. A Trac wiki page can
> easily link to tickets and individual comments, and can use dynamic
> features such as lists of active tickets. These are useful and well-used
> features. I don't know what's best here, but thinking about the real loss
> associated with moving away from these features gives me pause.
>
> Richard
>
> > On Sep 27, 2016, at 5:58 PM, Michael Sloan wrote:
> >
> > On Tue, Sep 27, 2016 at 9:18 AM, Eric Seidel wrote:
> >> On Tue, Sep 27, 2016, at 09:06, Richard Eisenberg wrote:
> >>> Yes, I agree with Michael’s observations in the blog post. However, one
> >>> thing that’s easier about a wiki is that the editing process is much
> more
> >>> lightweight than making a PR.
> >>>
> >>> But GitHub has a wonderful feature (that I have rarely used) that
> >>> mitigates this problem. Viewing a file in GitHub offers a little pencil
> >>> icon in the top-right. It allows you to make arbitrary changes in the
> >>> file and then automates the construction of a PR. The owner of the file
> >>> can then accept the PR very, very easily. If the editor has commit
> >>> rights, you can make your edits into a commit right away. No need to
> >>> fork, pull and push.
> >>
> >> Indeed, GitHub also supports git-backed wikis, so you can have nicely
> >> rendered and inter-linked pages *and* have the option for web-based or
> >> git-based editing. Though, based on my limited experience with GitHub
> >> wikis, I wonder if they would scale to the size of GHC's wiki..
> >
> > I agree, I don't think GitHub wikis are sufficient for GHC. We've
> > tried using GitHub wikis, and found that they were clunkier than just
> > having wiki / docs in your repo. GHC would probably want to have a
> > separate docs repo, as otherwise the commit history will get filled
> > with commits related to proposals, etc.
> >
> > It may be worth considering a similar approach with the GHC
> > documentation. We've had great success in stack with using
> > https://readthedocs.org/ . The way this works is that you have a
> > branch that readthedocs points at ("stable"), which provides the
> > current version to display. I realize that ghc would want to have
> > multiple versions of the docs up, but I'm sure that's feasible.
> >
> > Github itself has pretty nice markdown rendering, and the ability to
> > edit directly. Note that there is no GitHub lock-in here - it is just
> > a collection of markdown files, organized however you like them.
> >
> > The risk with such a migration is that the old wiki(s?) don't get
> > fully migrated and shut down. If that happens, then information will
> > be even more spread out and hard to find. Perhaps we can use pandoc
> > to automatically migrate much of the wiki content to markdown? It
> > probably will not be a lossfree conversion.
> >
> >> There's also a tool called gitit (https://github.com/jgm/gitit) that
> >> seems to offer the same set of features, but apparently with a more
> >> traditional (and I assume customizable) layout.
> >>
> >> I think having the option for simple, immediate edits or peer-reviewed
> >> edits (the peer-review is much more important to me than having an
> >> explicitly file-based system) would be a big win. Perhaps there's even a
> >> trac module that implements something like this? Then we could decouple
> >> it from the question/task of migrating the existing content elsewhere.
> >>
> >> Eric
> >>
Re: [Haskell-cafe] Bikeshedding request for GHCi's :type
Hi Richard, I like your decision and plan. Thank you a lot of work, for community. About new command name for (1): Most users, perhaps, have entered the `:t` rather than `:type`. ghci> :t length In the same way, how about a full name and abbreviation name for (1). For example, we prepare `:type-default` and `:td`. ghci> :td length So they don't misunderstand that it is "typedef". I also like `:type!` and `:types` with Jack :) ghci> :t! length Regards, Takenobu 2016-05-03 5:10 GMT+09:00 Richard Eisenberg : > I have collected feedback gleaned here, on the ticket, and on reddit and > summarized here: > https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type#Summaryoffeedbackaboutthisissue > > That summary includes this concrete proposal: > 1. Ask for concrete suggestions about names for the new commands. > 2. Use these names on my current implementation (which prints out only > one specialization) > 3. Post a feature request looking for more specializations. > > I simply don't have time to specify a design or implement an algorithm for > printing out multiple specializations. Furthermore, my current > implementation meets all specifications proffered for printing out multiple > specializations, for all values of "multiple" that equal 1. It is easy to > extend later. > > Separately, there is a groundswell of support for :doc, but that's beyond > the scope of my work on this point. (I personally would love :doc, too.) > > So, what shall we name the two new commands? > > 1. A new command that specializes a type. (Currently with one > specialization, but perhaps more examples in the future.) > > 2. A new command that preserves specialized type variables so that users > of TypeApplications know what type parameters to pass in next. > > I have suggested :type-def for (1) and :type-spec for (2). I don't > strongly like either. :examples and :inst have been suggested for (1). Any > other ideas? > > Thanks! > Richard > > On Apr 26, 2016, at 9:08 AM, Richard Eisenberg wrote: > > > Hi devs, > > > > Over the weekend, I was pondering the Haskell course I will be teaching > next year and shuddered at having to teach Foldable at the same time as > `length`. So I implemented feature request #10963 ( > https://ghc.haskell.org/trac/ghc/ticket/10963), which allows for a way > for a user to request a specialization of a type. It all works wonderfully, > but there is a real user-facing design issue here around the default > behavior of :type and whether or not to add new :type-y like commands. I > have outlined the situation here: > https://ghc.haskell.org/trac/ghc/wiki/Design/GHCi/Type > > > > I'd love some broad input on this issue. If you've got a stake in how > this all works, please skim that wiki page and comment on #10963. > > > > Thanks! > > Richard > > ___ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [ANNOUNCE] GHC 8.0.1 release candidate 4 available
Hi Ben, Richard and GHC team,
I appreciate your great effort.
The rc4 simply represents `$` type in ghci.
$ ./ghcii.sh
GHCi, version 8.0.0.20160421: http://www.haskell.org/ghc/ :? for help
Prelude> :t ($)
($) :: (a -> b) -> a -> b
Newcomers may love it :)
Thank you very much,
Takenobu
2016-04-28 18:10 GMT+09:00 Ben Gamari :
>
> Hello Haskellers,
>
> The GHC team is happy to announce the availability of fourth release
> candidate of the Glasgow Haskell Compiler's 8.0.1 release. Source and
> binary distributions can be found at,
>
> http://downloads.haskell.org/~ghc/8.0.1-rc4/
>
> This is the last of four candidates leading up to the 8.0.1 release,
> addressing nearly all of the known issues of the previous candidates.
> These include,
>
> * A type-checker panic triggered by use of Typeable on a
> kind-polymorphic type constructor (#11334)
>
> * A type-checker explosion where -XTypeInType would gobble up massive
> amounts of memory when used in a data instance (#11407)
>
> * A variety of other typechecker issues (#11811, #11797, #11813,
> #11814)
>
> * A build issue seen on OS X (#11828)
>
> * Template Haskell can now produce instances with
> OVERLAPP{ING,ABLE,ED} pragmas
>
> * Autoconf has improved version checks for libdw (#11820)
>
> * Typeable and hs-boot files now interact nicely (#11824)
>
> * The build system now checks for the broken Apple `nm` utility
> (#11823, #11744)
>
> * Various issues involving unexpected laziness resulting in exception
> handlers not being invoked (#11555)
>
> * GHC now fails more gracefully when used with an older cabal-install
> release (#11558)
>
> * TypeInType now has proper documentation in the users guide (#11614)
>
> * The story surrounding type `RuntimeRep`s (formerly known as
> `Levity`) is now far better developed, closing several doors to
> unsafe behavior that TypeInType previously opened (#11473, #11723)
>
> * A long-standing bug in the constant-folding rules for `mod` for the
> `Word` type has been resolved (#11702)
>
> * Various issues introduced by OverloadedRecordFields have been fixed
> (#11662, #11401)
>
> * A regression in the typechecker resulting in the rejection of code
> in the `free` and `microlens` packages has been fixed (#11608)
>
> * A bug in the LLVM code generator which caused some programs to emit
> unbuildable LLVM IR has been fixed (#11649)
>
> * A bug where pattern synonyms defined in terms of a pattern match on
> a record would be rejected if the fields weren't written in the same
> order
> as they were defined has been resolved (#11633)
>
> * A bug in the runtime system's treatment of weak references which
> could result in segmentation faults in some cases has been fixed
> (#11108)
>
> * a variety of optimizations improving compiler performance have been
> merged
>
> * and many others
>
> Mac OS X users should be aware that the recent XCode 7.3 release ships
> with a broken `nm` utility which breaks the GHC build (#11744, #11823).
> The build system will check for this condition and request that the tree
> is configured to use the `nm-classic` utility if found. OS X users
> running XCode 7.3 are encouraged to open a ticket with Apple so that
> this issue may be fixed in future XCode releases.
>
> If no major issues pop up we expect that this will be the last release
> candidate before the final release, which we hope to push out in the
> coming weeks. Thanks to everyone who has contributed code, testing,
> builds, and bug reports thusfar!
>
> Cheers and happy testing,
>
> - Ben
>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: New type of ($) operator in GHC 8.0 is problematic
Hi, I know the issue of beginner's Prelude. But how about "profile"? (like H264/MPEG4-AVC profile [1]) * Beginner Profile : beginner's Prelude or ghci beginner's representation mode * Main Profile : Haskell 2010 standard * Leading edge Profile : set of GHC extensions If beginners know exist of profile at first, they may avoid to confuse by step-up? More confused? Already we implicitly have at least two profiles (Haskell2010 and GHC extensions). [1] https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles Regards, Takenobu 2016-02-18 16:45 GMT+09:00 Herbert Valerio Riedel : > On 2016-02-18 at 04:02:24 +0100, Eric Seidel wrote: > > On Wed, Feb 17, 2016, at 08:09, Christopher Allen wrote: > >> I have tried a beginner's Prelude with people. I don't have a lot of > data > >> because it was clearly a failure early on so I bailed them out into the > >> usual thing. It's just not worth it and it deprives them of the > >> preparedness to go write real Haskell code. That's not something I'm > >> willing to give up just so I can teach _less_. > > > > Chris, have you written about your experiences teaching with a > > beginner's Prelude? I'd be quite interested to read about it, as (1) it > > seems like a natural thing to do and (2) the Racket folks seem to have > > had good success with their staged teaching languages. > > > > In particular, I'm curious if your experience is in the context of > > teaching people with no experience programming at all, vs programming > > experience but no Haskell (or generally FP) experience. The Racket "How > > to Design Programs" curriculum seems very much geared towards absolute > > beginners, and that could be a relevant distinction. > > Btw, IMHO it's also interesting to distinguish between teaching > functional programming vs teaching Haskell. > > I've noticed that in the former case, instructors would often prefer a > radically slimmed down standard-library and conceal some of Haskell's > language features not pertinent to their FP curriculum (e.g. typeclasses > or record syntax). > > -- > ___ > 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: New type of ($) operator in GHC 8.0 is problematic
Hi Manuel, > I do worry about the same thing. The Haskell ecosystem is very much geared towards experts and tinkerers (with laudable exceptions, such as, for example, the great work done by Chris Allen). Being an expert and tinkerer that didn’t worry me too much, but lately I am trying to make functional programming and Haskell accessible to a broader audience and it is an uphill battle. Even many professional software developers are put off even trying to install the toolchain. It is not that they wouldn’t been able to do it if they wanted. They just can’t be bothered because they are not convinced of the value of doing so at this stage — exactly as you are saying. > > We should make it easier to get started, not harder. You are thinking deeply. We should find approaches that satisfy the follows: * No surprise for various beginners * No confuse by their step-up * No stress for experts * No prevent GHC(Haskell)'s evolution I like diversity of Haskell community =) Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: New type of ($) operator in GHC 8.0 is problematic
Hi Manuel, > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. > (Num and Show are the typical classes to explain it at.) > As an example, see how we do that in the first chapter of our new Haskell > tutorial: http://learn.hfm.io/first_steps.html This is straightforward and elegance tutorial! I like this. As you know, I'll share one point to list. It's better to assume that "beginners are not only students in universities". Beginners are also engineers, hobbyist, teenager, your friends and your family. Someone of them will touch to Haskell alone and learn with self study in a little bit of knowledge. If they feel complex at first impression in their 1st week, they would go back before they realize beauty of Haskell. Sometimes, I'm worried about it. Regards, Takenobu 2016-02-17 8:05 GMT+09:00 Manuel M T Chakravarty : > > Richard Eisenberg : > > > > On Feb 16, 2016, at 5:35 AM, Ben Gamari wrote: > >> Indeed. I'll just say that I envision that a beginner's prelude would be > >> for learning and nothing more. The goal is that it would be used in the > >> first dozen hours of picking up the language and nothing more. > >> > >> I'd be interested to hear what Richard had in mind when he has time > >> again. > > > > Yes, that's right. And, of course, it doesn't even need to be something > released with GHC. > > > > I hope to have the opportunity to teach intro Haskell in the > not-too-distant future. Maybe even this coming fall. Though I have yet to > look closely at Chris's book, which will be one of the first things I do to > prep, I suspect I'll be writing a custom Prelude for my first few weeks of > the class, eliminating all type-classes. No Foldable, no Monoid, no Num. > And then, by week 3 or 4, bring all that back in. > > As somebody who has taught Haskell to hordes of students (literally, > 1000s), I am not at all convinced that this is going to be helpful. This is > for the following reasons: > > * Students understand the basic idea of overloading for Num, Show, etc > easily (week 1 or 2). We actually tried both doing basic overloading very > early or delaying it until later. The former worked much better. > > * You are not in a position to explain Foldable and probably not Monoid by > week 3 or 4. So, either you need to have more than one beginner Prelude, > delay overloading until much later (awkward), or we are really only talking > about the impact of Show, Num, etc here. > > * Changing things (i.e., one Prelude to another) always confuses some > people — i.e., there is an intellectual cost to all this. > > * Students will want to use Haskell on their own computers. Then, you need > to make sure, they import the right Prelude and that they stop importing > the beginner Prelude when you switch back to the normal one. A certain > percentage of students will mess that up and be confused. > > What we found works best is the following: > > * Introduce the concept of overloading right away. People get that easily, > because they use overloaded arithmetic functions in math, too. (Num and > Show are the typical classes to explain it at.) As an example, see how we > do that in the first chapter of our new Haskell tutorial: > http://learn.hfm.io/first_steps.html > > * Be careful in designing your exercises/assignments (esp early ones), to > make it unlikely for students to run into class related errors. > > Sorry for the mostly off-topic post, but since a beginner’s Prelude was > mentioned here multiple times recently as a countermeasure to making the > real Prelude more complicated, I just want to say, don’t put too much hope > into a ”solution” you never actually tried. > > Manuel > > ___ > 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: New type of ($) operator in GHC 8.0 is problematic
Hi Alexander, > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > For example: > foldr :: (a -> b -> b) -> b -> [a] -> b > foldr :: (a -> b -> b) -> b -> Maybe a -> b > foldr :: (a -> b -> b) -> b -> Identity a -> b > foldr :: (a -> b -> b) -> b -> (c, a) -> b > and more > > It is easy to see a pattern here. The order of the instances used could be the load order, so the ones from Prelude would come first. interesting idea. It's ":t" 's verbose representation mode. The ghci represents true type (not lie) and beginners may intuitively understand the relation between Foldable type class and instances. Beginners will be overcome FTP more easily. > Prelude> :t ($) > ($) :: <"unreadable blurb"> > For example: > ($) :: (a -> b) -> a -> b > ($) :: forall a (b :: #). (a -> b) -> a -> b > > At least one of those lines should be understandable. It's one of the options. But I feel that Levity (or RuntimeRep) is more deep than the type class. They may feel difficult to understand the difference of two patterns in ($). (If it will be long, it's better to separate thread =) ) Regards, Takenobu 2016-02-16 16:28 GMT+09:00 Alexander Kjeldaas : > > > On Fri, Feb 5, 2016 at 2:16 PM, Takenobu Tani > wrote: > >> Hi, >> >> I'll worry about the learning curve of beginners. >> Maybe, beginners will try following session in their 1st week. >> >> ghci> :t foldr >> ghci> :t ($) >> >> They'll get following result. >> >> >> Before ghc7.8: >> >> Prelude> :t foldr >> foldr :: (a -> b -> b) -> b -> [a] -> b >> >> Prelude> :t ($) >> ($) :: (a -> b) -> a -> b >> >> Beginners should only understand about following: >> >> * type variable (polymorphism) >> >> >> After ghc8.0: >> >> Prelude> :t foldr >> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b >> >> > If the output was the following it would be more understandable (and more > encouraging!) > > """ > Prelude> :t foldr > foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b > For example: > foldr :: (a -> b -> b) -> b -> [a] -> b > foldr :: (a -> b -> b) -> b -> Maybe a -> b > foldr :: (a -> b -> b) -> b -> Identity a -> b > foldr :: (a -> b -> b) -> b -> (c, a) -> b > and more > """ > > It is easy to see a pattern here. The order of the instances used could > be the load order, so the ones from Prelude would come first. > > > >> Prelude> :t ($) >> ($) >> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). >>(a -> b) -> a -> b >> >> > I'm not sure how this would work here, but when Levity is *, this should > collapse into the old syntax, so: > > """ > Prelude> :t ($) > ($) :: <"unreadable blurb"> > For example: > ($) :: (a -> b) -> a -> b > ($) :: forall a (b :: #). (a -> b) -> a -> b > """ > > At least one of those lines should be understandable. > > Alexander > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
Hi Ben, Thank you for explanation. Sorry, I was misunderstood that ghc8 changes representation of '*'. (In addition to the Bool, but also Int, Float,..) There are also followings: Alternative f => Monoid (Alt (TYPE Lifted) f a) Functor (Proxy (TYPE Lifted)) Foldable (Const (TYPE Lifted) m) Thank you very much, Takenobu 2016-02-11 21:33 GMT+09:00 Ben Gamari : > Takenobu Tani writes: > > > Hi, > > > > I understood one more point. (I share here.) > > The Prelude library document for ghc 8.0 is already well described for > > beginners/newcomers. > > > > * The ($)'s signature of 8.0.1 is already simple (not include forall > ...). > > * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" > > (changed from '*'). > > > > > > ghc7.8.4 [1]: > > > > data Bool :: * > > foldr :: (a -> b -> b) -> b -> [a] -> b > > ($) :: (a -> b) -> a -> b > > > > > > ghc7.10.4 [2]: > > > > data Bool :: * > > foldr :: (a -> b -> b) -> b -> t a -> b > > ($) :: (a -> b) -> a -> b > > > > > > ghc8.0.1-rc2 [3]: > > > > data Bool :: TYPE Lifted > > To clarify, this isn't actually a change; `*` is merely a synonym for > `TYPE 'Lifted`. > > Moreover, I believe this is a bug. In general we should continue to show > `*` for plain lifted types. If you look at other types in the -rc2 > haddocks you will see that they are indeed rendered as they were in > previous releases, with no kind annotation at all. Bool is likely only > rendered differently as it is a wired-in type; we'll need to fix this. > I've opened #11567 to track this issue. > > Cheers, > > - Ben > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
Hi, I understood one more point. (I share here.) The Prelude library document for ghc 8.0 is already well described for beginners/newcomers. * The ($)'s signature of 8.0.1 is already simple (not include forall ...). * The Bool's kind of 8.0.1 is already represented with "TYPE Lifted" (changed from '*'). ghc7.8.4 [1]: data Bool :: * foldr :: (a -> b -> b) -> b -> [a] -> b ($) :: (a -> b) -> a -> b ghc7.10.4 [2]: data Bool :: * foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b ghc8.0.1-rc2 [3]: data Bool :: TYPE Lifted foldr :: (a -> b -> b) -> b -> t a -> b ($) :: (a -> b) -> a -> b [1] https://downloads.haskell.org/~ghc/7.8.4/docs/html/libraries/base-4.7.0.2/Prelude.html [2] https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0/Prelude.html [3] https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0/Prelude.html Regards, Takenobu 2016-02-08 19:08 GMT+09:00 Takenobu Tani : > Hi Richard and devs, > > What a wonderful (#11549) ! > This is a beautiful solution for beginners/newcomers. > Beginners will not confuse and they can gradually go ahead. > > I extremely appreciate that you are continuously improving the ghc for us. > > Thank you very much, > Takenobu > > > 2016-02-07 0:17 GMT+09:00 Richard Eisenberg : > >> I have made a ticket #11549 ( >> https://ghc.haskell.org/trac/ghc/ticket/11549) requesting a >> -fshow-runtime-rep flag (recalling that the name levity will soon be >> outdated) as described in this thread. I will make sure this gets in for >> the release of 8.0. >> >> Other points: >> >> - You're quite right that (.) could be generalized. But I'll wait for >> someone to really want this. >> >> - I don't have a non-contrived example of the use of ($) with unlifted >> types. It's quite possible that when adding the dirty runST hack, it was >> observed that an unlifted type would be OK. At that point, the type of ($) >> didn't need to become so elaborate. And now we're just trying not to change >> old (but perhaps unrequested) behavior. >> >> - For the record, this debate is entirely unrelated to the runST >> impredicativity hack. (Except, as noted above, perhaps in history.) That >> hack remains, basically unchanged. >> >> - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka wrote: >> > >> > I would call this a simplification rather than a lie. >> >> This is a very convincing argument. >> >> - Thanks, also, for the voice of support. What I love about the Haskell >> community is that we can have an impassioned debate full of strong >> opinions, and it all very rarely devolves into a proper flame war. All the >> posts I've seen in this thread have been constructive and helpful. Thanks. >> >> Richard >> ___ >> Haskell-Cafe mailing list >> haskell-c...@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: [Haskell-cafe] Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
Hi Richard and devs, What a wonderful (#11549) ! This is a beautiful solution for beginners/newcomers. Beginners will not confuse and they can gradually go ahead. I extremely appreciate that you are continuously improving the ghc for us. Thank you very much, Takenobu 2016-02-07 0:17 GMT+09:00 Richard Eisenberg : > I have made a ticket #11549 (https://ghc.haskell.org/trac/ghc/ticket/11549) > requesting a -fshow-runtime-rep flag (recalling that the name levity will > soon be outdated) as described in this thread. I will make sure this gets > in for the release of 8.0. > > Other points: > > - You're quite right that (.) could be generalized. But I'll wait for > someone to really want this. > > - I don't have a non-contrived example of the use of ($) with unlifted > types. It's quite possible that when adding the dirty runST hack, it was > observed that an unlifted type would be OK. At that point, the type of ($) > didn't need to become so elaborate. And now we're just trying not to change > old (but perhaps unrequested) behavior. > > - For the record, this debate is entirely unrelated to the runST > impredicativity hack. (Except, as noted above, perhaps in history.) That > hack remains, basically unchanged. > > - On Feb 6, 2016, at 9:55 AM, Roman Cheplyaka wrote: > > > > I would call this a simplification rather than a lie. > > This is a very convincing argument. > > - Thanks, also, for the voice of support. What I love about the Haskell > community is that we can have an impassioned debate full of strong > opinions, and it all very rarely devolves into a proper flame war. All the > posts I've seen in this thread have been constructive and helpful. Thanks. > > Richard > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Language complexity & beginners (Was: New type of ($) operator in GHC 8.0 is problematic)
;>> think this is an improvement, because now it's not terribly hard to explain:
>>>
>>> ---
>>> 1. Types of kind * have values represented by pointers. This is the vast
>>> majority of data in Haskell, because almost everything in Haskell is boxed.
>>> 2. But sometimes, we don't care how a value is represented. In this
>>> case, we can be polymorphic in the choice of representation, just like
>>> `length` is polymorphic in the choice of list element type.
>>> 3. ($) works with functions whose result can have any representation, as
>>> succinctly stated in the type. Note that the argument to the function must
>>> be boxed, however, because the implementation of ($) must store and pass
>>> the argument. It doesn't care at all about the result, though, allowing for
>>> representation-polymorphism.
>>>
>>> In aid of this explanation, we can relate this all to Java. The
>>> reference types in Java (e.g., Object, int[], Boolean) are all like types
>>> of kind *. The primitive types in Java (int, boolean, char) do not have
>>> kind *. Java allows type abstraction (that is, generics) only over the
>>> types of kind *. Haskell is more general, allowing abstraction over
>>> primitive types via representation polymorphism.
>>> ---
>>>
>>> Could this all be explained to a novice programmer? That would be a
>>> struggle. But it could indeed be explained to an intermediate programmer in
>>> another language just learning Haskell.
>>>
>>> For point of comparison, Java is widely used as a teaching language. And
>>> yet one of the simplest programs is
>>>
>>> public class HelloWorld
>>> {
>>> public static void main(String[] args)
>>> {
>>> System.out.println("Hello, world!");
>>> }
>>> }
>>>
>>> When I taught Java (I taught high-school full time for 8 years), I would
>>> start with something similar to this and have to tell everyone to ignore
>>> 90% of what was written. My course never even got to arrays and `static`!
>>> That was painful, but everyone survived. This is just to point out that
>>> Haskell isn't the only language with this problem. Not to say we shouldn't
>>> try to improve!
>>>
>>> We're in a bit of a bind in all this. We really need the fancy type for
>>> ($) so that it can be used in all situations where it is used currently.
>>> The old type for ($) was just a plain old lie. Now, at least, we're not
>>> lying. So, do we 1) lie, 2) allow the language to grow, or 3) avoid certain
>>> growth because it affects how easy the language is to learn? I don't really
>>> think anyone is advocating for (3) exactly, but it's hard to have (2) and
>>> not make things more complicated -- unless we have a beginners' mode or
>>> other features in, say, GHCi that aid learning. As I've said, I'm in full
>>> favor of adding these features.
>>>
>>> Richard
>>>
>>> On Feb 5, 2016, at 12:55 PM, Kyle Hanson wrote:
>>>
>>> I am also happy the discussion was posted here. Although I don't teach
>>> Haskell professionally, one of the things I loved to do was show people how
>>> simple Haskell really was by inspecting types and slowly putting the puzzle
>>> pieces together.
>>>
>>> Summary of the problem for others:
>>>
>>> From *Takenobu Tani*
>>>
>>> Before ghc7.8:
>>>
>>> Prelude> :t foldr
>>> foldr :: (a -> b -> b) -> b -> [a] -> b
>>>
>>> Prelude> :t ($)
>>> ($) :: (a -> b) -> a -> b
>>>
>>> Beginners should only understand about following:
>>>
>>> * type variable (polymorphism)
>>>
>>>
>>> After ghc8.0:
>>>
>>> Prelude> :t foldr
>>> foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b
>>>
>>> Prelude> :t ($)
>>> ($)
>>> :: forall (w :: GHC.Types.Levity) a (b :: TYPE w).
>>>(a -> b) -> a -> b
>>>
>>>
>>>
>>> With this change it looks like I will no longer be able to keep `$` in
>>> my toolbox since telling a beginner its "magic" goes against what I believe
>>> Haskell is good at, being well defined and easy to understand (Not well
>>> defined in terms of Types but well defined in terms
Re: New type of ($) operator in GHC 8.0 is problematic
Hi,
I'll worry about the learning curve of beginners.
Maybe, beginners will try following session in their 1st week.
ghci> :t foldr
ghci> :t ($)
They'll get following result.
Before ghc7.8:
Prelude> :t foldr
foldr :: (a -> b -> b) -> b -> [a] -> b
Prelude> :t ($)
($) :: (a -> b) -> a -> b
Beginners should only understand about following:
* type variable (polymorphism)
After ghc8.0:
Prelude> :t foldr
foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b
Prelude> :t ($)
($)
:: forall (w :: GHC.Types.Levity) a (b :: TYPE w).
(a -> b) -> a -> b
Beginners should understand about following things, more:
* higher order polymorphism (t m)
* type class (class t =>)
* universal quantification (forall)
* kind (type::kind)
* levity (lifted/unlifted)
I think it's harder in their 1st week.
I tried to draw informal illustrations about Foldable,
but beginners may need ghci-beginner’s mode or something?
Sorry I don't still have good idea.
Of course I like Haskell's abstraction :)
Regards,
Takenobu
2016-02-05 18:19 GMT+09:00 Joachim Breitner :
> Hi,
>
> Am Freitag, den 05.02.2016, 09:22 +0200 schrieb Roman Cheplyaka:
> > On 02/05/2016 01:31 AM, Edward Z. Yang wrote:
> > > I'm not really sure how you would change the type of 'id' based on
> > > a language pragma.
> > >
> > > How do people feel about a cosmetic fix, where we introduce a new
> > > pragma, {-# LANGUAGE ShowLevity #-} which controls the display of
> > > levity
> > > arguments/TYPE. It's off by default but gets turned on by some
> > > extensions like MagicHash (i.e. we only show levity if you have
> > > enabled extensions where the distinction matters).
> >
> > Yes, I am surprised this isn't the way it's been done. The levity
> > arguments should totally be hidden unless requested explicitly.
> >
> > I'd only expect this to be a ghc flag (-fshow-levity), not a language
> > pragma, since it should only affect the way types are /shown/.
>
> shouldn’t this already happen, based on -fprint-explicit-kinds? At
> least I would have expected this.
>
> So we probably either want to make sure that -fno-print-explicit-kinds
> also prevents forall’ed kind variables, or add a new flag of that (heh)
> kind.
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
> m...@joachim-breitner.de • http://www.joachim-breitner.de/
> Jabber: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F
> Debian Developer: nome...@debian.org
>
>
> ___
> 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: May I update Kind page on wiki?
Hi Richard, Thank you for the advice. I'll get a wiki account and update this. I wish you a happy new year =) Regards, Takenobu 2015-12-30 23:51 GMT+09:00 Richard Eisenberg : > Yes, please. Thanks for picking up on this! > > Richard > > On Dec 29, 2015, at 4:55 AM, Takenobu Tani wrote: > > Dear devs, > > Apologies if I'm missing list. > > May I update Kind page on wiki[1] ? > > > In my understanding[2], kind '#' means "unlifted" kind rather than > "unboxed" kind. > If it's right, may I update the wiki[1] for newcomers ? > > I'd like to change the wiki page[1] as following: > > - GHC introduces another inhabited kind, #, for unboxed types. > + GHC introduces another inhabited kind, #, for unlifted types. > > > [1]: https://wiki.haskell.org/Kind > [2]: > https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/types/TyCoRep.hs#L284 > > I wish you a happy new year. > Regards, > Takenobu > > ___ > 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
May I update Kind page on wiki?
Dear devs, Apologies if I'm missing list. May I update Kind page on wiki[1] ? In my understanding[2], kind '#' means "unlifted" kind rather than "unboxed" kind. If it's right, may I update the wiki[1] for newcomers ? I'd like to change the wiki page[1] as following: - GHC introduces another inhabited kind, #, for unboxed types. + GHC introduces another inhabited kind, #, for unlifted types. [1]: https://wiki.haskell.org/Kind [2]: https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/types/TyCoRep.hs#L284 I wish you a happy new year. Regards, Takenobu ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Unlifted data types
Hi devs, Apologies if I'm missing context. Is it more better that "Unlifted" kind is other name, such as "BoxedUnlifted", "Bul", "%",... ? I'm studying Unlifted data types [1]. It's good proposals to optimize code by users. But I worry that newcomers may be confusing about its kind name. In my understanding [2], "unlifted" types may include "unboxed, unlifted" type. But "unlifted" kind does not include "unboxed, unlifted" types. [1]: https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes [2]: http://takenobu-hs.github.io/downloads/haskell_lazy_evaluation.pdf#page=190 (sorry, large) I wish you a happy new year. Regards, Takenobu 2015-09-04 17:03 GMT+09:00 Edward Z. Yang : > Hello friends, > > After many discussions and beers at ICFP, I've written up my current > best understanding of the unlifted data types proposal: > > https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes > > Many thanks to Richard, Iavor, Ryan, Simon, Duncan, George, Paul, > Edward Kmett, and any others who I may have forgotten for crystallizing > this proposal. > > Cheers, > Edward > ___ > 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: Better calling conventions for strict functions (bang patterns)?
Hi, I'm interested in execution performance. Maybe modern hardware (which implement IA64, ARMv8) is able to predict a long chain of jumps [1]. But prediction accuracy for indirect jump is low, especially dynamic addressed indirect jumps. By the way, Ryan's example code will be fast by following optimization: (If c3aX is most fast path, c3aX is reached without taken-branch.) // Skip to the chase if it's already evaluated: start: //if (R2 & 7 != 0) goto fastpath; else goto slowpath; if (R2 & 7 == 0) goto slowpath; // *** (1) remove branch for fastpath fastpath: // Formerly c3aO // *** (1) move fastpath here //if (R1 & 7 >= 2) goto c3aW; else goto c3aX; if (R1 & 7 >= 2) goto c3aW; // *** (2) remove branch for prior path(c3aX) c3aX: // *** (2) move else path to here(without branch) R1 = PicBaseReg + lvl_r39S_closure; call (I64[R1])(R1) args: 8, res: 0, upd: 8; // *** indirect jump, but fixed address (100% hit) c3aW: R1 = P64[R1 + 6] & (-8); call (I64[R1])(R1) args: 8, res: 0, upd: 8; // *** indirect jump, dynamic address (hit or miss) //c3aX: //R1 = PicBaseReg + lvl_r39S_closure; //call (I64[R1])(R1) args: 8, res: 0, upd: 8; slowpath: // Formerly c3aY if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0; c3aZ: // nop R1 = PicBaseReg + foo_closure; call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8; c3b0: I64[Sp - 8] = PicBaseReg + block_c3aO_info; R1 = R2; Sp = Sp - 8; call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8; // Sp bump moved to here so it's separate from "fastpath" Sp = Sp + 8; goto fastpath; // *** //fastpath: // Formerly c3aO //if (R1 & 7 >= 2) goto c3aW; else goto c3aX; //c3aW: //R1 = P64[R1 + 6] & (-8); //call (I64[R1])(R1) args: 8, res: 0, upd: 8; //c3aX: //R1 = PicBaseReg + lvl_r39S_closure; //call (I64[R1])(R1) args: 8, res: 0, upd: 8; [1]: Intel64 and IA-32 Architectures Optimization Reference Manual http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf 3.4 OPTIMIZING THE FRONT END 2.3.2.3 Branch Prediction I'm just studying and drawing about lazy evaluation. This thread is helpful to me :) Regards, Takenobu 2015-10-25 5:53 GMT+09:00 Carter Schonwald : > Doesn't modern hardware have pretty good branch prediction? In which case > the order of the branches may not matter unless it's a long chain of calls? > Vs say an inner loop that hasn't been inlined? > > Either way, I'd love be stay in the loop on this topic, for work I'm > building a strongly normalizing language that supports both strict and call > by need evaluation strategies. > > > On Friday, October 23, 2015, Ryan Newton wrote: > >> >>>1. Small tweaks: The CMM code above seems to be *betting* than the >>>thunk is unevaluated, because it does the stack check and stack write >>>*before* the predicate test that checks if the thunk is evaluated (if >>>(R1 & 7 != 0) goto c3aO; else goto c3aP;). With a bang-pattern >>>function, couldn't it make the opposite bet? That is, branch on whether >>>the thunk is evaluated first, and then the wasted computation is only a >>>single correctly predicted branch (and a read of a tag that we need to >>> read >>>anyway). >>> >>> Oh, a small further addition would be needed for this tweak. In the >> generated code above "Sp = Sp + 8;" happens *late*, but I think it could >> happen right after the call to the thunk. In general, does it seem >> feasible to separate the slowpath from fastpath as in the following tweak >> of the example CMM? >> >> >> * // Skip to the chase if it's already evaluated:* >> * start:* >> * if (R2 & 7 != 0) goto fastpath; else goto slowpath;* >> >> * slowpath: // Formerly c3aY* >> * if ((Sp + -8) < SpLim) goto c3aZ; else goto c3b0;* >> * c3aZ:* >> * // nop* >> * R1 = PicBaseReg + foo_closure;* >> * call (I64[BaseReg - 8])(R2, R1) args: 8, res: 0, upd: 8;* >> * c3b0:* >> * I64[Sp - 8] = PicBaseReg + block_c3aO_info;* >> * R1 = R2;* >> * Sp = Sp - 8;* >> >> * call (I64[R1])(R1) returns to fastpath, args: 8, res: 8, upd: 8;* >> * // Sp bump moved to here so it's separate from "fastpath"* >> * Sp = Sp + 8;* >> >> * fastpath: // Formerly c3aO* >> * if (R1 & 7 >= 2) goto c3aW; else goto c3aX;* >> * c3aW:* >> * R1 = P64[R1 + 6] & (-8);* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> * c3aX:* >> * R1 = PicBaseReg + lvl_r39S_closure;* >> * call (I64[R1])(R1) args: 8, res: 0, upd: 8;* >> >> >> >> > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ ghc-devs mailing list gh
Re: "Excuse me, I think this i my stop..." - Resigning from the Platform
Dear Mark, Thank you for your efforts. You've gave us a lot of opportunity to meet haskell. There are many people on the back side of the firewall. They can't access over the firewall. HP, all-in-one and web downloadable package, is very useful for them. Thanks to you, we were able to enjoy the haskell. Thank you very much, Takenobu 2015-10-13 12:08 GMT+09:00 Mark Lentczner : > I think this is the right time for me to exit: > > The truth is, I still can't bring myself to use a version of Haskell post > the Foldable-Traversable-aPocalypse, let alone some future Haskell after > the changes now in the works. My personal machines are all still 7.8. My > personal projects are all pre-FTP. The Haskell I love to code in, the > Haskell I'm passionate about, the Haskell I've advocated for real world > use, and the Haskell I like to teach, is 7.8, pre-FTP. > > It's not that I'm dead set against change and evolution in a language, or > even breaking changes. But FTP and beyond are changes that have lost the > balance that Haskell had between abstraction and clarity, between elaborate > and practical engineering. I don't see any restraint going forward, so I'm > getting off the train. > > This puts me in an odd position with respect to Haskell Platform: I find > myself building the Platform for a version of Haskell that I don't use. > This isn't healthy for either the Platform or me. Hence, I'm resigning as > release manager. > > I am sad because I believed that Haskell's path to much wider adoption was > within reach. Now, especially with the ramping up of the Haskell Prime > committee, which seems preordained to codify FTP and beyond into standard, > we are approaching our Algol 68 moment: Building a major language revision > with less opportunity than it's predecessor. > > I'll still see you 'round at meet-ups and conferences. I'll just be coding > with an older accent. > > - Mark "mzero" Lentczner > > > ___ > 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: How to stop the thread from yielding per 20ms?
Hi Zhen, Although you might be resolved, there are some information. In your example code, threads are waiting a MVar for each IO(print). (thread switch by self yield rather than timer-based(preemptive) scheduling) Maybe, these information would be helpful. Parallel and Concurrent Programming in Haskell Chapter 7. Basic Concurrency: Threads and MVars http://chimera.labs.oreilly.com/books/123000929/ch07.html The GHC scheduler http://blog.ezyang.com/2013/01/the-ghc-scheduler/ Runtime Support for Multicore Haskell http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/multicore-ghc.pdf Extending the Haskell Foreign Function Interface with Concurrency http://community.haskell.org/~simonmar/papers/conc-ffi.pdf And, ThreadScope and eventlog are here. Parallel and Concurrent Programming in Haskell 15. Debugging, Tuning, and Interfacing with Foreign Code Event Logging and ThreadScope http://chimera.labs.oreilly.com/books/123000929/ch15.html#sec_conc_eventlogging ThreadScope https://wiki.haskell.org/ThreadScope So, few image. http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=82 http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=47 Cheers, Takenobu 2015-07-05 14:10 GMT+09:00 Zhen Zhang : > Hi Ryan, > > Thank for your help. But it turned out to be not working for me. I even > commented out the `startTimer` and `stopTimer` in `rts/Timer.c`, but it > seems not working as well. > > For example. this program: > > main = do > forkIO $ forever $ print “a” > forkIO $ forever $ print “b” > threadDelay 10 > > When I added the `-threaded`, it will schedule normally, despite whether I > commented out some code or add `-V0`. When I dropped `-threaded`, the > `timerManager` stopped working as well, so it doesn’t make sense to me. Bad > luck, but thank you all the way. > > Zhen > > -- > Zhen Zhang > USTC, China > > On July 4, 2015 at 10:08:44 PM, Ryan Yates (fryguy...@gmail.com) wrote: > > Hi Zhen, > > The RTS flag -V sets the tick interval (setting to 0 disables). If you > grep for `RtsFlags.MiscFlags.tickInterval` you can find where it gets > used. Hope this helps. > > Ryan > > On Sat, Jul 4, 2015 at 6:25 AM, Zhen Zhang wrote: > >> Hi, >> >> I am trying to stop the GHC thread scheduler from atomically do >> round-robin scheduling. It might be strange that I am asking for that, in >> fact, my intention is to implement the “Lightweight Concurrency” on top of >> current RTS system. I am trying to use `GHC.Event`’s timeout mechanism to >> interfere with the scheduling behavior and it seems working a bit. But the >> automatic scheduling at the same time by RTS renders this effort invalid. >> >> For this part, I have tried to modify `rts/Scheduler.c`, masked some >> `startTimer` in `schedule()`, change the `appendToQueue` to `pushOnQueue` >> in `scheduleHandleYield` but nothing really works. (The GHC is still doing >> RR scheduling, even I changed some key code I thought) >> >> So I am curious if anyone familiar with the RTS could give me some >> suggestions on this problem. >> >> Thanks a lot! >> >> Zhen >> >> >> >> ___ >> 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: [Haskell-cafe] Consecutive FFI calls
Hi David,
Interesting.
I don't have an answer, but I write few things.
Your case is:
* consecutive FFI calls
* on the same Haskell Thread
Consecutive FFI call cases are:
(1) do { safe_ffiCall1; safe_ffiCall2 }
(2) do { safe_ffiCall1; unsafe_ffiCall2 }
(3) do { unsafe_ffiCall1; safe_ffiCall2 }
(4) do { unsafe_ffiCall1; unsafe_ffiCall2 }
I think at least answer is 'no' with case (4).
There are no memory barrier between unsafe_ffiCall1 and 2.
And apologies if I'm missing context.
Although a haskell thread can migrate to a different OS thread at any point,
you can put a memory barrier primitive (like "mfence" instruction [1][2][3])
at each target points before or after each ffi calls.
Of course, it's expensive if you put for each ffi calls.
And you should abstract from cpu hardware.
(I found useful explicit memory barrier api[4].)
I feel that the _exact_ memory barrier on out-of-order cpu,
multi core, memory mapped IO, ... is very expensive.
It's only satisfy by explicit "hardware memory barrier mechanism".
And it's difficult that exact memory barrier satisfy all case
by the combination of some implicit mechanism.
BTW, does it truly need memory barrier?
Also C language, exact memory barrier is expensive.
And, Maybe, ghc-devs are very busy to ship ghc7.10.2 :-)
[1]: Chapter 8.2,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf
[2]: MFENCE,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-system-programming-manual-325384.pdf
[3]: Chapter 7.5.5,
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
[4]: https://hackage.haskell.org/package/atomic-primops
Cheers,
Takenobu
2015-06-02 22:26 GMT+09:00 David Turner :
> Hi Takenobu,
>
> My question is more about consecutive FFI calls on the same Haskell
> thread, of which there are I suppose 8 cases in your model: the thread
> is {unbound,bound}, the first call is {safe,unsafe} and the second is
> {safe,unsafe}. If the thread is bound, there's no problem as the two
> calls happen on the same OS thread. No memory barriers are needed. If
> the thread is unbound, the two calls may occur on distinct OS threads.
> Although the first call must have returned before the second is made,
> it doesn't immediately follow that there has been a memory barrier in
> between. I'm not sure it matters whether either call is safe or
> unsafe. As a Haskell thread can migrate to a different OS thread at
> any point, I don't think it's possible to put appropriate memory
> barriers in the source.
>
> I've been looking at the GHC source and commentary and believe the
> answer is 'yes', but can anyone from ghc-dev comment on the following?
>
> If a Haskell thread moves to a different OS thread then
> yieldCapability() will at some point be called. This function normally
> calls ACQUIRE_LOCK, which is either pthread_mutex_lock() or
> EnterCriticalSection() in the threaded runtime (on Linux and Win32
> respectively). It looks like both of these count as full memory
> barriers. I think in the (rare) case where yieldCapability() only does
> a GC and then exits, the fact that it's always called in a loop means
> that eventually *some* Task or other emits a memory barrier.
>
> Thanks in advance,
>
> David
>
>
>
>
>
>
>
>
> On 30 May 2015 at 04:10, Takenobu Tani wrote:
> > Hi David,
> >
> > I'm not 100% sure, especially semantics, and I'm studying too.
> > I don't have an answer, but I describe the related matters in order to
> > organize my head.
> >
> > At first:
> > "memory barrier" ... is order control mechanism between memory
> accesses.
> > "bound thread" ... is association mechanism between ffi calls and a
> > specified thread.
> >
> > And:
> > "memory barrier" ... is depend on cpu hardware architecture(x86, ARM,
> > ...).
> > "OS level thread" ... is depend on OS(Linux, Windows, ...).
> >
> > Last:
> > There are four cases about ffi call [1]:
> > (1) safe ffi call on unbound thread(forkIO)
> > (2) unsafe ffi call on unbound thread(forkIO)
> > (3) safe ffi call on bound thread(main, forkOS)
> > (4) unsafe ffi call on bound thread(main, forkOS)
> >
> > I think, maybe (2) and (4) have not guarantee with memory ordering.
> > Because they might be inlined and optimized.
> >
> > If (1) and (3) always use pthread api (or memory barrier api) for
> thread/HEC
> > context swit
Re: [Haskell-cafe] Consecutive FFI calls
Hi David, I'm not 100% sure, especially semantics, and I'm studying too. I don't have an answer, but I describe the related matters in order to organize my head. At first: "memory barrier" ... is order control mechanism between memory accesses. "bound thread" ... is association mechanism between ffi calls and a specified thread. And: "memory barrier" ... is depend on cpu hardware architecture(x86, ARM, ...). "OS level thread" ... is depend on OS(Linux, Windows, ...). Last: There are four cases about ffi call [1]: (1) safe ffi call on unbound thread(forkIO) (2) unsafe ffi call on unbound thread(forkIO) (3) safe ffi call on bound thread(main, forkOS) (4) unsafe ffi call on bound thread(main, forkOS) I think, maybe (2) and (4) have not guarantee with memory ordering. Because they might be inlined and optimized. If (1) and (3) always use pthread api (or memory barrier api) for thread/HEC context switch, they are guarantee. But I think that it would not guarantee the full case. I feel that order issues are very difficult. I think order issues can be safely solved by explicit notation, like explicit memory barrier notation, STM,... If I have misunderstood, please teach me :-) [1]: http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=98 Cheers, Takenobu 2015-05-29 1:24 GMT+09:00 David Turner : > Hi, > > If I make a sequence of FFI calls (on a single Haskell thread) but > which end up being called from different OS threads, is there any kind > of ordering guarantee given? More specifically, is there a full memory > barrier at the point where a Haskell thread migrates to a new OS > thread? > > Many thanks, > > David > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
Hi Herbert, Thank you for your directions. I will send the pull-request after checking the file. Thank you, Takenobu 2015-02-17 22:02 GMT+09:00 Herbert Valerio Riedel : > On 2015-02-17 at 13:47:50 +0100, Takenobu Tani wrote: > > I modified System/Process/Internals.hs locally and build on MinGW 32bit. > > Then I was successful to build on 32bit Windows 7. > > > > Shall I write a bug report on trac or any? or ghc7.10.1.rc2 will not > > support 32 bit Windows? > > Please file a pull-request at https://github.com/haskell/process > > I'm somewhat surprised this wasn't noticed before(?) > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: ANNOUNCE: GHC 7.10.1 Release Candidate 2
Hi, I modified System/Process/Internals.hs locally and build on MinGW 32bit. Then I was successful to build on 32bit Windows 7. Shall I write a bug report on trac or any? or ghc7.10.1.rc2 will not support 32 bit Windows? Change part is the following: diff -u ghc-7.10.0.20150123/libraries/process/System/Process/ Internals.hs.org ghc-7.10.0.20150123/libraries/process/System/Process/Internals.hs --- ghc-7.10.0.20150123/libraries/process/System/Process/Internals.hs.org 2015-01-19 21:37:52 +0900 +++ ghc-7.10.0.20150123/libraries/process/System/Process/Internals.hs 2015-02-17 13:50:31 +0900 @@ -469,6 +469,9 @@ endDelegateControlC :: ExitCode -> IO () endDelegateControlC _ = return () +stopDelegateControlC :: IO () +stopDelegateControlC = return () + foreign import ccall unsafe "runInteractiveProcess" c_runInteractiveProcess :: CWString Regards, Takenobu 2015-02-13 19:35 GMT+09:00 Takenobu Tani : > Hi, > > Does ghc7.10rc2 support for windows 32bit OS (Windows 7) ? > > I tried to build ghc7.10rc2 [1],[2] on my old 32bit windows to check FTP. > Then, the following error has occurred: > > > "C:/MinGW/msys/1.0/home/my/devel/haskell.build.mingw/work8.ghc.7.10.rc2/ghc-7.10.0.20150123/inplace/mingw/bin/ld.exe" > -r -o > libraries/directory/dist-install/build/HSdirec_3OAebvWY9YTGrbhfMGQ0ml.o > libraries/directory/dist-install/build/System/Directory.o > libraries/directory/dist-install/build/cbits/directory.o > "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H64m > -O0 -fasm-this-package-key proce_9HgSaudU0TAKauLzQHuwnO > -hide-all-packages -i -ilibraries/process/. > -ilibraries/process/dist-install/build > -ilibraries/process/dist-install/build/autogen > -Ilibraries/process/dist-install/build > -Ilibraries/process/dist-install/build/autogen -Ilibraries/process/include >-optP-include > -optPlibraries/process/dist-install/build/autogen/cabal_macros.h > -package-key Win32_Cjc5QN7bEuvL7SrTr96E5g -package-key > base_469rOtLAqwTGFEOGWxSUiQ -package-key deeps_FT5iVCELxOr62eHY0nbvnU > -package-key direc_3OAebvWY9YTGrbhfMGQ0ml -package-key > filep_1vDJvPDP7mkAk0dVCj6gws -Wall -XHaskell2010 -O -fasm > -no-user-package-db -rtsopts -odir > libraries/process/dist-install/build -hidir > libraries/process/dist-install/build -stubdir > libraries/process/dist-install/build -c > libraries/process/./System/Process/Internals.hs -o > libraries/process/dist-install/build/System/Process/Internals.o > > libraries\process\System\Process\Internals.hs:36:5: > Not in scope: <81>estopDelegateControlC<81>f > Perhaps you meant one of these: > <81>estartDelegateControlC<81>f (line 467), > <81>eendDelegateControlC<81>f (line 470) > make[1]: *** > [libraries/process/dist-install/build/System/Process/Internals.o] Error 1 > make: *** [all] Error 2 > > > > I looks like 'stopDelegateControl' is not defined in > System\Process\Internals.hs for mingw32_HOST_OS. > > > [1]: > https://downloads.haskell.org/~ghc/7.10.1-rc2/ghc-7.10.0.20150123-src.tar.bz2 > [2]: > https://downloads.haskell.org/~ghc/7.10.1-rc2/ghc-7.10.0.20150123-windows-extra-src.tar.bz2 > > > Regards, > Takenobu > > > > > > 2015-01-27 9:13 GMT+09:00 Austin Seipp : > >> We are pleased to announce the second release candidate for GHC 7.10.1: >> >> https://downloads.haskell.org/~ghc/7.10.1-rc2/ >> >> This includes the source tarball and bindists for 64bit/32bit Linux >> and Windows. Binary builds for other platforms will be available >> shortly. (CentOS 6.5 binaries are not available at this time like they >> were for 7.8.x). These binaries and tarballs have an accompanying >> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >> >> We plan to make the 7.10.1 release sometime in February of 2015. >> >> Please test as much as possible; bugs are much cheaper if we find them >> before the release! >> >> -- >> Regards, >> >> Austin Seipp, Haskell Consultant >> Well-Typed LLP, http://www.well-typed.com/ >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/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.1 Release Candidate 2
Hi, Does ghc7.10rc2 support for windows 32bit OS (Windows 7) ? I tried to build ghc7.10rc2 [1],[2] on my old 32bit windows to check FTP. Then, the following error has occurred: "C:/MinGW/msys/1.0/home/my/devel/haskell.build.mingw/work8.ghc.7.10.rc2/ghc-7.10.0.20150123/inplace/mingw/bin/ld.exe" -r -o libraries/directory/dist-install/build/HSdirec_3OAebvWY9YTGrbhfMGQ0ml.o libraries/directory/dist-install/build/System/Directory.o libraries/directory/dist-install/build/cbits/directory.o "inplace/bin/ghc-stage1.exe" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm-this-package-key proce_9HgSaudU0TAKauLzQHuwnO -hide-all-packages -i -ilibraries/process/. -ilibraries/process/dist-install/build -ilibraries/process/dist-install/build/autogen -Ilibraries/process/dist-install/build -Ilibraries/process/dist-install/build/autogen -Ilibraries/process/include -optP-include -optPlibraries/process/dist-install/build/autogen/cabal_macros.h -package-key Win32_Cjc5QN7bEuvL7SrTr96E5g -package-key base_469rOtLAqwTGFEOGWxSUiQ -package-key deeps_FT5iVCELxOr62eHY0nbvnU -package-key direc_3OAebvWY9YTGrbhfMGQ0ml -package-key filep_1vDJvPDP7mkAk0dVCj6gws -Wall -XHaskell2010 -O -fasm -no-user-package-db -rtsopts -odir libraries/process/dist-install/build -hidir libraries/process/dist-install/build -stubdir libraries/process/dist-install/build -c libraries/process/./System/Process/Internals.hs -o libraries/process/dist-install/build/System/Process/Internals.o libraries\process\System\Process\Internals.hs:36:5: Not in scope: <81>estopDelegateControlC<81>f Perhaps you meant one of these: <81>estartDelegateControlC<81>f (line 467), <81>eendDelegateControlC<81>f (line 470) make[1]: *** [libraries/process/dist-install/build/System/Process/Internals.o] Error 1 make: *** [all] Error 2 I looks like 'stopDelegateControl' is not defined in System\Process\Internals.hs for mingw32_HOST_OS. [1]: https://downloads.haskell.org/~ghc/7.10.1-rc2/ghc-7.10.0.20150123-src.tar.bz2 [2]: https://downloads.haskell.org/~ghc/7.10.1-rc2/ghc-7.10.0.20150123-windows-extra-src.tar.bz2 Regards, Takenobu 2015-01-27 9:13 GMT+09:00 Austin Seipp : > We are pleased to announce the second release candidate for GHC 7.10.1: > > https://downloads.haskell.org/~ghc/7.10.1-rc2/ > > This includes the source tarball and bindists for 64bit/32bit Linux > and Windows. Binary builds for other platforms will be available > shortly. (CentOS 6.5 binaries are not available at this time like they > were for 7.8.x). These binaries and tarballs have an accompanying > SHA256SUMS file signed by my GPG key id (0x3B58D86F). > > We plan to make the 7.10.1 release sometime in February of 2015. > > Please test as much as possible; bugs are much cheaper if we find them > before the release! > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
