feel free to do pull request :)
On Sat, Jul 8, 2017 at 9:33 AM, Clément Bera <bera.clem...@gmail.com> wrote:
> 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 <stepharo.s...@gmail.com>
> 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 <stepharo.s...@gmail.com>
>> >> wrote:
>> >>
>> >>> On Thu, Jul 6, 2017 at 11:27 PM, Tim Mackinnon <tim@testit.works>
>> >>> 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 <stepharo.s...@gmail.com>
>> >>>>> 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 <pavel.kriva...@gmail.com>
>> >>>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>> TxText removal is already done too.
>> >>>>>
>> >>>>> -- Pavel
>> >>>>>
>> >>>>> 2017-07-06 10:55 GMT+02:00 Stephane Ducasse
>> >>>>> <stepharo.s...@gmail.com>:
>> >>>>>>
>> >>>>>> 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.
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>> >
>>
>
