- Pharo-dev - lists.pharo.org

ShortArray, DoubleArray & influence of 64bit

by Thibault Raffaillac

> I copy the comment of Behavior>>instSpec I had missed this one, thanks! > It depends. > > ByteArray is a good name and ShortArray is good name, self-explanatory, > there is no discussion here. > > Then it depends, at some place we use WordArray and DoubleWordArray, in > other we use LongArray and SixtyFourBitsIndexableArray... I'd go for > WordArray and DoubleWordArray, but I don't mind if one decides otherwise. > > For Float, we changed the representation to be "SmallFloat64" and > "BoxedFloat64". We have no proper support for single precision float in > Pharo. We could consider renaming FloatArray to DoubleArray, Float64Array, > or something similar. I don't know. I am still confused with WordArray in Pharo terminology: 32bit or native register size? For the naming I like the Java convention: byte(8), short(16), int(32), long(64). Ideally that would make: ByteArray(8), ShortArray(16), IntegerArray(32), LongArray(64), WordArray(native), DoubleWordArray(native*2) As for floats, one arithmetic on 64bit double is fine, but I think we need both 32bit & 64bit loads/stores, that is having FloatArray(32) and DoubleArray(64). That would make UFFI code consistent among 32bit & 64bit machines . Also in x86 all architectures do IEEE 64bit double arithmetic, so no need for a "native" register size. Thibault

July 7, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by Alexandre Bergel

Jeff, does this flush reduces the amount of crash you are experiencing? Alexandre > On Jul 6, 2016, at 9:01 PM, J.F. Rick <self(a)je77.com> wrote: > > Nicolai, > > THANKS! That worked. I no longer have any AthensCairoCanvas hanging around after executing "CairoBackendCache flush". > > Cheers, > > Jeff > > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Hi Jeff, > > if you use forms to paint on an AthensCairoCanvas, they are cached in the CairoBackendCache, > can you try to flush that cache whith > CairoBackendCache flush. > > > 2016-06-18 18:36 GMT+02:00 J.F. Rick <self(a)je77.com>: > I'm using Athens rendering for my multi-touch applications on Pharo5. As part of that, I create a surface: > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > Though the object creating that surface is deleted, the surface sticks around. So, each time I run the app, I get another instance of AthensCairoSurface hanging around. That means all the forms stick around as well. So my image can quickly grow towards the 1GB size. > > Is there anything I can do about that? Can I manually get the surface to delete itself? > > Cheers, > > Jeff > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 7, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Eliot Miranda

Hi Ben, On Wed, Jul 6, 2016 at 5:16 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > I'll try once more to explain. > > > > You like the catalog, don't you ? It was your idea in the first place. > With this feature you can just type XML, CSV, JSON or whatever and it will > suggest a couple of catalog projects that you can install with just one > click, no need to open any tool you don't even know. This is especially > good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD > WORK. It leverages all the work put in the catalog. > > > > Is Spotter or any other part of Pharo perfect ? No. > > > > For many people, Spotter make a huge functional difference, we use it > every minute. If it would hang or block the image even once a day, any of > us would complain loudly. > > > > Conclusion: it works for 99% of the people/cases. > > > > Even in the 1% where there is a problem, it is not 100% sure it is > related to the catalog searching. In the last concrete issue reported, the > guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! > > > > So again, why turn it off ? It is an overreaction, not engineering. > > > > The underlying problem is that in some very rare, hard to reproduce > cases we cannot reliably detect that there is no network. That's about it. > > If the root cause is a blocking system call e.g.... > "NetNameResolver class>>#addressForName: sometimes hangs when there is > no network" > https://pharo.fogbugz.com/default.asp?18281& > > this seems very hard to fix at the Image level, except maybe doing > in-Image name resolution instead of relying on the system library. I > found this... > http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html It'll be child's play when we have the threaded FFI. > > > and... > http://www.squeaksource.com/dnsclient.html > http://www.squeaksource.com/ar.html > > cheers -ben > > > > > Note also that almost every application or app today will do some > network calls, this is how the world work - we should be able to do the > same with Pharo, not run away and kill every feature that does a network > call. > > > >> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: > >> > >> Who vote to put it in? > >> > >> Seriously I think that my main concern is about getting Pharo stable in > any occasion and not giving > >> > >> a bad impression of the system. I takes enough time to build traction > and such glitches can spoil > >> > >> our effort in no time. "Yes Pharo froze." > >> > >> So it would be nice to care take of such aspect. > >> > >> I do not understand why super users do not manage to put a reference to > on in the preferences. > >> > >> Sorry esteban but I do not buy your argument that something off is > remove. No it is off. > >> > >> Stef > >>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: > >>>> > >>>> 18674 Turn spotter catalog off by default > >>>> https://pharo.fogbugz.com/f/cases/18674 > >>> We did not agree on this, at all, there was no public discussion, no > vote. > >>> > >>> > >> > >> > > > > > > -- _,,,^..^,,,_ best, Eliot

July 7, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Ben Coman

On Thu, Jul 7, 2016 at 2:19 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I'll try once more to explain. > > You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. > > Is Spotter or any other part of Pharo perfect ? No. > > For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. > > Conclusion: it works for 99% of the people/cases. > > Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! > > So again, why turn it off ? It is an overreaction, not engineering. > > The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. If the root cause is a blocking system call e.g.... "NetNameResolver class>>#addressForName: sometimes hangs when there is no network" https://pharo.fogbugz.com/default.asp?18281& this seems very hard to fix at the Image level, except maybe doing in-Image name resolution instead of relying on the system library. I found this... http://forum.world.st/ANN-DnsClient-More-protocol-fun-td2303225.html and... http://www.squeaksource.com/dnsclient.html http://www.squeaksource.com/ar.html cheers -ben > > Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. > >> On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: >> >> Who vote to put it in? >> >> Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving >> >> a bad impression of the system. I takes enough time to build traction and such glitches can spoil >> >> our effort in no time. "Yes Pharo froze." >> >> So it would be nice to care take of such aspect. >> >> I do not understand why super users do not manage to put a reference to on in the preferences. >> >> Sorry esteban but I do not buy your argument that something off is remove. No it is off. >> >> Stef >>>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>>> >>>> 18674 Turn spotter catalog off by default >>>> https://pharo.fogbugz.com/f/cases/18674 >>> We did not agree on this, at all, there was no public discussion, no vote. >>> >>> >> >> > >

July 7, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

by Ben Coman

On Thu, Jul 7, 2016 at 12:52 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> On 06 Jul 2016, at 18:16, stepharo <stepharo(a)free.fr> wrote: >> >> I always found such kind of changes totally obscure and it would be nice to have a description. >> > > The point I took from Stef's question is... not just getting a followup description here in the mail list, but could this text you've typed here.... > Fixes issues: > > - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:" > - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: #ifNotEmptyDo:ifEmpty:â > - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane > - Esteban's change to GLMAction ...in future be added as the Log message instead of just "Moose" so there is a permanent record in our package history. > > This was mostly me pushing for getting the trivial things *DONE* and not wait another 3 weeksâ¦ > > (I should have just committed slices, the overhead with committing and syncing is to high for > trivial refactorings) Sure, buts lets document this. Since anyway we'll just ask for a followup in the mail list ;) and I presume it takes more effort to go back and look these up after the fact, than copy-pasting at integration time. cheers -ben > > Marcus P.S. Not to take your efforts doing the integrations for granted, thanks for regularly doing this task.

July 6, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Andrei Chis

+1 On Wed, Jul 6, 2016 at 8:19 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I'll try once more to explain. > > You like the catalog, don't you ? It was your idea in the first place. > With this feature you can just type XML, CSV, JSON or whatever and it will > suggest a couple of catalog projects that you can install with just one > click, no need to open any tool you don't even know. This is especially > good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD > WORK. It leverages all the work put in the catalog. > > Is Spotter or any other part of Pharo perfect ? No. > > For many people, Spotter make a huge functional difference, we use it > every minute. If it would hang or block the image even once a day, any of > us would complain loudly. > > Conclusion: it works for 99% of the people/cases. > > Even in the 1% where there is a problem, it is not 100% sure it is related > to the catalog searching. In the last concrete issue reported, the guy > tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! > > So again, why turn it off ? It is an overreaction, not engineering. > > The underlying problem is that in some very rare, hard to reproduce cases > we cannot reliably detect that there is no network. That's about it. > > Note also that almost every application or app today will do some network > calls, this is how the world work - we should be able to do the same with > Pharo, not run away and kill every feature that does a network call. > > > On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: > > > > Who vote to put it in? > > > > Seriously I think that my main concern is about getting Pharo stable in > any occasion and not giving > > > > a bad impression of the system. I takes enough time to build traction > and such glitches can spoil > > > > our effort in no time. "Yes Pharo froze." > > > > So it would be nice to care take of such aspect. > > > > I do not understand why super users do not manage to put a reference to > on in the preferences. > > > > Sorry esteban but I do not buy your argument that something off is > remove. No it is off. > > > > Stef > >>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: > >>> > >>> 18674 Turn spotter catalog off by default > >>> https://pharo.fogbugz.com/f/cases/18674 > >> We did not agree on this, at all, there was no public discussion, no > vote. > >> > >> > > > > > > >

