September 2014 - ghc-devs

Re: GHC AST Annotations
by Alan & Kim Zimmerman 07 Sep '14

07 Sep '14

If this is done right it can enable this sort of thing : http://www.davidchristiansen.dk/2014/09/06/pretty-printing-idris/ On Fri, Sep 5, 2014 at 5:11 PM, Alan & Kim Zimmerman <alan.zimm(a)gmail.com> wrote: > Hi Neil > > Thanks for the feedback. > > I am going to start putting together a proof of concept, aiming to > identify what annotations are needed to roundtrip source. > > The first version will make use of the index into a separate structure > scheme, so that it can be used with existing GHC ASTs. Hopefully the > information gained will help in understanding what is needed for the > changes to the future AST. > > The concept I will be working with is a pretty-printer, where relative > spacing for the particular elements is derived from the initial SrcSpan > information. Any new elements added or changed in the AST can then have > only relative information, and the final render should honour the layout > from the original. > > It may be possible to harmonise this with Chris Done's hindent package, > which is a code-specific pretty printer for haskell-src-exts. > > Alan > > > On Sat, Aug 30, 2014 at 11:18 PM, Neil Mitchell <ndmitchell(a)gmail.com> > wrote: > >> Since Alan is trying to do something for HaRe that I want for HLint on >> top of haskell-src-exts, he asked me for my opinions on the proposal. >> There seem to be two approaches to take: >> >> * Add SrcSpan's throughout. The HSE approach of having a list of inner >> source spans is nasty - the details of which source space goes where >> is entirely undocumented and hard to discover. Even worse, for things >> like instance, which may or may not have a where after, the number of >> inner SrcSpan's changes. Simon's idea of hsdo_do_loc is much cleaner, >> and easily extends to Maybe SrcSpan if the keyword is optional. >> >> * Having the annotation be a type parameter gives much greater >> flexibility. In particular, it would let you mark certain nodes as >> being added/deleted. However, since SrcSpan has an Int in it, you can >> always pass around a separate IntMap and make the SrcSpan really be an >> index into more detailed information. It's nasty, but only the people >> who use it pay for it. >> >> Both approaches have disadvantages. You could always combine both >> ideas, and have a SrcSpan and entirely separately an annotation (which >> defaults to (), rather than SrcSpanInfo), but maybe that's too much >> extra baggage on the AST. >> >> Thanks, Neil >> >> >> On Sat, Aug 30, 2014 at 3:32 PM, Alan & Kim Zimmerman >> <alan.zimm(a)gmail.com> wrote: >> > A further use case would be to be able to convert all the locations to >> be >> > relative, or include a relative portion, so that as tools manipulate >> the AST >> > by adding or removing parts the layout can be preserved. >> > >> > I think I may need to make a wip branch for this and experiment, it is >> > always easier to comment on concrete things. >> > >> > Alan >> > >> > >> > On Thu, Aug 28, 2014 at 10:38 PM, Simon Peyton Jones < >> simonpj(a)microsoft.com> >> > wrote: >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> It’s probably not too bad if you use record syntax; thus >> >> >> >> | HsDo { hsdo_do_loc :: SrcSpan -- of the word "do" >> >> >> >> , hsdo_blocks :: BlockSrcSpans >> >> >> >> , hsdo_ctxt :: HsStmtContext Name >> >> >> >> , hsdo_stmts :: [ExprLStmt id] >> >> >> >> , hsdo_type :: PostTcType } >> >> >> >> >> >> >> >> Simon >> >> >> >> >> >> >> >> From: Alan & Kim Zimmerman [mailto:alan.zimm@gmail.com] >> >> Sent: 28 August 2014 19:35 >> >> To: Richard Eisenberg >> >> Cc: Simon Peyton Jones; ghc-devs(a)haskell.org >> >> Subject: Re: GHC AST Annotations >> >> >> >> >> >> >> >> This does have the advantage of being explicit. I modelled the initial >> >> proposal on HSE as a proven solution, and I think that they were >> trying to >> >> keep it non-invasive, to allow both an annotated and non-annoted AST. >> >> >> >> I thiink the key question is whether it is acceptable to sprinkle this >> >> kind of information throughout the AST. For someone interested in >> >> source-to-source conversions (like me) this is great, others may find >> it >> >> intrusive. >> >> >> >> The other question, which is probably orthogonal to this, is whether we >> >> want the annotation to be a parameter to the AST, which allows it to be >> >> overridden by various tools for various purposes, or fixed as in >> Richard's >> >> suggestion. >> >> >> >> A parameterised annotation allows the annotations to be manipulated via >> >> something like for HSE: >> >> >> >> -- |AST nodes are annotated, and this class allows manipulation of the >> >> annotations. >> >> class Functor ast => Annotated ast where >> >> >> >> -- |Retrieve the annotation of an AST node. >> >> ann :: ast l -> l >> >> >> >> -- |Change the annotation of an AST node. Note that only the >> annotation >> >> of the node itself is affected, and not >> >> -- the annotations of any child nodes. if all nodes in the AST tree >> are >> >> to be affected, use fmap. >> >> >> >> amap :: (l -> l) -> ast l -> ast l >> >> >> >> >> >> >> >> Alan >> >> >> >> >> >> >> >> On Thu, Aug 28, 2014 at 7:11 PM, Richard Eisenberg <eir(a)cis.upenn.edu> >> >> wrote: >> >> >> >> For what it's worth, my thought is not to use SrcSpanInfo (which, to >> me, >> >> is the wrong way to slice the abstraction) but instead to add SrcSpan >> fields >> >> to the relevant nodes. For example: >> >> >> >> | HsDo SrcSpan -- of the word "do" >> >> BlockSrcSpans >> >> (HsStmtContext Name) -- The parameterisation is >> >> unimportant >> >> -- because in this context we >> never >> >> use >> >> -- the PatGuard or ParStmt variant >> >> [ExprLStmt id] -- "do":one or more stmts >> >> PostTcType -- Type of the whole expression >> >> >> >> ... >> >> >> >> data BlockSrcSpans = LayoutBlock Int -- the parameter is the >> indentation >> >> level >> >> ... -- stuff to track the appearance >> of >> >> any semicolons >> >> | BracesBlock ... -- stuff to track the braces and >> >> semicolons >> >> >> >> >> >> The way I understand it, the SrcSpanInfo proposal means that we would >> have >> >> lots of empty SrcSpanInfos, no? Most interior nodes don't need one, I >> think. >> >> >> >> Popping up a level, I do support the idea of including this info in the >> >> AST. >> >> >> >> Richard >> >> >> >> >> >> On Aug 28, 2014, at 11:54 AM, Simon Peyton Jones < >> simonpj(a)microsoft.com> >> >> wrote: >> >> >> >> > In general I’m fine with this direction of travel. Some specifics: >> >> > >> >> > · You’d have to be careful to document, for every data >> >> > constructor in HsSyn, what the association between the [SrcSpan] in >> the >> >> > SrcSpanInfo and the “sub-entities” >> >> > · Many of the sub-entities will have their own SrcSpanInfo >> >> > wrapped around them, so there’s some unhelpful duplication. Maybe >> you only >> >> > want the SrcSpanInfo to list the [SrcSpan]s for the sub-entities >> (like the >> >> > syntactic keywords) that do not show up as children in the syntax >> tree? >> >> > Anyway do by all means create a GHC Trac wiki page to describe your >> >> > proposed design, concretely. >> >> > >> >> > Simon >> >> > >> >> > From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of >> Alan & >> >> > Kim Zimmerman >> >> > Sent: 28 August 2014 15:00 >> >> > To: ghc-devs(a)haskell.org >> >> > Subject: GHC AST Annotations >> >> > >> >> > Now that the landmines have hopefully been cleared from the AST via >> [1] >> >> > I would like to propose changing the location information in the AST. >> >> > >> >> > Right now the locations of syntactic markers such as >> do/let/where/in/of >> >> > in the source are discarded from the AST, although they are retained >> in the >> >> > rich token stream. >> >> > >> >> > The haskell-src-exts package deals with this by means of using the >> >> > SrcSpanInfo data type [2] which contains the SrcSpan as per the >> current GHC >> >> > Located type but also has a list of SrcSpan s for the syntactic >> markers, >> >> > depending on the particular AST fragment being annotated. >> >> > >> >> > In addition, the annotation type is provided as a parameter to the >> AST, >> >> > so that it can be changed as required, see [3]. >> >> > >> >> > The motivation for this change is then >> >> > >> >> > 1. Simplify the roundtripping and modification of source by >> explicitly >> >> > capturing the missing location information for the syntactic markers. >> >> > >> >> > 2. Allow the annotation to be a parameter so that it can be replaced >> >> > with a different one in tools, for example HaRe would include the >> tokens for >> >> > the AST fragment leaves. >> >> > >> >> > 3. Aim for some level compatibility with haskell-src-exts so that >> tools >> >> > developed for it could be easily ported to GHC, for example >> exactprint [4]. >> >> > >> >> > >> >> > >> >> > I would like feedback as to whether this would be acceptable, or if >> the >> >> > same goals should be achieved a different way. >> >> > >> >> > >> >> > >> >> > Regards >> >> > >> >> > Alan >> >> > >> >> > >> >> > >> >> > >> >> > [1] https://phabricator.haskell.org/D157 >> >> > >> >> > [2] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> > [3] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> > [4] >> >> > >> http://hackage.haskell.org/package/haskell-src-exts-1.15.0.1/docs/Language-… >> >> > >> >> >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs(a)haskell.org >> >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >> >> >> > >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs(a)haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > >> > >

