- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Epicea and #name in #behaviorAffectedName

by Martin Dias

Hi Torsten, just copied your report into here: https://pharo.fogbugz.com/f/cases/20222/Epicea-deprecation-warning-dialog-p… I'll see it ASAP. Thanks and sorry for my delay. MartÃn El 19/5/2017 17:45, "Torsten Bergmann" <astares(a)gmx.de> escribiÃ³: > Hi, > > in latest Pharo 6 image 60494 I run into some trouble today where the > deprecation warning dialog popped up and repeated itself unstoppable > due to Epicea. > > It is hard to reproduce but what I found out was that I had a class > modification (represented by EpClassModification) which run into a state > where "newClass" was nil and therefore in EpClassModification>>#behavior > AffectedName > the message #name was sent to nil. > > So #name was found in Object and as we all know we deprecated it now > which lead to the deprecation dialog, leading to the deprecation dialog, > leading to the deprecation dialog, ... > > Nearly all implementors of Epiceas #behaviorAffectedName send #name > which is ok if there is a valid object it is sent to. > > I do not know if we should protect them somehow in case something > goes wrong (like having nil in newClass) or if we should keep this > untouched. > > At least I wanted to inform because I do not know if this later > gets others into trouble too and losing their changes because Epicea > does not record. > > Thanks > T. > >

July 6, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60507 Home: https://github.com/pharo-project/pharo-core

July 6, 2017

[pharo-project/pharo-core] 9b87bb: 60507

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 9b87bb71fd929f5f2af417887b3598f79784ae60 https://github.com/pharo-project/pharo-core/commit/9b87bb71fd929f5f2af41788… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-07-06 (Thu, 06 Jul 2017) Changed paths: M Jobs.package/Job.class/class/examples/exampleCurrentValue.st M Kernel.package/Context.class/class/simulation/runSimulated_.st M Monticello.package/MCMcdReader.class/instance/loading/loadPatch.st M Monticello.package/MCMczReader.class/instance/loading/loadDefinitions.st M Monticello.package/MCPatch.class/instance/intializing/initializeWithBase_target_.st M Monticello.package/MCVersion.class/instance/enumerating/withAllDependenciesDo_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60506.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60507.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60506.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60507.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Text-Core.package/Text.class/class/initialization/initialize.st M Traits.package/TBehaviorCategorization.class/instance/organization/category.st M UnifiedFFI.package/FFISizeT.class/class/converting/asExternalTypeOn_.st Log Message: ----------- 60507 20218 Master branch (Pharo 6) needs to be safely merged into development branch (Pharo 7). https://pharo.fogbugz.com/f/cases/20218 http://files.pharo.org/image/60/60507.zip

July 6, 2017

Re: [Pharo-dev] OSPlatform currentVersion

by Norbert Hartl

Ok, it works in the 7.0 vm. I opened the ticket again in order that we do not forget the fix for 6.1 https://pharo.fogbugz.com/f/cases/20156/OSPlatform-current-returns-a-MacOSP… <https://pharo.fogbugz.com/f/cases/20156/OSPlatform-current-returns-a-MacOSP…> Norbert > Am 06.07.2017 um 14:29 schrieb Norbert Hartl <norbert(a)hartl.name>: > > Ok, then it is a regression because I downloaded vm and image freshly before trying > > thanks, > > Norbert > >> Am 06.07.2017 um 14:15 schrieb Alistair Grant <akgrant0710(a)gmail.com>: >> >> Hi Norbet, >> >> Take a look at: >> >> http://forum.world.st/Working-OSProcess-configuration-for-Pharo-6-release-p… >> >> HTH, >> Alistair >> >> >> On 6 July 2017 at 14:06, Norbert Hartl <norbert(a)hartl.name> wrote: >>> Does anyone know when the output for >>> >>> OSPlatform currentVersion >>> >>> changed? In Pharo 4 I get >>> >>> '1095' >>> >>> and in pharo6 I get >>> >>> '10.12.5'. >>> >>> The determination if it is a OSX system or older is done by >>> >>> currentVersion asNumber >= 1000 >>> >>> which changes behaviour because the currentVersion string has been changed. >>> Is the output the one supposed to be? >>> >>> Norbert >>> >>>

July 6, 2017

