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

Re: [Pharo-dev] catalog seems down?

by Esteban Lorenzano

is online now. but see that *it could* have been offline for a short period of timeâ¦ I added an auto-restart job that checks catalog status each hour, so it may happen that it was down during some time. Esteban > On 24 Sep 2017, at 09:12, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > >

Sept. 24, 2017

Re: [Pharo-dev] Non-deterministic ombu errors

by Stephane Ducasse

Hi jan let us know if you have a reproducible case so that we fix it. Stef On Sat, Sep 23, 2017 at 10:42 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > Hello > > I am having very similar errors from time to time when manually loading code > into Pharo from filetree (gitfiletree), but only in one of my projects which > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very same reason > (not able to find why sometimes the error is there and sometimes is not), I > did not report it yet, but it is quite annoying. Retrying loading the > package helps every time. > > Jan > > > gcotelli wrote >> Hi, >> >> I'm having some non-deterministic errors in the Travis builds, the error >> is >> always something like: >> >> *OmFileStoreReadingError: Reading entry from File @ >> pharo-local/ombu-sessions/Pharo.4p8buz6mww48y1noxrolgwkl1.ombu@17432579: >> Invalid utf8 input detected* >> >> If I retried the build it works without any change. I think it happens >> during the code loading phase. >> >> Is anyone experiencing this issue? >> >> Here's an extract of the travis log: > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 24, 2017

Re: [Pharo-dev] Class side method is missing in obsolete class after the class is removed from system

by Stephane Ducasse

do you know that you can create class silently? so that you do not have to remove them from the log? Stef On Sat, Sep 23, 2017 at 10:33 PM, NicolÃ¡s Papagna Maldonado <nicolas.papagna(a)gmail.com> wrote: > Im writing some tests that needs to create classes dynamically. During the > tearDown phase, i remove these classes using #removeFromSystem. > > I noticed that running these tests became more and more slower as i kept > adding more tests. > Using "Run Profiled" from Test Runner, i found out > ChangesLog>>#logClassRemoved: was responsible of about 43% of the execution > time: > > logClassRemoved: annoucement > annoucement classRemoved acceptsLoggingOfCompilation ifTrue: [ > self logChange: 'Smalltalk globals removeClassNamed: #', > annoucement > classRemoved name > ]. > > Based on that, i overrided #acceptsLoggingOfCompilation on the new classes > to avoid these changes being written down to disk (the classes are > disposable after all), but ChangeSet kept doing it. > > I confirmed this by inspecting annoucement classRemoved > acceptsLoggingOfCompilation which returns true, ignoring the overriding > implementation i provided. > > #acceptsLoggingOfCompilation overriding implementation seems to be lost > during the #removeFromSystem call. Specifically, during Behavior>>#obsolete, > which is called during > > Class>>#obsolete > "Change the receiver and all of its subclasses to an obsolete > class." > self == Object > ifTrue: [^self error: 'Object is NOT obsolete']. > self setName: 'AnObsolete' , self name. > Object class instSize + 1 to: self classSide instSize do: > [:i | self instVarAt: i put: nil]. "Store nil over class > instVars." > self classPool: nil. > self sharedPools: nil. > self hasClassSide ifTrue: [ self theMetaClass obsolete]. <======= > HERE > self propertyAt: #obsolete put: true. > super obsolete. > > When i checked Behavior>>#obsolete, i found out the method dictionary is > emptied, losing my implementation of #acceptsLoggingOfCompilation > > Behavior>>obsolete > "Invalidate and recycle local methods, > e.g., zap the method dictionary if can be done safely." > self canZapMethodDictionary > ifTrue: [self methodDict: self emptyMethodDictionary]. > <======= HERE > self hasTraitComposition ifTrue: [ > self traitComposition traits do: [:each | > each removeUser: self]] > > I don't know if this is by design or not, but it seems that the class that > gets announced when removed, is not exactly the same as the original. > > Any thoughts/recommendations? > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 24, 2017

Re: [Pharo-dev] Calypso question

by Stephane Ducasse