1 0

Problems with building GHC 7.8.3 on Windows
by Marek Wawrzos 06 Sep '14

06 Sep '14

Hello, I am trying to compile GHC 7.8.3 on Windows. I was following the instructions from the GHC wiki, but I have encountered errors during the make process. I have filed a bug report describing my issue: https://ghc.haskell.org/trac/ghc/ticket/9513 Does anyone had working setup for building GHC and would be willing to share information on how to achieve it? -- Best regards, Marek Wawrzos

5 6

Trac
by Simon Peyton Jones 06 Sep '14

06 Sep '14

Trac is still very slow, and super-hard to update a wiki page without getting "database locked" and often losing all your eits. It would be great if this could be fixed somehow. Simon

1 0

Status updates
by Austin Seipp 06 Sep '14

06 Sep '14

Hi *, Here are some status updates for the past week, which have been a bit light. - I spent a bunch of time code reviewing things and merging patches this week. There are still things in Phabricator that need some review, so please review them if you get a chance! You will probably learn things and learning things is good. [1] - I spent more time getting a Windows builder working, and talking with upstream about it. I believe it should Basically Work, but unfortunately the changes for this have not gone upstream yet, so it will probably be a week or two before I can officially do that - I have spent some time fixing some bugs, and I'm posting a review for some shortly, notably 7602! Unrelated to what I in particular am doing Right Now: - I would still _really_ like help with the Applicative Monad patch; I haven't touched it much. Please pester me if you have some cycles to spare. Or just helping me brainstorm would be really really useful![2] - After some minor instability in the tree earlier this week (test failures), everything is back to normal (Thanks to Edward & Simon). Please ping here if you're still having trouble on your machine. - I still think we should turn on --slow mode for our buildbots soon, but this will cause noise. I'd really like some inputs on this - maybe someone would like to help clean up the 'slow' vaildate failures? Bonus points for this, since you don't even have to - Gabor Pali & I had a minor discussion this last week about fixing nightly documentation snapshots. We've had complaints about this in the past and the prior system totally disappeared, so it will be really nice to fix this! Binary snapshots should be possible too, but documentation is perhaps the more key thing. A little work is necessary for this though, and my time is limited as always. Please let me know if you'd like to help with this, and I'll pull you into the loop with Gabor so can tackle this. ---------------------------- I've probably forgotten some things other people have done the past week, including myself. If you have any questions, suggestions, or want to pop in on this email and say something, you should. :) [1] https://phabricator.haskell.org/differential/ [2] https://phabricator.haskell.org/D13 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 5

