- Pharo-dev - lists.pharo.org

reinstating original UI thread after debugging
by Ben Coman June 14, 2018

June 14, 2018

I notice... DebugSession >> resumeProcess "Make sure the interrupted process is restored properly and restart the low space handler" interruptedProcess isTerminated ifFalse: [ errorWasInUIProcess ifTrue: [ UIManager default resumeUIProcess: interruptedProcess ] ifFalse: [ interruptedProcess resume ]]. "restart low space handler" Smalltalk installLowSpaceWatcher. and... MorphicUIManager >> resumeUIProcess: aProcess "Adopt aProcess as the project process -- probably because of proceeding from a debugger" UIProcess := aProcess. UIProcess resume This doesn't seem to do anything regarding the second UI process spawned in... MorphicUIManager >> debugProcess:context:label:fullView:notification: With Process Browser running with auto-update on, running the following experiment confirms that the second spawned UI is killed. TestCase subclass: #Example2 Example2 >> test1 Processor activeProcess name: 'ORIGINAL UI'. self halt So I'm curious, where is the code killing the second UI ? Also curious, when the first UI turns into a debuggger, why later reinstate the first UI and kill the second UI? If the second UI started clean and is running happily, why not leave it running and let first UI thread terminate normally? I get some strange behaviour** sometimes , and wonder if the swap back it might be related to this. ** Like today #testUserPriority below not opening a debugger at the first halt statement, or opening a pre-debug window that has a blank pane. testUserPriority debug := true. Processor activeProcess priority: 38. self halt. highPriorityProcess := self highPriorityRunLoop. Transcript cr. debug ifTrue: [self halt]. 3 timesRepeat: [ Transcript crShow: 'U'. self wakeHighPriorityLoop.]. highPriorityProcess terminate. cheers -ben

1 0

Re: [Pharo-dev] ApplicationSecurity Questions
by Sean DeNigris June 13, 2018

June 13, 2018

> Now I've fixed the BaselineOfApplicationSecurity Yes, successfully installed. > I don't have time to try it or support it in Pharo 5 now :( No problem. I only tried because I failed in Pharo 6 :) > Add an adaptor using the Control Panel then go to: Ah, yes! Up and running :) > Please let me know how it is going, Wil do

1 0

[Ann] Iceberg v1.1.0
by Guillermo Polito June 13, 2018

June 13, 2018

Time for the weekly Iceberg update. Thanks to all brave users, issue reporters and contributors :). Key changes: we have introduced some tag support, a new credential manager to manage keys and passwords per host or repository, a new version of tonel, and made a first step towards a simplified contribution to Iceberg by listing it as Pharo's repository. Enjoy, Guille in behalf of all Iceberg contributors Following, the detailed changes log. New Features #842 <https://github.com/pharo-project/pharo/pull/842> Adding Credentials Store #843 <https://github.com/pharo-project/pharo/pull/843> Update Tonel to 1.0.7 #823 <https://github.com/pharo-project/pharo/pull/823> Iceberg repository should be listed as Pharo's one #841 <https://github.com/pharo-project/pharo/pull/841> Basic tag support ( #372 <https://github.com/pharo-project/pharo/pull/372>) Infrastructure #787 <https://github.com/pharo-project/pharo/pull/787> Add Windows ci with Appveyor (not yet green!) Enhancements #827 <https://github.com/pharo-project/pharo/pull/827> Add package dialog has some glitches #833 <https://github.com/pharo-project/pharo/pull/833> replace #asIcon with #iconNamed: #832 <https://github.com/pharo-project/pharo/pull/832> Move Iceberg from MostUsedTools to Tools #830 <https://github.com/pharo-project/pharo/pull/830> Better handling of not github remote urls #825 <https://github.com/pharo-project/pharo/pull/825> Enhance Migrate to tonel commit message #637 <https://github.com/pharo-project/pharo/pull/637> Show tag version instead of "Detached HEAD" #829 <https://github.com/pharo-project/pharo/pull/829> migrate-versions-browser Bug Fixes #835 <https://github.com/pharo-project/pharo/pull/835> Compare file definitions by their binary uninterpreted content #838 <https://github.com/pharo-project/pharo/pull/838> Clone from incorrect github repository fails with DNU #826 <https://github.com/pharo-project/pharo/pull/826> Pushing to virgin repository raises a DNU

7 12

beacon documentation
by Tudor Girba June 13, 2018

June 13, 2018

Hi, To support the recent conversation about Beacon, we put together an updated documentation using Documenter. To play with it: 1. Load GToolkit (this will also load Beacon) https://github.com/feenkcom/gtoolkit 2. Inspect IceRepository repositoriesLocation / 'feenkcom'/ 'gtoolkit' / 'doc' / 'beacon' / 'index.pillarâ. Enjoy, The feenk team -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