Re: [Pharo-dev] OSPlatform currentVersion

by Norbert Hartl

Ok, then it is a regression because I downloaded vm and image freshly before trying thanks, Norbert > Am 06.07.2017 um 14:15 schrieb Alistair Grant <akgrant0710(a)gmail.com>: > > Hi Norbet, > > Take a look at: > > http://forum.world.st/Working-OSProcess-configuration-for-Pharo-6-release-p… > > HTH, > Alistair > > > On 6 July 2017 at 14:06, Norbert Hartl <norbert(a)hartl.name> wrote: >> Does anyone know when the output for >> >> OSPlatform currentVersion >> >> changed? In Pharo 4 I get >> >> '1095' >> >> and in pharo6 I get >> >> '10.12.5'. >> >> The determination if it is a OSX system or older is done by >> >> currentVersion asNumber >= 1000 >> >> which changes behaviour because the currentVersion string has been changed. >> Is the output the one supposed to be? >> >> Norbert >> >>

July 6, 2017

Re: [Pharo-dev] OSPlatform currentVersion

by Alistair Grant

Hi Norbet, Take a look at: http://forum.world.st/Working-OSProcess-configuration-for-Pharo-6-release-p… HTH, Alistair On 6 July 2017 at 14:06, Norbert Hartl <norbert(a)hartl.name> wrote: > Does anyone know when the output for > > OSPlatform currentVersion > > changed? In Pharo 4 I get > > '1095' > > and in pharo6 I get > > '10.12.5'. > > The determination if it is a OSX system or older is done by > > currentVersion asNumber >= 1000 > > which changes behaviour because the currentVersion string has been changed. > Is the output the one supposed to be? > > Norbert > >

July 6, 2017

OSPlatform currentVersion

by Norbert Hartl

Does anyone know when the output for OSPlatform currentVersion changed? In Pharo 4 I get '1095' and in pharo6 I get '10.12.5'. The determination if it is a OSX system or older is done by currentVersion asNumber >= 1000 which changes behaviour because the currentVersion string has been changed. Is the output the one supposed to be? Norbert

July 6, 2017

Re: [Pharo-dev] Discussing the roadmap

by Pavel Krivanek

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 6, 2017

Re: [Pharo-dev] Simply Happy

by Dimitris Chloupis

Pharo is finally in a mature state. I would not recommend Pharo few years back because of severe lack of documentation and libraries and several other issues.I would definetly recommend it now to people who want to try something fresh and well designed. Documentation is in much better state, new libraries pop up like mushroom old ones have matured to very stable , reliable and flexible. I dont have hopes that Pharo will be in the top 10 of popular languages but entering the top 100 is definetly not far away if we are not already there. 99.9% of programming languages never ever come close to that. On the other hand I dont want Pharo to become too popular because popularity comes usually with the price of huge compromises. So we are definetly close to what I call "the sweet spot". Glad to be part of the family, keep the great work going and well done :) On Thu, Jul 6, 2017 at 12:22 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > +42 > > > On 6 Jul 2017, at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > +100 > > > > Doru > > > > > >> On Jul 6, 2017, at 10:57 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> Hi pharoing people > >> > >> Just a little word to tell you that I'm super happy about the future of > Pharo. > >> The consortium is growing and will probably be able to pay esteban and > clement. > >> The roadmap for Pharo 70 is really exciting. > >> The bootstrap, git and the new project in the pipe will boost us. > >> So I wanted to thanks you all for all this super great energy. > >> > >> We (you and us) are building a super cool future. > >> > >> Stef > >> > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Every successful trip needs a suitable vehicle." > > > > > > > > > > > > > > >

July 6, 2017

Re: [Pharo-dev] Simply Happy

by Sven Van Caekenberghe

+42 > On 6 Jul 2017, at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > +100 > > Doru > > >> On Jul 6, 2017, at 10:57 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi pharoing people >> >> Just a little word to tell you that I'm super happy about the future of Pharo. >> The consortium is growing and will probably be able to pay esteban and clement. >> The roadmap for Pharo 70 is really exciting. >> The bootstrap, git and the new project in the pipe will boost us. >> So I wanted to thanks you all for all this super great energy. >> >> We (you and us) are building a super cool future. >> >> Stef >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > >

July 6, 2017