Discussing the roadmap

> On Sat, Jul 8, 2017 at 8:22 AM, Stephane Ducasse <[hidden email]> wrote:
> > Actually that's a good point - should the roadmap encompass what the community can offer too (i hadn't appreciated the distinction )?
>
> Yes it does.
> Esteban (and christophe 60% paid by rmod) and guille (60% but also
> writing papers) cannot do all that alone?
>
>
> > We collectively pay for some things to be achieved, but also we expect that we can contribute some of the lower hanging fruit.
>
> Yes and even more.
> We at RMOD are not paid to produce Pharo. Pharo only represents a
> small part of our job evaluation.
> Now if everybody takes 1 hour per week to improve Pharo it will be huge.
>
>
> > Of course some things are at the whim of what itches to scratch, but others we may be able to rally around?
> >
> > Tim
> >
> > Sent from my iPhone
> >
> >> On 7 Jul 2017, at 06:11, Stephane Ducasse <[hidden email]> wrote:
> >>
> >>> On Thu, Jul 6, 2017 at 11:27 PM, Tim Mackinnon <[hidden email]> wrote:
> >>> I didn’t mean to touch a nerve - and this was why I wrote “minor” points - but you did ask for feedback…
> >>
> >> you did not :)
> >> Just that if we just count on fully book engineers working on super
> >> important features we will not make it.
> >> This is why once in a while I sit and fix a boring pop up or related.
> >> I hate the stupid pop up for pakcgae selection and one day I will have
> >> to retry to kill it.
> >>
> >>>
> >>> Point noted on giving user feedback - I’d actually like to fix things, but currently its just too hard to submit fixes other than pull requests for documentation that is sitting in git hub (and I have submitted those). I know you are working on a simpler way to contribute (and getting the GitHub process smoothed out is in progress so its not fair to comment on that yet as its early days - and much appreciated.
> >>>
> >>> The Alt-Tab issue in the tracker since 2015 - but I will try and report others and possibly Calypso might have some better keyboard navigation tricks that help.
> >>
> >> do you have the bug entry?
> >>
> >>>
> >>> For website documentation - I’ll take it back, as I went back again just now and everything I could think of was there (a lot in the news section which I hadn’t noticed). I do think the download page is a bit confusing but I know there is work being done on that.
> >>>
> >>> Tim
> >>>
> >>>
> >>>>> On 6 Jul 2017, at 19:11, Stephane Ducasse <[hidden email]> wrote:
> >>>>>
> >>>>> Only 2 minor items stick out as missing:
> >>>>>
> >>>>> 1) Continuing to improve keyboard shortcut support (its a lot better, but
> >>>>> not quite completed - I really miss some shortcuts, particularly the ability
> >>>>> to meta-tab between windows - ALT-Tab only works in some windows, and widen
> >>>>> selection in the editor - e.g. CMD-W in IntelliJ to increasing select a
> >>>>> word, a statement, a function etc)
> >>>>
> >>>> There are three issues there:
> >>>> - moving from the vm the keyboard generation (this will be done via
> >>>> OSWindow and the VM can focus its main job: execution).
> >>>> - then there is the way we declare/manage shortcuts: this is an
> >>>> ongoing efforts where everybody can join. We should remove the
> >>>> hardcoded shortcut and turn them into KeyBindings
> >>>> - Most of the tools will be throw away when bloc will be integrated.
> >>>> Now it does not mean that we should not do it.
> >>>>
> >>>> Now an important point: as a user you should report but you can also
> >>>> contribute.
> >>>> This is super difficult for me to fix something that I have no clue
> >>>> how to reproduce/never encounter.
> >>>> You see the mental model of a real open-source movement is to share
> >>>> but also to produce together and the point is
> >>>> what is the reward model: why should I spend time on pain I do not
> >>>> feel. Of course we are already doing a lot
> >>>> of actions that is not focus on our immediate needs and we should
> >>>> improve the situation but I wanted to share
> >>>> with you this perspective.
> >>>>
> >>>>
> >>>>>
> >>>>> 2) Keeping the website documentation more up to date (again the pharo.org
> >>>>> website is very slick, and a great showcase, however often there are late
> >>>>> breaking changes which new users won’t know about unless they trace through
> >>>>> the news groups or subscribe to some blogs). If we could also focus on
> >>>>> keeping it simple but up to date - that might help.
> >>>>
> >>>> Where is it not up to date?
> >>>> We are always reacting to any broken piece there.
> >>>> You see producing Pharo by Example 5 was A LOT of work and I thank
> >>>> again Nicolai Hesse for all his huge efforts.
> >>>>
> >>>>
> >>>>> I also have 1 small query - the references to the text editor, is this
> >>>>> making the editor that was demo’d at PharoDays 2107 integrated? As that one
> >>>>> was very cool?
> >>>>
> >>>> Yes calypso will replace our old friend Nautilus and we will certainly
> >>>> need to put a lot of love into calypso to get
> >>>> it to the right level. Now the basis is sound.
> >>>> About the node we will revisit smart suggestions and indeed sometimes
> >>>> there are problems to catch the correct AST nodes.
> >>>>
> >>>>> I don’t know how extensible it is (I’m hoping so - and that
> >>>>> it might help making it easier to improve code editing tools such that
> >>>>> refactorings can more intelligently understand where your cursor is with
> >>>>> regards to the AST node underneath it, or we can add more intellisense
> >>>>> options that match some of the things we see in IntelliJ).
> >>>>>
> >>>>> Tim
> >>>>>
> >>>>> On 6 Jul 2017, at 13:00, Pavel Krivanek <[hidden email]> wrote:
> >>>>>
> >>>>>
> >>>>> TxText removal is already done too.
> >>>>>
> >>>>> -- Pavel
> >>>>>
> >>>>> 2017-07-06 10:55 GMT+02:00 Stephane Ducasse <[hidden email]>:
> >>>>>>
> >>>>>> We would like to share this list with you and get your feedback and
> >>>>>> inputs.
> >>>>>> It will be presented and discussed again at ESUG.
> >>>>>>
> >>>>>> Stef on the behalf of the engineering team of the Pharo consortium.
> >>>>>>
> >>>>>> # Pharo 7 (and 8) potential roadmap
> >>>>>>
> >>>>>> This document contains a list of actions that should be done during
> >>>>>> Pharo 7 and 8.
> >>>>>> It is not a definitive list. It is the result of a discussion within
> >>>>>> the engineer team and RModers.
> >>>>>> It first lists actions that should be performed at the image level
> >>>>>> then lists the actions for the VM.
> >>>>>>
> >>>>>>
> >>>>>> ## Image
> >>>>>> As a general principle, we will try to remove something when we add a
> >>>>>> new features or version of a component.
> >>>>>>
> >>>>>> ### New tools
> >>>>>> - Iceberg: Iceberg is the new tool suite to handle new VCS in Pharo.
> >>>>>> For the moment it supports Git. This tool will become central to the
> >>>>>> development of projects in Pharo. The key and first enhancements will
> >>>>>> be:
> >>>>>> - cherry picking
> >>>>>> - multiple directories support, subtrees
> >>>>>> - better new development process support
> >>>>>>
> >>>>>> - Calypso: Calypso is a new tool suite for editing and navigating
> >>>>>> code. It is modular and can easily be extended.
> >>>>>> - integration, set as the default browser
> >>>>>>
> >>>>>> - Hermes (binary loader): Hermes is a code loader that does not
> >>>>>> require the compiler to be loaded. It will be used to speed up the
> >>>>>> bootstrap.
> >>>>>>
> >>>>>> - Beacon: Beacon is an announcement-based logger. It should be
> >>>>>> introduced but in addition the left over of previous logging should be
> >>>>>> cleaned and removed for example many of the transcript show: should be
> >>>>>> removed.
> >>>>>>
> >>>>>> - Inspector refreshing: the inspector should refresh its values by
> >>>>>> default.
> >>>>>>
> >>>>>> - Cargo: Cargo is a new package manager. It supports the expression of
> >>>>>> dependencies between packages. We are currently validating that it can
> >>>>>> support conditional loading (platform) and building new tooling to
> >>>>>> express and validate data.
> >>>>>>
> >>>>>> - Check dependencies when committing. Pharo comes with a dependency
> >>>>>> analyser tools. Such tools should be used before commiting to warn the
> >>>>>> user when a new dependency is introduced in a package.
> >>>>>>
> >>>>>> ### Cleaning bloat
> >>>>>> - Removing of Nautilus: Once Calypso will be integrated and exhibit
> >>>>>> similar fetaures than Nautilus. Nautilus should be removed.
> >>>>>> - Remove old text editor: there is only one or two widgets still using
> >>>>>> the old text editor and the rubric text editor.
> >>>>>> - Remove TxText: TxText was an attempt to get a new generation text
> >>>>>> editor. Now it has been rewritten with a new design in Bloc so we
> >>>>>> should remove it since Bloc editor is better and actively maintained.
> >>>>>> - Remove Komitter: Iceberg already supports cherrypicking on commit
> >>>>>> therefore Komitter can be safely removed from Pharo.
> >>>>>> - Remove system categorizer: The old system categorizer is not used
> >>>>>> anymore and should be remove.
> >>>>>>
> >>>>>> - Old compiler removal: The old compiler should now get unloaded from
> >>>>>> Pharo.
> >>>>>> - The old compiler should be moved to an external package and make
> >>>>>> sure that it can be reloaded.
> >>>>>> - In addition the encoders should be separated. (@@ more here@@)
> >>>>>>
> >>>>>> - Old inspector cleanup: we should remove the eyeInspector framework
> >>>>>> but we should introduce a minimal fallback inspector. This inspector
> >>>>>> should work without Spec or any frameworks.
> >>>>>>
> >>>>>> - Clean behavior protocol. The number of methods in the core Behavior,
> >>>>>> ClassDescription and Class requires some analysis and cleaning.
> >>>>>>
> >>>>>> - Kernel modularization: the effort on modularising the packages
> >>>>>> should be continued.
> >>>>>>
> >>>>>> ### Language infrastructure
> >>>>>> The following points are more related to the infrastructure of
> >>>>>> manipulating and loading class definitions. There are the basis for
> >>>>>> the future module system and cleaning some often hidden parts of the
> >>>>>> system.
> >>>>>>
> >>>>>> - New class definition: The class definition is not scaling anymore
> >>>>>> due to the large number of options (traits, slot, tage, package,
> >>>>>> immediate, ephemeron). A fluid-based message API should be designed.
> >>>>>>
> >>>>>> - Support for Undefined classes: When loading old code or code whose
> >>>>>> superclass has not yet being loaded, the system has inconsistent
> >>>>>> behavior. Depending on the tools, it may not load the code, raise a
> >>>>>> warning or decide that the superclass is Object without any other
> >>>>>> notice and losing the name of the original superclass. We are working
> >>>>>> on a new mechanism to support a unique way to handle such case. To be
> >>>>>> presented at IWST/ESUG
> >>>>>>
> >>>>>> - Class definition parser: Class definition is parser in different
> >>>>>> place of the system and in addition the output is the direct creation
> >>>>>> of a class object instead of an object representing the class
> >>>>>> definition that can be further manipulated. We are working on class
> >>>>>> definition parser. It produces a separate AST. It will help the
> >>>>>> building of tools.
> >>>>>>
> >>>>>> - Better update infrastructure. Pablo Tesone has been working on a
> >>>>>> better update mechanism, better modular class builder.
> >>>>>>
> >>>>>> - Ring2: Ring is a metamodel to manipulate code that is not actively
> >>>>>> running in the current system. It is useful to perform analysis (such
> >>>>>> as browsing, navigating off-line or remote definitions) before
> >>>>>> actually loading the code. Ring got redesigned by Pavel Krivanek to
> >>>>>> support the bootstrap of Pharo 60. The results is Ring2.
> >>>>>>
> >>>>>> - Opal is the Pharo Compiler. It should be enhanced to support handle
> >>>>>> better the warning and a general enhancement pass is needed.
> >>>>>>
> >>>>>> ### System enhancements
> >>>>>>
> >>>>>> - Commandline enhancements. RMOD is currently improving the
> >>>>>> command-line infrastructure and making sure that the system can work
> >>>>>> in read-only mode.
> >>>>>>
> >>>>>> - Cleaning streams: the idea is to make sure that the system does not
> >>>>>> use the old streams. The idea is to start using the fileStreams and
> >>>>>> make sure that the Stream package can be substituated in the future by
> >>>>>> other streams with the same API. Therefore hardcoded class names
> >>>>>> should be substituted with factory (readSream writeStream). From that
> >>>>>> perspective we do not think that it is wise to introduce Xtreams. We
> >>>>>> should analyse the API of the current implementation.
> >>>>>>
> >>>>>> - New theme from the beginning. It is really important that each
> >>>>>> version of Pharo is identified open the default opening. Pharo should
> >>>>>> come up with two default themes: one light and one dark.
> >>>>>>
> >>>>>> - Better themes/palettes support
> >>>>>> - Better and nicer Tabs. Tabs design should be revisited.
> >>>>>>
> >>>>>> - OSWindow world rendering: the effort to remove the logic of the
> >>>>>> windowing from the VM should be continued. OSWindow should be used
> >>>>>> instead.
> >>>>>>
> >>>>>> - Freetype: The current freetype plugin is the source of many bugs and
> >>>>>> problem. Thibault Raffaillac used FFI to do direct call to openGL
> >>>>>> (@@to verify@@).
> >>>>>>
> >>>>>>
> >>>>>> - Refactoring 2: Refactoring 2 is an improved version of the
> >>>>>> refactorings developed by Gustavos Santos and they should used to
> >>>>>> replace the existing one.
> >>>>>>
> >>>>>>
> >>>>>> ## VM
> >>>>>>
> >>>>>> - 64-bits by default: Mac and Linux 64 bits VMs have been working for
> >>>>>> over a year and since June 2017 a Windows 64 bits VM has been working.
> >>>>>> The plan is to stabilize each part of Pharo that is not working in 64
> >>>>>> bits as well as in 32 bits and make the 64 bits Pharo images and VM
> >>>>>> the default download for Pharo.
> >>>>>>
> >>>>>> - Headless VM: Ronie Salgado has built a headless VM on his VM branch,
> >>>>>> we need to merge and check everything works fine. With the headless
> >>>>>> VM, Pharo can be run in true headless mode (not with a hidden window)
> >>>>>> and it is required for future VM features (embeddable VM, ...).
> >>>>>>
> >>>>>> - Embeddable VM: The VM should be able to be embedded in external
> >>>>>> applications, the application accessing objects through well-defined
> >>>>>> APIs.
> >>>>>>
> >>>>>> - Idle VM: The goal is to avoid the active waiting loop consuming
> >>>>>> several per cent of cpu time when the Pharo image is not doing
> >>>>>> anything.
> >>>>>>
> >>>>>> - Android VM: integration of the Android VM build and tests in the
> >>>>>> integration setup.
> >>>>>>
> >>>>>> - Threaded FFI: all FFI calls should be non-blocking (reviving
> >>>>>> prototype of Eliot)
> >>>>>>
> >>>>>> - ZeroConf for ARM: The ARM VM should be available from the zeroConf
> >>>>>> servers
> >>>>>>
> >>>>>> - Better support for large heaps (GC tuning API, incremental GC).
> >>>>>> Pharo 64 bit is now able to manage large heap. However better
> >>>>>> performance can be proposed by offering better settings for the
> >>>>>> different GC zone.
> >>>>>>
> >>>>>> - Integrate various fixes to support better high resolution display.
> >>>>>> In Retina mac display Pharo looks blurry. The fix to support Retina
> >>>>>> should be integrated in the VM.
> >>>>>>
> >>>>>> ### Sista-related
> >>>>>> Sista is an optimizing JIT for Pharo. It is the result of multiple
> >>>>>> years of developement by Clement Bera and Eliot Miranda. An optimizing
> >>>>>> JIT is manipulating code (folding constant, rewriting it) before
> >>>>>> compiling it to assembly code.
> >>>>>>
> >>>>>> - New Block Closure implementation by default: Allows one to implement
> >>>>>> in the Opal compiler the copying and clean blocks optimisations,
> >>>>>> reduce massively the complexity of some parts of the JIT (debugging
> >>>>>> API to map machine code pc to bytecode pc for example) and is required
> >>>>>> for the Sista support. Some work remains in debugging/IDE support.
> >>>>>>
> >>>>>> - New Bytecode set in production: Eases bytecode decoding (simplifying
> >>>>>> the code base of the bytecode to source code decompiler, the debugger,
> >>>>>> the JIT, etc.), lifts compiled code limitations (size of jumps, etc.)
> >>>>>> and is required for the Sista support. Some work remains in debugging
> >>>>>> support.
> >>>>>>
> >>>>>> - Read-only objects: They work in Pharo 6, but the in-image support
> >>>>>> needs to be improved (fall-back code of primitives, etc.) and some
> >>>>>> polishing needs to be done (primitive error code not always correct,
> >>>>>> etc.). Used for the support of different project, including GBS.
> >>>>>>
> >>>>>> - Literals immutability (based on read-only objects). In particular an
> >>>>>> analysis of the image usage of literal (string mutation) is needed.
> >>>>>>
> >>>>>> - Sista preview: A first version of Sista will be integrated, yielding
> >>>>>> 1.5x performance boost on most applications, but will be optional and
> >>>>>> will require specific constraints (not toying too much with literal
> >>>>>> mutability, partial IDE support, etc.).
> >>>>>>
> >>>>>>
> >>>>>> ### Already done
> >>>>>>
> >>>>>> - [DONE] Remove Shoreline reporter.
> >>>>>> - [DONE] Kernel should not depend on Traits: This will speed up the
> >>>>>> bootstrap and support the modular introduction of alternate traits
> >>>>>> implementation currently designed by Pablo Tesone and tested in the
> >>>>>> new generation of Moose.
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
> >
>
>

