[lldb-dev] Two CLs requiring changes to the Xcode project

[Zachary Turner via lldb-dev]

Hi all,

I submitted r252993 and 252994.  These changes will require a corresponding
change in the Xcode workspace.  Would anyone mind making those changes for
me?  It should be pretty simple, just need to add a .cpp and .h file to the
gtest target for ScriptInterpreterPythonTests, and add
PythonExceptionState.cpp to Plugins/ScriptInterpreter/Python
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

[Zachary Turner via lldb-dev]

Hmm, can you ask Todd about it?  He said he added one, but I'm not sure how
it works.

On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda  wrote:

> Done in r252998.
>
> I didn't see anything in the xcode project file about a gtest target.
>
> J
>
> > On Nov 12, 2015, at 5:39 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi all,
> >
> > I submitted r252993 and 252994.  These changes will require a
> corresponding change in the Xcode workspace.  Would anyone mind making
> those changes for me?  It should be pretty simple, just need to add a .cpp
> and .h file to the gtest target for ScriptInterpreterPythonTests, and add
> PythonExceptionState.cpp to Plugins/ScriptInterpreter/Python
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Two CLs requiring changes to the Xcode project

[Zachary Turner via lldb-dev]

Thanks!  I actually forgot, there's one more file for the lldb-gtest
target.  It's PythonExceptionStateTests.cpp.

Thanks for the help

On Thu, Nov 12, 2015 at 6:05 PM Jason Molenda  wrote:

> Ah, my bad.  It's the lldb-gtest target.
>
>
> > On Nov 12, 2015, at 5:49 PM, Zachary Turner  wrote:
> >
> > Hmm, can you ask Todd about it?  He said he added one, but I'm not sure
> how it works.
> >
> > On Thu, Nov 12, 2015 at 5:46 PM Jason Molenda 
> wrote:
> > Done in r252998.
> >
> > I didn't see anything in the xcode project file about a gtest target.
> >
> > J
> >
> > > On Nov 12, 2015, at 5:39 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hi all,
> > >
> > > I submitted r252993 and 252994.  These changes will require a
> corresponding change in the Xcode workspace.  Would anyone mind making
> those changes for me?  It should be pretty simple, just need to add a .cpp
> and .h file to the gtest target for ScriptInterpreterPythonTests, and add
> PythonExceptionState.cpp to Plugins/ScriptInterpreter/Python
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] swig generation

[Zachary Turner via lldb-dev]

On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi all,
>
> I'd like to do a few things with our swig generation and handling:
>
> * Create a maintainer-mode style setup where the swig Python bindings are
> generated and checked into the repo (I'll call it the static python
> binding).
>
> This will be used by default, removing the need for most people and all
> builders/bots from having swig on their system just for lldb.  In the event
> that Windows needs a different version (e.g. for, say, Python 3.5 support
> that is incompatible with the swig-1.3.40-generated bindings), we can
> support multiple source bindings, or we can post process the swig-1.3.x
> generated bindings.  We'll keep them by swig-{swig-major}-{swig-minor}.
> Internally over at Apple, we will stick with the swig-1.x bindings.  I
> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
> example).  We'll just make sure to use the latest for a
> {swig-major}.{swig-minor}.  As always, SB API changes generated by swig
> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
> generating usable Python wrappers).
>
I know you said you plan to stay on 1.x, but in this world of having SWIG
bindings checked in, does that open the door to potentially moving beyond
SWIG 1.x for the upstream?  I feel like the SWIG 1.x requirement holds the
upstream back, because there are a lot of hacks to workaround bugs and
limitations in SWIG, and it only understands the absolute most basic C /
C++ language constructs.  So we end up being limited in how we can design
SB APIs, all for reasons that having nothing to do with the upstream
project requirements, which is kind of a bummer.  It seems like there could
be a path here for the upstream to move forward, and anyone who is forced
to stay on an earlier version of SWIG could maintain whatever changes are
necessary to make this possible in a local repository.



>
> * Clean up the swig generation scripts
>
> These look to have been implemented as direct ports of the older OS X
> style bash scripts.  This Python script is very much the essence of using
> the paradigms of one language in another, and being the worse for it.  It
> implements features that are already present in the standard Python lib,
> and is more verbose than it needs to be.
>
Ugh, +1000.  Every time I have to crack these files open my head explodes.
More than happy to help with whatever porting is necessary.


>
> Also, it is likely the script needs to be broken out into a few parts.
> The scripts don't just generate the python binding using swig, they also
> setup (for OS X) some packaging and other bits.  Right now none of that is
> clearly broken out.  When we move to an explicit binding generation mode,
> this does need to be broken out better.
>
>
> * Get OS X Xcode build using the same bindings machinery as others.
>
Yay.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] swig generation

[Zachary Turner via lldb-dev]

On Fri, Nov 13, 2015 at 10:24 AM Todd Fiala  wrote:

> On Fri, Nov 13, 2015 at 9:43 AM, Zachary Turner 
> wrote:
>
>> On Fri, Nov 13, 2015 at 9:02 AM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi all,
>>>
>>> I'd like to do a few things with our swig generation and handling:
>>>
>>> * Create a maintainer-mode style setup where the swig Python bindings
>>> are generated and checked into the repo (I'll call it the static python
>>> binding).
>>>
>>> This will be used by default, removing the need for most people and all
>>> builders/bots from having swig on their system just for lldb.  In the event
>>> that Windows needs a different version (e.g. for, say, Python 3.5 support
>>> that is incompatible with the swig-1.3.40-generated bindings), we can
>>> support multiple source bindings, or we can post process the swig-1.3.x
>>> generated bindings.  We'll keep them by swig-{swig-major}-{swig-minor}.
>>> Internally over at Apple, we will stick with the swig-1.x bindings.  I
>>> don't think we will care about the dot release (1.3.40 vs. 1.3.39, for
>>> example).  We'll just make sure to use the latest for a
>>> {swig-major}.{swig-minor}.  As always, SB API changes generated by swig
>>> need to remain swig-1.3 compatible (i.e. swig-1.3 must be capable of
>>> generating usable Python wrappers).
>>>
>> I know you said you plan to stay on 1.x, but in this world of having SWIG
>> bindings checked in, does that open the door to potentially moving beyond
>> SWIG 1.x for the upstream?  I feel like the SWIG 1.x requirement holds the
>> upstream back, because there are a lot of hacks to workaround bugs and
>> limitations in SWIG, and it only understands the absolute most basic C /
>> C++ language constructs.  So we end up being limited in how we can design
>> SB APIs, all for reasons that having nothing to do with the upstream
>> project requirements, which is kind of a bummer.  It seems like there could
>> be a path here for the upstream to move forward, and anyone who is forced
>> to stay on an earlier version of SWIG could maintain whatever changes are
>> necessary to make this possible in a local repository.
>>
>>
> I may leave Greg to discuss that aspect (w/r/t using newer features).  The
> SB API itself is intended to be a very bare-bones linkage environment that
> does not break linkage requirements in ways that typical C++ binary
> libraries do (i.e. it does not use virtuals and follows a number of rules
> about data members so that it remains binary compatible across
> compiler/linker changes).
>

There's a couple of examples that come to mind.  C++11 is completely out,
for example.  In general this isn't a huge deal.  Nobody's going to be
passing rvalue references through the SB API or anything.  But even simple
things like enum classes are out.  1.x also doesn't support specifying the
underlying type of an enum, because it can't parse it.  In other words,
SWIG won't accept this:

enum Foo : unsigned {
};

This is actually important in MSVC because its algorithm for choosing the
underlying type and size of the enum differs from other compilers.  We've
got hundreds of warnings silenced in CMake because of this, and there's no
solution except upgrade SWIG.

We're also forced to use the archaic "const char* str, int len" syntax for
every single string, when we could be passing std strings or llvm
StringRefs.

No nested classes, namespace support doesn't work, and also missing out on
a ton of bugfixes and performance improvements of generated code.  Many
languages like Go aren't supported in 1.x, etc.  If I check the release
notes I could probably come up with more examples.

I don't mean to say that we have to do this with haste or anything, but I
think at some point there should probably be a path off of 1.x for the
upstream
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

Moving this back over to the list since I'm sure others have some input
here.  Also +lldb-dev since it has more visibility than lldb-commits.


On Tue, Nov 17, 2015 at 11:25 AM Zachary Turner  wrote:

> On Tue, Nov 17, 2015 at 8:18 AM Todd Fiala  wrote:
>
>> Breaking out the binding generation into a separate step will also be
>> important for a couple reasons:
>>
>> * (from before) I want to eliminate the requirement for the vast majority
>> of the builds to have a swig on their system, and
>>
>> * (not stated before) we'd like to move away from swig for binding
>> generation at some point.
>>
>> -Todd
>>
>
> Unless these plans (i.e. moving away from swig) are imminent, I would
> prefer to keep the binding generation step automatic so people can use
> whatever swig version is installed on their system.  I know there are pros
> and cons to each, but at the end of the day, we need various bugfixes from
> newer versions of SWIG for the Python 3 stuff, and if someone decides they
> want bindings for Go, or Rust, or some other languages, they too might need
> a different minimum SWIG version.  We could start checking in multiple sets
> of generated bindings, but then we start having multiple maintainers, and
> the checked in bindings become out of sync with each other, and it's more
> trouble than it's worth.
>
> We have buildbots building and testing the various configurations, so if
> someone uses something that is incompatible we shoudl catch it.  And just
> yesterday I added some options to the @expectedFailure and @skipIf
> decorators that allow you to skip tests based on the SWIG version and/or
> python version.
>
> Letting people using the SWIG on their system is the easiest way to ensure
> that everyone's needs are still met while still getting early notification
> when someone does something incompatible, and it can be fixed.
>
>
One possibility (which I mentioned to you offline, but I'll put it here for
others to see) is that we make a swig bot which is hosted in the cloud much
like our public build bots.  We provide a Python script that can be run on
your machine, which sends requests over to the swig bot to run swig and
send back the results.  Availability of the service would be governed by
the SLA of Google Compute Engine, viewable here:
https://cloud.google.com/compute/sla?hl=en

If we do something like this, it would allow us to raise the SWIG version
in the upstream, and at that point I can see some benefit in checking the
bindings in.  Short of that, I still dont' see the value proposition in
checking bindings in to the repo.  So far all I've heard is that it is so
that we don't need swig to be on everyone's machines, but I also don't see
the value proposition in that either, given that we already require many
other tools on peoples' machines.

If it means we can get off of SWIG 1.x in the upstream, I will do the work
to make remote swig generation service and get it up and running.  From the
user's perspective, it's already identical to what you're proposing.  No
swig executable on your machine (or anyone's machine for that matter), and
you run a simple script to generate bindings and check them in whenever you
make changes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

On Tue, Nov 17, 2015 at 8:03 PM Todd Fiala  wrote:

> Nothing concrete at the moment; however, it could be interesting to look
> at the clang community and see what could be done for llvm-based language
> implementations.  The angle that I think would be interesting would be if
> we can generate bindings more effectively based on the in-depth
> understanding of the language that is afforded by languages built on top of
> LLVM.  This is probably less interesting for Python (particularly since we
> have a functioning solution) and more interesting for languages built on
> LLVM or clang.
>
> Honestly, though, I haven't spent much time on that.
>
> For the time being, I am going to not change the path for everyone on
> swig, and only use a static binding if swig cannot be found.  This will be
> minimal impact for everyone and doesn't interfere with anyone using a
> specific version of swig.  We can revisit larger questions about
> who/what/when on static bindings after we gain some experience with
> enabling them for those who don't have swig.  We can review and adjust
> based on our collective experience.  The two files this seems like it will
> be are the LLDBWrapPython.cpp and the lldb.py file that comes out of
> python.  I hope to have this working in the next day or so.
>
To try this another way, I really would like to voice my opinion very very
strongly for moving away from having different ways of doing things for
different platforms / build configurations / etc unless it is *required* to
support a hard requirement of someone's environment.

Here's our current configuration matrix.

Platforms: Windows, Linux, FreeBSD, Darwin, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static (proposed)

In all of these cases (except the proposed), the matrix choices are
justifiable because they are there to support a hard requirement of
someone's environment, and I do not think we should grow for anything that
is not also a hard requirement of someone's environment.  We definitely
should not grow it out of convenience, and *especially* not if it's only a
minor convenience.  So I still am looking for a clear answer regarding what
problem this is solving.  Is not having a swig binary on every machine a
hard requirement?  You said

> We can revisit larger questions about who/what/when on static bindings
after we gain some experience with enabling them *for those who don't have
swig*"

And my question is, who doesn't have swig?  Maybe there is a legitimate use
case, I just want to understand what that is before we add more different
ways of building.

I mentioned earlier that one way there would be a definite tangible benefit
is if we could use these static bindings in conjunction with a swig bot
that would automatically generate swig on a remote server and send you back
the result.  This way we could remove one item from the configuration
matrix, which I think we all agree is a good thing based on the fact that
the original idea was to get everyone on 1.3x (which isn't possible since
it doesn't work well with Python 3.5).  Compare:

Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
SWIG version: 1.3x, latest
Python version: None, 2.7, 3.x (in progress)
SWIG Binding Generation: on-the-fly, static

with

Platforms: Windows, Linux, FreeBSD, OSX, NetBSD, Other(?)
Build Systems: CMake, Xcode
Python version: None, 2.7, 3.x (in progress)

The latter is much better, right?  Can we discuss whether this swig server
is a viable solution for getting to a single system that works for
everyone?  Again, I'm willing to do the brunt of the work getting it up and
running if it is (I can probably reuse the portion of work you've already
done related to running swig on the input files)

If the goal is just some kind of cleanup where it would be nice to not have
to install swig, I'm specifically arguing against that, because I don't
think that's a strong enough case to add one item to the configuration
matrix.

>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

On Wed, Nov 18, 2015 at 10:00 AM Todd Fiala  wrote:

> Checking in the static bindings is no different than projects checking in
> autoconf config baked scripts so that the vast majority of people don't
> need to run autoconf just to get a setup that rarely changes.  There is
> precedent for this going back a long way on open source projects.
>
> I'm backing off having anyone else use them if they don't want, and we
> (Apple) will keep those up to date.  Nobody else will use them.  Totally
> fine.
>
> On the swig-as-a-service front, I think the idea is interesting but there
> are several practical holes with that:
>
> * What does one do when the server is unavailable?  Needs to be a
> local-only backup.  So whatever service that provides isn't a guaranteed
> working solution (think on an airplane, network outage, other server
> outage, etc.)
>

> * Security: building code that has other code injected in it by another
> server. Safe? Attack vector?  I could argue so is a git/svn repo
> susceptible to this, so maybe this isn't a huge deal, but it's big enough
> and smells enough like "introduce random unvetted code that can't be
> reviewed as easily as a VCS tag" that I doubt we would ever use this in
> practice.
>
> * Security 2: what is the service really running?  Not obvious on the
> build machine accessing the service.
>
The end result of the service is a copy of LLDBWrapPython.cpp and lldb.py
that you check into the repo.  You still have a chance to diff this source
code against the repository's copy before committing, same as you would if
you had swig locally.  Vast majority of changes to SB interfaces are going
to be the addition of a couple methods, or maybe a class, and the diff
should be very easy to look at and understand.


>
> > In all of these cases (except the proposed), the matrix choices are
> justifiable because they are there to support a hard requirement of
> someone's environment, and I do not think we should grow for anything that
> is not also a hard requirement of someone's environment.
>
> I'm going to call that overreaching.  We are not in the business of
> dictating that one of the developers of the code "should not do something
> unless there is a hard requirement."
>
I'm not saying you shouldn't do *anything* if there's not a hard
requirement.  I agree that's overreaching.  I'm saying we should not
increase the number of ways of doing *the same thing* unless there is a
hard requirement.  Especially if one of the ways of doing the same thing
exists solely to save someone from running one command to install the
package (sorry if I'm not doing justice to how difficult it is on OSX, the
last time I did something on OSX it seemed fairly easy to install macports,
and I thought it's a wildly common thing for people to already have
installed).  For example, wouldn't people need to already have macports in
order to install CMake -- a necessary component of building LLVM?


>  Apple wants to eliminate the need for people to *require* swig.  The goal
> there is reducing the build requirements for the average person building
> lldb, not growing it.
>
I agree, which is why it is so important to keep the number of different
ways of building to a minimum.  It's the same reason that the autoconf
build is being removed wholesale from LLVM and people have decided that
CMake is the one true way.  Because even if it isn't perfect for everyone,
it works for everyone.  And there is inherent simplicity in having fewer
ways to do things, as well as reducing maintenance cost.


>
> So for the more common, casual lldb build environment where the developer
> is not touching SB API, help me understand how reducing the need for swig
> (without introducing the need for hitting another server) is increasing the
> requirement load?  (Especially if we --- our local dev group sitting by me
> --- maintains those static bindings)?
>

Well, we would need to disable static bindings on the OSX buildbots for
starters, otherwise when someone not using static bindings makes a change,
the buildbots break, and we cannot leave buildbots in a broken state.  So I
assume that will still be possible.  So now you don't have a buildbot
testing the static binding configuration.

Secondly, LLDB already has a problem (IMHO) of having too many things that
only work for a few people, instead of having things that work for
everyone.  It's gotten better, and even your work right now to port the
Xcode build over to these new python scripts is helping to make that
better.  So regardless of the outcome here, the end result will still be an
improvement over before when Xcode build was using the shells cripts and
CMake build was using python scripts.

But I still think it's important to take a hardline against introducing new
build configurations.  Static vs on-the-fly bindings are going to need
different logic for getting the resulting code into the place where it can
be compiled / imported, different logic for creating the symlinks, etc.

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:

>
> My intent here is to only provide the --allow-static-binding option on
> cmake if it is explicitly turned on.  And it will be off by default.
>
I know, but I don't really like adding options that nobody is going to use,
because it makes maintaining the build files more difficult, and when
people ask questions on the list about how to use various options, chances
are nobody is going to know because there's nobody maintaining that
codepath.  So I lean on the side of not even having the option.  There's
already a bunch of paths in the CMake build that don't even work because
they're not maintained and nobody uses them.  I'd actually like to go
through and remove that complexity from the CMake build at some point.


>
>
> Tell me more about the service idea.  How would you envision it working?
>
Well, pretty much like I described earlier.  I write a python script,
called swig-bot.py.  You run it like this (I've fabricated an example of
what the output of the tool might look like):

~/lldb$ scripts/swig-bot.py --lang Python --outdir scripts/Python/bindings
scripts/lldb.swig
swig-bot packaging up input files
scripts/lldb.swig
scripts/SBAddress.i
scripts/SBAttachInfo.i
scripts/SBBlock.i
scripts/SBBreakpoint.i
scripts/SBBreakpointLocation.i
scripts/SBBroadcaster.i
scripts/SBCommandInterpreter.i
scripts/SBCommandReturnObject.i
scripts/SBCommunication.i
scripts/SBCompileUnit.i
scripts/SBData.i
scripts/SBDebugger.i
...
transmitting input files...
awaiting response...
Generation
Output: scripts/Python/bindings/LLDBWrapPython.cpp
Output: scripts/Python/bindings/lldb.py

Now you add the 2 output files to your CL, diff them to verify sanity, and
submit.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

On Wed, Nov 18, 2015 at 11:15 AM Todd Fiala  wrote:

> On Wed, Nov 18, 2015 at 10:34 AM, Zachary Turner 
> wrote:
>
>>   Because even if it isn't perfect for everyone, it works for everyone.
>>
>
> Unless you can't get swig on your system in a way that doesn't break other
> items.  And then it doesn't work (as things stand now).
>
Is that a real issue that people on OSX are facing now?  Because I thought
having SWIG installed on your system has been a requirement for the past N
years.  Did something change  recently that now makes it impossible to
install swig in a way that doesn't break something?


>
>
>> And there is inherent simplicity in having fewer ways to do things, as
>> well as reducing maintenance cost.
>>
>>
>>>
>>> So for the more common, casual lldb build environment where the
>>> developer is not touching SB API, help me understand how reducing the need
>>> for swig (without introducing the need for hitting another server) is
>>> increasing the requirement load?  (Especially if we --- our local dev group
>>> sitting by me --- maintains those static bindings)?
>>>
>>
>> Well, we would need to disable static bindings on the OSX buildbots for
>> starters, otherwise when someone not using static bindings makes a change,
>> the buildbots break, and we cannot leave buildbots in a broken state.  So I
>> assume that will still be possible.  So now you don't have a buildbot
>> testing the static binding configuration.
>>
>
> I was actually going to add a verifier stage to the public OS X buildbot.
>
I'm not sure I follow this point.  What would your verifier stage do?  I'm
imagining the following scenario:

I check in some changes to SWIG interface files at like 10PM.  Ignoring the
fact that you and Jason are usually up firing commits away until the wee
hours of the morning, let's pretend nobody sees this until the morning.  So
the build bot has been broken all night.  Is this something that is going
to happen under this scenario?

>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Lldb-commits] [lldb] r253317 - Add Pythonic language binding wrapper generation script.

[Zachary Turner via lldb-dev]

(This is originally from a thread on lldb-commits, but it seems more
appropriate here, so I'm responding here.

On Wed, Nov 18, 2015 at 12:47 PM Todd Fiala  wrote:

> BTW if you cook up something on the swig-as-a-service end that ends up
> working to eliminate the need for swig, I'll be happy to remove the static
> binding support at that point.
>
> -Todd
>


Err, rewind.  If we have the swig as a service, then I think the static
binding does have value.  Because I don't want to hit the network every
single time I build, so it mostly solves the issue you mentioned about
network connectivity, because building LLDB doesn't require a network
connection unless you touch a swig interface file.

The thing I would like some guidance on from the Apple side is this: If I
make the swig service, can you (and will you) use code generated by swig
3.x?  If not, there's no value in the swig service.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] if you look at binding-generation-as-service element...

[Zachary Turner via lldb-dev]

Can I send you a sample set of bindings generated by 3.x as a fail-fast
test?  Try them out, see if anything breaks, etc?

On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala  wrote:

> Hey Zachary,
>
> Please make sure to ping Greg Clayton, particularly if it does anything
> that would make the binding no longer be C-linkage-compatible.  He can tell
> you all the bits we are counting on.  I think the keys are:
>
> * we don't ever have there be vtables.
> * we never remove API surface area.
> * we don't change signatures of existing API.
>
> but I don't think that's exhaustive and certainly not authoritative.
>
> Anyways, just make sure you sync up with him so you don't end up wasting
> any energy on something that will break some kind of requirement we have.
>
> Thanks!
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] if you look at binding-generation-as-service element...

[Zachary Turner via lldb-dev]

LLDBWrapPython.cpp
https://drive.google.com/file/d/0Bzpf8QJC6OGOc0RZNGY1dEhBZzQ/view?usp=sharing>
lldb.py
https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing>

Double check the top of lldb.py to make sure swig_version = (3,0,x)

On Wed, Nov 18, 2015 at 1:14 PM Todd Fiala  wrote:

> Sure.
>
> On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner 
> wrote:
>
>> Can I send you a sample set of bindings generated by 3.x as a fail-fast
>> test?  Try them out, see if anything breaks, etc?
>>
>> On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala  wrote:
>>
>>> Hey Zachary,
>>>
>>> Please make sure to ping Greg Clayton, particularly if it does anything
>>> that would make the binding no longer be C-linkage-compatible.  He can tell
>>> you all the bits we are counting on.  I think the keys are:
>>>
>>> * we don't ever have there be vtables.
>>> * we never remove API surface area.
>>> * we don't change signatures of existing API.
>>>
>>> but I don't think that's exhaustive and certainly not authoritative.
>>>
>>> Anyways, just make sure you sync up with him so you don't end up wasting
>>> any energy on something that will break some kind of requirement we have.
>>>
>>> Thanks!
>>> --
>>> -Todd
>>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] if you look at binding-generation-as-service element...

[Zachary Turner via lldb-dev]

Err, links aren't showing up for me.  Gonna try this again.

lldb.py   -
https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing
LLDBWrapPython.cpp-
https://drive.google.com/file/d/0Bzpf8QJC6OGOaEVaNF9GY0tPXzg/view?usp=sharing


On Wed, Nov 18, 2015 at 1:19 PM Zachary Turner  wrote:

> LLDBWrapPython.cpp
> lldb.py
>
> Double check the top of lldb.py to make sure swig_version = (3,0,x)
>
>
> On Wed, Nov 18, 2015 at 1:14 PM Todd Fiala  wrote:
>
>> Sure.
>>
>> On Wed, Nov 18, 2015 at 1:09 PM, Zachary Turner 
>> wrote:
>>
>>> Can I send you a sample set of bindings generated by 3.x as a fail-fast
>>> test?  Try them out, see if anything breaks, etc?
>>>
>>> On Wed, Nov 18, 2015 at 1:07 PM Todd Fiala  wrote:
>>>
 Hey Zachary,

 Please make sure to ping Greg Clayton, particularly if it does anything
 that would make the binding no longer be C-linkage-compatible.  He can tell
 you all the bits we are counting on.  I think the keys are:

 * we don't ever have there be vtables.
 * we never remove API surface area.
 * we don't change signatures of existing API.

 but I don't think that's exhaustive and certainly not authoritative.

 Anyways, just make sure you sync up with him so you don't end up
 wasting any energy on something that will break some kind of requirement we
 have.

 Thanks!
 --
 -Todd

>>>
>>
>>
>> --
>> -Todd
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

I would like to do a complete audit of dotest's command line options, find
out who's using what, and then potentially delete anything that isn't being
used.  There's a mess of command line options in use, to the point that
it's often hard to find free letters to use for new options.

I created this spreadsheet with a complete list of command line options,
their descriptions, and a place for people to enter what options they're
using or do not want to be deleted.

https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing

If someone has already written YES in the box that indicates they need the
option, please don't overwrite it.  If you write YES in a box, please
provide at least a small rationale for why this option is useful to you.
Feel free to add additional rationale if someone has already added some
rationale.

I'm going to have a couple days in mid-December and do this cleanup, so I'd
like to get a solid picture of what options are not needed before then.
After people have had some time to look over this, I'll go through the
results and decide what to do with each one, and then send out another
email with a proposed action column for each command line option.

Please do take the time to have a look at this, because any option that
doesn't have a YES in it after a couple of weeks I'm going to assume is a
candidate for deletion.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

Just to re-iterate, if we use the bindings as a service, then I envision
checking the bindings in.  This addresses a lot of the potential pitfalls
you point out, such as the "oops, you can't hit the network, no build for
you" and the issue of production build flows not wanting to hit a third
party server, etc.

So if we do that, then I don't think falling back to local generation will
be an issue (or important) in practice.  i.e. it won't matter if you can't
hit the network.  The reason I say this is that if you can't hit the
network you can't check in code either.  So, sure, there might be a short
window where you can't do a local build , but that would only affect you if
you were actively modifying a swig interface file AND you were actively
without a network connection.  The service claims 99.95% uptime, and it's
safe to say we are looking at significantly less than 100% usage of the
server (given checked in bindings), so I think we're looking at once a year
-- if that -- that anyone anywhere has an issue with being able to access
the service.

And, as you said, the option can be provided to change the host that the
service runs on, so someone could run one internally.

But do note, that if the goal here is to get the SWIG version bumped in the
upstream, then we will probably take advantage of some of these new SWIG
features, which may not work in earlier versions of SWIG.  So you should
consider how useful it will be to be able to run this server internally,
because if you can't run a new version of swig locally, then can you run it
internally anywhere?  I don't know, I'll leave that for you to figure out.

Either way, it will definitely have the ability to use a different host,
because that's the easiest way to debug theclient and server (i.e. run them
on the same machine with 127.0.0.1)

On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  wrote:

> For the benefit of continuity in conversation, here is what you had to say
> about it before:
>
> > One possibility (which I mentioned to you offline, but I'll put it here for
> others to see) is that we make a swig bot which is hosted in the cloud much
> like our public build bots.  We provide a Python script that can be run on
> your machine, which sends requests over to the swig bot to run swig and
> send back the results.  Availability of the service would be governed by
> the SLA of Google Compute Engine, viewable 
> here:https://cloud.google.com/compute/sla?hl=en
>
> > If we do something like this, it would allow us to raise the SWIG version
> in the upstream, and at that point I can see some benefit in checking the
> bindings in.  Short of that, I still dont' see the value proposition in
> checking bindings in to the repo.  [bits deleted]
>
> > If it means we can get off of SWIG 1.x in the upstream, I will do the work
> to make remote swig generation service and get it up and running.
>
>
> I'd like feedback from others on this.  Is this something we want to consider 
> doing?
>
> From my perspective, this seems reasonable to look into doing if we:
>
> (a) have the service code available, and
>
> (b) if we so choose, we can readily have the script hit another server (so 
> that a consumer can have the entire setup on an internal network), and
>
> (c: option 1) be able to fall back to generate with swig locally as we do now 
> in the event that we can't hit the server
>
> (c: option 2) rather than fall back to swig generation, use swig generation 
> as primary (as it is now) but, if a swig is not found, then do the 
> get-bindings-as-a-service flow.
>
> This does open up multiple ways to do something, but I think we need to avoid 
> a failure mode that says "Oops, you can't hit the network.  Sorry, no lldb 
> build for you."
>
>
> Reasoning:
>
> For (a): just so we all know what we're using.
>
> For (b): I can envision production build flows that will not want to be 
> hitting a third-party server.  We shouldn't require that.
>
> For (c): we don't want to prevent building in scenarios that can't hit a 
> network during the build.
>
>
> -Todd
>
>
> On Wed, Nov 18, 2015 at 10:58 PM, Todd Fiala  wrote:
>
>>
>>
>> On Wed, Nov 18, 2015 at 10:06 PM, Todd Fiala 
>> wrote:
>>
>>> Hey Zachary,
>>>
>>> I think the time pressure has gotten the better of me, so I want to
>>> apologize for getting snippy about the static bindings of late.  I am
>>> confident we will get to a good solution for removing that dependency, but
>>> I can certainly wait for a solution (using an alternate approach in our
>>> branch) until we arrive at something more palatable to everyone.
>>>
>>> Regarding the bindings as service idea:
>>>
>>> How quickly do you think you could flesh out the bindings as a service
>>> idea?  With a relatively strong dislike for the static approach I'm taking,
>>> I can back off that and just use my current code here in a downstream
>>> branch for now.  Ultimately I want to remove the requirement for swig, but
>>> I can probably achieve that without doing it in up

