Dear World,
Pharo 3.0 (http://www.pharo.org) is here.
The past year seemed short as we got busy building more than usual. Many things have changed in Pharo. Here are the highlights:
- The new modular Opal compiler is now the default compiler used in the system.
- The Athens vector graphics canvas is now integrated and it supports Cairo rendering on all platforms.
- Many tools have been rewritten using Spec, a new framework for building user interfaces.
- Versionner and Kommiter are two of the new development tools.
- RPackage, a new package mechanism got enhanced with tags and is fully integrated in the system.
- The debugger model was rewritten to become modular, the inspector received a bump to support multiple views, and the Nautilus code browser supports tags, search and lot more improvements.
- Morphic has seen many cleanings and improvements and the visual theme has been revamped.
These are just the more prominent highlights, but the details are just as important. We have closed 2364 issues in Pharo 3 (compared with 1727 issues in Pharo 2). Take a moment to go through a more detailed recount of the progress:
https://github.com/pharo-project/ChangeLogs/blob/master/Pharo30ChangeLogs.md
Pharo is improving on many fronts. Just take a look at the code city of Pharo (built with Pharo for Pharo). Every building is a class, and the red bricks represent the modified methods in Pharo 3.
Many things are changing but the system gets more stable. Moving from Pharo 2 to Pharo 3 is almost a matter of just loading the code.
Remember that Pharo is your platform. We thank all the contributors of this release: Jean-Baptiste Arnaud, Simon Allier, Philippe Back, Clément Bera, Alexandre Bergel, Torsten Bergmann, Usman Bhatti, Vincent Blondeau, Noury Bouraqadi, Johan Brichau, Camillo Bruni, Sven Van Caekenberghe, Damien Cassou, Nicolas Cellier, Guido Chari, Dimitris Chloupis, Bernardo Contreras, Ben Coman, Gabriel Omar Cotelli, Jordi Delgado, Tommaso Del Sasso, Gisela Decuzzi, Christophe Demarey, Sean DeNigris, Marcus Denker, Martin Dias, Erwan Douaille, Stephane Ducasse, Stephan Eggermont, Pablo Estefo, Luc Fabresse, Johan Fabry, Hilaire Fernandes, Nahuel Garbezza, Leo Gassman, Lucas Giudice, Tudor Girba, Thierry Goubier, Norbert Hartl, Dale Henrichs, Pablo Herrero, Nicolai Hess, Andre Hora, Alejandro Infante, Ricardo Jacas, Henrik Sperre Johansen, Denis Kudryashov, Pavel Krivanek, Juraj Kubelka, Laurent Laffont, Jannik Laval, Max Leske, David Lewis, Diego Lont, Esteban Lorenzano, Stefan Marr, Mariano Martinez Peck, Roberto Minelli, Hernan Morales Durand, Eliot Miranda, Fernando Olivero, Nicolas Papagna Maldonado, Nick Papoylias, Nicolas Passerini, Vanessa Peña, Nicolas Petton, Alain Plantec, Guillermo Polito, Damien Pollet, Jochen Rick, Benjamin Van Ryseghem, Ronie Salgado, Camille Teruel, Juan Pablo Sandoval Alcocer, Samir Saleh, Frank Shearar, Igor Stasenko, Aliaksei Syrel, Sebastian Tleye, Yuriy Tymchuk, Andres Valloud, Martin Walk, Hernan Wilkinson.
And many many more who contributed indirectly, by reporting bugs, participating in discussion threads, providing feedback...
Pharo 3.0 is the largest step we took since we started. Yet, it’s just a step. Expect more. Much more.
Enjoy!
The Pharo Team
Hi all,
Now that I am starting to use Pier, I notice several things:
1. The current version of Pier has become a bit unstable. The bugs I have found so far are:
- The default installation no longer requires you to be logged in to change content. This is because the owner is no longer set by default.
- The default installation no longer allows you to select a template.
I do not know how much this has to do with the work Damien is doing, but the question arises: who are currently the core team of Pier?
2. The website of Pier is outdated. It still refers to Pier2, the repository of Lucas Renggli, some new add-ons are missing, and several links to examples are no longer working.
3. Also Pier itself could use some new input. I am thinking about a bootstrap packages, that adds a bootstrap template, and allows to add bootstrap components, like a jumbotron, to be added easily, without having to resort to “verbatim”. And maybe there are other things that are missing too.
I am willing to do some work, as I am now using Pier for my website, but I don’t think I can do it without help.
Stephan and I already did some work on the code exporter, so has become more easy:
- to migrate a Pier site to the current version
- to develop Pier local, and deploy Pier remote.
We should probably add a screen cast and installation scripts, but then: who will put it on the Pier website?
So who is using Pier also and wants to help get it up to date?
Cheers,
Diego
Magritte is rather stable. The original papers by Lukas are fine.
The move from class-side to instance side of descriptions was
the most important change. The QCMagritte presentation might be useful
for understanding Magritte.
Stephan
All,
is there a common pattern to model object revision with Magritte? I need
to track historical changes to an object (and maybe undo changes). I'm
wondering whether there is something like a pattern as I think I
remember Pier storing page revisions as well.
Any pointers?
Thanks,
Udo
Hi all,
Stephan and I have been working on the release management, as this was giving trouble. I did not receive very much feed back, so either most of you all agreed to my proposal, or you did not care. I will assume the first.
I have added to Grease several symbolic version: release1, release1.0 and release1.1. The idea is that for all released versions there is a version that skips the last index and is the version with the highest version number that belongs to that.
Since there is a version “1.1.7” that is currently stable, this means there is a release 1.1 and 1. Also I made from the stable version “1.0.11” release 1.0
Following this logic in Seaside, Magritte and Pier, I have updated all versions, creating a release 3.0 and release 3.1. For Pier this is not 100% correct, as 3.1 isn’t a release yet. So maybe I should have sticked to development here … for this
- I have added a new stable version (as release version should not be changed)
- In this release version I reference the release versions of the used projects. This should allow patches to be easily adopted, as there will be included in the release, and will prevent breaking on an major upgrade with deprecations and such.
For now this results in a green build for Pier again.
Cheers,
Diego
Sergi wrote:
> The builds downloaded from CI have a bunch of issues, like showing the commands even to non-logged users,
That happens when pages have a nil owner. If you set the owner to the admin user recursively down from root,
the problem is gone. Anyone know a good place to set that by default?
Stephan
You can describe issues here on the list or on our issue tracker:
https://code.google.com/p/pier/issues/list
Pharo contributions CI creates 4 different images.
It helps to know if the problem is in one or all four.
And having issues as separate mails helps focus.
The issues we found with Pier3 on Pharo3 were
not difficult to solve. Mostly replacing deprecated and removed
functionality (FileSystem, WARenderCanvas)
Stephan
