October 2019 - Pharo-dev - lists.pharo.org

Fwd: [Esug-list] Smalltalk Employment

by StÃ©phane Ducasse

> Begin forwarded message: > > From: Norm Green <norm.green(a)gemtalksystems.com> > Subject: [Esug-list] Smalltalk Employment > Date: 8 October 2019 at 18:24:28 CEST > To: esug-list(a)lists.esug.org > > GemTalk has a customer in Canada looking for Smalltalkers in the greater Toronto area. Please email if you know someone who would be interested. > > Norm > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr http://www.synectique.eu / http://www.pharo.org 03 59 35 87 52 Assistant: Julie Jonas FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Oct. 8, 2019

Re: [Pharo-dev] Integer #byteAt: #digitAt: portability

by ducasse

> On 8 Oct 2019, at 18:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Recently, #digitAt: was renamed to #byteAt: in Pharo 8. I totally agree that this is better. > > However, how does one write a library that needs to use this selector and wants portability with at least Pharo 7 ? > > That requires quite some effort from my side (either an ugly dynamic hack, or different source code packages, just for one method). > > Can we back port #byteAt: at least as an alias to Pharo 7 ? yes of course good idea. If you can send a PR it will be faster :) > > Sven > >

Oct. 8, 2019

Integer #byteAt: #digitAt: portability

by Sven Van Caekenberghe

Hi, Recently, #digitAt: was renamed to #byteAt: in Pharo 8. I totally agree that this is better. However, how does one write a library that needs to use this selector and wants portability with at least Pharo 7 ? That requires quite some effort from my side (either an ugly dynamic hack, or different source code packages, just for one method). Can we back port #byteAt: at least as an alias to Pharo 7 ? Sven

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by ducasse

Hello > It is indeed clearer. > Previously I thought that "migrating tools to Spec2" means migrating Spec > tools to Spec2; now I see it's rewriting all tools to use Spec2. We cannot continue to stack layers and layers of âdust". For P9 we will have to have a massive cleanup again. I started to browse the code. Now we do not have enough people looking at modularity. > However, I still wonder about all shiny new tools being developed by feenk > as part GToolkit 2 - documenter, coder, etc. as well as new iterations on > inspector, debugger. > What is their place in the grand scheme of things? Good question. Why not but not at all prices :) - tests tests tests - real models because we will not rewrite all the time everything - code review and code review [ I do not like to have subclasses of announcer and other beast to maintain I was against Glamour even if I encouraged doru to do it and retrospectively I was right :) ] Iâm not sure that we all want to code in Coder :) but we will see. Our move is to make sure that we can move slowly in the right direction: Bloc / Brick Better VM Better infrastructure (this is why I cleaned/shrunk beacon and added in P8) Better Tools What we see is that Bloc deserves 6 months of work and a nice documentation. After we will have to design widgets (or revise the ones of feenk). There is a path between innovation and making sure that companies can deploy robust applications (this is why GTK will help us for that) but we should find the right path. You see we cannot just say ok let us throw away all the PharoThings effort and others :) because we could have follow the feenk path last year but was the implication. Stef

Oct. 8, 2019

[Pharo 8.0] Build #846: add-shortcut-printer

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

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

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by webwarrior

ducasse wrote > ... > > Is it clearer? > Do not hesitate to ask questions if you need. We do not have hidden > agenda. > > ... >> It is indeed clearer. Previously I thought that "migrating tools to Spec2" means migrating Spec tools to Spec2; now I see it's rewriting all tools to use Spec2. However, I still wonder about all shiny new tools being developed by feenk as part GToolkit 2 - documenter, coder, etc. as well as new iterations on inspector, debugger. What is their place in the grand scheme of things? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by Esteban Lorenzano