What is the relationship between a cursor and ClyEnvironmentContent and ClyEnvironment? On Sun, Sep 24, 2017 at 9:16 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > On Sat, Sep 23, 2017 at 10:56 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >>>> >>>> another question >>>> >>>> packageScope query: (ClyMessageSenders of: #(do: x)) >>>> >>>> It is returning all the senders of do: and the senders of x >>>> or >>>> returning all the sender of do: and x >>> >>> >>> It returns methods which sent #do: or #x >> >> >> This logic was needed to support "Senders button" when multiple methods are >> selected. I think it is expected behaviour in that case. > > Yes but this is not when you read the code > > packageScope query: (ClyMessageSenders of: #(do: x)) > > > packageScope query: (ClyMessageSenders anyOf: #(do: x)) > > is much clearer because it means what it does. > > > stef > > One day you should try to write documentation on something that you > should reverse engineer first and you will see. > Nothing is clear. > > >> >>> >>> >>>> >>>> >>>> >>>> Stef >>>> >>> >>

Sept. 24, 2017

Re: [Pharo-dev] Calypso question

by Stephane Ducasse

On Sat, Sep 23, 2017 at 10:56 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >>> >>> another question >>> >>> packageScope query: (ClyMessageSenders of: #(do: x)) >>> >>> It is returning all the senders of do: and the senders of x >>> or >>> returning all the sender of do: and x >> >> >> It returns methods which sent #do: or #x > > > This logic was needed to support "Senders button" when multiple methods are > selected. I think it is expected behaviour in that case. Yes but this is not when you read the code packageScope query: (ClyMessageSenders of: #(do: x)) packageScope query: (ClyMessageSenders anyOf: #(do: x)) is much clearer because it means what it does. stef One day you should try to write documentation on something that you should reverse engineer first and you will see. Nothing is clear. > >> >> >>> >>> >>> >>> Stef >>> >> >

Sept. 24, 2017

Re: [Pharo-dev] Calypso question

by Stephane Ducasse

anyOf: means senders of any of the following message = or because of: with a list could mean that you expect to find the senders of all the message in the list. Am I clear? Stef On Sat, Sep 23, 2017 at 10:37 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-09-23 7:54 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> Ok what is localClassScope? > > > From LocalClassScope you will see only things which are defined in class > itself. > > There are also ClassHierarchyScope subclasses. They show you all things > which are visible from related classes depending on what type of hierarchy > they represent (there are ClySubclassScope, ClyInheritedTraitScope, etc). > > I will add this notes to class comments. > > Before I introduced ClassHierarchyScope there was only ClassScope (with > instance side and class side subclasses). Then I extract LocalClassScope. > >> >> >> so may be we should rename it anyOf: > > > I not understand it. > >> >> >> On Fri, Sep 22, 2017 at 9:54 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> > Hi >> > >> > 2017-09-22 20:41 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >> >> >> Hi denis >> >> >> >> I'm doing a pass on the architecture of calypso chapter :) as a way to >> >> force me to understand it better. >> >> >> >> Now I do not understand why the following does not work. >> >> >> >> | env classScope | >> >> env := ClySystemNavigationEnvironment currentImage. >> >> classScope := env selectScope: ClyClassScope of: {Point. Collection}. >> >> classScope allClasses >> >> >> > >> > Probably it is not implemented. Each scope should implement what can be >> > retrieved from it. >> > If something was not needed for browser implementation then it will not >> > work. (I not implemented it). >> > >> > But try also with ClyLocalClassScope. I did little refactoring and it >> > can be >> > not reflected in any doc/comment. >> > >> >> >> >> >> >> another question >> >> >> >> packageScope query: (ClyMessageSenders of: #(do: x)) >> >> >> >> It is returning all the senders of do: and the senders of x >> >> or >> >> returning all the sender of do: and x >> > >> > >> > It returns methods which sent #do: or #x >> > >> >> >> >> >> >> >> >> Stef >> >> >> > >> >

Sept. 24, 2017

catalog seems down?

by Stephane Ducasse

Sept. 24, 2017

Re: [Pharo-dev] Non-deterministic ombu errors

by Jan BlizniÄenko

Hello I am having very similar errors from time to time when manually loading code into Pharo from filetree (gitfiletree), but only in one of my projects which contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very same reason (not able to find why sometimes the error is there and sometimes is not), I did not report it yet, but it is quite annoying. Retrying loading the package helps every time. Jan gcotelli wrote > Hi, > > I'm having some non-deterministic errors in the Travis builds, the error > is > always something like: > > *OmFileStoreReadingError: Reading entry from File @ > pharo-local/ombu-sessions/Pharo.4p8buz6mww48y1noxrolgwkl1.ombu@17432579: > Invalid utf8 input detected* > > If I retried the build it works without any change. I think it happens > during the code loading phase. > > Is anyone experiencing this issue? > > Here's an extract of the travis log: -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 23, 2017

Class side method is missing in obsolete class after the class is removed from system

by NicolÃ¡s Papagna Maldonado

Im writing some tests that needs to create classes dynamically. During the tearDown phase, i remove these classes using #removeFromSystem. I noticed that running these tests became more and more slower as i kept adding more tests. Using "Run Profiled" from Test Runner, i found out ChangesLog>>#logClassRemoved: was responsible of about 43% of the execution time: logClassRemoved: annoucement annoucement classRemoved acceptsLoggingOfCompilation ifTrue: [ self logChange: 'Smalltalk globals removeClassNamed: #', annoucement classRemoved name ]. Based on that, i overrided #acceptsLoggingOfCompilation on the new classes to avoid these changes being written down to disk (the classes are disposable after all), but ChangeSet kept doing it. I confirmed this by inspecting annoucement classRemoved acceptsLoggingOfCompilation which returns true, ignoring the overriding implementation i provided. #acceptsLoggingOfCompilation overriding implementation seems to be lost during the #removeFromSystem call. Specifically, during Behavior>>#obsolete, which is called during Class>>#obsolete "Change the receiver and all of its subclasses to an obsolete class." self == Object ifTrue: [^self error: 'Object is NOT obsolete']. self setName: 'AnObsolete' , self name. Object class instSize + 1 to: self classSide instSize do: [:i | self instVarAt: i put: nil]. "Store nil over class instVars." self classPool: nil. self sharedPools: nil. self hasClassSide ifTrue: [ self theMetaClass obsolete]. <======= HERE self propertyAt: #obsolete put: true. super obsolete. When i checked Behavior>>#obsolete, i found out the method dictionary is emptied, losing my implementation of #acceptsLoggingOfCompilation Behavior>>obsolete "Invalidate and recycle local methods, e.g., zap the method dictionary if can be done safely." self canZapMethodDictionary ifTrue: [self methodDict: self emptyMethodDictionary]. <======= HERE self hasTraitComposition ifTrue: [ self traitComposition traits do: [:each | each removeUser: self]] I don't know if this is by design or not, but it seems that the class that gets announced when removed, is not exactly the same as the original. Any thoughts/recommendations? -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 23, 2017

Re: [Pharo-dev] Calypso question

by Denis Kudriashov

> >> another question >> >> packageScope query: (ClyMessageSenders of: #(do: x)) >> >> It is returning all the senders of do: and the senders of x >> or >> returning all the sender of do: and x >> > > It returns methods which sent #do: or #x > This logic was needed to support "Senders button" when multiple methods are selected. I think it is expected behaviour in that case. > > >> >> >> Stef >> >> >

Sept. 23, 2017