Re: [lldb-dev] Failure connecting to lldb-server running in local virtual machine.
Greg Clayton wrote on 16/02/2017 17:17:41: > Sounds like a race condition we need to solve. It seemed likely but I thought I'd confirm that before I investigated too deeply just in case there was anything obvious I'd missed. > This sounds like a very common VM issue. If you can elaborate on > what happens with ports on your VM we might be able to deduce some > of the problems. Filing a bug will be nice, but since you are > running into this issue, seems like you will need to debug it and > make it work. We are happy to assist. Initially I was mapping ports with an offset but as part of investigating I simplified things and now my setup just routes ports 1234 and 2345 on my machine to 1234 and 2345 on the VM. I might retry with an offset just to double check if that changes anything but I don't think it did. It does seem to be fairly common, it happens with my VM and to another colleague using docker. It works with a remote system for me but fails with with a remote system for him. I've had some other bits to look at today but I'll try to take a deeper look next week. I'll try to update this thread with what I find as any useful suggestions other people have are likely to save a bit of time. Thanks, Howard Hellyer IBM Runtime Technologies, IBM Systems Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On 02/17/2017 12:16 AM, Mehdi Amini via lldb-dev wrote: Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key part of the process is about how do we select the projects. The way we’ve done it last year, is that the volunteer mentors shared an email thread and ultimately each one individually ranked the projects. We kept the average grading for each project to ranked them overall. In order to make the process more transparent to student applicants, we want to formalize and announce the criteria for ranking and selection project. The purpose of this email is to gather community feedback about the criterion that mentors should apply when ranking projects, for example: - Should we favor a student which has past contributions to LLVM compared to a newcomer? Is it more important or as equally important as the quality of the proposal? I think that the quality of the proposal is the most important thing, however, we should be realistic about the amount of time it will take to bring a newcomer up to speed on our coding conventions, quality standards, review process, etc. and factor that into the decision-making process. - How should we rank (if any) “research or unbounded projects” vs “project with an immediate application”? Should we strive to keep a balance? Given the short time period involved, I favor projects of more immediate utility. This does not mean that there can't be interesting open questions, but in our judgment, these should be answerable in a matter of weeks (i.e. choosing between clear alternatives, understood tuning parameters, and the like). - What about “projects that touch LLVM/Clang/…” vs “projects that are building something on top of LLVM”? (For example this project was first proposed to be selected by LLVM before being rejected and finally picked by the Julia project directly: https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )? I think we need to base this on the overall benefit to the community. If working on a project built on top of LLVM will bring additional users, end up making LLVM more robust, etc. then there might be significant anticipated value. That having been said, in practice, justifying this value will probably be more difficult than for a project contributing to LLVM, Clang, etc. - Should we ask that the work is done upstream all along? In the past there have been project developed on GitHub outside the community that have never been merged. The LLVM developer policy has a full section insisting on incremental development ( http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). I think we should insist on incremental upstream development. Thanks again, Hal Hopefully we should be able to provide a set of guidelines to student that would help them fill the best application, and avoid unfortunate surprise at the end of the process. We should have this discussion before receiving the projects proposals, which opens on 2/28. Best, -- Mehdi ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] LLVM Social Berlin #6, February 23rd
Hello again. We do not know exact topics for this meetup yet. If you want to give a talk (no matter whether it is one hour long or just 10 minutes), please get in touch. Otherwise, I will be preparing an introductory talk about JIT. I want to cover runtime compilation in general and also touch a bit of ORC JIT API. https://www.meetup.com/LLVM-Social-Berlin/events/237752524/ See you soon, cheers, -- AlexDenisov Software Engineer, https://lowlevelbits.org ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On Thu, Feb 16, 2017 at 10:16 PM, Mehdi Amini via llvm-dev wrote: > Hello all, > > GSOC is around the corner, and the LLVM projects plans to participate again > this year. For those who don’t know about GSOC, students are proposing a > project that they will work on for 3 months. Amongst other, one goal for > LLVM is to mentor students to become good developers and also contributors > to the LLVM project (or user/advocate of LLVM for building other cool > projects). > > A key part of the process is about how do we select the projects. The way > we’ve done it last year, is that the volunteer mentors shared an email > thread and ultimately each one individually ranked the projects. We kept the > average grading for each project to ranked them overall. > > In order to make the process more transparent to student applicants, we want > to formalize and announce the criteria for ranking and selection project. > > The purpose of this email is to gather community feedback about the > criterion that mentors should apply when ranking projects, for example: > > - Should we favor a student which has past contributions to LLVM compared to > a newcomer? Is it more important or as equally important as the quality of > the proposal? I really think that past contributions are *very* important and *a big plus*. When I was involved in FreeBSD we ended up with people submitting high-quality proposals, got accepted and then we realized at day 1 of coding they didn't even set up a VM or knew how to build things. In other words, I'm under the impression that students need to be well aware of the development workflow and being able to show up some involvement in the community. > - How should we rank (if any) “research or unbounded projects” vs “project > with an immediate application”? Should we strive to keep a balance? Again, my opinion, but we should give high(er) priority to projects which can produce something reasonable in 3 months. If it's a research project, it's fine, but I think there should be a bound (e.g. tune the thresholds for unrolling). > - What about “projects that touch LLVM/Clang/…” vs “projects that are > building something on top of LLVM”? (For example this project was first > proposed to be selected by LLVM before being rejected and finally picked by > the Julia project directly: > https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ > )? > - Should we ask that the work is done upstream all along? In the past there > have been project developed on GitHub outside the community that have never > been merged. The LLVM developer policy has a full section insisting on > incremental development ( > http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). > Yes, I think incremental patches are the way to go. If there are bugfixes, etc.. they should be merged immediately (after code review). If it's a larger chunk of work it should be in a state where others can take over if the student stops being interested after the summer (or we want to remove the thing altogether, e.g. a pass). > Hopefully we should be able to provide a set of guidelines to student that > would help them fill the best application, and avoid unfortunate surprise at > the end of the process. > > We should have this discussion before receiving the projects proposals, > which opens on 2/28. > -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] FYI, Phabricator is really slow due to HN about LLD
https://news.ycombinator.com/item?id=13670458 I'm restarting Phab with lots more cores / memory. Hopefully back up and fast soon. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] LLVM GSOC Projects Criteria Consultation (before 2/28)
On 2/17/17 1:16 AM, Mehdi Amini via lldb-dev wrote: Hello all, GSOC is around the corner, and the LLVM projects plans to participate again this year. For those who don’t know about GSOC, students are proposing a project that they will work on for 3 months. Amongst other, one goal for LLVM is to mentor students to become good developers and also contributors to the LLVM project (or user/advocate of LLVM for building other cool projects). A key part of the process is about how do we select the projects. The way we’ve done it last year, is that the volunteer mentors shared an email thread and ultimately each one individually ranked the projects. We kept the average grading for each project to ranked them overall. In order to make the process more transparent to student applicants, we want to formalize and announce the criteria for ranking and selection project. The purpose of this email is to gather community feedback about the criterion that mentors should apply when ranking projects, for example: - Should we favor a student which has past contributions to LLVM compared to a newcomer? Is it more important or as equally important as the quality of the proposal? Historically, we have opted for students with previous LLVM experience because they are more likely to make progress and complete their project. For most projects, this makes sense. However, it does have the downside of attracting students that are already "on board" with LLVM; it doesn't introduce new developers to the LLVM community. We therefore might want to devise projects that would fit beginner developers. For example, a proposal that aims to fix a set of bugs might work. - How should we rank (if any) “research or unbounded projects” vs “project with an immediate application”? Should we strive to keep a balance? We should strive to keep a balance. The important factor is getting students to either improve the existing LLVM software or to build cool tools using LLVM. We want to grow the LLVM community, and both the software development and research communities are important. I also believe that research projects and open-ended projects can provide long-term gains even if they don't provide immediate short-term benefits. Remember that LLVM itself was once a research project. If we keep a balance, then we will have a nice mix of short-term, low risk projects and projects that contribute to longer-term, higher risk goals. - What about “projects that touch LLVM/Clang/…” vs “projects that are building something on top of LLVM”? (For example this project was first proposed to be selected by LLVM before being rejected and finally picked by the Julia project directly: https://summerofcode.withgoogle.com/archive/2016/projects/6197080536121344/ )? We should encourage proposals that build something *with* LLVM/Clang/etc. as well as projects that improve the core compiler infrastructure. Part of LLVM's appeal is that one can build *a lot* of tools with it. We want to encourage students to use LLVM to build interesting things. In some cases, we will have overlap with other communities (the Julia and FreeBSD communities come to mind). I think that's fine. - Should we ask that the work is done upstream all along? In the past there have been project developed on GitHub outside the community that have never been merged. The LLVM developer policy has a full section insisting on incremental development ( http://llvm.org/docs/DeveloperPolicy.html#incremental-development ). It depends on the project. Projects that enhance the core infrastructure should probably follow the developer policy and contribute upstream. Projects that are "trying out" a new idea or are research-oriented should probably not worry about working upstream; why upstream if you don't even know if what you're trying to do is going to work? Hopefully we should be able to provide a set of guidelines to student that would help them fill the best application, and avoid unfortunate surprise at the end of the process. I think what actually makes a strong proposal is whether the student presents a good idea, whether the proposal convinces the reader that the student will be able to perform the work, and whether there is a mentor interested in the project. If you have these three things, then you have a project that is more likely to achieve its goals and grow the LLVM community. Regards, John Criswell -- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] FYI, Phabricator is really slow due to HN about LLD
On 17 February 2017 at 19:23, Chandler Carruth via lldb-dev wrote: > https://news.ycombinator.com/item?id=13670458 > > I'm restarting Phab with lots more cores / memory. Hopefully back up and > fast soon. Hi Chandler, Email notifications and the "recent changes" feed (https://reviews.llvm.org/feed/) seem to have stopped around the time you sent this email. Best, Alex ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD
Have they come back? the instance appeared to reboot cleanly and the pages are serving... I'll dig into this in a couple of hours when I can. On Fri, Feb 17, 2017 at 1:37 PM Alex Bradbury via llvm-dev < llvm-...@lists.llvm.org> wrote: > On 17 February 2017 at 19:23, Chandler Carruth via lldb-dev > wrote: > > https://news.ycombinator.com/item?id=13670458 > > > > I'm restarting Phab with lots more cores / memory. Hopefully back up and > > fast soon. > > Hi Chandler, > > Email notifications and the "recent changes" feed > (https://reviews.llvm.org/feed/) seem to have stopped around the time > you sent this email. > > Best, > > Alex > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD
Fixed! So sorry for the email outage folks, was my bad. On Fri, Feb 17, 2017 at 1:58 PM Chandler Carruth wrote: > Have they come back? the instance appeared to reboot cleanly and the pages > are serving... I'll dig into this in a couple of hours when I can. > > On Fri, Feb 17, 2017 at 1:37 PM Alex Bradbury via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > On 17 February 2017 at 19:23, Chandler Carruth via lldb-dev > wrote: > > https://news.ycombinator.com/item?id=13670458 > > > > I'm restarting Phab with lots more cores / memory. Hopefully back up and > > fast soon. > > Hi Chandler, > > Email notifications and the "recent changes" feed > (https://reviews.llvm.org/feed/) seem to have stopped around the time > you sent this email. > > Best, > > Alex > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD
Nah, its fine. Would have been completely easy to throw the necessary hardware at handling the load if I hadn't messed up the config. =] On Fri, Feb 17, 2017 at 2:39 PM Andrew Kelley via llvm-dev < llvm-...@lists.llvm.org> wrote: > Ah, sorry about that. Maybe I should have linked to the mailing list > archive instead of the phabricator code review page. > > On Fri, Feb 17, 2017 at 2:23 PM, Chandler Carruth via llvm-dev < > llvm-...@lists.llvm.org> wrote: > > https://news.ycombinator.com/item?id=13670458 > > I'm restarting Phab with lots more cores / memory. Hopefully back up and > fast soon. > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > ___ > LLVM Developers mailing list > llvm-...@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
