Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-19 Thread Raphael “Teemperor” Isemann via lldb-dev
The expected way as of now is to compile lldb-mi against an installed lldb 
(either a compiled version or whatever your OS/package manager provides). The 
CMake file will automatically find LLDB and build against it. See the travis CI 
script[1] in the repo on how that looks in practice.

The problem with the tests is that:

1. They (randomly) fail, which is why we already disabled most (all?) of them 
even before we removed lldb-mi. That’s mostly because of lldb-mi bugs and the 
way the tests were implemented from what I understand.
2. They depend on the LLDB python testing logic which isn’t as trivial to port 
over to the standalone lldb-mi repo. And the testing logic also not distributed 
with LLDB.

So after some discussion we decided that we don’t port the tests over as it’s 
just not worth it. The ideal outcome would be that someone writes a new set of 
tests that are is stable than the ones we had.

- Raphael

[1] https://github.com/lldb-tools/lldb-mi/blob/master/ci/travis.sh


> On Jul 19, 2019, at 6:34 PM, Ted Woodward  wrote:
> 
> As of yesterday, lldb-mi has been removed from lldb and moved to 
> https://github.com/lldb-tools/lldb-mi <https://github.com/lldb-tools/lldb-mi> 
> .
>  
> Some questions:
> Is the expected way to build lldb-mi to drop the lldb-tools/lldb-mi repo into 
> /tools/lldb-mi?
> The lldb-mi tests weren’t moved into the new repo on github. Do we plan on 
> moving them?
> If we don’t move them, do we just rely on the lldb-mi executable not existing 
> to keep from trying to run them?
> If we do move them, how do we run them?
>  
> Ted
>  
> From: lldb-dev  On Behalf Of Jonas 
> Devlieghere via lldb-dev
> Sent: Friday, July 5, 2019 11:44 AM
> To: Raphael “Teemperor” Isemann 
> Cc: LLDB 
> Subject: [EXT] Re: [lldb-dev] [RFC] Removing lldb-mi
>  
> Thank you for doing this, Raphael. I believe this shows that it's possible to 
> keep lldb-mi alive, without today's maintenance burden on the LLDB community, 
> a solution that seems to appease everyones concerns in this thread. I hope 
> this sparks interest for somebody to step up as a maintainer. 
>  
> I went ahead and created a diff to add the proposed deprecations to the LLVM 
> release notes: https://reviews.llvm.org/D64254 
> <https://reviews.llvm.org/D64254> 
> I'll put up another diff to remove the code, which we can land once LLVM 9 
> has branched. 
>  
> Thank you,
> Jonas
>  
> On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> I just went forward with this and made a quick test repo with an out-of-tree 
> lldb-mi that compiles against the system 
> LLDB:https://github.com/Teemperor/lldb-mi 
> <https://github.com/Teemperor/lldb-mi> This seems to work fine with the 
> exception of the python tests which require LLDB’s python code for testing 
> which isn’t installed alongside LLDB. I guess we will have to see if we copy 
> the related test code there or we just rewrite the test suite (which is 
> anyway broken). On the upside, we can now just use Travis for CI as we don’t 
> have to compile LLVM/Clang/LLDB, so that’s nice.
>  
> I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give 
> downstream time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi 
> for users. Given how simple lldb-mi is, this seems like a reasonable 
> timeframe.
>  
> - Raphael
>  
>  
> On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
>  
>  
>  
> On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> We're using it with Eclipse and Eclipse based product, so I'd like to keep as 
> well! :-)...
> 
> Zdenek
> 
>  
> I do understand that there's desire from people to keep this around (from an 
> user perspective), but I guess this fundamentally misses Jonas' original mail 
> point.
> lldb-mi has been unmaintained for a long time (at least the past two years 
> from what I can tell), and we tried to use it in emacs without success.
> It has never been a priority for many of the parties putting effort in lldb 
> and I'm under the impression the situation won't change in the foreseeable 
> future.
> Unless somebody steps up as maintainer I don't think there's a lot of future 
> for the tool. 
> Maybe a good compromise would be that of having lldb-mi living in a separate 
> repo somewhere on GitHub, as it only uses the SBAPI, which is public and set 
> in stone?
>  
> --
> Davide
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/lis

Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-19 Thread Ted Woodward via lldb-dev
As of yesterday, lldb-mi has been removed from lldb and moved to 
https://github.com/lldb-tools/lldb-mi .