Iâm planning to integrate it by the end of this month (or close). Which of course it does not means it will be finish and perfectly done, but that we are confident people can start using them and help us in the process :) Esteban > On 8 Oct 2019, at 16:57, ducasse <stepharo(a)netcourrier.com> wrote: > > Thanks Sven > I think Esteban is about to release something. We panned a missed meeting about the debugger monday. > > Esteban? > > Stef > >> On 8 Oct 2019, at 16:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 8 Oct 2019, at 16:45, ducasse <stepharo(a)netcourrier.com> wrote: >>> >>> The new inspector will let people define their own extensions but not using the same glamourous block-based API. >>> Esteban started to migrate extensions of Pharo and we will help as soon as the new inspector is available. >>> The community will also be able to help. >> >> I would love to help with the Inspector (having worked on both EyeInspector and GTInspector extensions). Please involve us as soon as possible. > > >

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by ducasse

Thanks Sven I think Esteban is about to release something. We panned a missed meeting about the debugger monday. Esteban? Stef > On 8 Oct 2019, at 16:54, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 8 Oct 2019, at 16:45, ducasse <stepharo(a)netcourrier.com> wrote: >> >> The new inspector will let people define their own extensions but not using the same glamourous block-based API. >> Esteban started to migrate extensions of Pharo and we will help as soon as the new inspector is available. >> The community will also be able to help. > > I would love to help with the Inspector (having worked on both EyeInspector and GTInspector extensions). Please involve us as soon as possible.

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by Sven Van Caekenberghe

> On 8 Oct 2019, at 16:45, ducasse <stepharo(a)netcourrier.com> wrote: > > The new inspector will let people define their own extensions but not using the same glamourous block-based API. > Esteban started to migrate extensions of Pharo and we will help as soon as the new inspector is available. > The community will also be able to help. I would love to help with the Inspector (having worked on both EyeInspector and GTInspector extensions). Please involve us as soon as possible.

Oct. 8, 2019

Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019

by ducasse

Hello The roadmap has been announced a while ago but I will repeat it. To prepare the migration to Bloc and Brick in the future we are rewriting all the tools using a new version of Spec (called Spec20). In addition we are providing a GTK backend so that companies can do business by exposing a nicer UI and as a validation that all our tools will be able to work without Morphic. The idea is to reuse the logic of the tools and avoid to have to rewrite them systematically. And to let companies do the same. The current iteration will not touch Calypso (but we will have sadly to rewrite Calypso because some of the logic in mixed with Morphs) so that we can migrate to Bloc. Esteban is rewriting all the tools Inspector Playground Debugger are now the main focus (in addition to other tools). We will deprecate Glamour because it is not maintained anymore and we have serious problems with its design. We will deprecate all the GT tools except Spotter. But we will propose replacement because we like these tools. You will have a nice Inspector framework a nice new debugger with object-centric and scriptable API a new playground Spotter will be also rewritten (may be not during this iteration) why? Because - it does not scale. - it has its own set of experimental and unmaintained widgets (and memory leaks that we fixed :) We will also revisit all the pragma uses and also symbols walking for completion that systematically scan the complete memory and make Pharo slow. We will create a super large image to have a case to show that we can improve on the speed front. The new inspector will let people define their own extensions but not using the same glamourous block-based API. Esteban started to migrate extensions of Pharo and we will help as soon as the new inspector is available. The community will also be able to help. Is it clearer? Do not hesitate to ask questions if you need. We do not have hidden agenda. Note that we do not that by pleasure. And frankly we would prefer to do something else - it would have been nice that as a community we understand that there is a value in having models well separated outside of UI but this is not the case. But we do not really decide. We cannot stay with Morphic forever and improving Morphic is a dead-end. We do it because it is important for Pharo and for consortium members. Stef > >> NewTools >> Inspector >> it now implements Miller columns >> Using TaskIt as backend for stepping. >> extensions migrated (we are at 10% of the total of migrations needed, we >> will enhance this in iterative way). >> Debugger >> Almost complete revamp of UI. >> Fix context updating (to allow commands to actually work) >> Integrate new inspector. >> Work on new layouts for debugger >> Make an experimental tool: "playbook", to concentrate playgrounds and test >> some UI ideas. >> >> ... > > I try to follow Pharo development with regards to UI, but I'm still lost. > > Are you ditching GToolkit and replacing it with new tools? > If so, what about inspector ans spotter extensions? > > Also what are the plans for next generation of GToolkit? > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 8, 2019