[lldb-dev] LLVM 9.0.1-rc1 Release has been tagged

[Tom Stellard via lldb-dev]

Hi,

I've tagged the LLVM 9.0.1-rc1 release.  Testers can begin testing and upload
binaries.  I've also updated the test-release.sh script to pull from GitHub
instead of SVN, if you run into any issues with the new script, let me know.

-Tom

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

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Vadim Chugunov via lldb-dev]

FWIW, Python provides stable ABI 
for a subset of their API.

I've actually managed to create a version of LLDB that is Python-optional
and Python version-agnostic (for versions 3.3 up).   Though given the
number of hoops I had to jump through to get there, I cannot recommend this
approach for mainline LLDB.


On Fri, Nov 22, 2019 at 9:39 AM Adrian McCarthy via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Yes, I think it's pretty reasonable to expect a specific version of
> Python, especially if the pre-built Python DLLs for Windows are still built
> with versions as old as VS 2013.  Once you get to VS 2015 or 2017, I think
> the compatibility improves.
>
> Perhaps the best thing for the pre-built LLDB is to include the right
> Python DLL in the distro, assuming the licensing allows that.
>
> The more sophisticated solutions are probably more work than is justified
> by the value.
>
> On Fri, Nov 22, 2019 at 8:29 AM Ted Woodward  wrote:
>
>>
>>
>> > > * Dynamically load any supported Python DLL if/when needed
>> > That might be tricky since the different versions are not binary
>> compatible in
>> > general. But it is possible, as Apple folks have shown, though it
>> amounts to
>> > building multiple copies of ScriptInterpreterPython and then choosing
>> the
>> > right one at runtime.
>>
>> It's not just the python dll; it's the modules directory as well. My
>> experiments with different versions of Python on Linux led me to just ship
>> the right python with our distribution.
>>
>> I saw things like building with 2.7.6 but using the 2.7.3 library/modules
>> (and vice versa) would crash, and building with 2.7.6 but running with
>> 2.6.x seemed to be OK, mostly. On Windows, I had crashes when loading
>> Python 2.7.8 from python.org (built with VS 2008) in lldb built with VS
>> 2013, so you have to think about other library dependencies too.
>>
>> My conclusion - you MUST use the same python that lldb was built with.
>> Period.
>>
> ___
> 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] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Adrian McCarthy via lldb-dev]

Yes, I think it's pretty reasonable to expect a specific version of Python,
especially if the pre-built Python DLLs for Windows are still built with
versions as old as VS 2013.  Once you get to VS 2015 or 2017, I think the
compatibility improves.

Perhaps the best thing for the pre-built LLDB is to include the right
Python DLL in the distro, assuming the licensing allows that.

The more sophisticated solutions are probably more work than is justified
by the value.

On Fri, Nov 22, 2019 at 8:29 AM Ted Woodward  wrote:

>
>
> > > * Dynamically load any supported Python DLL if/when needed
> > That might be tricky since the different versions are not binary
> compatible in
> > general. But it is possible, as Apple folks have shown, though it
> amounts to
> > building multiple copies of ScriptInterpreterPython and then choosing the
> > right one at runtime.
>
> It's not just the python dll; it's the modules directory as well. My
> experiments with different versions of Python on Linux led me to just ship
> the right python with our distribution.
>
> I saw things like building with 2.7.6 but using the 2.7.3 library/modules
> (and vice versa) would crash, and building with 2.7.6 but running with
> 2.6.x seemed to be OK, mostly. On Windows, I had crashes when loading
> Python 2.7.8 from python.org (built with VS 2008) in lldb built with VS
> 2013, so you have to think about other library dependencies too.
>
> My conclusion - you MUST use the same python that lldb was built with.
> Period.
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] The pre-built Windows LLDB binary has a dependency on an external python36.dll?

[Ted Woodward via lldb-dev]

> > * Dynamically load any supported Python DLL if/when needed
> That might be tricky since the different versions are not binary compatible in
> general. But it is possible, as Apple folks have shown, though it amounts to
> building multiple copies of ScriptInterpreterPython and then choosing the
> right one at runtime.

It's not just the python dll; it's the modules directory as well. My 
experiments with different versions of Python on Linux led me to just ship the 
right python with our distribution.