Re: [lldb-dev] LLDB Windows Python Bindings

[Zachary Turner via lldb-dev]

+lldb-dev since this could be useful to other people.

I'm actively working on getting Python 3.5 support working.  If you want to
go this route, it will make your life much easier.  But I don't have a
fully passing test suite yet, there are still about 30 failing tests.  So
consider Python 3.5 experimental, and at your own risk.  (Patches welcome!)

If you want to go with Python 2.7 then the test suite should pass fully,
but there are 1-2 flaky timeouts that happen occasionally.  But it is a lot
more work to set up and nobody ever gets it right because it's so
complicated.

So, *for Python 3.5:*
1) You must use Visual Studio 2015.  2013 or earlier will not work.
2) Install Python 3.5 from python.org
3) Run CMake with -DPYTHON_HOME=C:\Python35
4) That's it.  You're done.

You don't need to build your own Python 3.5, which it sounds like what
you're doing.  If you're not trying to build your own Python 3.5, then
check to make sure your PYTHONPATH is not set to anything.  Mixed
environments could be a problem.  If that doesn't fix it, then debugging
into it a little bit could help.  For example, try running
C:\Python35\python_d.exe and then typing "import _ctypes".  It should
work.  If you're doing a release build then try making sure that
finish_swig is running python.exe, and if you're doing a debug build then
try making sure that finish_swig is running python_d.exe.

*For Python 2.7*
1) You must *not *be using Visual Studio 2015.  Only 2013 will work
2) Can you tell me what command line you're invoking CMake with?
3) Can you open up build.ninja and search for this line:

*Custom command for tools\lldb\CMakeFiles\finish_swig*

And then paste the line under it back into this email?

On Thu, Nov 19, 2015 at 8:55 AM Aidan Dodds  wrote:

> Hi Zachary,
>
> I am currently trying to produce a windows build of LLDB that has python
> bindings.
> There seems to be a lot of discussion on the mailing list regarding
> python at the moment.
>
> I couldn't see any documentation or instructions anywhere about how to
> produce them.
>
> I have tried with python2.7 and 3.5 varying degrees of success.
> While I was able to produce a debug version of the 2.7 interpreter,
> CMake seems to be looking for
> python27_d+.lib, and I am not sure why the + has been appended.
> My build using python 3.5 fails on finish_swig, with: ImportError: No
> module named '_ctypes'.
>
> It would be very much appreciated if you could point me to a reference
> for building the bindings
> on windows or even just give me some direction to the simplest way to
> produce them.
>
> Also out of interest what is that state of the lldb test suite on windows?
>
> Thanks,
> Aidan
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

I wasn't planning on working on this immediately, but given the outcome of
the recent static bindings work, I can re-prioritize.  I don't know how
long it will take, because honestly writing this kind of thing in Python is
new to me.. to make an understatement.  But I'll get it done.  Give me
until mid next week and I'll post an update.

On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  wrote:

> On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner 
> wrote:
>
>> Just to re-iterate, if we use the bindings as a service, then I envision
>> checking the bindings in.  This addresses a lot of the potential pitfalls
>> you point out, such as the "oops, you can't hit the network, no build for
>> you" and the issue of production build flows not wanting to hit a third
>> party server, etc.
>>
>> So if we do that, then I don't think falling back to local generation
>> will be an issue (or important) in practice.  i.e. it won't matter if you
>> can't hit the network.  The reason I say this is that if you can't hit the
>> network you can't check in code either.  So, sure, there might be a short
>> window where you can't do a local build , but that would only affect you if
>> you were actively modifying a swig interface file AND you were actively
>> without a network connection.  The service claims 99.95% uptime, and it's
>> safe to say we are looking at significantly less than 100% usage of the
>> server (given checked in bindings), so I think we're looking at once a year
>> -- if that -- that anyone anywhere has an issue with being able to access
>> the service.
>>
>>
> That seems fine.
>
>
>> And, as you said, the option can be provided to change the host that the
>> service runs on, so someone could run one internally.
>>
>> But do note, that if the goal here is to get the SWIG version bumped in
>> the upstream, then we will probably take advantage of some of these new
>> SWIG features, which may not work in earlier versions of SWIG.  So you
>> should consider how useful it will be to be able to run this server
>> internally, because if you can't run a new version of swig locally, then
>> can you run it internally anywhere?  I don't know, I'll leave that for you
>> to figure out.
>>
>>
> That also seems fine.  And yes, we can work it out on our end.
>
> We'd need to make sure that developer flows would pick up the need to
> generate the bindings again if binding surface area changed, but that is no
> different than now.
>
>
>> Either way, it will definitely have the ability to use a different host,
>> because that's the easiest way to debug theclient and server (i.e. run them
>> on the same machine with 127.0.0.1)
>>
>>
> Yep, sounds right.
>
>
>> On Thu, Nov 19, 2015 at 8:00 AM Todd Fiala  wrote:
>>
>>> For the benefit of continuity in conversation, here is what you had to
>>> say about it before:
>>>
>>> > One possibility (which I mentioned to you offline, but I'll put it here 
>>> > for
>>> others to see) is that we make a swig bot which is hosted in the cloud much
>>> like our public build bots.  We provide a Python script that can be run on
>>> your machine, which sends requests over to the swig bot to run swig and
>>> send back the results.  Availability of the service would be governed by
>>> the SLA of Google Compute Engine, viewable 
>>> here:https://cloud.google.com/compute/sla?hl=en
>>>
>>> > If we do something like this, it would allow us to raise the SWIG version
>>> in the upstream, and at that point I can see some benefit in checking the
>>> bindings in.  Short of that, I still dont' see the value proposition in
>>> checking bindings in to the repo.  [bits deleted]
>>>
>>> > If it means we can get off of SWIG 1.x in the upstream, I will do the work
>>> to make remote swig generation service and get it up and running.
>>>
>>>
>>> I'd like feedback from others on this.  Is this something we want to 
>>> consider doing?
>>>
>>> From my perspective, this seems reasonable to look into doing if we:
>>>
>>> (a) have the service code available, and
>>>
>>> (b) if we so choose, we can readily have the script hit another server (so 
>>> that a consumer can have the entire setup on an internal network), and
>>>
>>> (c: option 1) be able to fall back to generate with swig locally as we do 
>>> now in the event that we can't hit the server
>>>
>>> (c: option 2) rather than fall back to swig generation, use swig generation 
>>> as primary (as it is now) but, if a swig is not found, then do the 
>>> get-bindings-as-a-service flow.
>>>
>>> This does open up multiple ways to do something, but I think we need to 
>>> avoid a failure mode that says "Oops, you can't hit the network.  Sorry, no 
>>> lldb build for you."
>>>
>>>
>>> Reasoning:
>>>
>>> For (a): just so we all know what we're using.
>>>
>>> For (b): I can envision production build flows that will not want to be 
>>> hitting a third-party server.  We shouldn't require that.
>>>
>>> For (c): we don't want to prevent building in scenarios that can't hit a 
>>> network d

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

Well some of the bugfixes are actually worth mentioning, because we
actually have bugs on the C++ side that we can't fix because then SWIG
won't be able to process the header files.  For example, if SWIG sees this
in a header file, it errors out and can't even proceed.

enum Foo : unsigned {
Bar = 0x
};

So instead we have to write this:

enum Foo {
Bar = 0x
};

According to the standard this produces an unsigned enum, but MSVC is
non-comformant here, and we get a signed enum.  So we have hundreds of
warnings disabled as a result of this, and it's a legitimate bug on the C++
side that we would like to fix, irrespective of SWIG.

Feature-wise, here's a potentially incomplete list:

* Typemaps can re-use other typemaps, similar to how functions can call
other functions
* A new -debug-tmsearch command line option which helps debugging typemap
problems.  For example, when you're looking at some generated code and
trying to figure out which typemap generated it.  I know I've had to do
this many times during the Python 3 conversion, and this would have helped.
* Template classes are supported.  We probably don't care about this, but
it's an interesting thought.
* -builtin option supports generating higher performance wrapping code.
Read the SWIG documentation about -builtin


JavaScript support has been mentioned as someone someone needs on more than
one occasion.  The name of the person interested escapes me, but this
wasn't added until SWIG 3.x.  Other languages like Go and Lua aren't in 1.x
of SWIG either, I don't believe.

I'll try to think of some more.

On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:

> I'm out next week, but I can help if needed after that.
>
> Related to all this, you have mentioned a few times that there are newer
> swig features you want to use.
>
> Can you enumerate the features not present in 1.x but present in 3.x that
> you want to take advantage of, and what benefits they will bring us?  (I'm
> not referring to bug fixes in bindings, but actual features that bring
> something new that we didn't have before).
>
> Thanks!
>
> -Todd
>
> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
> wrote:
>
>> I wasn't planning on working on this immediately, but given the outcome
>> of the recent static bindings work, I can re-prioritize.  I don't know how
>> long it will take, because honestly writing this kind of thing in Python is
>> new to me.. to make an understatement.  But I'll get it done.  Give me
>> until mid next week and I'll post an update.
>>
>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala  wrote:
>>
>>> On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner 
>>> wrote:
>>>
 Just to re-iterate, if we use the bindings as a service, then I
 envision checking the bindings in.  This addresses a lot of the potential
 pitfalls you point out, such as the "oops, you can't hit the network, no
 build for you" and the issue of production build flows not wanting to hit a
 third party server, etc.

 So if we do that, then I don't think falling back to local generation
 will be an issue (or important) in practice.  i.e. it won't matter if you
 can't hit the network.  The reason I say this is that if you can't hit the
 network you can't check in code either.  So, sure, there might be a short
 window where you can't do a local build , but that would only affect you if
 you were actively modifying a swig interface file AND you were actively
 without a network connection.  The service claims 99.95% uptime, and it's
 safe to say we are looking at significantly less than 100% usage of the
 server (given checked in bindings), so I think we're looking at once a year
 -- if that -- that anyone anywhere has an issue with being able to access
 the service.


>>> That seems fine.
>>>
>>>
 And, as you said, the option can be provided to change the host that
 the service runs on, so someone could run one internally.

 But do note, that if the goal here is to get the SWIG version bumped in
 the upstream, then we will probably take advantage of some of these new
 SWIG features, which may not work in earlier versions of SWIG.  So you
 should consider how useful it will be to be able to run this server
 internally, because if you can't run a new version of swig locally, then
 can you run it internally anywhere?  I don't know, I'll leave that for you
 to figure out.


>>> That also seems fine.  And yes, we can work it out on our end.
>>>
>>> We'd need to make sure that developer flows would pick up the need to
>>> generate the bindings again if binding surface area changed, but that is no
>>> different than now.
>>>
>>>
 Either way, it will definitely have the ability to use a different
 host, because that's the easiest way to debug theclient and server (i.e.
 run them on the same machine with 127.0.0.1)


>>> Yep, sounds right.
>>>
>>>
 On Thu, N

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner  wrote:

> Well some of the bugfixes are actually worth mentioning, because we
> actually have bugs on the C++ side that we can't fix because then SWIG
> won't be able to process the header files.  For example, if SWIG sees this
> in a header file, it errors out and can't even proceed.
>
> enum Foo : unsigned {
> Bar = 0x
> };
>
> So instead we have to write this:
>
> enum Foo {
> Bar = 0x
> };
>
> According to the standard this produces an unsigned enum, but MSVC is
> non-comformant here, and we get a signed enum.  So we have hundreds of
> warnings disabled as a result of this, and it's a legitimate bug on the C++
> side that we would like to fix, irrespective of SWIG.
>
> Feature-wise, here's a potentially incomplete list:
>
> * Typemaps can re-use other typemaps, similar to how functions can call
> other functions
> * A new -debug-tmsearch command line option which helps debugging typemap
> problems.  For example, when you're looking at some generated code and
> trying to figure out which typemap generated it.  I know I've had to do
> this many times during the Python 3 conversion, and this would have helped.
> * Template classes are supported.  We probably don't care about this, but
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.
> Read the SWIG documentation about -builtin
>
Grr, do embedded links not work on the mailing list or something?

http://www.swig.org/Doc3.0/Python.html#Python_builtin_types


>
> JavaScript support has been mentioned as someone someone needs on more
> than one occasion.  The name of the person interested escapes me, but this
> wasn't added until SWIG 3.x.  Other languages like Go and Lua aren't in 1.x
> of SWIG either, I don't believe.
>
> I'll try to think of some more.
>
>
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>
>> I'm out next week, but I can help if needed after that.
>>
>> Related to all this, you have mentioned a few times that there are newer
>> swig features you want to use.
>>
>> Can you enumerate the features not present in 1.x but present in 3.x that
>> you want to take advantage of, and what benefits they will bring us?  (I'm
>> not referring to bug fixes in bindings, but actual features that bring
>> something new that we didn't have before).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>> wrote:
>>
>>> I wasn't planning on working on this immediately, but given the outcome
>>> of the recent static bindings work, I can re-prioritize.  I don't know how
>>> long it will take, because honestly writing this kind of thing in Python is
>>> new to me.. to make an understatement.  But I'll get it done.  Give me
>>> until mid next week and I'll post an update.
>>>
>>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
>>> wrote:
>>>
 On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner 
 wrote:

> Just to re-iterate, if we use the bindings as a service, then I
> envision checking the bindings in.  This addresses a lot of the potential
> pitfalls you point out, such as the "oops, you can't hit the network, no
> build for you" and the issue of production build flows not wanting to hit 
> a
> third party server, etc.
>
> So if we do that, then I don't think falling back to local generation
> will be an issue (or important) in practice.  i.e. it won't matter if you
> can't hit the network.  The reason I say this is that if you can't hit the
> network you can't check in code either.  So, sure, there might be a short
> window where you can't do a local build , but that would only affect you 
> if
> you were actively modifying a swig interface file AND you were actively
> without a network connection.  The service claims 99.95% uptime, and it's
> safe to say we are looking at significantly less than 100% usage of the
> server (given checked in bindings), so I think we're looking at once a 
> year
> -- if that -- that anyone anywhere has an issue with being able to access
> the service.
>
>
 That seems fine.


> And, as you said, the option can be provided to change the host that
> the service runs on, so someone could run one internally.
>
> But do note, that if the goal here is to get the SWIG version bumped
> in the upstream, then we will probably take advantage of some of these new
> SWIG features, which may not work in earlier versions of SWIG.  So you
> should consider how useful it will be to be able to run this server
> internally, because if you can't run a new version of swig locally, then
> can you run it internally anywhere?  I don't know, I'll leave that for you
> to figure out.
>
>
 That also seems fine.  And yes, we can work it out on our end.

 We'd need to make sure that developer flows would pick up the need to
 generate 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

Doh!  lol

On Thu, Nov 19, 2015 at 10:57 AM Sean Callanan  wrote:

> I don’t think so, this was just an embedded link to your hard drive:
>
> file:///C:/tools/swigwin-3.0.7/Doc/Manual/Python.html#Python_builtin_types
>
> Sean
>
> On Nov 19, 2015, at 10:51 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner 
> wrote:
>
>> Well some of the bugfixes are actually worth mentioning, because we
>> actually have bugs on the C++ side that we can't fix because then SWIG
>> won't be able to process the header files.  For example, if SWIG sees this
>> in a header file, it errors out and can't even proceed.
>>
>> enum Foo : unsigned {
>> Bar = 0x
>> };
>>
>> So instead we have to write this:
>>
>> enum Foo {
>> Bar = 0x
>> };
>>
>> According to the standard this produces an unsigned enum, but MSVC is
>> non-comformant here, and we get a signed enum.  So we have hundreds of
>> warnings disabled as a result of this, and it's a legitimate bug on the C++
>> side that we would like to fix, irrespective of SWIG.
>>
>> Feature-wise, here's a potentially incomplete list:
>>
>> * Typemaps can re-use other typemaps, similar to how functions can call
>> other functions
>> * A new -debug-tmsearch command line option which helps debugging typemap
>> problems.  For example, when you're looking at some generated code and
>> trying to figure out which typemap generated it.  I know I've had to do
>> this many times during the Python 3 conversion, and this would have helped.
>> * Template classes are supported.  We probably don't care about this, but
>> it's an interesting thought.
>> * -builtin option supports generating higher performance wrapping code.
>> Read the SWIG documentation about -builtin
>>
> Grr, do embedded links not work on the mailing list or something?
>
> http://www.swig.org/Doc3.0/Python.html#Python_builtin_types
>
>
>>
>> JavaScript support has been mentioned as someone someone needs on more
>> than one occasion.  The name of the person interested escapes me, but this
>> wasn't added until SWIG 3.x.  Other languages like Go and Lua aren't in 1.x
>> of SWIG either, I don't believe.
>>
>> I'll try to think of some more.
>>
>>
>> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>>
>>> I'm out next week, but I can help if needed after that.
>>>
>>> Related to all this, you have mentioned a few times that there are newer
>>> swig features you want to use.
>>>
>>> Can you enumerate the features not present in 1.x but present in 3.x
>>> that you want to take advantage of, and what benefits they will bring us?
>>>  (I'm not referring to bug fixes in bindings, but actual features that
>>> bring something new that we didn't have before).
>>>
>>> Thanks!
>>>
>>> -Todd
>>>
>>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>>> wrote:
>>>
>>>> I wasn't planning on working on this immediately, but given the outcome
>>>> of the recent static bindings work, I can re-prioritize.  I don't know how
>>>> long it will take, because honestly writing this kind of thing in Python is
>>>> new to me.. to make an understatement.  But I'll get it done.  Give me
>>>> until mid next week and I'll post an update.
>>>>
>>>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
>>>> wrote:
>>>>
>>>>> On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner 
>>>>> wrote:
>>>>>
>>>>>> Just to re-iterate, if we use the bindings as a service, then I
>>>>>> envision checking the bindings in.  This addresses a lot of the potential
>>>>>> pitfalls you point out, such as the "oops, you can't hit the network, no
>>>>>> build for you" and the issue of production build flows not wanting to 
>>>>>> hit a
>>>>>> third party server, etc.
>>>>>>
>>>>>> So if we do that, then I don't think falling back to local generation
>>>>>> will be an issue (or important) in practice.  i.e. it won't matter if you
>>>>>> can't hit the network.  The reason I say this is that if you can't hit 
>>>>>> the
>>>>>> network you can&#x

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

Derp, I forgot C++11 support.  Some of it is not useful to us given the
limited nature of the SB API, but certain things could be useful.  Being
able to transition to enum classes is nice, for example.

Anyway, there's a lot here, so feel free to read through the document.
http://www.swig.org/Doc3.0/CPlusPlus11.html


On Thu, Nov 19, 2015 at 10:50 AM Zachary Turner  wrote:

> Well some of the bugfixes are actually worth mentioning, because we
> actually have bugs on the C++ side that we can't fix because then SWIG
> won't be able to process the header files.  For example, if SWIG sees this
> in a header file, it errors out and can't even proceed.
>
> enum Foo : unsigned {
> Bar = 0x
> };
>
> So instead we have to write this:
>
> enum Foo {
> Bar = 0x
> };
>
> According to the standard this produces an unsigned enum, but MSVC is
> non-comformant here, and we get a signed enum.  So we have hundreds of
> warnings disabled as a result of this, and it's a legitimate bug on the C++
> side that we would like to fix, irrespective of SWIG.
>
> Feature-wise, here's a potentially incomplete list:
>
> * Typemaps can re-use other typemaps, similar to how functions can call
> other functions
> * A new -debug-tmsearch command line option which helps debugging typemap
> problems.  For example, when you're looking at some generated code and
> trying to figure out which typemap generated it.  I know I've had to do
> this many times during the Python 3 conversion, and this would have helped.
> * Template classes are supported.  We probably don't care about this, but
> it's an interesting thought.
> * -builtin option supports generating higher performance wrapping code.
> Read the SWIG documentation about -builtin
>
> JavaScript support has been mentioned as someone someone needs on more
> than one occasion.  The name of the person interested escapes me, but this
> wasn't added until SWIG 3.x.  Other languages like Go and Lua aren't in 1.x
> of SWIG either, I don't believe.
>
> I'll try to think of some more.
>
>
> On Thu, Nov 19, 2015 at 10:17 AM Todd Fiala  wrote:
>
>> I'm out next week, but I can help if needed after that.
>>
>> Related to all this, you have mentioned a few times that there are newer
>> swig features you want to use.
>>
>> Can you enumerate the features not present in 1.x but present in 3.x that
>> you want to take advantage of, and what benefits they will bring us?  (I'm
>> not referring to bug fixes in bindings, but actual features that bring
>> something new that we didn't have before).
>>
>> Thanks!
>>
>> -Todd
>>
>> On Thu, Nov 19, 2015 at 10:14 AM, Zachary Turner 
>> wrote:
>>
>>> I wasn't planning on working on this immediately, but given the outcome
>>> of the recent static bindings work, I can re-prioritize.  I don't know how
>>> long it will take, because honestly writing this kind of thing in Python is
>>> new to me.. to make an understatement.  But I'll get it done.  Give me
>>> until mid next week and I'll post an update.
>>>
>>> On Thu, Nov 19, 2015 at 10:12 AM Todd Fiala 
>>> wrote:
>>>
 On Thu, Nov 19, 2015 at 9:44 AM, Zachary Turner 
 wrote:

> Just to re-iterate, if we use the bindings as a service, then I
> envision checking the bindings in.  This addresses a lot of the potential
> pitfalls you point out, such as the "oops, you can't hit the network, no
> build for you" and the issue of production build flows not wanting to hit 
> a
> third party server, etc.
>
> So if we do that, then I don't think falling back to local generation
> will be an issue (or important) in practice.  i.e. it won't matter if you
> can't hit the network.  The reason I say this is that if you can't hit the
> network you can't check in code either.  So, sure, there might be a short
> window where you can't do a local build , but that would only affect you 
> if
> you were actively modifying a swig interface file AND you were actively
> without a network connection.  The service claims 99.95% uptime, and it's
> safe to say we are looking at significantly less than 100% usage of the
> server (given checked in bindings), so I think we're looking at once a 
> year
> -- if that -- that anyone anywhere has an issue with being able to access
> the service.
>
>
 That seems fine.


> And, as you said, the option can be provided to change the host that
> the service runs on, so someone could run one internally.
>
> But do note, that if the goal here is to get the SWIG version bumped
> in the upstream, then we will probably take advantage of some of these new
> SWIG features, which may not work in earlier versions of SWIG.  So you
> should consider how useful it will be to be able to run this server
> internally, because if you can't run a new version of swig locally, then
> can you run it internally anywhere?  I don't know, I'll leave that for you
> 

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

On Thu, Nov 19, 2015 at 10:28 AM Todd Fiala  wrote:

> Some other points we need to consider on the bindings-as-service idea:
>
> * The service should be exposed via secure connection (https/ssl/etc.)
>  This might already be guaranteed on the Google end by virtue of the
> endpoint, but we'll want to make sure we can have a secure connection.
>  (This will be a non-issue for standing up a custom server, but the
> official one should have this taken care of).
>

If the only thing we're sending from client -> server is packaged up source
code which is already available on the open source repository, and the
server doesn't require authentication, is this necessary?

If so, does this mean everyone needs to generate a cert locally?

>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Windows Python Bindings

[Zachary Turner via lldb-dev]

-old list
+new list

On Thu, Nov 19, 2015 at 1:28 PM Zachary Turner  wrote:

> Python 2.7 literally does not even compile with VS 2015, you would have to
> fork it and fix the compilation errors.  I've tried to upstream fixes and
> they won't accept them, since 2.7 is "dead" except for maintenance and
> security fixes.
>
> On Thu, Nov 19, 2015 at 1:27 PM Ted Woodward 
> wrote:
>
>> Why can’t we use VS 2015 with Python 2.7?
>>
>>
>>
>> --
>>
>> Qualcomm Innovation Center, Inc.
>>
>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
>> Linux Foundation Collaborative Project
>>
>>
>>
>> *From:* lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] *On Behalf Of 
>> *Zachary
>> Turner via lldb-dev
>> *Sent:* Thursday, November 19, 2015 12:01 PM
>> *To:* Aidan Dodds; LLDB
>> *Subject:* Re: [lldb-dev] LLDB Windows Python Bindings
>>
>>
>>
>> +lldb-dev since this could be useful to other people.
>>
>>
>>
>> I'm actively working on getting Python 3.5 support working.  If you want
>> to go this route, it will make your life much easier.  But I don't have a
>> fully passing test suite yet, there are still about 30 failing tests.  So
>> consider Python 3.5 experimental, and at your own risk.  (Patches welcome!)
>>
>>
>>
>> If you want to go with Python 2.7 then the test suite should pass fully,
>> but there are 1-2 flaky timeouts that happen occasionally.  But it is a lot
>> more work to set up and nobody ever gets it right because it's so
>> complicated.
>>
>>
>>
>> So, *for Python 3.5:*
>>
>> 1) You must use Visual Studio 2015.  2013 or earlier will not work.
>>
>> 2) Install Python 3.5 from python.org
>>
>> 3) Run CMake with -DPYTHON_HOME=C:\Python35
>>
>> 4) That's it.  You're done.
>>
>>
>>
>> You don't need to build your own Python 3.5, which it sounds like what
>> you're doing.  If you're not trying to build your own Python 3.5, then
>> check to make sure your PYTHONPATH is not set to anything.  Mixed
>> environments could be a problem.  If that doesn't fix it, then debugging
>> into it a little bit could help.  For example, try running
>> C:\Python35\python_d.exe and then typing "import _ctypes".  It should
>> work.  If you're doing a release build then try making sure that
>> finish_swig is running python.exe, and if you're doing a debug build then
>> try making sure that finish_swig is running python_d.exe.
>>
>>
>>
>> *For Python 2.7*
>>
>> 1) You must *not *be using Visual Studio 2015.  Only 2013 will work
>>
>> 2) Can you tell me what command line you're invoking CMake with?
>>
>> 3) Can you open up build.ninja and search for this line:
>>
>>
>>
>> *Custom command for tools\lldb\CMakeFiles\finish_swig*
>>
>>
>>
>> And then paste the line under it back into this email?
>>
>>
>>
>> On Thu, Nov 19, 2015 at 8:55 AM Aidan Dodds  wrote:
>>
>> Hi Zachary,
>>
>> I am currently trying to produce a windows build of LLDB that has python
>> bindings.
>> There seems to be a lot of discussion on the mailing list regarding
>> python at the moment.
>>
>> I couldn't see any documentation or instructions anywhere about how to
>> produce them.
>>
>> I have tried with python2.7 and 3.5 varying degrees of success.
>> While I was able to produce a debug version of the 2.7 interpreter,
>> CMake seems to be looking for
>> python27_d+.lib, and I am not sure why the + has been appended.
>> My build using python 3.5 fails on finish_swig, with: ImportError: No
>> module named '_ctypes'.
>>
>> It would be very much appreciated if you could point me to a reference
>> for building the bindings
>> on windows or even just give me some direction to the simplest way to
>> produce them.
>>
>> Also out of interest what is that state of the lldb test suite on windows?
>>
>> Thanks,
>> Aidan
>>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] bindings as service idea

[Zachary Turner via lldb-dev]

On Thu, Nov 19, 2015 at 1:38 PM Ted Woodward 
wrote:

> For our builds at QUIC, we're not interested in hitting an external server
> to get code. So we'd either hit the server when needed and check in the
> resultant bindings, or  (preferably) use bindings from upstream.
>

Right, and this is actually what I'm proposing.  You only hit the service
when you are editing a swig interface file and you need to generate updated
code.  Otherwise the latest version of the bindings is already checked out
in your repository.

And even then, you only *really* need to hit it when you physically cannot
(for whatever reason) or do not want to install swig on your machine.
There can still be a local path, that says "use the swig installed on my
machine".  Of course, if we're going to standardize on a version, it will
be the version of swig that the service runs.   So whatever version you
have on your machine -- if you intend to check in those bindings -- need to
be the same version used by the service.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] FW: LLDB Windows Python Bindings

[Zachary Turner via lldb-dev]

On Thu, Nov 19, 2015 at 1:39 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>  Why can’t we use VS 2015 with Python 2.7?
>

Python 2.7 literally does not even compile with VS 2015, you would have to
fork it and fix the compilation errors.  I've tried to upstream fixes and
they won't accept them, since 2.7 is "dead" except for maintenance and
security fixes.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] reply： lldb debug jit-compiled code with llvm on windows

[Zachary Turner via lldb-dev]

Can you also try clang-cl and see if it works?

