I'm mostly but not entirely tongue in cheek wondering why we aren't calling
llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
that's a minor point.
If it is actually causing confusion (I haven't experienced such yet) I don't
mind typing some extra letters.
As we've d
On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
> I'm mostly but not entirely tongue in cheek wondering why we aren't
> calling llvm::Error llvm::LLVMError, as the lldb error class much preceded
> it, but that's a minor point.
>
FWIW I think the naming chosen by LLVM is correct. It's intended
> On May 1, 2017, at 11:48 AM, Zachary Turner wrote:
>
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
> I'm mostly but not entirely tongue in cheek wondering why we aren't calling
> llvm::Error llvm::LLVMError, as the lldb error class much preceded it, but
> that's a minor point.
>
BTW, I'm interested to know if you have some analysis which leads you to think
that propagating unchecked errors actually is a big problem in lldb, or are you
just doing this to remove a spelling collision? I see a lot of bugs for lldb
come by, but I really haven't seen many that this sort of f
The rename is just to avoid the spelling collision. Nothing in particular
leads me to believe that unchecked errors are a source of major bugs.
That said, I have some short term plans to begin making use of some llvm
library classes which deal in llvm::Error, and doing this first should make
thos
On 1 May 2017 at 19:48, Zachary Turner via lldb-dev
wrote:
>
>
> On Mon, May 1, 2017 at 11:28 AM Jim Ingham wrote:
>> If it is actually causing confusion (I haven't experienced such yet) I
>> don't mind typing some extra letters.
>
> I think that's in part because llvm::Error isn't very prevalent
> On May 1, 2017, at 12:54 PM, Zachary Turner wrote:
>
> The rename is just to avoid the spelling collision. Nothing in particular
> leads me to believe that unchecked errors are a source of major bugs.
>
> That said, I have some short term plans to begin making use of some llvm
> library cl
On 28 April 2017 at 16:04, Scott Smith wrote:
> Hmmm ok, I don't like hard coding pools. Your idea about limiting the
> number of high level threads gave me an idea:
>
> 1. System has one high level TaskPool.
> 2. TaskPools have up to one child and one parent (the parent for the high
> level Task
I think we agree about the SB layer. You can't have mandatory checking on
things that go through the SB API. I think we could code around that
though.
Regarding the other point, I actually think force checked errors *help* you
think about how to back out and leave the debug session alive.
Specif
On Mon, May 1, 2017 at 2:42 PM, Pavel Labath wrote:
> Besides, hardcoding the nesting logic into "add" is kinda wrong.
> Adding a task is not the problematic operation, waiting for the result
> of one is. Granted, generally these happen on the same thread, but
> they don't have to be -- you can w
> On May 1, 2017, at 2:51 PM, Zachary Turner wrote:
>
> I think we agree about the SB layer. You can't have mandatory checking on
> things that go through the SB API. I think we could code around that though.
>
> Regarding the other point, I actually think force checked errors *help* you
>
Does Xcode ship with a build of LLDB that has asserts enabled? Because if
not it shouldn't affect anything. If so, can you shed some light on why?
On Mon, May 1, 2017 at 3:08 PM Jim Ingham wrote:
>
> > On May 1, 2017, at 2:51 PM, Zachary Turner wrote:
> >
> > I think we agree about the SB lay
> On May 1, 2017, at 3:12 PM, Zachary Turner wrote:
>
> Does Xcode ship with a build of LLDB that has asserts enabled? Because if
> not it shouldn't affect anything. If so, can you shed some light on why?
Not sure that's entirely relevant. The point is not to make failure points
assert the
I'm confused. By having the library assert, you are informed of places
where you didn't do a good job of backing from errors, thereby allowing you
to do a *better* job.
You said this earlier:
> But a larger point about asserting as a result of errors is that it makes
it seem to the lldb develope
We'll be at Tied House as usual, starting on Thursday the 4th at 7pm!
If you can, help us plan and RSVP here: http://meetu.ps/38Kp7F
See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lld
> On May 1, 2017, at 3:29 PM, Zachary Turner wrote:
>
> I'm confused. By having the library assert, you are informed of places where
> you didn't do a good job of backing from errors, thereby allowing you to do a
> *better* job.
>
> You said this earlier:
>
> > But a larger point about asse
Yea, grouping the error and the result together is one of the most
compelling features of it. It's called Expected, so where we would
currently write something like:
int getNumberOfSymbols(Error &Err) {}
or
Error getNumberOfSymbols(int &Count) {}
You would now write:
Expected getNumberOfSymbo
> On May 1, 2017, at 4:52 PM, Zachary Turner wrote:
>
> Yea, grouping the error and the result together is one of the most compelling
> features of it. It's called Expected, so where we would currently write
> something like:
>
> int getNumberOfSymbols(Error &Err) {}
>
> or
>
> Error getNu
For instances where we know that we just want to log errors and continue
with some sensible default, we could introduce a new utility template along
the lines of:
template
T logUnwrap(Expected Result, T DefaultValue = T()) {
if (Result)
return std::move(*Result);
else {
log(Result.tak
Yeah - operations that may produce an valid result *and* a diagnostic would
be better suited to Status, or a pair where we want a hard
requirement that the API client check the diagnostic.
- Lang.
On Mon, May 1, 2017 at 5:27 PM, Jim Ingham wrote:
>
> > On May 1, 2017, at 4:52 PM, Zachary Turner
On Mon, May 1, 2017 at 5:27 PM Jim Ingham wrote:
>
> > On May 1, 2017, at 4:52 PM, Zachary Turner wrote:
> >
> > Yea, grouping the error and the result together is one of the most
> compelling features of it. It's called Expected, so where we would
> currently write something like:
> >
> > int
Is there any chance of introducing something like make_status() into
llvm/Error.h, that constructs the llvm::Error in such a way that it still
interoperates nicely with everything else? Then instead of Expected you
could have WithDiagnostics that enforces the proper semantics.
On Mon, May 1, 2017
Hi Zachary,
... Then instead of Expected you could have WithDiagnostics that
> enforces the proper semantics.
You mean something like an ErrorAnd? Chris Bieneman floated that idea
for some libObject code but we haven't got around to implementing it. If it
were generically useful we could do some
I suppose, but I'm not sure ErrorAnd captures the intended meaning very
well. In any case, that's not super important at this stage since this
isn't on the immediate horizon.
On Mon, May 1, 2017 at 5:43 PM Lang Hames wrote:
> Hi Zachary,
>
> ... Then instead of Expected you could have WithDiagn
Hi All,
I’ve been moderating the lldb mailing list for a very long time now, but I
don’t think it makes sense for me to continue. Is there anyone interested in
taking over this (important to the community) responsibility? Thanks!
-Chris
___
lldb-dev
I would still very much prefer we see if there is a way we can adapt LLVM's
ThreadPool class to be suitable for our needs. Unless some fundamental
aspect of its design results in unacceptable performance for our needs, I
think we should just use it and not re-invent another one. If there are
impr
IMO we should start with proving a better version in the lldb codebase, and
then work on pushing it upstream. I have found much more resistance
getting changes in to llvm than lldb, and for good reason - more projects
depend on llvm than lldb.
On Mon, May 1, 2017 at 9:48 PM, Zachary Turner wrot
I think that's all the more reason we *should* work on getting something
into LLVM first. Anything we already have in LLDB, or any modifications we
make will likely not be pushed up to LLVM, especially since LLVM already
has a ThreadPool, so any changes you make to LLDB's thread pool will likely
h
28 matches
Mail list logo
