- Pharo-dev - lists.pharo.org

Test Completion has been added to Pharo 8 - please test!

by Myroslava Romaniuk

Hi all, we added an intermediate version of the upcoming test completion to Pharo 8, it would be cool if you tested it and let us know the results. Here's a blog post about it - link <https://medium.com/@myroslavarm/test-code-completion-has-been-added-to-phar…>, and here's a tweet I'd be grateful if you shared - link <https://twitter.com/myroslavarm/status/1146013653067587584> so perhaps people who don't read the mailing list would also see it. In the blog post you can find more info how to enable the completion in the settings and details about the whole thing in general. If something doesn't work, or if something works differently than it used to in the old completion (both if you don't like it or perhaps if you prefer it) let me know either replying here, on twitter, or submitting an issue request directly for the github repository here - link <https://github.com/myroslavarm/Experimental-Completion/issues>. Thanks very much, Myroslava

July 2, 2019

[Pharo 8.0] Build #420: 3680-Fuel-serialization-should-null-external-addresses

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

There is a new Pharo build available! The status of the build #420 was: SUCCESS. The Pull Request #3682 was integrated: "3680-Fuel-serialization-should-null-external-addresses" Pull request url: https://github.com/pharo-project/pharo/pull/3682 Issue Url: https://github.com/pharo-project/pharo/issues/fuel Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 2, 2019

[Pharo 8.0] Build #419: 3732-cleanup-allLocalCallsOn

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

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

July 2, 2019

[Pharo 8.0] Build #418: 3730-SystemNavigation-allSendersOf-and-allReferencesTo-simplification

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

There is a new Pharo build available! The status of the build #418 was: FAILURE. The Pull Request #3731 was integrated: "3730-SystemNavigation-allSendersOf-and-allReferencesTo-simplification" Pull request url: https://github.com/pharo-project/pharo/pull/3731 Issue Url: https://github.com/pharo-project/pharo/issues/3730 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 2, 2019

Re: [Pharo-dev] A small game: do one trivial improvement every day

by Marcus Denker

> On 26 Jun 2019, at 08:16, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have started again to do one absolutely trivial improvement every week-day. > Small cleanup of the day: â¢ deprecate #allLocalCallsOn:ofClass: in SystemNavigation, implement it in ClassDescription>>allLocalCallsOn: â¢ add withAllSuperAndSubclasses, use it in #allInstVarNamesEverywhere â¢ simplify allLocalCallsOn: to use allInstVarNamesEverywhere and flatCollect Review needed: https://github.com/pharo-project/pharo/pull/3733/files Marcus

July 2, 2019

Re: [Pharo-dev] Pharo8: Advance on Spec2 and Gtk3 backend

by Pierce Ng

On Tue, Jul 02, 2019 at 09:29:01AM +0900, ducasse wrote: > we would be interested in knowing if the new infrastructure (FFI) you have better success. > If you want to give a try contact Pablo Tesone <tesonep(a)gmail.com> > > Because we believe that the infrastructure we are putting in place for GTK can be reuse/extended > for other projects. Hi Stef. Will do. Pierce

July 2, 2019

Re: [Pharo-dev] Pharo8: Advance on Spec2 and Gtk3 backend

by ducasse

Hi pierce we would be interested in knowing if the new infrastructure (FFI) you have better success. If you want to give a try contact Pablo Tesone <tesonep(a)gmail.com> Because we believe that the infrastructure we are putting in place for GTK can be reuse/extended for other projects. Stef > On 2 Jul 2019, at 09:11, Pierce Ng <pierce(a)samadhiweb.com> wrote: > > On Mon, Jul 01, 2019 at 05:58:17PM +0200, Esteban Lorenzano wrote: >> But overall, the Gtk3 backend is also in good shape and we will put it >> >> Instead, we moved at the top of the backlog the âmove to headless vmâ >> and Pablo and me started to work on that. >> >> Now, there are problems associated to that (like event loops and >> that)â¦ but this is not anymore Spec2+Gtk3 and then it requires a new >> mail to be explained :) > > Very exciting. Looking forward to it. > > Early this year I played with IUP using Pharo 7. Got as far as putting > up a hello world dialog but the overall behaviour was wonky, which I > imagined is due to event loops and such on the non-headless VM. > > IUP => http://webserver2.tecgraf.puc-rio.br/iup/ > IUPCocoa => https://github.com/ewmailing/IupCocoa > > Pierce >

July 2, 2019

Re: [Pharo-dev] Pharo8: Advance on Spec2 and Gtk3 backend

by Pierce Ng

