> On 8 Jul 2017, at 09:33, 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.
That is because "Better support for large heaps (GC tuning API, incremental GC)" is such an important topic ;-) > 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. Idem ditto ;-) > Inconsistent form makes the document look unprofessional. We need to make it > consistent, we can't let it like that. Yes, probably. > 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. > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > >
