sync-all
Herbert says (in bold font) do not ever use sync-all, in this post http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/. If that's really true, we should either nuke it altogether, or change it to do something correct. The idea that it might set up your tree in subtly different ways is alarming. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
On 10/02/2014 08:49 AM, Simon Peyton Jones wrote: Herbert says (in bold font) do not ever use sync-all, in this post http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/. If that's really true, we should either nuke it altogether, or change it to do something correct. The idea that it might set up your tree in subtly different ways is alarming. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs This is news to me, I always use sync-all get sync-all pull when I have to… I'd appreciate if such things were announced on lists rather than a comment on reddit somewhere… -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
On 2014-10-02 at 09:49:11 +0200, Simon Peyton Jones wrote:
Herbert says (in bold font) do not ever use sync-all, in this post
http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contains_1088_todos_please/.
If that's really true, we should either nuke it altogether, or change
it to do something correct. The idea that it might set up your tree
in subtly different ways is alarming.
To clarify what I mean by that:
For users just wanting to clone ghc.git now and just wanting to keep
their tree updated, I'd recommend doing the following one-shot
convenience configuration setup (see [1] for more details):
git config --global alias.pullall '!f(){ git pull $@ git submodule
update --init --recursive; }; f'
And then clone simply via
git clone --recursive http://ghc.haskell.org/ghc.git
(or use https:// or git:// or whatever) and to keep the tree simply use
git pullall --rebase
(`pullall` just saves you from having to call
`git pull`+`git submodule update --init` yourself)
In contrast, `sync-all` is a multi-step process:
1.) you need to clone ghc.git,
2.) then you have a sync-all, which when called
will `git submodule init` (which doesn't yet download the
submodules)
3.) rewrites the fetch-urls in each initialised submodule
4.) finally calls `git submodule update` to fetch the submodule and
checkout the commits registered in ghc.git
The difference become apparent when wanting to use github instead; my
recommended approach is to use the URL rewriting feature of GitHub which
even allows you to easily switch between git.haskell.org and github.com
with a single command, or in its simpler form (as described on [2]):
Only needed once, and idempotent setup step:
git config --global url.git://github.com/ghc/packages-.insteadOf
git://github.com/ghc/packages/
And then just as before:
git clone --recursive git://github.com/ghc/ghc
So long story short; I've mostly got a bad gut feeling recommending to
use a 1000-line Perl script
http://git.haskell.org/ghc.git/blob/HEAD:/sync-all
to accomplish what the 2 `git config` commands and the the day-to-day
`git` commands I mentioned in this email can do in a more Git-idiomatic
way.
So I'm not saying `sync-all` is doing something wrong, but rather that's
overly complex for the task at hand, and we've had support issues with
`sync-all` due to subtle bugs in it (just check the git history for
sync-all to see the tweaks we needed). Moreover, IMHO, if someone's
already proficient with Git, telling them to use `sync-all` will rather
confuse than help as it's not that transparent what it really does.
[1]:
https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#UsingaGitalias
[2]: https://ghc.haskell.org/trac/ghc/wiki/Newcomers
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Herbert, you are still not making the case for why we are keeping it. In fact, you are doing quite the opposite! The wiki[0] appears to no longer tell you to use sync-all when obtaining sources, however, it seems sync-all is still to be used when making local clones -- why? The sync-all entry[1] on the wiki says that you normally don't need it anymore. What does this mean? What abnormal situations are there where we need to use it? [0] https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources [1] https://ghc.haskell.org/trac/ghc/wiki/Building/SyncAll - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQtC6UACgkQRtClrXBQc7WubAEAqX+yflipFfpYDBdTm8pO1+Oe 9i/yxmIB6vzFl0Hf1PsA/iaiNXyxoy0O0lCTCB6u500CywvPq4GA8Ieg0PucBizB =VU62 -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I just realised I might have answered my last question with the observation that you're supposed to use it for local clones. But further clarification would still be appreciated. Thanks. - -- Alexander alexan...@plaimi.net https://secure.plaimi.net/~alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQtC/EACgkQRtClrXBQc7XnlQD/blKknLWHDHf0BWF2zcKrePnC i0dVPPDkAx5F43+6blYA/0C1xz7JyU6wAwMvo9OKyDVM4kV9GdX/egbunxuehKK3 =lS6d -END PGP SIGNATURE- ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cabal directory structure under /libraries/ for a lib that uses Rts.h
Well, which library should it be part of? Add it to the exposed-modules list there and it should get compiled. It's not only a get it compiled problem, even if I add it to base or some other lib and get it compiled, it's failing with a undefined reference linker error. I'm trying to use a function from `rts/RtsFlags.c`. I can define the function elsewhere but I still link it with `RtsFlags.c` because I'm using `RtsFlags` from that file. Any ideas? --- Ömer Sinan Ağacan http://osa1.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: sync-all
Herbert Valerio Riedel wrote: So I'm not saying `sync-all` is doing something wrong, but rather that's overly complex for the task at hand, and we've had support issues with `sync-all` due to subtle bugs in it (just check the git history for sync-all to see the tweaks we needed). Moreover, IMHO, if someone's already proficient with Git, telling them to use `sync-all` will rather confuse than help as it's not that transparent what it really does. So why not turn the current 1000 line Perl script with two lines of shell script and some comments? Erik (who uses sync-all because he didn't know any better) -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Feedback request for #9628 AST Annotations
After further discussion with Neil Mitchell arouund this, I have pushed an
update through to https://phabricator.haskell.org/D297.
It introduces one data structure per annotation, and allows the user to
look up based on the SrcSpan of the annotated AST element and th expected
annotation type.
On Wed, Oct 1, 2014 at 6:37 PM, Neil Mitchell ndmitch...@gmail.com wrote:
I was getting a bit lost between the idea and the implementation. Let
me try rephrasing the idea in my own words.
The goal: Capture inner source spans in AST syntax nodes. At the
moment if ... then ... else ... captures the spans [if [...] then
[...] else [...]]. We want to capture the spans for each keyword as
well, so: [{if} [...] {then} [...] {else} [...]].
The proposal: Rather than add anything to the AST, have a separate
mapping (SrcSpan,AstCtor) to [SrcSpan]. So you give in the SrcSpan
from the IfThenElse node, and some token for the IfThenElse
constructor, and get back a list of IfThenElse for the particular
keyword.
I like the proposal because it adds nothing inside the AST, and
requires no fresh invariants of the AST. I dislike it because the
contents of that separate mapping are highly tied up with the AST, and
easy to get out of sync. I think it's the right choice for three
reasons, 1) it is easier to try out and doesn't break the AST, so we
have more scope for changing our minds later; 2) the same technique is
able to represent things other than SrcSpan without introducing a
polymorphic src span; 3) the people who pay the complexity are the
people who use it, which is relatively few people.
That said, as a tweak to the API, rather than a single data type for
all annotations, you could have:
data AnnIfThenElse = AnnIfThenElse {posIf, posThen, posElse :: SrcSpan}
data AnnDo = AnnDo {posDo :: SrcSpan}
Then you could just have an opaque Map (SrcSpan, TypeRep) Dynamic,
with the invariant that the TypeRep in the key matches the Dynamic.
Then you can have: getAnnotation :: Typeable a = Annotations -
SrcSpan - Maybe a. I think it simplifies some of the TypeRep trickery
you are engaging in with mkAnnKey.
Thanks, Neil
On Wed, Oct 1, 2014 at 5:06 PM, Simon Peyton Jones
simo...@microsoft.com wrote:
Let me urge you, once more, to consult some actual heavy-duty users of
these
proposed facilities. I am very keen to avoid investing design and
implementation effort in facilities that may not meet the need.
If they end up acclaiming the node-key idea, then we should surely simply
make the key an abstract type, simply an instance of Hashable, Ord, etc.
Simon
From: Alan Kim Zimmerman [mailto:alan.z...@gmail.com]
Sent: 30 September 2014 19:48
To: Simon Peyton Jones
Cc: Richard Eisenberg; Edward Z. Yang; ghc-devs@haskell.org
Subject: Re: Feedback request for #9628 AST Annotations
On further reflection of the goals for the annotation, I would like to
put
forward the following proposal for comment
Instead of physically placing a node-key in each AST Node, a virtual
node key can be generated from any `GenLocated SrcSpan e' comprising a
combination of the `SrcSpan` value and a unique identifier from the
constructor for `e`, perhaps using its `TypeRep`, since the entire AST
derives Typeable.
To further reduce the intrusiveness, a base Annotation type can be
defined that captures the location of noise tokens for each AST
constructor. This can then be emitted from the parser, if the
appropriate flag is set to enable it.
So
data ApiAnnKey = AK SrcSpan TypeRep
mkApiAnnKey :: (Located e) - ApiAnnKey
mkApiAnnKey = ...
data Ann =
| AnnHsLetSrcSpan -- of the word let
SrcSpan -- of the word in
| AnnHsDo SrcSpan -- of the word do
And then in the parser
| 'let' binds 'in' exp { mkAnnHsLet $1 $3 (LL $ HsLet (unLoc
$2)
$4) }
The helper is
mkAnnHsLet :: Located a - Located b - LHsExpr RdrName - P (LHsExpr
RdrName)
mkAnnHsLet (L l_let _) (L l_in _) e = do
addAnnotation (mkAnnKey e) (AnnHsLet l_let l_in)
return e;
The Parse Monad would have to accumulate the annotations to be
returned at the end, if called with the appropriate flag.
There will be some boilerplate in getting the annotations and helper
functions defined, but it will not pollute the rest.
This technique can also potentially be backported to support older GHC
versions via a modification to ghc-parser.
https://hackage.haskell.org/package/ghc-parser
Regards
Alan
On Tue, Sep 30, 2014 at 2:04 PM, Alan Kim Zimmerman
alan.z...@gmail.com
wrote:
I tend to agree that this change is much too intrusive for what it
attempts
to do.
I think the concept of a node key could be workable, and ties in to the
approach I am taking in ghc-exactprint [1], which uses a SrcSpan together
with node type
Re: Feedback request for #9628 AST Annotations
Ok, report back 24 hrs after a Haskell Cafe email [1] and reference to it on Reddit [2]. The Reddit post has 16 upvotes and no downvotes. The Haskell Cafe post generated two reponses, one from Andrew Gibiansky (IHaskell,ghc-parser), and one from Mateusz Kowalczyk (Haddock,yi,GHC), both in favour. Neil Mitchell (hlint) has also expressed support on this mailing list. And of course the most enthusiastic user is me, as it will simplify HaRe dramatically. [1] http://www.haskell.org/pipermail/haskell-cafe/2014-October/116267.html [2] http://www.reddit.com/r/haskell/comments/2i0jo8/haskellcafe_ghc_710_ghcapi_changes_and_proposed/ On Wed, Oct 1, 2014 at 7:44 PM, Simon Peyton Jones simo...@microsoft.com wrote: Let me urge you, once again, to consult users. I really do not want to implement a feature that (thus far) lacks a single enthusiastic user. Please. Simon *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* 01 October 2014 16:13 *To:* Simon Peyton Jones *Cc:* Richard Eisenberg; Edward Z. Yang; ghc-devs@haskell.org *Subject:* Re: Feedback request for #9628 AST Annotations I have put up a new diff at https://phabricator.haskell.org/D297 It is just a proof of concept at this point, to check if the approach is acceptable. This is much less intrusive, and only affects the lexer/parser, in what should be a transparent way. The new module ApiAnnotation was introduced because it needs to be imported by Lexer.x, and I was worried about another circular import cycle. It does also allow the annotations to be defined in a self-contained way, which can then easily be used by other external projects such as ghc-parser. If there is consensus that this will not break anything else, I would like to go ahead and add the rest of the annotations. Regards Alan On Tue, Sep 30, 2014 at 11:19 AM, Simon Peyton Jones simo...@microsoft.com wrote: I'm anxious about it being too big a change too. I'd be up for it if we had several customers all saying yes, this is precisely what we need to make our usage of the GHC API far far easier. With enough detail so we can understand their use-case. Otherwise I worry that we might go to a lot of effort to solve the wrong problem; or to build a solution that does not, in the end, work for the actual use-case. Another way to tackle this would be to ensure that syntax tree nodes have a node-key (a bit like their source location) that clients could use in a finite map, to map node-key to values of their choice. I have not reviewed your patch in detail, but it's uncomfortable that the 'l' parameter gets into IfGblEnv and DsM. That doesn't smell right. Ditto DynFlags/HscEnv, though I think here that you are right that the hooks interface is very crucial. After all, the WHOLE POINT is too make the client interface more flexible. I would consult Luite and Edsko, who were instrumental in designing the new hooks interface https://ghc.haskell.org/trac/ghc/wiki/Ghc/Hooks (I'm not sure if that page is up to date, but I hope so) A good way to proceed might be to identify some of the big users of the GHC API (I'm sure I don't know them all), discuss with them what would help them, and share the results on a wiki page. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Richard Eisenberg | Sent: 30 September 2014 03:04 | To: Edward Z. Yang | Cc: ghc-devs@haskell.org | Subject: Re: Feedback request for #9628 AST Annotations | | I'm only speaking up because Alan is specifically requesting feedback: | I'm really ambivalent about this. I agree with Edward that this is a | big change and adds permanent noise in a lot of places. But, I also | really respect the goal here -- better tool support. Is it worthwhile | to do this using a dynamically typed bit (using Typeable and such), | which would avoid the noise? Maybe. | | What do other languages do? Do we know what, say, Agda does to get | such tight coupling with an editor? Does, say, Eclipse have such a | chummy relationship with a Java compiler to do its refactoring, or is | that separately implemented? Haskell/GHC is not the first project to | have this problem, and there's plenty of solutions out there. And, | unlike most other times, I don't think Haskell is exceptional in this | regard (there's nothing very special about Haskell's AST, maybe beyond | indentation-awareness), so we can probably adopt other solutions | nicely. | | Richard | | On Sep 29, 2014, at 8:58 PM, Edward Z. Yang ezy...@mit.edu wrote: | | Excerpts from Alan Kim Zimmerman's message of 2014-09-29 13:38:45 | -0700: | 1. Is this change too big, should I scale it back to just update | the | HsSyn structures and then lock it down to Located SrcSpan for all | the rest? | | I don't claim to speak for the rest of the GHC developers, but I | think | this
dropWhileEndLE breakage
What's going on here? No other library module defines this function, except in Cabal! Simon libraries\base\GHC\Windows.hs:124:16: Not in scope: 'dropWhileEndLE' Perhaps you meant 'dropWhileEnd' (imported from Data.OldList) libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/Windows.o' failed ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: dropWhileEndLE breakage
(Replying to ghc-devs@ as well.) - Yes, you're quite right. I think a part of the original diff was actually missing. Please update/rebase your tree. I've reverted this in d6d5c127b86dc186b25add2843cb83fc12e72a85 On Thu, Oct 2, 2014 at 2:48 PM, Simon Peyton Jones simo...@microsoft.com wrote: What’s going on here? No other library module defines this function, except in Cabal! Simon libraries\base\GHC\Windows.hs:124:16: Not in scope: ‘dropWhileEndLE’ Perhaps you meant ‘dropWhileEnd’ (imported from Data.OldList) libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/Windows.o' failed ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs -- 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
Re: Building ghc on Windows with msys2
Hi, All we need is someone to act as convenor/coordinator and we are good to go. Would any of you be willing to play that role? Indeed, the next thing I was going to ask was about expediting the decision process. I would be happy to try and coordinate a push in Windows matters. There is a caveat though: I don't have any skin in the GHC-on-Windows game, so I will want to move on to other things afterwards. An advantage of having a working group is that you can *decide* things. At the moment people often wait for GHC HQ to make a decision, and end up waiting a long time. It would be better if a working group was responsible for the GHC-on-Windows build and then if (say) you want to mandate msys2, you can go ahead and mandate it. Well, obviously consult ghc-devs for advice, but you are in the lead. Does that make sense? Sounds great. The question still remains about making changes to code: is there a particular person with commit rights that we could lean on for code reviews and committing changes to the main repository? I think an early task is to replace what Neil Mitchell encountered: FIVE different wiki pages describing how to build GHC on Windows. We want just one! (Others can perhaps be marked “out of date/archive” rather than deleted, but it should be clear which is the main choice.) Indeed, it's a bit of a mess. I intended to shape up the msys2 page to serve as the default, but wanted to see more testing done before before dropping the other pages. I agree with using msys2 as the main choice. (I’m using it myself.) It may be that Gintautas’s page https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 is already sufficient. Although I’d like to see it tested by others. For example, I found that it was CRUCIAL to set MSYSYSTEM=MINGW whereas Gintautas’s page says nothing about that. Are you sure that is a problem? The page specifically instructs to use the msys64_shell.bat script (through a shortcut) that is included in msys2, and that script takes care of setting MSYSTEM=MINGW64, among other important things. Other small thoughts: ·We started including the ghc-tarball stuff because when we relied directly on the gcc that came with msys, we kept getting build failures because the gcc that some random person happened to be using did not work (e..g. they had a too-old or too-new version of msys). By using a single, fixed gcc, we avoided all this pain. Makes sense. Just curious: why is this less of a problem on GNU/Linux distros compared to msys2? Does msys2 see comparatively less testing, or is it generally more bleeding edge? ·I don’t know what a “rubenvb” build is, but I think you can go ahead and say “use X and Y in this way”. The important thing is that it should be reproducible, and not dependent on the particular Cygwin or gcc or whatever the that user happens to have installed. A rubenvb build is one of the available types of prebuilt binary packages of mingw for Windows. Let's figure out if there is something more mainstream and if we can migrate to that. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Windows build broken (again)
Sigh. The testsuite fails utterly on Windows, with thousands of identical errors = tc012(normal) 3039 of 4088 [1, 2677, 88] cd .\typecheck\should_compile 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc012.hs -fno-warn-incomplete-patterns tc012.comp.stderr 21 sh: line 0: cd: .typecheckshould_compile: No such file or directory Compile failed (status 256) errors were: *** unexpected failure for tc012(normal) Presumably this is some kind of Windows escape-character problem. But it has worked fine for years, so what is going on? It's very tiresome dealing with Windows breakage so frequently. A few regression test failures, maybe, but outright breakage is very bad. Simon ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build broken (again)
We need to get a windows build not up for phabricator that stops breaking changes from getting submitted. On Oct 2, 2014 10:40 PM, Simon Peyton Jones simo...@microsoft.com wrote: Sigh. The testsuite fails utterly on Windows, with thousands of identical errors = tc012(normal) 3039 of 4088 [1, 2677, 88] cd .\typecheck\should_compile 'C:/code/HEAD/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c tc012.hs -fno-warn-incomplete-patterns tc012.comp.stderr 21 sh: line 0: cd: .typecheckshould_compile: No such file or directory Compile failed (status 256) errors were: *** unexpected failure for tc012(normal) Presumably this is some kind of Windows escape-character problem. But it has worked fine for years, so what is going on? It’s very tiresome dealing with Windows breakage so frequently. A few regression test failures, maybe, but outright breakage is very bad. Simon ___ 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
Re: Building ghc on Windows with msys2
I'm sure we could make git handle the tarballs, but it just seems like the wrong tool for the job. We'd have to use multiple advanced features of git where a simple wget/curl would do. Versioning is also a moot point, since we would embed versions in filenames. In fact, versioning would be easier and nicer when the filenames with versions are in a file on the main repository rather than in a submodule. I was thinking of performing the wget (if necessary) in the Makefile, to further bring down the number of steps that users have to execute for a working build. Any strong objections? Whom should I contact to get some static files deployed in a folder under haskell.org? On Mon, Sep 29, 2014 at 11:40 AM, Thomas Miedema thomasmied...@gmail.com wrote: 3. Why is ghc-tarballs a git repository? That does not seem very wise. [...] Could we have a stable folder under haskell.org/ to put the files in, to make sure that they never go away, and just wget/curl them from there? http://thread.gmane.org/gmane.comp.lang.haskell.ghc.devel/4883/focus=4887 Hmm, that was a while ago. Whom should I contact to get the files deployed under haskell.org? Here's a different solution to the 'big binary blobs' problem: * Keep the ghc-tarballs git repository, and add it as a submodule * Make sure it doesn't get cloned by default git config -f .gitmodules submodule.ghc-tarballs.update none * Windows developers run (after initial clone --recursive of the ghc repository, one time): git config submodule.ghc-tarballs.update checkout git submodule update --depth=1 * After that, windows developers run the normal: git submodule update The advantages are: * only the most recent ghc-tarballs commit gets cloned initially * subsequent 'git submodule update' runs will make sure always the most recent version of ghc-tarballs is available * full history of ghc-tarballs is tracked, easier bisecting * no extra scripts needed I don't know how much space overhead git adds. wget-ting just the files themselves might still be faster. -- Gintautas Miliauskas ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Windows build broken (again)
On Thu, Oct 2, 2014 at 4:39 PM, Simon Peyton Jones simo...@microsoft.com wrote: Presumably this is some kind of Windows escape-character problem. But it has worked fine for years, so what is going on? At a guess, something that was using / is now using \ and getting eaten by the shell. Or quoting that was preventing the \s from being eaten has been lost somewhere. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cabal directory structure under /libraries/ for a lib that uses Rts.h
Oh, in this case, it's likely because we're not actually exporting the symbol. Check Linker.c, esp the calls to SymI_HasProto. Edward Excerpts from Ömer Sinan Ağacan's message of 2014-10-02 02:34:35 -0700: Well, which library should it be part of? Add it to the exposed-modules list there and it should get compiled. It's not only a get it compiled problem, even if I add it to base or some other lib and get it compiled, it's failing with a undefined reference linker error. I'm trying to use a function from `rts/RtsFlags.c`. I can define the function elsewhere but I still link it with `RtsFlags.c` because I'm using `RtsFlags` from that file. Any ideas? --- Ömer Sinan Ağacan http://osa1.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: dropWhileEndLE breakage
Simon Peyton Jones asked What's going on here? No other library module defines this function, except in Cabal! Simon That was my fault; I'm very sorry. I had added that function (similar to Data.List.dropWhileEnd, but not the same) to compiler/utils/Util.lhs and to another module that used it, and then forgot it was not available in libraries/base/GHC/. Since neither Phab nor I run Windows, there was little hope of catching the mistake before it went out. I believe Joachim Breitner has fixed the problem now by using Data.List.dropWhileEnd to construct that error message—the difference in behavior doesn't matter there. David Feuer ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