On Fri, Nov 20, 2015 at 3:02 AM Tamas Berghammer via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I don't know how JIT debugging should work on WIndows with MSVC but I
> don't think LLDB support it in any way. What I wrote should be true on
> Linux (and on some related) systems. You might be able to get the same
> results on Windows if you use lli (LLVM based JIT runner) but I have no
> knowledge if it will work or not.
>
> On Fri, Nov 20, 2015 at 8:56 AM haifeng_q  wrote:
>
>> My analysis of the code, the reasons are:
>>
>> Since the debugging process is MSVC compiler, there is no DWARF debugging
>> information. So lldb get __jit_debug_register_code and
>> __it_debug_descriptor symbol debugging process fails, and
>> __jit_debug_register_code not support MSVC.
>> I do not know whether correct?
>>
>> -- original message--
>> *From:*"Tamas Berghammer";tbergham...@google.com;
>> Date*:*2015年11月19日 PM 8:37
>> *receive:* " "; "lldb-dev";
>>
>> *Subject:* Re: [lldb-dev] lldb debug jit-compiled code with llvm on
>> windows
>>
>> In theory you don't have to do anything special to debug some JIT-ed code
>> as everything should just work (based on the gdb jit interface). In
>> practice I tried it out a few days ago and it wasn't working at all even in
>> the case when the application is launched under LLDB (not with attach).
>> LLDB was understanding the eh_frame for the JIT-ed code but didn't found
>> the debug info for unknown reason. We should investigate it and try to fix
>> it sometime. We (lldb for android developers) plan to do it sometime but if
>> you are interested in it then please feel free to take a look and let us
>> know if you have any question.
>>
>> Tamas
>>
>> On Thu, Nov 19, 2015 at 8:40 AM haifeng_q via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> hi,
>>> process A generate function Func1 code with llvm jit compiler, and calls
>>> Func1. modeled on "Kaleidoscope: Adding Debug Information" add debug
>>> information. how to use LLDB to attach process A to debug this function, add
>>> a breakpoint in the function?
>>>
>>> thanks!
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB Windows Python Bindings

[Zachary Turner via lldb-dev]

On Fri, Nov 20, 2015 at 10:05 AM Aidan Dodds  wrote:

> First off thanks for opening that up to the mailing list, it will be good
> if discussion of this is useful to others.
>
> From the python 3.5 case:
> I'm not using ninja.build, but instead just compiling from the visual
> studio ide.  However, the custom build step I think you were referring to
> for finish_swig seems to be:
>
> setlocal
> "C:\Program Files (x86)\CMake\bin\cmake.exe" -E copy
> C:\Python35\python35.dll D:\rs_project\rs_llvm_build\$(Configuration)\bin
> if %errorlevel% neq 0 goto :cmEnd
> :cmEnd
> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
> :cmErrorLevel
> exit /b %1
> :cmDone
> if %errorlevel% neq 0 goto :VCEnd
>
>
> The exact error message for building finish_swig was the following:
>
> -- Build started: Project: finish_swig, Configuration: Debug x64 --
> Build started 20/11/2015 17:27:07.
> InitializeBuildStatus:
>   Touching "x64\Debug\finish_swig\finish_swig.tlog\unsuccessfulbuild".
> CustomBuild:
>   Python script sym-linking LLDB Python API
>   Traceback (most recent call last):
> File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 383, in 
>   main(sys.argv[1:])
> File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 326, in main
>   nResult, strMsg =
> run_post_process_for_each_script_supported(dictArgs)
> File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 281, in run_post_process_for_each_script_supported
>   vDictArgs)
> File
> "D:/rs_project/rs_llvm/tools/lldb/scripts/finishSwigWrapperClasses.py",
> line 223, in run_post_process
>   module = __import__(strModuleName)
> File
> "d:\rs_project\rs_llvm\tools\lldb\scripts\python\finishSwigPythonLLDB.py",
> line 42, in 
>   import ctypes   # Invoke Windows API for creating symlinks
> File "C:\Python35\lib\ctypes\__init__.py", line 7, in 
>   from _ctypes import Union, Structure, Array
>
>   ImportError: No module named '_ctypes'
>
Looks like this is an x64 build of LLDB, so it would need to be an x64
installation of Python 3.5  To be honest I haven't tested Python 3.5 with
x64, so I'm not sure what kind of issues might arise.  What happens if you
run C:\Python35\python_d.exe and then write "import ctypes".  Does it work?




>
>
> For the python 2.7 case:
>
> The error I see in CMake is the following:
>
> -- Found Python version 2.7.10+
>
> Unable to find C:/Python27/libs/python27+_d.lib
>
> Unable to find C:/Python27/libs/python27+.lib
>
> Unable to find C:/Python27/python27+_d.dll
>
> Unable to find C:/Python27/python27+.dll
>
> Python installation is corrupt. Python support will be disabled for this
> build.
>
Yea, I'm honestly not sure either.  I think you will need to do some CMake
debugging to figure this out.  Usually what I do is crack open the CMake
scripts and add some calls to the message() function at various points, to
see if you can figure out where this + is coming from.


>
> I'm not sure where the + comes from however...
>
> Aidan@AIDAN-PC /c/Python27
> $ python --version
> Python 2.7.10
>
> Aidan@AIDAN-PC /c/Python27
> $ python_d --version
> Python 2.7.10
>
This makes me think your'e using cygwin.  This isn't explicitly
unsupported, but also I don't know of anyone else Windows using cygwin, so
I can't guarantee there are no problems on the CMake side for cygwin
users.  If you do find some though, feel free to fix.


>
> As for the CMake options its again complicated because I'm using cmake-gui.
> Hopefully the relevant params are:
>
> PYTHON_EXCUTABLE = c:/python27/python_d.exe
> PYTHON_HOME = c:/python27
> LLDB_DISABLE_PYTHON = False
> LLDB_RELOCATABLE_PYTHON = False
> SWIG_DIR = d:/swig/lib
> SWIG_EXECUTABLE = d:/swig/swig.exe
> SWIG_VERSION = 3.0.5
>
>
> I am using Visual Studio 2013 and doing an x86_64 build.
> I compiled the python interpreter with the same version also.
>
> Its not a requirement for me to custom python for any reason, I just
> remember there being issues with using the release package.
>
Yea, what makes 2.7 so bad.  If you want to run the test suite, you have to
have a custom interpreter.  And then all the difficulty that goes along
with that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

Seems reasonable.  I will make a best effort to get as many of them as I
can.

On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:

> Zach, I would also like to get rid of all global variables in the process
> of this change. The history goes like this: a long time ago someone wrote
> the initial dotest.py and parsed the options manually and stored results in
> global variables. Later, someone converted the options over to use a python
> library to parse the options, but we mostly copied the options from the
> options dictionary over into the globals and still use the globals all over
> the code. It would be great if we had at most one global variable that is
> something like "g_options" and anyone that was using any global variables
> will switch over to use the "g_options." instead. Then we don't have to
> make copies and we can let the g_options contain all settings that are
> required.
>
> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I would like to do a complete audit of dotest's command line options,
> find out who's using what, and then potentially delete anything that isn't
> being used.  There's a mess of command line options in use, to the point
> that it's often hard to find free letters to use for new options.
> >
> > I created this spreadsheet with a complete list of command line options,
> their descriptions, and a place for people to enter what options they're
> using or do not want to be deleted.
> >
> >
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> >
> > If someone has already written YES in the box that indicates they need
> the option, please don't overwrite it.  If you write YES in a box, please
> provide at least a small rationale for why this option is useful to you.
> Feel free to add additional rationale if someone has already added some
> rationale.
> >
> > I'm going to have a couple days in mid-December and do this cleanup, so
> I'd like to get a solid picture of what options are not needed before
> then.  After people have had some time to look over this, I'll go through
> the results and decide what to do with each one, and then send out another
> email with a proposed action column for each command line option.
> >
> > Please do take the time to have a look at this, because any option that
> doesn't have a YES in it after a couple of weeks I'm going to assume is a
> candidate for deletion.
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Exclusively build and install LLDB?

[Zachary Turner via lldb-dev]

LLDB links against clang and llvm.  How would an lldb-only target work?
 i.e. how would you build lldb without first building clang and llvm?
Unless I'm misunderstanding the purpose of your question:

As for the install, are you saying that running "ninja install" does not
install lldb?  If so that's a bug and shoudl be fixed in the CMake.

On Sun, Nov 22, 2015 at 5:44 PM Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Are there plans to add new target: lldb-only and lldb-install? There
> are already similar targets for Clang.
>
> I'm debugging LLDB on NetBSD and I'm having very bad time building
> everything with debug symbols. There is also popular request from
> NetBSD users to just install lldb without conflicting with Clang and LLV
> M.
>
> I was looking at Open Source distributions with a LLDB package, for
> example ArchLinux is manually copying files from the build...
>
> I would like to skip building unnecessary parts and then focus on
> installing only the LLDB package... otherwise I need 64GB of
> RAM+storage and a lot of time to produce new package.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJWUm4GAAoJEEuzCOmwLnZsvNsP/RLpRVdnwC8Di9wIoovAGPEk
> ybsJeHHspBQNr304FEc5cgA67LOaDBNLGNGbIMCOCoSd4XnvnL484lSy2hA4nk/M
> 8N1XeRNdaMlw4jSexbZU7BTkIvBriTjU9ZakfFV4VbHFN04Kvf8U7nYLhQvCvA+i
> +g+m0xNrBccHXPqSaZXWHH2qScEL7AibMR96UsxEOSnZFxgZoEgRDCxaETyIwtai
> 13EOWxSaIxAjRzylfirZRWNsujGWfOx3u5/es5Ot4t/bRy+z5gnKG2mn1UONAuON
> rwpXh3hEnkhMIMvwYpjA2AyVKog1jSroMCh9ziDpGP8h77TmP8DrGg6kEww37Hjl
> hT2LF3WZLLsi3shVnEpgHZQYHTiqLUQo4rTJOTJaXWa8PR17c884WXsoeC/kvUIU
> ceyD2KaQv50dMA0aPkdp+hrHVa6Fws/af4S/ANHpqSFXgSYR2tYqs76mILd7FA7Y
> TCWXM2Pd6P9PbobHlqdVvN4KeANUIa0Jowto44yNGLv6WZN7wS4QMrL7UtYfbK9b
> rIZD1yiXg5jYcCC4QDmeiO2jxp8pVy7AP8w7S2UgMrMorbWb1rg7yY5jJFtqFQoT
> vxJZMyvOVdF4ckJUlFY/k1cEIPE1920rEcRooBbZ+mDJSkWKojgG3SzskR9NECPe
> MJPa+TQEyh1sgi8GkqnX
> =8teZ
> -END PGP SIGNATURE-
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] static swig bindings and xcode workspace

[Zachary Turner via lldb-dev]

Has the xcode build been changed to use static bindings yet?  I got to
thinking that maybe it would make sense to put them alongside the xcode
workspace folders, just to emphasize that the static bindings were an
artifact of how the xcode build works.  This way we just say "Xcode build
uses static bindings" and "CMake build needs an installed swig", and this
is enforced at the directory level.

In order to do this you'd have to probably make a new toplevel folder to
house both the lldb.xcodeproj and lldb.xcworkspace folders, but I think
that would be useful for other reasons as well.  For example, I want to
check in a visual studio python solution for the test suite at some point,
and it would make sense if all of this additional stuff was in one place.
So perhaps something like:

lldb
|__ contrib
|__ xcode
|__ LLDBWrapPython.cpp
|__ lldb.py
|__ lldb.xcodeproj
|__ lldb.xcworkspace
|__ msvc

I have been thinking about this idea of a contrib folder for a while
anyway, but wanted to have more reasons to make use of it before I brought
it up.

Good idea?  Bad idea?  Thoughts?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 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:
>>
>>> 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
>>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file
>>> st
>>> out
>>>
>>>
>> I cut and paste my line, but more than likely for most people you'd just
>> want this:
>>
>> test/dotest.py --results-formatter
>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file
>> stdout
>>
>> The other stuff was specific to my setup.  That line assumes you run from
>> the lldb source dir root.
>>
>>
>> Let me know if this satisfies the basic needs of counts and whatnot.  It
>>> counts test method runs rather than all the oddball "file, class, etc."
>>> counts we had before.
>>>
>>> It prints out the Details section when there are details, and keeps it
>>> nice and clean when there are none.
>>>
>>> It also mentions a bit about test reruns up top, but that won't come
>>> into play until I get the multi-test-pass, single-worker/low-load mechanism
>>> in place, which will depend on newer rerun count awareness support.
>>>
>>> The change also cleans up places where the test event framework was
>>> using string codes and replaces them with symbolic constants.
>>>
>>> Let me know what you think.  I can tweak it as needed to address testbot
>>> and other needs.  Once it looks reasonable, I'd like to move over to using
>>> it by default in the parallel test runner rather than the legacy support.
>>>
>>> Thanks!
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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.basic_results_formatter.BasicResultsFormatter but it might
make sense for this to be
lldbsuite.test.formatters.basic.BasicResultsFormatter.  If you do things
this way, it can actually result in a substantially shorter command line,
because the --results-formatter option can use lldbsuite.test.formatters as
a starting point.  So you could instead write:

test/dotest.py --results-formatter basic

dotest then looks for a `basic.py` module in the
`lldbsuite.test.formatters` package, looks for a class inside with a
@result_formatter decorator, and instantiates that.

This has the advantage of making the command line shorter *and* a more
logical source file organization.

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?
>
> 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 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:
>>>
 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
 lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file
 st
 out


>>> I cut and paste my line, but more than likely for most people you'd just
>>> want this:
>>>
>>> test/dotest.py --results-formatter
>>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file
>>> stdout
>>>
>>> The other stuff was specific to my setup.  That line assumes you run
>>> from the lldb source dir root.
>>>
>>>
>>> Let me know if this satisfies the basic needs of counts and whatnot.  It
 counts test method runs rather than all the oddball "file, class, etc."
 counts we had before.

 It prints out the Details section when there are details, and keeps it
 nice and clean when there are none.

 It also mentions a bit about test reruns up top, but that won't come
 into play until I get the multi-test-pass, single-worker/low-load mechanism
 in place, which will depend on newer rerun count awareness support.

 The change also cleans up places where the test event framework was
 using string codes and replaces them with symbolic constants.

 Let me know what you think.  I can tweak it as needed to address
 testbot and other needs.  Once it looks reasonable, I'd like to move over
 to using it by default in the parallel test runner rather than the legacy
 support.

 Thanks!
 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] static swig bindings and xcode workspace

[Zachary Turner via lldb-dev]

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:
>
>> 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 put them alongside
>>> the xcode workspace folders, just to emphasize that the static bindings
>>> were an artifact of how the xcode build works.
>>>
>>
>> We could do that.  Internally we also use that for builds other than
>> Xcode, so whatever solution I use (which is currently what I had proposed
>> earlier but now have only in our branches) really needs to work for more
>> than Xcode.
>>
>>
>>>   This way we just say "Xcode build uses static bindings" and "CMake
>>> build needs an installed swig", and this is enforced at the directory
>>> level.
>>>
>>>
>> That's a great compromise, I appreciate your thoughts on that.  Since I
>> need it for more than Xcode, right now the solution I have in our branch is
>> working okay.
>>
>>
>>> In order to do this you'd have to probably make a new toplevel folder to
>>> house both the lldb.xcodeproj and lldb.xcworkspace folders, but I think
>>> that would be useful for other reasons as well.  For example, I want to
>>> check in a visual studio python solution for the test suite at some point,
>>> and it would make sense if all of this additional stuff was in one place.
>>> So perhaps something like:
>>>
>>> lldb
>>> |__ contrib
>>> |__ xcode
>>> |__ LLDBWrapPython.cpp
>>> |__ lldb.py
>>> |__ lldb.xcodeproj
>>> |__ lldb.xcworkspace
>>> |__ msvc
>>>
>>>
>> That structure may make sense.  That could live in llvm.org.  Then for
>> other OSes where I want similar behavior, I could just keep those parts in
>> our branch.  Ultimately I'd end up with multiple copies of the wrapper (for
>> any OS we may build for internally), but I could symlink so that's not
>> really any kind of issue.
>>
>> This might work.
>>
>>
>>> I have been thinking about this idea of a contrib folder for a while
>>> anyway, but wanted to have more reasons to make use of it before I brought
>>> it up.
>>>
>>> Good idea?  Bad idea?  Thoughts?
>>>
>>
>> I could see that layout making sense.  If we did something like that, I
>> think I'd separate moving the lldb.xcodeproj and lldb.xcworkspace from the
>> creation of the contrib folder.
>>
>
> It looks like we may have some reasons why we need the Xcode
> workspace/project files at the top of the lldb source tree.  I'm not sure
> we'll able to move those.  But the rest of it looks like a reasonable way
> to go.
>
>
>>  (i.e. I'd start with the wrapper part in there, and have the others move
>> there at lower priority as a scheduling thing --- there's a bit of work to
>> make the workspace/project change but should be totally doable).
>>
>> I think I like the idea since it reduces the number of merge issues I'd
>> have to deal with.
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 module.  We should be encouraging more smaller files with single
responsibility.  One of the things I plan to do as part of some cleanup in
a week or two is to split up dotest, dosep, and lldbtest.py into a couple
different files by breaking out things like TestBase, etc into separate
files.  So that it's easier to keep a mental map of where different code is.

On Wed, Dec 2, 2015 at 11:26 AM Todd Fiala  wrote:

> 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 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.basic_results_formatter.BasicResultsFormatter but it
>>> might make sense for this to be
>>> lldbsuite.test.formatters.basic.BasicResultsFormatter.  If you do things
>>> this way, it can actually result in a substantially shorter command line,
>>> because the --results-formatter option can use lldbsuite.test.formatters as
>>> a starting point.  So you could instead write:
>>>
>>> test/dotest.py --results-formatter basic
>>>
>>> dotest then looks for a `basic.py` module in the
>>> `lldbsuite.test.formatters` package, looks for a class inside with a
>>> @result_formatter decorator, and instantiates that.
>>>
>>> This has the advantage of making the command line shorter *and* a more
>>> logical source file organization.
>>>
>>
> The other thing that could allow me to do is possibly short-circuit the
> results formatter specifier so that, if just the module is specified, and
> if the module only has one ResultsFormatter-derived class, I can probably
> rig up code that figures out the right results formatter, shortening the
> required discriminator to something even shorter (i.e. module.classname
> becomes just module.)
>
>
>>
>>> 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?

 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 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:
>>
>>> 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
>>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter 
>>> --results-file
>>> st
>>> out
>>>
>>>
>> I cut and paste my line, but more than likely for most people you'd
>> just want this:
>>
>> test/dotest.py --results-formatter
>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter 
>> --results-file
>> stdout
>>
>> The other stuff was specific to my setup.  That line assumes you run
>> from the lldb source dir root.
>>
>>
>> Let me know if this satisfies the basic needs of counts and whatnot.
>>> It counts test method runs rather than all the oddball "file, class, 
>>> etc."
>>> counts we had before.
>>>
>>> It prints out the Details section when there are details, and keeps
>>> it nice and clean when there are none.
>>>
>>> It also mentions a bit about test reruns up top, but that won't come
>>> into play until I get the multi-test-pass, single-worker/low-load 
>>> mechanism
>>> in place, which will depend on newer rerun count awareness support.
>>>
>>> The change also cleans up places where the test event framework was
>>> using string codes and replaces them with symbolic constants.
>>>
>>> Let me know what you think.  I can tweak it as needed to address
>>> testbot and other needs.  Once it looks reasonable, I'd like to move 
>>> over
>>> to using it by default in the parallel test runner rather than the 
>>> legacy
>>> support.
>>>
>>> Thanks!
>>> --
>>> -Todd
>>>
>>
>>>

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 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 module.  We should be encouraging more smaller files with single
> responsibility.  One of the things I plan to do as part of some cleanup in
> a week or two is to split up dotest, dosep, and lldbtest.py into a couple
> different files by breaking out things like TestBase, etc into separate
> files.  So that it's easier to keep a mental map of where different code is.
>
> On Wed, Dec 2, 2015 at 11:26 AM Todd Fiala  wrote:
>
>> 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 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.basic_results_formatter.BasicResultsFormatter but it
 might make sense for this to be
 lldbsuite.test.formatters.basic.BasicResultsFormatter.  If you do things
 this way, it can actually result in a substantially shorter command line,
 because the --results-formatter option can use lldbsuite.test.formatters as
 a starting point.  So you could instead write:

 test/dotest.py --results-formatter basic

 dotest then looks for a `basic.py` module in the
 `lldbsuite.test.formatters` package, looks for a class inside with a
 @result_formatter decorator, and instantiates that.

 This has the advantage of making the command line shorter *and* a more
 logical source file organization.

>>>
>> The other thing that could allow me to do is possibly short-circuit the
>> results formatter specifier so that, if just the module is specified, and
>> if the module only has one ResultsFormatter-derived class, I can probably
>> rig up code that figures out the right results formatter, shortening the
>> required discriminator to something even shorter (i.e. module.classname
>> becomes just module.)
>>
>>
>>>
 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?
>
> 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 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:
>>>
 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
 lldbsuite.test.basic_results_formatter.BasicResultsFormatter 
 --results-file
 st
 out


>>> I cut and paste my line, but more than likely for most people you'd
>>> just want this:
>>>
>>> test/dotest.py --results-formatter
>>> lldbsuite.test.basic_results_formatter.BasicResultsFormatter 
>>> --results-file
>>> stdout
>>>
>>> The other stuff was specific to my setup.  That line assumes you run
>>> from the lldb source dir root.
>>>
>>>
>>> Let me know if this satisfies the basic needs of counts and
 whatnot.  It counts test method runs rather than all the oddball "file,
 class, etc." counts we had before.

 It prints out the Details section when there are details, and keeps
 it nice and clean when there are none.

 It also mentions a bit about test reruns up top, but that won't
 come into play until I get the multi-test-pass, single-worker/low-load
 mechanism in place, which will depend on newer rerun count awareness
 support.

 The change also cleans up places where the test event framework was
 using string codes and repl

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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
execute in the single process test runner:

Command invoked: C:\Python35\python_d.exe
D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
D:/src/llvmbuild/ninja_py35/bin/lldb.exe -s
D:/src/llvmbuild/ninja_py35/lldb-test-traces -u CXXFLAGS -u CFLAGS
--enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
--results-port 60794 --inferior -p TestIntegerTypesExpr.py
D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
worker_index=7:int
411 out of 412 test suites processed - TestIntegerTypesExpr.py
Traceback (most recent call last):
  File "D:\src\llvm\tools\lldb\test\dotest.py", line 7, in 
lldbsuite.test.run_suite()
  File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py",
line 1476, in run_suite
setupTestResults()
  File "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py",
line 982, in setupTestResults
results_formatter_object.handle_event(initialize_event)
  File
"D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\test_results.py",
line 1033, in handle_event
"{}#{}".format(len(pickled_message), pickled_message))
TypeError: a bytes-like object is required, not 'str'

On Wed, Dec 2, 2015 at 11:40 AM Zachary Turner  wrote:

> 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 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 module.  We should be encouraging more smaller files with single
>> responsibility.  One of the things I plan to do as part of some cleanup in
>> a week or two is to split up dotest, dosep, and lldbtest.py into a couple
>> different files by breaking out things like TestBase, etc into separate
>> files.  So that it's easier to keep a mental map of where different code is.
>>
>> On Wed, Dec 2, 2015 at 11:26 AM Todd Fiala  wrote:
>>
>>> 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 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.basic_results_formatter.BasicResultsFormatter but it
> might make sense for this to be
> lldbsuite.test.formatters.basic.BasicResultsFormatter.  If you do things
> this way, it can actually result in a substantially shorter command line,
> because the --results-formatter option can use lldbsuite.test.formatters 
> as
> a starting point.  So you could instead write:
>
> test/dotest.py --results-formatter basic
>
> dotest then looks for a `basic.py` module in the
> `lldbsuite.test.formatters` package, looks for a class inside with a
> @result_formatter decorator, and instantiates that.
>
> This has the advantage of making the command line shorter *and* a more
> logical source file organization.
>

>>> The other thing that could allow me to do is possibly short-circuit the
>>> results formatter specifier so that, if just the module is specified, and
>>> if the module only has one ResultsFormatter-derived class, I can probably
>>> rig up code that figures out the right results formatter, shortening the
>>> required discriminator to something even shorter (i.e. module.classname
>>> becomes just module.)
>>>
>>>

> 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?
>>
>> 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 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:

> Hi

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 side in dotest_channels, there's a couple places where
you do something like:

self.ibuffer = ""

which would need to change to

self.ibuffer = b""

and any other similar operations on self.ibuffer which assume string data.

On Wed, Dec 2, 2015 at 1:33 PM Todd Fiala  wrote:

> 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
>> failure from your system?  Thanks!
>>
>> -Todd
>>
>> On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner 
>> wrote:
>>
>>> 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 execute in the single process test runner:
>>>
>>> Command invoked: C:\Python35\python_d.exe
>>> D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvmbuild/ninja_py35/bin/lldb.exe -s
>>> D:/src/llvmbuild/ninja_py35/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
>>> --results-port 60794 --inferior -p TestIntegerTypesExpr.py
>>> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
>>> worker_index=7:int
>>> 411 out of 412 test suites processed - TestIntegerTypesExpr.py
>>> Traceback (most recent call last):
>>>   File "D:\src\llvm\tools\lldb\test\dotest.py", line 7, in 
>>> lldbsuite.test.run_suite()
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
>>> 1476, in run_suite
>>> setupTestResults()
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
>>> 982, in setupTestResults
>>> results_formatter_object.handle_event(initialize_event)
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\test_results.py",
>>> line 1033, in handle_event
>>> "{}#{}".format(len(pickled_message), pickled_message))
>>> TypeError: a bytes-like object is required, not 'str'
>>>
>>> On Wed, Dec 2, 2015 at 11:40 AM Zachary Turner 
>>> wrote:
>>>
 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 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 module.  We should be encouraging more smaller files with single
> responsibility.  One of the things I plan to do as part of some cleanup in
> a week or two is to split up dotest, dosep, and lldbtest.py into a couple
> different files by breaking out things like TestBase, etc into separate
> files.  So that it's easier to keep a mental map of where different code 
> is.
>
> On Wed, Dec 2, 2015 at 11:26 AM Todd Fiala 
> wrote:
>
>> 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 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.basic_results_formatter.BasicResultsFormatter but
 it might make sense for this to be
 lldbsuite.test.formatters.basic.BasicResultsFormatter.  If you do 
 things
 this way, it can actually result in a substantially shorter command 
 line,
 because the --results-formatter option can use 
 lldbsuite.test.formatters as
 a starting point.  So you could instead write:

 test/dotest.py --results-formatter basic

 dotest then looks for a `basic.py` module in the
 `lldbsuite.test.formatters` package, looks fo

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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:

self.packet_bytes_remaining = struct.unpack("!I",
self.header_contents)[0]
self.header_contents = b""
self.reading_header = False
return data[(index+1):]

The current solution still doesn't work because it's calling socket.send()
with a str instead of a bytes.  So it has to be bytes all the way through.

On Wed, Dec 2, 2015 at 1:48 PM Todd Fiala  wrote:

> 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 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 easier for me
>> to verify that it doesn't break the non-Windows side since I'm right in
>> there now.  If that doesn't do it, we'll need to see what else doesn't work.
>>
>>
>>> 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, 2015 at 1:36 PM, Zachary Turner 
>>> wrote:
>>>
 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 side in dotest_channels, there's a couple places
 where you do something like:

 self.ibuffer = ""

 which would need to change to

 self.ibuffer = b""

 and any other similar operations on self.ibuffer which assume string
 data.

 On Wed, Dec 2, 2015 at 1:33 PM Todd Fiala  wrote:

> 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 failure from your system?  Thanks!
>>
>> -Todd
>>
>> On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner 
>> wrote:
>>
>>> 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 execute in the single process test runner:
>>>
>>> Command invoked: C:\Python35\python_d.exe
>>> D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
>>> D:/src/llvmbuild/ninja_py35/bin/lldb.exe -s
>>> D:/src/llvmbuild/ninja_py35/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
>>> --results-port 60794 --inferior -p TestIntegerTypesExpr.py
>>> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test 
>>> --event-add-entries
>>> worker_index=7:int
>>> 411 out of 412 test suites processed - TestIntegerTypesExpr.py
>>> Traceback (most recent call last):
>>>   File "D:\src\llvm\tools\lldb\test\dotest.py", line 7, in 
>>> lldbsuite.test.run_suite()
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
>>> 1476, in run_suite
>>> setupTestResults()
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
>>> 982, in setupTestResults
>>> results_formatter_object.handle_event(initialize_event)
>>>   File
>>> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\test_results.py",
>>> line 1033, in handle_event
>>> "{}#{}".format(len(pickled_message), pickled_message))
>>> TypeError: a bytes-like object is required, not 'str'
>>>
>>> On Wed, Dec 2, 2015 at 11:40 AM Zachary Turner 
>>> wrote:
>>>
 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 decorator idea because I didn't know all
> the formatters were derived from

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 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:
>
> self.packet_bytes_remaining = struct.unpack("!I",
> self.header_contents)[0]
> self.header_contents = b""
> self.reading_header = False
> return data[(index+1):]
>
> The current solution still doesn't work because it's calling socket.send()
> with a str instead of a bytes.  So it has to be bytes all the way through.
>
> On Wed, Dec 2, 2015 at 1:48 PM Todd Fiala  wrote:
>
>> 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 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 easier for me
>>> to verify that it doesn't break the non-Windows side since I'm right in
>>> there now.  If that doesn't do it, we'll need to see what else doesn't work.
>>>
>>>
 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, 2015 at 1:36 PM, Zachary Turner 
 wrote:

