February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bloc Documentation

by Stephan Eggermont

On 09-02-16 09:15, Aliaksei Syrel wrote: > Bloc does not have examples yet. > What classes/methods do you need to be commented first to understand the > system? In BlElement class>exampleAdvancedClipping there is twice addEventListener: (BlPluggableEventListener new whenMouseMoveDo: [ :event | event resumeBubbling ]); I'm not sure why the second one is needed. If this is needed a lot, I'd prefer #propagateEvent: #mouseMove or something like that. Stephan

Feb. 10, 2016

Re: [Pharo-dev] UUID Plugin ?

by Guille Polito

Yeap, linux VMs are not shipped with the plugin since a couple of years. Then, the code in the image is needed. On 02/10/2016 12:25 PM, phil(a)highoctane.be wrote: > The code is different for each platform... See screenshot. > > There is a CoCreateGuid thing in Windows... > > For unix, depends on what is on the platform. > > Can of worms in need of unification indeed. But as UUIDs are using > underlying system things, hard to do. > > Phil > > On Wed, Feb 10, 2016 at 11:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > I am not sure we got the root cause of the UUID problem. > > Guille wrote: > > > AAAANNNDDD! It looks I found the real cause of this! > > > > - I tested an image pre-new session manager, and an image > post-new session manager. The issue only appeared in the latter. > > > > - Checking, it seems that UUIDGenerator is not subscribed to the > new startup list. This means that the UUIDGenerator is not being > reinitialized on every startup. This means, moreover, that every > person that is loading the latest Pharo image is using the same > UUIDGenerator instance, with the same random seed => same > generated UUIDs. > > Yes, that is correct. But ... > > UUID new > > ends up calling > > UUID>>#primMakeUUID > <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > UUIDGenerator default generateBytes: self forVersion: 4. > > On my machines/VMs/images the primitive works. Which means the > UUIDGenerator is not needed, I can just as well throw it away. So > it does not matter whether it is initialised correctly or not. > > So the next question is: why does the primitive not work for some > people ? Was it like that forever ? I don't think we want that > kind of platform difference. > > This really is misleading and confusion. > > Sven > > >

Feb. 10, 2016

[pharo-project/pharo-core] e47293: 50575

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: e472935444158c365880e126e03108d765aab2ec https://github.com/pharo-project/pharo-core/commit/e472935444158c365880e126… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-10 (Wed, 10 Feb 2016) Changed paths: R Collections-Strings.package/String.class/instance/ToRemove/adaptToNumber_andSend_.st M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version010_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/initializeKeyBindings.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50574.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50575.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50574.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50575.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50575 17555 Update FastTable: In Linux some shortcuts use alt, some others ctrl https://pharo.fogbugz.com/f/cases/17555 17565 remove String>>#adaptToNumber:andSend: https://pharo.fogbugz.com/f/cases/17565 http://files.pharo.org/image/50/50575.zip

Feb. 10, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 10, 2016

Re: [Pharo-dev] Bloc Documentation

by Stephan Eggermont

On 09-02-16 09:15, Aliaksei Syrel wrote: > Bloc does not have examples yet. > What classes/methods do you need to be commented first to understand the > system? I'm looking at the examples of BlElement for upgrading Bloc-DragPanels. I'd expect BlElement to have a default eventlistener that allows moving the morphs around? Stephan

Feb. 10, 2016

Re: [Pharo-dev] UUID Plugin ?

by phil＠highoctane.be

