Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
Thanks for the roadmap. I am particularly excited about the underlying improvements, such as VM, TaskIT and TFFI, that might capture less headlines. About TaskIT, are these: > • Implement a prototype of a distributed backend to execute tasks. > • Implement a communication layer using Rabbit MQ > • Implement the first version of a process manager for handling > multiples images and workers. already available? Cheers, Doru > On Oct 7, 2019, at 4:02 PM, Esteban Lorenzano wrote: > > > Hi all, > > Since some time we wanted to start with this report to keep you all informed > on what we are doing to achieve our goals for the release. > After ESUG we took some time to organise and we managed to put this in > movement. > The idea is to post one the first week of each month (but it may vary, as you > see with this one who came a bit later :P) > > Actions reportes are just dots, since we do not have the time to add a big > explanation and we hope you are already involved and more or less know what > we are talking about. > But do not hesitate to ask if you want more details :) > > Roadmap progress report. > September 2019 > > > Image > > Code Loading > • Profiling the time spent to load code > • Reimplementing a better Read/Write Buffered Stream > • Improving the performance of Source writing and reading, > • Improving in at least 20% the time of loading code using Metacello. > > Spec 2 > • Pass on SpMillerColumnPresenter to made it of general use. > • Implement a specific SpMillerLayout to handle Miller columns. > • Pass on regular input ports (transmissions subsystem) to implement > activation ports. > • Pass on SpStyle subsystem (kind of STON based stylesheets for > Morphic). > • Fix SpGridLayout horizontal cell calculous. (It was broken). > • Fix SpBoxLayout berderWith and padding. (It was broken). > • Added contextual menus to widgets. > • This functionality was completely revamped to make it work in > all backends. > • It was generalised to all widgets (even if not all should use > it!) > • Added focus order to presenters. > • This is also a full revamp of old existing functionality. > • it accepts you to change the default order, but it has a > default order (previous implementations forced you to do the focusing by > hand). > • Added key binding support for all widgets. > • This is also a full revamp of old exiting functionality. > > Spec2+GTK3 > • callbacks can now be chained. This requires some explanation: In Gtk3 > you connect to signals. And you can connect just one callback to one signal. > Thankfully we control the callbacks in our side, so we modified signal > callbacks to accept to chain other callbacks (then we can connect several > actions to one single event, for example "keypress" or “hide"). > • along with this, we reworked the callback hierarchy. > • implemented inheritance in Pharo of Gtk3 objects and interfaces (this > is needed to enhance control of tables and many others). > • added autocompletion capabilities to SpCodePresenter. > • added a mechanism to avoid duplicate signalling between the backend > and the adaptors. > • Fix an important leak on GtkFormView. > > 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. > > UFFI > • Adding Tests > • Support for kind of literals and support type definitions in literals > • Documentation > • Measuring performance issues on large images. > > TaskIT > • Implement a prototype of a distributed backend to execute tasks. > • Implement a communication layer using Rabbit MQ > • Implement the first version of a process manager for handling > multiples images and workers. > > VM > • Fixing problem with LibGIT and Windows 1903. > • Fixing the performance issues of Windows 1903 with File accesses when > using solid-state 4k physical sector disks. > • XCode integration > • Adding an initial version to detect invalid order in the return from > concurrent callbacks. > • Improving the implementation of TFFI to run 50% faster in callouts. > • Build of StackVM > -- feenk.com "Some battles are better lost than fought."
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
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
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
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
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
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 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 wrote: >> >> >> >>> On 8 Oct 2019, at 16:45, ducasse 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. > > >
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
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 wrote: > > > >> On 8 Oct 2019, at 16:45, ducasse 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.
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
> On 8 Oct 2019, at 16:45, ducasse 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.
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
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 >
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
EstebanLM wrote > ... > > 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
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
Yes very nice ! Keep the good work. Cheers, Cedrick PS: interested in the XCode integration of the VM amongst several stuff. Any pointers ? > Le 8 oct. 2019 à 13:06, Ben Coman a écrit : > > > Nice list. Thx for posting. > cheers -ben > >> On Mon, 7 Oct 2019 at 22:03, Esteban Lorenzano wrote: >> >> Hi all, >> >> Since some time we wanted to start with this report to keep you all informed >> on what we are doing to achieve our goals for the release. >> After ESUG we took some time to organise and we managed to put this in >> movement. >> The idea is to post one the first week of each month (but it may vary, as >> you see with this one who came a bit later :P) >> >> Actions reportes are just dots, since we do not have the time to add a big >> explanation and we hope you are already involved and more or less know what >> we are talking about. >> But do not hesitate to ask if you want more details :) >> >> Roadmap progress report. >> September 2019 >> >> >> Image >> >> Code Loading >> Profiling the time spent to load code >> Reimplementing a better Read/Write Buffered Stream >> Improving the performance of Source writing and reading, >> Improving in at least 20% the time of loading code using Metacello. >> >> Spec 2 >> Pass on SpMillerColumnPresenter to made it of general use. >> Implement a specific SpMillerLayout to handle Miller columns. >> Pass on regular input ports (transmissions subsystem) to implement >> activation ports. >> Pass on SpStyle subsystem (kind of STON based stylesheets for Morphic). >> Fix SpGridLayout horizontal cell calculous. (It was broken). >> Fix SpBoxLayout berderWith and padding. (It was broken). >> Added contextual menus to widgets. >> This functionality was completely revamped to make it work in all backends. >> It was generalised to all widgets (even if not all should use it!) >> Added focus order to presenters. >> This is also a full revamp of old existing functionality. >> it accepts you to change the default order, but it has a default order >> (previous implementations forced you to do the focusing by hand). >> Added key binding support for all widgets. >> This is also a full revamp of old exiting functionality. >> >> Spec2+GTK3 >> callbacks can now be chained. This requires some explanation: In Gtk3 you >> connect to signals. And you can connect just one callback to one signal. >> Thankfully we control the callbacks in our side, so we modified signal >> callbacks to accept to chain other callbacks (then we can connect several >> actions to one single event, for example "keypress" or “hide"). >> along with this, we reworked the callback hierarchy. >> implemented inheritance in Pharo of Gtk3 objects and interfaces (this is >> needed to enhance control of tables and many others). >> added autocompletion capabilities to SpCodePresenter. >> added a mechanism to avoid duplicate signalling between the backend and the >> adaptors. >> Fix an important leak on GtkFormView. >> >> 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. >> >> UFFI >> Adding Tests >> Support for kind of literals and support type definitions in literals >> Documentation >> Measuring performance issues on large images. >> >> TaskIT >> Implement a prototype of a distributed backend to execute tasks. >> Implement a communication layer using Rabbit MQ >> Implement the first version of a process manager for handling multiples >> images and workers. >> >> VM >> Fixing problem with LibGIT and Windows 1903. >> Fixing the performance issues of Windows 1903 with File accesses when using >> solid-state 4k physical sector disks. >> XCode integration >> Adding an initial version to detect invalid order in the return from >> concurrent callbacks. >> Improving the implementation of TFFI to run 50% faster in callouts. >> Build of StackVM >>
Re: [Pharo-dev] [ANN] Roadmap progress report. September 2019
Nice list. Thx for posting. cheers -ben On Mon, 7 Oct 2019 at 22:03, Esteban Lorenzano wrote: > > Hi all, > > Since some time we wanted to start with this report to keep you all > informed on what we are doing to achieve our goals for the release. > After ESUG we took some time to organise and we managed to put this in > movement. > The idea is to post one the first week of each month (but it may vary, as > you see with this one who came a bit later :P) > > Actions reportes are just dots, since we do not have the time to add a big > explanation and we hope you are already involved and more or less know what > we are talking about. > But do not hesitate to ask if you want more details :) > > *Roadmap progress report.* > *September 2019* > > > *Image* > > *Code Loading* > >- Profiling the time spent to load code >- Reimplementing a better Read/Write Buffered Stream >- Improving the performance of Source writing and reading, >- Improving in at least 20% the time of loading code using Metacello. > > > *Spec 2* > >- Pass on SpMillerColumnPresenter to made it of general use. > - Implement a specific SpMillerLayout to handle Miller columns. >- Pass on regular input ports (transmissions subsystem) to implement >activation ports. >- Pass on SpStyle subsystem (kind of STON based stylesheets for >Morphic). >- Fix SpGridLayout horizontal cell calculous. (It was broken). >- Fix SpBoxLayout berderWith and padding. (It was broken). >- Added contextual menus to widgets. > - This functionality was completely revamped to make it work in all > backends. > - It was generalised to all widgets (even if not all should use it!) >- Added focus order to presenters. > - This is also a full revamp of old existing functionality. > - it accepts you to change the default order, but it has a default > order (previous implementations forced you to do the focusing by hand). >- Added key binding support for all widgets. > - This is also a full revamp of old exiting functionality. > > > *Spec2+GTK3* > >- callbacks can now be chained. This requires some explanation: In >Gtk3 you connect to signals. And you can connect just one callback to one >signal. Thankfully we control the callbacks in our side, so we modified >signal callbacks to accept to chain other callbacks (then we can connect >several actions to one single event, for example "keypress" or “hide"). > - along with this, we reworked the callback hierarchy. >- implemented inheritance in Pharo of Gtk3 objects and interfaces >(this is needed to enhance control of tables and many others). >- added autocompletion capabilities to SpCodePresenter. >- added a mechanism to avoid duplicate signalling between the backend >and the adaptors. >- Fix an important leak on GtkFormView. > > > *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. > > > *UFFI* > >- Adding Tests >- Support for kind of literals and support type definitions in literals >- Documentation >- Measuring performance issues on large images. > > > *TaskIT* > >- Implement a prototype of a distributed backend to execute tasks. >- Implement a communication layer using Rabbit MQ >- Implement the first version of a process manager for handling >multiples images and workers. > > > *VM* > >- Fixing problem with LibGIT and Windows 1903. >- Fixing the performance issues of Windows 1903 with File accesses >when using solid-state 4k physical sector disks. >- XCode integration >- Adding an initial version to detect invalid order in the return from >concurrent callbacks. >- Improving the implementation of TFFI to run 50% faster in callouts. >- Build of StackVM > > >