> 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 side in dotest_channels, there's a couple places
> where you do something like:
>
> self.ibuffer = ""
>
> which would need to change to
>
> self.ibuffer = b""
>
> and any other similar operations on self.ibuffer which assume string
> data.
>
> On Wed, Dec 2, 2015 at 1:33 PM Todd Fiala 
> wrote:
>
>> 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 failure from your system?  Thanks!
>>>
>>> -Todd
>>>
>>> On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner 
>>> wrote:
>>>
 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 execute in the single process test runner:

 Command invoked: C:\Python35\python_d.exe
 D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
 D:/src/llvmbuild/ninja_py35/bin/lldb.exe -s
 D:/src/llvmbuild/ninja_py35/lldb-test-traces -u CXXFLAGS -u CFLAGS
 --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
 --results-port 60794 --inferior -p TestIntegerTypesExpr.py
 D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test 
 --event-add-entries
 worker_index=7:int
 411 out of 412 test suites processed - TestIntegerTypesExpr.py
 Traceback (most recent call last):
   File "D:\src\llvm\tools\lldb\test\dotest.py", line 7, in 
 lldbsuite.test.run_suite()
   File
 "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
 1476, in run_suite
 setupTestResults()
   File
 "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", line
 982, in setupTestResults
 results_formatter_object.handle_event(initialize_event)
   File
 "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\test_results.py",
 line 1033, in handle_event
 "{}#{}".format(len(pickled_message), pickled_message))
 TypeError: a bytes-like object is required, not 'str'

 On Wed, Dec 2, 2015 at 11:40 AM Zachary Turner 
 wrote:

> When I run this under Python 3 I get "A bytes object is used like
> a string" on Line 1033 of test_results.py

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

 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  wrote:
>
>> 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:
>>
>> self.packet_bytes_remaining = struct.unpack("!I",
>> self.header_contents)[0]
>> self.header_contents = b""
>> self.reading_header = False
>> return data[(index+1):]
>>
>> The current solution still doesn't work because it's calling
>> socket.send() with a str instead of a bytes.  So it has to be bytes all the
>> way through.
>>
>> On Wed, Dec 2, 2015 at 1:48 PM Todd Fiala  wrote:
>>
>>> 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 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 easier for
 me to verify that it doesn't break the non-Windows side since I'm right in
 there now.  If that doesn't do it, we'll need to see what else doesn't 
 work.


> 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, 2015 at 1:36 PM, Zachary Turner 
> wrote:
>
>> 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 side in dotest_channels, there's a couple places
>> where you do something like:
>>
>> self.ibuffer = ""
>>
>> which would need to change to
>>
>> self.ibuffer = b""
>>
>> and any other similar operations on self.ibuffer which assume string
>> data.
>>
>> On Wed, Dec 2, 2015 at 1:33 PM Todd Fiala 
>> wrote:
>>
>>> 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 failure from your system?  Thanks!

 -Todd

 On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner >>> > wrote:

> 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 execute in the single process test runner:
>
> Command invoked: C:\Python35\python_d.exe
> D:\src\llvm\tools\lldb\test\dotest.py -q --arch=i686 --executable
> D:/src/llvmbuild/ninja_py35/bin/lldb.exe -s
> D:/src/llvmbuild/ninja_py35/lldb-test-traces -u CXXFLAGS -u CFLAGS
> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
> --results-port 60794 --inferior -p TestIntegerTypesExpr.py
> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test 
> --event-add-entries
> worker_index=7:int
> 411 out of 412 test suites processed - TestIntegerTypesExpr.py
> Traceback (most recent call last):
>   File "D:\src\llvm\tools\lldb\test\dotest.py", line 7, in 
> lldbsuite.test.run_suite()
>   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", 
> line
> 1476, in run_suite
> setupTestResults()
>   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest.py", 
> line
> 982, in setupTestResults
> results_formatter_object.handle_event(initialize_event)
>   File
> "D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\test_results.py",
> line 1033, in handle_event
> "{}#{}".format(len(pickled_message), pickled_message)

Re: [lldb-dev] Running lldb tests?

[Zachary Turner via lldb-dev]

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 other platform.

Are you running lldb/test/dotest.py or
lldb/packages/lldbsuite/test/dotest.py?  You should be running the former.
The `progress` module is located in
lldb/third_party/Python/module/progress.  That should be in your `sys.path`
because when you run `lldb/test/dotest.py` the first line calls `import
use_lldb_suite`, which modifies `sys.path` to contain this and a few other
directories.

Hopefully that gives you a starting point to diagnose what's wrong.

On Wed, Dec 2, 2015 at 2:35 PM Chuck Ries via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> 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 python 3 and I am using Python
> 2.7.10. The info at http://lldb.llvm.org/test.html does not seem to be up
> to date. Is there any fix to get the test script working?
>
>
>
> ChuckR
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Running lldb tests?

[Zachary Turner via lldb-dev]

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 was moved was to make a "real"
python package out of the core of the test suite, which allows lots of
functionality to be more easily reused both within the test suite itself,
as well as within other scripts that are not part of the test suite.

On Wed, Dec 2, 2015 at 2:43 PM Chuck Ries  wrote:

> 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:* Chuck Ries ; lldb-dev@lists.llvm.org
> *Subject:* Re: [lldb-dev] Running lldb tests?
>
>
>
> 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 other platform.
>
>
>
> Are you running lldb/test/dotest.py or
> lldb/packages/lldbsuite/test/dotest.py?  You should be running the former.
> The `progress` module is located in
> lldb/third_party/Python/module/progress.  That should be in your `sys.path`
> because when you run `lldb/test/dotest.py` the first line calls `import
> use_lldb_suite`, which modifies `sys.path` to contain this and a few other
> directories.
>
>
>
> Hopefully that gives you a starting point to diagnose what's wrong.
>
>
>
> On Wed, Dec 2, 2015 at 2:35 PM Chuck Ries via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> 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 python 3 and I am using Python
> 2.7.10. The info at http://lldb.llvm.org/test.html
> 
> does not seem to be up to date. Is there any fix to get the test script
> working?
>
>
>
> ChuckR
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Running lldb tests?

[Zachary Turner via lldb-dev]

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, 2015 at 3:15 PM Jim Ingham  wrote:

> 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 <
> lldb-dev@lists.llvm.org> 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 was moved was to make a
> "real" python package out of the core of the test suite, which allows lots
> of functionality to be more easily reused both within the test suite
> itself, as well as within other scripts that are not part of the test suite.
> >
> > On Wed, Dec 2, 2015 at 2:43 PM Chuck Ries 
> wrote:
> > 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: Chuck Ries ; lldb-dev@lists.llvm.org
> > Subject: Re: [lldb-dev] Running lldb tests?
> >
> >
> >
> > 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 other platform.
> >
> >
> >
> > Are you running lldb/test/dotest.py or
> lldb/packages/lldbsuite/test/dotest.py?  You should be running the former.
> The `progress` module is located in
> lldb/third_party/Python/module/progress.  That should be in your `sys.path`
> because when you run `lldb/test/dotest.py` the first line calls `import
> use_lldb_suite`, which modifies `sys.path` to contain this and a few other
> directories.
> >
> >
> >
> > Hopefully that gives you a starting point to diagnose what's wrong.
> >
> >
> >
> > On Wed, Dec 2, 2015 at 2:35 PM Chuck Ries via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > 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 python 3 and I am using
> Python 2.7.10. The info at http://lldb.llvm.org/test.html does not seem
> to be up to date. Is there any fix to get the test script working?
> >
> >
> >
> > ChuckR
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 bunch
of junk fly by.
2) Summary output is organized by test function, not by file.  This gives
better counts.
3) Behavior seems different somehow.  My successes / failures / unexpected
successes seem different when using this formatter.  I'll have to look into
this to figure out if it's just my imagination or something's actually
wrong.

Will this abstraction of a result formatter provide some way to make a
formatter intended for machine consumption?  Right now lots of people
scrape logs for the purposes of build bots, and it would be better if we
could just dump the results as json or something.

Only suggestion I have at this point is that in the summary printout the
lines are too long.  Long test name (module.classname.function) and long
filename.  Perhaps the filename could be converted to a relative path and
the classname could be dropped (there's only one class per file anyway, so
the classname is just wasted space)

On Wed, Dec 2, 2015 at 3:06 PM Todd Fiala  wrote:

> 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:
>>
>>> 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 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:

 self.packet_bytes_remaining = struct.unpack("!I",
 self.header_contents)[0]
 self.header_contents = b""
 self.reading_header = False
 return data[(index+1):]

 The current solution still doesn't work because it's calling
 socket.send() with a str instead of a bytes.  So it has to be bytes all the
 way through.

 On Wed, Dec 2, 2015 at 1:48 PM Todd Fiala  wrote:

> 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 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 easier for
>> me to verify that it doesn't break the non-Windows side since I'm right 
>> in
>> there now.  If that doesn't do it, we'll need to see what else doesn't 
>> work.
>>
>>
>>> 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, 2015 at 1:36 PM, Zachary Turner 
>>> wrote:
>>>
 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 side in dotest_channels, there's a couple places
 where you do something like:

 self.ibuffer = ""

 which would need to change to

 self.ibuffer = b""

 and any other similar operations on self.ibuffer which assume
 string data.

 On Wed, Dec 2, 2015 at 1:33 PM Todd Fiala 
 wrote:

> 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 failure from your system?  Thanks!
>>
>> -Todd
>>
>> On Wed, Dec 2, 2015 at 12:34 PM, Zachary Turner <
>> ztur...@google.com> wrote:
>>
>>> Is there any way to force the si

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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)

Print this:

FAIL: TestDataFormatterPythonSynth.test_rdar10960550_with_run_command_dwo
(functionalities\data-formatter\data-formatter-python-synth\TestDataFormatterPythonSynth.py)

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 run.  Much
> better than staring at a black screen for 5 minutes and then seeing a bunch
> of junk fly by.
> 2) Summary output is organized by test function, not by file.  This gives
> better counts.
> 3) Behavior seems different somehow.  My successes / failures / unexpected
> successes seem different when using this formatter.  I'll have to look into
> this to figure out if it's just my imagination or something's actually
> wrong.
>
> Will this abstraction of a result formatter provide some way to make a
> formatter intended for machine consumption?  Right now lots of people
> scrape logs for the purposes of build bots, and it would be better if we
> could just dump the results as json or something.
>
> Only suggestion I have at this point is that in the summary printout the
> lines are too long.  Long test name (module.classname.function) and long
> filename.  Perhaps the filename could be converted to a relative path and
> the classname could be dropped (there's only one class per file anyway, so
> the classname is just wasted space)
>
> On Wed, Dec 2, 2015 at 3:06 PM Todd Fiala  wrote:
>
>> 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:
>>>
 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 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:
>
> self.packet_bytes_remaining = struct.unpack("!I",
> self.header_contents)[0]
> self.header_contents = b""
> self.reading_header = False
> return data[(index+1):]
>
> The current solution still doesn't work because it's calling
> socket.send() with a str instead of a bytes.  So it has to be bytes all 
> the
> way through.
>
> On Wed, Dec 2, 2015 at 1:48 PM Todd Fiala 
> wrote:
>
>> 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 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 easier
>>> for me to verify that it doesn't break the non-Windows side since I'm 
>>> right
>>> in there now.  If that doesn't do it, we'll need to see what else 
>>> doesn't
>>> work.
>>>
>>>
 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, 2015 at 1:36 PM, Zachary Turner 
 wrote:

> 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 side in dotest_channels, there's a couple places
> where you do something like:
>
> self.ibuffer = ""
>
> which would need to change to
>
> self.ibuffer = b""
>
> and any other similar operations on self.ibuffer which assume
> string data.
>
>

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

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 name, method name or even file name
> being used for a test.  I think, though, that most of those are addressed
> by having the path (relative is fine) to the python test file.  I think we
> can probably get by with classname.methodname (relative test path).  (From
> your other email, I think you nuke the classname and keep the module name,
> but I'd probably do the reverse, keeping the class name and getting rid of
> the module name since it can be derived from the filename).
>
I don't think the filename can be the same anymore, as things will break if
two filenames are the same.  We could go one step further and enforce this
in the part where it scans for all the tests.  If it finds two test files
with the same name we could just generate an error.  I think that's a good
idea anyway, because if two test files have the same name, then the tests
inside must be similar enough to warrant merging them into the same file.

If no two filenames are the same, and if there's only 1 class per file,
then filename + method name should uniquely identify a single test, and so
you could omit the class name and show a relative path to the filename.

>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:

> 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 several times where copy
>>> and paste errors lead to the same class name, method name or even file name
>>> being used for a test.  I think, though, that most of those are addressed
>>> by having the path (relative is fine) to the python test file.  I think we
>>> can probably get by with classname.methodname (relative test path).  (From
>>> your other email, I think you nuke the classname and keep the module name,
>>> but I'd probably do the reverse, keeping the class name and getting rid of
>>> the module name since it can be derived from the filename).
>>>
>> I don't think the filename can be the same anymore, as things will break
>> if two filenames are the same.
>>
>
> Maybe, but that wasn't my experience as of fairly recently.  When tracking
> failures sometime within the last month, I tracked something down in a
> downstream branch with two same-named files that (with the legacy output)
> made it hard to track down what was actually failing given the limited info
> of the legacy test summary output.  Maybe that has changed since then, but
> I'm not aware of anything that would have prohibited that.
>
Well I only said "things" will break, not everything will break.  Most
likely you just didn't notice the problem or it didn't present itself in
your scenario.  There are definitely bugs surrounding multiple files with
the same name, because of some places where we use a dictionary keyed on
filename.


>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

Ahh I read further and see this was already mentioned by Pavel.

On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:

> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
>
>> 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 several times where copy
 and paste errors lead to the same class name, method name or even file name
 being used for a test.  I think, though, that most of those are addressed
 by having the path (relative is fine) to the python test file.  I think we
 can probably get by with classname.methodname (relative test path).  (From
 your other email, I think you nuke the classname and keep the module name,
 but I'd probably do the reverse, keeping the class name and getting rid of
 the module name since it can be derived from the filename).

>>> I don't think the filename can be the same anymore, as things will break
>>> if two filenames are the same.
>>>
>>
>> Maybe, but that wasn't my experience as of fairly recently.  When
>> tracking failures sometime within the last month, I tracked something down
>> in a downstream branch with two same-named files that (with the legacy
>> output) made it hard to track down what was actually failing given the
>> limited info of the legacy test summary output.  Maybe that has changed
>> since then, but I'm not aware of anything that would have prohibited that.
>>
> Well I only said "things" will break, not everything will break.  Most
> likely you just didn't notice the problem or it didn't present itself in
> your scenario.  There are definitely bugs surrounding multiple files with
> the same name, because of some places where we use a dictionary keyed on
> filename.
>
>
>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] New test summary results formatter

[Zachary Turner via lldb-dev]

It would also be nice if the summary statistics were printed after the list
of failing / errored tests.  The reason is that it involves a fixed number
of lines to print the table, but the list of failures and errors is a
variable number of lines which could potentially be very long and push the
statistics off the screen.

On Thu, Dec 3, 2015 at 10:08 AM Zachary Turner  wrote:

> Ahh I read further and see this was already mentioned by Pavel.
>
> On Thu, Dec 3, 2015 at 10:06 AM Zachary Turner  wrote:
>
>> On Wed, Dec 2, 2015 at 10:20 PM Todd Fiala  wrote:
>>
>>> 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 several times where
> copy and paste errors lead to the same class name, method name or even 
> file
> name being used for a test.  I think, though, that most of those are
> addressed by having the path (relative is fine) to the python test file.  
> I
> think we can probably get by with classname.methodname (relative test
> path).  (From your other email, I think you nuke the classname and keep 
> the
> module name, but I'd probably do the reverse, keeping the class name and
> getting rid of the module name since it can be derived from the filename).
>
 I don't think the filename can be the same anymore, as things will
 break if two filenames are the same.

>>>
>>> Maybe, but that wasn't my experience as of fairly recently.  When
>>> tracking failures sometime within the last month, I tracked something down
>>> in a downstream branch with two same-named files that (with the legacy
>>> output) made it hard to track down what was actually failing given the
>>> limited info of the legacy test summary output.  Maybe that has changed
>>> since then, but I'm not aware of anything that would have prohibited that.
>>>
>> Well I only said "things" will break, not everything will break.  Most
>> likely you just didn't notice the problem or it didn't present itself in
>> your scenario.  There are definitely bugs surrounding multiple files with
>> the same name, because of some places where we use a dictionary keyed on
>> filename.
>>
>>
>>>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Windows Buildbot binaries

[Zachary Turner via lldb-dev]

We don't have anything set up like this at the moment unfortunately.  It
could happen in the future, but we've been spending our limited amount of
Windows resources making new debugging scenarios work, and just haven't
gotten to this.

I'd be happy to help diagnose build errors if you're willing to give it a
go again.  The biggest difficulty is the Python part.  If you don't care
about contributing patches to LLDB or scripting LLDB, and you just want to
use it for something, you can set LLDB_DISABLE_PYTHON=1 on the command line
and that should fix most of the difficulty that goes with building LLDB.

I've been working on getting Python 3 support working, which should also
greatly simplify the build process, but it's not quite there yet, although
it's very close.

On Fri, Dec 4, 2015 at 11:11 AM Ridgway, Nick via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hello,
>
>
>
> I have been investigating using the LLDB-MI tool for debugging a project
> at work on Windows, but have been unable to work out how to build the
> program from source (I spent several days with errors I couldn’t work out
> how to fix before giving up).  Would it be possible to download the
> binaries that the Windows buildbot generates?  It would save me a large
> amount of hassle.
>
>
>
>
>
> Thanks
>
> Nick
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

I have updated the list of command line options with a proposed action.  It
looks like exactly half of the command line options can be deleted, which
is going to be a huge win for being able to understand what the test suite
does and how to use it effectively.  Please take a look at the updated
spreadsheet and make final comments.  Last change to keep an option if I've
marked it as delete.

https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?pli=1#gid=0

For a few of the ones people wrote that they use the option, but it seems
like the same functionality is provided by a different option.  I marked
these as PREFER DELETE, but feel free to comment here if you still think it
should remain.  I'll tackle those last and make sure there's consensus that
it's ok to delete them before doing so.

If there's no otehr comments, I plan to start working on this on Wednesday.

On Fri, Nov 20, 2015 at 5:17 PM Todd Fiala  wrote:

> Yeah that would be awesome, and also would be a lot of work.  Good luck!
>
>
> On Fri, Nov 20, 2015 at 10:37 AM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Seems reasonable.  I will make a best effort to get as many of them as I
>> can.
>>
>> On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:
>>
>>> Zach, I would also like to get rid of all global variables in the
>>> process of this change. The history goes like this: a long time ago someone
>>> wrote the initial dotest.py and parsed the options manually and stored
>>> results in global variables. Later, someone converted the options over to
>>> use a python library to parse the options, but we mostly copied the options
>>> from the options dictionary over into the globals and still use the globals
>>> all over the code. It would be great if we had at most one global variable
>>> that is something like "g_options" and anyone that was using any global
>>> variables will switch over to use the "g_options." instead. Then we
>>> don't have to make copies and we can let the g_options contain all settings
>>> that are required.
>>>
>>> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > I would like to do a complete audit of dotest's command line options,
>>> find out who's using what, and then potentially delete anything that isn't
>>> being used.  There's a mess of command line options in use, to the point
>>> that it's often hard to find free letters to use for new options.
>>> >
>>> > I created this spreadsheet with a complete list of command line
>>> options, their descriptions, and a place for people to enter what options
>>> they're using or do not want to be deleted.
>>> >
>>> >
>>> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
>>> >
>>> > If someone has already written YES in the box that indicates they need
>>> the option, please don't overwrite it.  If you write YES in a box, please
>>> provide at least a small rationale for why this option is useful to you.
>>> Feel free to add additional rationale if someone has already added some
>>> rationale.
>>> >
>>> > I'm going to have a couple days in mid-December and do this cleanup,
>>> so I'd like to get a solid picture of what options are not needed before
>>> then.  After people have had some time to look over this, I'll go through
>>> the results and decide what to do with each one, and then send out another
>>> email with a proposed action column for each command line option.
>>> >
>>> > Please do take the time to have a look at this, because any option
>>> that doesn't have a YES in it after a couple of weeks I'm going to assume
>>> is a candidate for deletion.
>>> >
>>> >
>>> > ___
>>> > lldb-dev mailing list
>>> > lldb-dev@lists.llvm.org
>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

Hi Greg,

Take a look at dotest.py next time you get some free time and let me know
what you think.  There should be no more globals.  Everything that used to
be a global is now stored in its own module `configuration.py`, and
everything in `configuration.py` can be referenced from everywhere in the
entire test suite.

On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton  wrote:

> Zach, I would also like to get rid of all global variables in the process
> of this change. The history goes like this: a long time ago someone wrote
> the initial dotest.py and parsed the options manually and stored results in
> global variables. Later, someone converted the options over to use a python
> library to parse the options, but we mostly copied the options from the
> options dictionary over into the globals and still use the globals all over
> the code. It would be great if we had at most one global variable that is
> something like "g_options" and anyone that was using any global variables
> will switch over to use the "g_options." instead. Then we don't have to
> make copies and we can let the g_options contain all settings that are
> required.
>
> > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > I would like to do a complete audit of dotest's command line options,
> find out who's using what, and then potentially delete anything that isn't
> being used.  There's a mess of command line options in use, to the point
> that it's often hard to find free letters to use for new options.
> >
> > I created this spreadsheet with a complete list of command line options,
> their descriptions, and a place for people to enter what options they're
> using or do not want to be deleted.
> >
> >
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> >
> > If someone has already written YES in the box that indicates they need
> the option, please don't overwrite it.  If you write YES in a box, please
> provide at least a small rationale for why this option is useful to you.
> Feel free to add additional rationale if someone has already added some
> rationale.
> >
> > I'm going to have a couple days in mid-December and do this cleanup, so
> I'd like to get a solid picture of what options are not needed before
> then.  After people have had some time to look over this, I'll go through
> the results and decide what to do with each one, and then send out another
> email with a proposed action column for each command line option.
> >
> > Please do take the time to have a look at this, because any option that
> doesn't have a YES in it after a couple of weeks I'm going to assume is a
> candidate for deletion.
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

There's no way to avoid doing a transfer out of the options dictionary at
some level, because it's not a straight transfer.  There's a ton of
post-processing that gets done on the options dictionary in order to
convert the raw options into a useful format.

That might be solvable with more advanced use of argparse.  This approach
does get rid of one level of option transfer though.  Because we would
transfer
1. From the class returned by argparse into the global
2. From the global into the lldb module

Now we only transfer from the argparse class into the `configuration`
module, and everything else just uses that.


On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton  wrote:

> Do we not want to have an "options" global variable in this module that
> contains everything instead of having separate global variables in this
> file? The idea would be that you could assign directly when parsing
> arguments:
>
> (configuration.options, args) = parser.parse_args(sys.argv[1:])
>
> Its OK if we don't do this, but this is what I was originally thinking.
> Then we don't need to do any transfer out of the options dictionary that is
> returned by the option parser. The drawback with this approach is the
> "configuration.options" would probably need to be initialized in case
> someone tries to access the "configuration.options" without first parsing
> arguments. So in that respect the global approach is nicer.
>
> Greg
>
> > On Dec 8, 2015, at 10:45 AM, Zachary Turner  wrote:
> >
> > Hi Greg,
> >
> > Take a look at dotest.py next time you get some free time and let me
> know what you think.  There should be no more globals.  Everything that
> used to be a global is now stored in its own module `configuration.py`, and
> everything in `configuration.py` can be referenced from everywhere in the
> entire test suite.
> >
> > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton 
> wrote:
> > Zach, I would also like to get rid of all global variables in the
> process of this change. The history goes like this: a long time ago someone
> wrote the initial dotest.py and parsed the options manually and stored
> results in global variables. Later, someone converted the options over to
> use a python library to parse the options, but we mostly copied the options
> from the options dictionary over into the globals and still use the globals
> all over the code. It would be great if we had at most one global variable
> that is something like "g_options" and anyone that was using any global
> variables will switch over to use the "g_options." instead. Then we
> don't have to make copies and we can let the g_options contain all settings
> that are required.
> >
> > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > I would like to do a complete audit of dotest's command line options,
> find out who's using what, and then potentially delete anything that isn't
> being used.  There's a mess of command line options in use, to the point
> that it's often hard to find free letters to use for new options.
> > >
> > > I created this spreadsheet with a complete list of command line
> options, their descriptions, and a place for people to enter what options
> they're using or do not want to be deleted.
> > >
> > >
> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
> > >
> > > If someone has already written YES in the box that indicates they need
> the option, please don't overwrite it.  If you write YES in a box, please
> provide at least a small rationale for why this option is useful to you.
> Feel free to add additional rationale if someone has already added some
> rationale.
> > >
> > > I'm going to have a couple days in mid-December and do this cleanup,
> so I'd like to get a solid picture of what options are not needed before
> then.  After people have had some time to look over this, I'll go through
> the results and decide what to do with each one, and then send out another
> email with a proposed action column for each command line option.
> > >
> > > Please do take the time to have a look at this, because any option
> that doesn't have a YES in it after a couple of weeks I'm going to assume
> is a candidate for deletion.
> > >
> > >
> > > ___
> > > lldb-dev mailing list
> > > lldb-dev@lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Auditing dotest's command line options

[Zachary Turner via lldb-dev]

One advantage of this approach is that it makes the options available to
the entire test suite.  Even if we have no transferring going on, and we
get argparse to return us a perfectly organized structure with everything
in the right format, in order to make all the options accessible to the
rest of the test suite, we still need to stick it in a global module
somewhere.  And then you would write
`configuration.options.test_categories`, whereas with this approach we just
write `configuration.test_categories`.  It's a minor point, but I like the
shorter member access personally.

On Tue, Dec 8, 2015 at 11:07 AM Zachary Turner  wrote:

> There's no way to avoid doing a transfer out of the options dictionary at
> some level, because it's not a straight transfer.  There's a ton of
> post-processing that gets done on the options dictionary in order to
> convert the raw options into a useful format.
>
> That might be solvable with more advanced use of argparse.  This approach
> does get rid of one level of option transfer though.  Because we would
> transfer
> 1. From the class returned by argparse into the global
> 2. From the global into the lldb module
>
> Now we only transfer from the argparse class into the `configuration`
> module, and everything else just uses that.
>
>
> On Tue, Dec 8, 2015 at 10:52 AM Greg Clayton  wrote:
>
>> Do we not want to have an "options" global variable in this module that
>> contains everything instead of having separate global variables in this
>> file? The idea would be that you could assign directly when parsing
>> arguments:
>>
>> (configuration.options, args) = parser.parse_args(sys.argv[1:])
>>
>> Its OK if we don't do this, but this is what I was originally thinking.
>> Then we don't need to do any transfer out of the options dictionary that is
>> returned by the option parser. The drawback with this approach is the
>> "configuration.options" would probably need to be initialized in case
>> someone tries to access the "configuration.options" without first parsing
>> arguments. So in that respect the global approach is nicer.
>>
>> Greg
>>
>> > On Dec 8, 2015, at 10:45 AM, Zachary Turner  wrote:
>> >
>> > Hi Greg,
>> >
>> > Take a look at dotest.py next time you get some free time and let me
>> know what you think.  There should be no more globals.  Everything that
>> used to be a global is now stored in its own module `configuration.py`, and
>> everything in `configuration.py` can be referenced from everywhere in the
>> entire test suite.
>> >
>> > On Fri, Nov 20, 2015 at 10:34 AM Greg Clayton 
>> wrote:
>> > Zach, I would also like to get rid of all global variables in the
>> process of this change. The history goes like this: a long time ago someone
>> wrote the initial dotest.py and parsed the options manually and stored
>> results in global variables. Later, someone converted the options over to
>> use a python library to parse the options, but we mostly copied the options
>> from the options dictionary over into the globals and still use the globals
>> all over the code. It would be great if we had at most one global variable
>> that is something like "g_options" and anyone that was using any global
>> variables will switch over to use the "g_options." instead. Then we
>> don't have to make copies and we can let the g_options contain all settings
>> that are required.
>> >
>> > > On Nov 18, 2015, at 2:32 PM, Zachary Turner via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>> > >
>> > > I would like to do a complete audit of dotest's command line options,
>> find out who's using what, and then potentially delete anything that isn't
>> being used.  There's a mess of command line options in use, to the point
>> that it's often hard to find free letters to use for new options.
>> > >
>> > > I created this spreadsheet with a complete list of command line
>> options, their descriptions, and a place for people to enter what options
>> they're using or do not want to be deleted.
>> > >
>> > >
>> https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?usp=sharing
>> > >
>> > > If someone has already written YES in the box that indicates they
>> need the option, please don't overwrite it.  If you write YES in a box,
>> please provide at least a small rationale for why this option is useful to
>> you.  Feel free to add additional rational

[lldb-dev] Benchmark tests

[Zachary Turner via lldb-dev]

Is anyone using the benchmark tests?  None of the command line options

related to the benchmark tests were claimed as being used by anyone.  Which
makes me wonder if the tests are even being used by anyone.

What I really want to know is: Is it really ok to delete the -x and -y
command line options?  And what is the status of these tests?  Does anyone
use them?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] swig generation and "six" module

[Zachary Turner via lldb-dev]

What about requiring that the user has done "pip install six" on their
machine?

On Wed, Dec 9, 2015 at 1:40 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> r252764 changes finishSwigPythonLLDB.py to symlink the “six” module in
> site-packages. six.py is a symlink to
> /tools/lldb/third_party/Python/module/six/six.py. This assumes I have
> access to this build’s sources when I run lldb, which I don’t – our
> workstations don’t have access to the buildbots’ filesystem, and even if
> they did, the sources may change between build and run.
>
>
>
> Shouldn’t six.py just be copied? It’s only 30k.
>
>
>
> Zach, how do I do a build using static swig bindings? I don’t think we’re
> going to change the bindings internally, so using the standard ones should
> be fine.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Benchmark tests