1 0

[ANN] ba-st Web Stack new versions available
by Gabriel Cotelli June 13, 2018

June 13, 2018

Check the announcement at https://medium.com/ba-st/web-stack-june-release-bbfb2674b11. Anyone interested in joining our ba-st projects <https://github.com/ba-st/> is welcomed. Regards, Gabriel Cotelli, Maxi Tabacman and all the contributors.

1 0

CfP: 3rd Workshop on Meta-Programming Techniques and Reflection (Metaâ18), Co-located with SPLASH 2018
by Guido Chari June 13, 2018

June 13, 2018

======================================================================== Call for Papers 3rd Workshop on Meta-Programming Techniques and Reflection (Metaâ18) Co-located with SPLASH 2018 November 6, 2018, Boston, USA https://2018.splashcon.org/track/meta-2018 Follow us on twitter @MetaAtSPLASH ======================================================================== The Metaâ18 workshop aims to bring together researchers working on metaprogramming and reflection, as well as users building applications, language extensions, or software tools using them. The changing hardware and software landscape, and the increased heterogeneity of systems make metaprogramming once more an important research topic to handle the associate complexity. The challenges which metaprogramming faces are manifold. They start with typing of reflective programs, continue with performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. While industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript and others, academia still needs to bring it to the same level of convenience, tooling, and understanding as for direct programming styles. Contributions to the workshop are welcome on a wide range of topics related to the design, implementation, and application of metaprogramming techniques, as well as empirical studies on typing models for such systems and languages. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming, from static to dynamic techniques: - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques - contract systems, or typing of reflective programs - reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, and taxonomization of existing approaches In short, we invite contributions to the workshop on a wide range of topics related to design, implementation, and application of reflective APIs and meta-programming techniques, as well as empirical studies and typing for such systems and languages. ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. Papers submitted by the first deadline will be considered for publication in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. For all papers, use of the SIGPLAN acmart style is mandatory: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex or Word. technical paper: max. 8 pages, excluding references position and work-in-progress paper: 1-4 pages, excluding references technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work, but will not be considered for publication in the ACM DL. For the submission, please use the submission system at: https://meta18.hotcrp.com/ ### Important Dates 7 Aug 2018 - Abstract Submission 17 Aug 2018 - Paper Submission (considered for ACM DL) 14 Sep 2018 - Notification 7 Sep 2018 - Demo, position or work-in-progress paper submission 30 Sep 2018 - Demo, position or work-in-progress paper notification 6 Nov 2018 - Workshop ### Organizing Committee Guido Chari, Czech Technical University Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, University of Kent ### Program Committee Anya Helene Bagge, University of Bergen, Norway Camilo Bruni, Google, Germany Walter Cazzola, UniversitÃ degli Studi di Milano, Italy Pascal Costanza, imec Marcus Denker, INRIA, Lille Matthew Flatt, University of Utah, United States Diego Garbervetsky, University of Buenos Aires, Argentina Eduardo Guerra, INPE, National Institute for Space Research Pablo Inostroza, CWI, Netherlands Hidehiko Masuhara, Tokyo Institute of Technology ,Japan Tom Van Cutsem, Nokia Bell Labs, Belgium

1 0

[Pharo 7.0-dev] Build #1053: 22133-Rename-Epiceas-test-packages-to-follow-convention
by ci-pharo-ci-jenkins2＠inria.fr June 13, 2018

June 13, 2018

There is a new Pharo build available! The status of the build #1053 was: SUCCESS. The Pull Request #1536 was integrated: "22133-Rename-Epiceas-test-packages-to-follow-convention" Pull request url: https://github.com/pharo-project/pharo/pull/1536 Issue Url: https://pharo.fogbugz.com/f/cases/22133 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

problem debugging <Over> - correctly sequencing debug of multi-threaded code per process priorities
by Ben Coman June 13, 2018

June 13, 2018

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.

1 2

FileAttributesPlugin: request for comment and testing
by Alistair Grant June 13, 2018

June 13, 2018

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

2 2

[Pharo 7.0-dev] Build #1052: 22130-parseFaultyExpression-deserves-a-nice-comment
by ci-pharo-ci-jenkins2＠inria.fr June 13, 2018

June 13, 2018

There is a new Pharo build available! The status of the build #1052 was: SUCCESS. The Pull Request #1534 was integrated: "22130-parseFaultyExpression-deserves-a-nice-comment" Pull request url: https://github.com/pharo-project/pharo/pull/1534 Issue Url: https://pharo.fogbugz.com/f/cases/22130 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0