- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #428: 20921 PackageChecker>>check not needed anymore
by ci-pharo-ci-jenkins2＠inria.fr Jan. 16, 2018

Jan. 16, 2018

There is a new Pharo build available! The status of the build #428 was: FAILURE. The Pull Request #679 was integrated: "20921 PackageChecker>>check not needed anymore" Pull request url: https://github.com/pharo-project/pharo/pull/679 Issue Url: https://pharo.fogbugz.com/f/cases/20921 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #427: 20970 remove pharo 6 platform class from pharo 7
by ci-pharo-ci-jenkins2＠inria.fr Jan. 16, 2018

Jan. 16, 2018

There is a new Pharo build available! The status of the build #427 was: FAILURE. The Pull Request #682 was integrated: "20970 remove pharo 6 platform class from pharo 7" Pull request url: https://github.com/pharo-project/pharo/pull/682 Issue Url: https://pharo.fogbugz.com/f/cases/20970 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[Pharo 7.0-dev] Build #426: 20971 - Class comment and method format fixes
by ci-pharo-ci-jenkins2＠inria.fr Jan. 16, 2018

Jan. 16, 2018

There is a new Pharo build available! The status of the build #426 was: SUCCESS. The Pull Request #683 was integrated: "20971 - Class comment and method format fixes" Pull request url: https://github.com/pharo-project/pharo/pull/683 Issue Url: https://pharo.fogbugz.com/f/cases/20971 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[ann] gt connector
by Tudor Girba Jan. 15, 2018

Jan. 15, 2018

Hi, Towards the end of last year we worked on GT Connector, a new kind of interface that allows us to exercise and test the limits (or the lack thereof) of Bloc. It looks like this: You can see it in action here: https://twitter.com/feenkcom/status/936109463462965248 In the current implementation, the Connector allows us to navigate and connect example methods. The focus is not on examples, but on the connections. We used examples because the engine was already around and offered us a nice use case. We want to extend it in the near future to other kinds of objects. There are a couple of things that are worth noting: â¢ The editor works live, and the connection points appear and disappear as you type. â¢ The layout of the editor elements is based on a tree-based graph layout that only works with constrains (no actual visible edges between the editor elements). â¢ The editor works live, so adding new elements to the scene properly rearranges the scene. â¢ But, perhaps, the most exciting part is the fact that the lines connect an element from inside the text editor element with another that lives outside of the editor element. All these validate the architecture of Bloc of having exactly one rendering tree. It was not an obvious goal a couple of years ago, but we are really happy that it works. To put it in perspective, let's compare this with the html world. Text is text is rendered through the DOM tree. If you want graphics you might use something like SVG which comes with its own tree. However, these are two distinct worlds, and you cannot go from one to another, or at least not easily. This is the case in most engines we looked at. Why is this important? One thing we learn in the Smalltalk world is that covering the same space with less concepts opens up a whole dimension of creativity that is simply not possible outside of it. The goal with Bloc is to enable new kinds of user interfaces. As we are late to the game of modern interfaces, even though the field was invented in Smalltalk, our only chance to take the lead again is to rethink the model. Let's look at the Connector again. In most user interfaces we have panes on the outside, and visuals confined within the boundaries of those panes. Interestingly, we can trace this pattern to the very first Smalltalk interfaces. In the Connector interface we have no boundaries with text and visualization being intertwined to form a new kind of workflow. Talking about workflows, we now have two distinct and novel ways to explore examples: one is Connector, and the other one is the expandable code editor. For example, the scene from above looks like this in the example expanding editor: Both of these interfaces are not found in other infrastructures, and yet they were both inexpensive to implement in Bloc. We believe this will have a deep impact for all sorts of interfaces, and especially for the IDE. If you are interested in more details related to the IDE, take a look at the following paper from 2015: http://scg.unibe.ch/archive/papers/Girb15b-PervasiveSoftwareVisualizations.… Please let us know what you think. Cheers, The feenk team -- www.tudorgirba.com www.feenk.com "What is more important: To be happy, or to make happy?"

5 4

Tonel code?
by Javier PimÃ¡s Jan. 15, 2018

Jan. 15, 2018

Hi, I wanted to do some dialect porting experiments. I want to export to pharo using tonel file format and got some questions. 1. Is this the main source? https://github.com/pharo-vcs/tonel 2. Is it already loaded in pharo 7? 3. Seems to have dependencies with monticello, how hard would it be to have a port without monticello/port the needed monticello dependencies? 4. Any advice? Cheers, Javier -- Javier PimÃ¡s Ciudad de Buenos Aires

3 5

Blame support P7
by Torsten Bergmann Jan. 15, 2018

Jan. 15, 2018

Not having timestamps/authors in Pharo 7 due to git and missing blame support (see [1]) has other bad side effects: - it clobbers all method stamps in an MCZ package [1] if you use Monticello which can lead easily to trouble/lamenting - it is not possible to fileout a changeset [2] in the ChangeSorter Was there any further discussion/decision for P7 on solving this or adding blame support? Thx T. [1] http://forum.world.st/Author-name-in-version-Iceberg-td4968472.html [2] http://lists.squeakfoundation.org/pipermail/vm-dev/2018-January/026350.html [3] https://pharo.fogbugz.com/f/cases/20951/

12 32

git and author/timestamps, 10000's of files, etc.
by Dale Henrichs Jan. 15, 2018

Jan. 15, 2018

I've been skimming the ironically named "blame" thread and just want to clear up some apparent misconceptions. git/github is not the reason that the author/timestamps information was "lost" ... when tonel was introduced the author/timestamp info was not included in the format as a separately serialized file. filetree's implementation of author/timestamp support (around for almost 6 years now) was an annoying source of commit conflicts and often prevented automatic merges. git/github has perfectly functional blame support[1], so the decision to rely on git for supplying the author/timestamp for tonel was a sound decision. Thierry Goubier's GitFileTree[2] implementation does a very good job of converting git author/timestamp information into Monticello meta data, and is proof that author/timestamp information can be extracted from a git repository. AFAICT, the single issue here is that the code to link between git's author/timestamp information and the in-image author/timestamp information has not been written YET ... git/github is not the reason that there are "1000's of files on disk". Tonel uses a file per class format which significanly reduces the file count for Smalltalk repositories on disk. FileTree format uses a file per method format and for large projects leads to a large number of files, which in and of itself is not a problem (at least for git), but does lead to excessive disk space consumption. SmalltalkCI[2], which provides support for Smalltalk on travis-ci[3] and appveyory[4] was created by Fabio Niephaus an active member of the Squeak community. Travis-ci makes it possible to run cross-dialect tests to validate github pull requests and checkins[5] for cross-dialect projects. It seems that there are at least some (less vocal) members of the Squeak community who are interested in using git. Dale [1] https://www.git-scm.com/docs/git-blame [2] https://github.com/hpi-swa/smalltalkCI [3] https://travis-ci.org/ [4] https://www.appveyor.com/ [5] https://travis-ci.org/Metacello/metacello

5 4

Pavel's ChangeLog week of 2018-01-08
by Pavel Krivanek Jan. 15, 2018

Jan. 15, 2018

I was continuing on work on Ring 2 integration. The image with replaced Ring versions can be bootstrapped and most of the failing tests are fixed. The most problematic part is Epicea adoption. I improved the optional resolving granularity in Ring 2 and added new cleaning mechanisms of the environments but some work still left. In past we had a MethodReference class that was then replaced with Ring models. With the Ring 2 integration a similar class will be re-introduced because the models in Ring 2 are more complex and they are not the best option for cases where only a simple model with a method class name and selector is needed - e.g. for code coverage etc. It is important that such reference class will NOT be polymorphic with real methods because people then tend to mix usage of models and real system. Small tip. When you want to work on an image that was created by the CI from a pull request and you want to make next commits based on it (it can be a PR done by someone else), you will probably see this error when you will try to reload packages: IceError: Your repository seems to be out of sync.! Please fetch from "noname (git@github.com:pharo-project/pharo.git)" and try again. It is caused by the fact that the versions that are loaded in the image are based on merging commits done by the CI that are not present in any repository. Iceberg then cannot find them and so no fetch will help. It can be solved by reloading of the packages from the Tonel working copy on disk. Then you can finally reload the packages from the Git repository. It should not be done in a single pass so that's why the code looks so strange: pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo' ]. repository := TonelRepository new directory: (pharoRepository location / pharoRepository subdirectory); yourself. (pharoRepository savedPackages select: [:aPackage | aPackage isLoaded ]) do: [ :package | [ (repository loadVersionFromFileNamed: package name) load. ] on: MCMergeOrLoadWarning do: [:warning | warning resume: true ]]. (pharoRepository savedPackages select: [:aPackage | aPackage isLoaded ]) do: [ :package | [ package reload ] on: MCMergeOrLoadWarning do: [:warning | warning resume: true ]]. Cheers, -- Pavel

1 0

pharo 6.1 iceberg problem with latest windows (32bit) VM
by Sanjay Minni Jan. 15, 2018

Jan. 15, 2018

Using Pharo 6.1 with the latest windows 32 bit VM, i get the following message when trying to use world->tools->iceberg "This version of iceberg required libgit2 0.25.1, you have 0.23.0, pls update your PharoVM" regards Sanjay ----- --- Regards, Sanjay -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

2 1

Pharo Lecture at Tunis next week
by Stephane Ducasse Jan. 15, 2018

Jan. 15, 2018

Hi guys just to tell you that next week I will give a lecture at ENIS at tunis. 3 full days of Pharo and advanced design. Stef

4 3