July 2017 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Beacon moved to github

by Esteban Lorenzano

> 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 stephan

On 06-07-17 23:56, Eliot Miranda wrote: > But what I was getting at in my comment was that, while 64-bit server > applications are indeed very important, I have not been contacted by > anyone yet complaining about scaling problems with the 64-bit system. It has been too early to get scaling problems in 64-bit for me. I ran into a lot of the gc bugs you fixed. In what I do (loading a lot of data in the image, adding restructuring information, and creating visualizations), the long GC wait is annoying but perfectly usable. Incremental GC fits perfectly for that use case. Stephan

July 8, 2017