[Zachary Turner via lldb-dev]

When you do run the benchmark tests, what command line options do you use?
At the moment I'm mostly just trying to remove dead options from the test
suite.  I removed one already that allowed you to specify the benchmark
executable, but then when I started looking at the rest and seeing how
tightly integrated they are with the benchamrk tests in general, I started
to wonder.

The three benchmark related command line options are:

1. An option to specify the benchmark executable (defaults to lldb.exe)
2. An option to specify the breakpoint spec (defaults to -n main)
3. An option to specify the breakpoint iteration count (defaults to 30 I
think)
4. An option to specify that you only want to run benchmark tests and no
other tests.

I deleted #4 because you can use the category system for that.  I deleted
#1 because nobody said they needed it on the spreadsheet.  Nobody said they
needed #2 or #3 either, but I just want to double check that deleting them
is fine.

On Wed, Dec 9, 2015 at 2:01 PM Enrico Granata  wrote:

> I have actually added a few benchmark tests recently. We admittedly are
> not that good with running those tests ever (because they're not run by
> default most likely - and I do wonder if some of them would take a long
> time to run.. I don't think I have ever run the full set, just my own as I
> increment on performance work).
>
> Maybe we could try flipping the default to be "run the benchmarks", see if
> test suite run times explode and take it from there in terms of feasibility
> as well as whether they all still make sense.
>
> The other problem with the tests as they stand is that they mark
> themselves as PASS or FAIL purely on the basis of whether they encounter
> command or API errors, and do nothing to track performance regressions.
> That is admittedly a harder problem to tackle given heterogeneous hardware
> and workload - but maybe we could have them fail if the timings go wildly
> crazy over some threshold?
>
> Sent from my iPhone
>
> On Dec 9, 2015, at 1:22 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hey Jason,
>
> Are you the benchmark user?
>
> -Todd
>
> On Wed, Dec 9, 2015 at 12:32 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Is anyone using the benchmark tests?  None of the command line options
>> <https://docs.google.com/spreadsheets/d/1wkxAY7l0_cJOHhhsSlh3aKKlQShlX1D7X1Dn8kpqxy4/edit?pli=1#gid=0>
>> related to the benchmark tests were claimed as being used by anyone.  Which
>> makes me wonder if the tests are even being used by anyone.
>>
>> What I really want to know is: Is it really ok to delete the -x and -y
>> command line options?  And what is the status of these tests?  Does anyone
>> use them?
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> -Todd
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] swig generation and "six" module

[Zachary Turner via lldb-dev]

I don't mind it being a copy instead of a link, I had just been thinking
about getting rid of that workflow anyway and requiring a pip install.  But
if you can't do that, then scratch that idea.

Feel free to change it to a copy and upstream that if it makes your life
easier.

Just to be clear though, the issue with six is orthogonal to the issue with
static bindings, right?  We couldn't all agree on a way to get static
bindings in, so as of now it's not a thing.  I did some work to get a
swig-as-a-service thing going, and it's mostly complete except for the part
where I get a server and make it run on that server.  If I can push that
through static bindings will be a thing again, but I'm blocked on that for
the moment.

On Wed, Dec 9, 2015 at 2:33 PM Ted Woodward 
wrote:

> Unfortunately, the LLDB we build needs to run on SLES 11, Ubuntu 10+ and
> who knows what else.  I don’t think I can require they install a six
> package. I can make our build do a copy instead of a link, if you want to
> keep it a link.
>
>
>
> Are the static swig bindings checked in yet, or do we still need to run
> swig to generate them on each build?
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Wednesday, December 09, 2015 3:47 PM
> *To:* Ted Woodward; LLDB
> *Subject:* Re: [lldb-dev] swig generation and "six" module
>
>
>
> What about requiring that the user has done "pip install six" on their
> machine?
>
>
>
> On Wed, Dec 9, 2015 at 1:40 PM Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> r252764 changes finishSwigPythonLLDB.py to symlink the “six” module in
> site-packages. six.py is a symlink to
> /tools/lldb/third_party/Python/module/six/six.py. This assumes I have
> access to this build’s sources when I run lldb, which I don’t – our
> workstations don’t have access to the buildbots’ filesystem, and even if
> they did, the sources may change between build and run.
>
>
>
> Shouldn’t six.py just be copied? It’s only 30k.
>
>
>
> Zach, how do I do a build using static swig bindings? I don’t think we’re
> going to change the bindings internally, so using the standard ones should
> be fine.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] BasicResultsFormatter - new test results summary

[Zachary Turner via lldb-dev]

On Thu, Dec 10, 2015 at 12:54 PM Todd Fiala  wrote:

> Hi Tamas,
>
>
>
> On Thu, Dec 10, 2015 at 2:52 AM, Tamas Berghammer 
> wrote:
>
>> HI Todd,
>>
>> You changed the way the test failure list is printed in a way that now we
>> only print the name of the test function failing with the name of the test
>> file in parenthesis. Can we add back the name of the test class to this
>> list?
>>
>
> Sure.  I originally planned to have that in there but there was some
> discussion about it being too much info.  I'm happy to add that back.
>
Can we have it tied to verbosity level?  We have -t and -v, maybe one of
those could trigger more detail in the summary view.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

Currently our folder structure looks like this:

lldbsuite
|-- test
|-- dotest.py
|-- dosep.py
|-- lldbtest.py
|-- ...
|-- functionalities
|-- lang
|-- expression_command
|-- ...
etc

I've been thinking about organizing it like this instead:

lldbsuite
|-- test
|-- functionalities
|-- lang
|-- expression_command
|-- ...
|-- engine
|-- dotest.py
|-- dosep.py
|-- lldbtest.py
|-- ...

Anybody have any thoughts on this?  Good idea or bad idea?  The main reason
I want to do this is because as we start breaking up some of the code, it
makes sense to start having some subpackages under the `engine` folder (or
the `test` folder in our current world).  For example, Todd and I have
discussed the idea of putting formatter related stuff under a `formatters`
subpackage.  In the current world, there's no way to differentiate between
folders which contain tests and folders which contain test infrastructure,
so when we walk the directory tree looking for tests we end up walking a
bunch of directories that are used for test infrastructure code and not
actual tests.  So I like the logical separation this provides -- having the
tests themselves all under a single subpackage.

Thoughts?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

Yea wasn't planning on doing this today, just throwing the idea out there.

On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala  wrote:

> I'm fine with the idea.
>
> FWIW the test events model will likely shift a bit, as it is currently a
> single sink, whereas I am likely to turn it into a test event filter chain
> shortly here.  Formatters still make sense as they'll be the things at the
> end of the chain.
>
> Minor detail, result_formatter.py should be results_formatter.py - they
> are ResultsFormatter instances (plural on Results since it transforms a
> series of results into coherent reported output).  I'll rename that at some
> point in the near future, but if you shift a number of things around, you
> can do that.
>
> I'm just about done with the multi-pass running.  I expect to get an
> opt-in version of that running end of day today or worst case on Sunday.
> It would be awesome if you can hold off on any significant change like that
> until this little bit is done as I'm sure we'll collide, particularly since
> this hits dosep.py pretty significantly.
>
> Thanks!
>
> -Todd
>
> On Fri, Dec 11, 2015 at 1:33 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Sounds like a reasonable thing to do. A couple of tiny remarks:
>> - when you do the move, you might as well rename dotest into something
>> else, just to avoid the "which dotest should I run" type of
>> questions...
>> - there is nothing that makes it obvious that "engine" is actually a
>> "test running engine", as it sits in a sibling folder. OTOH,
>> "test_engine" might be too verbose, and messes up tab completion, so
>> that might not be a good idea either...
>>
>> pl
>>
>>
>> On 10 December 2015 at 23:30, Zachary Turner via lldb-dev
>>  wrote:
>> > Currently our folder structure looks like this:
>> >
>> > lldbsuite
>> > |-- test
>> > |-- dotest.py
>> > |-- dosep.py
>> > |-- lldbtest.py
>> > |-- ...
>> > |-- functionalities
>> > |-- lang
>> > |-- expression_command
>> > |-- ...
>> > etc
>> >
>> > I've been thinking about organizing it like this instead:
>> >
>> > lldbsuite
>> > |-- test
>> > |-- functionalities
>> > |-- lang
>> > |-- expression_command
>> > |-- ...
>> > |-- engine
>> > |-- dotest.py
>> > |-- dosep.py
>> > |-- lldbtest.py
>> > |-- ...
>> >
>> > Anybody have any thoughts on this?  Good idea or bad idea?  The main
>> reason
>> > I want to do this is because as we start breaking up some of the code,
>> it
>> > makes sense to start having some subpackages under the `engine` folder
>> (or
>> > the `test` folder in our current world).  For example, Todd and I have
>> > discussed the idea of putting formatter related stuff under a
>> `formatters`
>> > subpackage.  In the current world, there's no way to differentiate
>> between
>> > folders which contain tests and folders which contain test
>> infrastructure,
>> > so when we walk the directory tree looking for tests we end up walking a
>> > bunch of directories that are used for test infrastructure code and not
>> > actual tests.  So I like the logical separation this provides -- having
>> the
>> > tests themselves all under a single subpackage.
>> >
>> > Thoughts?
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

Presumably those tests use an entirely different, hand-rolled test running
infrastructure?

On Fri, Dec 11, 2015 at 10:52 AM Todd Fiala  wrote:

> One thing I want to make sure we can do is have a sane way of storing and
> running tests that  test the test execution engine.  Those are tests that
> should not run as part of an "lldb test run".  These are tests that
> maintainers of the test system run to make sure we're not breaking stuff
> when we touch the test system.
>
> I would be writing more of those if I had a semi-sane way of doing it.
>  (Part of the reason I broke out the python-based timeout logic the way I
> did, before the major packaging changes, was so I had an obvious spot to
> add tests for the process runner logic).
>
> On Fri, Dec 11, 2015 at 10:03 AM, Todd Fiala  wrote:
>
>> I like it.
>>
>> On Fri, Dec 11, 2015 at 9:51 AM, Zachary Turner 
>> wrote:
>>
>>> Yea wasn't planning on doing this today, just throwing the idea out
>>> there.
>>>
>>> On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala  wrote:
>>>
>>>> I'm fine with the idea.
>>>>
>>>> FWIW the test events model will likely shift a bit, as it is currently
>>>> a single sink, whereas I am likely to turn it into a test event filter
>>>> chain shortly here.  Formatters still make sense as they'll be the things
>>>> at the end of the chain.
>>>>
>>>> Minor detail, result_formatter.py should be results_formatter.py - they
>>>> are ResultsFormatter instances (plural on Results since it transforms a
>>>> series of results into coherent reported output).  I'll rename that at some
>>>> point in the near future, but if you shift a number of things around, you
>>>> can do that.
>>>>
>>>> I'm just about done with the multi-pass running.  I expect to get an
>>>> opt-in version of that running end of day today or worst case on Sunday.
>>>> It would be awesome if you can hold off on any significant change like that
>>>> until this little bit is done as I'm sure we'll collide, particularly since
>>>> this hits dosep.py pretty significantly.
>>>>
>>>> Thanks!
>>>>
>>>> -Todd
>>>>
>>>> On Fri, Dec 11, 2015 at 1:33 AM, Pavel Labath via lldb-dev <
>>>> lldb-dev@lists.llvm.org> wrote:
>>>>
>>>>> Sounds like a reasonable thing to do. A couple of tiny remarks:
>>>>> - when you do the move, you might as well rename dotest into something
>>>>> else, just to avoid the "which dotest should I run" type of
>>>>> questions...
>>>>> - there is nothing that makes it obvious that "engine" is actually a
>>>>> "test running engine", as it sits in a sibling folder. OTOH,
>>>>> "test_engine" might be too verbose, and messes up tab completion, so
>>>>> that might not be a good idea either...
>>>>>
>>>>> pl
>>>>>
>>>>>
>>>>> On 10 December 2015 at 23:30, Zachary Turner via lldb-dev
>>>>>  wrote:
>>>>> > Currently our folder structure looks like this:
>>>>> >
>>>>> > lldbsuite
>>>>> > |-- test
>>>>> > |-- dotest.py
>>>>> > |-- dosep.py
>>>>> > |-- lldbtest.py
>>>>> > |-- ...
>>>>> > |-- functionalities
>>>>> > |-- lang
>>>>> > |-- expression_command
>>>>> > |-- ...
>>>>> > etc
>>>>> >
>>>>> > I've been thinking about organizing it like this instead:
>>>>> >
>>>>> > lldbsuite
>>>>> > |-- test
>>>>> > |-- functionalities
>>>>> > |-- lang
>>>>> > |-- expression_command
>>>>> > |-- ...
>>>>> > |-- engine
>>>>> > |-- dotest.py
>>>>> > |-- dosep.py
>>>>> > |-- lldbtest.py
>>>>> > |-- ...
>>>>> >
>>>>> > Anybody have any thoughts on this?  Good idea or bad idea?  The main
>>>>> reason
>>>>> > I want to do this is because as we start breaking up some of the
>>>>> code, it
>>>>> > makes sense to start having some subpackag

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

Not sure I follow.  Are you trying to test the execution engine itself
(dotest.py, lldbtest.py, etc) or are you trying to have another alternative
to running individual tests?  The

if __name__ == "__main__":
unittest.main() stuff

was deleted deleted from all tests a few months ago as part of the package
re-organization, and I thought I had general consensus at the time that
that was ok to do.

On Fri, Dec 11, 2015 at 11:13 AM Todd Fiala  wrote:

> It just requires running the test file as a python script.
>
> The runner is fired off like this:
>
> if __name__ == "__main__":
> unittest.main()
>
> which is typically added to the bottom of all test files so you can call
> it directly.
>
> -Todd
>
> On Fri, Dec 11, 2015 at 11:12 AM, Todd Fiala  wrote:
>
>> Unittest.
>>
>> Comes with Python.
>>
>> On Fri, Dec 11, 2015 at 11:07 AM, Zachary Turner 
>> wrote:
>>
>>> Presumably those tests use an entirely different, hand-rolled test
>>> running infrastructure?
>>>
>>> On Fri, Dec 11, 2015 at 10:52 AM Todd Fiala 
>>> wrote:
>>>
>>>> One thing I want to make sure we can do is have a sane way of storing
>>>> and running tests that  test the test execution engine.  Those are tests
>>>> that should not run as part of an "lldb test run".  These are tests that
>>>> maintainers of the test system run to make sure we're not breaking stuff
>>>> when we touch the test system.
>>>>
>>>> I would be writing more of those if I had a semi-sane way of doing it.
>>>>  (Part of the reason I broke out the python-based timeout logic the way I
>>>> did, before the major packaging changes, was so I had an obvious spot to
>>>> add tests for the process runner logic).
>>>>
>>>> On Fri, Dec 11, 2015 at 10:03 AM, Todd Fiala 
>>>> wrote:
>>>>
>>>>> I like it.
>>>>>
>>>>> On Fri, Dec 11, 2015 at 9:51 AM, Zachary Turner 
>>>>> wrote:
>>>>>
>>>>>> Yea wasn't planning on doing this today, just throwing the idea out
>>>>>> there.
>>>>>>
>>>>>> On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala 
>>>>>> wrote:
>>>>>>
>>>>>>> I'm fine with the idea.
>>>>>>>
>>>>>>> FWIW the test events model will likely shift a bit, as it is
>>>>>>> currently a single sink, whereas I am likely to turn it into a test 
>>>>>>> event
>>>>>>> filter chain shortly here.  Formatters still make sense as they'll be 
>>>>>>> the
>>>>>>> things at the end of the chain.
>>>>>>>
>>>>>>> Minor detail, result_formatter.py should be results_formatter.py -
>>>>>>> they are ResultsFormatter instances (plural on Results since it 
>>>>>>> transforms
>>>>>>> a series of results into coherent reported output).  I'll rename that at
>>>>>>> some point in the near future, but if you shift a number of things 
>>>>>>> around,
>>>>>>> you can do that.
>>>>>>>
>>>>>>> I'm just about done with the multi-pass running.  I expect to get an
>>>>>>> opt-in version of that running end of day today or worst case on Sunday.
>>>>>>> It would be awesome if you can hold off on any significant change like 
>>>>>>> that
>>>>>>> until this little bit is done as I'm sure we'll collide, particularly 
>>>>>>> since
>>>>>>> this hits dosep.py pretty significantly.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> -Todd
>>>>>>>
>>>>>>> On Fri, Dec 11, 2015 at 1:33 AM, Pavel Labath via lldb-dev <
>>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Sounds like a reasonable thing to do. A couple of tiny remarks:
>>>>>>>> - when you do the move, you might as well rename dotest into
>>>>>>>> something
>>>>>>>> else, just to avoid the "which dotest should I run" type of
>>>>>>>> questions...
>>>>>>>> - there is nothing that makes it obvious that "engi

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

Also at some point I will probably want to kill unittest2 and move to the
upstream unittest.  AFAICT we only use unittest2 because it works on 2.6
and unittest doesn't.  But now that we're ok with saying 2.6 is
unsupported, we can in theory go to the upstream unittest.

On Fri, Dec 11, 2015 at 11:17 AM Zachary Turner  wrote:

> Not sure I follow.  Are you trying to test the execution engine itself
> (dotest.py, lldbtest.py, etc) or are you trying to have another alternative
> to running individual tests?  The
>
> if __name__ == "__main__":
> unittest.main() stuff
>
> was deleted deleted from all tests a few months ago as part of the package
> re-organization, and I thought I had general consensus at the time that
> that was ok to do.
>
> On Fri, Dec 11, 2015 at 11:13 AM Todd Fiala  wrote:
>
>> It just requires running the test file as a python script.
>>
>> The runner is fired off like this:
>>
>> if __name__ == "__main__":
>> unittest.main()
>>
>> which is typically added to the bottom of all test files so you can call
>> it directly.
>>
>> -Todd
>>
>> On Fri, Dec 11, 2015 at 11:12 AM, Todd Fiala 
>> wrote:
>>
>>> Unittest.
>>>
>>> Comes with Python.
>>>
>>> On Fri, Dec 11, 2015 at 11:07 AM, Zachary Turner 
>>> wrote:
>>>
>>>> Presumably those tests use an entirely different, hand-rolled test
>>>> running infrastructure?
>>>>
>>>> On Fri, Dec 11, 2015 at 10:52 AM Todd Fiala 
>>>> wrote:
>>>>
>>>>> One thing I want to make sure we can do is have a sane way of storing
>>>>> and running tests that  test the test execution engine.  Those are tests
>>>>> that should not run as part of an "lldb test run".  These are tests that
>>>>> maintainers of the test system run to make sure we're not breaking stuff
>>>>> when we touch the test system.
>>>>>
>>>>> I would be writing more of those if I had a semi-sane way of doing it.
>>>>>  (Part of the reason I broke out the python-based timeout logic the way I
>>>>> did, before the major packaging changes, was so I had an obvious spot to
>>>>> add tests for the process runner logic).
>>>>>
>>>>> On Fri, Dec 11, 2015 at 10:03 AM, Todd Fiala 
>>>>> wrote:
>>>>>
>>>>>> I like it.
>>>>>>
>>>>>> On Fri, Dec 11, 2015 at 9:51 AM, Zachary Turner 
>>>>>> wrote:
>>>>>>
>>>>>>> Yea wasn't planning on doing this today, just throwing the idea out
>>>>>>> there.
>>>>>>>
>>>>>>> On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm fine with the idea.
>>>>>>>>
>>>>>>>> FWIW the test events model will likely shift a bit, as it is
>>>>>>>> currently a single sink, whereas I am likely to turn it into a test 
>>>>>>>> event
>>>>>>>> filter chain shortly here.  Formatters still make sense as they'll be 
>>>>>>>> the
>>>>>>>> things at the end of the chain.
>>>>>>>>
>>>>>>>> Minor detail, result_formatter.py should be results_formatter.py -
>>>>>>>> they are ResultsFormatter instances (plural on Results since it 
>>>>>>>> transforms
>>>>>>>> a series of results into coherent reported output).  I'll rename that 
>>>>>>>> at
>>>>>>>> some point in the near future, but if you shift a number of things 
>>>>>>>> around,
>>>>>>>> you can do that.
>>>>>>>>
>>>>>>>> I'm just about done with the multi-pass running.  I expect to get
>>>>>>>> an opt-in version of that running end of day today or worst case on
>>>>>>>> Sunday.  It would be awesome if you can hold off on any significant 
>>>>>>>> change
>>>>>>>> like that until this little bit is done as I'm sure we'll collide,
>>>>>>>> particularly since this hits dosep.py pretty significantly.
>>>>>>>>
>>>>>>>> Thanks!
>>>

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

t;>>>>>>>>> filter chain shortly here.  Formatters still make sense as they'll 
>>>>>>>>>> be the
>>>>>>>>>> things at the end of the chain.
>>>>>>>>>>
>>>>>>>>>> Minor detail, result_formatter.py should be results_formatter.py
>>>>>>>>>> - they are ResultsFormatter instances (plural on Results since it
>>>>>>>>>> transforms a series of results into coherent reported output).  I'll 
>>>>>>>>>> rename
>>>>>>>>>> that at some point in the near future, but if you shift a number of 
>>>>>>>>>> things
>>>>>>>>>> around, you can do that.
>>>>>>>>>>
>>>>>>>>>> I'm just about done with the multi-pass running.  I expect to get
>>>>>>>>>> an opt-in version of that running end of day today or worst case on
>>>>>>>>>> Sunday.  It would be awesome if you can hold off on any significant 
>>>>>>>>>> change
>>>>>>>>>> like that until this little bit is done as I'm sure we'll collide,
>>>>>>>>>> particularly since this hits dosep.py pretty significantly.
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>>
>>>>>>>>>> -Todd
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 11, 2015 at 1:33 AM, Pavel Labath via lldb-dev <
>>>>>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sounds like a reasonable thing to do. A couple of tiny remarks:
>>>>>>>>>>> - when you do the move, you might as well rename dotest into
>>>>>>>>>>> something
>>>>>>>>>>> else, just to avoid the "which dotest should I run" type of
>>>>>>>>>>> questions...
>>>>>>>>>>> - there is nothing that makes it obvious that "engine" is
>>>>>>>>>>> actually a
>>>>>>>>>>> "test running engine", as it sits in a sibling folder. OTOH,
>>>>>>>>>>> "test_engine" might be too verbose, and messes up tab
>>>>>>>>>>> completion, so
>>>>>>>>>>> that might not be a good idea either...
>>>>>>>>>>>
>>>>>>>>>>> pl
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10 December 2015 at 23:30, Zachary Turner via lldb-dev
>>>>>>>>>>>  wrote:
>>>>>>>>>>> > Currently our folder structure looks like this:
>>>>>>>>>>> >
>>>>>>>>>>> > lldbsuite
>>>>>>>>>>> > |-- test
>>>>>>>>>>> > |-- dotest.py
>>>>>>>>>>> > |-- dosep.py
>>>>>>>>>>> > |-- lldbtest.py
>>>>>>>>>>> > |-- ...
>>>>>>>>>>> > |-- functionalities
>>>>>>>>>>> > |-- lang
>>>>>>>>>>> > |-- expression_command
>>>>>>>>>>> > |-- ...
>>>>>>>>>>> > etc
>>>>>>>>>>> >
>>>>>>>>>>> > I've been thinking about organizing it like this instead:
>>>>>>>>>>> >
>>>>>>>>>>> > lldbsuite
>>>>>>>>>>> > |-- test
>>>>>>>>>>> > |-- functionalities
>>>>>>>>>>> > |-- lang
>>>>>>>>>>> > |-- expression_command
>>>>>>>>>>> > |-- ...
>>>>>>>>>>> > |-- engine
>>>>>>>>>>> > |-- dotest.py
>>>>>>>>>>> > |-- dosep.py
>>>>>>>>>>> > |-- lldbtest.py
>>>>>>>>>>> > |-- ...
>>>>>>>>>>> >
>>>>>>>>>>> > Anybody have any thoughts on this?  Good idea or bad idea?
>>>>>>>>>>> The main reason
>>>>>>>>>>> > I want to do this is because as we start breaking up some of
>>>>>>>>>>> the code, it
>>>>>>>>>>> > makes sense to start having some subpackages under the
>>>>>>>>>>> `engine` folder (or
>>>>>>>>>>> > the `test` folder in our current world).  For example, Todd
>>>>>>>>>>> and I have
>>>>>>>>>>> > discussed the idea of putting formatter related stuff under a
>>>>>>>>>>> `formatters`
>>>>>>>>>>> > subpackage.  In the current world, there's no way to
>>>>>>>>>>> differentiate between
>>>>>>>>>>> > folders which contain tests and folders which contain test
>>>>>>>>>>> infrastructure,
>>>>>>>>>>> > so when we walk the directory tree looking for tests we end up
>>>>>>>>>>> walking a
>>>>>>>>>>> > bunch of directories that are used for test infrastructure
>>>>>>>>>>> code and not
>>>>>>>>>>> > actual tests.  So I like the logical separation this provides
>>>>>>>>>>> -- having the
>>>>>>>>>>> > tests themselves all under a single subpackage.
>>>>>>>>>>> >
>>>>>>>>>>> > Thoughts?
>>>>>>>>>>> >
>>>>>>>>>>> > ___
>>>>>>>>>>> > lldb-dev mailing list
>>>>>>>>>>> > lldb-dev@lists.llvm.org
>>>>>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>>>>> >
>>>>>>>>>>> ___
>>>>>>>>>>> lldb-dev mailing list
>>>>>>>>>>> lldb-dev@lists.llvm.org
>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -Todd
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> -Todd
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -Todd
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -Todd
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> -Todd
>>>>
>>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Separating test runner and tests

[Zachary Turner via lldb-dev]

roke out the python-based timeout logic 
>>>>>>>>> the way
>>>>>>>>> I did, before the major packaging changes, was so I had an obvious 
>>>>>>>>> spot to
>>>>>>>>> add tests for the process runner logic).
>>>>>>>>>
>>>>>>>>> On Fri, Dec 11, 2015 at 10:03 AM, Todd Fiala >>>>>>>> > wrote:
>>>>>>>>>
>>>>>>>>>> I like it.
>>>>>>>>>>
>>>>>>>>>> On Fri, Dec 11, 2015 at 9:51 AM, Zachary Turner <
>>>>>>>>>> ztur...@google.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Yea wasn't planning on doing this today, just throwing the idea
>>>>>>>>>>> out there.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Dec 11, 2015 at 9:35 AM Todd Fiala 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'm fine with the idea.
>>>>>>>>>>>>
>>>>>>>>>>>> FWIW the test events model will likely shift a bit, as it is
>>>>>>>>>>>> currently a single sink, whereas I am likely to turn it into a 
>>>>>>>>>>>> test event
>>>>>>>>>>>> filter chain shortly here.  Formatters still make sense as they'll 
>>>>>>>>>>>> be the
>>>>>>>>>>>> things at the end of the chain.
>>>>>>>>>>>>
>>>>>>>>>>>> Minor detail, result_formatter.py should be
>>>>>>>>>>>> results_formatter.py - they are ResultsFormatter instances (plural 
>>>>>>>>>>>> on
>>>>>>>>>>>> Results since it transforms a series of results into coherent 
>>>>>>>>>>>> reported
>>>>>>>>>>>> output).  I'll rename that at some point in the near future, but 
>>>>>>>>>>>> if you
>>>>>>>>>>>> shift a number of things around, you can do that.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm just about done with the multi-pass running.  I expect to
>>>>>>>>>>>> get an opt-in version of that running end of day today or worst 
>>>>>>>>>>>> case on
>>>>>>>>>>>> Sunday.  It would be awesome if you can hold off on any 
>>>>>>>>>>>> significant change
>>>>>>>>>>>> like that until this little bit is done as I'm sure we'll collide,
>>>>>>>>>>>> particularly since this hits dosep.py pretty significantly.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>> -Todd
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Dec 11, 2015 at 1:33 AM, Pavel Labath via lldb-dev <
>>>>>>>>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds like a reasonable thing to do. A couple of tiny remarks:
>>>>>>>>>>>>> - when you do the move, you might as well rename dotest into
>>>>>>>>>>>>> something
>>>>>>>>>>>>> else, just to avoid the "which dotest should I run" type of
>>>>>>>>>>>>> questions...
>>>>>>>>>>>>> - there is nothing that makes it obvious that "engine" is
>>>>>>>>>>>>> actually a
>>>>>>>>>>>>> "test running engine", as it sits in a sibling folder. OTOH,
>>>>>>>>>>>>> "test_engine" might be too verbose, and messes up tab
>>>>>>>>>>>>> completion, so
>>>>>>>>>>>>> that might not be a good idea either...
>>>>>>>>>>>>>
>>>>>>>>>>>>> pl
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 10 December 2015 at 23:30, Zachary Turner via lldb-dev
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>> > Currently our folder structure looks like this:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > lldbsuite
>>>>>>>>>>>>> > |-- test
>>>>>>>>>>>>> > |-- dotest.py
>>>>>>>>>>>>> > |-- dosep.py
>>>>>>>>>>>>> > |-- lldbtest.py
>>>>>>>>>>>>> > |-- ...
>>>>>>>>>>>>> > |-- functionalities
>>>>>>>>>>>>> > |-- lang
>>>>>>>>>>>>> > |-- expression_command
>>>>>>>>>>>>> > |-- ...
>>>>>>>>>>>>> > etc
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I've been thinking about organizing it like this instead:
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > lldbsuite
>>>>>>>>>>>>> > |-- test
>>>>>>>>>>>>> > |-- functionalities
>>>>>>>>>>>>> > |-- lang
>>>>>>>>>>>>> > |-- expression_command
>>>>>>>>>>>>> > |-- ...
>>>>>>>>>>>>> > |-- engine
>>>>>>>>>>>>> > |-- dotest.py
>>>>>>>>>>>>> > |-- dosep.py
>>>>>>>>>>>>> > |-- lldbtest.py
>>>>>>>>>>>>> > |-- ...
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Anybody have any thoughts on this?  Good idea or bad idea?
>>>>>>>>>>>>> The main reason
>>>>>>>>>>>>> > I want to do this is because as we start breaking up some of
>>>>>>>>>>>>> the code, it
>>>>>>>>>>>>> > makes sense to start having some subpackages under the
>>>>>>>>>>>>> `engine` folder (or
>>>>>>>>>>>>> > the `test` folder in our current world).  For example, Todd
>>>>>>>>>>>>> and I have
>>>>>>>>>>>>> > discussed the idea of putting formatter related stuff under
>>>>>>>>>>>>> a `formatters`
>>>>>>>>>>>>> > subpackage.  In the current world, there's no way to
>>>>>>>>>>>>> differentiate between
>>>>>>>>>>>>> > folders which contain tests and folders which contain test
>>>>>>>>>>>>> infrastructure,
>>>>>>>>>>>>> > so when we walk the directory tree looking for tests we end
>>>>>>>>>>>>> up walking a
>>>>>>>>>>>>> > bunch of directories that are used for test infrastructure
>>>>>>>>>>>>> code and not
>>>>>>>>>>>>> > actual tests.  So I like the logical separation this
>>>>>>>>>>>>> provides -- having the
>>>>>>>>>>>>> > tests themselves all under a single subpackage.
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > Thoughts?
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > ___
>>>>>>>>>>>>> > lldb-dev mailing list
>>>>>>>>>>>>> > lldb-dev@lists.llvm.org
>>>>>>>>>>>>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>>>>>>> >
>>>>>>>>>>>>> ___
>>>>>>>>>>>>> lldb-dev mailing list
>>>>>>>>>>>>> lldb-dev@lists.llvm.org
>>>>>>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> -Todd
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> -Todd
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -Todd
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> -Todd
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -Todd
>>>>>>
>>>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Problem with dotest_channels.py

