- Pharo-dev - lists.pharo.org

Dependencies between git projects ?

by Sven Van Caekenberghe

I normally specify my dependencies between git projects like this: BaselineOfP3 >> baselineOf: spec <baseline> spec for: #common do: [ spec baseline: 'NeoJSON' with: [ spec repository: 'github://svenvc/NeoJSON:master/repository' ]. baseline: 'ZTimestamp' with: [ spec repository: 'github://svenvc/ztimestamp:master/repository' ]. spec baseline: 'Glorp' with: [ spec repository: 'github://pharo-rdbms/glorp:master/']. spec package: 'P3' with: [ spec requires: #('NeoJSON' 'ZTimestamp') ]. spec package: 'P3-Tests' with: [ spec requires: #('P3') ]. spec package: 'P3-Glorp' with: [ spec requires: #('P3' 'Glorp') ]. spec group: 'default' with: #('P3' 'P3-Tests'). spec group: 'core' with: #('P3'). spec group: 'glorp' with: #('P3-Glorp') ] Today I (finally, duh) realised that the github:// syntax actually requires a valid GitHub user. Since I do this with all my (public) projects, it obviously works (for others too), but still, is it actually 'wrong' ? Sven

May 7, 2019

[Pharo 8.0] Build #258: 3300-Could-we-have-better-comment-for-SlotemitStore-

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

There is a new Pharo build available! The status of the build #258 was: SUCCESS. The Pull Request #3309 was integrated: "3300-Could-we-have-better-comment-for-SlotemitStore-" Pull request url: https://github.com/pharo-project/pharo/pull/3309 Issue Url: https://github.com/pharo-project/pharo/issues/3300 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 7, 2019

[Pharo 8.0] Build #257: update Calypso 0.16.4 which fixes broken tab selection

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

There is a new Pharo build available! The status of the build #257 was: SUCCESS. The Pull Request #3308 was integrated: "update Calypso 0.16.4 which fixes broken tab selection" Pull request url: https://github.com/pharo-project/pharo/pull/3308 Issue Url: https://github.com/pharo-project/pharo/issues/updateCalypso0164 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 7, 2019

[Pharo 8.0] Build #256: Use Calypso 0.16.3

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

There is a new Pharo build available! The status of the build #256 was: FAILURE. The Pull Request #3298 was integrated: "Use Calypso 0.16.3" Pull request url: https://github.com/pharo-project/pharo/pull/3298 Issue Url: https://github.com/pharo-project/pharo/issues/updateCalypso0163 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 6, 2019

Re: [Pharo-dev] Explaining Spec2 and why Bloc is on the roadmap

by Tudor Girba

