- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ExternalSemaphoreTable curious garbageCollect

by Ben Coman

On Thu, Sep 22, 2016 at 2:54 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > The semaphores are strongly held, but not the objects that put them there. > Sockets are the main users of the table. > Sockets are finalized by removing registered semaphores from the table. > Garbage collect triggers finalization. > > Hence, garbage collect can result in slots being freed. Gotcha.Thanks for that insight. Socket>>finalize self primSocketDestroyGently: socketHandle. Smalltalk unregisterExternalObject: semaphore. Smalltalk unregisterExternalObject: readSemaphore. Smalltalk unregisterExternalObject: writeSemaphore. cheers -ben

Sept. 22, 2016

Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide)

by Sven Van Caekenberghe

> On 22 Sep 2016, at 00:19, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > thanks. Did not notice that I need three instead of two slashes. So no need > to explicitly convert to ZnUrl. > > So for the records this is what works: > > > pathToPackageDirectory := 'C:\ClonedRepo\packages'. > Metacello new > baseline: 'MyProject'; > repository: ('gitfiletree:///', pathToPackageDirectory) ; > load. So mixing back & forward slashes works ? Pretty weird ;-) > Thanks > T. > >> Gesendet: Dienstag, 20. September 2016 um 20:41 Uhr >> Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> >> An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Betreff: Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide) >> >> Hi Torsten, >> >> Just for the ZnUrl part, have a look at >> >> ZnFileUrlTests>>#testWindowsDriveNamesInFileUrl >> >> AFAIK, your example should be written as: >> >> ('filetree:///' , 'C:/ClonedRepo/packages') asZnUrl. >> >> Or maybe, >> >> (FileLocator C / 'ClonedRepo' / 'packages') asZnUrl. >> >> Sven >> >>> On 20 Sep 2016, at 20:30, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> Hi, >>> >>> according to the Metacello quide on [1] in section "Prime Metacello registry" one can write >>> >>> | pathToPackageDirectory | >>> "edit to match the path to your chosen package directory" >>> pathToPackageDirectory := '/opt/git/Sample/packages'. >>> Metacello new >>> baseline: 'Sample'; >>> repository: 'filetree://', pathToPackageDirectory; >>> load. >>> >>> Adopting this for a Windows path I have: >>> >>> | pathToPackageDirectory | >>> pathToPackageDirectory := 'C:\ClonedRepo\packages'. >>> Metacello new >>> baseline: 'MyProject'; >>> repository: 'filetree://', pathToPackageDirectory; >>> load. >>> >>> But I get a ZnPortNotANumber exception, even when I use a diffent protocol like "client://". >>> Tried this in Pharo 6.0 Latest update: #60233 >>> >>> What I want to do (on Windows) is to load all project packages from a local cloned git >>> directory (not a remote GitHub) using the dependencies given in the Baseline. >>> >>> Did I miss something, is it just broken or the docu not up to date? If so is this a parsing issue on the Zinc URLs >>> or an issue of Metacello API? >>> >>> Thanks >>> T. >>> >>> [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… >>> >> >> >> >

Sept. 22, 2016

Re: [Pharo-dev] ExternalSemaphoreTable curious garbageCollect

by Henrik Sperre Johansen

The semaphores are strongly held, but not the objects that put them there. Sockets are the main users of the table. Sockets are finalized by removing registered semaphores from the table. Garbage collect triggers finalization. Hence, garbage collect can result in slots being freed. Cheers, Henry -- View this message in context: http://forum.world.st/ExternalSemaphoreTable-curious-garbageCollect-tp49165… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 22, 2016

ExternalSemaphoreTable curious garbageCollect

by Ben Coman

A curiosity I can't work out and maybe I can learn something... ExternalSemaphoreTable unprotectedExternalObjects class ==> Array so in #freedSlotsIn:ratherThanIncreaseSizeTo: how does the garbageCollect manage to free slots given that the Array holds strongly to its elements? cheers -ben

Sept. 22, 2016

Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide)

by Torsten Bergmann