[Zachary Turner via lldb-dev]

Hi Todd, lately I've been seeing this sporadically when running the test
suite.

[TestNamespaceLookup.py FAILED]
Command invoked: C:\Python27_LLDB\x86\python_d.exe
D:\src\llvm\tools\lldb\test\dotest.pyc -q --arch=i686 --executable
D:/src/llvmbuild/ninja/bin/lldb.exe -s
D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
--enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
--results-port 55886 --inferior -p TestNamespaceLookup.py
D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
worker_index=10:int
416 out of 416 test suites processed - TestAddDsymCommand.py
error: uncaptured python exception, closing channel
 (:[Errno 10054] An
existing connection was forcibly closed by the remote host
[C:\Python27_LLDB\x86\lib\asyncore.py|read|83]
[C:\Python27_LLDB\x86\lib\asyncore.py|handle_read_event|449]
[D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|133]
[C:\Python27_LLDB\x86\lib\asyncore.py|recv|387])

It seems to happen randomly and not always on the same test.  Sometimes it
doesn't happen at all.  I wonder if this could be related to some of the
work that's been going on recently.  Are you seeing this?  Any idea how to
diagnose?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] debug info test failures

[Zachary Turner via lldb-dev]

I believe I already fixed this issue

On Mon, Dec 14, 2015 at 1:53 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I temporarily skipped these tests on Darwin  and Linux here:
> r255549
>
> I'll file a bug in a moment...
>
> On Mon, Dec 14, 2015 at 1:42 PM, Todd Fiala  wrote:
>
>> Hi all,
>>
>> I'm seeing locally on OS X the same build failures that I'm seeing on the
>> ubuntu 14.04 cmake builedbot:
>>
>> ERROR: 
>> TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwarf 
>> (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py)
>> ERROR: 
>> TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwo 
>> (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py)
>>
>>
>>
>> It looks something like this:
>>
>> ==
>> ERROR: test_limit_debug_info_dsym
>> (TestWithLimitDebugInfo.TestWithLimitDebugInfo)
>> --
>> Traceback (most recent call last):
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>> line 2247, in test_method
>> return attrvalue(self)
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>> line 1134, in wrapper
>> if expected_fn(self):
>>   File
>> "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
>> line 1096, in fn
>> debug_info_passes = debug_info is None or self.debug_info in
>> debug_info
>> TypeError: argument of type 'function' is not iterable
>> Config=x86_64-clang
>> =
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with dotest_channels.py

[Zachary Turner via lldb-dev]

If nothing else, maybe we can print out a more useful exception backtrace.
What kind of exception, what line, and what was the message?  That might
help give us a better idea of what's causing it.

On Mon, Dec 14, 2015 at 2:03 PM Todd Fiala  wrote:

> Hi Zachary!
>
>
>
>
>
> On Mon, Dec 14, 2015 at 1:28 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi Todd, lately I've been seeing this sporadically when running the test
>> suite.
>>
>> [TestNamespaceLookup.py FAILED]
>> Command invoked: C:\Python27_LLDB\x86\python_d.exe
>> D:\src\llvm\tools\lldb\test\dotest.pyc -q --arch=i686 --executable
>> D:/src/llvmbuild/ninja/bin/lldb.exe -s
>> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
>> --results-port 55886 --inferior -p TestNamespaceLookup.py
>> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
>> worker_index=10:int
>> 416 out of 416 test suites processed - TestAddDsymCommand.py
>>   error: uncaptured python exception, closing channel
>> > 127.0.0.1:56008 at 0x2bdd578> (:[Errno 10054] An
>> existing connection was forcibly closed by the remote host
>> [C:\Python27_LLDB\x86\lib\asyncore.py|read|83]
>> [C:\Python27_LLDB\x86\lib\asyncore.py|handle_read_event|449]
>> [D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|133]
>> [C:\Python27_LLDB\x86\lib\asyncore.py|recv|387])
>>
>> It seems to happen randomly and not always on the same test.  Sometimes
>> it doesn't happen at all.  I wonder if this could be related to some of the
>> work that's been going on recently.  Are you seeing this?  Any idea how to
>> diagnose?
>>
>
> Eww.
>
> That *looks* like one side of the connection between the inferior and the
> test runner process choked on reading content from the test event socket
> when the other end went down.  Reading it a bit more carefully, it looks
> like it is the event collector (which would be the parallel test runner
> side) that was receiving when the socket went down.
>
> I think this means I just need to put a try block around the receiver and
> just bail out gracefully (possibly with a message) when that happens at an
> unexpected time.  Since test inferiors can die at any time, possibly due to
> a timeout where they are forcibly killed, we do need to handle that
> gracefully.'
>
> I'll see if I can force it, replicate it, and fix it.  I'll look at that
> now (pending watching the buildbots for the other change I just put in).
>
> And yes, this would be a code path that we use heavily with the xUnit
> reporter, but only started getting used by you more recently when I turned
> on the newer summary results by default.  (The newer summary results use
> the test event system, which means test inferiors are now going to be using
> the sockets to pass back test events, where you didn't have that happening
> before unless you used the curses or xUnit results formatter).
>
> I hope to have it reproduced and fixed up here quickly.  I suspect you may
> have an environment that just might make it more prevalent, but it needs to
> be fixed.
>
> Hopefully back in a bit with a fix!
>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] debug info test failures

[Zachary Turner via lldb-dev]

Yea I think r255542 fixes it, or at least it was supposed to.  Let me know

On Mon, Dec 14, 2015 at 2:04 PM Todd Fiala  wrote:

> Okay.  I appeared to be up to date when hitting it, but we may have
> crossed on it.
>
> I'll take out the skip if I am not hitting it now.  Thanks!
>
> On Mon, Dec 14, 2015 at 2:01 PM, Zachary Turner 
> wrote:
>
>> I believe I already fixed this issue
>>
>> On Mon, Dec 14, 2015 at 1:53 PM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I temporarily skipped these tests on Darwin  and Linux here:
>>> r255549
>>>
>>> I'll file a bug in a moment...
>>>
>>> On Mon, Dec 14, 2015 at 1:42 PM, Todd Fiala 
>>> wrote:
>>>
 Hi all,

 I'm seeing locally on OS X the same build failures that I'm seeing on
 the ubuntu 14.04 cmake builedbot:

 ERROR: 
 TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwarf 
 (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py)
 ERROR: 
 TestWithLimitDebugInfo.TestWithLimitDebugInfo.test_limit_debug_info_dwo 
 (lang/cpp/limit-debug-info/TestWithLimitDebugInfo.py)



 It looks something like this:

 ==
 ERROR: test_limit_debug_info_dsym
 (TestWithLimitDebugInfo.TestWithLimitDebugInfo)
 --
 Traceback (most recent call last):
   File
 "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 2247, in test_method
 return attrvalue(self)
   File
 "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1134, in wrapper
 if expected_fn(self):
   File
 "/Users/tfiala/src/lldb-tot/lldb/packages/Python/lldbsuite/test/lldbtest.py",
 line 1096, in fn
 debug_info_passes = debug_info is None or self.debug_info in
 debug_info
 TypeError: argument of type 'function' is not iterable
 Config=x86_64-clang
 =

 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] test rerun phase is in

[Zachary Turner via lldb-dev]

I've checked in r255567 which fixes a problem pointed out by Siva.  It
doesn't sound related to in 255542, but looking at those logs I can't
really tell how my CL would be related.  If r255567 doesn't fix the bots,
would someone mind helping me briefly?  r255542 seems pretty
straightforward, so I don't see why it would have an effect here.

On Mon, Dec 14, 2015 at 2:35 PM Todd Fiala  wrote:

> Ah yes I see.  Thanks, Ying (and Siva!  Saw your comments too).
>
> On Mon, Dec 14, 2015 at 2:34 PM, Ying Chen  wrote:
>
>> Seems this is the first build that fails, and it only has one CL 255542
>> .
>>
>> http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/9446
>> I believe Zachary is looking at that problem.
>>
>> On Mon, Dec 14, 2015 at 2:18 PM, Todd Fiala  wrote:
>>
>>> I am seeing several failures on the Ubuntu 14.04 testbot, but
>>> unfortunately there are a number of changes that went in at the same time
>>> on that build.  The failures I'm seeing are not appearing at all related to
>>> the test running infrastructure.
>>>
>>> Anybody with a fast Linux system able to take a look to see what exactly
>>> is failing there?
>>>
>>> -Todd
>>>
>>> On Mon, Dec 14, 2015 at 1:39 PM, Todd Fiala 
>>> wrote:
>>>
 Hi all,

 I just put in the single-worker, low-load, follow-up test run pass in
 r255543.  Most of the work for it went in late last week, this just mostly
 flips it on.

 The feature works like this:

 * First test phase works as before: run all tests using whatever level
 of concurrency is normally used.  (e.g. 8 works on an 8-logical-core box).

 * Any timeouts, failures, errors, or anything else that would have
 caused a test failure is eligible for rerun if either (1) it was marked as
 a flakey test via the flakey decorator, or (2) if the --rerun-all-issues
 command line flag is provided.

 * After the first test phase, if there are any tests that met rerun
 eligibility that would have caused a test failure, those get run using a
 serial test phase.  Their results will overwrite (i.e. replace) the
 previous result for the given test method.

 The net result should be that tests that were load sensitive and
 intermittently fail during the first higher-concurrency test phase should
 (in theory) pass in the second, single worker test phase when the test
 suite is only using a single worker.  This should make the test suite
 generate fewer false positives on test failure notification, which should
 make continuous integration servers (testbots) much more useful in terms of
 generating actionable signals caused by version control changes to the lldb
 or related sources.

 Please let me know if you see any issues with this when running the
 test suite using the default output.  I'd like to fix this up ASAP.  And
 for those interested in the implementation, I'm happy to do post-commit
 review/changes as needed to get it in good shape.

 I'll be watching the  builders now and will address any issues as I see
 them.

 Thanks!
 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Problem with dotest_channels.py

[Zachary Turner via lldb-dev]

I wonder if you need a flush somewhere before you invoke the cleanup func?
Would that do it?  It looks like the sending side of the connection is
closing before the receiving side has received all its data.

On Tue, Dec 15, 2015 at 3:49 PM Adrian McCarthy  wrote:

> With Todd's change, I was getting a Ninja crash.  Zach and I replaced the
> returns Todd added with raises, in order to propagate the exception up the
> stack, and that avoids the Ninja crash, so I'll check that in in a moment.
>
> In the mean time, here's the error message we got out of it.
>
> 155 out of 416 test suites processed - TestBacktraceAll.py
> INFO: received socket error when reading data from test inferior:
> [Errno 10054] An existing connection was forcibly closed by the remote host
> error: uncaptured python exception, closing channel
>  127.
> 0.0.1:58961 at 0x2bb8878> (:[Errno 10054] An
> existing connection was forcibly closed by the remote host
> [D:\Python_for_lldb\x86\lib\asyncore.py|read|83]
> [D:\Python_for_lldb\x86\lib\asyncore.py|handle_read_event|449]
> [D:\src\llvm\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|137]
> [D:\Python_for_lldb\x86\lib\asyncore.py|recv|387])
> 175 out of 416 test suites processed - TestNoSuchArch.py
>
> On Mon, Dec 14, 2015 at 3:58 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hey Zachary,
>>
>> I just put in:
>> r255581
>>
>> which should hopefully:
>> (1) catch the exception you see there,
>> (2) handle it gracefully in the common and to-be-expected case of the
>> test inferior going down hard, and
>> (3) print out an error if anything else unexpected is happening here.
>>
>> Let me know if you get any more info with it.  Thanks!
>>
>> -Todd
>>
>> On Mon, Dec 14, 2015 at 2:16 PM, Todd Fiala  wrote:
>>
>>> Yeah that's a messed up exception scenario that is hard to read.  I'll
>>> figure something out when I repro it.  One side is closing before the other
>>> is expecting it, but likely in a way we need to expect.
>>>
>>> I think it is ugly-ified because it is coming from some kind of worker
>>> thread within async-core.
>>>
>>> I will get something in to help it today.  The first bit may be just
>>> catching the exception as you mentioned.
>>>
>>> On Mon, Dec 14, 2015 at 2:05 PM, Zachary Turner 
>>> wrote:
>>>
>>>> If nothing else, maybe we can print out a more useful exception
>>>> backtrace.  What kind of exception, what line, and what was the message?
>>>> That might help give us a better idea of what's causing it.
>>>>
>>>> On Mon, Dec 14, 2015 at 2:03 PM Todd Fiala 
>>>> wrote:
>>>>
>>>>> Hi Zachary!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 14, 2015 at 1:28 PM, Zachary Turner via lldb-dev <
>>>>> lldb-dev@lists.llvm.org> wrote:
>>>>>
>>>>>> Hi Todd, lately I've been seeing this sporadically when running the
>>>>>> test suite.
>>>>>>
>>>>>> [TestNamespaceLookup.py FAILED]
>>>>>> Command invoked: C:\Python27_LLDB\x86\python_d.exe
>>>>>> D:\src\llvm\tools\lldb\test\dotest.pyc -q --arch=i686 --executable
>>>>>> D:/src/llvmbuild/ninja/bin/lldb.exe -s
>>>>>> D:/src/llvmbuild/ninja/lldb-test-traces -u CXXFLAGS -u CFLAGS
>>>>>> --enable-crash-dialog -C d:\src\llvmbuild\ninja_release\bin\clang.exe
>>>>>> --results-port 55886 --inferior -p TestNamespaceLookup.py
>>>>>> D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test --event-add-entries
>>>>>> worker_index=10:int
>>>>>> 416 out of 416 test suites processed - TestAddDsymCommand.py
>>>>>>   error: uncaptured python exception, closing channel
>>>>>> >>>>> connected
>>>>>> 127.0.0.1:56008 at 0x2bdd578> (:[Errno 10054]
>>>>>> An existing connection was forcibly closed by the remote host
>>>>>> [C:\Python27_LLDB\x86\lib\asyncore.py|read|83]
>>>>>> [C:\Python27_LLDB\x86\lib\asyncore.py|handle_read_event|449]
>>>>>> [D:\src\llvm\tools\lldb\packages\Python\lldbsuite\test\dotest_channels.py|handle_read|133]
>>>>>> [C:\Python27_LLDB\x86\lib\asyncore.py|recv|387])
>>>>>>
>>>>>> It seems to happen randomly and 

Re: [lldb-dev] building on mac

[Zachary Turner via lldb-dev]

Are the Xcode scripts using the llvm configure build?  If so they will need
to be changed to the CMake build sooner or later, because the configure
build is going away in the near future.

On Thu, Dec 17, 2015 at 3:18 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Ah.
>
> Okay, this might be the llvm/clang build script that Xcode uses as an
> llvm/clang build step.  That's going to need to be updated if it is using
> configure (for the reasons I mentioned above).
>
> So it sounds like some part of llvm or clang may be sniffing and finding
> some part of ocaml, and deciding it should make some bindings for it.  I'll
> have a look at the script and see if there's an obvious way to explicitly
> deny it (the warning seemed like it had a way to disable that binding, so
> we might just need to work it in).
>
> Of course, if you are not using ocaml, you might want to consider
> removing/hiding it if you don't need it.
>
> Interestingly, I did have ocaml on my home system a while back and didn't
> have any trouble building, but I probably had ounit2 as well, and likely
> wouldn't have noticed if the Xcode-based build-llvm script ended up doing
> more work when building the embedded llvm/clang during the Xcode build.
>
>  I can probably replicate this pretty easily.
>
> On Thu, Dec 17, 2015 at 3:10 PM, Ryan Brown  wrote:
>
>> Does xcode use configure? I just push command-B.
>> It does look like I have ocaml installed on my system, but I'm not sure
>> how it go installed or why xcode is trying to use it.
>>
>> -- Ryan Brown
>>
>> On Thu, Dec 17, 2015 at 2:54 PM, Todd Fiala  wrote:
>>
>>> We definitely should not be requiring ocaml :-)
>>>
>>> Are you using a configure-based build?  If so, can you switch over to
>>> using cmake and see if you see that same issue?  We pretty much don't
>>> maintain the configure build, and it is getting stripped from llvm and
>>> clang in the next version of them after 3.8, so we will not be able to
>>> support configure-based builds in the near future.
>>>
>>> In the event that you still see it, let us know if you have ocaml or
>>> opam somewhere on your system.  The warnings do seem to indicate that ocaml
>>> was specified for one reason or another?  Maybe parts of it were sniffed
>>> out when trying to configure the build.
>>>
>>> -Todd
>>>
>>> On Thu, Dec 17, 2015 at 1:36 PM, Ryan Brown via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Are there new prereqs for building on a mac?
 I just updated, and I'm getting this error:

 checking for __dso_handle... yes

 configure: WARNING: --enable-bindings=ocaml specified, but ctypes is
 not installed

 configure: WARNING: --enable-bindings=ocaml specified, but OUnit 2 is
 not installed. Tests will not run

 configure: error: Prequisites for bindings not satisfied. Fix them or
 use configure --disable-bindings.

 error: making llvm and clang child exited with value 2


 -- Ryan Brown

 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Patch for addressing format warnings on 32-bit

[Zachary Turner via lldb-dev]

Incidentally, once we can start requiring VS 2015 %z will be supported
there.  Not sure if MSVC is the only supported platform that currently
doesn't support %z

On Mon, Jan 4, 2016 at 11:24 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Please do cast to 64 bit and user PRI*64 macros. %z isn't supported on all
> platforms and we need to get away from using it.
>
> > On Dec 28, 2015, at 10:32 AM, William Dillon via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi Todd,
> >
> > The example I put in my last email is one of a few (maybe one more)
> instances where the existing code casts to 64-bit and uses PRIu64.  When
> I’m dabbling in existing code I try to copy the conventions that are
> already in place, so that’s why I went this way.  I’m happy to change it to
> %zu.  I was just checking about that.
> >
> > - Will
> >
> >> On Dec 28, 2015, at 10:24 AM, Todd Fiala  wrote:
> >>
> >> Hi William,
> >>
> >> It looks like just the PRIx64/PRIu64 bits are needed from a visual
> inspection.  The source variables that are printed from already are 64-bit
> always, aren't they?  If they're not but they should be, that seems like
> the real underlying problem rather than needing to cast.
> >>
> >> What kind of warning are you seeing if you just replace the % format
> specifier?
> >>
> >> Thanks!
> >>
> >> -Todd
> >>
> >> On Sun, Dec 27, 2015 at 12:32 PM, William Dillon via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >> > Message: 1
> >> > Date: Sat, 26 Dec 2015 21:15:53 +0100
> >> > From: Joerg Sonnenberger via lldb-dev 
> >> > To: lldb-dev@lists.llvm.org
> >> > Subject: Re: [lldb-dev] Patch for addressing format warnings on 32-bit
> >> > Message-ID: <20151226201553.gb14...@britannica.bec.de>
> >> > Content-Type: text/plain; charset=utf-8
> >> >
> >> > On Fri, Dec 25, 2015 at 06:34:09PM -0800, William Dillon via lldb-dev
> wrote:
> >> >> There are a handful of -Wformat warnings on 32-bit platforms.
> >> >> I addressed all those that I’ve seen while working on Swift.
> >> >> Let me know if the git diff format is inappropriate for this.
> >> >
> >> > Don't cast size_t to uint64_t, format it with %zu directly.
> >> >
> >> > Joerg
> >> >
> >>
> >> I can go ahead and do that, but I wonder whether there should be two
> different ways of handling this, even on the same line.  For example:
> >>
> >> -error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
> addr=0x%" PRIx64 ": tried to read %lu bytes but only read %" PRIu64,
> __FUNCTION__, m_addr, m_opcode_size, (uint64_t)bytes_read);
> >> +error.SetErrorStringWithFormat ("SoftwareBreakpointr::%s
> addr=0x%" PRIx64 ": tried to read %" PRIu64 " bytes but only read %"
> PRIu64, __FUNCTION__, m_addr, (uint64_t)m_opcode_size,
> (uint64_t)bytes_read);
> >>
> >> - Will
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
> >>
> >>
> >> --
> >> -Todd
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

Feel free to file bugs or post your feedback here after you use about what
worked, what didn't work, what's missing, etc.  Anything that doesn't work
is a bug that I would like to fix.

On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner  wrote:

> Hi, I guess I should make a new blog post at some point, or post status on
> the website.  Here's my best estimate at what you can expect.
>
> * Most common debugging scenarios should work.  Run under debugger, attach
> to process, interrupt, continue, print variable values, evaluate
> expressions, etc.
> * Step-over might be unstable in certain scenarios
> * Conditional breakpoints don't work
> * Hardware watchpoints don't work
> * Expression evaluation might not work in some advanced cases.
>
> The main big feature that has been added since the original blog post is
> support for windows minidump files.  So you can create a minidump of a
> stopped process from inside LLDB, and you can load up a minidump and do
> post-mortem debugging.
>
> On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Where can i look lldb status for native debug at Windows?
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

As far as I'm aware, this is the last major incompatibility between LLDB's
style and clang-format's feature set.

I would appreciate it if more people could try it out with a few of their
patches, and let me know if any LLDB style incompatibilities arise in the
formatted code.

I would eventually like to move towards requiring that all patches be
clang-formatted before committing to LLDB.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

Should look like this:

llvm
|__ tools
 |__ clang
 |__ lld
 |__ lldb

You will need clang because lldb needs to link against it, and you will
need lld because lldb on Windows doesn't (yet) understand PDB, so you have
to compile your programs with clang.exe -fuse-ld=lld



