- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cycles lost on startup

by Nicolai Hess

2016-09-06 12:34 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Sep 6, 2016, at 12:25 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-09-06 11:47 GMT+02:00 Henrik Nergaard <henrik.nergaard(a)uia.no>: > >> Rewriting the implementation of #initSelectorTable to: >> >> >> >> SelectorTable := WeakSet withAll: (CompiledMethod allInstances collect: >> [:m | m selector] as: IdentitySet). >> >> >> >> Makes it 20ms faster, so it looks like there is some overhead when using >> WeakSet compared to first use a normal set to remove duplicates. >> >> >> >> Another possibility could be to store the selectors in an >> IdentityDictionary as #selector->count which keep track of how many users >> of a selector there is itself, instead of using a WeakArray. >> >> >> >> Best regards, >> >> Henrik >> > > Maybe we can just move the rebuilding to the image shutdown instead of the > image startup ? > > > That's a much better idea. But only if the image snapshots. There is no > point doing it on an exit without saving. > Is there a way to see whether we are just quitting or "quit & save" in Pharos Session/Shutdown list "shutDown:" method ? > > And just to drive home the point, 70ms is an age in a web server. This > kind of thing really damages Pharo performance in web servers. One wants > startup times in the few tens of milliseconds or better. > > > > >> >> >> *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *On Behalf >> Of *Nicolai Hess >> *Sent:* Monday, September 5, 2016 7:52 PM >> *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> >> *Subject:* Re: [Pharo-dev] Cycles lost on startup >> >> >> >> >> >> >> >> 2016-09-05 18:37 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> Hi All, >> >> >> >> we are simulating a full block Pharo image derived from Pharo 6. On >> startup we see a very sad loss of cycles due to a very slow rebuild of the >> selector table in Symbol class. Why is this done at each startup? Here is >> the stack: >> >> >> >> 16r107154 M ByteString class(ProtoObject)>identityHash 16r786AE8: a(n) >> ByteString class >> >> 16r10716C M ByteString class(Object)>hash 16r786AE8: a(n) ByteString >> class >> >> 16r10718C M ByteSymbol(String)>hash 16rE6A5C8: a(n) ByteSymbol >> >> 16r1071B0 M WeakSet>scanForEmptySlotFor: 16r26B968: a(n) WeakSet >> >> 16r1071DC M WeakSet>noCheckNoGrowFillFrom: 16r26B968: a(n) WeakSet >> >> 16r1071FC M WeakSet>growTo: 16r26B968: a(n) WeakSet >> >> 16r10721C M WeakSet>grow 16r26B968: a(n) WeakSet >> >> 16r107234 M WeakSet(HashedCollection)>fullCheck 16r26B968: a(n) WeakSet >> >> 16r10724C M WeakSet(HashedCollection)>atNewIndex:put: 16r26B968: a(n) >> WeakSet >> >> 16r107274 M WeakSet>add: 16r26B968: a(n) WeakSet >> >> 16r107294 M [] in Symbol class>(nil) 16r1D319A8: a(n) Symbol class >> >> 16r1072B8 M Array(SequenceableCollection)>do: 16r3C17370: a(n) Array >> >> 16r1072E8 I CompiledMethod class(Behavior)>allInstancesDo: 16r164E260: >> a(n) CompiledMethod class >> >> 16r10730C I Symbol class>initSelectorTable 16r1D319A8: a(n) Symbol class >> >> 16r10732C I Symbol class>selectorTable 16r1D319A8: a(n) Symbol class >> >> 16r107350 I Symbol class>internSelector: 16r1D319A8: a(n) Symbol class >> >> 16r10737C I CompiledMethod>selector: 16r26AB58: a(n) CompiledMethod >> >> 16r1073A4 I IRMethod>generate: 16r25A030: a(n) IRMethod >> >> 16r1073CC I FFICalloutMethodBuilder>generateMethodFromSpec: 16r255580: >> a(n) FFICalloutMethodBuilder >> >> 16r1073F0 I FFICalloutMethodBuilder>generate 16r255580: a(n) >> FFICalloutMethodBuilder >> >> 16r1030C8 I FFICalloutMethodBuilder>build: 16r255580: a(n) >> FFICalloutMethodBuilder >> >> 16r1030F4 I FFICalloutAPI>function:module: 16r255568: a(n) FFICalloutAPI >> >> 16r10311C I UnixEnvironment(Object)>ffiCall:module: 16r3816180: a(n) >> UnixEnvironment >> >> 16r103144 I UnixEnvironment(OSEnvironment)>getEnv: 16r3816180: a(n) >> UnixEnvironment >> >> 16r103168 I UnixEnvironment(OSEnvironment)>at:ifAbsent: 16r3816180: >> a(n) UnixEnvironment >> >> 16r10318C M [] in MacOSResolver>(nil) 16r241170: a(n) MacOSResolver >> >> 16r1031A4 M FullBlockClosure(BlockClosure)>on:do: 16r2553F0: a(n) >> FullBlockClosure >> >> 16r1031D0 I MacOSResolver(PlatformResolver >> )>directoryFromEnvVariableNamed:or: 16r241170: a(n) MacOSResolver >> >> 16r1031F8 I MacOSResolver(PlatformResolver >> )>directoryFromEnvVariableNamed: 16r241170: a(n) MacOSResolver >> >> 16r10321C I MacOSResolver>home 16r241170: a(n) MacOSResolver >> >> 16r10323C I MacOSResolver>userLibrary 16r241170: a(n) MacOSResolver >> >> 16r103254 M MacOSResolver>userApplicationSupport 16r241170: a(n) >> MacOSResolver >> >> 16r10326C M MacOSResolver(FileSystemResolver)>resolve: 16r241170: a(n) >> MacOSResolver >> >> 16r103288 M SystemResolver(FileSystemResolver)>unknownOrigin: >> 16r240D30: a(n) SystemResolver >> >> 16r1032A4 M SystemResolver(FileSystemResolver)>resolve: 16r240D30: >> a(n) SystemResolver >> >> 16r1032C4 M InteractiveResolver>unknownOrigin: 16r240CF0: a(n) >> InteractiveResolver >> >> 16r1032E4 M [] in InteractiveResolver>(nil) 16r240CF0: a(n) >> InteractiveResolver >> >> 16r103300 M IdentityDictionary(Dictionary)>at:ifAbsent: 16r240D00: >> a(n) IdentityDictionary >> >> 16r103320 M InteractiveResolver>resolve: 16r240CF0: a(n) >> InteractiveResolver >> >> 16r10333C M FileLocator>resolve 16r255258: a(n) FileLocator >> >> 16r103354 M FileLocator(AbstractFileReference)>exists 16r255258: a(n) >> FileLocator >> >> 16r10337C M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r103398 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r1033B0 M FullBlockClosure(BlockClosure)>on:do: 16r255190: a(n) >> FullBlockClosure >> >> 16r1033D0 M FullBlockClosure(BlockClosure)>ifError: 16r255190: a(n) >> FullBlockClosure >> >> 16r1033EC M PharoFilesOpener>ignoreIfFail: 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r102188 M [] in PharoFilesOpener>(nil) 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r1021AC M Array(SequenceableCollection)>do: 16r2495E8: a(n) Array >> >> 16r1021DC I PharoFilesOpener>openSources:forImage: 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r102204 I PharoFilesOpener>openSources 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r102228 I PharoFilesOpener>sourcesFileOrNil 16rE79FD8: a(n) >> PharoFilesOpener >> >> 16r10224C I SourceFileArray>ensureOpen 16r8AA128: a(n) SourceFileArray >> >> 16r10226C I SmalltalkImage>openSourceFiles 16rA58A28: a(n) >> SmalltalkImage >> >> 16r10228C I SmalltalkImage class>startUp: 16rFDA6A8: a(n) >> SmalltalkImage class >> >> 16r1022A8 M ClassSessionHandler>startup: 16r8B8978: a(n) >> ClassSessionHandler >> >> 16r1022C8 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession >> >> 16r1022EC M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession >> >> 16r102304 M FullBlockClosure(BlockClosure)>on:do: 16r245640: a(n) >> FullBlockClosure >> >> 16r102328 M [] in WorkingSession>(nil) 16r1A45D0: a(n) WorkingSession >> >> 16r10234C M Array(SequenceableCollection)>do: 16r1A47B8: a(n) Array >> >> 16r102370 I WorkingSession>runList:do: 16r1A45D0: a(n) WorkingSession >> >> 16r102398 I WorkingSession>runStartup: 16r1A45D0: a(n) WorkingSession >> >> 16r1023BC I WorkingSession>start: 16r1A45D0: a(n) WorkingSession >> >> 16r1023E8 I SessionManager>snapshot:andQuit: 16r17AA950: a(n) >> SessionManager >> >> >> >> You'll see that Symbol class>selectorTable calls Symbol class> >> initSelectorTable which then calls CompiledMethod >> class(Behavior)>allInstancesDo: to enumerate over all methods. This >> takes a significant amount of time, even on a fast machine. For example, >> on a 2.%GHz machine this takes about 70 milliseconds. That's a /lot/ of >> time to squander on startup. And it will grow the larger the image is. >> >> >> >> Hm, I didn't thought about that. >> >> >> >> >> >> The selector table seems to be discarded on shut-down, which seems >> pointless. If one wants to recompute the table then before or after >> methods are added or removed seems like a better choice, not on every image >> startup. >> >> >> >> I think I wanted to be on the save side and just discard on shutdown and >> rebuild on startup to be sure to have the correct set of selector symbols. >> >> >> >> >> >> In around 2000 we were able to startup VisualWorks images in about 40 >> milliseconds on the hardware available at the time. I hope someone >> reconsiders this code and a avoids recomputing the selector table on each >> startup. >> >> >> >> I will take a look and try to find a better way. >> >> nicolai >> >> >> >> _,,,^..^,,,_ >> >> best, Eliot >> >> >> > >

