> On Jun 2, 2016, at 4:28 PM, Tanya Lattner wrote:
>
>
>
>> On Jun 2, 2016, at 12:18 PM, Mehdi Amini wrote:
>>
>>
>>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev
>>> wrote:
>>>
>>> I personally find this email thread very hard to follow and read (this
>>> isn’t anyones fault.
> On Jun 2, 2016, at 12:18 PM, Mehdi Amini wrote:
>
>
>> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev
>> wrote:
>>
>> I personally find this email thread very hard to follow and read (this isn’t
>> anyones fault.. its just a lot of replies). I am sure others do as well. I
>> thi
> On Jun 2, 2016, at 3:59 PM, Brian Cain wrote:
>
>> On Thu, Jun 2, 2016 at 11:21 AM, Tanya Lattner via cfe-dev
>> wrote:
>> I personally find this email thread very hard to follow and read (this isn’t
>> anyones fault.. its just a lot of replies). I am sure others do as well. I
>> think i
On Thu, Jun 2, 2016 at 5:43 AM, Aaron Ballman via lldb-dev
wrote:
> Some developers on Windows prefer to use GUI tools like TortoiseSVN to
> command line tools for version control. The last time I tried
> TortoiseGit on Windows (which was over a year ago), it did not feel
> ready for production us
On Thu, Jun 2, 2016 at 11:21 AM, Tanya Lattner via cfe-dev <
cfe-...@lists.llvm.org> wrote:
> I personally find this email thread very hard to follow and read (this
> isn’t anyones fault.. its just a lot of replies). I am sure others do as
> well. I think it would be good to have a form/survey of
This has no eh_frame unwind instructions. Even if we were using eh_frame at
frame 0, you'd be out of luck.
I forget the exact order of fallbacks. I think for frame 0 we try to use the
assembly profile unwind ("async unwind plan") and if we can't do that we fall
back to the eh_frame unwind ("s
Mehdi Amini via cfe-dev writes:
>> Fair enough. It might be less confusing to use a term other that
>> "submodule" though. I've used "superproject/subproject" in the past,
>> for example, and also "host repository" and "project repository."
>
> It does not even represent the full set of possibi
Hi all,
I was investigating a bug when I saw something suspicious in:
StackFrame.cpp:38
// The first bits in the flags are reserved for the SymbolContext::Scope bits
// so we know if we have tried to look up information in our internal symbol
// context (m_sc) already.
#define RESOLVED_FRAME_CO
> On Jun 2, 2016, at 11:51 AM, d...@cray.com wrote:
>
> Mehdi Amini via cfe-dev writes:
>
>> My opinion is that submodules or not is an implementation details. For
>> the sake of this high-level discussion we should be able to keep it as
>> "submodules" meaning "some system to integrate and man
Mehdi Amini via cfe-dev writes:
> My opinion is that submodules or not is an implementation details. For
> the sake of this high-level discussion we should be able to keep it as
> "submodules" meaning "some system to integrate and manage different
> repositories coherently".
> We should evaluate
via llvm-dev writes:
> Anton Korobeynikov via llvm-dev writes:
>
>> I'm not sure we will benefit from having *all* the subprojects in the
>> single repository. This might affect pull / clone time significantly.
>> Think about having lld, lldb along with llvm + clang in the single
>> main repo.
>
Mehdi Amini via llvm-dev writes:
>> How do you get monotonically increasing number with a history graph?
>
> I think what we're trying to get is a "pushed" revision number,
> i.e. tracking the state of the upstream repositories at a given time.
Ah, that is something else entirely. We use Stash/
> they would have to come with a technical justification. Just claiming "it is
> unreliable" does not make it a reality.
Of course I don't expect anyone to accept a claim because I say so. The
relative merits of Git and SVN have been widely discussed for years and most
interested parties have a
Mehdi Amini via llvm-dev writes:
>> What exactly is the concrete benefit of monotonically increasing
>> revision numbers? It's completely foreign to git's architecture.
>
> I'm notified that bug is fixed in r12345, my binary says "clang -v" is
> r23456, if I observe the bug I know there is a pro
Renato Golin via cfe-dev writes:
> * Sub-modules may help with a lot of the current relationship we have
> inside the SVN repo, but it also has some problems. Namely they:
>- require a modern version of git (1.7/1.9), but that's 2013 onward.
>- may need additional server side scripting,
> On Jun 2, 2016, at 11:22 AM, d...@cray.com wrote:
>
> Matthias Braun via cfe-dev writes:
>
>> 3. Make sure we have ala llvm-project-submodules setup in the official
>> account. (Optional or necessary for the buildbots?)
>
>> 7. Make sure bisecting with llvm-project-submodules is a good exper
> On Jun 2, 2016, at 11:22 AM, Robinson, Paul wrote:
>
>>> How do you get monotonically increasing number with a history graph?
>>
>> I think what we're trying to get is a "pushed" revision number, i.e.
>> tracking the state of the upstream repositories at a given time.
>
> I think I've mentio
We could also think about using gerrit in the future to manage code reviews
and commits into the repository. (perhaps via the gerrithub.io hosted
platform, which also has github integration, including the ability to deal
with pull requests).
Gerrit already has pretty good support for cross-reposit
> > How do you get monotonically increasing number with a history graph?
>
> I think what we're trying to get is a "pushed" revision number, i.e.
> tracking the state of the upstream repositories at a given time.
I think I've mentioned this before but internally we are (mostly) using
"rev-list --
Matthias Braun via cfe-dev writes:
> 3. Make sure we have ala llvm-project-submodules setup in the official
> account. (Optional or necessary for the buildbots?)
> 7. Make sure bisecting with llvm-project-submodules is a good experience
I would like to have a fuller discussion about how to hand
> On Jun 2, 2016, at 10:53 AM, Chris Bieneman via llvm-dev
> wrote:
>
> My personal 2 cents is that I’d love to see us move to github and a
> git-native workflow. I’m already on a mostly git workflow and the only thing
> that tears me out of it is git-svn, which corrupts itself way too often.
> On Jun 2, 2016, at 9:28 AM, Scott Warren via llvm-dev
> wrote:
>
> My two cents worth: our group tries very hard to avoid Git because we find it
> immature, hard to use, and unreliable.
I'm willing to take such claims into account, but they would have to come with
a technical justification
Piotr Padlewski via llvm-dev writes:
> I also find it bad idea to have it all in one repo. Right now when I
> develope clang-tidy, I don't have to recompile clang often because
> most of the commits in clang-estra doesn't require new clang fetures.
> This is pretty nice if work on 2 core machine
> On Jun 2, 2016, at 9:21 AM, Tanya Lattner via llvm-dev
> wrote:
>
> I personally find this email thread very hard to follow and read (this isn’t
> anyones fault.. its just a lot of replies). I am sure others do as well. I
> think it would be good to have a form/survey of some sort that can
Anton Korobeynikov via llvm-dev writes:
> I'm not sure we will benefit from having *all* the subprojects in the
> single repository. This might affect pull / clone time significantly.
> Think about having lld, lldb along with llvm + clang in the single
> main repo.
I have a personal setup just l
> On Jun 2, 2016, at 11:03 AM, d...@cray.com wrote:
>
> Tim Northover via cfe-dev writes:
>
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>> wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> projects) would be simple decoupled, individual git
>>> repositories
Florent Castelli via cfe-dev writes:
> For a linear history, you can have GitHub doing a rebase when merging
> the changes instead of a merge. I would recommend to do that to keep
> the history clean and have less "fixup" or "wip" commits in the
> history.
Non-linear history doesn't casue "fixu
Looks good.
> On Jun 2, 2016, at 1:40 AM, Carlo Kok via lldb-dev
> wrote:
>
> Seems win64 almost works fine out of the box. 1 minor thing is needed:
>
>
> diff --git
> a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
> b/source/Plugins/Process/Windows/Common/x64/Re
Richard Smith via llvm-dev writes:
> How would you ensure that two dependent changes on different
> repositories get the same revision number?
>
> That is not the case today and isn't (in my opinion) a problem we need
> to solve with this migration. If there's a small (1-2 revision) windo
> On Jun 2, 2016, at 11:01 AM, d...@cray.com wrote:
>
> Mehdi Amini via llvm-dev writes:
>
>>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>>> github at some point, despite the fact that I continue to dislike
>>> git as a tool and consider monotonicly increasing version n
Tim Northover via cfe-dev writes:
> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
> wrote:
>> Apparently I wasn't very clear: llvm and clang (and the others
>> projects) would be simple decoupled, individual git
>> repositories. You would be able to check them out however you want
>> and com
Mehdi Amini via llvm-dev writes:
>> Personally, I’m hugely in favor of moving llvm’s source hosting to
>> github at some point, despite the fact that I continue to dislike
>> git as a tool and consider monotonicly increasing version numbers to
>> be hugely beneficial.
>
> Getting a monotonically
Saleem Abdulrasool via llvm-dev writes:
> As long as a mechanism for bisecting across the repositories is worked
> out, definitely a +1 from me.
I have some git-subtree changes in the works (and used in production
here) that allows this quite naturally.
Not that I'm necessarily recommending git
My personal 2 cents is that I’d love to see us move to github and a git-native
workflow. I’m already on a mostly git workflow and the only thing that tears me
out of it is git-svn, which corrupts itself way too often.
As a late-comer on the thread I do have a few thoughts I want to share based o
On Thu, Jun 02, 2016 at 04:48:36PM +0100, Renato Golin via llvm-dev wrote:
> * Git developer tooling is a growing trend, while SVN tooling is
> dying. This is not just about GUIs, but repository management (GitHub,
> GitLab, BitBucket, etc versus SourceForge), bisects, branches,
> remotes, hooks,
My two cents worth: our group tries very hard to avoid Git because we find it
immature, hard to use, and unreliable. I know others feel differently but our
vote is to stay with SVN. If distributed repositories are a priority we’d be
much happier with Mercurial.
skw
> On Jun 2, 2016, at 11:21
You could try Git GUI [1]. I don't know if it's any good, I've only
used Git BASH on Windows (never had any problems with it).
Diana
[1] https://git-for-windows.github.io/
On 2 June 2016 at 15:43, Aaron Ballman via cfe-dev
wrote:
> On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
>> I think
I personally find this email thread very hard to follow and read (this isn’t
anyones fault.. its just a lot of replies). I am sure others do as well. I
think it would be good to have a form/survey of some sort that can get feedback
from users such as: who they are, how they use LLVM/contribution
Renato,
> Firstly, the responses were overwhelmingly positive (I counted 20 of
> the ~25 people strongly supporting and another 2~3 weakly supporting).
> This is a good indication that the move could be very beneficial to
> the community as a whole, including downstream infrastructure, not
> just
A little summary...
After a lot of discussion, I think we converged to a few issues that
we need to solved before we finally decide to move.
Firstly, the responses were overwhelmingly positive (I counted 20 of
the ~25 people strongly supporting and another 2~3 weakly supporting).
This is a good i
On 2 June 2016 at 13:43, Aaron Ballman via lldb-dev
wrote:
> Are there suitable GUI tools for git on Windows for projects as
> complex as LLVM? I believe MSVC has some integration, but I've not
> used it before. Perhaps other tools exist that match the integration
> and stability that TortoiseSVN
Am 02.06.2016 um 14:43 schrieb Aaron Ballman via cfe-dev:
On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.
Some developers on Windows prefer to use GUI tool
On Wed, Jun 1, 2016 at 6:31 PM, Renato Golin wrote:
> I think we should start two other threads: one about git tooling on Windows
> and one about infrastructure problems migrating to git.
Some developers on Windows prefer to use GUI tools like TortoiseSVN to
command line tools for version control
Hello,
This is happening in TestPrintStackTraces, where we can end up
here:
ld-linux-x86-64.so.2`___lldb_unnamed_symbol95$$ld-linux-x86-64.so.2:
0x77df04e0 <+0>: 48 83 ec 38
subq $0x38, %rsp
0x77df04e4 <+4>: 48 89 04 24
movq %rax, (%rsp)
0x77df04e8 <+8>: 4
Seems win64 almost works fine out of the box. 1 minor thing is needed:
diff --git
a/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
b/source/Plugins/Process/Windows/Common/x64/RegisterContextWindows_x64.cpp
index 103cff4..4b37c3f 100644
---
a/source/Plugins/Process/W
45 matches
Mail list logo