slow Trac
by Simon Peyton Jones 05 Sep '14

05 Sep '14

Is it my imagination or is Trac taking ages to render pages at the moment? Simon

4 5

Building HEAD (e83e873d) on mips64el: unknown package: old-locale-1.0.0.6
by Nikita Karetnikov 05 Sep '14

05 Sep '14

$ git clone git://github.com/ghc/ghc.git ghc-github $ cd ghc-github $ ./sync-all get $ perl boot $ ./configure $ make […] "inplace/bin/ghc-stage1" -this-package-key rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl,'$ORIGIN' -optl-Wl,-zorigin `cat rts/dist/libs.depend` rts/dist/build/Adjustor.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/Papi.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/STM.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/AutoApply.dyn_o -fPIC -dynamic -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -fno-use-rpaths -optl-Wl,-zorigin -o rts/dist/build/libHSrts-ghc7.9.20140809.so /usr/bin/ld: rts/dist/build/Adjustor.dyn_o: relocation R_MIPS_HI16 against `__gnu_local_gp' can not be used when making a shared object; recompile with -fPIC rts/dist/build/Adjustor.dyn_o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [rts/dist/build/libHSrts-ghc7.9.20140809.so] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 After making this change (see #8857) $ diff -Nru config.mk.in-orig config.mk.in --- config.mk.in-orig 2014-08-11 04:39:24.257232224 +0000 +++ config.mk.in 2014-08-11 04:41:50.666057938 +0000 @@ -99,7 +99,8 @@ x86_64-unknown-mingw32 \ i386-unknown-mingw32 \ sparc-sun-solaris2 \ - sparc-unknown-linux + sparc-unknown-linux \ + mipsel-unknown-linux ifeq "$(SOLARIS_BROKEN_SHLD)" "YES" NoSharedLibsPlatformList += i386-unknown-solaris2 and running $ make distclean $ ./configure $ make it failed with a different error: "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key time_KUji6QoLFw0LtcZkg4b7t4 -hide-all-packages -i -ilibraries/time/. -ilibraries/time/dist-install/build -ilibraries/time/dist-install/build/autogen -Ilibraries/time/dist-install/build -Ilibraries/time/dist-install/build/autogen -Ilibraries/time/include -optP-DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP-include -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package-key base_DiPQ1siqG3SBjHauL3L03p -package-key deeps_L0rJEVU1Zgn8x0Qs5aTOsU -package-key oldlo_EJWcQwUgW2gEwNtIuJl2P8 -Wall -XHaskell2010 -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O2 -no-user-package-db -rtsopts -odir libraries/time/dist-install/build -hidir libraries/time/dist-install/build -stubdir libraries/time/dist-install/build -c libraries/time/./Data/Time/Clock/CTimeval.hs -o libraries/time/dist-install/build/Data/Time/Clock/CTimeval.o <command line>: unknown package: old-locale-1.0.0.6 make[1]: *** [libraries/time/dist-install/build/Data/Time/Clock/CTimeval.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 ‘libraries/old-locale’ is present in the tree and is not empty. Is it necessary to run anything else after distclean? According to ‘MAKEHELP’, it is not needed, so I’m puzzled.