Sept. 8, 2016

Latest Configuration of XPath is broken

by Henrik Nergaard

Hi, Trying to load XPath using the latest configuration (ConfigurationOfXPath-monty.91) gives the following error: MetacelloProjectSpecLoadError: No version found for #'release-2.8.7' of ConfigurationOfXMLParser because: The symbolic version #'release-2.8.7' is not defined in ConfigurationOfXMLParser for the current platform. Possible symbolic version values include: #(#bleedingEdge #development #'release-2' #'release-2.4' #'release-2.5' #'release-2.5.3' #'release-2.5.5' #'release-2.6' #'release-2.6.3' #'release-2.6.5' #'release-2.6.8' #'release-2.7.3' #'release-2.7.4' #'release-2.7.6' #'release-2.7.7' #'release-2.8.1' #'release-2.8.3' #'release-2.8.6' #stable) ConfigurationOfXPath-monty.90 loads fine. Best regards, Henrik

Sept. 8, 2016

Re: [Pharo-dev] Ombu losing file on folder renaming

by Damien Pollet

The path you copied corresponds to before, or after the rename ? On 8 September 2016 at 09:27, stepharo <stepharo(a)free.fr> wrote: > Hi Martin > > I often get > > Information > Ombu: Couldn't write entry, since FileDoesNotExist: File @ > /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/ > PharoHarvestingFixes/60/current/pharo-local/ombu-sessions/ > Pharo_ajxqkxc.ombu > > And this happens when I save and close the image, renamed the folder and > reopen the image. > > Stef > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Sept. 8, 2016

Re: [Pharo-dev] [Pharo-users] Small OS-... project addition

by Esteban Lorenzano

> On 08 Sep 2016, at 15:55, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Pretty cool! > Is it available from the catalog? > > Alexandre > > >> On Sep 8, 2016, at 4:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi, >> >> now also the OSX project in the OS series [1] has support to >> >> - directly open a terminal >> - directly open a file browser (Finder) on the working directory >> >> right from the Pharo tools menu. See attached screenshot. >> >> Depending on your platform just load >> >> - OSOSX >> - OSWindows >> - OSLinuxUbuntu >> - OSLinuxCentOS >> >> from catalog. ^ this :) >> >> Bye >> T. >> >> >> [1] http://smalltalkhub.com/#!/~OS<OSMenu.png> > >

Sept. 8, 2016

Re: [Pharo-dev] [Pharo-users] Small OS-... project addition

by Alexandre Bergel

Pretty cool! Is it available from the catalog? Alexandre > On Sep 8, 2016, at 4:06 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > now also the OSX project in the OS series [1] has support to > > - directly open a terminal > - directly open a file browser (Finder) on the working directory > > right from the Pharo tools menu. See attached screenshot. > > Depending on your platform just load > > - OSOSX > - OSWindows > - OSLinuxUbuntu > - OSLinuxCentOS > > from catalog. > > Bye > T. > > > [1] http://smalltalkhub.com/#!/~OS<OSMenu.png>

