- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] b51a9d: 60128

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: b51a9d4f140ce072fc066ca35a7fa3e7fe3b55b4 https://github.com/pharo-project/pharo-core/commit/b51a9d4f140ce072fc066ca3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/symbolic versions/stable_.st A ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version210_.st M ConfigurationOfGTDebugger.package/ConfigurationOfGTDebugger.class/instance/versions/version29_.st M ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/symbolic versions/stable_.st A ConfigurationOfGTEventRecorder.package/ConfigurationOfGTEventRecorder.class/instance/versions/version018_.st M ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version315_.st M ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/symbolic versions/stable_.st A ConfigurationOfGTSpotter.package/ConfigurationOfGTSpotter.class/instance/versions/version212_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/symbolic versions/stable_.st M ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version322_.st A ConfigurationOfGToolkitCore.package/ConfigurationOfGToolkitCore.class/instance/versions/version323_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/baselines/baseline34_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/development_.st M ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/instance/versions/version417_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60128.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60128.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60128 Moose http://files.pharo.org/image/60/60128.zip

June 30, 2016

[pharo-project/pharo-core]

by GitHub

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

June 30, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by David T. Lewis

On Thu, Jun 30, 2016 at 09:59:37AM +0200, Max Leske wrote: > > > On 30 Jun 2016, at 05:09, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Tue, Jun 28, 2016 at 6:04 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Hi, > >> > >> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. > >> > >> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. > >> > >> > >> I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… > >> > >> > >> Cheers, > >> Max > > > > I just learnt something quite surprising that is probably important to > > be aware of... "Locks given by fcntl are not associated with the > > file-descriptor or open-file table entries. Instead, they are bound to > > the process itself. For example, a process has multiple open file > > descriptors for a particular file and gets a read/write lock using any > > one of these descriptors. Now closing any of these file descriptors > > will release the lock, the process holds on the file. The descriptor > > that was used to acquire the lock in the first place might still be > > open, but the process will loose its lock. So, it does not require an > > explicit unlock or a close ONLY on the descriptor that was used to > > acquire the lock in fcntl call. Doing unlock or close on any of the > > open file descriptors will release the lock owned by the process on > > the particular file." > > > > https://loonytek.com/2015/01/15/advisory-file-locking-differences-between-p… > > > > cheers -ben > > > > Which would solve the problem of a crashed image not cleaning up its lock. Thanks for sharing Ben. FYI, file locking for Unix/Linux/OS X is supported in OSProcess, see UnixProcessFileLockTestCase and the 'file locking' tests in UnixProcessAccessorTestCase. Dave

June 30, 2016

Re: [Pharo-dev] Subscription Form to FogBugz

by Tomas Saez Binelli

it's fixed! thanks bye! Tomas 2016-06-30 1:15 GMT-04:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > yeah, noâ¦ there was a problem with credentials in app. > can you try again? > > thanks, > Esteban > > > On 29 Jun 2016, at 23:56, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli > > <tomas.saezbin(a)gmail.com> wrote: > >> Hi everybody! > >> > >> I was trying to create an account on Fogbugz during a Sprint using the > link > >> posted here: > >> > >> https://pharo.fogbugz.com/ > >> > >> But after filling the form and submiting it, i received the following > >> message: > >> > >> "Incorrect password or username" > >> > >> This is a little bit strange because i was not able to finish the > >> registration and create an account. > >> > >> Sending this email to make the error public. > >> > >> > >> Bye! > >> Tomas > >> > > > > Thanks for the report Tomas. I think I've seen this a long time ago, > > maybe your account was created but something went wrong with setting > > the password. As a work around, see if you can find a password reset > > button. > > > > cheers -ben > > > > >

June 30, 2016

[pharo-project/pharo-core]

by GitHub

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

June 30, 2016