Hi Sven, thanks. Did not notice that I need three instead of two slashes. So no need to explicitly convert to ZnUrl. So for the records this is what works: pathToPackageDirectory := 'C:\ClonedRepo\packages'. Metacello new baseline: 'MyProject'; repository: ('gitfiletree:///', pathToPackageDirectory) ; load. Thanks T. > Gesendet: Dienstag, 20. September 2016 um 20:41 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] ZnPortNotANumber exception when loading from local clone dir (following Metacello Guide) > > Hi Torsten, > > Just for the ZnUrl part, have a look at > > ZnFileUrlTests>>#testWindowsDriveNamesInFileUrl > > AFAIK, your example should be written as: > > ('filetree:///' , 'C:/ClonedRepo/packages') asZnUrl. > > Or maybe, > > (FileLocator C / 'ClonedRepo' / 'packages') asZnUrl. > > Sven > > > On 20 Sep 2016, at 20:30, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > according to the Metacello quide on [1] in section "Prime Metacello registry" one can write > > > > | pathToPackageDirectory | > > "edit to match the path to your chosen package directory" > > pathToPackageDirectory := '/opt/git/Sample/packages'. > > Metacello new > > baseline: 'Sample'; > > repository: 'filetree://', pathToPackageDirectory; > > load. > > > > Adopting this for a Windows path I have: > > > > | pathToPackageDirectory | > > pathToPackageDirectory := 'C:\ClonedRepo\packages'. > > Metacello new > > baseline: 'MyProject'; > > repository: 'filetree://', pathToPackageDirectory; > > load. > > > > But I get a ZnPortNotANumber exception, even when I use a diffent protocol like "client://". > > Tried this in Pharo 6.0 Latest update: #60233 > > > > What I want to do (on Windows) is to load all project packages from a local cloned git > > directory (not a remote GitHub) using the dependencies given in the Baseline. > > > > Did I miss something, is it just broken or the docu not up to date? If so is this a parsing issue on the Zinc URLs > > or an issue of Metacello API? > > > > Thanks > > T. > > > > [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/GettingStart… > > > > >

Sept. 22, 2016

Re: [Pharo-dev] [Vm-dev] PrimitiveFailed: primitive #elementsForwardIdentityTo: in Array failed

by HernÃ¡n Morales Durand

