[lldb-dev] FOSDEM 2021 LLVM dev room?

2020-10-27 Thread Kristof Beyls via lldb-dev
Hi,

LLVM has been present at FOSDEM with an LLVM dev room for many years.
The FOSDEM organizers have just put up a call for participation for the
next FOSDEM, on February 6th and 7th 2021. It's no surprise it's an
online-only event. See https://fosdem.org/2021/news/2020-10-26-devroom-cfp/

In the past few years, I've been the main organizer of the LLVM dev room at
FOSDEM, together with a number of other volunteers.
This year, it's looking like I will not have the time available to be the
main organizer on the day itself. Furthermore, with the conference moving
to an online event, it looks like at least 10 volunteers are needed to be
able to run the dev room, covering various roles as described below.

I've decided to not be the main organizer for the LLVM dev room at FOSDEM
myself for the 2021 edition.
That being said, I am more than happy to support a new main organizer if
someone steps up. If you're interested, please let me know.
If you're interested in any of the other volunteer support roles (described
below), please let me know too so that we can have a guess of whether
enough volunteers are available.
The deadline for proposing the dev room is really nearby: this coming
Friday. So if you're interested, please do reach out by Thursday at the
latest.

Please note that it should be expected that the dev room will run roughly
during day time Brussels time zone (CET).

Thanks,

Kristof


PS. Please see the below notes from the FOSDEM organizers on the volunteer
roles they expect are needed.






































































































*Our basic strategy is to replicate the various elements of the
physicalevent as closely as we can in an online environment.  (Well,
exceptfor the overcrowding!)The main thing to appreciate is that the
volunteer input requiredto produce a professional online event will be
significantly higher thanyou may be used to.  We expect a typical devroom
to need at least 10volunteers during the event so that people can take
breaks.Devroom managers will be responsible for finding and
schedulingvolunteers to perform the various roles needed for an online
conference.Until the end of this year, the input required will be similar
to normal- selecting and scheduling talks.  One thing to note here is that
use ofour systems (e.g. pentabarf) will be compulsory and this includes
callsfor papers.  Systems will change and adapt and we need to be able
tocontact all speakers directly whenever necessary.The changes will be
noticeable in January, when devroom managers willneed to assign specific
volunteers to work 1:1 with individual speakersto prepare recordings of
their talks.  All presentations will need to bepre-recorded and put into
our system at least a couple of weeks beforethe event.  We expect live
presentations to be a rarity, but even if aspeaker intends to deliver their
session live, there must be a recordingavailable to use as a fallback if
something goes wrong and the livepresentation can't be delivered for any
reason.As regards the features for devrooms, we are thinking along
thefollowing lines:- A main stream for each devroom.   Talks here will be
pre-recorded, but questions will be taken live.- A second stream for each
devroom representing hallway discussions  that may follow each talk.- A
facility for people watching to submit questions.- A facility for people
watching to chat between themselves.As such, we're thinking of the
following volunteer roles:Prior to the event:- A devroom manager and a
deputy responsible for everything below.  This includes finding, assigning
and scheduling all the volunteer  roles required.- A programme committee to
select and schedule the talks.  This is the same as a normal year.
Timeline: November/December- Reviewers to help the speakers produce their
pre-recorded content.  This is a new role.  Each speaker will need to be
assigned to a reviewer who will be  responsible for ensuring the content is
put into our system and ready  to be broadcast.   Timeline: January.During
the event itself:- Stream controllers, one per stream, responsible for the
content of  the outgoing stream at all times.  They will switch between
inputs (live video rooms, recordings)  according to the schedule and
intervene (sometimes on video) and make  decisions if there are problems.-
Chat moderators.  They will be responsible for monitoring the content of
the chat and  dealing with any problems that arise (including banning
people if  necessary).  There might also be people assigned to answering
questions about the devroom content.- Session moderators.  Every speaker
will be assigned a moderator who will be responsible  for accompanying that
speaker's session, including all the preparation  and hallway chat
afterwards, including checking the speaker's video  connection is working,
monitoring the chat and submitted questions  and asking them on video to
the speaker.  The moderator will have the speaker's private contact de

[lldb-dev] Deleting lldb/utils/test/

2020-10-27 Thread Vedant Kumar via lldb-dev
Hi,

I'm considering deleting the lldb/utils/test/ directory as a cleanup. Does 
anyone has a reason to keep these scripts around?

Here are the files in the directory:

% ls lldb/utils/test
README-disasm   README-run-until-faultedlldb-disasm.py  
main.c  run-dis.py
README-lldb-disasm  disasm.py   
llvm-mc-shell.pyras.py  
run-until-faulted.py

AFAICT:

- disasm.py would've been helpful before lldb gained a 'disassemble' command, 
but it doesn't seem useful anymore
- ditto for lldb-disasm.py; this one also seems quite Darwin-specific (I'm 
pretty sure it doesn't work anymore)
- llvm-mc-shell.py might be useful if you want to type bytes by hand and see 
the disassembly, but even then, seems better to just do `echo "" | 
llvm-mc`
- ras.py isn't running the test suite properly, also (imo) seems like an ersatz 
Jenkins replacement
- main.c is just an example program
- run-dis.py looks like a driver for stress-testing lldb's disassembly command, 
but it looks very iOS/Darwin specific and has likely outlived its usefulness
- run-until-faulted.py runs a program up to 100 times to see if any of the runs 
fail; I suspect most users would reach for a shell one-liner before looking for 
something like this script

Thoughts?

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


Re: [lldb-dev] Deleting lldb/utils/test/

2020-10-27 Thread Jonas Devlieghere via lldb-dev
Last time I looked at these nothing seemed relevant (anymore) to me either.
I'm in favor of getting rid of the directory.

On Tue, Oct 27, 2020 at 10:26 AM Vedant Kumar via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I'm considering deleting the lldb/utils/test/ directory as a cleanup. Does
> anyone has a reason to keep these scripts around?
>
> Here are the files in the directory:
>
> % ls lldb/utils/test
> README-disasm   README-run-until-faulted
> lldb-disasm.py  main.c  run-dis.py
> README-lldb-disasm  disasm.py
>  llvm-mc-shell.pyras.py
> run-until-faulted.py
>
> AFAICT:
>
> - disasm.py would've been helpful before lldb gained a 'disassemble'
> command, but it doesn't seem useful anymore
> - ditto for lldb-disasm.py; this one also seems quite Darwin-specific (I'm
> pretty sure it doesn't work anymore)
> - llvm-mc-shell.py might be useful if you want to type bytes by hand and
> see the disassembly, but even then, seems better to just do `echo ""
> | llvm-mc`
> - ras.py isn't running the test suite properly, also (imo) seems like an
> ersatz Jenkins replacement
> - main.c is just an example program
> - run-dis.py looks like a driver for stress-testing lldb's disassembly
> command, but it looks very iOS/Darwin specific and has likely outlived its
> usefulness
> - run-until-faulted.py runs a program up to 100 times to see if any of the
> runs fail; I suspect most users would reach for a shell one-liner before
> looking for something like this script
>
> Thoughts?
>
> thanks,
> vedant
> ___
> 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