August 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1174: 22315-remove-implicit-requirement-from-traits

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1174 was: SUCCESS. The Pull Request #1686 was integrated: "22315-remove-implicit-requirement-from-traits" Pull request url: https://github.com/pharo-project/pharo/pull/1686 Issue Url: https://pharo.fogbugz.com/f/cases/22315 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

[Pharo 7.0-dev] Build #1173: 22314-Stdio-doesnt-handle-cygwin-terminals-correctly

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1173 was: FAILURE. The Pull Request #1684 was integrated: "22314-Stdio-doesnt-handle-cygwin-terminals-correctly" Pull request url: https://github.com/pharo-project/pharo/pull/1684 Issue Url: https://pharo.fogbugz.com/f/cases/22314 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

Re: [Pharo-dev] Association hash vs equality

by Guillermo Polito

Actually, #= and #hash should be defined so: if (a=b) then a hash = b hash if a != b, it's not important This is required because some collections (like sets, dictionaries) will index their elements by their hash. Then, typically the collection implementation will first ask the hash, access the index with it, and retrieve the object if it is = only. Notice that several objects can have the same hash but be equals nonetheless. On Thu, Aug 16, 2018 at 11:36 AM Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > Hello, I've been looking at implementation of Associtation and LookupKey > (its > superclass). > In LookupKey, there is LookupKey>>#= and LookupKey>>#hash both implemented > to use key (compare keys and use hash of key), but in Association, > Association>>#= compares both key and value, but hash is not changed there, > so only hash of key is used, therefore it does not correspond to > implementation of method = ... shouldn't it? > > To demonstrate: > (1 -> #a) = (1 -> #b). > is false but > (1 -> #a) hash = (1 -> #b) hash. > is true > > I also noticed similar discussion for Doplhin smalltalk > http://forum.world.st/Association-gt-gt-hash-td3368868.html where guys > state > it is all right, but I still do not see why. > > Jan > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- 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

Aug. 16, 2018

Association hash vs equality

by Jan BlizniÄenko