On Mon, Jul 01, 2019 at 05:58:17PM +0200, Esteban Lorenzano wrote: > But overall, the Gtk3 backend is also in good shape and we will put it > > Instead, we moved at the top of the backlog the âmove to headless vmâ > and Pablo and me started to work on that. > > Now, there are problems associated to that (like event loops and > that)â¦ but this is not anymore Spec2+Gtk3 and then it requires a new > mail to be explained :) Very exciting. Looking forward to it. Early this year I played with IUP using Pharo 7. Got as far as putting up a hello world dialog but the overall behaviour was wonky, which I imagined is due to event loops and such on the non-headless VM. IUP => http://webserver2.tecgraf.puc-rio.br/iup/ IUPCocoa => https://github.com/ewmailing/IupCocoa Pierce

July 2, 2019

Re: [Pharo-dev] Pharo8: Advance on Spec2 and Gtk3 backend

by Esteban Lorenzano

> On 1 Jul 2019, at 18:44, Alexandre Bergel <abergel(a)dcc.uchile.cl> wrote: > > Hi! > > Thanks for this wonderful effort! > >> The consequences of this are obvious: we can, if we need it, fallback to morphic if you need to do something the backend does not allows (Roassal, I talking about you). > > Why would you need to fallback to Morphic if you wish to use Roassal3? I donât. My idea is that you will be able to fallback to Bloc or to plain Athens as you need. Morphic was just the first component. Also, I imagine someone who has already something made an investment in morphic (like someone using Roassal2 extensively). Then he will be able to benefit of it too. > Believe me, we will put the necessary resources to have R3 working very smoothly with Gtk. As soon as you feel confident for us to play with, then we will focus on this. Oh, I believe you :) Esteban > > Enjoy your well-deserved holidays! > > Cheers, > Alexandre >

July 1, 2019

Pharo8: Advance on Spec2 and Gtk3 backend

by Esteban Lorenzano

Hi, Last couple of months I have been really busy moving forward (along with Cyril and Pablo, in different places of the roadmap) what will be the backbone of Pharo 8.0 tool development: Spec 2. I worked in a lot of things and somehow the weekly reports went missing (my mistake). Now Iâm going on holidays but I will take this week to announce/release/show what I have done latest weeks (then it does not accumulates so much and resuming the weekly report when Iâm back will be smoother). Anyway, this is the status of this parts: 1) Spec 2 has move into a less immature status, and we are arriving to a status of âinternal betaâ soon. For âinternal betaâ means the features we wanted to implement are there even if still with bugs and miss-behaviours). For this, in (very) short summary we passed through: - We made a pass on all Spec components and we deprecated some and added some others. - We introduced the concept of âtransmissionâ, to partially mimic what glamour was capable of doing in a very easy way. - We introduced 5 different layouts to replace the unique âdo-it-allâ older. - We introduced the concept âApplicationâ to handle window flow and application resources. And all this was already announced, but we have moved to a more stable phase now and this is ready to be stressed. Last version of this is already integrated on Pharo 8 (we renamed the prefix to Sp, so we avoid part of the migration pain). Other point where there was a lot of movement was in the Gtk3 backend. Work has been done for stability that will affect (positively) all the system, not just backend: for example in UFFI I needed to introduce the concept of NULL and the possibility to âcastâ numeric declarations. This is because in 64bit NULL != 0 (being 6 an int32), and because 0 != 0L (and many like that). So now you can have ffi invocations of the form: self ffiCall: #(void myFunction (NULL, (long)42)). And this will be correctly parsed on the different platforms. But overall, the Gtk3 backend is also in good shape and we will put it to be tested soon(â¢) :P (I estimated it was last week, but as always there were complications). One thing I think is interesting to talk about (because we needed to change a lot of things to make it work, much more than was expected at first) was one Gtk element that you will find interesting: GtkMorphView. Basically GtkMorphView allows you to put a morph (whatever you want) into a Gtk container (the Spec component to allow this is SpMorphPresenter). This allows you to do things like this: And as I said to Stef last week: I find this screenshot very sexy because what is showing is 4 simple button morphs behaving in sync with other Gtk3 components in an external window. The consequences of this are obvious: we can, if we need it, fallback to morphic if you need to do something the backend does not allows (Roassal, I talking about you). Of course, since this is our final target, there is a BlocPresenter also on the works. Iâm sure Pavel can share some sexier screenshots of what he is doing with this. A fun fact, that drives me to the next step is this: The GtkMorphView was working smoothly in windows but crashing immediately in macOS (I found it fun because is usually the opposite). I needed to make a âstop the worldâ and jump to work on it and it tooks a couple of weeks to just figure out what was happening (debugging this kind of things is always hard). And at the end I had an approximate guess: The problem was in a not-thread safe way to handle the display in the VM side. I took a breath to decide the solution and at the end I decided to take the easiest path but maybe more time consuming at the beginning: Since we are going to move to a âheadlessâ vm (which means do not initiate a display at all, unless demanded and through the image), I did not see the point on jump and fix a code very hard to understand and debug. Instead, we moved at the top of the backlog the âmove to headless vmâ and Pablo and me started to work on that. Now, there are problems associated to that (like event loops and that)â¦ but this is not anymore Spec2+Gtk3 and then it requires a new mail to be explained :) Esteban

July 1, 2019