June 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] STON Question

by Stephane Ducasse

Sven I know what Ston is :) Now Pillar dev used Ston as input and it works. Then with some hooks they let the user convert the strings into specific objects and this is ok. Now I want to add export in Ston and for configurations I need to control for the application and not as a ston object the value saved. For example a file reference should not be just a file reference in Ston but a string relative the the baseDirectory of the configuration. So I thought that I can build a hook and control the call to Ston (convert the object before to the correct values) and export. It should be working now doing this I found myself redoing the output of Ston. So I will do it. Then I thought that may be I could reuse this logic. Stef On Sun, Jun 4, 2017 at 11:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Stef, > > STON is like FUEL, it can write any object to a stream and read it back. > Although you can customise how this is done, only one way of doing so is > supported (i.e. you cannot change the format for each application). > > People have used STON for various applications now, including for > configuration stuff (because it is a textual format that is easy to read). > > I would suggest you just try to see what your config looks like once you > have the objects in Pharo. > > STON toStringPretty: myConfig. > > Then we can see how to tune the representation. > > Sven > > > On 4 Jun 2017, at 22:58, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Hi sven > > > > I'm working on a new configuration frameworks similar to the one use > pillar.conf. > > > > So basically I have > > > > ston := '{ > > "newLine":#unix, > > "separateOutputFiles":true > > }'. > > and I want to recreate it. > > > > So I did > > > > Object >> toConfigurationString > > > > ^ STON toString: self > > > > SimpleConfiguration >> exportStream > > > > ^ String streamContents: [ :str | > > str << '{' . > > self propertiesKeysAndValuesDo: [ :key :value| > > str << key toConfigurationString. > > str << ':'. > > str << value toConfigurationString. > > str << ','. > > str lf. > > ]. > > str << '}'. > > str contents > > ] > > > > The idea is that for special configuration values people should be able > to define > > how to go from the object to configuration. > > For example for some FileReference I want to have just the path up to > the baseDirectory. > > > > Now I wonder if I could not better reuse ston. > > I saw the stonOn: > > but I did not look further because I was wondering how the writer where > passed. > > > > Any feedback is welcome. > > > > Stef (now bed time). > > > > >

June 5, 2017

Re: [Pharo-users] Saving selected changes in Monticello

by serge.stinckwich＠gmail.com

Kommiter available in default image allows you do cherry pick quite easily. EnvoyÃ© de mon iPhone > Le 5 juin 2017 Ã 07:14, Ben Coman <btc(a)openinworld.com> a Ã©crit : > > > >> On Mon, Jun 5, 2017 at 10:12 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> I have a half done changes in my image, but I need to distribute the other changes that are done. I thought I was going to do this all at once, but now I realize I should split this into 2 commit versions. >> >> Is there a way in Monticello to say save my changes, but not this and that changes? I can't seem to find it nor in books. How do people deal with this situation? > > AFAIK, Monticello cannot cherry pick. One work around is probably something like... > 1. Save the mcz locally > 2. Merge back into a fresh image selecting only the bits you want. > 3. Save as a second mcz. > One issue is that the second mcz will have the first mcz as an ancestor, so before 2 you might create a new changeset to file out after 2, and load that into a second new image. yuck! > > Another alternative might be to use Tools > ChangeSorter to move the code you want to exclude from the mcz to a changeset, file that out and then revert that code in the image. After save the package to a mcz, reload the changeset. > > cheers -ben

June 5, 2017

Re: [Pharo-users] Saving selected changes in Monticello

by Ben Coman

On Mon, Jun 5, 2017 at 10:12 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > I have a half done changes in my image, but I need to distribute the other > changes that are done. I thought I was going to do this all at once, but > now I realize I should split this into 2 commit versions. > > Is there a way in Monticello to say save my changes, but not this and that > changes? I can't seem to find it nor in books. How do people deal with this > situation? > AFAIK, Monticello cannot cherry pick. One work around is probably something like... 1. Save the mcz locally 2. Merge back into a fresh image selecting only the bits you want. 3. Save as a second mcz. One issue is that the second mcz will have the first mcz as an ancestor, so before 2 you might create a new changeset to file out after 2, and load that into a second new image. yuck! Another alternative might be to use Tools > ChangeSorter to move the code you want to exclude from the mcz to a changeset, file that out and then revert that code in the image. After save the package to a mcz, reload the changeset. cheers -ben

June 5, 2017

Re: [Pharo-users] Wiring objects, IoC and Service Locator

by Ben Coman

Sorry I'm not familiar with the pattern, so I don't have a direct answer, and the following might not have a direct answer either, but in general I'd strongly suggest two books for adapting from static OO languages. 1. The Design Patterns Smalltalk Companion, Alpert, Brown & Woolf - including some discussion on why certain patterns required for static-OO are redundant in Smalltalk. My naive guess is the Factory, Strategy and/or Template patterns may apply. 2. A Mentoring Course on Smalltalk, Valloud On Mon, Jun 5, 2017 at 5:17 AM, Vitor Medina Cruz <vitormcruz(a)gmail.com> wrote: > Hello, > > I would like to know how people in Pharo ecosystem do to deal with object > wiring, as described by Marting Fowler in https://martinfowler.com/ > articles/injection.html#FormsOfDependencyInjection: > > "A common issue to deal with is how to wire together different elements: > how do you fit together this web controller architecture with that database > interface backing when they were built by different teams with little > knowledge of each other." > > He gives an example, I will leave it in java as it is simple enough to > understand: > > "class MovieLister... > > public Movie[] moviesDirectedBy(String arg) { > List allMovies = finder.findAll(); > for (Iterator it = allMovies.iterator(); it.hasNext();) { > Movie movie = (Movie) it.next(); > if (!movie.getDirector().equals(arg)) it.remove(); > } > return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]); > > }" > > The question is how to provide the finder object in a decoupled matter, a > naive approach would be: > > " private MovieFinder finder; > > public MovieLister() { > finder = new ColonDelimitedMovieFinder("movies1.txt"); > > }" > I'm not really familiar with IoC or DI patterns, so just taking your example at face value, in Pharo I'd do... MovieLister>>moviesDirectedBy: director allMovies := finder allMovies. ^ allMovies select: [ :movie | movie getDirector = director ]. "although typically #getDirector would be renamed #director" MovieLister>>finder: movieFinder finder := movieFinder. to be used like this... lister := MovieLister new finder: (ColonDelimitedMovieFinder on: 'movies1.txt'). movies := lister moviesDirectedBy: 'Tarantino'. > > Which couples the MovieLister to the specific ColonDelimitedMovieFinder > class. > > Fowler explains how to decouple using an IoC framework or a Service > Locator. In Java and .Net IoC is used most of the time. I Googled how this > problem is approached in Smalltalk/Pharo, and I generally I found answers > "that is easy to do in Smalltalk, so there is no need of a framework", what > I miss is a description on *how* to do that: > Just to satisfy my curiosity, I did find... "MVC was invented on Smalltalk and is arguably the original Inversion of Control framework. ... I think that IOC or the Dependency Injection pattern solves a problem that doesn't really exist in the Smalltalk environment. Smalltalk is an untyped dynamic language and uses message passing to communicate. This makes for objects that are loosely coupled by nature at the language level" http://www.weizhishi.tech/questions/296612/smalltalk-and-ioc And this... "In an explicitly-typed language like C++, C#, or Java, it is necessary to define an explicit interface for the injected collaborator. The real collaborator and the substitute both have to implement the interface. In a dynamically-typed language like Ruby [& Smalltalk], explicit interfaces are not necessary. We can just take advantage of 'duck-typing'." http://randycoulman.com/blog/2013/06/04/affordances-dependency-injection/ And GIlad Bracha knows a bit about Java... "I think that if youâre stuck with a mainstream language, [dependency Injection] may be a reasonable work around. It requires a significant degree of preplanning, and makes your application dependent on one more piece of machinery that has nothing to do with the actual problem the application is trying to solve. On the positive side, it helps guarantee employment for software engineers. That said, itâs important to understand that DIFs are just a work around for a deficiency in the underlying language. So why not get rid of constructors and have a class declaration create a factory object instead? Well, Smalltalk did just that a generation ago. Every time you define a class, you define the factory object for its instances." https://gbracha.blogspot.com.au/2007/06/constructors-considered-harmful.html btw, following Randy's example the two steps #new & #finder: should hidden/combined by renaming MovieLister>>finder: to MovieLister>>initializeWithFinder: and adding... MovieLister class >> newWithFinder: finder ^ self basicNew initializeWithFinder: finder to be used like this... lister := MovieLister newWithFinder: (ColonDelimitedMovieFinder on: 'movies1.txt'). movies := lister moviesDirectedBy: 'Tarantino'. btw, while you are at it, if you haven't done this before, try implementing this using Smalltalk's version of TDD... https://www.youtube.com/watch?v=ymITEeAOtEA https://www.youtube.com/watch?v=XxqZVAOomfM In a clean image, first implement the following method and run the test, then fill code as needed just-in-time... MovieListerTest>>testColonDelimitedFinder lister := MovieLister newWithFinder: (ColonDelimitedMovieFinder on: 'movies1.txt'). movies := lister moviesDirectedBy: 'Tarantino'. self assert: (movies includes: 'Pulp Fiction') > https://stackoverflow.com/questions/243905/smalltalk-and-ioc > https://stackoverflow.com/questions/2684326/is-there-a- > dependency-injection-framework-for-smalltalk > https://stackoverflow.com/questions/243905/smalltalk-and-ioc/347477#347477 > I see similar comments to my references in these. I hope the bits I've focussed on are not redundant . > I know that in Smalltalk I can make MovieLister to receive, upon > construction, a class representing MovieFinder and call it construction > message. As long an object that responds to this message is provided, I can > create as many derivations I want and the MovieLister will be decoupled > from the MovieFinder. > Reading this, I think maybe all I've done with my example is echo this. So what I'm not clear on is what you mean by "wire things by hand" > That way, however, I still have to wire things by hand, and I am not sure > if this is what I am supposed to do in order to solve the decouple problem. > I would say use Pharo's TDD approach of coding-from-within-the-debugger. The beauty of it is not that you get a lot of test coverage. There other significant benefits are: A. Your API ends up designed "in the most natural way to be used" since each time you code how you want to use your API before you define the implementation. B. You only need to code the minimum to get that API aspect working. So you get a faster feedback loop on your design. C. You consistency API implementation, you might define a test like... MovieListerTest>>testAllFinders AbstractMovieFinder allSubclasses do: [ :finderclass | lister := MovieLister newWithFinder: (finderclass on: 'movies1.txt'). movies := lister moviesDirectedBy: 'Tarantino'. self assert: (movies includes: 'Pulp Fiction'). ] and then each time you add an AbstractMovieFinder subclass, you implementation is again just work through fixing the tests from within the debugger. > Can you explain me how this is done in Pharo? It's is usually wiring by > hand? Is there a simple construction that deals with the wiring problem > that I cannot foresee? > TDD helps you avoid worrying about problems that might not exist. cheers -ben > > Thanks in advance, > Vitor > > > >

June 5, 2017

Saving selected changes in Monticello

by Andreas Sunardi

I have a half done changes in my image, but I need to distribute the other changes that are done. I thought I was going to do this all at once, but now I realize I should split this into 2 commit versions. Is there a way in Monticello to say save my changes, but not this and that changes? I can't seem to find it nor in books. How do people deal with this situation? -- Andreas Sunardi

June 5, 2017

Re: [Pharo-users] Creating a BaselineOf from a ConfigurationOf>>#baselineXyz:

by HernÃ¡n Morales Durand

Hi Sean, I didn't tried too much but you may first have to match the node in the parse tree. Something like this: | node | node := (RBParseTreeRewriter treeMatching: '`@expr blessing: `#lit' in: (YourClass >> #baseline01:) parseTree). (node parent removeNode: node) newSource. Cheers, HernÃ¡n 2017-06-04 0:48 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > I'm trying to write a rewrite rule, but can't quite get it. > > I first want to remove `spec blessing: #baseline.` > > I tried the following with no effect: > > RBParseTreeRewriter new > replace: '`@expr blessing: `#lit' > with: ''; > executeTree: methodTree; > tree. > > NB: If I try to edit the expression instead of remove, by passing something > like '`@expr assert: `#lit' for #with:, it works > > What am I missing here? > > Thanks! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ > Creating-a-BaselineOf-from-a-ConfigurationOf-baselineXyz-tp4949192.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

June 5, 2017

Re: [Pharo-users] STON Question

by Sven Van Caekenberghe

Stef, STON is like FUEL, it can write any object to a stream and read it back. Although you can customise how this is done, only one way of doing so is supported (i.e. you cannot change the format for each application). People have used STON for various applications now, including for configuration stuff (because it is a textual format that is easy to read). I would suggest you just try to see what your config looks like once you have the objects in Pharo. STON toStringPretty: myConfig. Then we can see how to tune the representation. Sven > On 4 Jun 2017, at 22:58, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi sven > > I'm working on a new configuration frameworks similar to the one use pillar.conf. > > So basically I have > > ston := '{ > "newLine":#unix, > "separateOutputFiles":true > }'. > and I want to recreate it. > > So I did > > Object >> toConfigurationString > > ^ STON toString: self > > SimpleConfiguration >> exportStream > > ^ String streamContents: [ :str | > str << '{' . > self propertiesKeysAndValuesDo: [ :key :value| > str << key toConfigurationString. > str << ':'. > str << value toConfigurationString. > str << ','. > str lf. > ]. > str << '}'. > str contents > ] > > The idea is that for special configuration values people should be able to define > how to go from the object to configuration. > For example for some FileReference I want to have just the path up to the baseDirectory. > > Now I wonder if I could not better reuse ston. > I saw the stonOn: > but I did not look further because I was wondering how the writer where passed. > > Any feedback is welcome. > > Stef (now bed time). >

June 4, 2017

Wiring objects, IoC and Service Locator

by Vitor Medina Cruz

Hello, I would like to know how people in Pharo ecosystem do to deal with object wiring, as described by Marting Fowler in https://martinfowler.com/articles/injection.html#FormsOfDependencyInjection: "A common issue to deal with is how to wire together different elements: how do you fit together this web controller architecture with that database interface backing when they were built by different teams with little knowledge of each other." He gives an example, I will leave it in java as it is simple enough to understand: "class MovieLister... public Movie[] moviesDirectedBy(String arg) { List allMovies = finder.findAll(); for (Iterator it = allMovies.iterator(); it.hasNext();) { Movie movie = (Movie) it.next(); if (!movie.getDirector().equals(arg)) it.remove(); } return (Movie[]) allMovies.toArray(new Movie[allMovies.size()]); }" The question is how to provide the finder object in a decoupled matter, a naive approach would be: " private MovieFinder finder; public MovieLister() { finder = new ColonDelimitedMovieFinder("movies1.txt"); }" Which couples the MovieLister to the specific ColonDelimitedMovieFinder class. Fowler explains how to decouple using an IoC framework or a Service Locator. In Java and .Net IoC is used most of the time. I Googled how this problem is approached in Smalltalk/Pharo, and I generally I found answers "that is easy to do in Smalltalk, so there is no need of a framework", what I miss is a description on *how* to do that: https://stackoverflow.com/questions/243905/smalltalk-and-ioc https://stackoverflow.com/questions/2684326/is-there-a-dependency-injection… https://stackoverflow.com/questions/243905/smalltalk-and-ioc/347477#347477 I know that in Smalltalk I can make MovieLister to receive, upon construction, a class representing MovieFinder and call it construction message. As long an object that responds to this message is provided, I can create as many derivations I want and the MovieLister will be decoupled from the MovieFinder. That way, however, I still have to wire things by hand, and I am not sure if this is what I am supposed to do in order to solve the decouple problem. Can you explain me how this is done in Pharo? It's is usually wiring by hand? Is there a simple construction that deals with the wiring problem that I cannot foresee? Thanks in advance, Vitor

June 4, 2017

STON Question

by Stephane Ducasse

Hi sven I'm working on a new configuration frameworks similar to the one use pillar.conf. So basically I have ston := '{ "newLine":#unix, "separateOutputFiles":true }'. and I want to recreate it. So I did Object >> toConfigurationString ^ STON toString: self SimpleConfiguration >> exportStream ^ String streamContents: [ :str | str << '{' . self propertiesKeysAndValuesDo: [ :key :value| str << key toConfigurationString. str << ':'. str << value toConfigurationString. str << ','. str lf. ]. str << '}'. str contents ] The idea is that for special configuration values people should be able to define how to go from the object to configuration. For example for some FileReference I want to have just the path up to the baseDirectory. Now I wonder if I could not better reuse ston. I saw the stonOn: but I did not look further because I was wondering how the writer where passed. Any feedback is welcome. Stef (now bed time).

June 4, 2017

Deadline Extension - SLE 2017 (10th ACM SIGPLAN International Conference on Software Language Engineering)

by Andrei Chis

======================================================================== **Call for Papers** - **Deadline Extension** **Abstract Submission**: Friday 9, June 2017 **Paper Submission**: Friday 16, June 2017 ======================================================================== 10th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2017) 23-24 October 2017, Vancouver, Canada (Co-located with SPLASH 2017) General chair: Benoit Combemale, University of Rennes 1, France Program co-chairs: Marjan Mernik, University of Maribor, Slovenia Bernhard Rumpe, RWTH Aachen University, Germany Artifact evaluation chairs: Tanja Mayerhofer, TU Wien, Austria Laurence Tratt, King's College London, UK Keynote Speaker: Peter D. Mosses, Swansea University, UK (http://cs.swan.ac.uk/~cspdm/) http://conf.researchr.org/track/sle-2017/sle-2017-papers http://www.sleconf.org/2017 Follow us on twitter: https://twitter.com/sleconf ======================================================================== Software Language Engineering (SLE) is the application of systematic, disciplined, and measurable approaches to the development, use, deployment, and maintenance of software languages. The term "software language" is used broadly, and includes: general-purpose programming languages; domain-specific languages (e.g. BPMN, Simulink, Modelica); modeling and metamodeling languages (e.g. SysML and UML); data models and ontologies (e.g. XML-based and OWL-based languages and vocabularies). ### Important Dates Fri 9 Jun 2017 - Abstract Submission Fri 16 Jun 2017 - Paper Submission Fri 4 Aug 2017 - Author Notification Thu 10 Aug 2017 - Artifact Submission Fri 1 Sep 2017 - Artifact Notification Fri 8 Sep 2017 - Camera Ready Deadline Sun 22 Oct - SLE workshops Mon 23 Oct - Tue 24 Oct 2017 - SLE Conference ### Topics of Interest SLE aims to be broad-minded and inclusive about relevance and scope. We solicit high-quality contributions in areas ranging from theoretical and conceptual contributions to tools, techniques, and frameworks in the domain of language engineering. Topics relevant to SLE cover generic aspects of software languages development rather than aspects of engineering a specific language. In particular, SLE is interested in principled engineering approaches and techniques in the following areas: * Language Design and Implementation * Approaches and methodologies for language design * Static semantics (e.g., design rules, well-formedness constraints) * Techniques for behavioral / executable semantics * Generative approaches (incl. code synthesis, compilation) * Meta-languages, meta-tools, language workbenches * Language Validation * Verification and formal methods for languages * Testing techniques for languages * Simulation techniques for languages * Language Integration and Composition * Coordination of heterogeneous languages and tools * Mappings between languages (incl. transformation languages) * Traceability between languages * Deployment of languages to different platforms * Language Maintenance * Software language reuse * Language evolution * Language families and variability * Domain-specific approaches for any aspects of SLE (design, implementation, validation, maintenance) * Empirical evaluation and experience reports of language engineering tools * User studies evaluating usability * Performance benchmarks * Industrial applications ### Types of Submissions * **Research papers**: These should report a substantial research contribution to SLE or successful application of SLE techniques or both. Full paper submissions must not exceed 12 pages including bibliography in ACM SIGPLAN acmart conference style ( http://www.sigplan.org/Resources/Author/) * **Tool papers**: Because of SLE's interest in tools, we seek papers that present software tools related to the field of SLE. Selection criteria include originality of the tool, its innovative aspects, and relevance to SLE. Any of the SLE topics of interest are appropriate areas for tool demonstrations. Submissions must provide a tool description of 4 pages including bibliography in ACM SIGPLAN acmart conference style ( http://www.sigplan.org/Resources/Author/) and a demonstration outline including screenshots of up to 6 pages. Tool demonstrations must have the keywords âTool Demoâ or âTool Demonstrationâ in the title. The 4-page tool description will, if the demonstration is accepted, be published in the proceedings. The 6-page demonstration outline will be used by the program committee only for evaluating the submission. * **Industrial papers**: These should describe real-world application scenarios of SLE in industry, explained in their context with an analysis of the challenges that were overcome and the lessons which the audience can learn from this experience. Industry paper submissions must not exceed 6 pages including bibliography in ACM SIGPLAN acmart conference style ( http://www.sigplan.org/Resources/Author/) * **New ideas / vision papers**: New ideas papers should describe new, non-conventional SLE research approaches that depart from standard practice. They are intended to describe well-defined research ideas that are at an early stage of investigation. Vision papers are intended to present new unifying theories about existing SLE research that can lead to the development of new technologies or approaches. New ideas / vision papers must not exceed 4 pages including bibliography in ACM SIGPLAN acmart conference style (http://www.sigplan.org/Resources/Author/) ### Artifact evaluation SLE will for the second year use an evaluation process for assessing the quality of artifacts on which papers are based. The aim of this evaluation process is to foster a culture of experimental reproducibility as well as a higher quality in the research area as a whole. Authors of papers accepted for SLE 2017 will be invited to submit artifacts. Any kind of artifact that is presented in the paper, supplements the paper with further details, or underlies the paper can be submitted. This includes, for instance, tools, grammars, metamodels, models, programs, algorithms, scripts, proofs, datasets, statistical tests, checklists, surveys, interview scripts, visualizations, annotated bibliographies, and tutorials. The submitted artifacts will be reviewed by a dedicated Artifact Evaluation Committee (AEC). Artifacts that live up to the expectations created by the paper will receive a badge of approval from the AEC. The approved artifacts will be invited for inclusion in the electronic conference proceedings published in the ACM Digital Library. This will ensure the permanent and durable storage of the artifacts alongside the published papers fostering the repeatability of experiments, enabling precise comparison with alternative approaches, and helping the dissemination of the authorâs ideas in detail. Participating in the artifact evaluation and publishing approved artifacts in the ACM Digital Library is voluntary. However, we strongly encourage authors to consider this possibility as the availability of artifacts will greatly benefit readers of papers and increase the impact of the work. Note that the artifact evaluation cannot affect the acceptance of the paper, because it only happens after the decision about acceptance has been made. ### Publications All submitted papers will be reviewed by at least three members of the program committee. All accepted papers, including tool papers, industrial papers and new ideas / vision papers will be published in ACM Digital Library. Selected accepted papers will be invited to a special issue of the Computer Languages, Systems and Structures (COMLAN) journal. ### Awards * **Distinguished paper**: Award for most notable paper, as determined by the PC chairs based on the recommendations of the program committee. * **Distinguished reviewer**: Award for distinguished reviewer, as determined by the PC chairs using feedback from the authors. * **Distinguished artifact**: Award for the artifact most significantly exceeding expectations, as determined by the AEC chairs based on the recommendations of the artifact evaluation committee. ### Program Committee Marjan Mernik (co-chair), University of Maribor, Slovenia Bernhard Rumpe (co-chair), RWTH Aachen University, Germany Christian Berger, Chalmers, Sweden Mark van den Brand, TU Eindhoven, The Netherlands Ruth Breu, University of Innsbruck, Austria Jordi Cabot, ICREA, Spain Walter Cazzola, University of Milan, Italy Marsha Chechik, University of Toronto, Canada Tony Clark, Middlesex University, UK Tom Dinkelaker, Ericsson, Germany Bernd Fischer, Stellenbosch University, South Africa Sebastian Gerard, CEA, France Jeff Gray, University of Alabama, USA Esther Guerra, Autonomous University of Madrid, Spain Michael Homer, Victoria University of Wellington, New Zealand Ralf LÃ¤mmel, University of Koblenz-Landau, Germany Tihamer Levendovszky, Microsoft, USA Gunter Mussbacher, McGill University, Canada Terence Parr, University of San Francisco, USA Jaroslav PorubÃ¤n, University of KoÅ¡ice, Slovakia Jan Ringert, Tel Aviv University, Israel Julia Rubin, University of British Columbia, Canada Tony Sloane, Macquarie University, Australia Eugene Syriani, University of Montreal, Canada Emma SÃ¶derberg, Google, Denmark Eric Van Wyk, University of Minnesota, USA Jurgen Vinju, CWI, Netherlands Eric Walkingshaw, Oregon State University, USA Andreas Wortmann, RWTH Aachen University, Germany Tian Zhang, Nanjing University, China ### Contact For any question, please contact the organizers via email: sle2017(a)inria.fr

June 4, 2017