July 6, 2016

Re: [Pharo-dev] AthensCairoSurface not getting garbage collected

by J.F. Rick

Nicolai, THANKS! That worked. I no longer have any AthensCairoCanvas hanging around after executing "CairoBackendCache flush". Cheers, Jeff On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Hi Jeff, > > if you use forms to paint on an AthensCairoCanvas, they are cached in the > CairoBackendCache, > can you try to flush that cache whith > CairoBackendCache flush. > > > 2016-06-18 18:36 GMT+02:00 J.F. Rick <self(a)je77.com>: > >> I'm using Athens rendering for my multi-touch applications on Pharo5. As >> part of that, I create a surface: >> surface := AthensCairoSurface extent: bounds extent asIntegerPoint. >> >> Though the object creating that surface is deleted, the surface sticks >> around. So, each time I run the app, I get another instance of >> AthensCairoSurface hanging around. That means all the forms stick around as >> well. So my image can quickly grow towards the 1GB size. >> >> Is there anything I can do about that? Can I manually get the surface to >> delete itself? >> >> Cheers, >> >> Jeff >> > >

July 6, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] ec7b0e: 60137

by Sven Van Caekenberghe

I'll try once more to explain. You like the catalog, don't you ? It was your idea in the first place. With this feature you can just type XML, CSV, JSON or whatever and it will suggest a couple of catalog projects that you can install with just one click, no need to open any tool you don't even know. This is especially good for new people. IT IS A FANTASTIC FEATURE, IT IS THE WAY THINGS SHOULD WORK. It leverages all the work put in the catalog. Is Spotter or any other part of Pharo perfect ? No. For many people, Spotter make a huge functional difference, we use it every minute. If it would hang or block the image even once a day, any of us would complain loudly. Conclusion: it works for 99% of the people/cases. Even in the 1% where there is a problem, it is not 100% sure it is related to the catalog searching. In the last concrete issue reported, the guy tried disabling the catalog searching AND IT MADE NO DIFFERENCE ! So again, why turn it off ? It is an overreaction, not engineering. The underlying problem is that in some very rare, hard to reproduce cases we cannot reliably detect that there is no network. That's about it. Note also that almost every application or app today will do some network calls, this is how the world work - we should be able to do the same with Pharo, not run away and kill every feature that does a network call. > On 06 Jul 2016, at 18:14, stepharo <stepharo(a)free.fr> wrote: > > Who vote to put it in? > > Seriously I think that my main concern is about getting Pharo stable in any occasion and not giving > > a bad impression of the system. I takes enough time to build traction and such glitches can spoil > > our effort in no time. "Yes Pharo froze." > > So it would be nice to care take of such aspect. > > I do not understand why super users do not manage to put a reference to on in the preferences. > > Sorry esteban but I do not buy your argument that something off is remove. No it is off. > > Stef >>> On 06 Jul 2016, at 09:52, GitHub <noreply(a)github.com> wrote: >>> >>> 18674 Turn spotter catalog off by default >>> https://pharo.fogbugz.com/f/cases/18674 >> We did not agree on this, at all, there was no public discussion, no vote. >> >> > >

July 6, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

by Marcus Denker