Thank you Henrik, I will wait to a new stable version as the problem does not affect too much my workflow. Cheers, HernÃ¡n 2016-09-21 6:03 GMT-03:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > Yes, you need a new VM built from Cog sources after June, hopefully a > newer can be promoted to stable soon... > > https://pharo.fogbugz.com/f/cases/18711/Cannot-commit-a- > special-character-into-Monticello > > Cheers, > Henry > > > > > On 21 Sep 2016, at 7:19 , HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > Hi > > > > I don't know if this was reported. Apparently there is a problem when > migrating a large number of instances, I have aprox. 270,000 instances from > which I simply pulled up an ivar in their class to a higher superclass, and > a PrimitiveFailed raised. > > > > It can be reproduced by installing Territorial in Pharo 5.0 with Spur VM > 5.0 from 4 May 2016 in Windows 8.1 (this is the standard image installed > using wget command line in msys). > > > > Gofer it > > smalltalkhubUser: 'hernan' project: 'Territorial'; > > configuration; > > loadDevelopment. > > TCityOrganization addOpenGeoCode > > > > Then manually install Territorial-HernanMoralesDurand.163 from > Monticello. Backwards (installing .163, populating, then .166) also > reproduces the issue. > > > > Is there a fix for this? > > > > --- The full stack --- > > Array(Object)>>primitiveFailed: > > Array(Object)>>primitiveFailed > > Array>>elementsForwardIdentityTo: > > TerritorialCity class(ClassDescription)>>updateInstances:from:isMeta: > > TerritorialCity class(ClassDescription)>>updateInstancesFrom: > > PharoClassInstaller>>updateClass:to: > > [ 1 to: old size do: [ :index | self updateClass: (old at: index) to: > (new at: index) ]. > > old elementsForwardIdentityTo: new. > > " Garbage collect away the zombie instances left behind in garbage > memory in #updateInstancesFrom: " > > " If we don't clean up this garbage, a second update would revive them > with a wrong layout! " > > " (newClass rather than oldClass, since they are now both newClass) " > > Smalltalk garbageCollect ] in PharoClassInstaller>> > migrateClasses:to:using: > > BlockClosure>>ensure: > > BlockClosure>>valueUnpreemptively > > PharoClassInstaller>>migrateClasses:to:using: > > SlotClassBuilder>>migrateClasses: > > SlotClassBuilder>>apply: > > SlotClassBuilder>>build > > PharoClassInstaller class(AbstractClassInstaller class)>>make: > > [ PharoClassInstaller > > make: [ :builder | > > builder > > superclass: superClass; > > name: name; > > layoutClass: (ObjectLayout layoutForType: type); > > slots: self instanceVariables; > > sharedVariables: self classVariables; > > sharedPools: self sharedPoolsString; > > classSlots: self classInstanceVariables; > > traitComposition: self traitCompositionCompiled; > > classTraitComposition: self classTraitCompositionCompiled; > > comment: comment stamp: commentStamp; > > category: category; > > environment: superClass environment ] ] in > MCClassDefinition>>createClass > > BlockClosure>>on:do: > > MCClassDefinition>>createClass > > MCClassDefinition>>load > > MCClassDefinition(MCDefinition)>>addMethodAdditionTo: > > [ :each | each addMethodAdditionTo: methodAdditions ] in > MCPackageLoader>>basicLoadDefinitions > > [ :each | > > | newLabel | > > "Special handling for first and last element" > > (count = 0 > > or: [ count + 1 = size > > or: [ (Time millisecondsSince: lastUpdate) >= msecs ] ]) > > ifTrue: [ bar current: count. > > oldLabel = (newLabel := (labelBlock cull: each) ifNil: [ > oldLabel ]) > > ifFalse: [ bar label: newLabel. > > oldLabel := newLabel ]. > > lastUpdate := Time millisecondClockValue ]. > > aBlock value: each. > > count := count + 1 ] in [ :bar | > > labelBlock := aStringOrBlock isString > > ifTrue: [ bar label: aStringOrBlock. > > [ :dummyItem | aStringOrBlock ] ] > > ifFalse: [ aStringOrBlock ]. > > self > > do: [ :each | > > | newLabel | > > "Special handling for first and last element" > > (count = 0 > > or: [ count + 1 = size > > or: [ (Time millisecondsSince: lastUpdate) >= msecs > ] ]) > > ifTrue: [ bar current: count. > > oldLabel > > = (newLabel := (labelBlock cull: each) ifNil: [ > oldLabel ]) > > ifFalse: [ bar label: newLabel. > > oldLabel := newLabel ]. > > lastUpdate := Time millisecondClockValue ]. > > aBlock value: each. > > count := count + 1 ] ] in OrderedCollection(Collection)> > >do:displayingProgress:every: > > OrderedCollection>>do: > > [ :bar | > > labelBlock := aStringOrBlock isString > > ifTrue: [ bar label: aStringOrBlock. > > [ :dummyItem | aStringOrBlock ] ] > > ifFalse: [ aStringOrBlock ]. > > self > > do: [ :each | > > | newLabel | > > "Special handling for first and last element" > > (count = 0 > > or: [ count + 1 = size > > or: [ (Time millisecondsSince: lastUpdate) >= msecs > ] ]) > > ifTrue: [ bar current: count. > > oldLabel > > = (newLabel := (labelBlock cull: each) ifNil: [ > oldLabel ]) > > ifFalse: [ bar label: newLabel. > > oldLabel := newLabel ]. > > lastUpdate := Time millisecondClockValue ]. > > aBlock value: each. > > count := count + 1 ] ] in OrderedCollection(Collection)> > >do:displayingProgress:every: > > BlockClosure>>cull: > > [ ^ block cull: self ] in [ self prepareForRunning. > > CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run > > [ p psValueAt: index put: anObject. > > aBlock value ] in CurrentJob(DynamicVariable)>>value:during: > > BlockClosure>>ensure: > > CurrentJob(DynamicVariable)>>value:during: > > CurrentJob class(DynamicVariable class)>>value:during: > > [ self prepareForRunning. > > CurrentJob value: self during: [ ^ block cull: self ] ] in Job>>run > > BlockClosure>>ensure: > > Job>>run > > MorphicUIManager(UIManager)>>displayProgress:from:to:during: > > ByteString(String)>>displayProgressFrom:to:during: > > OrderedCollection(Collection)>>do:displayingProgress:every: > > OrderedCollection(Collection)>>do:displayingProgress: > > MCPackageLoader>>basicLoadDefinitions > > [ self basicLoadDefinitions ] in [ self handleLoadErrorsDuring: [ self > basicLoadDefinitions ] ] in MCPackageLoader>>basicLoad > > BlockClosure>>on:do: > > - - - - - - - - - - - - - - - > > - - - - - - - - - - - - - - - - - - > > [ aBlock > > on: InMidstOfFileinNotification > > do: [ :notification | notification resume: true ] ] in > MCPackageLoader>>handleLoadErrorsDuring: > > BlockClosure>>on:do: > > MCPackageLoader>>handleLoadErrorsDuring: > > [ self handleLoadErrorsDuring: [ self basicLoadDefinitions ] ] in > MCPackageLoader>>basicLoad > > BlockClosure>>ensure: > > MCPackageLoader>>basicLoad > > [ self basicLoad ] in MCPackageLoader>>loadWithNameLike: > > BlockClosure>>ensure: > > MCPackageLoader>>useChangeSetNamed:during: > > MCPackageLoader>>useNewChangeSetNamedLike:during: > > MCPackageLoader>>loadWithNameLike: > > MCThreeWayMerger(MCMerger)>>loadWithNameLike: > > MCVersionMerger>>mergeWithNameLike: > > MCVersionMerger class>>mergeVersion: > > MCVersion>>merge > > MCFileRepositoryInspector(MCVersionInspector)>>merge > > MCFileRepositoryInspector>>merge > > MCFileRepositoryInspector(MCTool)>>performButtonAction:enabled: > > PluggableButtonMorph>>performAction: > > [ :m | > > (m containsPoint: evt cursorPoint) > > ifTrue: [ m enabled > > ifTrue: [ m performAction: evt ] ] ] in > PluggableButtonMorph>>mouseUp: > > Array(SequenceableCollection)>>do: > > PluggableButtonMorph>>mouseUp: > > PluggableButtonMorph(Morph)>>handleMouseUp: > > MouseButtonEvent>>sentTo: > > PluggableButtonMorph(Morph)>>handleEvent: > > PluggableButtonMorph(Morph)>>handleFocusEvent: > > [ ActiveHand := self. > > ActiveEvent := anEvent. > > result := focusHolder > > handleFocusEvent: (anEvent transformedBy: (focusHolder > transformedFrom: self)) ] in HandMorph>>sendFocusEvent:to:clear: > > BlockClosure>>on:do: > > WorldMorph(PasteUpMorph)>>becomeActiveDuring: > > HandMorph>>sendFocusEvent:to:clear: > > HandMorph>>sendEvent:focus:clear: > > HandMorph>>sendMouseEvent: > > HandMorph>>handleEvent: > > HandMorph>>processEvents > > [ :h | > > ActiveHand := h. > > h processEvents. > > ActiveHand := nil ] in WorldState>>doOneCycleNowFor: > > Array(SequenceableCollection)>>do: > > WorldState>>handsDo: > > WorldState>>doOneCycleNowFor: > > WorldState>>doOneCycleFor: > > WorldMorph>>doOneCycle > > [ [ World doOneCycle. > > Processor yield. > > false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess > > [ self value. > > Processor terminateActive ] in BlockClosure>>newProcess > > ------------------------------------------------------------ > ------------------- > > > > > > > > HernÃ¡n > > > > >

