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

Re: [Pharo-dev] problem debugging <Over> - correctly sequencing debug of multi-threaded code per process priorities

by Ben Coman

On 13 June 2018 at 11:46, Ben Coman <btc(a)openinworld.com> wrote: > I'm not sure if I'm doing the wrong thing, or if I've bumped into a > problem with step <Over>. > I'm trying to add some debugging support into multi-threaded code to help > properly sequence debugging different priority processes. I've extracted a > little demo... > > TestCase subclass: #Example > instanceVariableNames: 'doCycle debug highPriorityProcess' > classVariableNames: '' > package: 'KernelX-DelayScheduler' > > > Example >> highPriorityCycle > debug ifTrue: [ self halt ]. > Transcript show: 'H'. > > > Example >> highPriorityRunLoop > doCycle := Semaphore new. > ^[ [ doCycle wait. > self highPriorityCycle ] repeat. > ] forkAt: 45 named: 'Example high side' > > > Process >> isWaiting > ^myList isKindOf: Semaphore > > > Example >> wakeHighPriorityLoop > doCycle signal. > debug ifTrue: [ "wait until high priority process is sleeping" > [ highPriorityProcess isWaiting & highPriorityProcess isTerminated not] > whileFalse: [ > Transcript show: '.'. > 100 milliSeconds wait ]. > self halt > ]. > > > Example >> testUserPriority > debug := true. > Sorry, the above line should have been "debug := false" and this stage of the post. cheers -ben > highPriorityProcess := self highPriorityRunLoop. > Transcript cr. > debug ifTrue: [self halt]. > 3 timesRepeat: [ > Transcript crShow: 'U'. > self wakeHighPriorityLoop.]. > highPriorityProcess terminate. > > > Running #testUserPriority, on Transcript you'll see.... > UH > UH > UH > > _______________ > Changing "debug := true" and run #testUserPriority > and the UI will lockup, until "TestTookTooMuchTime" appears. > But it works with the following change... > > ClyRunTestsFromMethodsCommand >> runTest: testSelector of: testClass > [ > | testResult | > testResult := testClass debug: testSelector. > self > notifyUserAboutResults: testResult > with: 'Method: ' , testClass asString , '>>#' , testSelector asString > ] forkNamed: 'TESTING ' , testClass asString , '>>#' , testSelector > asString > > > Now running #testUserPriority and pressing <Proceed> > at each pre-debug window gives the following result... > > U................H > U..............H > U............H > > > It also works properly to run #testUserPriority and debug <Into> > #wakeHighPriorityLoop > initially ignoring the #highPriorityCycle pre-debug that pops up > to step around the #whileFalse: loop a few times. > Then <Proceed>ing the #highPriorityCycle pre-debug > and stepping until out of #wakeHighPriorityLoop. > Works fine. > > > However running #testUserPriority, debugging into #wakeHighPriorityLoop > but stepping <Over> #wakeHighPriorityLoop > locks up the UI, and I can't tell why. > > Can anyone advise? > > cheers -ben > > P.S. What I'm trying to do it make it easier for others to trace the > operation of the delay scheduler to understand its unit tests. >

June 13, 2018

problem debugging <Over> - correctly sequencing debug of multi-threaded code per process priorities

by Ben Coman