Sept. 8, 2016

Deactivated Locale Still Sets TimeZone

by Sean P. DeNigris

I was surprised to find that Pharo kept setting my local offset, even though I explicitly set it to UTC and then made sure Locale was disabled. Then I saw: Locale class>>#startUp: resuming ... DateAndTime localTimeZone: self localTimeZone. (self activated) ifTrue: [ First it does some work, and then it checks to see whether it's activated! I propose to move the first line into the subsequent block, or maybe better yet - move that behavior into DateAndTime itself. Thoughts? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Deactivated-Locale-Still-Sets-TimeZone-tp4914754.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 8, 2016

Re: [Pharo-dev] SystemLogger in Pharo 5

by Sean P. DeNigris

NorbertHartl wrote > Since 20 minutes there is :) Ha ha, thanks! ----- Cheers, Sean -- View this message in context: http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695p4914752.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 8, 2016

Re: [Pharo-dev] SystemLogger in Pharo 5

by Norbert Hartl

> Am 08.09.2016 um 14:24 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > NorbertHartl wrote >> I started today to build my first project using Beacon instead of >> SystemLogger > > That's what I ended up doing as well and it fit my needs nicely. I just > loaded the #development version as there is no #stable declared for Pharo > 5.0. > > Since 20 minutes there is :) Remember to load ConfigurationOfBeacon and not ConfigurationOfBeaconCore. If you loaded the stable before please note that quite some things have changed. Norbert

Sept. 8, 2016

Re: [Pharo-dev] SystemLogger in Pharo 5

by Sean P. DeNigris

NorbertHartl wrote > I started today to build my first project using Beacon instead of > SystemLogger That's what I ended up doing as well and it fit my needs nicely. I just loaded the #development version as there is no #stable declared for Pharo 5.0. ----- Cheers, Sean -- View this message in context: http://forum.world.st/SystemLogger-in-Pharo-5-tp4914695p4914747.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 8, 2016

Re: [Pharo-dev] FileDoesNotExist vs. FileDoesNotExistException

by Esteban Lorenzano

> On 08 Sep 2016, at 09:03, Guille Polito <guillermopolito(a)gmail.com> wrote: > > I'd argue also for consistency. When some exceptions are named "Exception" and others are not, my eyes hurt. +1 > > -------- Original Message -------- >> My very first thoughts are... >> >> On Thu, Sep 8, 2016 at 3:35 AM, stepharo <stepharo(a)free.fr> wrote: >>> Hi guys >>> >>> in >>> https://pharo.fogbugz.com/f/cases/19026/Merge-FileDoesNotExist-and-FileDoes… >>> sven proposed to have >>> >>> FileDoesNotExist and remove the FileDoesNotExistException >> This seems quite reasonable. It would be very hard to confuse the >> semantics of FileDoesNotExist with something else. Also this is >> probably something end-user-devs will use more frequently in their >> application, so less verbose is better. >> >> The only thing that crosses my mind is perhaps discoverability... in >> Spotter searching on "File" the drilling into classes and searching on >> "Exception". Oh I just tried in Pharo 5 and it worked, there are >> four. The other way to handle that might be for Spotter to have a >> "KindOf" search. >> >> btw, in the Spotter preview pane when a class is selected, could the >> class comment be displayed? >> >>> Before doing it I would like to have your point of view on the names. For >>> now I'm neutral and indeed if we apply it to exception >>> >>> it seems to work for announcement. Now in Spec I was planning to put nearly >>> systematically Presenter at the end of Presenters :). >> Spec has more interrelated design pattern components. Its seems there >> has been some confusion around the nomenclature of these components. >> So the additional hint is probably beneficial. >> >> cheers -ben >> > >

Sept. 8, 2016