Re: workshop and sessions for OctConf 2018

[Rik]

On 02/27/2018 09:00 AM, address@hidden wrote:

Subject:

Re: workshop and sessions for OctConf 2018

From:

Carnë Draug <address@hidden>

Date:

02/27/2018 07:24 AM

To:

octave maintainers mailing list <address@hidden>, Octave Help <address@hidden>

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

quoted-printable

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset="UTF-8"

Message:

2

On 4 February 2018 at 17:27, Carnë Draug <address@hidden> wrote:

Hi everyone

As you know, the Octave conference will happen soon, March 12-15 [1].
We are planning it to be mainly workshops, unconference, and code
sprint sessions.

We are looking for feedback on our pick of workshops and ideas for
more.  The ones we are currently considering are:

  * creating Octave packages
  * using Octave in C++ programs
  * hacking the Octave GUI
  * using mercurial
  * navigating Octave core source
  * hacking the interpreter
  * profiling

Please let us know which of those you would be interested and suggest
new ones.

If there's a workshop you would like to give, or a topic you would
like to discuss, please let us know too.  Preferably on the mailing
list so we can get more feedback from everyone.

Thank you

The OctConf committee

[1] https://wiki.octave.org/OctConf_2018

If you are attending OctConf and are interested in any of the
workshops and sessions, please let us know.  If you don't tell us,
then we can't prepare them.

Thank you
Carnë

I can volunteer to help lead a session on profiling, and possibly also on Mercurial (although Jordi or Mike are probably even better for this one).

I think these three topics could be the subject of unconference discussions:

1) Threading and how to create a stable interface between the interpreter and the GUI
2) The inadequacies of the print subsystem for publication-quality documents
3) OpenGL graphics system issues such as large ranges (need to scale data to fit within single-type values), performance, lack of WYSIWYG

--Rik