> The incremental GC is already mentioned in "Better support for large heaps
> (GC tuning API, incremental GC)". Now we have a second paragraph about the
> incremental GC, that's redundant and the form of the paragraph is not
> consistent with the rest of the roadmap where each feature has 1 or 2 lines
> of explanations, not 10 lines.
>
> Same thing, the Sista-related introduction is 10 lines instead of 2-3, which
> is not consistent with the form of the rest of the roadmap.
>
> Inconsistent form makes the document look unprofessional. We need to make it
> consistent, we can't let it like that.
>
> On Sat, Jul 8, 2017 at 8:22 AM, Stephane Ducasse <[hidden email]>
> wrote:
>>
>> > Actually that's a good point - should the roadmap encompass what the
>> > community can offer too (i hadn't appreciated the distinction )?
>>
>> Yes it does.
>> Esteban (and christophe 60% paid by rmod) and guille (60% but also
>> writing papers) cannot do all that alone?
>>
>>
>> > We collectively pay for some things to be achieved, but also we expect
>> > that we can contribute some of the lower hanging fruit.
>>
>> Yes and even more.
>> We at RMOD are not paid to produce Pharo. Pharo only represents a
>> small part of our job evaluation.
>> Now if everybody takes 1 hour per week to improve Pharo it will be huge.
>>
>>
>> > Of course some things are at the whim of what itches to scratch, but
>> > others we may be able to rally around?
>> >
>> > Tim
>> >
>> > Sent from my iPhone
>> >
>> >> On 7 Jul 2017, at 06:11, Stephane Ducasse <[hidden email]>
>> >> wrote:
>> >>
>> >>> On Thu, Jul 6, 2017 at 11:27 PM, Tim Mackinnon <[hidden email]>
>> >>> wrote:
>> >>> I didn’t mean to touch a nerve - and this was why I wrote “minor”
>> >>> points - but you did ask for feedback…
>> >>
>> >> you did not :)
>> >> Just that if we just count on fully book engineers working on super
>> >> important features we will not make it.
>> >> This is why once in a while I sit and fix a boring pop up or related.
>> >> I hate the stupid pop up for pakcgae selection and one day I will have
>> >> to retry to kill it.
>> >>
>> >>>
>> >>> Point noted on giving user feedback - I’d actually like to fix things,
>> >>> but currently its just too hard to submit fixes other than pull requests for
>> >>> documentation that is sitting in git hub (and I have submitted those). I
>> >>> know you are working on a simpler way to contribute (and getting the GitHub
>> >>> process smoothed out is in progress so its not fair to comment on that yet
>> >>> as its early days - and much appreciated.
>> >>>
>> >>> The Alt-Tab issue in the tracker since 2015 - but I will try and
>> >>> report others and possibly Calypso might have some better keyboard
>> >>> navigation tricks that help.
>> >>
>> >> do you have the bug entry?
>> >>
>> >>>
>> >>> For website documentation - I’ll take it back, as I went back again
>> >>> just now and everything I could think of was there (a lot in the news
>> >>> section which I hadn’t noticed). I do think the download page is a bit
>> >>> confusing but I know there is work being done on that.
>> >>>
>> >>> Tim
>> >>>
>> >>>
>> >>>>> On 6 Jul 2017, at 19:11, Stephane Ducasse <[hidden email]>
>> >>>>> wrote:
>> >>>>>
>> >>>>> Only 2 minor items stick out as missing:
>> >>>>>
>> >>>>> 1) Continuing to improve keyboard shortcut support (its a lot
>> >>>>> better, but
>> >>>>> not quite completed - I really miss some shortcuts, particularly the
>> >>>>> ability
>> >>>>> to meta-tab between windows - ALT-Tab only works in some windows,
>> >>>>> and widen
>> >>>>> selection in the editor - e.g. CMD-W in IntelliJ to increasing
>> >>>>> select a
>> >>>>> word, a statement, a function etc)
>> >>>>
>> >>>> There are three issues there:
>> >>>> - moving from the vm the keyboard generation (this will be done via
>> >>>> OSWindow and the VM can focus its main job: execution).
>> >>>> - then there is the way we declare/manage shortcuts: this is an
>> >>>> ongoing efforts where everybody can join. We should remove the
>> >>>> hardcoded shortcut and turn them into KeyBindings
>> >>>> - Most of the tools will be throw away when bloc will be integrated.
>> >>>> Now it does not mean that we should not do it.
>> >>>>
>> >>>> Now an important point: as a user you should report but you can also
>> >>>> contribute.
>> >>>> This is super difficult for me to fix something that I have no clue
>> >>>> how to reproduce/never encounter.
>> >>>> You see the mental model of a real open-source movement is to share
>> >>>> but also to produce together and the point is
>> >>>> what is the reward model: why should I spend time on pain I do not
>> >>>> feel. Of course we are already doing a lot
>> >>>> of actions that is not focus on our immediate needs and we should
>> >>>> improve the situation but I wanted to share
>> >>>> with you this perspective.
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> 2) Keeping the website documentation more up to date (again the
>> >>>>> pharo.org
>> >>>>> website is very slick, and a great showcase, however often there are
>> >>>>> late
>> >>>>> breaking changes which new users won’t know about unless they trace
>> >>>>> through
>> >>>>> the news groups or subscribe to some blogs). If we could also focus
>> >>>>> on
>> >>>>> keeping it simple but up to date - that might help.
>> >>>>
>> >>>> Where is it not up to date?
>> >>>> We are always reacting to any broken piece there.
>> >>>> You see producing Pharo by Example 5 was A LOT of work and I thank
>> >>>> again Nicolai Hesse for all his huge efforts.
>> >>>>
>> >>>>
>> >>>>> I also have 1 small query - the references to the text editor, is
>> >>>>> this
>> >>>>> making the editor that was demo’d at PharoDays 2107 integrated? As
>> >>>>> that one
>> >>>>> was very cool?
>> >>>>
>> >>>> Yes calypso will replace our old friend Nautilus and we will
>> >>>> certainly
>> >>>> need to put a lot of love into calypso to get
>> >>>> it to the right level. Now the basis is sound.
>> >>>> About the node we will revisit smart suggestions and indeed sometimes
>> >>>> there are problems to catch the correct AST nodes.
>> >>>>
>> >>>>> I don’t know how extensible it is (I’m hoping so - and that
>> >>>>> it might help making it easier to improve code editing tools such
>> >>>>> that
>> >>>>> refactorings can more intelligently understand where your cursor is
>> >>>>> with
>> >>>>> regards to the AST node underneath it, or we can add more
>> >>>>> intellisense
>> >>>>> options that match some of the things we see in IntelliJ).
>> >>>>>
>> >>>>> Tim
>> >>>>>
>> >>>>> On 6 Jul 2017, at 13:00, Pavel Krivanek <[hidden email]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> TxText removal is already done too.
>> >>>>>
>> >>>>> -- Pavel
>> >>>>>
>> >>>>> 2017-07-06 10:55 GMT+02:00 Stephane Ducasse
>> >>>>> <[hidden email]>:
>> >>>>>>
>> >>>>>> We would like to share this list with you and get your feedback and
>> >>>>>> inputs.
>> >>>>>> It will be presented and discussed again at ESUG.
>> >>>>>>
>> >>>>>> Stef on the behalf of the engineering team of the Pharo consortium.
>> >>>>>>
>> >>>>>> # Pharo 7 (and 8) potential roadmap
>> >>>>>>
>> >>>>>> This document contains a list of actions that should be done during
>> >>>>>> Pharo 7 and 8.
>> >>>>>> It is not a definitive list. It is the result of a discussion
>> >>>>>> within
>> >>>>>> the engineer team and RModers.
>> >>>>>> It first lists actions that should be performed at the image level
>> >>>>>> then lists the actions for the VM.
>> >>>>>>
>> >>>>>>
>> >>>>>> ## Image
>> >>>>>> As a general principle, we will try to remove something when we add
>> >>>>>> a
>> >>>>>> new features or version of a component.
>> >>>>>>
>> >>>>>> ### New tools
>> >>>>>> - Iceberg: Iceberg is the new tool suite to handle new VCS in
>> >>>>>> Pharo.
>> >>>>>> For the moment it supports Git. This tool will become central to
>> >>>>>> the
>> >>>>>> development of projects in Pharo. The key and first enhancements
>> >>>>>> will
>> >>>>>> be:
>> >>>>>> - cherry picking
>> >>>>>> - multiple directories support, subtrees
>> >>>>>> - better new development process support
>> >>>>>>
>> >>>>>> - Calypso: Calypso is a new tool suite for editing and navigating
>> >>>>>> code. It is modular and can easily be extended.
>> >>>>>> - integration, set as the default browser
>> >>>>>>
>> >>>>>> - Hermes (binary loader): Hermes is a code loader that does not
>> >>>>>> require the compiler to be loaded. It will be used to speed up the
>> >>>>>> bootstrap.
>> >>>>>>
>> >>>>>> - Beacon: Beacon is an announcement-based logger. It should be
>> >>>>>> introduced but in addition the left over of previous logging should
>> >>>>>> be
>> >>>>>> cleaned and removed for example many of the transcript show: should
>> >>>>>> be
>> >>>>>> removed.
>> >>>>>>
>> >>>>>> - Inspector refreshing: the inspector should refresh its values by
>> >>>>>> default.
>> >>>>>>
>> >>>>>> - Cargo: Cargo is a new package manager. It supports the expression
>> >>>>>> of
>> >>>>>> dependencies between packages. We are currently validating that it
>> >>>>>> can
>> >>>>>> support conditional loading (platform) and building new tooling to
>> >>>>>> express and validate data.
>> >>>>>>
>> >>>>>> - Check dependencies when committing. Pharo comes with a dependency
>> >>>>>> analyser tools. Such tools should be used before commiting to warn
>> >>>>>> the
>> >>>>>> user when a new dependency is introduced in a package.
>> >>>>>>
>> >>>>>> ### Cleaning bloat
>> >>>>>> - Removing of Nautilus: Once Calypso will be integrated and exhibit
>> >>>>>> similar fetaures than Nautilus. Nautilus should be removed.
>> >>>>>> - Remove old text editor: there is only one or two widgets still
>> >>>>>> using
>> >>>>>> the old text editor and the rubric text editor.
>> >>>>>> - Remove TxText: TxText was an attempt to get a new generation text
>> >>>>>> editor. Now it has been rewritten with a new design in Bloc so we
>> >>>>>> should remove it since Bloc editor is better and actively
>> >>>>>> maintained.
>> >>>>>> - Remove Komitter: Iceberg already supports cherrypicking on commit
>> >>>>>> therefore Komitter can be safely removed from Pharo.
>> >>>>>> - Remove system categorizer: The old system categorizer is not used
>> >>>>>> anymore and should be remove.
>> >>>>>>
>> >>>>>> - Old compiler removal: The old compiler should now get unloaded
>> >>>>>> from
>> >>>>>> Pharo.
>> >>>>>> - The old compiler should be moved to an external package and make
>> >>>>>> sure that it can be reloaded.
>> >>>>>> - In addition the encoders should be separated. (@@ more here@@)
>> >>>>>>
>> >>>>>> - Old inspector cleanup: we should remove the eyeInspector
>> >>>>>> framework
>> >>>>>> but we should introduce a minimal fallback inspector. This
>> >>>>>> inspector
>> >>>>>> should work without Spec or any frameworks.
>> >>>>>>
>> >>>>>> - Clean behavior protocol. The number of methods in the core
>> >>>>>> Behavior,
>> >>>>>> ClassDescription and Class requires some analysis and cleaning.
>> >>>>>>
>> >>>>>> - Kernel modularization: the effort on modularising the packages
>> >>>>>> should be continued.
>> >>>>>>
>> >>>>>> ### Language infrastructure
>> >>>>>> The following points are more related to the infrastructure of
>> >>>>>> manipulating and loading class definitions. There are the basis for
>> >>>>>> the future module system and cleaning some often hidden parts of
>> >>>>>> the
>> >>>>>> system.
>> >>>>>>
>> >>>>>> - New class definition: The class definition is not scaling anymore
>> >>>>>> due to the large number of options (traits, slot, tage, package,
>> >>>>>> immediate, ephemeron). A fluid-based message API should be
>> >>>>>> designed.
>> >>>>>>
>> >>>>>> - Support for Undefined classes: When loading old code or code
>> >>>>>> whose
>> >>>>>> superclass has not yet being loaded, the system has inconsistent
>> >>>>>> behavior. Depending on the tools, it may not load the code, raise a
>> >>>>>> warning or decide that the superclass is Object without any other
>> >>>>>> notice and losing the name of the original superclass. We are
>> >>>>>> working
>> >>>>>> on a new mechanism to support a unique way to handle such case. To
>> >>>>>> be
>> >>>>>> presented at IWST/ESUG
>> >>>>>>
>> >>>>>> - Class definition parser: Class definition is parser in different
>> >>>>>> place of the system and in addition the output is the direct
>> >>>>>> creation
>> >>>>>> of a class object instead of an object representing the class
>> >>>>>> definition that can be further manipulated. We are working on class
>> >>>>>> definition parser. It produces a separate AST. It will help the
>> >>>>>> building of tools.
>> >>>>>>
>> >>>>>> - Better update infrastructure. Pablo Tesone has been working on a
>> >>>>>> better update mechanism, better modular class builder.
>> >>>>>>
>> >>>>>> - Ring2: Ring is a metamodel to manipulate code that is not
>> >>>>>> actively
>> >>>>>> running in the current system. It is useful to perform analysis
>> >>>>>> (such
>> >>>>>> as browsing, navigating off-line or remote definitions) before
>> >>>>>> actually loading the code. Ring got redesigned by Pavel Krivanek to
>> >>>>>> support the bootstrap of Pharo 60. The results is Ring2.
>> >>>>>>
>> >>>>>> - Opal is the Pharo Compiler. It should be enhanced to support
>> >>>>>> handle
>> >>>>>> better the warning and a general enhancement pass is needed.
>> >>>>>>
>> >>>>>> ### System enhancements
>> >>>>>>
>> >>>>>> - Commandline enhancements. RMOD is currently improving the
>> >>>>>> command-line infrastructure and making sure that the system can
>> >>>>>> work
>> >>>>>> in read-only mode.
>> >>>>>>
>> >>>>>> - Cleaning streams: the idea is to make sure that the system does
>> >>>>>> not
>> >>>>>> use the old streams. The idea is to start using the fileStreams and
>> >>>>>> make sure that the Stream package can be substituated in the future
>> >>>>>> by
>> >>>>>> other streams with the same API. Therefore hardcoded class names
>> >>>>>> should be substituted with factory (readSream writeStream). From
>> >>>>>> that
>> >>>>>> perspective we do not think that it is wise to introduce Xtreams.
>> >>>>>> We
>> >>>>>> should analyse the API of the current implementation.
>> >>>>>>
>> >>>>>> - New theme from the beginning. It is really important that each
>> >>>>>> version of Pharo is identified open the default opening. Pharo
>> >>>>>> should
>> >>>>>> come up with two default themes: one light and one dark.
>> >>>>>>
>> >>>>>> - Better themes/palettes support
>> >>>>>> - Better and nicer Tabs. Tabs design should be revisited.
>> >>>>>>
>> >>>>>> - OSWindow world rendering: the effort to remove the logic of the
>> >>>>>> windowing from the VM should be continued. OSWindow should be used
>> >>>>>> instead.
>> >>>>>>
>> >>>>>> - Freetype: The current freetype plugin is the source of many bugs
>> >>>>>> and
>> >>>>>> problem. Thibault Raffaillac used FFI to do direct call to openGL
>> >>>>>> (@@to verify@@).
>> >>>>>>
>> >>>>>>
>> >>>>>> - Refactoring 2: Refactoring 2 is an improved version of the
>> >>>>>> refactorings developed by Gustavos Santos and they should used to
>> >>>>>> replace the existing one.
>> >>>>>>
>> >>>>>>
>> >>>>>> ## VM
>> >>>>>>
>> >>>>>> - 64-bits by default: Mac and Linux 64 bits VMs have been working
>> >>>>>> for
>> >>>>>> over a year and since June 2017 a Windows 64 bits VM has been
>> >>>>>> working.
>> >>>>>> The plan is to stabilize each part of Pharo that is not working in
>> >>>>>> 64
>> >>>>>> bits as well as in 32 bits and make the 64 bits Pharo images and VM
>> >>>>>> the default download for Pharo.
>> >>>>>>
>> >>>>>> - Headless VM: Ronie Salgado has built a headless VM on his VM
>> >>>>>> branch,
>> >>>>>> we need to merge and check everything works fine. With the headless
>> >>>>>> VM, Pharo can be run in true headless mode (not with a hidden
>> >>>>>> window)
>> >>>>>> and it is required for future VM features (embeddable VM, ...).
>> >>>>>>
>> >>>>>> - Embeddable VM: The VM should be able to be embedded in external
>> >>>>>> applications, the application accessing objects through
>> >>>>>> well-defined
>> >>>>>> APIs.
>> >>>>>>
>> >>>>>> - Idle VM: The goal is to avoid the active waiting loop consuming
>> >>>>>> several per cent of cpu time when the Pharo image is not doing
>> >>>>>> anything.
>> >>>>>>
>> >>>>>> - Android VM: integration of the Android VM build and tests in the
>> >>>>>> integration setup.
>> >>>>>>
>> >>>>>> - Threaded FFI: all FFI calls should be non-blocking (reviving
>> >>>>>> prototype of Eliot)
>> >>>>>>
>> >>>>>> - ZeroConf for ARM: The ARM VM should be available from the
>> >>>>>> zeroConf
>> >>>>>> servers
>> >>>>>>
>> >>>>>> - Better support for large heaps (GC tuning API, incremental GC).
>> >>>>>> Pharo 64 bit is now able to manage large heap. However better
>> >>>>>> performance can be proposed by offering better settings for the
>> >>>>>> different GC zone.
>> >>>>>>
>> >>>>>> - Integrate various fixes to support better high resolution
>> >>>>>> display.
>> >>>>>> In Retina mac display Pharo looks blurry. The fix to support Retina
>> >>>>>> should be integrated in the VM.
>> >>>>>>
>> >>>>>> ### Sista-related
>> >>>>>> Sista is an optimizing JIT for Pharo. It is the result of multiple
>> >>>>>> years of developement by Clement Bera and Eliot Miranda. An
>> >>>>>> optimizing
>> >>>>>> JIT is manipulating code (folding constant, rewriting it) before
>> >>>>>> compiling it to assembly code.
>> >>>>>>
>> >>>>>> - New Block Closure implementation by default: Allows one to
>> >>>>>> implement
>> >>>>>> in the Opal compiler the copying and clean blocks optimisations,
>> >>>>>> reduce massively the complexity of some parts of the JIT (debugging
>> >>>>>> API to map machine code pc to bytecode pc for example) and is
>> >>>>>> required
>> >>>>>> for the Sista support. Some work remains in debugging/IDE support.
>> >>>>>>
>> >>>>>> - New Bytecode set in production: Eases bytecode decoding
>> >>>>>> (simplifying
>> >>>>>> the code base of the bytecode to source code decompiler, the
>> >>>>>> debugger,
>> >>>>>> the JIT, etc.), lifts compiled code limitations (size of jumps,
>> >>>>>> etc.)
>> >>>>>> and is required for the Sista support. Some work remains in
>> >>>>>> debugging
>> >>>>>> support.
>> >>>>>>
>> >>>>>> - Read-only objects: They work in Pharo 6, but the in-image support
>> >>>>>> needs to be improved (fall-back code of primitives, etc.) and some
>> >>>>>> polishing needs to be done (primitive error code not always
>> >>>>>> correct,
>> >>>>>> etc.). Used for the support of different project, including GBS.
>> >>>>>>
>> >>>>>> - Literals immutability (based on read-only objects). In particular
>> >>>>>> an
>> >>>>>> analysis of the image usage of literal (string mutation) is needed.
>> >>>>>>
>> >>>>>> - Sista preview: A first version of Sista will be integrated,
>> >>>>>> yielding
>> >>>>>> 1.5x performance boost on most applications, but will be optional
>> >>>>>> and
>> >>>>>> will require specific constraints (not toying too much with literal
>> >>>>>> mutability, partial IDE support, etc.).
>> >>>>>>
>> >>>>>>
>> >>>>>> ### Already done
>> >>>>>>
>> >>>>>> - [DONE] Remove Shoreline reporter.
>> >>>>>> - [DONE] Kernel should not depend on Traits: This will speed up the
>> >>>>>> bootstrap and support the modular introduction of alternate traits
>> >>>>>> implementation currently designed by Pablo Tesone and tested in the
>> >>>>>> new generation of Moose.
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>