On Wed, Dec 2, 2015 at 9:48 PM, Zachary Turner wrote:
>
>
> On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrote:
>
>>
>>
>>> and the classname could be dropped (there's only one class per file
>>> anyway, so the classname is just wasted space)
>>>
>>
>> Part of the reason I included that is I've hit
On Wed, Dec 2, 2015 at 9:44 PM Todd Fiala wrote:
>
>
>> and the classname could be dropped (there's only one class per file
>> anyway, so the classname is just wasted space)
>>
>
> Part of the reason I included that is I've hit several times where copy
> and paste errors lead to the same class na
Thanks, Zachary.
On Wed, Dec 2, 2015 at 3:59 PM, Zachary Turner wrote:
> Now that it's working in Python 3 and I've had a chance to see the output,
> I think I like it much better. These are the things I noticed (good and
> bad):
>
> 1) Output of each test is printed on the fly as the test is r
Could you re-build lldb with http://reviews.llvm.org/D15172 and try to hit
a breakpoint in jit code?
I'm using following setup to compile and run JIT code:
./build_release/bin/clang -c -O0 -g -emit-llvm ./jit_test.cpp
./build_release/bin/lli -debugger-tune=lldb -jit-kind=mcjit
~/projects/lldb/test
In other words, instead of printing this:
FAIL:
TestDataFormatterPythonSynth.PythonSynthDataFormatterTestCase.test_rdar10960550_with_run_command_dwo
(D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\data-formatter\data-formatter-python-synth\TestDataFormatterPythonSynth.py)
P
Now that it's working in Python 3 and I've had a chance to see the output,
I think I like it much better. These are the things I noticed (good and
bad):
1) Output of each test is printed on the fly as the test is run. Much
better than staring at a black screen for 5 minutes and then seeing a bun
Yea. And I should also make the if __name__ == "__main__" check actually
work by putting it above the import statements. It's supposed to print out
a message and tell you what to do when you accidentally run that, but it
doesn't get that far because it fails to import a module.
On Wed, Dec 2, 20
Should we change the name of lldb/packages/Python/lldbsuite/dotest.py to
something else to avoid this confusion?
Jim
> On Dec 2, 2015, at 2:48 PM, Zachary Turner via lldb-dev
> wrote:
>
> You shouldn't have to point it anywhere. Just run lldb/test/dotest.py the
> same way you're currently r
All good.
Yeah Python 2/3 string/byte handling is one of the trickier areas of
cross-Python version compatibility.
On Wed, Dec 2, 2015 at 2:18 PM, Zachary Turner wrote:
> think I got something working, I'll upload a patch in a few.
>
> On Wed, Dec 2, 2015 at 2:10 PM Zachary Turner wrote:
>
>>
You shouldn't have to point it anywhere. Just run lldb/test/dotest.py the
same way you're currently running it and it should work if you use the
right script. That use_lldb_suite also adds the location of the test
folder to sys.path so it can find it.
The reason all this happened and everything
I was confused because all the tests moved to the packages directory. Do I need
to run the dotest.py from the lldb/test/ directory but point it to the
individual tests within the packages directory?
From: Zachary Turner [mailto:ztur...@google.com]
Sent: Wednesday, December 2, 2015 2:41 PM
To: Ch
Couple things:
1) Python 2.7.10 is still the officially supported way to run tests for all
platforms
2) Python 3 is only supported for Windows and it's experimental.
3) At some point I will drop support for 2.x on Windows, but 2.x will
always be the officially supported way to run tests on every o
I am trying to run the lldb tests with dotest.py but it is failing with
chuckr-mac-build:test chuckr$ python ./dotest.py
Traceback (most recent call last):
File "./dotest.py", line 30, in
import progress
ImportError: No module named progress
It looks like some work was done to move to pytho
think I got something working, I'll upload a patch in a few.
On Wed, Dec 2, 2015 at 2:10 PM Zachary Turner wrote:
> BTW, this is what I do in the swig service, and I think it's the idiomatic
> way of sending variable length data over a socket.
>
> On Wed, Dec 2, 2015 at 2:08 PM Zachary Turner
BTW, this is what I do in the swig service, and I think it's the idiomatic
way of sending variable length data over a socket.
On Wed, Dec 2, 2015 at 2:08 PM Zachary Turner wrote:
> I think the best solution is going to be to use struct.pack. Like this on
> the writing side:
>
> import s
I think the best solution is going to be to use struct.pack. Like this on
the writing side:
import struct
msg = cPickle.dumps(test_event)
packet = struct.pack("!I%ds" % len(msg), len(msg), msg)
self.out_file.send(packet)
and like this on the reading side:
Those fixes are up here:
r254550
Let me know what you see after that, Zachary.
On Wed, Dec 2, 2015 at 1:45 PM, Todd Fiala wrote:
>
>
> On Wed, Dec 2, 2015 at 1:42 PM, Todd Fiala wrote:
>
>> Can you try making those changes in the other spots? There's a handful
>> of code you have probably not
On Wed, Dec 2, 2015 at 1:42 PM, Todd Fiala wrote:
> Can you try making those changes in the other spots? There's a handful of
> code you have probably not ever run if you haven't selected running with a
> test results formatter.
>
>
I'm actually going to make the ibuffer ones now since it's easi
Can you try making those changes in the other spots? There's a handful of
code you have probably not ever run if you haven't selected running with a
test results formatter.
If not, I can try to address them tonight or tomorrow night when I can get
to some kind of python 3 setup.
On Wed, Dec 2, 2
Can you try this?
diff --git a/packages/Python/lldbsuite/test/test_results.py
b/packages/Python/lldbsuite/test/test_results.py
index 12fb2e5..547603e 100644
--- a/packages/Python/lldbsuite/test/test_results.py
+++ b/packages/Python/lldbsuite/test/test_results.py
@@ -1029,8 +1029,8 @@ class RawPick
Yea I was messing around with it too. I don't have a fix yet but I think
you will need to either encode the pickled data as utf8, or better yet,
don't write this:
"{}#{}".format(...)
because pickled data is supposed to be binary data anyway. So use
bytes.append() instead.
Then on the other sid
I think I know how to fix. Trying now.
On Wed, Dec 2, 2015 at 1:17 PM, Todd Fiala wrote:
> I think I can fix the issue without you debugging.
>
> Getting the single pass test runner to use it isn't impossible but will
> take some work. Can you direct-send me the backtrace from the point of
> f
On Wed, Dec 2, 2015 at 11:04 AM, Zachary Turner wrote:
> Can --results-file=stdout be the default so that we don't have to specify
> that?
>
>
I've adjusted the code here:
r254546
to support dropping the --results-file=stdout part if a --results-formatter
is specified and no results-file is spec
I think I can fix the issue without you debugging.
Getting the single pass test runner to use it isn't impossible but will
take some work. Can you direct-send me the backtrace from the point of
failure from your system? Thanks!
-Todd
On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner wrote:
> I
Is there any way to force the single process test runner to use this same
system? I'm trying to debug the problem, but this codepath doesn't execute
in the single process test runner, and it executes in the child process in
the multiprocess test runner. Basically I need the following callstack to
When I run this under Python 3 I get "A bytes object is used like a string"
on Line 1033 of test_results.py. I'm going to dig into it a little bit,
but maybe you know off the top of your head the right way to fix it.
On Wed, Dec 2, 2015 at 11:32 AM Zachary Turner wrote:
> Oh yea, I made up that
Oh yea, I made up that decorator idea because I didn't know all the
formatters were derived from a common base. But your idea is better if
everything is derived from a common base. To be honest you could even just
generate an error if there are two ResultsFormatter derived classes in the
same mod
On Wed, Dec 2, 2015 at 11:20 AM, Todd Fiala wrote:
> Yeah I'd be good with that. I can change that as well.
>
> -Todd
>
> On Wed, Dec 2, 2015 at 11:10 AM, Zachary Turner
> wrote:
>
>> Also another stylistic suggestion. I've been thinking about how to more
>> logically organize all the source f
I'll dig in more when I get to it, but yeah I like the concept for sure.
On Wed, Dec 2, 2015 at 11:12 AM, Zachary Turner wrote:
> Ahh, that's a bummer if true. Because `contrib` is a nice way to group
> together all the things that all the things that have specific maintainers
> and so everyone
I'll also move those couple counts (total tests run and the rerun count)
under the summary. I missed that when evolving the code.
On Wed, Dec 2, 2015 at 11:20 AM, Todd Fiala wrote:
> Yeah I'd be good with that. I can change that as well.
>
> -Todd
>
> On Wed, Dec 2, 2015 at 11:10 AM, Zachary T
Yeah I'd be good with that. I can change that as well.
-Todd
On Wed, Dec 2, 2015 at 11:10 AM, Zachary Turner wrote:
> Also another stylistic suggestion. I've been thinking about how to more
> logically organize all the source files now that we have a package. So it
> makes sense conceptually
Ahh, that's a bummer if true. Because `contrib` is a nice way to group
together all the things that all the things that have specific maintainers
and so everyone else is allowed to break.
On Wed, Dec 2, 2015 at 11:04 AM Todd Fiala wrote:
> On Wed, Dec 2, 2015 at 8:28 AM, Todd Fiala wrote:
>
>>
Also another stylistic suggestion. I've been thinking about how to more
logically organize all the source files now that we have a package. So it
makes sense conceptually to group all of the different result formatters
under a subpackage called formatters. So right now you've got
lldbsuite.test.
Nope, it didn't work without the results-file entry.
I can get that fixed up. I'll look at that now.
On Wed, Dec 2, 2015 at 11:05 AM, Todd Fiala wrote:
> I think it might be already - let me check.
>
> The longer-term goal would be to get this without specifying anything
> (i.e. does what we w
I think it might be already - let me check.
The longer-term goal would be to get this without specifying anything (i.e.
does what we want by default). If stdout is not already being used by
default when a formatter is specified, that would be an easy fix.
Checking now...
On Wed, Dec 2, 2015 at
Can --results-file=stdout be the default so that we don't have to specify
that?
On Wed, Dec 2, 2015 at 11:02 AM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Also, all the text in the summary is fixed-width lined up nicely, which
> may not show in the commit message description if y
On Wed, Dec 2, 2015 at 8:28 AM, Todd Fiala wrote:
> Hi Zachary,
>
> On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner
> wrote:
>
>> Has the xcode build been changed to use static bindings yet?
>>
>
> It is only in our downstream branches. I stripped out support in llvm.org
> lldb per our other th
Also, all the text in the summary is fixed-width lined up nicely, which may
not show in the commit message description if you're using a variable-width
font. On a terminal it looks nice.
On Wed, Dec 2, 2015 at 11:01 AM, Todd Fiala wrote:
>
>
> On Wed, Dec 2, 2015 at 10:57 AM, Todd Fiala wrote:
On Wed, Dec 2, 2015 at 10:57 AM, Todd Fiala wrote:
> Hi all,
>
> I just put up an optional test results formatter that is a prototype of
> what we may move towards for our default test summary results. It went in
> here:
>
> r254530
>
> and you can try it out with something like:
>
> time test/d
Hi all,
I just put up an optional test results formatter that is a prototype of
what we may move towards for our default test summary results. It went in
here:
r254530
and you can try it out with something like:
time test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter
lldbsu
Todd is right, at runtime lldb does need to find some of the clang include
files in order to build modules for its own purposes. On an OS X install,
these headers are put in:
LLDB.framework/Resources/Clang
and are:
> ls
./ avx512vlbwintrin.h lzcntintrin.h
> On Dec 2, 2015, at 8:35 AM, Todd Fiala via lldb-dev
> wrote:
>
> Does our init file mechanism have the ability to do something conditionally
> if it's a core file? (i.e. do we already have a way to get Ted's desired
> behavior via an inserted call to "thread backtrace all" that somehow get
Yes, that concept came out in the thread. I just wanted to make sure there
wasn't also a desire to park on a version of llvm/clang, and if so, that
the path there is not pleasant and definitely not intended to be supported
on top of tree svn/trunk.
Thanks for clarifying!
-Todd
On Wed, Dec 2, 20
Does our init file mechanism have the ability to do something conditionally
if it's a core file? (i.e. do we already have a way to get Ted's desired
behavior via an inserted call to "thread backtrace all" that somehow gets
triggered by the init, but only when we're talking about a core file?)
Alt
On 2 December 2015 at 16:19, Todd Fiala wrote:
> Sorry for being late the the party here.
>
> Sean Callanan and some of the other members can comment more on this, but
> LLDB's expression parser for C/C++ is going to need access to the clang
> include headers, so somehow lldb has to be able to fin
Hi Zachary,
On Mon, Nov 30, 2015 at 9:23 AM, Zachary Turner wrote:
> Has the xcode build been changed to use static bindings yet?
>
It is only in our downstream branches. I stripped out support in llvm.org
lldb per our other threads.
> I got to thinking that maybe it would make sense to pu
Sorry for being late the the party here.
Sean Callanan and some of the other members can comment more on this, but
LLDB's expression parser for C/C++ is going to need access to the clang
include headers, so somehow lldb has to be able to find them. Out of tree
llvm/clang usage is certainly possib
47 matches
Mail list logo