Some questions:

  *   Is the expected way to build lldb-mi to drop the lldb-tools/lldb-mi repo 
into /tools/lldb-mi?
  *   The lldb-mi tests weren’t moved into the new repo on github. Do we plan 
on moving them?
  *   If we don’t move them, do we just rely on the lldb-mi executable not 
existing to keep from trying to run them?
  *   If we do move them, how do we run them?

Ted

From: lldb-dev  On Behalf Of Jonas Devlieghere 
via lldb-dev
Sent: Friday, July 5, 2019 11:44 AM
To: Raphael “Teemperor” Isemann 
Cc: LLDB 
Subject: [EXT] Re: [lldb-dev] [RFC] Removing lldb-mi

Thank you for doing this, Raphael. I believe this shows that it's possible to 
keep lldb-mi alive, without today's maintenance burden on the LLDB community, a 
solution that seems to appease everyones concerns in this thread. I hope this 
sparks interest for somebody to step up as a maintainer.

I went ahead and created a diff to add the proposed deprecations to the LLVM 
release notes: https://reviews.llvm.org/D64254
I'll put up another diff to remove the code, which we can land once LLVM 9 has 
branched.

Thank you,
Jonas

On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
I just went forward with this and made a quick test repo with an out-of-tree 
lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi This seems to work fine with the exception 
of the python tests which require LLDB’s python code for testing which isn’t 
installed alongside LLDB. I guess we will have to see if we copy the related 
test code there or we just rewrite the test suite (which is anyway broken). On 
the upside, we can now just use Travis for CI as we don’t have to compile 
LLVM/Clang/LLDB, so that’s nice.

I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream 
time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi for users. 
Given how simple lldb-mi is, this seems like a reasonable timeframe.

- Raphael


On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:



On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:

We're using it with Eclipse and Eclipse based product, so I'd like to keep as 
well! :-)...

Zdenek

I do understand that there's desire from people to keep this around (from an 
user perspective), but I guess this fundamentally misses Jonas' original mail 
point.
lldb-mi has been unmaintained for a long time (at least the past two years from 
what I can tell), and we tried to use it in emacs without success.
It has never been a priority for many of the parties putting effort in lldb and 
I'm under the impression the situation won't change in the foreseeable future.
Unless somebody steps up as maintainer I don't think there's a lot of future 
for the tool.
Maybe a good compromise would be that of having lldb-mi living in a separate 
repo somewhere on GitHub, as it only uses the SBAPI, which is public and set in 
stone?

--
Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org<mailto:lldb-dev@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-05 Thread Jonas Devlieghere via lldb-dev
Thank you for doing this, Raphael. I believe this shows that it's possible
to keep lldb-mi alive, without today's maintenance burden on the LLDB
community, a solution that seems to appease everyones concerns in this
thread. I hope this sparks interest for somebody to step up as a
maintainer.

I went ahead and created a diff to add the proposed deprecations to the
LLVM release notes: https://reviews.llvm.org/D64254
I'll put up another diff to remove the code, which we can land once LLVM 9
has branched.

Thank you,
Jonas

On Thu, Jul 4, 2019 at 12:24 PM Raphael “Teemperor” Isemann via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> I just went forward with this and made a quick test repo with an
> out-of-tree lldb-mi that compiles against the system LLDB:
> https://github.com/Teemperor/lldb-mi This seems to work fine with the
> exception of the python tests which require LLDB’s python code for testing
> which isn’t installed alongside LLDB. I guess we will have to see if we
> copy the related test code there or we just rewrite the test suite (which
> is anyway broken). On the upside, we can now just use Travis for CI as we
> don’t have to compile LLVM/Clang/LLDB, so that’s nice.
>
> I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give
> downstream time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi
> for users. Given how simple lldb-mi is, this seems like a reasonable
> timeframe.
>
> - Raphael
>
>
> On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>
>
> On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> We're using it with Eclipse and Eclipse based product, so I'd like to
>> keep as well! :-)...
>>
>> Zdenek
>>
>
> I do understand that there's desire from people to keep this around (from
> an user perspective), but I guess this fundamentally misses Jonas' original
> mail point.
> lldb-mi has been unmaintained for a long time (at least the past two years
> from what I can tell), and we tried to use it in emacs without success.
> It has never been a priority for many of the parties putting effort in
> lldb and I'm under the impression the situation won't change in the
> foreseeable future.
> Unless somebody steps up as maintainer I don't think there's a lot of
> future for the tool.
> Maybe a good compromise would be that of having lldb-mi living in a
> separate repo somewhere on GitHub, as it only uses the SBAPI, which is
> public and set in stone?
>
> --
> Davide
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-05 Thread Nat! via lldb-dev
I was asked by the author of lldb-mi, to forward this to the list, since 
he is not subscribed:


Illya Rudkin schrieb am 05.07.19 um 10:37:

Hi Nat

Thank you for bring this to my attention. Yes I am the original author 
but for a long time now I have not been involved in its further 
development or maintenance. I have been popping in to the Git repository 
occasionally to see the activity and it seems to me there are people 
actively maintaining to this day, either fixing commands or adding new 
ones. This is not very often mind perhaps indicating its maturity. Of 
course this does not indicate the number of people actively using it 
today or how they access the tool to use it, Eclipse users being main 
ones in the past. I am not sure how to get this information.


(To the others in this discussion) Anyway to the point of the this 
discussion I do not mind if it stays where it is currently or is moved. 
The thing I would say is just remember even if you may not be using it 
or interested in it there may be others who are. It may be a bit of 
noise for you but it is a dependency for them. Perhaps reach out before 
making a decision.


All the best

Illya

*From: *Nat! 
*Date: *Thursday, 4 July 2019 at 22:21
*To: *Illya Rudkin 
*Subject: *Fwd: Re: [lldb-dev] [RFC] Removing lldb-mi

Hi

I am forwarding you this, because I believe you are the original author 
of lldb-mi. I think I prefer, if it would stay in the project, but I am 
not really sure.


Ciao
    Nat!


 Forwarded Message 

*Subject: *



Re: [lldb-dev] [RFC] Removing lldb-mi

*Date: *



Thu, 4 Jul 2019 12:24:48 -0700

*From: *



Raphael “Teemperor” Isemann via lldb-dev  
<mailto:lldb-dev@lists.llvm.org>


*Reply-To: *



Raphael “Teemperor” Isemann  
<mailto:teempe...@gmail.com>


*To: *



Davide Italiano  <mailto:dccitali...@gmail.com>

*CC: *



LLDB  <mailto:lldb-dev@lists.llvm.org>



I just went forward with this and made a quick test repo with an 
out-of-tree lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi This seems to work fine with the 
exception of the python tests which require LLDB’s python code for 
testing which isn’t installed alongside LLDB. I guess we will have to 
see if we copy the related test code there or we just rewrite the test 
suite (which is anyway broken). On the upside, we can now just use 
Travis for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.


I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give 
downstream time until 10.0.0 (or X.0.0 :) ) to package out-of-tree 
lldb-mi for users. Given how simple lldb-mi is, this seems like a 
reasonable timeframe.


- Raphael

On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev
mailto:lldb-dev@lists.llvm.org>> wrote:

We're using it with Eclipse and Eclipse based product, so I'd
like to keep as well! :-)...

Zdenek

I do understand that there's desire from people to keep this around
(from an user perspective), but I guess this fundamentally misses
Jonas' original mail point.

lldb-mi has been unmaintained for a long time (at least the past two
years from what I can tell), and we tried to use it in emacs without
success.

It has never been a priority for many of the parties putting effort
in lldb and I'm under the impression the situation won't change in
the foreseeable future.

Unless somebody steps up as maintainer I don't think there's a lot
of future for the tool.

Maybe a good compromise would be that of having lldb-mi living in a
separate repo somewhere on GitHub, as it only uses the SBAPI, which
is public and set in stone?

--

Davide

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



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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-04 Thread Raphael “Teemperor” Isemann via lldb-dev
I just went forward with this and made a quick test repo with an out-of-tree 
lldb-mi that compiles against the system LLDB: 
https://github.com/Teemperor/lldb-mi  
This seems to work fine with the exception of the python tests which require 
LLDB’s python code for testing which isn’t installed alongside LLDB. I guess we 
will have to see if we copy the related test code there or we just rewrite the 
test suite (which is anyway broken). On the upside, we can now just use Travis 
for CI as we don’t have to compile LLVM/Clang/LLDB, so that’s nice.

I’m in favor of deprecating lldb-mi with 9.0.0 and then we can give downstream 
time until 10.0.0 (or X.0.0 :) ) to package out-of-tree lldb-mi for users. 
Given how simple lldb-mi is, this seems like a reasonable timeframe.

