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

[Pharo 7.0-dev] Build #1168: Disabling OSX tests until the slave resucitates
by ci-pharo-ci-jenkins2＠inria.fr Aug. 14, 2018

Aug. 14, 2018

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…

1 0

Is Jenkins OK?
by Alistair Grant Aug. 14, 2018

Aug. 14, 2018

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

4 5

Mustache bug?
by StÃ©phane Ducasse Aug. 14, 2018

Aug. 14, 2018

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

2 2

CfP: Next Generation Programming Paradigms and Systems (NGPS at SAC 2019)
by Nick Papoylias Aug. 13, 2018

Aug. 13, 2018

------------------------------------------------------------------------------- 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

1 0

Esteban's ChangeLog week of 6 August 2018
by estebanlm＠gmail.com Aug. 13, 2018

Aug. 13, 2018

Hello! This is my weekly ChangeLog, from 6 August 2018 to 12 August 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/8/2018&to=12/8/2018 ChangeLog ========= 7 August 2018: -------------- * I've been working on a new ODBC driver for Pharo, made on UFFI and Garage. Sadly, I cannot take the existing older ODBC driver as base because it was depending too much on old FFI structure. Also, it didn't have any test or example so it was hard to take as inspiration (too many differences to tacle). Anyway, the new ODBC driver will come soon(tm), in the mean time I needed to fix some issues on UnifiedFFI: * [case: 22287](https://pharo.fogbugz.com/f/cases/22287) * [case: 22300](https://pharo.fogbugz.com/f/cases/22300) This fixes some missing/incorrect parts on UFFI: first one adds a special handling for +size_t+ types (needed because they behave differently in different platforms/architectures). And the second fixes a problem when returning +enum+ values. cheers! Esteban

1 0

Fwd: [Ann.] Pharo-HDFS API
by Matteo Marra Aug. 11, 2018

Aug. 11, 2018

Hello, I would like to share one of my projects that I am working on in my PhD. Since I am working on Big Data I wrote a library to access the Hadoop Distributed File System (HDFS). We implemented it as a FileSystem in Pharo, using the webHDFS API of HDFS to access the files. With this API you can browse the distributed file system and create/modify/delete directories and files. Here is the git repository: https://gitlab.soft.vub.ac.be/Marra/pharo-hdfs Documentation is in the readme. Ciao, Matteo

2 1

[Pharo 7.0-dev] Build #1167: 22304-vmtarget-pharo-not-found-during-bootstrap
by ci-pharo-ci-jenkins2＠inria.fr Aug. 10, 2018

Aug. 10, 2018

There is a new Pharo build available! The status of the build #1167 was: SUCCESS. The Pull Request #1678 was integrated: "22304-vmtarget-pharo-not-found-during-bootstrap" Pull request url: https://github.com/pharo-project/pharo/pull/1678 Issue Url: https://pharo.fogbugz.com/f/cases/22304 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

debugger "Step Out"
by Ben Coman Aug. 10, 2018

Aug. 10, 2018

A very quick note because its hardly important so I know I'll forget it. Using MSVC recently and jumping back in the Pharo debugger I had a moment when I missing their "Step Out" debugger feature. Probably less important in Pharo where we tend to have shorter methods, and you can always select up the stack and "Step Over", but while I was in-the-flow "Step Out" was what the thing I wanted. Anyway, just sharing the thought. cheers -ben

3 2

Re: [Pharo-dev] [Pharo-users] New Iceberg Version 1.2.1
by Norbert Hartl Aug. 9, 2018

Aug. 9, 2018

> Am 08.08.2018 um 14:12 schrieb Herbert VojÄÃk <herby(a)mailbox.sk>: > > > > Damien Pollet wrote on 8. 8. 2018 13:53: >> First of all, quick stupid question: I'm currently loading my code with gitlocal://./src <gitlocal://./src> as the repository URL (my workflow starts in a terminal rather than in a Pharo image) >> Should I just remove the /src part, now that my repo has the project metadata? >> Also, are more features planned for the .project file? E.g. what about storing a default selection for Calypso and the Test Runner in there? >> On Wed, 8 Aug 2018 at 10:28, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name> <mailto:norbert@hartl.name <mailto:norbert@hartl.name>>> wrote: >> - I donât think there can be a âstandard wayâ of defining source >> directory. And I donât think that a tool should enforce this >> however. I keep frontend and backend code in some repositories >> together so the source is in my case in backend/source. What does it >> mean for users not using the âstandardâ name? >> Sure there can. Look at any ruby or maven project, they all have strong conventions for organizing projects and standard config files for deviating from those conventions. >> I would have preferred if Iceberg picked one convention (arbitrarily) in the absence of a .project file instead of forcing its explicit presence. IMHO the choice of default directory per se (be it ./, ./src, ./source or whatever) matters less than the fact that there is a convention in place. >> - I donât see why there needs to be a 1:1 relationship between a >> repository and working copy in pharo. It is like this at the moment >> already but the .project file manifests this. So it should not be >> supported to have more source dirs in one git repo? It might be not >> a good idea that the client has to write the source dir but it opens >> the possibility that there can be more than one. >> I see your point here, but by using separate source directories you're sort of creating a hydra projectâ¦ What I mean here is that the source directories are separate, but their histories are tangled. If you want separate source dirs it kinda means that you want separate change histories, doesn't it? What if the same class has diverging definitions in separate directories (I wonder what maven does in that caseâ¦)? > > There are monorepos. Some people / companies love them. > One of these companies we know for good. It is google. Google has one (!) repositoryf for all their software. And that is the point I want to stretch here. One repo with one project and a standard source directory is too theoretical and too narrow in thoughts. Today there is no possibility to reliably make one product out of multiple repos. Git submodule and git subtree are not even close to something reliable and usable. Descriptions like metacello are language centric. So what is the most secure way of defining a single product? It is the mono repo. That is the main reason I have my sources in backend/source because there is a javascript frontend in the same repo because I want to have one reliable source that defines my product and I can be sure that the backend and frontend are always the ones that match. I donât think it is a good idea if we once leave the island to embrace something like git just to make git islandish a little later. Just to be very clear. We are talking about two files: .project and .properties. I have nothing against .properties because we have multiple formats possible so making it explicit is a good idea. But .project makes every repo a single source repo. If we enforce .properties files why do we not scan the repo for directories containing this file? If none is found we cannot know (or we add looking at some default locations). If multiple directory are found I can add that to iceberg as a real project out of the combination for repository-source directory. This way I could have multiple projects out of one repo. And with the possibility of having multiple source directories it is obvious that the path still needs to be added to a url in metacello. Unless there is one of this directories marked to be the default which would be loaded if no directory is given. This way the default directory would be the one selected if only one is there. So you can have multiple projects in one repo and if this is only one per project the directory can be automatically resolved. Use case kept. Norbert >> On the other hand, separate source directories would be helpful to work with git-subrepo and similar toolsâ¦ >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet <http://people.untyped.org/damien.pollet>

3 2

New Iceberg Version 1.2.1
by tesonep＠gmail.com Aug. 9, 2018

Aug. 9, 2018

New Iceberg Version 1.2.1 [ https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.0 + https://github.com/pharo-vcs/iceberg/releases/tag/v1.2.1] Thanks to all brave users, issue reporters, and contributors :). This version includes the implementation of projects. Projects are a way of defining basic metadata of the repository. Now, this metadata just includes the source directory. This means that people do not need anymore to provide ALL THE TIME the source directory. Instead, every repository includes a project file that provides it. Iceberg will guide people to create the given file. This file is managed by Iceberg and people should not touch it from the outside or accept the consequences :). This version is integrated in the latest Pharo 7 images. #New Features - #866 Introduce first version of Projects #Infrastructure - #870 Improving tests of Metacello Integration - #903 Split basic tests from metacello tests in CI - #914 Sync Wiki with documentation directory automatically - #934 Manually check metacello integration dialogs - #935 Try to refrite the metacello integration tests. - #940 Installation in new Pharo should also bootstrap pharo repository #Enhancements - #675 The History of a Method in Calypso should show a progress bar. - #788 Show progress during network operations (fetch,push, ...) Libgit. - #875 Tonel plugin does not delete .filetree Migration - #897 Update to OSSubprocess 1.0.1 - #911 Repair Checkout branch should appear in "no project found" - #933 Fix Edit repository dialog - #939 IceInteractiveErrorVisitor duplicates IceTipInteractiveErrorVisitor - #944 Extract pharo repository bootstrap code into iceberg #Bug Fixes - #828 Convert sources to tonel raises an Exception - #839 Infinite loop in IceGitLocalRepositoryType if the path is wrong - #849 VM crash while saving credentials Credential Manager - #851 .properties file is not create if project is imported and not cloned. - #869 Error msg after an http timeout is unreadable - #873 Error with credential provider Credential Manager - #874 The integration with Metacello does not work when there is a src directory, but not project file. - #880 Putting "." in project src field gives dnu - #884 Edit Project Dialog tries to select 'src' folder as default, but does not handle if it does not exists - #886 Edit Project Dialog does not allow to select the root of the repository as source directory - #888 Could not locate repository does not have subdirectory anymore. - #889 Loading an unborn project through metacello does not work - #894 GitHubAPI fails when the API responds with a 204 No Content - #901 I get a DNU projectName.... - #902 Edit project metadata does not detect default format - #918 Cloning pharo from a sync'ed repository does not correctly show dirty packages - #928 Pull request cancel - #930 Changed ivar/slot name in stateful trait not recognized as a change - #931 DNU when trying to unload an Iceberg pkg where underlying Pharo pkg has been removed - #932 Pharo repository forgets packages - #938 Do not catch assertion failures - #941 Iceberg pre-installed repository has wrong repair action - #946 Fixing Metacello Integration Tests - #948 Cloning from github creates an invalid remote - #950 Iceberg v1.2.0 breaks projects Metacello Integration bug - #951 New project window should be coherent on the vocabulary UI enhancement - #953 Make remote request anonymous enhancement - #952 Cannot Clone Pharo Repository Pharo plugin bug - #955 Repair actions for repositories with fetch required are wrong UI bug -- Pablo Tesone. tesonep(a)gmail.com

4 7