Sept. 21, 2016

[pharo-project/pharo-core]

by GitHub

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

Sept. 21, 2016

[pharo-project/pharo-core] 8620d7: 60235

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 8620d723d417c322870a76f3d12dc0e0a415b5a3 https://github.com/pharo-project/pharo-core/commit/8620d723d417c322870a76f3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-09-21 (Wed, 21 Sep 2016) Changed paths: R Chroma-CubeHelix.package/CubeHelix.class/README.md R Chroma-CubeHelix.package/CubeHelix.class/class/class initialization/initialize.st R Chroma-CubeHelix.package/CubeHelix.class/class/instance creation/hueShift_rotations_saturation_.st R Chroma-CubeHelix.package/CubeHelix.class/definition.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/at_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/gamma_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/hueShift_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/rotations.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/rotations_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/accessing/saturation_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/conversion - athens/asColorStops_on_.st R Chroma-CubeHelix.package/CubeHelix.class/instance/initialization/initialize.st M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version0104_.st M Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/expandAll.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60234.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60235.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60234.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60235.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M SmartSuggestions.package/SugsGlamourCodeContext.class/instance/refactoring/sourceTextArea.st Log Message: ----------- 60235 19023 debug menu in GTDebugger https://pharo.fogbugz.com/f/cases/19023 19101 Unload CubeHelix https://pharo.fogbugz.com/f/cases/19101 19116 FTRootItem>>expandAll sends deprecated #name message https://pharo.fogbugz.com/f/cases/19116 http://files.pharo.org/image/60/60235.zip