- Raphael


> On Jul 4, 2019, at 9:51 AM, Davide Italiano via lldb-dev 
>  wrote:
> 
> 
> 
> On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> We're using it with Eclipse and Eclipse based product, so I'd like to keep as 
> well! :-)...
> 
> Zdenek
> 
> 
> I do understand that there's desire from people to keep this around (from an 
> user perspective), but I guess this fundamentally misses Jonas' original mail 
> point.
> lldb-mi has been unmaintained for a long time (at least the past two years 
> from what I can tell), and we tried to use it in emacs without success.
> It has never been a priority for many of the parties putting effort in lldb 
> and I'm under the impression the situation won't change in the foreseeable 
> future.
> Unless somebody steps up as maintainer I don't think there's a lot of future 
> for the tool. 
> Maybe a good compromise would be that of having lldb-mi living in a separate 
> repo somewhere on GitHub, as it only uses the SBAPI, which is public and set 
> in stone?
> 
> --
> Davide
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-04 Thread Davide Italiano via lldb-dev
On Thu, Jul 4, 2019 at 12:58 AM Zdenek Prikryl via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We're using it with Eclipse and Eclipse based product, so I'd like to keep
> as well! :-)...
>
> Zdenek
>

I do understand that there's desire from people to keep this around (from
an user perspective), but I guess this fundamentally misses Jonas' original
mail point.
lldb-mi has been unmaintained for a long time (at least the past two years
from what I can tell), and we tried to use it in emacs without success.
It has never been a priority for many of the parties putting effort in lldb
and I'm under the impression the situation won't change in the foreseeable
future.
Unless somebody steps up as maintainer I don't think there's a lot of
future for the tool.
Maybe a good compromise would be that of having lldb-mi living in a
separate repo somewhere on GitHub, as it only uses the SBAPI, which is
public and set in stone?

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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-04 Thread Zdenek Prikryl via lldb-dev
We're using it with Eclipse and Eclipse based product, so I'd like to 
keep as well! :-)...


Zdenek

On 7/2/19 12:21 AM, Ted Woodward via lldb-dev wrote:


We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d 
really like to keep it! 


Ted

*From:* lldb-dev  *On Behalf Of 
*Jonas Devlieghere via lldb-dev

*Sent:* Monday, July 1, 2019 5:09 PM
*To:* LLDB 
*Subject:* [EXT] [lldb-dev] [RFC] Removing lldb-mi

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,

Jonas


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


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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-02 Thread Nat! via lldb-dev


I use a plugin in Visual Studio Code 
https://github.com/WebFreak001/code-debug, that uses lldb-mi. It works 
fairly well for me.


Ciao
   Nat!


On 02.07.19 00:09, Jonas Devlieghere via lldb-dev wrote:

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.


Thanks,
Jonas

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


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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-02 Thread Pavel Labath via lldb-dev

On 02/07/2019 00:09, Jonas Devlieghere via lldb-dev wrote:

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code 
style, and worst of all the tests are unreliable if not already 
disabled. As far as I can tell it's missing core functionality to be 
usable from something like say emacs.




I am in favour of this proposal, for all of the reasons stated above. 
Since lldb-mi uses lldb stable API, any interested parties can easily 
create a separate project for it on github (or wherever). Maybe this 
would even serve as a spark to reignite lldb-mi development (which has 
been sitting in idle for quite some time now).


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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Davide Italiano via lldb-dev
On Mon, Jul 1, 2019 at 3:21 PM Ted Woodward via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really
> like to keep it! 
>
>
>

Is there any reason why this can't be a downstream project?

Thanks,

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


Re: [lldb-dev] [RFC] Removing lldb-mi

2019-07-01 Thread Ted Woodward via lldb-dev
We’re using lldb-mi to debug with Eclipse in the Hexagon SDK. I’d really like 
to keep it! 

Ted

From: lldb-dev  On Behalf Of Jonas Devlieghere 
via lldb-dev
Sent: Monday, July 1, 2019 5:09 PM
To: LLDB 
Subject: [EXT] [lldb-dev] [RFC] Removing lldb-mi

Hi everyone,

After long consideration, I want to propose removing lldb-mi from the 
repository. It is basically unmaintained, doesn't match the LLDB code style, 
and worst of all the tests are unreliable if not already disabled. As far as I 
can tell it's missing core functionality to be usable from something like say 
emacs.

Thanks,
Jonas
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev