- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Beacon moved to github

by Norbert Hartl

You are right and I like this the most. Will change any repo I see ð Norbert > Am 08.07.2017 um 14:54 schrieb Gabriel Cotelli <g.cotelli(a)gmail.com>: > > We're using source, because you know in Smalltalk we don't like to invent abbreviations ;) > >> On Jul 8, 2017 07:18, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: >> >> > On 8 Jul 2017, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: >> > >> > Hi Peter - I just hit this yesterday with your kind help deciphering SmalltalkCI, and I have to confess that "src" was my inclination over repository for the reason you mention in that it is a repository already. >> > >> > I noticed other STCi projects have used "packages" . >> > >> > I would vote for "src" so other newcomers more easily understand what it is compared to where they came from. >> >> yes, I agreeâ¦ even if at first is me the one who used mc, I think âsrcâis better convention, now (thatâs why pharo is using it :P) >> >> Esteban >> >> > >> > I also think it would be helpful for iceberg to default to using that so we get some consistency? >> > >> > Tim >> > >> > Sent from my iPhone >> > >> >> On 7 Jul 2017, at 17:03, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> >> >>> On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: >> >>> Hi. >> >>> >> >>> I though it was already done :) >> >>> One notice. Should we all follow standard convention on repo structure? >> >>> Because source directory in beacon is called "repository" instead "src" >> >>> like in other repos. >> >> >> >> There is no standard convention for Pharo repos on github. >> >> >> >> In pharo-project I see >> >> >> >> * repository 3x >> >> * mc 3x >> >> * src 1x (not smalltalk code) >> >> >> >> And the rest of the github uses a variety of options >> >> >> >> * nothing >> >> - imho disorganized and very messy if you have several packages >> >> * repository >> >> - I've been using it and recommending it for ~2 years; also used by filetree and metacello repos ;) >> >> - Argument could be made that git is already a repository so it could be confusing >> >> * mc >> >> - because MontiCello/MetaCello I guess? I don't know how much this makes sense in the light of Iceberg >> >> * src >> >> - quite common in other programming languages >> >> * packages >> >> - well, the folder does contain just packages >> >> >> >> Someone could mine github to find precise numbers... but current usage shouldn't be a deciding factor. >> >> >> >> Peter >> >> >> >>> >> >>> 2017-07-07 16:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> >> >>>> I used the git migration tool of Peter Uhnak to migrate Beacon from >> >>>> smalltalkhub to github. It is available now here >> >>>> >> >>>> https://github.com/pharo-project/pharo-beacon >> >>>> >> >>>> I just need to know how I can switch a smalltalkhub project to read-only. >> >>>> >> >>>> FYI, >> >>>> >> >>>> Norbert >> >>>> >> >>>> >> >> >> > >> > >> >>

July 8, 2017

wrong file on the download

by Stephane Ducasse

http://pharo.org/web/download Pharo 7.0 image & changes latest.... donwloads a Pharo 60 image

July 8, 2017

Re: [Pharo-dev] Pharo contribute page still points to Pharo50Inbox

by Stephane Ducasse

I update it to at least make sure that people know that we are in flux :) On Sat, Jul 8, 2017 at 8:04 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks hernan. > We should update it to refer to github and I do not really know how to > update it. > > On Sat, Jul 8, 2017 at 6:45 PM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> http://pharo.org/contribute-propose-fix >> >> - Also the text to the mailing list is not linked. >> - "Select the Pharo60 repository" & "Publish the slice to Pharo50Inbox" >> >> Cheers, >> >> HernÃ¡n >>

July 8, 2017

how to issue a PR that changes package structure?

by Stephane Ducasse

Hi guys I would like to split or/and create packages. Should I update the Pharo baseline. Stef

July 8, 2017

Re: [Pharo-dev] Pharo contribute page still points to Pharo50Inbox

by Stephane Ducasse

Thanks hernan. We should update it to refer to github and I do not really know how to update it. On Sat, Jul 8, 2017 at 6:45 PM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > http://pharo.org/contribute-propose-fix > > - Also the text to the mailing list is not linked. > - "Select the Pharo60 repository" & "Publish the slice to Pharo50Inbox" > > Cheers, > > HernÃ¡n >

July 8, 2017

Re: [Pharo-dev] Beacon moved to github

by Pierce Ng

On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: > One notice. Should we all follow standard convention on repo structure? > Because source directory in beacon is called "repository" instead "src" > like in other repos. In my PasswordCrypt package, I have src-c for the C sources and Makefile, and src-st for the Smalltalk code. Pierce

July 8, 2017

Pharo contribute page still points to Pharo50Inbox

by HernÃ¡n Morales Durand

http://pharo.org/contribute-propose-fix - Also the text to the mailing list is not linked. *- "**Select the Pharo60 repository" & *"Publish the slice to Pharo50Inbox" Cheers, HernÃ¡n

July 8, 2017

Re: [Pharo-dev] Beacon moved to github

by Gabriel Cotelli

We're using source, because you know in Smalltalk we don't like to invent abbreviations ;) On Jul 8, 2017 07:18, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > On 8 Jul 2017, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: > > > > Hi Peter - I just hit this yesterday with your kind help deciphering > SmalltalkCI, and I have to confess that "src" was my inclination over > repository for the reason you mention in that it is a repository already. > > > > I noticed other STCi projects have used "packages" . > > > > I would vote for "src" so other newcomers more easily understand what it > is compared to where they came from. > > yes, I agreeâ¦ even if at first is me the one who used mc, I think âsrcâis > better convention, now (thatâs why pharo is using it :P) > > Esteban > > > > > I also think it would be helpful for iceberg to default to using that so > we get some consistency? > > > > Tim > > > > Sent from my iPhone > > > >> On 7 Jul 2017, at 17:03, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > >>> On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: > >>> Hi. > >>> > >>> I though it was already done :) > >>> One notice. Should we all follow standard convention on repo structure? > >>> Because source directory in beacon is called "repository" instead "src" > >>> like in other repos. > >> > >> There is no standard convention for Pharo repos on github. > >> > >> In pharo-project I see > >> > >> * repository 3x > >> * mc 3x > >> * src 1x (not smalltalk code) > >> > >> And the rest of the github uses a variety of options > >> > >> * nothing > >> - imho disorganized and very messy if you have several packages > >> * repository > >> - I've been using it and recommending it for ~2 years; also used by > filetree and metacello repos ;) > >> - Argument could be made that git is already a repository so it could > be confusing > >> * mc > >> - because MontiCello/MetaCello I guess? I don't know how much this > makes sense in the light of Iceberg > >> * src > >> - quite common in other programming languages > >> * packages > >> - well, the folder does contain just packages > >> > >> Someone could mine github to find precise numbers... but current usage > shouldn't be a deciding factor. > >> > >> Peter > >> > >>> > >>> 2017-07-07 16:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > >>> > >>>> I used the git migration tool of Peter Uhnak to migrate Beacon from > >>>> smalltalkhub to github. It is available now here > >>>> > >>>> https://github.com/pharo-project/pharo-beacon > >>>> > >>>> I just need to know how I can switch a smalltalkhub project to > read-only. > >>>> > >>>> FYI, > >>>> > >>>> Norbert > >>>> > >>>> > >> > > > > > > >

July 8, 2017

Re: [Pharo-dev] Beacon moved to github

by Stephane Ducasse

We should write the convention somewhere too :) On Sat, Jul 8, 2017 at 12:17 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> On 8 Jul 2017, at 09:29, Tim Mackinnon <tim(a)testit.works> wrote: >> >> Hi Peter - I just hit this yesterday with your kind help deciphering SmalltalkCI, and I have to confess that "src" was my inclination over repository for the reason you mention in that it is a repository already. >> >> I noticed other STCi projects have used "packages" . >> >> I would vote for "src" so other newcomers more easily understand what it is compared to where they came from. > > yes, I agreeâ¦ even if at first is me the one who used mc, I think âsrcâis better convention, now (thatâs why pharo is using it :P) > > Esteban > >> >> I also think it would be helpful for iceberg to default to using that so we get some consistency? >> >> Tim >> >> Sent from my iPhone >> >>> On 7 Jul 2017, at 17:03, Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> On Fri, Jul 07, 2017 at 04:53:20PM +0200, Denis Kudriashov wrote: >>>> Hi. >>>> >>>> I though it was already done :) >>>> One notice. Should we all follow standard convention on repo structure? >>>> Because source directory in beacon is called "repository" instead "src" >>>> like in other repos. >>> >>> There is no standard convention for Pharo repos on github. >>> >>> In pharo-project I see >>> >>> * repository 3x >>> * mc 3x >>> * src 1x (not smalltalk code) >>> >>> And the rest of the github uses a variety of options >>> >>> * nothing >>> - imho disorganized and very messy if you have several packages >>> * repository >>> - I've been using it and recommending it for ~2 years; also used by filetree and metacello repos ;) >>> - Argument could be made that git is already a repository so it could be confusing >>> * mc >>> - because MontiCello/MetaCello I guess? I don't know how much this makes sense in the light of Iceberg >>> * src >>> - quite common in other programming languages >>> * packages >>> - well, the folder does contain just packages >>> >>> Someone could mine github to find precise numbers... but current usage shouldn't be a deciding factor. >>> >>> Peter >>> >>>> >>>> 2017-07-07 16:45 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >>>> >>>>> I used the git migration tool of Peter Uhnak to migrate Beacon from >>>>> smalltalkhub to github. It is available now here >>>>> >>>>> https://github.com/pharo-project/pharo-beacon >>>>> >>>>> I just need to know how I can switch a smalltalkhub project to read-only. >>>>> >>>>> FYI, >>>>> >>>>> Norbert >>>>> >>>>> >>> >> >> > >

July 8, 2017

Re: [Pharo-dev] Discussing the roadmap

by Stephane Ducasse

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

July 8, 2017