2 4

Extending fold/build fusion
by Akio Takano 05 Sep '14

05 Sep '14

Hi, I have been thinking about how foldl' can be turned into a good consumer, and I came up with something that I thought would work. So I'd like to ask for opinions from the ghc devs: if this idea looks good, if it is a known bad idea, if there is a better way to do it, etc. The main idea is to have an extended version of foldr: -- | A mapping between @a@ and @b@. data Wrap a b = Wrap (a -> b) (b -> a) foldrW :: (forall e. Wrap (f e) (e -> b -> b)) -> (a -> b -> b) -> b -> [a] -> b foldrW (Wrap wrap unwrap) f z0 list0 = wrap go list0 z0 where go = unwrap $ \list z' -> case list of [] -> z' x:xs -> f x $ wrap go xs z' This allows the user to apply an arbitrary "worker-wrapper" transformation to the loop. Using this, foldl' can be defined as newtype Simple b e = Simple { runSimple :: e -> b -> b } foldl' :: (b -> a -> b) -> b -> [a] -> b foldl' f initial xs = foldrW (Wrap wrap unwrap) g id xs initial where wrap (Simple s) e k a = k $ s e a unwrap u = Simple $ \e -> u e id g x next acc = next $! f acc x The wrap and unwrap functions here ensure that foldl' gets compiled into a loop that returns a value of 'b', rather than a function 'b -> b', effectively un-CPS-transforming the loop. I put preliminary code and some more explanation on Github: https://github.com/takano-akio/ww-fusion Thank you, Takano Akio

5 20

Copyright headers etc.
by Alexander Berntsen 04 Sep '14

04 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 We should probably do something about copyright headers. They're all very out of date and basically useless. I suggest just having a CONTRIBUTORS file with one name per line, and pointing to that in the files. But IANAL, and copyright is complicated, so other ideas are welcome. - -- Alexander alexander(a)plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlQIRnsACgkQRtClrXBQc7XDlAD/TEAkGaXPD3jzTDxOYVlyCSwP RIMvBcKuJqZvX+atIOMA/A4e4yuy5QIy9YR7U50jdZVK63fONkFyXa6iTYwuxTCE =rVWx -----END PGP SIGNATURE-----

2 1

Unique as special boxing type & hidden constructors
by p.k.f.holzenspies＠utwente.nl 04 Sep '14

04 Sep '14

Dear all, I'm working with Alan to instantiate everything for Data.Data, so that we can do better SYB-traversals (which should also help newcomers significantly to get into the GHC code base). Alan's looking at the AST types, I'm looking at the basic types in the compiler. Right now, I'm looking at Unique and two questions come up: > data Unique = MkUnique FastInt 1) As someone already commented: Is there a specific reason (other than history) that this isn't simply a newtype around an Int? If we're boxing anyway, we may as well use the default Int boxing and newtype-coerce to the specific purpose of Unique, no? 2) As a general question for GHC hacking style; what is the reason for hiding the constructors in the first place? I understand about abstraction and there are reasons for hiding, but there's a "public GHC API" and then there are all these modules that people can import at their own peril. Nothing is guaranteed about their consistency from version to version of GHC. I don't really see the point about hiding constructors (getting in the way of automatically deriving things) and then giving extra functions like (in the case of Unique): > getKeyFastInt (MkUnique x) = x > mkUniqueGrimily x = MkUnique (iUnbox x) I would propose to just make Unique a newtype for an Int and making the constructor visible. Regards, Philip

5 16

Can Phabricator be made to understand git better?
by Johan Tibell 04 Sep '14

04 Sep '14

Hi, I have to fight Phab too much because it doesn't understand git or git working conventions very well. For example, the other day I uploaded https://phabricator.haskell.org/D128, built from a single git commit on a feature branch I made on a local feature branch (based on my local master). First, doing that was in itself a bit of a pain. 'arc diff' didn't do the right thing and included some random commit(s) instead of my single commit in my feature branch. Perhaps it tried to diff against origin/master or something, which doesn't make any sense if you know how git is meant to be used (doing that would imply that you have to constantly sync with upstream to create a patch.) I eventually got it to used the right commit by doing 'arc diff <commit id>`. Second, today when I wanted to update my commit to address some review comments I 1) amended my commit in my feature branch and 2) ran 'arc diff', expecting that it would do the right thing. It didn't and now D128 contains a bunch of changes that aren't mine. I don't know where they came from. Is there a way to configure Phab so it works with git established workflows? -- Johan

3 3