[pharo-project/pharo-core] 59ad9e: 60127

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 59ad9eafc76334d06cdba97d22a8ce2c38010146 https://github.com/pharo-project/pharo-core/commit/59ad9eafc76334d06cdba97d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-06-30 (Thu, 30 Jun 2016) Changed paths: M Kernel-Tests.package/RecursionStopperTest.class/README.md M Kernel-Tests.package/RecursionStopperTest.class/definition.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/mixedMethod.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/recursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/setUp.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/tearDown.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testMixedMethod.st M Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testNoRecursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testThreadSafe.st M Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/testWithRecursion.st A Kernel-Tests.package/RecursionStopperTest.class/instance/as yet unclassified/threadSafe.st M Kernel.package/Halt.class/class/halting/once.st M Kernel.package/Halt.class/class/once-reset/resetHaltOnCount.st M Kernel.package/Halt.class/class/once-reset/resetHaltOnce.st M Kernel.package/RecursionStopper.class/README.md R Kernel.package/RecursionStopper.class/class/api/check.st A Kernel.package/RecursionStopper.class/class/api/default.st M Kernel.package/RecursionStopper.class/class/api/during_.st R Kernel.package/RecursionStopper.class/class/api/off.st R Kernel.package/RecursionStopper.class/class/api/on.st M Kernel.package/RecursionStopper.class/definition.st A Kernel.package/RecursionStopper.class/instance/as yet unclassified/initialize.st A Kernel.package/RecursionStopper.class/instance/as yet unclassified/stopMethod_during_.st A Reflectivity-Tools.package/FlagIconStyler.class/README.md A Reflectivity-Tools.package/FlagIconStyler.class/definition.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/highlightColor.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/iconFor_.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/defaults/iconLabel_.st A Reflectivity-Tools.package/FlagIconStyler.class/instance/testing/shouldStyleNode_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60126.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60127.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60126.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60127.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60127 18628 can not put haltOnce in RBScanner methods https://pharo.fogbugz.com/f/cases/18628 18644 IconStyler for "self flag:" https://pharo.fogbugz.com/f/cases/18644 http://files.pharo.org/image/60/60127.zip

June 30, 2016

Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready

by Yuriy Tymchuk

Maybe I will find some time to hack the tree-matching rules to highlight the matched piece of code. Itâs so frustrating that they donât do itâ¦ Uko > On 30 Jun 2016, at 10:17, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > finalizationProcess > "The finalization process arranges to send mourn to each element of the VM's finalization queue, > which is accessed via primitiveFetchMourner. The VM signals FinalizationSemaphore whenever > the queue is non-empty. This process loops, waiting on the semaphore, fetches the first element > of the queue and then spawns a process at a higher priority to acually send the mourn messages. > If an error occurs in the higher priority mourn loop process then this process will simply spawn > another process, hence ensuring that errors in finalization methods don't break finalization. > > In addition this process also runs the old finalization scheme, supporting clients of the older, > WeakRegistry based scheme. Hopefully this will go away when all cleints have moved over." > | throttle firstMourner | > throttle := Semaphore new. > [FinalizationSemaphore wait; initSignals. > "Support the old scheme until things have changed over..." > self doOldFinalization. > [firstMourner := self primitiveFetchMourner. > firstMourner notNil] whileTrue: > [[throttle signal. > self mournLoopWith: firstMourner] forkAt: Processor activePriority + 1. > throttle wait]] > > Doh! So I wrote a naked block, not a loop !! So it did nothing. Thank you!! I think the compiler should warn about naked blocks. > > > I added a new Code-Critic rule "RBDeadBlockRule", with > > initialize > super initialize. > self matcher > matches: '`{:node | node isBlock and: [node parent isSequence > and: [ node isLastStatementInBlock not ]]}' > do: [ :node :answer | node ] > > This now shows a warning in the tools (the explanation is shown when clicking on the ? button): > It does not yet highlight the block and has no automatic transformation to fix the problem, but as > a first step it should be nice to have. > > > <Dead.jpg> > > This is in 60 update 126. > > (I did not read the mail again before doing it, so now it is called "dead", not "naked", we can change > that... dead somehow makes it look to be related a "dead context"...). > > Marcus > > >

June 30, 2016

Re: [Pharo-dev] [Vm-dev] Re: [ANN] Ephemeron Support is Ready

by Marcus Denker