I saw things like building with 2.7.6 but using the 2.7.3 library/modules (and 
vice versa) would crash, and building with 2.7.6 but running with 2.6.x seemed 
to be OK, mostly. On Windows, I had crashes when loading Python 2.7.8 from 
python.org (built with VS 2008) in lldb built with VS 2013, so you have to 
think about other library dependencies too.

My conclusion - you MUST use the same python that lldb was built with. Period.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] EuroLLVM 2020 - Call for presentations

[Kristof Beyls via lldb-dev]

 All developers and users of LLVM and related sub-projects are invited to
present and discuss at the EuroLLVM'20 
developers’ meeting in Paris, France.

We are looking for the following proposals:

   1.

   Technical Talks (25 minutes + 5 minutes Q):
   -

  On any llvm project such as the core libraries, clang, mlir, flang,
  etc.
  -

  On uses of LLVM in academia or industry
  -

  On new projects using Clang or LLVM
  -

  On any other LLVM-related topic of interest to participants.
  2.

   Tutorials (60 minutes): in depth talks focussed on helping less
   experienced people get up to speed on an aspect of the LLVM project, with
   in depth examples and explanations.
   3.

   Student Research Competition Technical Talks & Poster (25 minutes + 5
   minutes Q) : The SRC offers students doing LLVM related research a
   non-academic platform to announce and advertise their work as well as to
   discuss it with other researchers, developers and users of LLVM. Students
   are strongly encouraged to present a poster as well, as this will enable
   wider discussions with the audience. An embargo period to delay the
   publication of the abstract/talk/poster is possible. There will be a prize
   for the best SRC entry.
   4.

   Lightning Talks (5 minutes, no questions, no discussions)
   5.

   Panels / round tables (30-60 minutes) / Birds of a Feather
    (BoF) (30
   minutes)

These are all discussion formats. The best format is probably mostly
dependent on the number of expected participants. For small group
highly-engaged discussion, round tables are expected to work best. Round
table topics can be proposed closer to the EuroLLVM meeting.
For discussions that are expected to attract larger groups, either a BoF or
Panel format is expected to work better. A BoF session is run in a
presentation-like setup, and therefore is expected to have somewhat less
free-flowing discussion than a round table.

We encourage proposals for a panel format where several experts (and a
moderator) on a topic get together and have an open discussion in front of
an audience with prepared questions and also questions from the audience.
The program committee will be looking for panel proposals and giving favor
to them over more traditional BoF proposals.

   1.

   Posters (1 hour)



Submission Requirements:

The submission deadline is January 11, 2020 at 11:59PM AoE (Anywhere on
Earth).

Please submit your proposal to the EuroLLVM'20 submission site


For each proposal, please submit a title, short abstract, submission type,
abstract for the website, and include who the speakers or panel
member/moderators are. If you wish, you can provide a more detailed
description of the talk through an extended PDF abstract. We highly
recommend you consult and follow the guide at the end of this CFP when
submitting your proposal.

FAQ

When will I be notified of acceptance?

Our goal is to notify all submissions by January 24th, 2020.

What are panels?

Panels may discuss any topic as long as it’s relevant to LLVM or related
sub-projects. Panels can take many forms, but a common format is to begin
with short introductions from each panel member, and follow with an
interactive dialogue among the panelists and audience members. Panels
should consist of 3 to 6 people including a moderator.

Should I register if I have submitted a proposal?

We have 1 complimentary reserved registration for each accepted technical
talk, BoF, or student research competition talk. Accepted tutorials have
been reserved 2 complimentary registrations. Panels have up to 3 reserved
registrations. There are no reserved registration spots for posters or
lightning talks. So please register any additional speakers or if you do
not have a reserved registration slot.

What if I registered and my talk got accepted?

We can refund your registration fee and instructions will be sent following
notification.  If you plan to attend even if your proposal is not accepted
and are worried about the event selling out, we suggest registering before
notification of acceptance.

What if I registered and my talk DID NOT get accepted?

We can refund your registration fee if you no longer wish to attend if you
contact the organizers by March 6th, 2020.

What will be recorded?

All technical talks, tutorials, SRC talks, panels, and lightning talks will
be recorded and published. By submitting your proposal, you are giving us
permission to record and publish if you present at the meeting. For SRC
talks, you have the option to delay publication of the slides and video for
you talk for up to 12 months.

Who is on the program committee?

Our program committee chair is Kristof Beyls. The program committee is
composed of active developers of the LLVM, Clang, and related
sub-communities. The website will be updated with the list of