I'm not sure if I'm doing the wrong thing, or if I've bumped into a problem with step <Over>. I'm trying to add some debugging support into multi-threaded code to help properly sequence debugging different priority processes. I've extracted a little demo... TestCase subclass: #Example instanceVariableNames: 'doCycle debug highPriorityProcess' classVariableNames: '' package: 'KernelX-DelayScheduler' Example >> highPriorityCycle debug ifTrue: [ self halt ]. Transcript show: 'H'. Example >> highPriorityRunLoop doCycle := Semaphore new. ^[ [ doCycle wait. self highPriorityCycle ] repeat. ] forkAt: 45 named: 'Example high side' Process >> isWaiting ^myList isKindOf: Semaphore Example >> wakeHighPriorityLoop doCycle signal. debug ifTrue: [ "wait until high priority process is sleeping" [ highPriorityProcess isWaiting & highPriorityProcess isTerminated not] whileFalse: [ Transcript show: '.'. 100 milliSeconds wait ]. self halt ]. Example >> testUserPriority debug := true. highPriorityProcess := self highPriorityRunLoop. Transcript cr. debug ifTrue: [self halt]. 3 timesRepeat: [ Transcript crShow: 'U'. self wakeHighPriorityLoop.]. highPriorityProcess terminate. Running #testUserPriority, on Transcript you'll see.... UH UH UH _______________ Changing "debug := true" and run #testUserPriority and the UI will lockup, until "TestTookTooMuchTime" appears. But it works with the following change... ClyRunTestsFromMethodsCommand >> runTest: testSelector of: testClass [ | testResult | testResult := testClass debug: testSelector. self notifyUserAboutResults: testResult with: 'Method: ' , testClass asString , '>>#' , testSelector asString ] forkNamed: 'TESTING ' , testClass asString , '>>#' , testSelector asString Now running #testUserPriority and pressing <Proceed> at each pre-debug window gives the following result... U................H U..............H U............H It also works properly to run #testUserPriority and debug <Into> #wakeHighPriorityLoop initially ignoring the #highPriorityCycle pre-debug that pops up to step around the #whileFalse: loop a few times. Then <Proceed>ing the #highPriorityCycle pre-debug and stepping until out of #wakeHighPriorityLoop. Works fine. However running #testUserPriority, debugging into #wakeHighPriorityLoop but stepping <Over> #wakeHighPriorityLoop locks up the UI, and I can't tell why. Can anyone advise? cheers -ben P.S. What I'm trying to do it make it easier for others to trace the operation of the delay scheduler to understand its unit tests.

June 13, 2018

[Pharo 7.0-dev] Build #1047: 22115-Extract-Athens-to-its-own-baseline

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1047 was: SUCCESS. The Pull Request #1521 was integrated: "22115-Extract-Athens-to-its-own-baseline" Pull request url: https://github.com/pharo-project/pharo/pull/1521 Issue Url: https://pharo.fogbugz.com/f/cases/22115 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 12, 2018

FileAttributesPlugin: request for comment and testing

by Alistair Grant

Hi Esteban, Guille, Marcus, Cyril and Everyone, I'm (finally!) almost ready to merge in the FileAttributesPlugin changes... I have one bug to fix in the VM related to file creation, modification and access times on Windows. While I sort that out (and probably lose what remaining hair I have) I was hoping that a few people could have a look at the PR on linux and / or Mac - since it is an admittedly big one. Note that you can't merge the changes in to an existing image as Iceberg will attempt to use the file system in the middle of the merge and fail. (I haven't tested this after the latest refactor, but I expect that hasn't changed). You'll need to use the image that has been bootstrapped from the PR (link below). The source code for the plugin is at: http://smalltalkhub.com/#!/~Alistair/FileAttributesPlugin PR: https://github.com/pharo-project/pharo/pull/1529 Fogbugz: - https://pharo.fogbugz.com/f/cases/21368/Integrate-FileAttributesPlugin - https://pharo.fogbugz.com/f/cases/18279/ Images: - 32 bit: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… - 64 bit: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… It requires a recent VM, from May 9 or later (the current stable VM). What are the changes? ===================== - Fixes FileReference>>isSymlink Currently it only returns true for a broken symbolic link. - Adds the ability to retrieve symbolic link attributes. - Extends the set of file attributes that can be retrieved to all attributes returned by the libc stat() and lstat() calls. - Refactors the code to be more efficient. In particular FileReference>>exists. 1. #isSymlink now works properly on Linux (and it should also work on MacOS and BSD). 2. The list of file attributes available from DiskDirectoryEntry now is: #accessTime (new) #changeTime (new) #deviceId (new) #gid (new) #inode (new) #isBlock (new) #isCharacter (new) #isExecutable (new) #isFIFO (new) #isRegular (new) #isSocket (new) #isSymlink (works) #numberOfHardLinks (new) #targetFile (new) #uid (new) #creationTime #exists #isDirectory #isFile #isReadable #isWritable #modificationTime #permissions #size 3. FileReference>>exists is faster than before (well, at least on my linux laptop). This is useful as it is called often. 4. It is possible to retrieve symbolic link attributes, i.e. all the attributes listed above plus the target path. The public interface hasn't changed. There are a number of internal changes to FileSystem. As implied above, the changes are all backward compatible (except the broken #isSymlink), although a couple deserve mention: 1. Obviously #isSymlink now answers correctly (previously it would only answer correctly for a broken link). 2. Requesting any of the attributes listed above (except #isSymlink) will return the value of the target path. If the FileReference is to a broken symbolic link, it will return the attributes of the symbolic link (keeping existing behaviour). 3. The attributes of a symbolic link can be retrieved using FileReference>>symlinkEntry. Overall, performance is slightly better than before. Code that accesses a single attribute through FileReference will be faster than before (it used to retrieve all supported elements and throw the unused ones away). Code that needs to access multiple attributes and uses FileSystemDirectoryEntry can access the new attributes without any additional performance cost. Rough development timeline ========================== April 2017: Started development May 2017: First working version. I've been using this in my personal environment since May last year. August 2017: Plugin review by Nicolas Cellier (thanks, Nicolas!) September 2017 - January 2018 : Plugin review by Eliot Miranda (thanks Eliot!) This was very detailed and tidied up parameter checking, error return codes, making the code simulator friendly, etc. November 2017: FileAttributesPlugin added to the VM. February 2018: Tidy up Windows specific code, fix error handling in #creationTime. June 2018: Refactored to place primitives in File instead of FileAttributesPluginPrims (which matched FilePluginPrims). Testing ======= - As mentioned above I've been using this on a daily basis since May 2017. Some of the packages I have loaded include: Roassal2, Glorp, OSSubprocess, NeoCSV, DataFrame. - Automated tests have been added for the new functionality. - Additional automated tests have been added for existing functionality. - All existing tests pass Thanks! Alistair

June 12, 2018

[Pharo 7.0-dev] Build #1046: 22115-Extract-Athens-to-its-own-baseline

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1046 was: FAILURE. The Pull Request #1521 was integrated: "22115-Extract-Athens-to-its-own-baseline" Pull request url: https://github.com/pharo-project/pharo/pull/1521 Issue Url: https://pharo.fogbugz.com/f/cases/22115 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 12, 2018

[Pharo 7.0-dev] Build #1045: 22124 Improve Tool-Compilers package

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1045 was: FAILURE. The Pull Request #1528 was integrated: "22124 Improve Tool-Compilers package" Pull request url: https://github.com/pharo-project/pharo/pull/1528 Issue Url: https://pharo.fogbugz.com/f/cases/22124 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 12, 2018

[Pharo 7.0-dev] Build #1044: 22122-Categorize-methods-in-AthensCairoPatternSurfacePaint

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1044 was: FAILURE. The Pull Request #1526 was integrated: "22122-Categorize-methods-in-AthensCairoPatternSurfacePaint" Pull request url: https://github.com/pharo-project/pharo/pull/1526 Issue Url: https://pharo.fogbugz.com/f/cases/22122 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 12, 2018

[Pharo 7.0-dev] Build #1043: 22119-transforming-depreaction-for-addAndClassifySelectorwithMethodinProtocolnotifying

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1043 was: FAILURE. The Pull Request #1525 was integrated: "22119-transforming-depreaction-for-addAndClassifySelectorwithMethodinProtocolnotifying" Pull request url: https://github.com/pharo-project/pharo/pull/1525 Issue Url: https://pharo.fogbugz.com/f/cases/22119 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 12, 2018

Re: [Pharo-dev] Window groups and Calypso Browser

by Cyril Ferlicot D.

On 12/06/2018 13:41, Torsten Bergmann wrote: > Hi Denis, > > when I open a Pharo window (like Playground) and select "Create window group" I can > drag and drop other windows onto it. So one can group several windows into one, each > one shown with an own tab. > > This works for most of the Pharo windows (Playground, Iceberg, ...) in latest Pharo 7 - but > not for the Calypso browser. > > I can drag a system browser into the window group - but when I drag it out again it is just a gray > window and the content is not usable anymore. > > I guess this is a bug in Calypso - so I opened https://github.com/pharo-ide/Calypso/issues/287 > Hi, Today I opened this: https://pharo.fogbugz.com/f/cases/22125/Cannot-drop-window-in-a-window-grou… I probably though it was broken because I tried with Calypso. > Thx > T. > -- Cyril Ferlicot https://ferlicot.fr

June 12, 2018

Window groups and Calypso Browser

by Torsten Bergmann

Hi Denis, when I open a Pharo window (like Playground) and select "Create window group" I can drag and drop other windows onto it. So one can group several windows into one, each one shown with an own tab. This works for most of the Pharo windows (Playground, Iceberg, ...) in latest Pharo 7 - but not for the Calypso browser. I can drag a system browser into the window group - but when I drag it out again it is just a gray window and the content is not usable anymore. I guess this is a bug in Calypso - so I opened https://github.com/pharo-ide/Calypso/issues/287 Thx T.

June 12, 2018