Hi--
I got the unused-method-removal stuff from Spoon running in
SqueakJS, and I wrote a blog post about it:
https://thiscontext.com/2019/03/25/the-big-shake-out
I'd love to hear of any use cases people are interested in pursuing.
thanks,
-C
--
Craig Latta
Black Page Digital
Amsterdam :: San Francisco
craig(a)blackpagedigital.com
+31 6 2757 7177
+ 1 415 287 3547
Hello
What is a good modern way in Squeak to load a picture from the web?
I am looking for an equivalent of
| pngPicURL aStream |
pngPicURL := 'https://upload.wikimedia.org/wikipedia/commons/thumb/1/11/Squeak-x11.png/61…'.
aStream := HTTPSocket httpGet: pngPicURL.
(ImageReadWriter formFromStream: aStream) asMorph openInHand
And answer or just comments are welcome.
Thank you.
Kind regards
Hannes
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, March 30, 2019 12:33 AM, Robert <robert.withers(a)protonmail.com> wrote:
> Is there any sort of network browser for Squeak?
>
> Best,
> Robert
Just in case anyone wonders: a workaround is to make the uses list empty
#(), this will remove the traits from a class.
And if I would not use traits, I wouldn't have known that. I use them to
give objects a common protocol based on a few would-be template methods
that are "required" by the trait (as described in the paper). I don't like
to impose abstract superclasses if there is no common, mandatory state,
such as instance variables.
Often my trait methods are general defaults that implement the protocol
simply, but not efficiently. This allows the user classes to adopt the
protocol quickly, based on a few "primitives" (not real primitives, but the
template methods). More efficient implementations can replace the trait
methods later. But it gets you started.
For the same reason I provide traits if I want others to implement that
protocol in their objects. At the same time, the traits "document" that
protocol, like interfaces in statically typed languages. Abstract
superclasses fulfill the same requirements, but seem to dictate
inheritance. While you can also just copy their methods, the copies will be
out of date when these methods are changed in the abstract superclass.
Am Do., 28. März 2019 um 16:22 Uhr schrieb <patrick.rein(a)hpi.uni-potsdam.de
>:
> The test documents the (currently not working) workflow for removing a
> trait from a class by simply removing the "uses:" line from the class
> definition. To make this work, we would have to make the
> Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
> method aware of traits. The method would have to reset the trait
> composition as
> Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category:
> currently does. Potentially, the change could also be embedded deeper in
> the class creation code to avoid that duplication and make the other class
> creation methods more robust.
>
> I am hesitant, as I am aware that traits have been prevented from being
> integrated more deeply so far. At the same time, the described missing
> workflow has already led users to struggle with using traits in the first
> place. So as they are part of the system I would rather improve their
> usability. Any other oppinions?
>
> Bests
> Patrick
>
> >Patrick Rein uploaded a new version of TraitsTests to project The Inbox:
> >http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
> >
> >==================== Summary ====================
> >
> >Name: TraitsTests-pre.19
> >Author: pre
> >Time: 28 March 2019, 3:30:48.769796 pm
> >UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017
> >Ancestors: TraitsTests-ul.18
> >
> >Adds a test case for removing traits from a class by simply executing a
> class creation method without a trait composition. This does currently not
> yet work.
> >
> >=============== Diff against TraitsTests-ul.18 ===============
> >
> >Item was added:
> >+ ----- Method: TraitTest>>expectedFailures (in category 'failures') -----
> >+ expectedFailures
> >+
> >+ ^ #(testRemoveTraitBySimpleClassDefinition)!
> >
> >Item was added:
> >+ ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in
> category 'testing') -----
> >+ testRemoveTraitBySimpleClassDefinition
> >+
> >+ | classAv1 classAv2 |
> >+ classAv1 := self createClassNamed: #TraitTestMethodClassA
> superclass: Object uses: T1.
> >+ classAv2 := self createClassNamed: #TraitTestMethodClassA
> superclass: Object.
> >+
> >+ self assert: classAv1 == classAv2.
> >+ self assert: classAv2 traits isEmpty.!
> >
> >Item was added:
> >+ ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category
> 'utility') -----
> >+ createClassNamed: aSymbol superclass: aClass
> >+ | class |
> >+ class := aClass
> >+ subclass: aSymbol
> >+ instanceVariableNames: ''
> >+ classVariableNames: ''
> >+ poolDictionaries: ''
> >+ category: self categoryName.
> >+ self createdClassesAndTraits add: class.
> >+ ^class!
> >
> >
>
>
Hi
On Thu, Mar 28, 2019 at 8:15 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote:
> Sorry to open this up again. I have progressed well in shuffling things
> around. However: While moving the corresponding test cases I noticed that
> there is also #isBinary, #isDoIt, #isInfix, #isUnary, #isKeyword, and
> #isPvtSelector implemented on Symbol. Given that these all exist, I would
> rather keep #asSimpleSetter, #isSimpleSetter, #asSetterSelector in the
> Collections package.
>
> Any other oppinions on that?
>
isPvtSelector, isUnary, isInfix, isKeyword, isDoIt - all similar to your
new isMutator (and all mostly used in MethodFinder, Shout, and
occassionally compiler). I'd prefer to see them moved off to
tools/system/compiler similarly, although that feeling isn't as strong as
some of the other commentators previously. But it is re-enforced by the
#isBinary selector.
#isBinary is a stinker. First off, it just delegates to #isInfix on
Symbol. But it is also on many other classes in Collections, where it
deals with wheither or not the stream is a binary stream or not - in other
words, completely unrelated to the meaning of #isBinary on Symbol (and
shoutParser). I would think pulling this one out for sure from Collections
would be good - even better would be to stop using it for this purpose and
instead directly use #isInfix. (Although I suspect it is called from
packages outside of base Squeak - maybe VMMaker?)
If you don't want to move these, I'd be happy too (as long as overall
consensus doesn't swing away from this direction).
Thanks,
cbc
>
> Bests
> Patrick
>
> >Sounds good to me!
> >
> >How about the following: I would deprecate #asMutator/#isMutator in favor
> of #asSimpleSetter and #isSimpleSetter. At the same time I would move the
> #asSimpleSetter up from Symbol to String where #asSetterSelector already
> resides. Finally, I would move both pairs of selectors to the Tools (or
> System or Compiler?) package (I would rather not keep them scattered across
> MorphicExtras and Etoys as common selectors would then also be used by
> System).
> >
> >Bests,
> >Patrick
> >
> >>
> >>
> >>On Thu, Mar 21, 2019 at 1:03 PM Chris Muller <asqueaker(a)gmail.com>
> wrote:
> >>
> >>My main objection is about growing the "mutator" nomenclature further
> >>instead of trimming it back.
> >>
> >>
> >>+1
> >>
> >>I'm working on a GraphQL framework.
> >>GraphQL has a first-class notion of "mutations".
> >>
> >>https://graphql.org/learn/queries/
> >>
> >>Currently, we have almost zero mention of the word
> >>"mutator" in the image. I would appreciate if, instead of germinating
> >>the overloading the word, we uproot it and keep the nomenclature for
> >>this Smalltalk tooling confined to "getter" and "setter" that we have
> >>now.
> >>
> >>
> >>+1
> >>
> >>So, instead of #asMutator and #isMutator, how about #asSimpleSetter and
> >>#isSimpleSetter?
> >>
> >>
> >>+1
> >>
> >>
> >>We can end up removing a method instead of adding one. We already
> >>have many existing methods which are dealing with this conversion, all
> >>of which use the traditional Smalltalk / developer linguisitic of
> >>"setter". Browsing through all the "setter" nomenclature we have in a
> >>message names browser, including
> >>
> >>Utilities class>>#getterSelectorFor:
> >>Utilities class>>#setterSelectorFor:
> >>Utilities class>>#simpleSetterFor:
> >>
> >>which instruct Etoys users to use existing methods on String,
> >>#asSetterSelector or #asSimpleSetter.
> >>
> >>Of special note is SyntaxMorph>>#isStandardSetterKeyword: which, by
> >>its use of a utility-method implementation, acknowledges that this
> >>behavior is _application-specific_.
> >>
> >>I, myself, would just write:
> >>
> >>someSelector asSimpleSetter = someSelector "same as isMutator /
> >>isSimpleSetter"
> >>
> >>instead of #isSimpleSetter, but can appreciate both styles. They both
> >>better avoid the awkwardness of "mutator" as a general, reliable
> >>behavior when:
> >>
> >>#at: isMutator "true"
> >>
> >>while
> >>
> >>#at:put: isMutator "false"
> >>
> >>
> >>+1000. Chris is right. isMutator is a mistake.
> >>
> >>
> >>Best,
> >>Chris
> >>
> >>
> >>
> >>On Thu, Mar 21, 2019 at 1:16 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote:
> >>>
> >>> Which one are you refering to? I only see Symbol>>#asMutator in
> Collections in the method category converting. It is also used in a few
> other places beyond generating instance variable accessors.
> >>>
> >>> Bests,
> >>> Patrick
> >>>
> >>> >#asMutator: is for "generate instVar accessors" code-generation, and
> >>> >that's why it's in the Tools package.
> >>> >
> >>> >IMHO, if #isMutator belongs anywhere, it isn't in Collections.
> >>> >
> >>> >Regards,
> >>> > Chris
> >>> >
> >>> >
> >>> >
> >>> >On Wed, Mar 20, 2019 at 3:08 PM Chris Muller <asqueaker(a)gmail.com>
> wrote:
> >>> >>
> >>> >> Assuming a single-keyword is a mutator? Object>>#at: is not a
> >>> >> mutator. #indexOf: is not. #first: is not. Obviously many more..
> >>> >>
> >>> >> If API balance is the goal of this, perhaps #asMutator should be
> >>> >> removed instead. This feels application-specific...
> >>> >>
> >>> >> On Wed, Mar 20, 2019 at 2:05 PM <commits(a)source.squeak.org> wrote:
> >>> >> >
> >>> >> > Patrick Rein uploaded a new version of Collections to project The
> Trunk:
> >>> >> > http://source.squeak.org/trunk/Collections-pre.822.mcz
> >>> >> >
> >>> >> > ==================== Summary ====================
> >>> >> >
> >>> >> > Name: Collections-pre.822
> >>> >> > Author: pre
> >>> >> > Time: 20 March 2019, 8:05:20.383677 pm
> >>> >> > UUID: 483c4461-cee4-4a4f-82d3-fbc03e7201cc
> >>> >> > Ancestors: Collections-dtl.821
> >>> >> >
> >>> >> > Adds #isMutator to Symbol which is analogous to asMutator.
> >>> >> >
> >>> >> > =============== Diff against Collections-dtl.821 ===============
> >>> >> >
> >>> >> > Item was added:
> >>> >> > + ----- Method: Symbol>>isMutator (in category 'testing') -----
> >>> >> > + isMutator
> >>> >> > +
> >>> >> > + ^ self isKeyword and: [self numArgs = 1]!
> >>> >> >
> >>> >> >
> >>> >
> >>>
> >>
> >>
> >>
> >>--
> >>_,,,^..^,,,_
> >>best, Eliot --000000000000004a690584a05ffa--
> >
>
>
+1 for improving the usability of traits.
--Hannes
On 3/28/19, patrick.rein(a)hpi.uni-potsdam.de
<patrick.rein(a)hpi.uni-potsdam.de> wrote:
> The test documents the (currently not working) workflow for removing a trait
> from a class by simply removing the "uses:" line from the class definition.
> To make this work, we would have to make the
> Class>>#subclass:instanceVariableNames:classVariableNames:poolDictionaries:category:
> method aware of traits. The method would have to reset the trait composition
> as
> Class>>#subclass:uses:instanceVariableNames:classVariableNames:poolDictionaries:category:
> currently does. Potentially, the change could also be embedded deeper in the
> class creation code to avoid that duplication and make the other class
> creation methods more robust.
>
> I am hesitant, as I am aware that traits have been prevented from being
> integrated more deeply so far. At the same time, the described missing
> workflow has already led users to struggle with using traits in the first
> place. So as they are part of the system I would rather improve their
> usability. Any other oppinions?
>
> Bests
> Patrick
>
>>Patrick Rein uploaded a new version of TraitsTests to project The Inbox:
>>http://source.squeak.org/inbox/TraitsTests-pre.19.mcz
>>
>>==================== Summary ====================
>>
>>Name: TraitsTests-pre.19
>>Author: pre
>>Time: 28 March 2019, 3:30:48.769796 pm
>>UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017
>>Ancestors: TraitsTests-ul.18
>>
>>Adds a test case for removing traits from a class by simply executing a
>> class creation method without a trait composition. This does currently not
>> yet work.
>>
>>=============== Diff against TraitsTests-ul.18 ===============
>>
>>Item was added:
>>+ ----- Method: TraitTest>>expectedFailures (in category 'failures') -----
>>+ expectedFailures
>>+
>>+ ^ #(testRemoveTraitBySimpleClassDefinition)!
>>
>>Item was added:
>>+ ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in
>> category 'testing') -----
>>+ testRemoveTraitBySimpleClassDefinition
>>+
>>+ | classAv1 classAv2 |
>>+ classAv1 := self createClassNamed: #TraitTestMethodClassA superclass:
>> Object uses: T1.
>>+ classAv2 := self createClassNamed: #TraitTestMethodClassA superclass:
>> Object.
>>+
>>+ self assert: classAv1 == classAv2.
>>+ self assert: classAv2 traits isEmpty.!
>>
>>Item was added:
>>+ ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category
>> 'utility') -----
>>+ createClassNamed: aSymbol superclass: aClass
>>+ | class |
>>+ class := aClass
>>+ subclass: aSymbol
>>+ instanceVariableNames: ''
>>+ classVariableNames: ''
>>+ poolDictionaries: ''
>>+ category: self categoryName.
>>+ self createdClassesAndTraits add: class.
>>+ ^class!
>>
>>
>
>
A new version of Morphic was added to project The Inbox:
http://source.squeak.org/inbox/Morphic-sjce.1465.mcz
==================== Summary ====================
Name: Morphic-sjce.1465
Author: sjce
Time: 21 March 2019, 10:43:01.809481 pm
UUID: f283ce64-3557-483a-971f-43ad678deef9
Ancestors: Morphic-eem.1464
Trying to open the debugger halo on the resulting window results in a MNU
Text>>truncateWithElipsisTo: in HaloMorph>>doDebug:with:
Trying to grab the window results in a MNU Text>>truncateTo:
in Morph>>nameForUndoWording that needs a similar change
=============== Diff against Morphic-eem.1464 ===============
Item was changed:
----- Method: HaloMorph>>doDebug:with: (in category 'private') -----
doDebug: evt with: menuHandle
"Ask hand to invoke the a debugging menu for my inner target. If shift key is down, immediately put up an inspector on the inner target"
| menu |
evt shiftPressed ifTrue: [
evt hand removeHalo.
^ innerTarget inspectInMorphic: evt].
menu := innerTarget buildDebugMenu: evt hand.
+ menu addTitle: (innerTarget externalName asString truncateWithElipsisTo: 40).
- menu addTitle: (innerTarget externalName truncateWithElipsisTo: 40).
menu popUpEvent: evt in: self world.
evt hand removeHalo.!
Item was changed:
----- Method: Morph>>nameForUndoWording (in category 'dropping/grabbing') -----
nameForUndoWording
"Return wording appropriate to the receiver for use in an undo-related menu item (and perhaps elsewhere)"
| aName |
aName := self knownName ifNil: [self renderedMorph class name].
+ ^ aName asString truncateTo: 24!
- ^ aName truncateTo: 24!
On 3/22/19, patrick.rein(a)hpi.uni-potsdam.de
<patrick.rein(a)hpi.uni-potsdam.de> wrote:
> Sounds good to me!
>
> How about the following: I would deprecate #asMutator/#isMutator in favor of
> #asSimpleSetter and #isSimpleSetter. At the same time I would move the
> #asSimpleSetter up from Symbol to String where #asSetterSelector already
> resides. Finally, I would move both pairs of selectors to the Tools (or
> System or Compiler?) package (I would rather not keep them scattered across
> MorphicExtras and Etoys as common selectors would then also be used by
> System).
+1
> Bests,
> Patrick
>
>>
>>
>>On Thu, Mar 21, 2019 at 1:03 PM Chris Muller <asqueaker(a)gmail.com> wrote:
>>
>>My main objection is about growing the "mutator" nomenclature further
>>instead of trimming it back.
>>
>>
>>+1
>>
>>I'm working on a GraphQL framework.
>>GraphQL has a first-class notion of "mutations".
>>
>>https://graphql.org/learn/queries/
>>
>>Currently, we have almost zero mention of the word
>>"mutator" in the image. I would appreciate if, instead of germinating
>>the overloading the word, we uproot it and keep the nomenclature for
>>this Smalltalk tooling confined to "getter" and "setter" that we have
>>now.
>>
>>
>>+1
>>
>>So, instead of #asMutator and #isMutator, how about #asSimpleSetter and
>>#isSimpleSetter?
>>
>>
>>+1
>>
>>
>>We can end up removing a method instead of adding one. We already
>>have many existing methods which are dealing with this conversion, all
>>of which use the traditional Smalltalk / developer linguisitic of
>>"setter". Browsing through all the "setter" nomenclature we have in a
>>message names browser, including
>>
>>Utilities class>>#getterSelectorFor:
>>Utilities class>>#setterSelectorFor:
>>Utilities class>>#simpleSetterFor:
>>
>>which instruct Etoys users to use existing methods on String,
>>#asSetterSelector or #asSimpleSetter.
>>
>>Of special note is SyntaxMorph>>#isStandardSetterKeyword: which, by
>>its use of a utility-method implementation, acknowledges that this
>>behavior is _application-specific_.
>>
>>I, myself, would just write:
>>
>>someSelector asSimpleSetter = someSelector "same as isMutator /
>>isSimpleSetter"
>>
>>instead of #isSimpleSetter, but can appreciate both styles. They both
>>better avoid the awkwardness of "mutator" as a general, reliable
>>behavior when:
>>
>>#at: isMutator "true"
>>
>>while
>>
>>#at:put: isMutator "false"
>>
>>
>>+1000. Chris is right. isMutator is a mistake.
>>
>>
>>Best,
>>Chris
>>
>>
>>
>>On Thu, Mar 21, 2019 at 1:16 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote:
>>>
>>> Which one are you refering to? I only see Symbol>>#asMutator in
>>> Collections in the method category converting. It is also used in a few
>>> other places beyond generating instance variable accessors.
>>>
>>> Bests,
>>> Patrick
>>>
>>> >#asMutator: is for "generate instVar accessors" code-generation, and
>>> >that's why it's in the Tools package.
>>> >
>>> >IMHO, if #isMutator belongs anywhere, it isn't in Collections.
>>> >
>>> >Regards,
>>> > Chris
>>> >
>>> >
>>> >
>>> >On Wed, Mar 20, 2019 at 3:08 PM Chris Muller <asqueaker(a)gmail.com>
>>> > wrote:
>>> >>
>>> >> Assuming a single-keyword is a mutator? Object>>#at: is not a
>>> >> mutator. #indexOf: is not. #first: is not. Obviously many more..
>>> >>
>>> >> If API balance is the goal of this, perhaps #asMutator should be
>>> >> removed instead. This feels application-specific...
>>> >>
>>> >> On Wed, Mar 20, 2019 at 2:05 PM <commits(a)source.squeak.org> wrote:
>>> >> >
>>> >> > Patrick Rein uploaded a new version of Collections to project The
>>> >> > Trunk:
>>> >> > http://source.squeak.org/trunk/Collections-pre.822.mcz
>>> >> >
>>> >> > ==================== Summary ====================
>>> >> >
>>> >> > Name: Collections-pre.822
>>> >> > Author: pre
>>> >> > Time: 20 March 2019, 8:05:20.383677 pm
>>> >> > UUID: 483c4461-cee4-4a4f-82d3-fbc03e7201cc
>>> >> > Ancestors: Collections-dtl.821
>>> >> >
>>> >> > Adds #isMutator to Symbol which is analogous to asMutator.
>>> >> >
>>> >> > =============== Diff against Collections-dtl.821 ===============
>>> >> >
>>> >> > Item was added:
>>> >> > + ----- Method: Symbol>>isMutator (in category 'testing') -----
>>> >> > + isMutator
>>> >> > +
>>> >> > + ^ self isKeyword and: [self numArgs = 1]!
>>> >> >
>>> >> >
>>> >
>>>
>>
>>
>>
>>--
>>_,,,^..^,,,_
>>best, Eliot --000000000000004a690584a05ffa--
>
>
DLS 2019 - 15th Dynamic Languages Symposium
Co-located with SPLASH 2019, October 22, Athens, Greece
https://conf.researchr.org/home/dls-2019
Follow us @dynlangsym
Dynamic Languages play a fundamental role in today’s world of software,
from the perspective of research and practice. Languages such as
JavaScript, R, and Python are vehicles for cutting edge research as well
as building widely used products and computational tools.
The 15th Dynamic Languages Symposium (DLS) at SPLASH 2019 is the
premier forum for researchers and practitioners to share research and
experience on all aspects on dynamic languages.
DLS 2019 invites high quality papers reporting original research and
experience related to the design, implementation, and applications of
dynamic languages.
Areas of interest are generally empirical studies, language design,
implementation, and runtimes, which includes but is not limited to:
- innovative language features
- innovative implementation techniques
- innovative applications
- development environments and tools
- experience reports and case studies
- domain-oriented programming
- late binding, dynamic composition, and run-time adaptation
- reflection and meta-programming
- software evolution
- language symbiosis and multi-paradigm languages
- dynamic optimization
- interpretation, just-in-time and ahead-of-time compilation
- soft/optional/gradual typing
- hardware support
- educational approaches and perspectives
- semantics of dynamic languages
- frameworks and languages for the Cloud and the IoT
Submission Details
Submissions must neither be previously published nor under review at
other events. DLS 2019 uses a single-blind, two-phase reviewing process.
Papers are assumed to be in one of the following categories:
Research Papers:
describe work that advances the current state of the art
Experience Papers:
describe insights gained from substantive practical
applications that should be of a broad interest
Dynamic Pearls:
describe a known idea in an appealing way to remind the
community and capture a reader’s interest
The program committee will evaluate each paper based on its
relevance, significance, clarity, and originality.
The paper category needs to be indicated during submission,
and papers are judged accordingly.
Papers are to be submitted electronically at https://dls19.hotcrp.com/
in PDF format. Submissions must be in the ACM SIGPLAN conference acmart
format, 10 point font, and should not exceed 12 pages. Please see full
details in the instructions for authors available at:
https://conf.researchr.org/home/dls-2019#Instructions-for-Authors
DLS 2019 will run a two-phase reviewing process to help authors make
their final papers the best that they can be. Accepted papers will be
published in the ACM Digital Library and will be freely available for
one month, starting two weeks before the event.
Important Deadlines
Abstract Submission: May 29, 2019
Paper Submission: June 5, 2019
First Phase Notification: July 3, 2019
Final Notifications: August 14, 2019
Camera Ready: August 28, 2019
All deadlines are 23:59 AoE (UTC-12h).
AUTHORS TAKE NOTE: The official publication date is the date the
proceedings are made available in the ACM Digital Library. This date
may be up to two weeks prior to the first day of your conference.
The official publication date affects the deadline for any patent
filings related to published work.
Program CommitteeAlexandre Bergel, University of Chile
Carl Friedrich Bolz-Tereick, Heinrich-Heine-Universität Düsseldorf
Chris Seaton, Oracle Labs
David Chisnall, Microsoft Research
Elisa Gonzalez Boix, Vrije Universiteit Brussel
Gregor Richards, University of Waterloo
Guido Chari, Czech Technical University
Hannes Payer, Google
James Noble, Victoria University of Wellington
Jeremy Singer, University of Glasgow
Joe Gibbs Politz, University of California San Diego
Juan Fumero, The University of Manchester
Julien Ponge, Red Hat
Mandana Vaziri, IBM Research
Manuel Serrano, Inria
Marc Feeley, Université de Montréal
Mark Marron, Microsoft Research
Na Meng, Virginia Tech
Nick Papoulias, Université Grenoble Alpes
Richard Roberts, Victoria University of Wellington
Sam Tobin-Hochstadt, Indiana University
Sarah Mount, Aston University
Sébastien Doeraene, École polytechnique fédérale de Lausanne
William Cook, University of Texas at Austin
Program Chair
Stefan Marr, University of Kent, United Kingdom