Hi, Thanks for the mail. Iâd like to add a few remarks from the perspective of the team that currently develops Bloc/Brick. We are quite happy to see that Bloc/Brick starts to be considered a target platform. Bloc was started by Alain Plantec and StÃ©phane Ducasse. Glenn Cavarle was an important contributor at some point, too. At feenk, we got involved about 3+ years ago and since then we invested significantly in it and we are planning to continue to do so. In this process, the code was rewritten several times. We are developing Bloc/Brick in the context of Glamorous Toolkit (GT). The latest code (including reproducible releases) is here: https://github.com/feenkcom/Bloc https://github.com/feenkcom/Brick While we could say that GT is only one user, the requirements that come from GT are broader than that of a typical application. For example, this led us to build an editor with rather unique abilities. Also, Bloc has the property of being able to accommodate both visualizations and typical widgets within the same scene and this allows us to compose new kinds of interfaces. GT is still in alpha and things will still evolve in the coming months, and Bloc/Brick will change as well. However, we can consider Bloc quite stable and we find that we can operate significant changes without affecting users. For example, recently, we added a complete new support for native windows (we replaced SDL2 with Glutin) and made it work on all platforms without impact the users: https://twitter.com/feenkcom/status/1124544911716515840 Brick already has a list of widgets that are usable. If you want to see it in practice, just open a Glamorous Toolkit image. Brick will go through more changes in the following period mostly due to the introduction on theming support and user-specific preferences. Nevertheless, we would be happy to see the code exercised from a different perspective than the one we have. So, if people want to play with it, we would be happy to support and provide feedback. Cheers, Doru > On May 2, 2019, at 11:27 AM, ducasse <stepharo(a)netcourrier.com> wrote: > > Dear Pharoers > > We would like to explain what is Spec 2.0 and how Bloc is on the Pharo roadmap. > > Spec is a way to support a way to express and reuse application interaction logic. > Spec was first developed by Benjamin van Ryseghem and others while supervised > by StÃ©phane Ducasse. > Over the years we cleaned Spec, but we never took the time to really revisit it, and Spec > was never stressed outside the scope of Pharo tools (even if there is some people who > used it in their projects, this was not the general case). There was a need to deeply rethink > the way we express and reuse interaction application logic. > > Spec 2.0 revisits fundamentally Spec. The consortium wants to acknowledge the strong financial > support of Schmidt in this new development. Here is a list of points we are working on to support companies > to build modern applications with Pharo. > > - adding support for many widgets and at the same time improving existing widgets such as fasttable > - adds much better layouts (we will deprecate the interpreter design) > - introducing a new way to architecture an application: > Spec20 introduces the notion of application to better handle resources and window flow > - revisiting the internal logic of Spec (to remove useless parts and enhance the ones that works) > - adding many tests > > In addition we want that Spec 2.0 is not tight anymore with Morphic. > Why? Because we want to make sure that: > - companies can deploy desktop applications > - we can reuse all the tools logic of Pharo with new widgets sets such as Brick (widgets on top of Bloc) > without having to rewrite everything. > > This is why Spec2.0 can optionally render using Gtk3.0. It also means that in the future we can have native widgets. > > Now that Bloc/Brick is finally reaching a point where it can be tried and eventually adopted, we want to > make sure the transition to it will not force us to throw away the tools we developed last ten years. > We think that Bloc needs some effort to clean and structure it and Spec2.0 gives the time to let Bloc and Brick > mature. Also, we want to make sure that in the future we will be able to adopt other backends in case we > decide it (Remember new now is old tomorrow and while Bloc/Brick is new and modern, it will not remain > new and modern forever). > > Brick needs to be ready for Pharo consumption, and to make it possible we need to move the image to converge. > With Spec 2.0, in future versions we will just need to define a new backend to get all our tools working. > > The Pharo Board > > > -- www.feenk.com "To utilize feedback, you first have to acquire it."

May 4, 2019

[Pharo 8.0] Build #255: add example: LazySlot

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

There is a new Pharo build available! The status of the build #255 was: SUCCESS. The Pull Request #3293 was integrated: "add example: LazySlot" Pull request url: https://github.com/pharo-project/pharo/pull/3293 Issue Url: https://github.com/pharo-project/pharo/issues/3292 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 4, 2019

Visit Tokyo from 27 June to 5 of July

by ducasse

Dear Pharoers/Smalltalkers from Japan (and other countries) I will visit (mainly) Tokyo from 27 of June to 5th of July 2019. I will give several talks and one is scheduled to the Smalltalk User group (Oda Tomohiro is organising it). I will give some talks to researchers and companies. Iâm really excited to meet people. Do not hesitate to contact me so that we can plan extra meetings. I really want to see what you are doing and how to support the community. Stef

May 4, 2019

[Pharo 8.0] Build #254: Typos

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

There is a new Pharo build available! The status of the build #254 was: FAILURE. The Pull Request #3295 was integrated: "Typos" Pull request url: https://github.com/pharo-project/pharo/pull/3295 Issue Url: https://github.com/pharo-project/pharo/issues/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 3, 2019

[Pharo 8.0] Build #253: 3269-Make-EmergencyEvaluator-work-again

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

There is a new Pharo build available! The status of the build #253 was: SUCCESS. The Pull Request #3271 was integrated: "3269-Make-EmergencyEvaluator-work-again" Pull request url: https://github.com/pharo-project/pharo/pull/3271 Issue Url: https://github.com/pharo-project/pharo/issues/3269 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 3, 2019

[Pharo 8.0] Build #252: 3289-beForText-is-deprecated-but-there-are-two-senders

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

There is a new Pharo build available! The status of the build #252 was: SUCCESS. The Pull Request #3290 was integrated: "3289-beForText-is-deprecated-but-there-are-two-senders" Pull request url: https://github.com/pharo-project/pharo/pull/3290 Issue Url: https://github.com/pharo-project/pharo/issues/3289 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 3, 2019