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

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

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

by Ben Coman

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

June 30, 2016

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

by David T. Lewis

On Wed, Jun 29, 2016 at 02:00:19PM -0400, David T. Lewis wrote: > Let's not solve the wrong problem folks. I only looked at this for 10 > minutes this morning, and I think (but I am not sure) that the issue > affects the case of saving the image, and that the normal writing of > changes is fine. I am wrong. I spent some more time with this, and it is clear that two images saving chunks to the same changes file will result in corrupted change records in the changes file. It is not just an issue related to the image save as I suggested above. In practice, this is not an issue that either Chris or I have noticed, probably because we are not doing software development (saving method changes) at the same time that we are running RemoteTask and similar. But I can certainly see how it might be a problem if, for example, I had a bunch of students running the same image from a network shared folder. Dave > > Max was running on Pharo, which may or may not be handling changes the > same way. I think he may be seeing a different problem from the one I > confirmed. > > So a bit more testing and verification would be in order. I can't look at > it now though. > > Dave > > > > >> On 29-06-2016, at 10:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > >> wrote: > >> > > {snip much rant} > > > >> The most obvious place where this is an issue is where two images are > >> using the same changes file and think they???re appending. Image A seeks > >> to the end of the file, ???writes??? stuff. Image B near-simultaneously > >> does the same. Eventually each process gets around to pushing data to > >> hardware. Oops! And let???s not dwell too much on the problems possible > >> if either process causes a truncation of the file. Oh, wait, I think we > >> actually had a problem with that some years ago. > >> > >> The thing is that this problem bites even if we have a unitary primitive > >> that both positions and writes if that primitive is written above a > >> substrate that, as unix and stdio streams do, separates positioning from > >> writing. The primitive is neat but it simply drives the problem further > >> underground. > > > > > > Oh absolutely - we only have real control over a small part of it. It > > would probably be worth making use of that where we can. > > > >> > >> A more robust solution might be to position, write, reposition, read, > >> and compare, shortening on corruption, and retrying, using exponential > >> back-off like ethernet packet transmission. Most of the time this adds > >> only the overhead of reading what's written. > > > > Yes, for anything we want reliable that???s probably a good way. A limit > > on the number of retries would probably be smart to stop infinite > > recursion. Imagine the fun of an error causing infinite retries of writing > > an error log about an infinite recursion. On an infinitely large Beowulf > > cluster! > > > > It???s all yet another example of where software meeting reality leads to > > nightmares. > > > > > > tim > > -- > > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > > If it was easy, the hardware people would take care of it. > > > > > > >

June 29, 2016