The code is different for each platform... See screenshot. There is a CoCreateGuid thing in Windows... For unix, depends on what is on the platform. Can of worms in need of unification indeed. But as UUIDs are using underlying system things, hard to do. Phil On Wed, Feb 10, 2016 at 11:28 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am not sure we got the root cause of the UUID problem. > > Guille wrote: > > > AAAANNNDDD! It looks I found the real cause of this! > > > > - I tested an image pre-new session manager, and an image post-new > session manager. The issue only appeared in the latter. > > > > - Checking, it seems that UUIDGenerator is not subscribed to the new > startup list. This means that the UUIDGenerator is not being reinitialized > on every startup. This means, moreover, that every person that is loading > the latest Pharo image is using the same UUIDGenerator instance, with the > same random seed => same generated UUIDs. > > Yes, that is correct. But ... > > UUID new > > ends up calling > > UUID>>#primMakeUUID > <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> > UUIDGenerator default generateBytes: self forVersion: 4. > > On my machines/VMs/images the primitive works. Which means the > UUIDGenerator is not needed, I can just as well throw it away. So it does > not matter whether it is initialised correctly or not. > > So the next question is: why does the primitive not work for some people ? > Was it like that forever ? I don't think we want that kind of platform > difference. > > This really is misleading and confusion. > > Sven > > >

Feb. 10, 2016

UUID Plugin ?

by Sven Van Caekenberghe

I am not sure we got the root cause of the UUID problem. Guille wrote: > AAAANNNDDD! It looks I found the real cause of this! > > - I tested an image pre-new session manager, and an image post-new session manager. The issue only appeared in the latter. > > - Checking, it seems that UUIDGenerator is not subscribed to the new startup list. This means that the UUIDGenerator is not being reinitialized on every startup. This means, moreover, that every person that is loading the latest Pharo image is using the same UUIDGenerator instance, with the same random seed => same generated UUIDs. Yes, that is correct. But ... UUID new ends up calling UUID>>#primMakeUUID <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'> UUIDGenerator default generateBytes: self forVersion: 4. On my machines/VMs/images the primitive works. Which means the UUIDGenerator is not needed, I can just as well throw it away. So it does not matter whether it is initialised correctly or not. So the next question is: why does the primitive not work for some people ? Was it like that forever ? I don't think we want that kind of platform difference. This really is misleading and confusion. Sven

Feb. 10, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 13d069: 50574

by Marcus Denker

> On 10 Feb 2016, at 10:42, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-10 10:16 GMT+01:00 GitHub <noreply(a)github.com <mailto:noreply@github.com>>: > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core <https://github.com/pharo-project/pharo-core> > Commit: 13d069e690c17556c53e525e866b08aa63cb8100 > https://github.com/pharo-project/pharo-core/commit/13d069e690c17556c53e525e… <https://github.com/pharo-project/pharo-core/commit/13d069e690c17556c53e525e…> > Author: Jenkins Build Server <board(a)pharo-project.org <mailto:board@pharo-project.org>> > Date: 2016-02-10 (Wed, 10 Feb 2016) > > Changed paths: > M ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/symbolic versions/stable_.st > A ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/versions/version11_.st > M Kernel-Tests.package/BlockClosureTest.class/instance/tests/testTallyInstructions.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50573.st <http://script50573.st/> > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50574.st <http://script50574.st/> > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50573.st <http://update50573.st/> > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50574.st <http://update50574.st/> > M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > A System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/asserting/assertHandledId_equals_.st > M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testCategoriesPriorityOrder.st > M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testPriorityOrderInTheSameCategoryIsRespected.st > M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterElementByDefault.st > M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterSystemElement.st > M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testSubscriptionReverseOrder.st > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/README.md > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/definition.st <http://definition.st/> > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/running/setUp.st > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenARegisteredClassRenamedThenItsHandlerIsUpdated.st > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInDifferentCategoriesShoudlLastClassRegistrationBeTheOnlyOccurenceInStartupList.st > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryAtDifferentPriorityShoudlAClassBePresentOnlyOnceInStartupList.st > A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryShoudlAClassBePresentOnlyOnceInStartupList.st > A System-SessionManager.package/SessionCategory.class/instance/private/renamedClass_from_to_.st > A System-SessionManager.package/SessionCategory.class/instance/registration/unregisterHandler_.st > R System-SessionManager.package/SessionCategory.class/instance/registrqtion/unregisterClassNamed_.st > M System-SessionManager.package/SessionManager.class/class/compatibility - startupList/initializedSessionManager.st > M System-SessionManager.package/SessionManager.class/instance/registration/register_inCategory_atPriority_.st > A System-SessionManager.package/SessionManager.class/instance/registration/renamedClass_from_to_.st > M System-SessionManager.package/SessionManager.class/instance/registration/unregisterClassNamed_.st > A System-SessionManager.package/SessionManager.class/instance/registration/unregisterHandler_.st > M System-SessionManager.package/StartupUIManager.class/instance/ui requests/inform_.st > R System-SessionManager.package/UIManagerSessionHandler.class/class/initialize-release/release.st <http://release.st/> > > Log Message: > ----------- > 50574 > 17281 Failing test: BlockClosureTest>>#testTallyInstructions > https://pharo.fogbugz.com/f/cases/17281 <https://pharo.fogbugz.com/f/cases/17281> > > I don't understand this one. Does this mean bytecode 139 is a "real" instruction > tallyInstruction should count ? > I would expect tallyInstruction would only "simulate" ordinary insturction and this 139 bytecode is > only some kind of "primitive-flag". > It is a bytecodeâ¦ a nop, but a byte code. Maybe I am wrong, though. Marcus

Feb. 10, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] 13d069: 50574

by Nicolai Hess

2016-02-10 10:16 GMT+01:00 GitHub <noreply(a)github.com>: > Branch: refs/heads/5.0 > Home: https://github.com/pharo-project/pharo-core > Commit: 13d069e690c17556c53e525e866b08aa63cb8100 > > https://github.com/pharo-project/pharo-core/commit/13d069e690c17556c53e525e… > Author: Jenkins Build Server <board(a)pharo-project.org> > Date: 2016-02-10 (Wed, 10 Feb 2016) > > Changed paths: > M > ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/symbolic > versions/stable_.st > A > ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/versions/version11_.st > M > Kernel-Tests.package/BlockClosureTest.class/instance/tests/testTallyInstructions.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/ > script50573.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/ > script50574.st > R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/ > update50573.st > A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/ > update50574.st > M > ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/asserting/assertHandledId_equals_.st > M > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testCategoriesPriorityOrder.st > M > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testPriorityOrderInTheSameCategoryIsRespected.st > M > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterElementByDefault.st > M > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterSystemElement.st > M > System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testSubscriptionReverseOrder.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/README.md > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/ > definition.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/running/setUp.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenARegisteredClassRenamedThenItsHandlerIsUpdated.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInDifferentCategoriesShoudlLastClassRegistrationBeTheOnlyOccurenceInStartupList.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryAtDifferentPriorityShoudlAClassBePresentOnlyOnceInStartupList.st > A > System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryShoudlAClassBePresentOnlyOnceInStartupList.st > A > System-SessionManager.package/SessionCategory.class/instance/private/renamedClass_from_to_.st > A > System-SessionManager.package/SessionCategory.class/instance/registration/unregisterHandler_.st > R > System-SessionManager.package/SessionCategory.class/instance/registrqtion/unregisterClassNamed_.st > M > System-SessionManager.package/SessionManager.class/class/compatibility - > startupList/initializedSessionManager.st > M > System-SessionManager.package/SessionManager.class/instance/registration/register_inCategory_atPriority_.st > A > System-SessionManager.package/SessionManager.class/instance/registration/renamedClass_from_to_.st > M > System-SessionManager.package/SessionManager.class/instance/registration/unregisterClassNamed_.st > A > System-SessionManager.package/SessionManager.class/instance/registration/unregisterHandler_.st > M System-SessionManager.package/StartupUIManager.class/instance/ui > requests/inform_.st > R > System-SessionManager.package/UIManagerSessionHandler.class/class/initialize-release/ > release.st > > Log Message: > ----------- > 50574 > 17281 Failing test: BlockClosureTest>>#testTallyInstructions > https://pharo.fogbugz.com/f/cases/17281 > I don't understand this one. Does this mean bytecode 139 is a "real" instruction tallyInstruction should count ? I would expect tallyInstruction would only "simulate" ordinary insturction and this 139 bytecode is only some kind of "primitive-flag". > > 17553 missing classes in startup list > https://pharo.fogbugz.com/f/cases/17553 > > http://files.pharo.org/image/50/50574.zip > > >

Feb. 10, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 10, 2016