On Sat, Jan 9, 2016 at 1:29 PM Red Skotina via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> If i want compile as part of llvm then what is destination directory for
> lldb trunk sources ?
> I has placed this in llvm/projects/lldb and has  much errors while
> compiling lldb with MSVC 2015.
>
> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
> "d:\code\llvm\build\ALL_BUILD.vcxproj.metaproj" (целевой объект по
> умолчанию) (
> 2) ->
> "d:\code\llvm\build\projects\lldb\finish_swig.vcxproj.metaproj" (целевой
> объект
>  по умолчанию) (482) ->
> "d:\code\llvm\build\projects\lldb\source\API\liblldb.vcxproj.metaproj"
> (целевой
>  объект по умолчанию) (483) ->
>
> "d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC\lldbPluginObjCLa
> nguage.vcxproj.metaproj" (целевой объект по умолчанию) (570) ->
>
> "d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC\lldbPluginObjCLa
> nguage.vcxproj" (целевой объект по умолчанию) (571) ->
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\Cocoa.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Language\O
> bjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\NSArray.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Language
> \ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\ObjCLanguage.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Lan
> guage\ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\CF.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC
> \lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/Basic/DiagnosticIDs.h(53):
> fatal
> error C1083: Cannot open include file:
> 'clang/Basic/DiagnosticCommonKinds.inc':
>  No such file or directory (compiling source file
> D:\code\llvm\llvm\projects\ll
> db\source\Plugins\Language\ObjC\NSDictionary.cpp)
> [d:\code\llvm\build\projects\
> lldb\source\Plugins\Language\ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/Basic/DiagnosticIDs.h(53):
> fatal
> error C1083: Cannot open include file:
> 'clang/Basic/DiagnosticCommonKinds.inc':
>  No such file or directory (compiling source file
> D:\code\llvm\llvm\projects\ll
> db\source\Plugins\Language\ObjC\NSError.cpp)
> [d:\code\llvm\build\projects\lldb\
> source\Plugins\Language\ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/Basic/DiagnosticIDs.h(53):
> fatal
> error C1083: Cannot open include file:
> 'clang/Basic/DiagnosticCommonKinds.inc':
>  No such file or directory (compiling source file
> D:\code\llvm\llvm\projects\ll
> db\source\Plugins\Language\ObjC\NSException.cpp)
> [d:\code\llvm\build\projects\l
> ldb\source\Plugins\Language\ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\NSIndexPath.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Lang
> uage\ObjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\NSSet.cpp)
> [d:\code\llvm\build\projects\lldb\source\Plugins\Language\O
> bjC\lldbPluginObjCLanguage.vcxproj]
>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
> error C10
> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
> direct
> ory (compiling source file
> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
> age\ObjC\NSString.cpp)
> [d:\

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

I have never built with -DLLVM_INCLUDE_TESTS=OFF
-DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that
could be related.  Can you try removing those options on CMake to see if
that fixes it?

The other thing I do differently is I use ninja generator.  So I use -G
Ninja instead of -G "Visual Studio 14 2015".  Building from within Visual
Studio like you're doing is supposed to work, I just don't know if anyone
tests it.  My command line is usually:

cmake -G Ninja  -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME= ..\llvm

ninja


On Sun, Jan 10, 2016 at 4:02 AM Red Skotina  wrote:

> thanks.
> i still have 5 errors while linking
> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
> "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj"
> (целев
> ой объект по умолчанию) (741) ->
>
> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj.metaproj"
>  (целевой объект по умолчанию) (742) ->
> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj"
> (целевой
>  объект по умолчанию) (743) ->
>   LINK : fatal error LNK1181: cannot open input file 'gtest.lib'
> [d:\code\llvm\
> build\tools\lldb\unittests\Utility\UtilityTests.vcxproj]
>
> my commands:
>
> cmake -G "Visual Studio 14 2015"  -DCMAKE_BUILD_TYPE=Release
> -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF
> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF
> -DPYTHON_HOME= ..\llvm
>
> msbuild LLVM.sln /p:Configuration=Release;Platform=Win32
>
> i look to llvm\tools\lldb\gtest and cant find any file. here is only empty
> directories.
> should i download something or should skip unittests ?
>
> 2016-01-10 6:28 GMT+03:00 Zachary Turner :
>
>> Should look like this:
>>
>> llvm
>> |__ tools
>>  |__ clang
>>  |__ lld
>>  |__ lldb
>>
>> You will need clang because lldb needs to link against it, and you will
>> need lld because lldb on Windows doesn't (yet) understand PDB, so you have
>> to compile your programs with clang.exe -fuse-ld=lld
>>
>>
>>
>> On Sat, Jan 9, 2016 at 1:29 PM Red Skotina via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> If i want compile as part of llvm then what is destination directory for
>>> lldb trunk sources ?
>>> I has placed this in llvm/projects/lldb and has  much errors while
>>> compiling lldb with MSVC 2015.
>>>
>>> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
>>> "d:\code\llvm\build\ALL_BUILD.vcxproj.metaproj" (целевой объект по
>>> умолчанию) (
>>> 2) ->
>>> "d:\code\llvm\build\projects\lldb\finish_swig.vcxproj.metaproj" (целевой
>>> объект
>>>  по умолчанию) (482) ->
>>> "d:\code\llvm\build\projects\lldb\source\API\liblldb.vcxproj.metaproj"
>>> (целевой
>>>  объект по умолчанию) (483) ->
>>>
>>> "d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC\lldbPluginObjCLa
>>> nguage.vcxproj.metaproj" (целевой объект по умолчанию) (570) ->
>>>
>>> "d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC\lldbPluginObjCLa
>>> nguage.vcxproj" (целевой объект по умолчанию) (571) ->
>>>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
>>> error C10
>>> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
>>> direct
>>> ory (compiling source file
>>> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
>>> age\ObjC\Cocoa.cpp)
>>> [d:\code\llvm\build\projects\lldb\source\Plugins\Language\O
>>> bjC\lldbPluginObjCLanguage.vcxproj]
>>>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
>>> error C10
>>> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
>>> direct
>>> ory (compiling source file
>>> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
>>> age\ObjC\NSArray.cpp)
>>> [d:\code\llvm\build\projects\lldb\source\Plugins\Language
>>> \ObjC\lldbPluginObjCLanguage.vcxproj]
>>>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
>>> error C10
>>> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
>>> direct
>>> ory (compiling source file
>>> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
>>> age\ObjC\ObjCLanguage.cpp)
>>> [d:\code\llvm\build\projects\lldb\source\Plugins\Lan
>>> guage\ObjC\lldbPluginObjCLanguage.vcxproj]
>>>   D:\code\llvm\llvm\tools\clang\include\clang/AST/ASTFwd.h(22): fatal
>>> error C10
>>> 83: Cannot open include file: 'clang/AST/DeclNodes.inc': No such file or
>>> direct
>>> ory (compiling source file
>>> D:\code\llvm\llvm\projects\lldb\source\Plugins\Langu
>>> age\ObjC\CF.cpp)
>>> [d:\code\llvm\build\projects\lldb\source\Plugins\Language\ObjC
>>> \lldbPluginObjCLanguage.vcxproj]
>>>   D:\code\llvm\llvm\tools\clang\include\clang/Basic/DiagnosticIDs.h(53):
>>> fatal
>>> error C1083: Cannot open include file:
>>> 'clang/Basic/DiagnosticCommonKinds.inc':
>>>  No such file or directory (compiling source file
>>> D:\code\llvm\llvm\projects\ll
>>> db\source\Plugins\Language\ObjC\NSDictionary.cpp)
>>> [d:\code\llvm\build\projects\
>>> lldb\source\Plugins\Languag

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

Yea, unfortunately the way things work is that the person who is affected
by the problem and who needs it fixed is usually the one that needs to fix
it.  Right now we don't have any Windows people building inside Visual
Studio, so nobody has fixed that.  But you're welcome to submit a patch :)

FWIW, I actually generate CMake twice, into two separate folders.  I have
build/vs and build/ninja.  In the vs directory I generate using "Visual
Studio 14 2015" generator, and in ninja I generate using Ninja generator.
I build from the Ninja folder, and I use the vs folder just for opening a
solution, source browsing, and debugging (i.e. change the Debugger settings
to point the executable into the ninja folder).

This way you still do everything from vs, just not the compile step.

On Mon, Jan 11, 2016 at 9:16 AM Red Skotina  wrote:

> thanks. i build successefuly llvm and lldb with ninja and cl compiler.
>
> If i build VS solution without options on CMake then i have ever more
> errors around unittests in llvm.
>
> like that:
>
> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой
> объект по
>  умолчанию) (749) ->
> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по
> умолчани
> ю) (750) ->
> (Целевой объект ClCompile) ->
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
> C2327: 'll
> vm::PointerEmbeddedInt::Value': is not a type name, static, or
> enume
> rator (compiling source file
> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt
> Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
> C2065: 'Va
> lue': undeclared identifier (compiling source file
> D:\code\llvm\llvm\unittests\
> ADT\PointerEmbeddedIntTest.cpp)
> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
> roj]
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
> C2327: 'll
> vm::PointerEmbeddedInt::Value': is not a type name, static, or
> enumerato
> r (compiling source file
> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error
> C2338: Can
> not embed more bits than we have in a pointer! (compiling source file
> D:\code\l
> lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp)
> [d:\code\llvm\build\unittest
> s\ADT\ADTTests.vcxproj]
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
> C2327: 'll
> vm::PointerEmbeddedInt::Value': is not a type name, static, or
> enumerato
> r (compiling source file
> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
> C2065: 'Va
> lue': undeclared identifier (compiling source file
> D:\code\llvm\llvm\unittests\
> ADT\PointerEmbeddedIntTest.cpp)
> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
> roj]
>
>
> 2016-01-11 0:56 GMT+03:00 Zachary Turner :
>
>> I have never built with -DLLVM_INCLUDE_TESTS=OFF
>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that
>> could be related.  Can you try removing those options on CMake to see if
>> that fixes it?
>>
>> The other thing I do differently is I use ninja generator.  So I use -G
>> Ninja instead of -G "Visual Studio 14 2015".  Building from within Visual
>> Studio like you're doing is supposed to work, I just don't know if anyone
>> tests it.  My command line is usually:
>>
>> cmake -G Ninja  -DCMAKE_BUILD_TYPE=Release -DPYTHON_HOME=> to python\x86 from dest variable> ..\llvm
>>
>> ninja
>>
>>
>> On Sun, Jan 10, 2016 at 4:02 AM Red Skotina 
>> wrote:
>>
>>> thanks.
>>> i still have 5 errors while linking
>>> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
>>> "d:\code\llvm\build\tools\lldb\unittests\LLDBUnitTests.vcxproj.metaproj"
>>> (целев
>>> ой объект по умолчанию) (741) ->
>>>
>>> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj.metaproj"
>>>  (целевой объект по умолчанию) (742) ->
>>> "d:\code\llvm\build\tools\lldb\unittests\Utility\UtilityTests.vcxproj"
>>> (целевой
>>>  объект по умолчанию) (743) ->
>>>   LINK : fatal error LNK1181: cannot open input file 'gtest.lib'
>>> [d:\code\llvm\
>>> build\tools\lldb\unittests\Utility\UtilityTests.vcxproj]
>>>
>>> my commands:
>>>
>>> cmake -G "Visual Studio 14 2015"  -DCMAKE_BUILD_TYPE=Release
>>> -DLLVM_INCLUDE_EXAMPLES=OFF -DLLVM_INCLUDE_TESTS=OFF
>>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF
>>> -DPYTHON_HOME= ..\llvm
>>>
>>> msbuild LLVM.sln /p:Configuration=Release;Platform=Win32
>>>
>>> i look to llvm\tools\lldb\gtest and cant find any file. here is only
>>> empty directories.
>>> should i download something or should skip unittests ?
>>>
>>> 2016-01-10 6:28 GMT+03:00 Zachary Turner :
>>>
 Should look like this:

 llvm
 |_

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

VS 2013 support is going to be deprecated soon.  At that point it could
break any time, because nobody is going to be making an effort to keep it
working.

On Tue, Jan 12, 2016 at 7:54 AM Aidan Dodds via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Just to chip in on this thread.
> I regularly build X64 LLDB using Visual Studio, but I only use it for
> debugging remote targets.
> I have noticed the gtests linking error, but unfortunately due to tight
> time constraints I've not been free to fix it.
> I tend to 'unload' all of the projects in Visual Studio that are not
> directly related to building LLDB, so I don't see the linking error often.
> Also since its not a direct dependency, LLDB still builds fine for me.
>
> Fixes are always nice however :)
>
> Last I checked I was able to build LLDB in VS2013 as well as VS2015
> without problems.
>
>
> On 11/01/2016 18:48, Zachary Turner via lldb-dev wrote:
>
> Yea, unfortunately the way things work is that the person who is affected
> by the problem and who needs it fixed is usually the one that needs to fix
> it.  Right now we don't have any Windows people building inside Visual
> Studio, so nobody has fixed that.  But you're welcome to submit a patch :)
>
> FWIW, I actually generate CMake twice, into two separate folders.  I have
> build/vs and build/ninja.  In the vs directory I generate using "Visual
> Studio 14 2015" generator, and in ninja I generate using Ninja generator.
> I build from the Ninja folder, and I use the vs folder just for opening a
> solution, source browsing, and debugging (i.e. change the Debugger settings
> to point the executable into the ninja folder).
>
> This way you still do everything from vs, just not the compile step.
>
> On Mon, Jan 11, 2016 at 9:16 AM Red Skotina  wrote:
>
>> thanks. i build successefuly llvm and lldb with ninja and cl compiler.
>>
>> If i build VS solution without options on CMake then i have ever more
>> errors around unittests in llvm.
>>
>> like that:
>>
>> "d:\code\llvm\build\LLVM.sln" (целевой объект по умолчанию) (1) ->
>> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj.metaproj" (целевой
>> объект по
>>  умолчанию) (749) ->
>> "d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj" (целевой объект по
>> умолчани
>> ю) (750) ->
>> (Целевой объект ClCompile) ->
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enume
>> rator (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedInt
>> Test.cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2065: 'Va
>> lue': undeclared identifier (compiling source file
>> D:\code\llvm\llvm\unittests\
>> ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
>> roj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(33): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enumerato
>> r (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
>> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(34): error
>> C2338: Can
>> not embed more bits than we have in a pointer! (compiling source file
>> D:\code\l
>> lvm\llvm\unittests\ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittest
>> s\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
>> C2327: 'll
>> vm::PointerEmbeddedInt::Value': is not a type name, static, or
>> enumerato
>> r (compiling source file
>> D:\code\llvm\llvm\unittests\ADT\PointerEmbeddedIntTest
>> .cpp) [d:\code\llvm\build\unittests\ADT\ADTTests.vcxproj]
>>   D:\code\llvm\llvm\include\llvm/ADT/PointerEmbeddedInt.h(39): error
>> C2065: 'Va
>> lue': undeclared identifier (compiling source file
>> D:\code\llvm\llvm\unittests\
>> ADT\PointerEmbeddedIntTest.cpp)
>> [d:\code\llvm\build\unittests\ADT\ADTTests.vcxp
>> roj]
>>
>>
>> 2016-01-11 0:56 GMT+03:00 Zachary Turner :
>>
>>> I have never built with -DLLVM_INCLUDE_TESTS=OFF
>>> -DCLANG_INCLUDE_EXAMPLES=OFF -DCLANG_INCLUDE_TESTS=OFF before, so that
>>> could be related.  Can you try removing those options on CMake to see if
>>> that fixes it?
>>

Re: [lldb-dev] LLDB build at windows

[Zachary Turner via lldb-dev]

When we move to VS 2015 (which will be soon, btw) we will require Python
3.5+ on Windows.  This already works for the most part, you can even try it
out today.  I've spent the better part of the past 6 months making LLDB's
python bindings work with Python 3.  The best part is that you don't need
to custom build Python 3.5, you can just use the installer from Python.org
(make sure you choose to install debug binaries too).

So in summary:
* VS 2013 -> requires Python custom built version of Python 2.7
* VS 2015 -> requires any version of Python >= 3.5, doesn't have to be
custom built.

On Thu, Jan 14, 2016 at 10:20 AM Vadim Chugunov via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>  VS 2013 support is going to be deprecated soon. At that point it could
>
> break any time, because nobody is going to be making an effort to keep it
>> > working.
>>
> How is this going to play with Python scripting on Windows?   Given that LLDB 
> only supports Python 2.7 bindings,
> and that Python 2.7 extensions can be built only with VS2008, isn't that 
> going to be a problem?
> (When LLDB for Windows is officially declared "ready", that is.  For now, one 
> can rebuild Python with VS2015.)
>
> Vadim
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb tests and tear down hooks

[Zachary Turner via lldb-dev]

So this is biting us again, for unrelated reasons.  I thought of a
potentially interesting solution.  Right now each test class has a setUp
and tearDown method.  This method is called before and after EVERY test
method in the class.  So you can't put anything in these methods unless
it's common to all test methods.  If one particular test method creates a
file on the filesystem and wants to clean up that file, you can't use setUp
/ tearDown because then every test method will be creating / cleaning up
files that they don't need.

So what if tests could be *either* a method *or* a nested class.  If it's a
nested class, it could provide setUp, tearDown, and run methods.  These
setup and teardown methods can do whatever they want specific to the
individual test, and it also provides the exception safe way to clean up.
For example, instead of this:

def test_method(self):
self.addTearDownHook(/* do cleanup here */)
# run test

You could have this:

def TestClass(TestMethodBase):
def tearDown(self):
/* do cleanup here */
TestMethodBase.tearDown(self)
def run(self):
# run test

It's a little bit more code, but a lot more flexible.  And we still support
the old method of using test methods too, so you only use this when
necessary.

Thoughts?

On Thu, Oct 22, 2015 at 11:38 AM Todd Fiala  wrote:

> (And side note: if you're pushing a "lambda: self.foo()" with no
> arguments, the lambda is unneeded and you can just push "self.foo" --- that
> cleanup hook pushed on most tests at the end of the file is a perfect
> example of an unneeded level of lambda indirection).
>
> On Wed, Oct 21, 2015 at 12:04 PM, Zachary Turner via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Well you can see them getting added via self.addTearDownHook(), so that
>> means they're called through an instance.  Specifically, it happens in
>> Base.tearDown(self), so it's basically identical (in concept) to if the
>> relevant handlers were called in the implementation of MyTest.tearDown(),
>> but different in order.
>>
>> I agree that it's useful in principle to be able to do what you suggest
>> in your example, but there's just no way to guarantee the right ordering if
>> you let the base class run the handlers.  If there actually *were* a
>> tearDown() function in your example, to be correct it would need to look
>> like this:
>>
>> class MyTest(TestBase):
>> def tearDown(self):
>> # run the teardown hooks
>> # Do the inverse of setUp()
>> super.tearDown()
>>
>> def test_1(self):
>> self.addTearDownHook(lambda: self.foo())
>> raise ValueError
>> def test_2(self):
>> self.addTearDownHook(lambda: self.bar())
>> raise ValueError
>>
>> One possible solution is to shift burden of maintaining the hooks list to
>> the individual test case.  E.g.
>>
>> class MyTest(TestBase):
>> self.hooks = []
>> def tearDown(self):
>> self.runTearDownHooks(self.hooks)   # This could be implemented
>> in TestBase, since now we can call it with our list at the right time.
>> # Do the inverse of setUp()
>> super.tearDown()
>>
>> def test_1(self):
>> self.hooks.append(lambda: self.foo())
>> raise ValueError
>> def test_2(self):
>> self.hooks.append(lambda: self.bar())
>> raise ValueError
>>
>> Almost no extra code to write, and should be bulletproof.
>>
>> On Wed, Oct 21, 2015 at 11:41 AM Greg Clayton  wrote:
>>
>>> I think it was mostly done to provide an exception safe way to cleanup
>>> stuff without having to override TestBase.tearDown(). I am guessing this
>>> cleanup happens on TestCase.tearDown() and not after the current test case
>>> right?
>>>
>>> I could see it being used to cleanup after a single test case in case
>>> you have:
>>>
>>> class MyTest(TestBase):
>>> def test_1(self):
>>> self.addTearDownHook(lambda: self.foo())
>>> raise ValueError
>>> def test_2(self):
>>> self.addTearDownHook(lambda: self.bar())
>>> raise ValueError
>>>
>>>
>>> Are these tearDowns happening per test function, or during class
>>> setup/teardown?
>>>
>>> > On Oct 21, 2015, at 9:33 AM, Zachary Turner via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>> >
>>> > Yea, that's what I think too.  I think this mechanism was probably
>>> inven

Re: [lldb-dev] lldb tests and tear down hooks

[Zachary Turner via lldb-dev]

There's no reason a finally block inside each test method wouldn't work,
and that's probably the simplest solution.

On Fri, Jan 15, 2016 at 12:59 AM Pavel Labath  wrote:

> On 14 January 2016 at 21:52, Zachary Turner via lldb-dev
>  wrote:
> > So what if tests could be *either* a method *or* a nested class.  If
> it's a
> > nested class, it could provide setUp, tearDown, and run methods.  These
> > setup and teardown methods can do whatever they want specific to the
> > individual test, and it also provides the exception safe way to clean up.
>
> I don't think this is supported by unittest, which is what determines
> what constitutes a "test". Nothing that couldn't be hacked around, but
> I don't see the added value over just using a finally block.
>
> Was there any reason we couldn't use that? I don't think it prevents
> code reuse, and it's a standard way of doing things that everyone
> should be familiar with.
>
> pl
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Getting lldb tests working on Hexagon

[Zachary Turner via lldb-dev]

If it should never run with x86_64 on Hexagon, then don't bother using
command lines, just change dotest.py so that when the target is hexagon,
the default archs doesn't include x86_64

On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For
> example, I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Getting lldb tests working on Hexagon

[Zachary Turner via lldb-dev]

Apparently I'm dumb, you actually should specify archs.  For example, on
Windows we use --arch=i686

If you don't specify a value for --arch, it uses the result of
`platform.machine()`.  If you do, it uses the list that you specify.  So
basically if you say --arch=i386 or something like, it will use that
instead of x86_64.

On Wed, Jan 20, 2016 at 10:56 AM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
>
> Where are the default archs defined? I’m not seeing it, looking through
> testcases/dotest.py.
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> *From:* Zachary Turner [mailto:ztur...@google.com]
> *Sent:* Wednesday, January 20, 2016 11:55 AM
> *To:* Ted Woodward; LLDB
>
>
> *Subject:* Re: [lldb-dev] Getting lldb tests working on Hexagon
>
>
>
> If it should never run with x86_64 on Hexagon, then don't bother using
> command lines, just change dotest.py so that when the target is hexagon,
> the default archs doesn't include x86_64
>
>
>
> On Wed, Jan 20, 2016 at 9:48 AM Ted Woodward via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> I’m trying to get the lldb tests running using lldb built with Hexagon
> support. Some tests are running correctly, but others are failing/skipped
> etc.
>
>
>
> First, I’d like to get it to skip tests that shouldn’t be run. For
> example, I see output that looks like this:
>
> Configuration: arch=x86_64
> compiler=/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Or
>
>
>
>
> Config=x86_64-/prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
>
>
>
> Those are clearly incorrect.
>
>
>
> My dotest line is:
>
> python dotest.py -C
> /prj/dsp/qdsp6/release/internal/branch-8.0/linux64/latest/Tools/bin/hexagon-clang
> --executable /local/mnt/workspace/ted/8.0/build/bin/lldb
>
>
>
> How does the –A flag affect the Configuration/Config outputs above?
>
>
>
> Ted
>
>
>
> --
>
> Qualcomm Innovation Center, Inc.
>
> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
> Linux Foundation Collaborative Project
>
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

I'm not sure I agree.  I don't think anything will be awkwardly formatted
with regards to the rest of the file.  The biggest thing this is going to
fix are whitespace at the end of lines, line breakign conventions, and
space between function name and parentheses.

If we're not going to enforce a coding style, why have one at all?
 clang-format enforces it.

On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala  wrote:

> Glad to see clang-format getting some improvements.
>
>
>
> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner 
> wrote:
>
>> As far as I'm aware, this is the last major incompatibility between
>> LLDB's style and clang-format's feature set.
>>
>> I would appreciate it if more people could try it out with a few of their
>> patches, and let me know if any LLDB style incompatibilities arise in the
>> formatted code.
>>
>> I would eventually like to move towards requiring that all patches be
>> clang-formatted before committing to LLDB.
>>
>
> Question to the group on that last part.  I think if we have a large body
> of code that is just getting a few tweaks to a method, having the patch run
> through the formatter could lead to some pretty ugly code.  Imagine a few
> lines of a file awkwardly formatted related to the rest of the file.  Since
> we're not trying to reformat everything at once (which makes for difficult
> code traceability), and given there was a large code base to start with
> before LLDB was part of LLVM, I'm not sure we want a blanket statement that
> says it must go through clang-format.  (I personally would be fine with
> doing whole new functions and other logical blocks of code via clang-format
> when inserted into existing code, but I think it probably extreme when
> we're talking about new little sections within existing functions).
>
> Thoughts?
>
>
>
> --
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

Also this is the same standard that applies to the rest of LLVM.
 clang-format your patches.  Just because we haven't been consistently
following the rules until now doesn't mean we should continue to not follow
the rules going forward.  This way eventually the codebase slowly converges
towards a properly formatted one.  If clang-format does something that you
think looks awkward with respect to the surrounding code (perhaps within a
single logical block or whatever else) then just touch a line of code in
the surrounding area so that clang-format will do it too. Since it only
formats the differential, you have as much control as you need to produce
something that a) is consistent with the rules, and b) doesn't look awkward
with respect to surrounding code.

On Thu, Jan 21, 2016 at 10:11 AM Zachary Turner  wrote:

