> That makes it fragile, and that’s why I disagree with your “90% done”
> assessment.
> What if the service behing the hook is down for a few days?
In the long-term view, a pretty trivial catch-up script ought to be
able to synthesize a sane history after any amount of down-time.
People could eve
> On Jun 29, 2016, at 10:03 AM, Renato Golin via llvm-dev
> wrote:
>
> Hi all,
>
> A short summary: Takumi has done 90% of the work here:
>
> https://github.com/llvm-project/llvm-project-submodule
>
> and I've been talking to GitHub, and here are the answers to my questions:
>
>
>> 1. How
On Fri, Jun 10, 2016 at 1:38 PM, Hans Wennborg wrote:
> 2) Following up on the May thread about the release process [1], I'd
> like to make the schedule we've followed for the last few years more
> official by posting somewhere on the web page that we're committed to
> shipping two major releases
Nevermind, I was finally unable to build by "git pull" and
"xcodebuild -configuration Debug"
On Mon, Jun 27, 2016 at 9:55 PM, Jeffrey Tan
wrote:
> Hi,
>
> I followed instructions in http://lldb.llvm.org/build.html to build lldb
> on Mac.
>
> I opened "*lldb/lldb.xcworkspace*" in Xcode7.3.1, sele
On Wed, Jun 29, 2016 at 12:34 PM, Sean Silva wrote:
>
>
> On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin
> wrote:
>
>> On 29 June 2016 at 20:14, Sean Silva wrote:
>> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
>> > important special case we may be able to agree on
On Wed, Jun 29, 2016 at 12:18 PM, Renato Golin
wrote:
> On 29 June 2016 at 20:14, Sean Silva wrote:
> > Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
> > important special case we may be able to agree on. (and I say this as
> > somebody that largely builds cross-compil
On 29 June 2016 at 20:14, Sean Silva wrote:
> Sure. But selfhost (incl. stuff like selfhost w/ sanitizers) is a fairly
> important special case we may be able to agree on. (and I say this as
> somebody that largely builds cross-compilers (targeting PS4))
In that case, RT wouldn't "have" to be cor
On Wed, Jun 29, 2016 at 12:04 PM, Renato Golin
wrote:
> On 29 June 2016 at 19:51, Sean Silva wrote:
> > Roughly speaking, I would prefer a repo division (if any) to be along the
> > lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra
> stuff
> > not strictly required".
>
> The p
On 29 June 2016 at 19:51, Sean Silva wrote:
> Roughly speaking, I would prefer a repo division (if any) to be along the
> lines of "core toolchain" (clang, llvm, lld, compiler-rt) and "extra stuff
> not strictly required".
The problem comes when different people consider "core" different projects
On 29 June 2016 at 16:50, Tom Honermann wrote:
> How would you coordinate dependent updates to the sub-modules?
We won't. Not now. Maybe later.
Right now, doing that means changing how we work and we're trying to
make the least number of changes at a time.
But this is the most requested feature
On 29 June 2016 at 15:11, David Chisnall wrote:
> Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
> continue to work by simply switching the remote in the config?
I hope so. There isn't anything (modulo mistakes) stopping us from
having a clean migration.
We'll have
On Wed, Jun 29, 2016 at 9:28 AM, James Y Knight via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> On 27 June 2016 at 17:03, Rafael Espíndola
>> wrote:
>> > I think that trying to create a ordering/
Thanks Jim, thats some very helpful information.
Sounds like we should take a closer look at our setup to see why the
existing precedence is having trouble resolving this for us.
Aidan
On 29/06/16 18:24, Jim Ingham wrote:
We have a not-yet-implemented scheme to allow some syntax like:
(lldb)
We have a not-yet-implemented scheme to allow some syntax like:
(lldb) expr $$foo.c$bar(5)
that would mean: look up the version of bar defined in foo.c and call that.
What I wrote above isn't right, since the "." is going to cause the parser
headaches, so we'll have to come up with some clever
> On Jun 29, 2016, at 9:51 AM, Bogdan Hopulele via lldb-dev
> wrote:
>
> Hi all,
>
> Given a file name, line number and variable name, I am trying to determine
> the address. I tried the following approach:
> · First I got the block corresponding to the file and line:
> o from the
Hi all,
Given a file name, line number and variable name, I am trying to determine the
address. I tried the following approach:
* First I got the block corresponding to the file and line:
o from the file name I got a SBCompileUnit
o using the SBCompileUnit and line number I got a S
On Mon, Jun 27, 2016 at 12:13 PM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:
> On 27 June 2016 at 17:03, Rafael Espíndola
> wrote:
> > I think that trying to create a ordering/rev number between independent
> git
> > repositories is fundamentally unreliable.
> >
> > If we want to
On 6/29/2016 10:03 AM, Renato Golin via cfe-dev wrote:
> Since the umbrella project cannot see the sub-modules' commits without
> some form of update, there are two ways to do this:
>
> P. Per push: Every push (not commit) on all other repositories will
> trigger a hook that will hit a URL on our s
On 29 Jun 2016, at 15:03, Renato Golin via llvm-dev
wrote:
>
> Any more comments before we put this proposal to vote?
Thank you very much for driving all of this. I just have one quick question:
Will existing clones from the LLVM git mirror and / or llvm-mirror on GitHub
continue to work by
Hi all,
A short summary: Takumi has done 90% of the work here:
https://github.com/llvm-project/llvm-project-submodule
and I've been talking to GitHub, and here are the answers to my questions:
> 1. How will the umbrella project's auto-increment hook work?
Since the umbrella project cannot see
Hi Adrien,
I think your diagnosis is correct here. LLDB does indeed create an
additional connection to the gdb-server instance which is started by the
platform instance when you start debugging. In case of android platforms we
already include code to forward this port automatically, but there is n
Hi all,
We have a process that contains multiple definitions of the same
function. The function in question is declared 'static extern' in a
header and included in multiple compilation units.
This causes some confusion for lldb expression parser when trying to
invoke the function by name, sin
https://llvm.org/bugs/show_bug.cgi?id=28354
Bug ID: 28354
Summary: TestTemplateIntegerArgs.py fails with gcc
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
https://llvm.org/bugs/show_bug.cgi?id=28353
Bug ID: 28353
Summary: TestTopLevelExprs.py fails with gcc-4.8
Product: lldb
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
P
24 matches
Mail list logo