Hello, I've been looking at implementation of Associtation and LookupKey (its superclass). In LookupKey, there is LookupKey>>#= and LookupKey>>#hash both implemented to use key (compare keys and use hash of key), but in Association, Association>>#= compares both key and value, but hash is not changed there, so only hash of key is used, therefore it does not correspond to implementation of method = ... shouldn't it? To demonstrate: (1 -> #a) = (1 -> #b). is false but (1 -> #a) hash = (1 -> #b) hash. is true I also noticed similar discussion for Doplhin smalltalk http://forum.world.st/Association-gt-gt-hash-td3368868.html where guys state it is all right, but I still do not see why. Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Aug. 16, 2018

[Pharo 7.0-dev] Build #1172: 22307-Refactoring-doesnt-work-in-debugger---Walkback-dnu-contentSelection

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1172 was: FAILURE. The Pull Request #1680 was integrated: "22307-Refactoring-doesnt-work-in-debugger---Walkback-dnu-contentSelection" Pull request url: https://github.com/pharo-project/pharo/pull/1680 Issue Url: https://pharo.fogbugz.com/f/cases/22307 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

[Pharo 7.0-dev] Build #1171: 22312-Integrate-Iceberg-v122

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1171 was: SUCCESS. The Pull Request #1682 was integrated: "22312-Integrate-Iceberg-v122" Pull request url: https://github.com/pharo-project/pharo/pull/1682 Issue Url: https://pharo.fogbugz.com/f/cases/22312 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 16, 2018

Re: [Pharo-dev] Collection groupedBy: and groups order

by Damien Pollet

The problem is, there isn't really an order to preserve in the first place, since even if the original collection is a sequencable one, the elements of each group would be interleaved in it. I could see the point of sorting the keys though. On Tue, 14 Aug 2018 at 18:32, Petr Fischer via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Hello, I found a useful method in the collection - groupedBy: - the result > container is some PlugableDictionary (integer variant) and group order > (keys) is not preserved. > > Would not it be better to choose some other Dictionary variant, which > preserve the order of groups (like in source Collection)? > > pf > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Aug. 15, 2018

[Pharo 7.0-dev] Build #1170: 22137-gif-read-writer-refactoring-and-animated-images

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1170 was: FAILURE. The Pull Request #1666 was integrated: "22137-gif-read-writer-refactoring-and-animated-images" Pull request url: https://github.com/pharo-project/pharo/pull/1666 Issue Url: https://pharo.fogbugz.com/f/cases/22137 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 15, 2018

[Pharo 7.0-dev] Build #1169: Revert "Disabling OSX tests until the slave resucitates"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1169 was: SUCCESS. The Pull Request #1688 was integrated: "Revert "Disabling OSX tests until the slave resucitates"" Pull request url: https://github.com/pharo-project/pharo/pull/1688 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 14, 2018

ZnHeaders should allow custom or empty Server info

by Torsten Bergmann

Hi Sven, when running a Zinc Server ZnServer startDefaultOn: 8080. the server currently reveals the framework, the framework version and the Pharo version the server is running on as part of the HTTP communication. For instance (ZnEasy get: 'http://localhost:8080') headers at: 'Server' would give Zinc HTTP Components 1.0 (Pharo/7.0) in the Server Header. While this is nice for debugging and during development this can be a problem in more secured/pentested environments where usually specific headers are turned off to not give specific informations to an attacker (to allow him to find vulnerabilities of specific versions or servers). While headers could be changed rewritten in front-ends or load balancing servers we can not assume that Pharo images work as backend server always. Webservers like Nginx, Apache, IIS, Express in JS, PHP and other allow to disable/modify these headers. Using the attached changeset it is possible to modify the Server header and customize it: ZnHeaders serverString: 'MoreSecureServer' If the server string is not customized the default server string is used as before. We should make sure this is integrated into Pharo 7 but also into the Zinc framework. I opened a bug https://pharo.fogbugz.com/f/cases/22317/ZnHeaders-should-allow-custom-or-em… As Zinc is also managed externally how should we proceed? Thx T.

Aug. 14, 2018

Collection groupedBy: and groups order

by Petr Fischer

Hello, I found a useful method in the collection - groupedBy: - the result container is some PlugableDictionary (integer variant) and group order (keys) is not preserved. Would not it be better to choose some other Dictionary variant, which preserve the order of groups (like in source Collection)? pf

Aug. 14, 2018

ZnHTTPSTests and more CI trouble

by Torsten Bergmann

Latest build fails with #testGetPharoVersion when run manually because this Test is calling https://ci.inria.fr/pharo/job/Pharo-6.0/lastSuccessfulBuild/api/xml?xpath=/… currently returning an error.

Aug. 14, 2018

[Pharo 7.0-dev] Build #1168: Disabling OSX tests until the slave resucitates

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1168 was: FAILURE. The Pull Request #1687 was integrated: "Disabling OSX tests until the slave resucitates" Pull request url: https://github.com/pharo-project/pharo/pull/1687 Issue Url: https://pharo.fogbugz.com/f/cases/Disabling Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Aug. 14, 2018

Re: [Pharo-dev] Is Jenkins OK?

by Guillermo Polito

Thanks Torsten. Builds should be working now, though unstable. We are experiencing several other issues with the CI regarding permissions and so. We have open a ticket in the ci-support app and we are waiting for their answer. On Tue, Aug 14, 2018 at 11:20 AM Torsten Bergmann <astares(a)gmx.de> wrote: > For future reference: https://github.com/pharo-project/pharo/pull/1687 > > *Gesendet:* Dienstag, 14. August 2018 um 10:45 Uhr > *Von:* "tesonep(a)gmail.com" <tesonep(a)gmail.com> > *An:* Pharo-dev <pharo-dev(a)lists.pharo.org> > *Betreff:* Re: [Pharo-dev] Is Jenkins OK? > I am disabling the testing on OS X until the slave come back from the > grave!! > > So we can continue working! > > Cheers. > > On Tue, Aug 14, 2018 at 10:03 AM Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> On Tue, 14 Aug 2018 at 09:59, Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >> > >> > Nope, the osx slave is down since yesterday. >> > https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/ >> > >> > I've been trying to restart it but no luck so far... >> > I'll keep you updated. >> >> >> Thanks, Guille! >> >> Cheers, >> Alistair >> >> >> > >> > >> > On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant <akgrant0710(a)gmail.com> >> wrote: >> >> >> >> I have a PR that has been running for over 13 hours... >> >> >> >> >> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… >> >> >> >> (if there's something I can do about this myself instead of annoying >> >> the list, please let me know) >> >> >> >> Thanks, >> >> Alistair >> >> >> > >> > >> > -- >> > >> > >> > >> > 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 >> > >> > >> > Web: http://guillep.github.io >> > >> > Phone: +33 06 52 70 66 13 >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com > -- 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

Aug. 14, 2018

Re: [Pharo-dev] Is Jenkins OK?

by Torsten Bergmann

Aug. 14, 2018

Re: [Pharo-dev] Is Jenkins OK?

by tesonep＠gmail.com

I am disabling the testing on OS X until the slave come back from the grave!! So we can continue working! Cheers. On Tue, Aug 14, 2018 at 10:03 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > On Tue, 14 Aug 2018 at 09:59, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > > > Nope, the osx slave is down since yesterday. > > https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/ > > > > I've been trying to restart it but no luck so far... > > I'll keep you updated. > > > Thanks, Guille! > > Cheers, > Alistair > > > > > > > > On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> > >> I have a PR that has been running for over 13 hours... > >> > >> > https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… > >> > >> (if there's something I can do about this myself instead of annoying > >> the list, please let me know) > >> > >> Thanks, > >> Alistair > >> > > > > > > -- > > > > > > > > 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 > > > > > > Web: http://guillep.github.io > > > > Phone: +33 06 52 70 66 13 > > -- Pablo Tesone. tesonep(a)gmail.com

Aug. 14, 2018

Re: [Pharo-dev] Mustache bug?

by StÃ©phane Ducasse

Hello Norbert >> >> In pillar we needed variable lookup with Mustache so we used a https://github.com/Ducasse/Containers-PropertyEnvironment <https://github.com/Ducasse/Containers-PropertyEnvironment> >> instead of a simple dictionary. >> > thanks. Do I understand it correctly that the user has to build nested structured manually with the PropertyEnvironment? I started to do something similar to PropertyEnvironment but only as a wrapper to the value object plus parent reference. Iâm trying to make this purely > internal. In fact we did not want to modify mustache nor to fork it but the good solution would be that mustache use property environment internally instead of a dictionary and that this look up is hidden from the client. If you go that road let me know if I should enhance the API of CTEnvironment. Originally I developed it more as a lispish environment and less as a dictionary but Iâm unifying the API (using internally an OrderedDictionary to support some traversal order). I should add addAll: for example Stef > > Norbert >> Notice that https://github.com/Ducasse/Containers-PropertyEnvironment <https://github.com/Ducasse/Containers-PropertyEnvironment> has 100% test coverage. >> >> Stef >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> >> http://www.synectique.eu <http://www.synectique.eu/> / http://www.pharo.org <http://www.pharo.org/> >> 03 59 35 87 52 >> Assistant: Julie Jonas >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 14, 2018

Re: [Pharo-dev] Is Jenkins OK?

by Alistair Grant

On Tue, 14 Aug 2018 at 09:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Nope, the osx slave is down since yesterday. > https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/ > > I've been trying to restart it but no luck so far... > I'll keep you updated. Thanks, Guille! Cheers, Alistair > > > On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> I have a PR that has been running for over 13 hours... >> >> https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… >> >> (if there's something I can do about this myself instead of annoying >> the list, please let me know) >> >> Thanks, >> Alistair >> > > > -- > > > > 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 > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13

Aug. 14, 2018

Re: [Pharo-dev] Is Jenkins OK?

by Guillermo Polito

Nope, the osx slave is down since yesterday. https://ci.inria.fr/pharo-ci-jenkins2/computer/pharo-ci-jenkins2-osx/ I've been trying to restart it but no luck so far... I'll keep you updated. On Tue, Aug 14, 2018 at 7:49 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > I have a PR that has been running for over 13 hours... > > > https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… > > (if there's something I can do about this myself instead of annoying > the list, please let me know) > > Thanks, > Alistair > > -- 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

Aug. 14, 2018

Re: [Pharo-dev] Mustache bug?

by Norbert Hartl

Steph, > Am 13.08.2018 um 18:45 schrieb StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > Hi > > In pillar we needed variable lookup with Mustache so we used a https://github.com/Ducasse/Containers-PropertyEnvironment > instead of a simple dictionary. > thanks. Do I understand it correctly that the user has to build nested structured manually with the PropertyEnvironment? I started to do something similar to PropertyEnvironment but only as a wrapper to the value object plus parent reference. Iâm trying to make this purely internal. Norbert > Notice that https://github.com/Ducasse/Containers-PropertyEnvironment has 100% test coverage. > > Stef > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza > Villeneuve d'Ascq 59650 > France >

Aug. 14, 2018

Is Jenkins OK?

by Alistair Grant

I have a PR that has been running for over 13 hours... https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… (if there's something I can do about this myself instead of annoying the list, please let me know) Thanks, Alistair

Aug. 14, 2018

Re: [Pharo-dev] Minheadless trial

by Ben Coman

Hi Ronie, Esteban, Could you do a quick review of my CMakeLists.txt change for any obvious blunder. This may be my last post on this thread for a short while. On 8 August 2018 at 21:39, Ben Coman <btc(a)openinworld.com> wrote: > > Well thats enough for one post! > Success running a MSVC compiled Spur Stack "minheadless" VM. > > Next I'll try... option(COG_JIT "Cog JIT" ON) > I did that, and then... "CMakeLists.txt > Cache(x64-Debug only) > Delete cache folder..." "CMake > Build All" then started "x64-Debug" , "pharo.exe minImage+eval" and a console window opens that reports... "linking callsite to invalid address" Well I'm not sure how ready is the Windows 64bit JIT is, so lets try with 32bit JIT. In VS selecting "x86-Debug" , "pharo.exe minImage+eval" and "Cmake > Build All" reports... "Severity Code Description Project File Line Suppression State Error C1189 #error: As yet no Cogit implementation appears to exist for your platform. C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\ IDE\CMakeLists.txt C:\#Repos\OpenSmalltalk\opensmalltalk-vm\spur64src\vm\ cogit.c In the CMake variables SourceFolderName=spur64src because.. VM_64BITS=TRUE which is set here... if(SQUEAK_PLATFORM_X86_64) if(BUILD_I386_VERSION) set(SQUEAK_PLATFORM_X86_32 True) set(SQUEAK_PLATFORM_X86_64 False) else() set(VM_64BITS TRUE) set(SourceFolderName "${SourceFolderName}64") if(WIN32) set(FFI_VARIANT_X64_WIN64 True) else() set(FFI_VARIANT_X64_SYSV True) endif() set(VM_TARGET_CPU "x86_64") endif() else() set(VM_64BITS False) endif() which I'm not clear how that logic works, since it seems BUILD_I386_VERSION doesn't prevent VM_64BITS=True Rearranging like... if(BUILD_I386_VERSION) set(SQUEAK_PLATFORM_X86_32 True) set(SQUEAK_PLATFORM_X86_64 False) set(VM_64BITS False) else() endif() if(SQUEAK_PLATFORM_X86_64) set(VM_64BITS TRUE) set(SourceFolderName "${SourceFolderName}64") if(WIN32) set(FFI_VARIANT_X64_WIN64 True) else() set(FFI_VARIANT_X64_SYSV True) endif() set(VM_TARGET_CPU "x86_64") else() endif() then adding -DBUILD_I386_VERSION in "CmakeSettings.json" like this... "CMakeLists.txt > Change Cmake Settings" { "name": "x86-Debug", "generator": "Ninja", "configurationType": "Debug", "inheritEnvironments": [ "msvc_x86" ], "buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\ \build\\${name}", "installRoot": "${env.USERPROFILE}\\ CMakeBuilds\\${workspaceHash}\\install\\${name}", "cmakeCommandArgs": "-DBUILD_I386_VERSION=ON", "buildCommandArgs": "-v", "ctestCommandArgs": "" }, then refreshing... "CMakeLists.txt > Cache(x64-Debug only) > Delete cache folder..." "CMake > Build All" leaves these values in the Cmake variables... VM_64BITS=False SourceFolderName=spursrc and the build completes successfully. I'm leaving it there for the moment. Actually the above sat in unchanged in draft for a week since I've had to shift my attention to something else. Modifications to date here... https://github.com/bencoman/opensmalltalk-vm/tree/MinimalisticHeadless-x64-… Next would be to catch up to Esteban's branch... https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm cheers -ben

Aug. 14, 2018

Mustache bug?

by StÃ©phane Ducasse

Hi In pillar we needed variable lookup with Mustache so we used a https://github.com/Ducasse/Containers-PropertyEnvironment <https://github.com/Ducasse/Containers-PropertyEnvironment> instead of a simple dictionary. Notice that https://github.com/Ducasse/Containers-PropertyEnvironment <https://github.com/Ducasse/Containers-PropertyEnvironment> has 100% test coverage. Stef -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 13, 2018

A new rule to implement in Pharo ?

by Lionel Akue

Hello, Do you have a rule you would like to get implement in Pharo? I am reading about Renraku and I would like to exercise. Thanks, Lionel

Aug. 13, 2018

CfP: Next Generation Programming Paradigms and Systems (NGPS at SAC 2019)

by Nick Papoylias

------------------------------------------------------------------------------- Next Generation Programming Paradigms and Systems (NGPS 2019) Track of the 34th ACM/SIGAPP Symposium On Applied Computing Limassol, Cyprus https://ngps2019.github.io/ ------------------------------------------------------------------------------- AIMS AND TOPICS The complexity of modern software systems is continuously growing together with the communication capabilities and computational power of pervasive technology, embodied by a wide range of interacting heterogeneous smart devices. This new scenario is posing serious challenges to software development, which hardly keeps pace with this technological evolution. Sophisticated frameworks exposed through application programming interfaces, or directly integrated with mainstream programming languages provide partial solutions to support big data streaming and complex analytic; dynamic, autonomous, and collective coordination and adaptation capabilities; emergent behavior in cooperating systems; Internet of Things (IoT) systems development and maintenance; and employment of cloud platforms and parallel architectures, in particular heterogeneous ones. This calls for new abstractions, features, middlewares and tools able to reduce the time, effort, and cost of designing and developing the next generation software systems, improving performance, and ensuring reliability and security. To this aim, NGPS is seeking to advance the state-of-the-art and the state-of-the-practice of computational models and paradigms, formal techniques and software methods for easing software development and verification, and improving efficiency of complex modern systems. The specific topics of interest for the NGPS track include, but are not limited to, the following: - Integration of computational paradigms - Runtime verification and monitoring - Platforms for the Cloud - IoT systems - Secure and dependable software - Formal models and verification - Testing and debugging - System evaluation - Design, implementation and optimization of high-level programming languages - Middleware platforms - Scenarios, case studies and experience reports on innovative applications - High-level parallel programming - Distributed systems and concurrency - Development tools - Coordination models, specification, and technologies - Multi-agent systems, mobile agents, intelligent agents, and agent-based simulations - Models, frameworks and tools for Collective Adaptive Systems - Internet, Web, and pervasive computing systems - Self-organizing, self-adaptive, context-aware and nature-inspired systems - Security, trust and privacy management SUBMISSIONS Prospective papers should be submitted to the track in pdf format using the START submission system for regular and SRC papers available through the SAC 2019 home page. Submission of the same paper to multiple tracks is not allowed; all papers should represent original and previously unpublished works that are currently not under review in any conference or journal. Both basic and applied research papers are welcome. SAC 2019 will use double-blind reviewing; to facilitate this, author name(s) and institution(s) must be omitted, and references to authorsâ own related work should be in the third person. The format of the paper must adhere to the sig-alternate style. Full papers are limited to 8 pages, in camera-ready format, included in the registration fee. Authors have the option to include up to two (2) extra pages at additional fee of US$80 per page. Papers accepted as posters are limited to 3 pages, in camera-ready format, included in the registration fee. Authors have the option to include only one (1) extra page at additional fee of US$80. SRC abstracts are limited to 4 pages, in camera-ready format, included in the registration fee. No extra pages are allowed. Accepted papers will be published by ACM in the annual conference proceedings. Accepted posters will be published as extended abstracts in the same proceedings. Papers that fall short the above requirements are subjected to rejection. All papers must be submitted by September 10, 2018. For more information please visit the SAC 2019 home page. Paper registration is required, allowing the inclusion of the paper/poster in the conference proceedings. An author or a proxy attending SAC MUST present the paper: This is a requirement for the paper/poster to be included in the ACM/IEEE digital library. No-show of scheduled papers and posters will result in excluding them from the ACM/IEEE digital library. DEADLINES Sept 10, 2018 Submission of regular papers and SRC research abstracts Nov 10, 2018 Notification of paper acceptance/rejection Nov 10, 2018 Notification of SRC acceptance/rejection Nov 25, 2018 Camera-ready copies of accepted papers/SRC Dec 10, 2018 Author registration due date April 8-12, 2019 ACM SAC Conference TRACK CO-CHAIRS Davide Ancona, DIBRIS, University of Genova, IT Frederic Loulergue, SICCS, Northern Arizona University, USA Danilo Pianini, DISI, University of Bologna, IT Mirko Viroli, DISI, University of Bologna, IT PROGRAM COMMITTEE (to be completed) Mohamad Al Hajj Hassan, Huawei, DE Lorenzo Bettini, DISIA, University of Florence, IT HÃ©lÃ¨ne Coullon, IMT Atlantique, Inria, FR Ferruccio Damiani, DI, University of Torino, IT Simon Dobson, CS, University of St Andrews, UK Kento Emoto, IPL-Lab, Kyushu Institute of Technology, JP Erik Ernst, Google Inc., USA Lukas Esterle, ALICE, Aston University, UK FrÃ©dÃ©ric Gava, LACL, UniversitÃ© Paris-Est CrÃ©teil, FR Robert Hirschfeld, HPI, University of Potsdam, DE Jaakko JÃ¤rvi, II, University of Bergen, NO Einar Broch Johnsen, UiO, University of Oslo, NO Khaled Hamidouche AMD Research, USA Geoff Hamilton, School of Computing, Dublin City University, IE Hideya Iwasaki, The University of Electro-Communications, JP Doug Lea, CS, University of New York at Oswego Michele Loreti, DI, University of Camerino, IT Alberto Lluch Lafuente, DTU COMPUTE, Technical University of Denmark, DK Hidehiko Masuhara, PRG, Tokyo Institute of Technology, JP Virginia Niculescu, CS, Babes-Bolyai University of Cluj-Napoca, RO Nick Papoulias, University of La Rochelle, UMR LIENSs, CNRS, FR AntÃ³nio Ravara, DI FCT, New University of Lisbon, PT Barbara Re, SST, University of Camerino, IT Sophie Robert, LIFO, University of OrlÃ©ans Stefan Rudolph, OC, Augsburg University, DE Maurice ter Beek, FMT-ISTI, CNR, IT Martin Wirsing, SoSy-Lab, LMU Munich, D

Aug. 13, 2018