> On 06 Jul 2016, at 18:16, stepharo <stepharo(a)free.fr> wrote: > > I always found such kind of changes totally obscure and it would be nice to have a description. > Fixes issues: - 18450 GT-Tools: "Do not use #ifNotNilDo:ifNil:, #ifNil:ifNotNilDo:, #ifNotNilDo:" - 18453 GT-Tools: "do not use #ifEmpty:ifNotEmptyDo: #ifNotEmptyDo: #ifNotEmptyDo:ifEmpty:â - 18431 attach glmpopplers shortcut to the textarea instead of the scroll pane - Esteban's change to GLMAction This was mostly me pushing for getting the trivial things *DONE* and not wait another 3 weeksâ¦ (I should have just committed slices, the overhead with committing and syncing is to high for trivial refactorings) Marcus

July 6, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] a813b2: 60138

by stepharo

I always found such kind of changes totally obscure and it would be nice to have a description. Stef Le 6/7/16 Ã 11:29, GitHub a Ã©crit : > Branch: refs/heads/6.0 > Home: https://github.com/pharo-project/pharo-core > Commit: a813b2cc8d72ea3442e7ab1e9be5856203ea4c3f > https://github.com/pharo-project/pharo-core/commit/a813b2cc8d72ea3442e7ab1e… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-07-06 (Wed, 06 Jul 2016) > > Changed paths: > M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st > M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st > M ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version310_.st > A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version311_.st > M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st > M GT-BytecodeDebugger.package/extension/Context/instance/gtBytecodeDebuggerRetrieveContextValues.st > M GT-EventRecorder.package/GTEventPacking.class/instance/private/updateAnnouncement_for_.st > A GT-EventRecorder.package/GlobalIdentifier.class/class/class initialization/initialize.st > A GT-EventRecorder.package/GlobalIdentifier.class/class/system startup/startUp_.st > R GT-Inspector.package/GTExample.class/class/examples/gtExample.st > A GT-Inspector.package/GTExample.class/class/examples/gtExampleFromPragma.st > R GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterClass_selector_arguments_.st > R GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinishClass_selector_.st > R GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinishClass_selector_arguments_.st > R GT-Inspector.package/GTExample.class/instance/pragma-selectors/afterFinish_.st > R GT-Inspector.package/GTExample.class/instance/pragma-selectors/after_arguments_.st > A GT-Inspector.package/GTExample.class/instance/public/signalableExceptions.st > M GT-Inspector.package/GTExampleEvaluator.class/README.md > M GT-Inspector.package/GTExampleEvaluator.class/definition.st > M GT-Inspector.package/GTExampleEvaluator.class/instance/initializing/initialize.st > R GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExampleAfterFinish_.st > R GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExampleAfter_.st > M GT-Inspector.package/GTExampleEvaluator.class/instance/primitives/primitiveProcessExample_withArguments_.st > A GT-Inspector.package/GTExampleEvaluator.class/instance/private/newResultFor_.st > A GT-Inspector.package/GTExampleEvaluator.class/instance/private/processAfter_.st > A GT-Inspector.package/GTExampleEvaluator.class/instance/private/processAfter_withResult_.st > M GT-Inspector.package/GTExampleEvaluator.class/instance/private/process_withArguments_.st > R GT-Inspector.package/GTExampleEvaluator.class/instance/private/withLinkContextFor_do_.st > M GT-Inspector.package/GTExampleEvaluator.class/instance/public/result.st > R GT-Inspector.package/GTExampleLinkContext.class/README.md > R GT-Inspector.package/GTExampleLinkContext.class/definition.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/accessing/example.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/accessing/example_.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/private/install.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/private/onLinkNode_arguments_.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/private/onLinkNode_at_put_.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/private/uninstall.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/private/withLinksDo_.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/public/arguments.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/public/do_.st > R GT-Inspector.package/GTExampleLinkContext.class/instance/testing/hasLinks.st > M GT-Inspector.package/GTExampleTestCase.class/instance/private/runExampleContainers_.st > A GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_.st > R GT-Inspector.package/GTExampleTestCase.class/instance/private/runExample_fromContainer_.st > M GT-Inspector.package/GTInspector.class/class/inspecting/inspectorExtendingMethods.st > M GT-Inspector.package/GTInspector.class/instance/building/compose.st > M GT-Inspector.package/GTInspectorHelp.class/class/accessing/pages.st > A GT-Inspector.package/extension/Class/instance/gtInspectorGTExamplesIn_.st > M GT-Inspector.package/extension/CompiledMethod/instance/gtExample.st > A GT-Inspector.package/extension/CompiledMethod/instance/gtExampleValue.st > A GT-Inspector.package/extension/CompiledMethod/instance/valueWithReceiver_possibleArguments_.st > M GT-Inspector.package/extension/ProtoObject/instance/gtInspectorPresentationsFromPragmas_In_inContext_.st > A GT-InspectorExtensions-Core.package/extension/MethodChunk/instance/gtDisplayOn_.st > A GT-InspectorExtensions-Core.package/extension/RBAbstractCondition/instance/gtInspectorChildren.st > A GT-InspectorExtensions-Core.package/extension/RBAbstractCondition/instance/gtInspectorTreeIn_.st > A GT-InspectorExtensions-Core.package/extension/RBConjunctiveCondition/instance/gtInspectorChildren.st > M GT-Spotter.package/GTSpotter.class/class/inspecting/spotterExtendingMethods.st > R GT-SpotterExtensions-Core.package/GTSelector.class/instance/ui/spotterSendersFor_.st > A GT-SpotterExtensions-Core.package/GTSelector.class/instance/ui/spotterUsersFor_.st > M GT-SpotterExtensions-Core.package/PragmaType.class/instance/accessing/pragmas.st > A GT-SpotterExtensions-Core.package/PragmaType.class/instance/accessing/users.st > M GT-SpotterExtensions-Core.package/PragmaType.class/instance/ui/gtInspectorPragmasIn_.st > A GT-SpotterExtensions-Core.package/PragmaType.class/instance/ui/gtInspectorUsersIn_.st > R GT-SpotterExtensions-Core.package/PragmaType.class/instance/ui/spotterSendersFor_.st > A GT-SpotterExtensions-Core.package/PragmaType.class/instance/ui/spotterUsersFor_.st > M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/class/gtExampleWorkingCopy.st > M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/allAncestors.st > M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/nextAncestors.st > M GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/spotterPackageFor_.st > M GT-SpotterExtensions-Core.package/extension/RPackage/instance/spotterMonticelloPackageFor_.st > M GT-SpotterExtensions-Core.package/extension/RPackage/instance/spotterMonticelloWorkingCopyFor_.st > M GT-Tests-Spotter.package/GTSpotterStepTest.class/instance/private-navigation/pragmas_inPackages_.st > A GT-Tests-Spotter.package/GTSpotterStepTest.class/instance/private-navigation/users_.st > A GT-Tests-Spotter.package/GTSpotterStepTest.class/instance/private-navigation/users_inPackages_.st > M GT-Tests-Spotter.package/GTSpotterStepTest.class/instance/tests/testProcessorForPragmasThenDiveIn.st > M Glamour-Core.package/GLMAction.class/definition.st > A Glamour-Core.package/GLMAction.class/instance/accessing/enabledCondition.st > A Glamour-Core.package/GLMAction.class/instance/accessing/enabledCondition_.st > A Glamour-Core.package/GLMAction.class/instance/testing/isEnabledOn_.st > A Glamour-Core.package/GLMPresentation.class/instance/scripting actions/selectionAct_entitled_enabledWhen_.st > M Glamour-Examples.package/GLMBasicExamples.class/instance/actions examples/staticAndDynamicMenu.st > M Glamour-Morphic-Renderer.package/GLMMorphicWidgetRenderer.class/instance/private/menuIn_for_.st > M Glamour-Morphic-Renderer.package/GLMMorphicWidgetRenderer.class/instance/private/moreToolbarActions_on_.st > M Glamour-Morphic-Widgets.package/GLMMorphicModel.class/instance/callbacks/menu_.st > M Glamour-Morphic-Widgets.package/GLMPopper.class/instance/private/updateWithString_from_.st > M Glamour-Morphic-Widgets.package/GLMPrintPopper.class/instance/public/openFromRubric_withResult_.st > M Glamour-Morphic-Widgets.package/GLMTreeMorphNodeModel.class/instance/menu/menu_shifted_.st > M PragmaCollector.package/PragmaCollector.class/instance/system changes/removedEventOccurs_.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60137.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60138.st > R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60137.st > A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60138.st > M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > > Log Message: > ----------- > 60138 > Moose > > http://files.pharo.org/image/60/60138.zip > >

July 6, 2016