- Pharo-users - lists.pharo.org

Re: [Pharo-users] UFFI correct way to cast void*

by Egor Scorik

Thanks! #valueFromHandle: exactly what I looking for! I also add method for strings to make them working FFIExternalString >> valueFromHandle: anAddress | data | data := ExternalData fromHandle: anAddress type: ExternalType string. data isNull ifTrue: [ ^ nil ]. ^ data fromCString -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Esteban Lorenzano

> On 17 Feb 2018, at 02:50, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On 16 February 2018 at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C compiler that a pointer is form a certain type (but is always a pointer, and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > > Perhaps this is a bit about discover-ability. People with C experience may > naturally search for "cast". If I Spotter search for..... cast #i > it turns up only four... "broadcast" under Socket class > > If that was instead like... (typeClass castFromHandle: address) > then people may be more likely to find it themselves. I was thinking to implement the #castTo: for all the âpointerâ classes (ByteArray, FFIExternalReference, FFIExternalStructure). #[42 0 0 0] castTo: FFIInt32 -> 42 what do you think? Esteban > > cheers -ben > > > > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, like int, long, etc. because those values are passed âby valueâ and not by pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail clientâ, but you get the idea ;) ) > > > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com <mailto:shirofaii@gmail.com>> wrote: > > > > Hi, > > > > I'm trying to play with new UFFI system. It looks much easier then > > NativeBoost, but unfortunately its hard to find any docs or examples. > > I have problem with casting void* (ExternalAddress) into smalltalk object if > > there is no hardcoded type in ffi method. And I really dislike the idea of > > making many ffi methods, one for each required type. > > In this example i can't understand how to make something like `address > > castTo: type` > > > > FFIExternalObject subclass: #Iterator > > > > Iterator >> asCollectionOfType: aTypeName > > | result address type | > > > > result := OrderedCollection new. > > address := ExternalAddress new. > > type := FFIExternalType resolveType: aTypeName. > > [self iterator_next: address] whileTrue: [ > > result add: (address castTo: type). > > ]. > > ^result > > > > Iterator >> iterator_next: data > > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> > > > > >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Stephane Ducasse

Hi esteban do you plan to add this explanation to the documentation of uFFI? Stef On Fri, Feb 16, 2018 at 9:38 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C compiler that a pointer is form a certain type (but is always a pointer, and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, like int, long, etc. because those values are passed âby valueâ and not by pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail clientâ, but you get the idea ;) ) > >> On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: >> >> Hi, >> >> I'm trying to play with new UFFI system. It looks much easier then >> NativeBoost, but unfortunately its hard to find any docs or examples. >> I have problem with casting void* (ExternalAddress) into smalltalk object if >> there is no hardcoded type in ffi method. And I really dislike the idea of >> making many ffi methods, one for each required type. >> In this example i can't understand how to make something like `address >> castTo: type` >> >> FFIExternalObject subclass: #Iterator >> >> Iterator >> asCollectionOfType: aTypeName >> | result address type | >> >> result := OrderedCollection new. >> address := ExternalAddress new. >> type := FFIExternalType resolveType: aTypeName. >> [self iterator_next: address] whileTrue: [ >> result add: (address castTo: type). >> ]. >> ^result >> >> Iterator >> iterator_next: data >> ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** data)) >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Stephane Ducasse

On Fri, Feb 16, 2018 at 9:07 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>but unfortunately its hard to find any docs or examples. > > PDF Docu: https://github.com/SquareBracketAssociates/Booklet-uFFI > > (this should be added to http://books.pharo.org) It will be added when it will be completed. And since this is not me that will do it because I cannot then I wait. May be one day someone with enough knowledge will consider that FFI is important enough to document it seriously. Stef > > Examples: load OSWindows, OSLinuxUbuntu, ... or GlorpSQlite from catalog > They all use UFFI. >

Feb. 17, 2018

Re: [Pharo-users] UFFI correct way to cast void*

by Ben Coman

On 16 February 2018 at 16:38, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > hi, > > âcastingâ is not necessary in general since is just a way to tell the C > compiler that a pointer is form a certain type (but is always a pointer, > and in machine code is always the same). > > So, here you will do something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass fromHandle: address) ]. > Perhaps this is a bit about discover-ability. People with C experience may naturally search for "cast". If I Spotter search for..... cast #i it turns up only four... "broadcast" under Socket class If that was instead like... (typeClass castFromHandle: address) then people may be more likely to find it themselves. cheers -ben > ^result > > Iterator >> iterator_next: data > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** > data)) > > nowâ¦ you have a problem if your type if your type is an âatomicâ type, > like int, long, etc. because those values are passed âby valueâ and not by > pointer, so you will need to decode them. > in this case, I would implement a method extension (probably it worths to > add it to UFFI): > > FFIExternalType class >> valueFromHandle: anAddress > ^ self new handle: anAddress at: 1 âThis is used for structures, > but we can reuse them :)" > > FFIExternalReference class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > FFIExternalStructure class >> valueFromHandle: anAddress > ^ self fromHandle: anAddress > > So your function will be like something like this: > > Iterator >> asCollectionOfType: aTypeName > | result address typeClass | > > result := OrderedCollection new. > address := ExternalAddress new. > typeClass := FFIExternalType resolveType: aTypeName. > [self iterator_next: address] > whileTrue: [ result add: (typeClass valueFromHandle:: > address) ]. > ^result > > and voilÃ , you have your cast :) > > Esteban > > ps: (some errors can be found here, since Iâm âprogramming at mail > clientâ, but you get the idea ;) ) > > > On 15 Feb 2018, at 19:59, Egor Scorik <shirofaii(a)gmail.com> wrote: > > > > Hi, > > > > I'm trying to play with new UFFI system. It looks much easier then > > NativeBoost, but unfortunately its hard to find any docs or examples. > > I have problem with casting void* (ExternalAddress) into smalltalk > object if > > there is no hardcoded type in ffi method. And I really dislike the idea > of > > making many ffi methods, one for each required type. > > In this example i can't understand how to make something like `address > > castTo: type` > > > > FFIExternalObject subclass: #Iterator > > > > Iterator >> asCollectionOfType: aTypeName > > | result address type | > > > > result := OrderedCollection new. > > address := ExternalAddress new. > > type := FFIExternalType resolveType: aTypeName. > > [self iterator_next: address] whileTrue: [ > > result add: (address castTo: type). > > ]. > > ^result > > > > Iterator >> iterator_next: data > > ^ self ffiCall: #(Boolean iterator_next (Iterator self, void** > data)) > > > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > >

Feb. 17, 2018

Re: [Pharo-users] Pillar questions

by Arturo Zambrano

Oh! I see. Thanks a lot! On Fri, Feb 16, 2018 at 9:16 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Pay attention that there is a pharo bug. The downloaded image has a > minimal window of 10 pixels height and 5 width. > > > On Thu, Feb 15, 2018 at 9:02 PM, Arturo Zambrano < > arturo.zambrano(a)gmail.com> wrote: > >> Thanks for your support! >> >> The image seems to be successfully built. >> When running it, it seems to be headless but I'm sure I'm not running it >> in headless mode. >> Is there any specific parameter for building or running it with UI? (I >> also tried the pharo-ui launch script). >> >> >> >> >> On Thu, Feb 15, 2018 at 3:16 PM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >>> Hi arturo >>> >>> I do not really get how you do it. :) >>> >>> $ git clone git@github.com:pillar-markup/pillar.git -b newpipeline >>> $ ./pillar/scripts/build.sh >>> >>> >>> should load and then you get an image with pillar loaded. >>> Now you can also just clone the branch and add with iceberg the project >>> and load should work. >>> >>> May be you should enable the metacello settings to true. >>> >>> Stef >>> >>> >>> On Thu, Feb 15, 2018 at 5:32 PM, Arturo Zambrano < >>> arturo.zambrano(a)gmail.com> wrote: >>> >>>> I found the baseline menu entry.. sorry >>>> >>>> [image: Inline image 1] >>>> >>>> installations fails when I choose Install baseline of Pillar (default) >>>> [image: Inline image 2] >>>> >>>> On Thu, Feb 15, 2018 at 12:50 PM, Arturo Zambrano < >>>> arturo.zambrano(a)gmail.com> wrote: >>>> >>>>> Thanks Stef & Guillermo. >>>>> >>>>> Sorry, I'm a bit confused with Icerberg and GIT support. >>>>> I'm using Iceberg and works fine for my small project without handling >>>>> dependencies in github. >>>>> >>>>> I don't understand how dependencies are managed in this case. >>>>> >>>>> What I understand is that Pillar7 lives in Github, I cloned that repo, >>>>> moved to the indicated branch >>>>> when I try to install the packages (Icerber ->load package) it, as >>>>> expected, >>>>> asks for its dependencies. That's why I tried ConfigurationOfPillar >>>>> loadXYZ >>>>> >>>>> @Stef, I'm trying to load Pillar packages into my image (pharo 6.1) >>>>> for development. I tried the readme of that branch, I will report the >>>>> errors I got in a separate thread. >>>>> >>>>> @Guillermo do you mean to manually clone each dependency github >>>>> repo with iceberg? I think I'm missing something, some documentation >>>>> maybe, any pointer is welcome. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Thu, Feb 15, 2018 at 6:01 AM, Guillermo Polito < >>>>> guillermopolito(a)gmail.com> wrote: >>>>> >>>>>> And you should load baselines with iceberg (and git). >>>>>> >>>>>> On Thu, Feb 15, 2018 at 8:25 AM, Stephane Ducasse < >>>>>> stepharo.self(a)gmail.com> wrote: >>>>>> >>>>>>> No you should use iceberg. The newpipeline is managed on github. >>>>>>> Have a look at the readme of the that branch >>>>>>> Before executing the build scripts check what it is doing. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 14, 2018 at 10:00 PM, Arturo Zambrano < >>>>>>> arturo.zambrano(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi Guillermo >>>>>>>> >>>>>>>> I'd recommend to use the latest pillar version in this branch: >>>>>>>>> >>>>>>>>> https://github.com/pillar-markup/pillar/tree/newpipeline >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I cloned that repo (using Iceberg on 6.1 image), moved to that >>>>>>>> branch and then tried >>>>>>>> ConfigurationOfPillar load{stable|bleedingEdge| etc} >>>>>>>> >>>>>>>> To get all the dependencies. >>>>>>>> I got an error (see below) regarding magritte. >>>>>>>> >>>>>>>> Any advice? >>>>>>>> >>>>>>>> TIA >>>>>>>> >>>>>>>> [image: Inline image 1] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Arturo >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Guille Polito >>>>>>>>> >>>>>>>>> Research Engineer >>>>>>>>> >>>>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>>>> >>>>>>>>> CRIStAL - UMR 9189 >>>>>>>>> >>>>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>>>> <http://www.cnrs.fr>* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>>>> >>>>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>> >>>>>> CRIStAL - UMR 9189 >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>> <http://www.cnrs.fr>* >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>> >> >

Feb. 16, 2018

Re: [Pharo-users] Web scrapping with Pharo Chrome

by Alistair Grant

Hi Offray, On 16 February 2018 at 19:08, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi Alistair, > > > On 15/02/18 12:50, Alistair Grant wrote: >> Hi Offray, >> >> On 14 February 2018 at 20:29, Offray Vladimir Luna CÃ¡rdenas >> <offray.luna(a)mutabit.com> wrote: >>> Yes. Me too. Alistair, any starting points with this example? I will take >>> from there and we could get visibility in the upcoming Open Data Day. >> I'm not sure that I understand what you're after, but maybe the >> following will help. >> >> This simply returns a collection of all the h4 headings that are in cells: >> >> >> | rootNode divs cells cellTitleNodes cellTitles | >> >> rootNode := GoogleChrome get: 'http://mutabit.com/grafoscopio/index.en.html'. >> divs := rootNode findAllTags: 'div'. >> cells := divs select: [ :each | (' ' split: (each attributeAt: >> 'class')) includes: 'mdl-cell' ]. >> cellTitleNodes := cells flatCollect: [ :each | each findAllTags: 'h4' ]. >> cellTitles := cellTitleNodes collect: [ :each | (each findAllStrings: >> true) first nodeValue ]. >> { rootNode. divs. cells. cellTitleNodes. cellTitles } >> > > Thanks. This was the starting point I was looking for. Great. The other place to look is at any examples you can find using Soup (which can be loaded from the Catalog). The API for Pharo-Chrome is a subset of that provided by Soup. >>> Of course, we're going to document everything and share back (I have already >>> proposed some improvements in documentation via PR on the Git repo). >> Thanks very much for improving the readme. I've merged the PR. > > No problem. Thanks to you for starting the project. Actually we need to thank Torsten: https://github.com/astares/Pharo-Chrome Cheers, Alistair > Cheers, > > Offray >

Feb. 16, 2018

Re: [Pharo-users] global exception handler mechanism

by Norbert Hartl

> Am 16.02.2018 um 13:38 schrieb Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > > You can also override #defaultAction on Exception, and install a custom > UIManager subclass implementing unhandledErrorDefaultAction: (sent by > UnhandledError #defaultAction, receives the error as argument). > > Would be nice(r) if UIManager had a defaultUnhandledErrorActionBlock: > setter, but it's not too bothersome creating a subclass. > +1 Norbert > Cheers, > Henry > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 16, 2018

Re: [Pharo-users] Web scrapping with Pharo Chrome

by Offray Vladimir Luna CÃ¡rdenas

Hi Alistair, On 15/02/18 12:50, Alistair Grant wrote: > Hi Offray, > > On 14 February 2018 at 20:29, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Yes. Me too. Alistair, any starting points with this example? I will take >> from there and we could get visibility in the upcoming Open Data Day. > I'm not sure that I understand what you're after, but maybe the > following will help. > > This simply returns a collection of all the h4 headings that are in cells: > > > | rootNode divs cells cellTitleNodes cellTitles | > > rootNode := GoogleChrome get: 'http://mutabit.com/grafoscopio/index.en.html'. > divs := rootNode findAllTags: 'div'. > cells := divs select: [ :each | (' ' split: (each attributeAt: > 'class')) includes: 'mdl-cell' ]. > cellTitleNodes := cells flatCollect: [ :each | each findAllTags: 'h4' ]. > cellTitles := cellTitleNodes collect: [ :each | (each findAllStrings: > true) first nodeValue ]. > { rootNode. divs. cells. cellTitleNodes. cellTitles } > Thanks. This was the starting point I was looking for. > > >> Of course, we're going to document everything and share back (I have already >> proposed some improvements in documentation via PR on the Git repo). > Thanks very much for improving the readme. I've merged the PR. No problem. Thanks to you for starting the project. Cheers, Offray

Feb. 16, 2018

First Call for Papers: 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018)

by Andrei Chis

------------------------------------------------------------------------ Call for Papers: 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018) co-located with SPLASH 2018 November 5-6, 2018 Boston, Massachusetts, United States https://conf.researchr.org/track/sle-2018/papers ------------------------------------------------------------------------ We are pleased to invite you to submit papers to the 11th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2018), held in conjunction with SPLASH 2018 at Boston, Massachusetts on November 5-6, 2018. --------------------------- Scope --------------------------- With the ubiquity of computers, software has become the dominating intellectual asset of our time. In turn, this software depends on software languages, namely the languages it is written in, the languages used to describe its environment, and the languages driving its development process. Given that everything depends on software and that software depends on software languages, it seems fair to say that for many years to come, everything will depend on software languages. Software language engineering (SLE) is the discipline of engineering languages and their tools required for the creation of software. It abstracts from the differences between programming languages, modelling languages, and other software languages, and emphasizes the engineering facet of the creation of such languages, that is, the establishment of the scientific methods and practices that enable the best results. While SLE is certainly driven by its metacircular character (software languages are engineered using software languages), SLE is not self-satisfying: its scope extends to the engineering of languages for all and everything. Like its predecessors, the 11th edition of the SLE conference, SLE 2018, will bring together researchers from different areas united by their common interest in the creation, capture, and tooling of software languages. It overlaps with traditional conferences on the design and implementation of programming languages, model-driven engineering, and compiler construction, and emphasizes the fusion of their communities. To foster the latter, SLE traditionally fills a two-day program with a single track, with the only temporal overlap occurring between co-located events. --------------------------- Topics of Interest --------------------------- SLE 2018 solicits high-quality contributions in areas ranging from theoretical and conceptual contributions, to tools, techniques, and frameworks in the domain of software 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 contributions from the following areas: * Software Language Design and Implementation - Approaches to and methods for language design - Static semantics (e.g., design rules, well-formedness constraints) - Techniques for specifying behavioral / executable semantics - Generative approaches (incl. code synthesis, compilation) - Meta-languages, meta-tools, language workbenches * Software Language Validation - Verification and formal methods for languages - Testing techniques for languages - Simulation techniques for languages * Software 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 * Software 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 --------------------------- Important Dates --------------------------- All dates are Anywhere on Earth. * Fri 29 June 2018 - Abstract Submission * Fri 6 July 2018 - Paper Submission * Fri 24 August 2018 - Author Notification * Fri 31 August 2018 - Artifact Submission * Fri 5 October 2018 - Camera Ready Deadline * Wed 10 October 2018 - Artifact Notification * Fri 12 October 2018 - Deadline for Artifact-Related Paper Updates * Sun 4 Nov 2018 - SLE Workshops * Mon 5 Nov - Tue 6 Nov 2018 - SLE Conference --------------------------- 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 excluding bibliography. * 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 excluding bibliography, 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. * 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 excluding bibliography. Workshops: Workshops will be organized by SPLASH. Please inform us and contact the SPLASH organizers if you would like to organize a workshop of interest to the SLE audience. Information on how to submit workshops can be found at the SPLASH 2018 Website: https://conf.researchr.org/track/splash-2018/splash-2018-Workshops. --------------------------- Artifact Evaluation --------------------------- For the third year SLE will use an evaluation process for assessing the quality of the artifacts on which papers are based to foster the culture of experimental reproducibility. Authors of accepted papers are invited to submit artifacts. More information will be announced on the Website. --------------------------- Submission --------------------------- Submissions have to use the ACM SIGPLAN Conference Format "acmart" ( http://sigplan.org/Resources/Author/#acmart-format) please make sure that you always use the latest ACM SIGPLAN acmart LaTeX template ( https://www.acm.org/binaries/content/assets/publications/consolidated-tex-t…) and that the document class definition is \documentclass[sigplan,screen]{acmart}. Do not make any changes to this format! Using the Word template is strongly discouraged. Ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes in figures and tables are legible. SLE follows a single-blind review process. Thus, you do not have to blind your submission. All submissions must be in PDF format. Concurrent Submissions: Papers must describe unpublished work that is not currently submitted for publication elsewhere as described by SIGPLANâs Republication Policy ( http://www.sigplan.org/Resources/Policies/Republication) Submitters should also be aware of ACMâs Policy and Procedures on Plagiarism ( http://www.acm.org/publications/policies/plagiarism_policy) Submissions that violate these policies will be desk-rejected. Submission Site: Submissions will be accepted at https://sle18.hotcrp.com/. --------------------------- Reviewing Process --------------------------- All submitted papers will be reviewed by at least three members of the program committee. Research papers and tool papers will be evaluated concerning novelty, correctness, significance, readability, and alignment with the conference call. New ideas / vision papers will be evaluated primarily concerning novelty, significance, readability, and alignment with the conference call. For fairness reasons, all submitted papers must conform to the above instructions. Submissions that violate these instructions may be rejected without review, at the discretion of the PC chairs. --------------------------- Awards --------------------------- * Distinguished paper: Award for most notable paper, as determined by the PC chairs based on the recommendations of the programme committee. * Distinguished reviewer: Award for distinguished reviewer, as determined by the PC chairs. * 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. --------------------------- Publication --------------------------- All accepted papers will be published in the ACM Digital Library. 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 the conference. The official publication date affects the deadline for any patent filings related to published work. --------------------------- Program Committee --------------------------- Andrew Black, Portland State University, USA Erwan Bousse, TU Wien, Austria Marco Brambilla, Politecnico di Milano, Italy Ruth Breu, University of Innsbruck, Austria Walter Cazzola, University of Milan, Italy Marsha Chechik, University of Toronto, Canada Tony Clark, Sheffield Hallam University, UK Juan de Lara, Universidad Autonoma de Madrid, Spain Thomas Degueule, CWI Amsterdam, Netherlands Juergen Dingel, Queen's University, Canada Tom Dinkelaker, Ericsson, Germany Sebastian Erdweg, Delft University of Technology, Netherlands Bernd Fischer, Stellenbosch University, South Africa Esther Guerra, Autonomous University of Madrid, Spain Daco Harkes, Delft University of Technology, Netherlands Robert Hirschfeld, University of Potsdam, Germany Michael Homer, Victoria University of Wellington, New Zealand Dimitris Kolovos, University of York, UK Ralf LÃ¤mmel, University of Koblenz-Landau, Germany Marjan Mernik, University of Maribor, Slovenia Gunter Mussbacher, McGill University, Canada James Noble, Victoria University of Wellington, New Zealand Bruno Oliveira, University of Hong Kong, China Christoph Reichenbach, Lund University, Sweden Jan Oliver Ringert, University of Leicester, UK Bernhard Rumpe, RWTH Aachen University, Germany Anthony Sloane, Macquarie University, Australia Emma SÃ¶derberg, Google, Denmark Mark van den Brand, TU Eindhoven, Netherlands Tijs van der Storm, CWI Amsterdam, Netherlands Eelco Visser, Delft University of Technology, Netherlands Eric Walkingshaw, Oregon State University, USA Andreas Wortmann, RWTH Aachen University, Germany Vadim Zaytsev, Rain Code, Belgium --------------------------- Contact --------------------------- For additional information, clarification, or answers to questions, please contact the organizers by email: sle2018(a)googlegroups.com.

Feb. 16, 2018