>> finalizationProcess >> "The finalization process arranges to send mourn to each element of >> the VM's finalization queue, >> which is accessed via primitiveFetchMourner. The VM signals >> FinalizationSemaphore whenever >> the queue is non-empty. This process loops, waiting on the >> semaphore, fetches the first element >> of the queue and then spawns a process at a higher priority to >> acually send the mourn messages. >> If an error occurs in the higher priority mourn loop process then >> this process will simply spawn >> another process, hence ensuring that errors in finalization methods >> don't break finalization. >> >> In addition this process also runs the old finalization scheme, >> supporting clients of the older, >> WeakRegistry based scheme. Hopefully this will go away when all >> cleints have moved over." >> | throttle firstMourner | >> throttle := Semaphore new. >> [FinalizationSemaphore wait; initSignals. >> "Support the old scheme until things have changed over..." >> self doOldFinalization. >> [firstMourner := self primitiveFetchMourner. >> firstMourner notNil] whileTrue: >> [[throttle signal. >> self mournLoopWith: firstMourner] forkAt: Processor >> activePriority + 1. >> throttle wait]] >> > > Doh! So I wrote a naked block, not a loop !! So it did nothing. Thank > you!! I think the compiler should warn about naked blocks. > > I added a new Code-Critic rule "RBDeadBlockRule", with initialize super initialize. self matcher matches: '`{:node | node isBlock and: [node parent isSequence and: [ node isLastStatementInBlock not ]]}' do: [ :node :answer | node ] This now shows a warning in the tools (the explanation is shown when clicking on the ? button): It does not yet highlight the block and has no automatic transformation to fix the problem, but as a first step it should be nice to have. [image: Inline image 1] This is in 60 update 126. (I did not read the mail again before doing it, so now it is called "dead", not "naked", we can change that... dead somehow makes it look to be related a "dead context"...). Marcus

June 30, 2016

Re: [Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

by Max Leske

> On 30 Jun 2016, at 05:09, Ben Coman <btc(a)openInWorld.com> wrote: > > On Tue, Jun 28, 2016 at 6:04 PM, Max Leske <maxleske(a)gmail.com> wrote: >> Hi, >> >> Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello. >> >> I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file. >> >> >> Iâve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to… >> >> >> Cheers, >> Max > > I just learnt something quite surprising that is probably important to > be aware of... "Locks given by fcntl are not associated with the > file-descriptor or open-file table entries. Instead, they are bound to > the process itself. For example, a process has multiple open file > descriptors for a particular file and gets a read/write lock using any > one of these descriptors. Now closing any of these file descriptors > will release the lock, the process holds on the file. The descriptor > that was used to acquire the lock in the first place might still be > open, but the process will loose its lock. So, it does not require an > explicit unlock or a close ONLY on the descriptor that was used to > acquire the lock in fcntl call. Doing unlock or close on any of the > open file descriptors will release the lock owned by the process on > the particular file." > > https://loonytek.com/2015/01/15/advisory-file-locking-differences-between-p… > > cheers -ben > Which would solve the problem of a crashed image not cleaning up its lock. Thanks for sharing Ben.

June 30, 2016

Re: [Pharo-dev] Subscription Form to FogBugz

by Esteban Lorenzano

yeah, noâ¦ there was a problem with credentials in app. can you try again? thanks, Esteban > On 29 Jun 2016, at 23:56, Ben Coman <btc(a)openInWorld.com> wrote: > > On Thu, Jun 30, 2016 at 2:40 AM, Tomas Saez Binelli > <tomas.saezbin(a)gmail.com> wrote: >> Hi everybody! >> >> I was trying to create an account on Fogbugz during a Sprint using the link >> posted here: >> >> https://pharo.fogbugz.com/ >> >> But after filling the form and submiting it, i received the following >> message: >> >> "Incorrect password or username" >> >> This is a little bit strange because i was not able to finish the >> registration and create an account. >> >> Sending this email to make the error public. >> >> >> Bye! >> Tomas >> > > Thanks for the report Tomas. I think I've seen this a long time ago, > maybe your account was created but something went wrong with setting > the password. As a work around, see if you can find a password reset > button. > > cheers -ben >

June 30, 2016