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

Pharo Launcher

by Stephane Ducasse

Hi where can I find the pharo launcher for the latest version of Pharo? Stef

June 29, 2017

[CfP][Meta'17] Workshop on Meta-Programming Techniques and Reflection

by Stefan Marr

Call for Papers: Metaâ17 ======================== Workshop on Meta-Programming Techniques and Reflection Co-located with SPLASH 2017 October 22, 2017, Vancouver, Canada Twitter @MetaAtSPLASH http://2017.splashcon.org/track/meta-2017 The heterogeneity of mobile computing, cloud applications, multicore architectures, and other systems leads to increasing complexity of software and requires new approaches to programming languages and software engineering tools. To manage the complexity, we require generic solutions that can be adapted to specific application domains or use cases, making metaprogramming an important topic of research once more. However, the challenges with metaprogramming are still manifold. They start with fundamental issues such as typing of reflective programs, continue with practical concerns such as performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. Thus, while industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript and others, academia still needs to answer a wide range of questions to bring it to the same level of convenience, tooling, and programming styles to cope with the increasing complexity of software systems. This workshop aims to explore meta-level technologies that help tackling the heterogeneity, scalability and openness requirements of emerging computations platforms. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming: - from static to dynamic techniques - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques to minimize runtime overhead - contract systems, or typing of reflective programs reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, and taxonomization of existing approaches In short, we invite contributions to the workshop on a wide range of topics related to design, implementation, and application of reflective APIs and meta-programming techniques, as well as empirical studies and typing for such systems and languages. ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. The workshop papers will be published in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. Therefore, papers are to be submitted using the SIGPLAN acmart style: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex http://www.sigplan.org/sites/default/files/acmart/current/acmart-sigplanpro…) or Word http://www.acm.org/publications/proceedings-template. - technical paper: max. 8 pages, excluding references - position and work-in-progress paper: 1-4 pages, excluding references - technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work. For the submission, please use the submission system at: https://meta17.hotcrp.com/ ### Important Dates Abstract Submission: 07 August 2017 Paper Submission: 14 August 2017 Author Notification: 06 September 2017 Position/WIP Paper Deadline: 08 September 2017 Camera Ready Deadline: 18 September 2017 Position/WIP Notification: 21 September 2017 ### Program Committee The program committee consists of the organizers and the following reviewers: Anya Helen Bagge, University of Bergen, Norway Daniele Bonetta, Oracle Labs, Austria Nicolas Cardozo, Universidad de los Andes, Colombia Sebastian Erdweg, TU Delf, The Nederlands Robert Hirschfeld, HPI, Germany Roberto Ierusalimschy, PUC-Rio, Brazil Pablo Inostroza, CWI, The Nederlands Kim Mens, Universite Catholique de Louvain, Belgium Cyrus Omar, Carnegie Mellon University, USA Guillermo Polito, CNRS, France Tiark Rompf, Purdue University, USA Tom Van Cutsem, Nokia Bell Labs, Belgium Takuo Watanabe, Tokyo Institute of Technology, Japan ### Workshop Organizers Shigeru Chiba, University of Tokyo Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, Johannes Kepler University Linz

June 29, 2017

Anyone in Oslo ?

by Alexandre Bergel

Hi! I am in Oslo for a couple of days. Anyone up for a beer ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 29, 2017

The new implementation of current working directory

by Rajula Vineet

Hi all, As I have already been posting about my GSoC work and updates on my blog <https://vineetreddy.wordpress.com> and on the mailing list <http://forum.world.st/template/NamlServlet.jtp?macro=search_page&node=12947…> . In this post, I would like to go in depth of my work on 'the working directory' so that I can get valuable feedback and suggestions from everyone. This discussion was started on an github PR <https://github.com/pharo-project/pharo/pull/96> which was conflicting my PR. Firstly, I would like to go through the current implementation of the working directory. With this implementation, when you use the defaultWorkingDirectory method, the directory in which the running image is present in, is returned. This is not a completely good working because when you run the image from a different directory like './pharo ../Pharo.image' the working directory is the one in which your image resides. But that isn`t your actual working directory. Due to this, 1. Pharo cannot be installed as a normal application in a read-only environment. 2. Pharo wrongly reads and writes files relative to the 'working directory'. 3. It also makes scripting difficult. In the FogBugz issue here <https://pharo.fogbugz.com/f/cases/5723/Default-Working-Directory> , there is an example which explains the problem. Let say the Pharo VM and Image are in the directory "~/Pharo", and I wrote a script in "~/Documents/Pharo-scripts" called "perfect-numbers.st" I have 2 possibilities: cd ~/Pharo && pharo Pharo.image st ~/Documents/Pharo-scripts/perfect-numbers.st // works or cd ~/Documents/Pharo-scripts && pharo ~/Pharo/Pharo.image st perfect-numbers.st // doesn't work... It doesn't work because when pharo wants to load the file, it tries to locate it with: FileSystem disk workingDirectory !!! which is NOT the current working directory." I hope you get the problem. So for the new implementation <https://github.com/rajula96reddy/pharo-cli> with the help of Guille I researched about $PWD and getcwd() for a while and wrote a new implementation. This is how it goes 1. I have written new methods in OSPlatorm 'getPwdFromFFI' and 'getPwdFromFFIwithsize:'. These call the getcwd() function using the UFFI 2. And a new method currentWorkingDirectoryPath and currentWorkingDirectoryPathWithBufferSize: in OSPlatform which uses the above method and gets the working directory. 3. To integrate this, I have patched the DiskStore method 'defaultWorkingDirectory' to use the new methods in OSPlatform. I have checked all the sendors of the 'defaultWorkingDirectory' for any issue. And I also wrote some unit tests. So, the new implementation is working fine. With this, now I am able to get the right working directory. The example mentioned above works perfectly. But, there may be a few cases where it can break interoperability between Pharo and other Smalltalk dialects like squeak etc. And the 'pharo-local' directory and its methods should also be patched subsequently. In fact, these problems can be tackled by running image from its own directory itself (which is obvious ;) ) or by using the method imageDirectory in FileLocator class explicitly when necessary. But overall a good thing is this is will ensure the system will behave as in other languages. I have completed this implementation and submitted a PR <https://github.com/pharo-project/pharo/pull/92> to github. But because of some dependency issue, it has not yet been merged. With the help of my mentor, I am working on the problem. Thanks for reading all this. Please give your feedback and comments on this new implementation. Your suggestions help me in learning more about the project and also about the organization. Thanks, Rajula -- View this message in context: http://forum.world.st/The-new-implementation-of-current-working-directory-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 29, 2017

Re: [Pharo-dev] Pharo 7 - Method Version Browser does not include author name

by Pavel Krivanek

Yes, this is expected behavior. The metadata-less cypress format does not store method authors and timestamps and because we are bootstrapping from repository in this format, we do not have this information. I hope we will be able to get the method history later from Git. Cheers, -- Pavel 2017-06-29 13:58 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Hi, > > I have just spotted that Pharo 7 does not include names in Method Version > Browser. > > In Pharo 7: > > > In Pharo 6: > > > > Is it an expected behavior? I think it is good to know the developer name > and also the time it was changed. > If there is any error, someone can check when it was changed and who is > the author. > > What do you think? > Juraj > >

June 29, 2017

Pharo 7 - Method Version Browser does not include author name

by Juraj Kubelka

Hi, I have just spotted that Pharo 7 does not include names in Method Version Browser. In Pharo 7: In Pharo 6: Is it an expected behavior? I think it is good to know the developer name and also the time it was changed. If there is any error, someone can check when it was changed and who is the author. What do you think? Juraj

June 29, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60504 Home: https://github.com/pharo-project/pharo-core

June 29, 2017

[pharo-project/pharo-core] 6620fb: 60504

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6620fb9590b2f111b274832b86ab30e560c95f05 https://github.com/pharo-project/pharo-core/commit/6620fb9590b2f111b274832b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-06-29 (Thu, 29 Jun 2017) Changed paths: M CodeExport.package/extension/TClassDescription/instance/fileOutLocalMethodsInCategory_on_.st M Files.package/StdioStream.class/instance/accessing/next_.st M Kernel.package/Context.class/class/simulation/runSimulated_.st M Monticello.package/MCMcdReader.class/instance/loading/loadPatch.st M Monticello.package/MCMczReader.class/instance/loading/loadDefinitions.st M Monticello.package/MCPatch.class/instance/intializing/initializeWithBase_target_.st M Monticello.package/MCVersion.class/instance/enumerating/withAllDependenciesDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60503.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60504.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60503.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60504.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60504 20185 Request pipe after block argments https://pharo.fogbugz.com/f/cases/20185 20183 TraitDescription>>fileOutLocalMethodsInCategory:on: method temp var name overlap https://pharo.fogbugz.com/f/cases/20183 20184 Request space between argument and selector in StdioStream>>next: https://pharo.fogbugz.com/f/cases/20184 http://files.pharo.org/image/60/60504.zip

June 29, 2017

Early Pull Request Validation Process

by Guillermo Polito

Hi all, As some/a lot of you have been asking how to contribute, I'm here to answer some questions :). First of all, integrating fixes in Pharo has been "slowed down" because we missed the Monkey for Pull Request (PR) integration. Some of you have seen a travis job going around and checking. That was our initial solution, but it has a main issue for us: it only works for unix because our build process is long, uses lots of small files due to file tree and osx travis support is REALLY SLOW with I/O access. This is why we chose to use good old Jenkins. https://ci.inria.fr/pharo-ci-jenkins2/ # Why it took so much time Just some explanation of why it took so much time (you can skip this if you're not interested). I started working on integrating Jenkins with Pull Requests several weeks ago (note that I'm part time on this, also working in other projects and the deadlines of the past weeks like IWST were killing my time). We have now a new and working Jenkins server for Pharo7. This jenkins server is hosted in Inria, its url being - We chose to use Jenkins 2 because I managed to make the PR integration plugin work only in Jenkins 2. - This required the creation of a new jenkins server + slaves. The pharo and pharo-contribution servers run with Jenkins 1.6 and I did not want to migrate existing servers to not break existing jobs. - At the same moment, the inria CI infrastructure was having some (lots?) of hiccups because of storage limitations. I spent several weeks to create the running slaves for each platform and connect jenkins to them because of that. - Finally, I spent some time to test the new Jenkins MultiJobs. These kind of jobs allow to split a single job in sequential phases. And each phase can have multiple jobs that run concurrently. This allows us to bootstrap once (on unix) and test in all platforms. An example of the new multijob can be found here: https://ci.inria.fr/pharo-ci-jenkins2/job/Pharo-PullRequest-Pipeline/ # Current Design Right at this moment, we are validating PRs using Jenkins. The process is as follows: 1) Github notifies about changes in PRs to Jenkins using webhooks. So far, we have configured it to notify about PR changes (including comments) and normal pushes (to capture merges into the #development branch). 2) Upon the reception of a GH notification, Jenkins will launch two jobs/validations. The basic structure of both validations is the same so far. Bootstrap once (unix) and test in many platforms. There are the following two test configurations however. 2.1) Full Validation: tests 32 and 64 bits, for linux, osx and windows. This configuration is not fully working right now because we found a VM bug in 64 bits that prevents us from creating a full pharo image. Bootstrap is Ok, but there is a segfault when loading a big Metacello configuration. 2.2) Basic Validation: tests only 32 bits, for now in linux and osx (I'm planning to do windows today). This validation is to give us nevertheless a feedback of the build even if the full is failing so far. 2.3) Others? We could easily add new validations to run some faster tests i.e., just loading a patch on the previous image. 3) Jenkins takes control and notifies Github So far, Full validation is failing, and I plan to keep it running until it gets green. I don't care if it's red right now, the idea is that we should fix it, and we should remember it is broken :). On the other hand, the Basic Validation is working and running tests. Once the tests runs are finished, Github PR state will be either a success (if all tests went green) or a failure (if it failed or some tests failed). You will see actually a message saying: Validation Failure. Please check test results. 7782 tests run, 0 skipped, 6 failed. + a link to jenkins if you want to inspect results. You can see an example of it in action in here: https://github.com/pharo-project/pharo/pull/119 # Next points Right now we are missing: - Fogbugz integration - Publish new images in the file server when a push/merge happens in the #development branch (I should sit today with Esteban to do some ssh key configuration in a server I have no access to) - fixing the failing tests => TO HAVE A GREEN BUILD> :D - Enhance tests? - your enhancement idea :) The current validation already gives us an idea of what works and what does not work, what breaks the bootstrap, and if we have failing tests or not. I'd like however that before integrating a fix, there is at least 2 people that look at it and put a +1. Because Monkey validation and the ability to merge does not mean much actually :). If you have some questions, enhancements, there is this thread, there is the #bootstrap channel in discord also. Guille (in behalf of everybody that helped me with this) -- Guille Polito Research Engineer 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

June 29, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Stephane Ducasse

Thanks for all your positive energy. Your return of experience on the new tools is great too. I experienced some glitches but this is getting really better and open a lot of possibilities. On Wed, Jun 28, 2017 at 4:49 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 27 Jun 2017, at 14:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> P3 is a modern, lean and mean PostgreSQL client for Pharo. >> >> P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. >> >> With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. >> >> More info, usage examples and code at https://github.com/svenvc/P3 >> >> P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. >> >> This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. > > I made the code easier to load. > > The default group loads P3Client and its basic dependencies NeoJSON and ZTimestamp > > Metacello new > baseline: 'P3'; > repository: 'github://svenvc/P3'; > load. > > The glorp group loads P3DatabaseDriver and the whole of Glorp (warning: large download) > > Metacello new > baseline: 'P3'; > repository: 'github://svenvc/P3'; > load: 'glorp'. > >> Sven >> >> PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! >> > >

June 29, 2017