> I'm not sure I agree.  I don't think anything will be awkwardly formatted
> with regards to the rest of the file.  The biggest thing this is going to
> fix are whitespace at the end of lines, line breakign conventions, and
> space between function name and parentheses.
>
> If we're not going to enforce a coding style, why have one at all?
>  clang-format enforces it.
>
> On Thu, Jan 21, 2016 at 8:41 AM Todd Fiala  wrote:
>
>> Glad to see clang-format getting some improvements.
>>
>>
>>
>> On Thu, Jan 7, 2016 at 10:30 AM, Zachary Turner 
>> wrote:
>>
>>> As far as I'm aware, this is the last major incompatibility between
>>> LLDB's style and clang-format's feature set.
>>>
>>> I would appreciate it if more people could try it out with a few of
>>> their patches, and let me know if any LLDB style incompatibilities arise in
>>> the formatted code.
>>>
>>> I would eventually like to move towards requiring that all patches be
>>> clang-formatted before committing to LLDB.
>>>
>>
>> Question to the group on that last part.  I think if we have a large body
>> of code that is just getting a few tweaks to a method, having the patch run
>> through the formatter could lead to some pretty ugly code.  Imagine a few
>> lines of a file awkwardly formatted related to the rest of the file.  Since
>> we're not trying to reformat everything at once (which makes for difficult
>> code traceability), and given there was a large code base to start with
>> before LLDB was part of LLVM, I'm not sure we want a blanket statement that
>> says it must go through clang-format.  (I personally would be fine with
>> doing whole new functions and other logical blocks of code via clang-format
>> when inserted into existing code, but I think it probably extreme when
>> we're talking about new little sections within existing functions).
>>
>> Thoughts?
>>
>>
>>
>> --
>> -Todd
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan  wrote:

> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them.  I’m concerned about
> a specific class of functions, though.  Let’s say I have a function that
> has had lots of activity (I’m thinking of, for example, ParseType off in
> the DWARF parser).  Unfortunately, such functions tend to be the ones that
> benefit most from clang-format.
>
> In such a function, there’s a lot of useful history available via svn
> blame that helps when fixing bugs.  My concern is that if someone
> clang-formats this function after applying the *k*th fix, suddenly I've
> lost convenient access to that history.  It’s only available with a fair
> amount of pain, and this pain increases as more fixes are applied because
> now I need to interleave the info before and after reformatting.
>
> Would it be reasonable to mark such functions as “Don’t clang-format”?
> That could be also interpreted as a “// TODO add comments so what this does
> is more understandable”
>

Well again by default it's only going to format the code you touch in yoru
diff plus 1 or 2 surrounding lines.  So having it format an entire function
is something you would have to explicitly go out of your way to do.  So
it's a judgement call.  If you think the function would be better off
clang-formatting the entire thing, do that.  If you just want to format the
lines you're touching because you were in there anyway, that's the default
behavior.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

By the way, one place where you are guaranteed to get undesirable results
is where you have a large array formatted so that the columns line up.
Like in our options tables in the CommandObjects.  If you're using git, one
way to avoid having clang-format touch these files is to commit that file
by itself, then run git clang-format (since it only looks at staged files),
then git commit --amend.  But of course that will gloss over any other
changes you made to the file as well.  But in any case, it's another trick
I've found useful occasionally.

On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
wrote:

> Agreed.  My guidance has been that we go ahead and require submitters to
> use clang-format for patches, but to acknowledge that there may be cases
> where this produces undesirable results.  Manual formatting to correct
> these issues is acceptable and should lead to discussions about concrete
> examples where the automated approach is imperfect.
>
> Kate Stone k8st...@apple.com
>  Xcode Runtime Analysis Tools
>
> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Okay, sounds like a reasonable thing to try.  We can always review it if
> it causes any real issues.
>
> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
> wrote:
>
>>
>>
>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
>> wrote:
>>
>>> I tend to agree with Zachary on the overall principle – and I would be
>>> willing to clang-format functions when I modify them.  I’m concerned about
>>> a specific class of functions, though.  Let’s say I have a function that
>>> has had lots of activity (I’m thinking of, for example, ParseType off in
>>> the DWARF parser).  Unfortunately, such functions tend to be the ones that
>>> benefit most from clang-format.
>>>
>>> In such a function, there’s a lot of useful history available via svn
>>> blame that helps when fixing bugs.  My concern is that if someone
>>> clang-formats this function after applying the *k*th fix, suddenly I've
>>> lost convenient access to that history.  It’s only available with a fair
>>> amount of pain, and this pain increases as more fixes are applied because
>>> now I need to interleave the info before and after reformatting.
>>>
>>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>>> That could be also interpreted as a “// TODO add comments so what this does
>>> is more understandable”
>>>
>>
>> Well again by default it's only going to format the code you touch in
>> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
>> function is something you would have to explicitly go out of your way to
>> do.  So it's a judgement call.  If you think the function would be better
>> off clang-formatting the entire thing, do that.  If you just want to format
>> the lines you're touching because you were in there anyway, that's the
>> default behavior.
>>
>
>
>
> --
> -Todd
>
> ___
>
>
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

When you compile, you need to use -fuse-ld=lld.  Most people miss this step.

That said, it's not supposed to hang, but it is supposed to not work.

What's the command line you used with clang?

On Fri, Jan 22, 2016 at 11:08 AM Red Skotina  wrote:

> Look like I miss something , but i cant debug simple program program
> compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
> developer console .
>  i use lldb from trunk
> #include "stdio.h"
>
> int main(int argc, char **argv)
> {
> printf("hello1\n");
> printf("hello2\n");
> return 0;
> }
>
> d:\code\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6264 launching
>
> ---
> a.exe and lldb hangs
>
> What i doing wrong ?
>
>
> 2016-01-08 0:42 GMT+03:00 Red Skotina :
>
>> Nice to hear. I should answer after some time of using
>>
>> 2016-01-07 21:04 GMT+03:00 Zachary Turner :
>>
>>> Feel free to file bugs or post your feedback here after you use about
>>> what worked, what didn't work, what's missing, etc.  Anything that doesn't
>>> work is a bug that I would like to fix.
>>>
>>> On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner 
>>> wrote:
>>>
 Hi, I guess I should make a new blog post at some point, or post status
 on the website.  Here's my best estimate at what you can expect.

 * Most common debugging scenarios should work.  Run under debugger,
 attach to process, interrupt, continue, print variable values, evaluate
 expressions, etc.
 * Step-over might be unstable in certain scenarios
 * Conditional breakpoints don't work
 * Hardware watchpoints don't work
 * Expression evaluation might not work in some advanced cases.

 The main big feature that has been added since the original blog post
 is support for windows minidump files.  So you can create a minidump of a
 stopped process from inside LLDB, and you can load up a minidump and do
 post-mortem debugging.

 On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> Where can i look lldb status for native debug at Windows?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

Under llvm/tools also checkout lld.  So your directories should look like
this:

llvm
\-- tools
\-- clang
\-- lldb
\-- lld

Then re-run cmake to generate build files again, recompile, and then it
should work.  Right now the problem is that lld-link.exe hasn't been
compiled yet.

On Fri, Jan 22, 2016 at 12:22 PM Red Skotina  wrote:

> yes, i miss it. but anyway dont work
>
>
> d:\code\Unity_Unpacker\tests\test2>clang -v -fuse-ld=lld main.cpp
> clang version 3.9.0 (trunk 258509)
> Target: i686-pc-windows-msvc
> Thread model: posix
> InstalledDir: d:\code\llvm\build\bin
>  "d:\\code\\llvm\\build\\bin\\clang.exe" -cc1 -triple
> i686-pc-windows-msvc18.0.0
>  -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free
> -disable-ll
> vm-verifier -main-file-name main.cpp -mrelocation-model static
> -mthread-model po
> six -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
> -target-c
> pu pentium4 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
> "d:\\code\\
> llvm\\build\\bin\\..\\lib\\clang\\3.9.0" -internal-isystem
> "d:\\code\\llvm\\buil
> d\\bin\\..\\lib\\clang\\3.9.0\\include" -internal-isystem "C:\\Program
> Files (x8
> 6)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE" -internal-isystem
> "C:\\Program Fi
> les (x86)\\Microsoft Visual Studio 14.0\\VC\\ATLMFC\\INCLUDE"
> -internal-isystem
> "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\ucrt"
> -intern
> al-isystem "C:\\Program Files (x86)\\Windows
> Kits\\NETFXSDK\\4.6.1\\include\\um"
>  -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includeshare
> d" -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includeum"
>  -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includewinrt
> " -fdeprecated-macro -fdebug-compilation-dir
> "d:\\code\\Unity_Unpacker\\tests\\t
> est2" -ferror-limit 19 -fmessage-length 80 -fms-extensions
> -fms-compatibility -f
> ms-compatibility-version=18 -std=c++11 -fno-threadsafe-statics
> -fdelayed-templat
> e-parsing -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
> -o "C
> :\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o" -x c++ main.cpp
> clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target
> i686-pc-windows
> -msvc
> #include "..." search starts here:
> #include <...> search starts here:
>  d:\code\llvm\build\bin\..\lib\clang\3.9.0\include
>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE
>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE
>  C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
>  C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
>  C:\Program Files (x86)\Windows Kits\8.1\include\\shared
>  C:\Program Files (x86)\Windows Kits\8.1\include\\um
>  C:\Program Files (x86)\Windows Kits\8.1\include\\winrt
> End of search list.
>  "d:\\code\\llvm\\build\\bin\\lld-link.exe" -out:a.exe -defaultlib:libcmt
> -nolog
> o "C:\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o"
>
> d:\code\Unity_Unpacker\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6448 launching
>
> --
> process hang
>
> 2016-01-22 22:13 GMT+03:00 Zachary Turner :
>
>> When you compile, you need to use -fuse-ld=lld.  Most people miss this
>> step.
>>
>> That said, it's not supposed to hang, but it is supposed to not work.
>>
>> What's the command line you used with clang?
>>
>> On Fri, Jan 22, 2016 at 11:08 AM Red Skotina 
>> wrote:
>>
>>> Look like I miss something , but i cant debug simple program program
>>> compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
>>> developer console .
>>>  i use lldb from trunk
>>> #include "stdio.h"
>>>
>>> int main(int argc, char **argv)
>>> {
>>> printf("hello1\n");
>>> printf("hello2\n");
>>> return 0;
>>> }
>>>
>>> d:\code\tests\test2>lldb a.exe
>>> (lldb) target create "a.exe"
>>> Current executable set to 'a.exe' (i686).
>>> (lldb) run
>>>
>>> Process 6264 launching
>>>
>>> ---
>>> a.exe and lldb hangs
>>>
>>> What i doing wrong ?
>>>
>>>
>>> 2016-01-08 0:42 GMT+03:00 Red Skotina :
>>>
 Nice to hear. I should answer after some time of using

 2016-01-07 21:04 GMT+03:00 Zachary Turner :

> Feel free to file bugs or post your feedback here after you use about
> what worked, what didn't work, what's missing, etc.  Anything that doesn't
> work is a bug that I would like to fix.
>
> On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner 
> wrote:
>
>> Hi, I guess I should make a new blog post at some point, or post
>> status on the website.  Here's my best estimate at what you can expect.
>>
>> * Most common debugging scenarios should work.  Run under debugger,
>> attach to process, interrupt, continue, print variable values, evaluate
>> expressions, etc.
>> * Step

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

Oh neat, I didn't know about that.  I'll play around with that when I have
some time and see how the behavior works with respect to git clang-format
(which formats diffs instead of entire files)

On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath  wrote:

> Apparently, you can also disable the formatting of a piece of code by
> a magic comment. Could be quite useful for those tables. From the
> docs:
> -
> Clang-format understands also special comments that switch formatting
> in a delimited range. The code between a comment // clang-format off
> or /* clang-format off */ up to a comment // clang-format on or /*
> clang-format on */ will not be formatted. The comments themselves will
> be formatted (aligned) normally.
> -
>
>
> On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
>  wrote:
> > Okay, thanks for the tip!
> >
> > On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner 
> wrote:
> >>
> >> By the way, one place where you are guaranteed to get undesirable
> results
> >> is where you have a large array formatted so that the columns line up.
> Like
> >> in our options tables in the CommandObjects.  If you're using git, one
> way
> >> to avoid having clang-format touch these files is to commit that file by
> >> itself, then run git clang-format (since it only looks at staged files),
> >> then git commit --amend.  But of course that will gloss over any other
> >> changes you made to the file as well.  But in any case, it's another
> trick
> >> I've found useful occasionally.
> >>
> >> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
> >> wrote:
> >>>
> >>> Agreed.  My guidance has been that we go ahead and require submitters
> to
> >>> use clang-format for patches, but to acknowledge that there may be
> cases
> >>> where this produces undesirable results.  Manual formatting to correct
> these
> >>> issues is acceptable and should lead to discussions about concrete
> examples
> >>> where the automated approach is imperfect.
> >>>
> >>> Kate Stone k8st...@apple.com
> >>>  Xcode Runtime Analysis Tools
> >>>
> >>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
> >>>  wrote:
> >>>
> >>> Okay, sounds like a reasonable thing to try.  We can always review it
> if
> >>> it causes any real issues.
> >>>
> >>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
> >>> wrote:
> 
> 
> 
>  On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
>  wrote:
> >
> > I tend to agree with Zachary on the overall principle – and I would
> be
> > willing to clang-format functions when I modify them.  I’m concerned
> about a
> > specific class of functions, though.  Let’s say I have a function
> that has
> > had lots of activity (I’m thinking of, for example, ParseType off in
> the
> > DWARF parser).  Unfortunately, such functions tend to be the ones
> that
> > benefit most from clang-format.
> >
> > In such a function, there’s a lot of useful history available via svn
> > blame that helps when fixing bugs.  My concern is that if someone
> > clang-formats this function after applying the kth fix, suddenly
> I've lost
> > convenient access to that history.  It’s only available with a fair
> amount
> > of pain, and this pain increases as more fixes are applied because
> now I
> > need to interleave the info before and after reformatting.
> >
> > Would it be reasonable to mark such functions as “Don’t
> clang-format”?
> > That could be also interpreted as a “// TODO add comments so what
> this does
> > is more understandable”
> 
> 
>  Well again by default it's only going to format the code you touch in
>  yoru diff plus 1 or 2 surrounding lines.  So having it format an
> entire
>  function is something you would have to explicitly go out of your way
> to do.
>  So it's a judgement call.  If you think the function would be better
> off
>  clang-formatting the entire thing, do that.  If you just want to
> format the
>  lines you're touching because you were in there anyway, that's the
> default
>  behavior.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -Todd
> >>>
> >>> ___
> >>>
> >>>
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > -Todd
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

Ahh you probably need to add -g to clang, otherwise it's not generating
debug info.  I've never tried debugging a binary with no debug info.
Obviously it shouldn't hang, but either way it's just not something we've
tested on Windows.



On Sat, Jan 23, 2016 at 12:51 AM Red Skotina  wrote:

> yes. i doing it. you can see what clang use d:\\code\\llvm\\build\\bin\\
> lld-link.exe
> but anyway it is hang :(
>
> 2016-01-22 23:30 GMT+03:00 Zachary Turner :
>
>> Under llvm/tools also checkout lld.  So your directories should look like
>> this:
>>
>> llvm
>> \-- tools
>> \-- clang
>> \-- lldb
>> \-- lld
>>
>> Then re-run cmake to generate build files again, recompile, and then it
>> should work.  Right now the problem is that lld-link.exe hasn't been
>> compiled yet.
>>
>> On Fri, Jan 22, 2016 at 12:22 PM Red Skotina 
>> wrote:
>>
>>> yes, i miss it. but anyway dont work
>>>
>>>
>>> d:\code\Unity_Unpacker\tests\test2>clang -v -fuse-ld=lld main.cpp
>>> clang version 3.9.0 (trunk 258509)
>>> Target: i686-pc-windows-msvc
>>> Thread model: posix
>>> InstalledDir: d:\code\llvm\build\bin
>>>  "d:\\code\\llvm\\build\\bin\\clang.exe" -cc1 -triple
>>> i686-pc-windows-msvc18.0.0
>>>  -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free
>>> -disable-ll
>>> vm-verifier -main-file-name main.cpp -mrelocation-model static
>>> -mthread-model po
>>> six -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
>>> -target-c
>>> pu pentium4 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>>> "d:\\code\\
>>> llvm\\build\\bin\\..\\lib\\clang\\3.9.0" -internal-isystem
>>> "d:\\code\\llvm\\buil
>>> d\\bin\\..\\lib\\clang\\3.9.0\\include" -internal-isystem "C:\\Program
>>> Files (x8
>>> 6)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE" -internal-isystem
>>> "C:\\Program Fi
>>> les (x86)\\Microsoft Visual Studio 14.0\\VC\\ATLMFC\\INCLUDE"
>>> -internal-isystem
>>> "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\ucrt"
>>> -intern
>>> al-isystem "C:\\Program Files (x86)\\Windows
>>> Kits\\NETFXSDK\\4.6.1\\include\\um"
>>>  -internal-isystem "C:\\Program Files (x86)\\Windows
>>> Kits\\8.1\\includeshare
>>> d" -internal-isystem "C:\\Program Files (x86)\\Windows
>>> Kits\\8.1\\includeum"
>>>  -internal-isystem "C:\\Program Files (x86)\\Windows
>>> Kits\\8.1\\includewinrt
>>> " -fdeprecated-macro -fdebug-compilation-dir
>>> "d:\\code\\Unity_Unpacker\\tests\\t
>>> est2" -ferror-limit 19 -fmessage-length 80 -fms-extensions
>>> -fms-compatibility -f
>>> ms-compatibility-version=18 -std=c++11 -fno-threadsafe-statics
>>> -fdelayed-templat
>>> e-parsing -fobjc-runtime=gcc -fdiagnostics-show-option
>>> -fcolor-diagnostics -o "C
>>> :\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o" -x c++ main.cpp
>>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target
>>> i686-pc-windows
>>> -msvc
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>>  d:\code\llvm\build\bin\..\lib\clang\3.9.0\include
>>>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE
>>>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE
>>>  C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
>>>  C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
>>>  C:\Program Files (x86)\Windows Kits\8.1\include\\shared
>>>  C:\Program Files (x86)\Windows Kits\8.1\include\\um
>>>  C:\Program Files (x86)\Windows Kits\8.1\include\\winrt
>>> End of search list.
>>>  "d:\\code\\llvm\\build\\bin\\lld-link.exe" -out:a.exe
>>> -defaultlib:libcmt -nolog
>>> o "C:\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o"
>>>
>>> d:\code\Unity_Unpacker\tests\test2>lldb a.exe
>>> (lldb) target create "a.exe"
>>> Current executable set to 'a.exe' (i686).
>>> (lldb) run
>>>
>>> Process 6448 launching
>>>
>>> --
>>> process hang
>>>
>>> 2016-01-22 22:13 GMT+03:00 Zachary Turner :
>>>
 When you compile, you need to use -fuse-ld=lld.  Most people miss this
 step.

 That said, it's not supposed to hang, but it is supposed to not work.

 What's the command line you used with clang?

 On Fri, Jan 22, 2016 at 11:08 AM Red Skotina 
 wrote:

> Look like I miss something , but i cant debug simple program program
> compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
> developer console .
>  i use lldb from trunk
> #include "stdio.h"
>
> int main(int argc, char **argv)
> {
> printf("hello1\n");
> printf("hello2\n");
> return 0;
> }
>
> d:\code\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6264 launching
>
> ---
> a.exe and lldb hangs
>
> What i doing wrong ?
>
>
> 2016-01-08 0:42 GMT+03:00 Red Skotina :
>
>> Nice to hear. I 

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

I'm out of office until Monday, but I'll try to reproduce this then and
update.  Never seen a hang before, so I wonder if there's something
different about your machine that we haven't thought of or taken into
account.  Either way I'll update Monday.

On Sat, Jan 23, 2016 at 12:57 AM Red Skotina  wrote:

> same.
>
> d:\code\Unity_Unpacker\tests\test2>clang -g -fuse-ld=lld main.cpp
>
> d:\code\Unity_Unpacker\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6984 launching
> ---
> hangs
>
> 2016-01-23 11:54 GMT+03:00 Zachary Turner :
>
>> Ahh you probably need to add -g to clang, otherwise it's not generating
>> debug info.  I've never tried debugging a binary with no debug info.
>> Obviously it shouldn't hang, but either way it's just not something we've
>> tested on Windows.
>>
>>
>>
>> On Sat, Jan 23, 2016 at 12:51 AM Red Skotina 
>> wrote:
>>
>>> yes. i doing it. you can see what clang use d:\\code\\llvm\\build\\bin\\
>>> lld-link.exe
>>> but anyway it is hang :(
>>>
>>> 2016-01-22 23:30 GMT+03:00 Zachary Turner :
>>>
 Under llvm/tools also checkout lld.  So your directories should look
 like this:

 llvm
 \-- tools
 \-- clang
 \-- lldb
 \-- lld

 Then re-run cmake to generate build files again, recompile, and then it
 should work.  Right now the problem is that lld-link.exe hasn't been
 compiled yet.

 On Fri, Jan 22, 2016 at 12:22 PM Red Skotina 
 wrote:

> yes, i miss it. but anyway dont work
>
>
> d:\code\Unity_Unpacker\tests\test2>clang -v -fuse-ld=lld main.cpp
> clang version 3.9.0 (trunk 258509)
> Target: i686-pc-windows-msvc
> Thread model: posix
> InstalledDir: d:\code\llvm\build\bin
>  "d:\\code\\llvm\\build\\bin\\clang.exe" -cc1 -triple
> i686-pc-windows-msvc18.0.0
>  -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free
> -disable-ll
> vm-verifier -main-file-name main.cpp -mrelocation-model static
> -mthread-model po
> six -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
> -target-c
> pu pentium4 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
> "d:\\code\\
> llvm\\build\\bin\\..\\lib\\clang\\3.9.0" -internal-isystem
> "d:\\code\\llvm\\buil
> d\\bin\\..\\lib\\clang\\3.9.0\\include" -internal-isystem "C:\\Program
> Files (x8
> 6)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE" -internal-isystem
> "C:\\Program Fi
> les (x86)\\Microsoft Visual Studio 14.0\\VC\\ATLMFC\\INCLUDE"
> -internal-isystem
> "C:\\Program Files (x86)\\Windows
> Kits\\10\\include\\10.0.10240.0\\ucrt" -intern
> al-isystem "C:\\Program Files (x86)\\Windows
> Kits\\NETFXSDK\\4.6.1\\include\\um"
>  -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includeshare
> d" -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includeum"
>  -internal-isystem "C:\\Program Files (x86)\\Windows
> Kits\\8.1\\includewinrt
> " -fdeprecated-macro -fdebug-compilation-dir
> "d:\\code\\Unity_Unpacker\\tests\\t
> est2" -ferror-limit 19 -fmessage-length 80 -fms-extensions
> -fms-compatibility -f
> ms-compatibility-version=18 -std=c++11 -fno-threadsafe-statics
> -fdelayed-templat
> e-parsing -fobjc-runtime=gcc -fdiagnostics-show-option
> -fcolor-diagnostics -o "C
> :\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o" -x c++ main.cpp
> clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target
> i686-pc-windows
> -msvc
> #include "..." search starts here:
> #include <...> search starts here:
>  d:\code\llvm\build\bin\..\lib\clang\3.9.0\include
>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE
>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE
>  C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
>  C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
>  C:\Program Files (x86)\Windows Kits\8.1\include\\shared
>  C:\Program Files (x86)\Windows Kits\8.1\include\\um
>  C:\Program Files (x86)\Windows Kits\8.1\include\\winrt
> End of search list.
>  "d:\\code\\llvm\\build\\bin\\lld-link.exe" -out:a.exe
> -defaultlib:libcmt -nolog
> o "C:\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o"
>
> d:\code\Unity_Unpacker\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6448 launching
>
> --
> process hang
>
> 2016-01-22 22:13 GMT+03:00 Zachary Turner :
>
>> When you compile, you need to use -fuse-ld=lld.  Most people miss
>> this step.
>>
>> That said, it's not supposed to hang, but it is supposed to not work.
>>
>> What's the command line you used with 

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

sorry, yea I stuck around for a while after that patch waiting for emails,
but nothing came through.  Please revert in the meantime, I'll work on a
fix tomorrow.

On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I think I see what happened w/r/t why no emails when out when the build
> went heavy red.  (Well they went out internally, but not externally).  When
> I made the change on Friday to improve the workflow for the Green Dragon OS
> X builder and test output, I switched email over to the builder step, which
> doesn't know anything about who made which changes.  So it didn't know who
> to put on the blame list for the broken build.  Drats, I'll have to figure
> that out.
>
> I'd really prefer to have all those stages happening in one build step to
> keep it clear what's going on.
>
> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>
>> Well our whole test suite just stopped running, so yes.
>>
>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>> wrote:
>>
>>>
>>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Not sure exactly what it is, but all the tests are failing due to some
>>> bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.
>>>
>>>
>>> Author: zturner
>>> Date: Mon Jan 25 18:59:42 2016
>>> New Revision: 258759
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>>> Log:
>>> Write the session log file in UTF-8.
>>>
>>> Previously we were writing in the default encoding, which depends
>>> on the operating system and is not guaranteed to be unicode aware.
>>> On Python 3, this would lead to a situation where writing unicode
>>> text to the log file generates an exception.  The fix here is to
>>> write session logs using the proper encoding, which incidentally
>>> fixes another test, so xfail is removed from that.
>>>
>>> sounds like a likely culprit from what you’re saying
>>>
>>> I am not going to be able to look at details on that, but here's a link
>>> to the log on the OS X builder:
>>>
>>>
>>> Do you want me to revert?
>>>
>>> http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console
>>>
>>> --
>>> -Todd
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>> Thanks,
>>> *- Enrico*
>>> 📩 egranata@.com ☎️ 27683
>>>
>>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

I'm also not sure why Linux isn't failing.  Looking at the documentation
for io.write https://docs.python.org/2/library/io.html#text-i-o>
object, i see this:

write(*s*) 

Write the unicode 
 string *s* to the stream and return the number of characters written.
So clearly it does have to be a unicode object, and saying
print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
string to the file.

What's the pattern you're referring to?  You can't convert a string to a
unicode without specifying an encoding, and it seems annoying to have to do
that on every single call to print.

On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner  wrote:

> sorry, yea I stuck around for a while after that patch waiting for emails,
> but nothing came through.  Please revert in the meantime, I'll work on a
> fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the build
>> went heavy red.  (Well they went out internally, but not externally).  When
>> I made the change on Friday to improve the workflow for the Green Dragon OS
>> X builder and test output, I switched email over to the builder step, which
>> doesn't know anything about who made which changes.  So it didn't know who
>> to put on the blame list for the broken build.  Drats, I'll have to figure
>> that out.
>>
>> I'd really prefer to have all those stages happening in one build step to
>> keep it clear what's going on.
>>
>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala  wrote:
>>
>>> Well our whole test suite just stopped running, so yes.
>>>
>>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>>> wrote:
>>>

 On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Not sure exactly what it is, but all the tests are failing due to some
 bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to guess.


 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759

 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.

 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where writing unicode
 text to the log file generates an exception.  The fix here is to
 write session logs using the proper encoding, which incidentally
 fixes another test, so xfail is removed from that.

 sounds like a likely culprit from what you’re saying

 I am not going to be able to look at details on that, but here's a link
 to the log on the OS X builder:


 Do you want me to revert?

 http://lab.llvm.org:8080/green/job/lldb_build_test/16166/console

 --
 -Todd
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



 Thanks,
 *- Enrico*
 📩 egranata@.com ☎️ 27683


>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

No worries, worst case scenario a sledgehammer solution is to change all
the places where we write to the session file to convert to unicode first
(which would be a trivial conversion, since everything is going to be
ascii, which is already valid utf 8).

The reason a problem arose at all is because TestCxxWcharT.py tried to
write actual unicode characters to the session file.  I don't think there's
any way to prevent that because the characters could appear in a backtrace,
in a variable name, or in a test that is specifically testing unicode.  So
we can't just have the one place that needs to write unicode encode it as
bytes because there's no one place.

I'll sleep on it and try to see if there's a better solution.  Maybe we can
just make a function called write_session_file() that takes either a string
or a unicode, converts it to a unicode if it's not already one, and then
writes.

On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:

> Okay we're back to green here:
> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>
> Thanks, Enrico!
>
> Zachary, I may let this rest until the morning.  If you want to try
> something else, shoot me a patch and I'll gladly try it.
>
> -Todd
>
> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala  wrote:
>
>> It's in item 3 from Effective Python, by Brett Slatkin, which goes over
>> having methods that always go to unicode or to byte streams taking either
>> unicode or byte style strings, for both Python 2 and Python 3.  Essentially
>> you figure out what you want it to be in, and you write a couple helper
>> routes to go in either the "to unicode" or the "to bytes" direction.  It
>> basically looks at the type of the string/bytes you give it, and makes sure
>> it becomes what you need.  It's going to assume an encoding like utf-8.
>>
>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>> wrote:
>>
>>> I'm also not sure why Linux isn't failing.  Looking at the documentation
>>> for io.write object, i see this:
>>>
>>> write(*s*)
>>> 
>>>
>>> Write the unicode
>>>  string *s* to
>>> the stream and return the number of characters written.
>>> So clearly it does have to be a unicode object, and saying
>>> print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
>>> string to the file.
>>>
>>> What's the pattern you're referring to?  You can't convert a string to a
>>> unicode without specifying an encoding, and it seems annoying to have to do
>>> that on every single call to print.
>>>
>>> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
>>> wrote:
>>>
 sorry, yea I stuck around for a while after that patch waiting for
 emails, but nothing came through.  Please revert in the meantime, I'll work
 on a fix tomorrow.

 On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> I think I see what happened w/r/t why no emails when out when the
> build went heavy red.  (Well they went out internally, but not
> externally).  When I made the change on Friday to improve the workflow for
> the Green Dragon OS X builder and test output, I switched email over to 
> the
> builder step, which doesn't know anything about who made which changes.  
> So
> it didn't know who to put on the blame list for the broken build.  Drats,
> I'll have to figure that out.
>
> I'd really prefer to have all those stages happening in one build step
> to keep it clear what's going on.
>
> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
> wrote:
>
>> Well our whole test suite just stopped running, so yes.
>>
>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>> wrote:
>>
>>>
>>> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Not sure exactly what it is, but all the tests are failing due to
>>> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
>>> guess.
>>>
>>>
>>> Author: zturner
>>> Date: Mon Jan 25 18:59:42 2016
>>> New Revision: 258759
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
>>> Log:
>>> Write the session log file in UTF-8.
>>>
>>> Previously we were writing in the default encoding, which depends
>>> on the operating system and is not guaranteed to be unicode aware.
>>> On Python 3, this would lead to a situation where writing unicode
>>> text to the log file generates an exception.  The fix here is to
>>> write session logs using the proper encoding, which incidentally
>>> fixes another test, so xfail is removed from that.
>>>
>>> sounds like a likely culprit from what you’re saying
>>>
>>> I am not going to be able to look at details on that, but here's a
>>> link to the log on the OS X builder:
>>>
>>>
>

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

Can one of you guys try out this patch and see if it works?  If so I'll
commit it.

I don't know of a way to make this "elegant".  i.e. a single syntax /
paradigm that works in both versions without introducing any helper
functions.


On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner  wrote:

> No worries, worst case scenario a sledgehammer solution is to change all
> the places where we write to the session file to convert to unicode first
> (which would be a trivial conversion, since everything is going to be
> ascii, which is already valid utf 8).
>
> The reason a problem arose at all is because TestCxxWcharT.py tried to
> write actual unicode characters to the session file.  I don't think there's
> any way to prevent that because the characters could appear in a backtrace,
> in a variable name, or in a test that is specifically testing unicode.  So
> we can't just have the one place that needs to write unicode encode it as
> bytes because there's no one place.
>
> I'll sleep on it and try to see if there's a better solution.  Maybe we
> can just make a function called write_session_file() that takes either a
> string or a unicode, converts it to a unicode if it's not already one, and
> then writes.
>
> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:
>
>> Okay we're back to green here:
>> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>>
>> Thanks, Enrico!
>>
>> Zachary, I may let this rest until the morning.  If you want to try
>> something else, shoot me a patch and I'll gladly try it.
>>
>> -Todd
>>
>> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala  wrote:
>>
>>> It's in item 3 from Effective Python, by Brett Slatkin, which goes over
>>> having methods that always go to unicode or to byte streams taking either
>>> unicode or byte style strings, for both Python 2 and Python 3.  Essentially
>>> you figure out what you want it to be in, and you write a couple helper
>>> routes to go in either the "to unicode" or the "to bytes" direction.  It
>>> basically looks at the type of the string/bytes you give it, and makes sure
>>> it becomes what you need.  It's going to assume an encoding like utf-8.
>>>
>>> On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
>>> wrote:
>>>
 I'm also not sure why Linux isn't failing.  Looking at the
 documentation for io.write object, i see this:

 write(*s*)
 

 Write the unicode
  string *s* to
 the stream and return the number of characters written.
 So clearly it does have to be a unicode object, and saying
 print(self.getvalue(), file=self.session) is clearly NOT printing a unicode
 string to the file.

 What's the pattern you're referring to?  You can't convert a string to
 a unicode without specifying an encoding, and it seems annoying to have to
 do that on every single call to print.

 On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
 wrote:

> sorry, yea I stuck around for a while after that patch waiting for
> emails, but nothing came through.  Please revert in the meantime, I'll 
> work
> on a fix tomorrow.
>
> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> I think I see what happened w/r/t why no emails when out when the
>> build went heavy red.  (Well they went out internally, but not
>> externally).  When I made the change on Friday to improve the workflow 
>> for
>> the Green Dragon OS X builder and test output, I switched email over to 
>> the
>> builder step, which doesn't know anything about who made which changes.  
>> So
>> it didn't know who to put on the blame list for the broken build.  Drats,
>> I'll have to figure that out.
>>
>> I'd really prefer to have all those stages happening in one build
>> step to keep it clear what's going on.
>>
>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
>> wrote:
>>
>>> Well our whole test suite just stopped running, so yes.
>>>
>>> On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata 
>>> wrote:
>>>

 On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

 Not sure exactly what it is, but all the tests are failing due to
 some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
 guess.


 Author: zturner
 Date: Mon Jan 25 18:59:42 2016
 New Revision: 258759

 URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
 Log:
 Write the session log file in UTF-8.

 Previously we were writing in the default encoding, which depends
 on the operating system and is not guaranteed to be unicode aware.
 On Python 3, this would lead to a situation where wri

Re: [lldb-dev] something just toasted the test suite on OS X

[Zachary Turner via lldb-dev]

Bump.  Can I re-submit this?

On Tue, Jan 26, 2016 at 10:54 AM Zachary Turner  wrote:

> Can one of you guys try out this patch and see if it works?  If so I'll
> commit it.
>
> I don't know of a way to make this "elegant".  i.e. a single syntax /
> paradigm that works in both versions without introducing any helper
> functions.
>
>
> On Tue, Jan 26, 2016 at 12:26 AM Zachary Turner 
> wrote:
>
>> No worries, worst case scenario a sledgehammer solution is to change all
>> the places where we write to the session file to convert to unicode first
>> (which would be a trivial conversion, since everything is going to be
>> ascii, which is already valid utf 8).
>>
>> The reason a problem arose at all is because TestCxxWcharT.py tried to
>> write actual unicode characters to the session file.  I don't think there's
>> any way to prevent that because the characters could appear in a backtrace,
>> in a variable name, or in a test that is specifically testing unicode.  So
>> we can't just have the one place that needs to write unicode encode it as
>> bytes because there's no one place.
>>
>> I'll sleep on it and try to see if there's a better solution.  Maybe we
>> can just make a function called write_session_file() that takes either a
>> string or a unicode, converts it to a unicode if it's not already one, and
>> then writes.
>>
>> On Mon, Jan 25, 2016 at 9:45 PM Todd Fiala  wrote:
>>
>>> Okay we're back to green here:
>>> http://lab.llvm.org:8080/green/job/lldb_build_test/16173/
>>>
>>> Thanks, Enrico!
>>>
>>> Zachary, I may let this rest until the morning.  If you want to try
>>> something else, shoot me a patch and I'll gladly try it.
>>>
>>> -Todd
>>>
>>> On Mon, Jan 25, 2016 at 9:16 PM, Todd Fiala 
>>> wrote:
>>>
 It's in item 3 from Effective Python, by Brett Slatkin, which goes over
 having methods that always go to unicode or to byte streams taking either
 unicode or byte style strings, for both Python 2 and Python 3.  Essentially
 you figure out what you want it to be in, and you write a couple helper
 routes to go in either the "to unicode" or the "to bytes" direction.  It
 basically looks at the type of the string/bytes you give it, and makes sure
 it becomes what you need.  It's going to assume an encoding like utf-8.

 On Mon, Jan 25, 2016 at 9:09 PM, Zachary Turner 
 wrote:

> I'm also not sure why Linux isn't failing.  Looking at the
> documentation for io.write object, i see this:
>
> write(*s*)
> 
>
> Write the unicode
>  string *s* to
> the stream and return the number of characters written.
> So clearly it does have to be a unicode object, and saying
> print(self.getvalue(), file=self.session) is clearly NOT printing a 
> unicode
> string to the file.
>
> What's the pattern you're referring to?  You can't convert a string to
> a unicode without specifying an encoding, and it seems annoying to have to
> do that on every single call to print.
>
> On Mon, Jan 25, 2016 at 8:54 PM Zachary Turner 
> wrote:
>
>> sorry, yea I stuck around for a while after that patch waiting for
>> emails, but nothing came through.  Please revert in the meantime, I'll 
>> work
>> on a fix tomorrow.
>>
>> On Mon, Jan 25, 2016 at 8:52 PM Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> I think I see what happened w/r/t why no emails when out when the
>>> build went heavy red.  (Well they went out internally, but not
>>> externally).  When I made the change on Friday to improve the workflow 
>>> for
>>> the Green Dragon OS X builder and test output, I switched email over to 
>>> the
>>> builder step, which doesn't know anything about who made which changes. 
>>>  So
>>> it didn't know who to put on the blame list for the broken build.  
>>> Drats,
>>> I'll have to figure that out.
>>>
>>> I'd really prefer to have all those stages happening in one build
>>> step to keep it clear what's going on.
>>>
>>> On Mon, Jan 25, 2016 at 8:25 PM, Todd Fiala 
>>> wrote:
>>>
 Well our whole test suite just stopped running, so yes.

 On Mon, Jan 25, 2016 at 6:58 PM, Enrico Granata >>> > wrote:

>
> On Jan 25, 2016, at 6:48 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Not sure exactly what it is, but all the tests are failing due to
> some bad assumptions of unicode vs. str on Python 2 vs. 3 if I had to 
> guess.
>
>
> Author: zturner
> Date: Mon Jan 25 18:59:42 2016
> New Revision: 258759
>
> URL: http://llvm.org/viewvc/llvm-project?rev=258759&view=rev
> Log:
> Write the session log file