Sept. 21, 2016

Re: [Pharo-dev] How do recover change with epicea?

by Sven Van Caekenberghe

Thank you for this clear explanation, Martin. People will always have trouble using any tool/UI if they do not understand the underlying model. It helped me. Needless to say, such high level documentation needs to go somewhere. > On 21 Sep 2016, at 06:50, Martin Dias <tinchodias(a)gmail.com> wrote: > > Hi Stef, âNo idea why Epicea didn't log your changes. > > About "monitor vs. log set"... the two new entries in World Menu > Tools > Epicea... I'd like user opinions to improve naming and UI. I can tell some things introduced in the latest integration. > > - The Log Set > As you know, Epicea Monitor logs code changes (and some IDE events such as MC load/save and refactorings). Such data is placed in .ombu files in a local directory. Each time a Pharo image opens, Epicea Monitor logs code changes into a new ombu file. Those ombu files in the local directory is what is currently called "Log Set". > > - The Monitor UI shows the code changes since Epicea started to log. > ===> This means it shows changes placed in potentially several ombu files. > > - The Log Set UI shows: > -- all the logs in the local directory on the left panel, and > -- the content of the selected log in the right panel. > ===> This UI visually connects the logs to help user to understand how the ombu files are related. Note that the code changes displayed on the right panel belong to only one log (different than in the Monitor UI, that might show changes in several logs). > > Cheers, > Martin > > On Tue, Sep 20, 2016 at 4:57 PM, stepharo <stepharo(a)free.fr> wrote: > even better > > Smalltalk tools changeList browseRecentLog > > does not show any changes :) > > So I redownloaded the latest version of tried > > - changes something > > - exist without saving > > - reopening the image > > And I could not reproduce the bug.... Shit. > > So I lost my time. > > Stef > > > > > > Hi > > i introduced a loop (yes totally stupid) in menu morph icon :) > so I had to quit my image. > I thought that epicea would show me all the changes and I could not find how to do it. > I do not know how to invoke the old recover lost changes... so so far I lost 40 min of dev :( > > I have no idea what is monitor vs log set in Epicea. > And log set is just with the changes I'm doing :( not the ones I lost :( > > In cutting alpha image it would be good to make sure that we cannot lose our work :( > Stef > > > > > > > <epiceaLogSet.jpg>

Sept. 21, 2016

Re: [Pharo-dev] SharedPool method definitions do not resolve Class names

by Marcus Denker

Hi, Yes, this is why it works nowâ¦ but I think it would be good to be more uniform. I remember that there where some non-standard uses of SharePool subclasses in native boost at some point, so it is not obvious that these classes are different. > On 20 Sep 2016, at 13:59, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Are SharedPool supposed to be instantiated ? Why did you need to instantiate a SharedPool ? > > I only use them (maybe mistakenly) by setting with class-side methods the default values of the SharedPool class variables, then use the poolDictionary: keyword to access those variables values from other classes. I thought that was the only way they should be used. Please explain me the other use-cases for a shared pool. > > > > > On Tue, Sep 20, 2016 at 10:38 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > > > 2016-09-19 16:02 GMT+02:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: > This is probably my lack of understanding but I found this surprising > behaviour.... > > I was trying to add a method to a subclass of FFIExternalEnumeration > and it was not recognising classes. I traced this back to SharedPool > which can be demostrated by trying to save the following method... > > SharedPool >> test1 > ^Object > > > reports... "Unknown variable: Object please correct, or cancel:" > > > Any insights? > > I think it is a bug. SharedPool implement some special lookup to make the SharedPool variable lookup work. But it seems this conflicts with the variable lookup for > globals. > > cheers -ben > > >

Sept. 21, 2016