I didn’t mean to touch a nerve - and this was why I wrote “minor” points - but you did ask for feedback…
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. 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 <[email protected]> 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 <[email protected]> wrote: >> >> >> TxText removal is already done too. >> >> -- Pavel >> >> 2017-07-06 10:55 GMT+02:00 Stephane Ducasse <[email protected]>: >>> >>> 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. >>> >> >> >
