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

[pharo-project/pharo-core] 05fc2b: 50517

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 05fc2b66ed00f050276fb9cca64b829b0395f060 https://github.com/pharo-project/pharo-core/commit/05fc2b66ed00f050276fb9cc… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-08 (Fri, 08 Jan 2016) Changed paths: M ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/stable_.st A ConfigurationOfShoreLineReporter.package/ConfigurationOfShoreLineReporter.class/instance/versions/version022_.st M Refactoring-Environment.package/RBCategoryEnvironment.class/instance/accessing/packages.st M Refactoring-Environment.package/RBVariableEnvironment.class/instance/accessing/packages.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50516.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50517.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50516.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50517.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M ShoreLine-Report-Core.package/SlReportExtractor.class/instance/extraction/extract.st M ShoreLine-Report-Core.package/SlReportExtractor.class/instance/extraction/extractMetadata.st M ShoreLine-Report-Core.package/SlReportExtractor.class/instance/extraction/extractPayload.st M ShoreLine-Report-Core.package/SlReportExtractor.class/instance/extraction/extractVersion.st R ShoreLine-Report-Core.package/SlReportMessage.class/README.md R ShoreLine-Report-Core.package/SlReportMessage.class/class/instance creation/withMetadata_.st R ShoreLine-Report-Core.package/SlReportMessage.class/class/instance creation/withPayload_.st R ShoreLine-Report-Core.package/SlReportMessage.class/definition.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/author.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/author_.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/auto.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/auto_.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/date.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/date_.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/payload.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/payload_.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/version.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/accessing/version_.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/converting/asDictionary.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/converting/metadata.st R ShoreLine-Report-Core.package/SlReportMessage.class/instance/converting/metadata_.st M ShoreLine-Report-Core.package/SlReporter.class/class/accessing/mimeType.st M ShoreLine-Report-Core.package/SlReporter.class/class/configuration/defaultExtractor.st A ShoreLine-Report-Core.package/SlReporter.class/instance/actions/serializeFUEL_.st A ShoreLine-Report-Core.package/SlReporter.class/instance/actions/serializeSTON_.st M ShoreLine-Report-Core.package/SlReporter.class/instance/actions/serialize_.st R ShoreLine-Report-Core.package/SlStackTraceReportExtractor.class/README.md R ShoreLine-Report-Core.package/SlStackTraceReportExtractor.class/definition.st R ShoreLine-Report-Core.package/SlStackTraceReportExtractor.class/instance/extraction/extractPayload.st M ShoreLine-Report-UI.package/SlReportWindow.class/class/specs/defaultSpec.st M ShoreLine-Report-UI.package/SlReportWindow.class/definition.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/granularity.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/granularity_.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/report.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/reportSummary.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/accessing/report_.st R ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeGranularity.st M ShoreLine-Report-UI.package/SlReportWindow.class/instance/initialization/initializeWidgets.st Log Message: ----------- 50517 17316 "Push Down" instVar refactoring not working -> RBVariableEnvironment should implement #packages https://pharo.fogbugz.com/f/cases/17316 17344 QAEventCollector uninitialized https://pharo.fogbugz.com/f/cases/17344 17320 ShoreLine Reporter version 0.2.2 https://pharo.fogbugz.com/f/cases/17320 http://files.pharo.org/image/50/50517.zip

Jan. 8, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] Where to get Monitor implementation based on primitives?

by Ben Coman

On Fri, Jan 8, 2016 at 2:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Ben, > > On Thu, Jan 7, 2016 at 10:39 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On Fri, Jan 8, 2016 at 1:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > >> > and here's a version with a better class comment >> > >> > On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> > wrote: >> >> >> >> Hi Denis, Hi ClÃ©ment, Hi Frank, >> >> >> >> On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> Eliot, please, you told me you had the code and Denis is interested. >> >>> >> >>> It uses 3 primitives for performance. >> >> >> >> >> >> Forgive the delay. I thought it proper to ask permission since the >> >> code was written while I was at Qwaq. I'm attaching the code in a fairly raw >> >> state, see the attached. The code is MIT, but copyright 3DICC. >> >> >> >> It is a plugin replacement for Squeak's Mutex, and with a little >> >> ingenuity could be a replacement for Squeak's Monitor. It is quicker >> >> because it uses three new primitives to manage entering a critical section >> >> and setting the owner, exiting the critical section and releasing the owner, >> >> and testing if a critical section, entering if the section is unowned. The >> >> use of the primitives means fewer block activations and ensure: blocks in >> >> entering and exiting the critical section, and that's the actual cause of >> >> the speed-up. >> >> >> >> You can benchmark the code as is. Here are some results on 32-bit >> >> Spur, on my 2.2GHz Core i7 >> >> >> >> {Mutex new. Monitor new. CriticalSection new} collect: >> >> [:cs| | n | >> >> n := 0. >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. >> >> n ] bench] >> >> >> >> {Mutex new. Monitor new. CriticalSection new} collect: >> >> [:cs| | n | >> >> n := 0. >> >> cs class name, ' -> ', >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: [n >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. >> >> n ] bench] >> >> >> >> #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' >> >> 'Monitor -> 688,000 per second. 1.45 microseconds per run.' >> >> 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') >> >> >> >> This is great Eliot. Thank you and 3DICC. After loading the changeset >> into Pharo-50515 (32 bit Spur) I get the following results on my >> laptop i5-2520M @ 2.50GHz >> >> #('Mutex -> 254,047 per second' >> 'Monitor -> 450,442 per second' >> 'CriticalSection -> 683,393 per second') >> >> In a fresh Image "Mutex allInstances basicInspect" lists just two >> mutexes... >> 1. NetNameResolver-->ResolverMutex >> 2. ThreadSafeTranscript-->accessSemaphore > > > I hate myself for getting distracted but I'm finding this is un. One can > migrate to the new representation using normal Monticello loads by > > In the first version redefine Mutex and Monitor to subclass LinkedList and > have their owner/ownerProcess inst var first (actually third after firstLink > & lastLink), and add the primitives. > > In the next version check that all Mutex and Monitor instanes are unowned > and then redefine to discard excess inst vars > > Let me test this before committing, and see that all tests are ok. Should Mutex and Monitor both directly subclass LinkedList and duplicate the primitives in each? Or should they both subclass CriticalSection which subclasses LinkedList so the primitives are only defined once? What effect would using the primitives from the superclass have on performance? If any, I'd vote to optimise for duplication rather than "nice" design, but our comments should document this. cheers -ben

Jan. 8, 2016

Re: [Pharo-dev] Interrupting processes question. Can method return be interrupted?

by Eliot Miranda

Hi Denis, On Thu, Jan 7, 2016 at 8:44 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Denis, > > On Thu, Jan 7, 2016 at 7:54 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Look at example: >> >> >> methodA >> | result | >> result := false. >> [result := self methodB] ensure: [result ifTrue: [...]] >> >> methodB >> result := 1 < 2. >> >> ^result >> >> >> Imagine now that methodB starts execution in context of call inside >> methodA. >> Is it possible to terminate process at point of methodB return (^result)? >> In that case ensure block in methodA will perform wrong logic. >> > > Returns are not suspension points, so no. In the Cog and Stack VMs the > only suspension points are backward jumps (at the end of while loops) and > method activations. Note that invocations of methods with primitives > (including quick methods, e.g. ^true or ^instVar) are not suspension > points, unless their primitives fail, or unless the primitives are suspend, > wait et al. > I forgot to say that block activations are also suspension points. In the Cog JIT sufficiently simple methods and sufficiently simple blocks are not necessarily suspension points when converted to machine code. the KIT will generate a frameless method (which is not a suspension point) if the block or method contains only #== and #class sends and no jumps and no temporary accesses. But this is just an optimization, and it removes suspension points not adds them. > > In the interpreter VM (incorrectly IMO) primitive invocation in the > context of a perform:, tryPrimitive:, executeMethod: primitive is also a > suspension point. i.e. /any/ primitive including a quick primitive invoked > via primitives 83, 84, 100, 188, 188 & 189, could potentially be a > suspension point, in which case the process would be suspended immediately > following the send that invoked the primitive. > > _,,,^..^,,,_ > best, Eliot > -- _,,,^..^,,,_ best, Eliot

Jan. 7, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 7, 2016

[pharo-project/pharo-core] bcba85: 50516

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: bcba85d5f995016da96d32402b00aa0613161dca https://github.com/pharo-project/pharo-core/commit/bcba85d5f995016da96d3240… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-07 (Thu, 07 Jan 2016) Changed paths: M Morphic-Core.package/WorldState.class/instance/update cycle/interCyclePause_.st A Nautilus.package/AbstractMethodIconAction.class/instance/order/iconExtent.st M Nautilus.package/MethodClassInitializeAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodContainsBreakAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodFromTraitAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodIsATraitExplicitRequirementAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodIsExampleAction.class/instance/as yet unclassified/privateActionIcon.st M Nautilus.package/MethodIsScriptAction.class/instance/private - accessing/privateActionIcon.st M Nautilus.package/MethodIsTestAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodOveridesAction.class/instance/order/privateActionIcon.st M Nautilus.package/MethodOveridesAction.class/instance/private/buildUpAndDownArrowIcon_.st M Nautilus.package/MethodWidget.class/instance/icon/rebuildUpAndDownArrowIconFrom_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50515.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50516.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50515.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50516.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50516 17338 Align "up and down" icon centered https://pharo.fogbugz.com/f/cases/17338 17297 Remove Delay>>otherwise: (senders) https://pharo.fogbugz.com/f/cases/17297 http://files.pharo.org/image/50/50516.zip

Jan. 7, 2016

GTDebugger (case 17341 Integrate GTools version 3.3)

by Nicolai Hess

Some feedback on GTDebugger - The inspector pane is great, we can inspect, evaluate code, and easily show/ inspect the code (for thisContext). although the evaluator pane has a bad text mode (for the thisContext). - I think the buttons are too small and the icon for "stop over" is misleading, it looks like a "step out" - the shortcuts (neither ctrl+t nor cmd+t) aren't working - I find it totally annoying and useless that the context pane inspector scrolls away if you select a value in the rightmost pane. The context inspector should be fixed. - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - the stacklist entry for block closures prints the block closure code, this is confusing (too much text for such a small widget). nicolai

Jan. 7, 2016

Re: [Pharo-dev] Atomic commits

by Alexandre Bergel

Would the situation be different if we had one per per class in the git repo? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 6, 2016, at 3:13 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi, > I wish the commits were much more atomic than they currently are... > With current practice, reviewing the changes is near to impossible: > - it requires far too much concentration > - it's just impossible through github web interface > > For example, I did wander if the structure fields were correclty aligned in: > https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8… <https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8…> > because I see no code for aligning the offsets... > > But I cannot even navigate in the history... If I do so, > https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405… <https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405…> > the page tells me > "Sorry, we could not display the entire diff because too many files (2,121) changed" > and I couldn't find a way of displaying the portion of interest. > > I thus loose the ability to deposit a comment. > > I can still open a fresh Pharo image and browse and review the whole code snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs and navigating a bit in history without replicating the repository, I can't. > > While ranting, it's nice to have the commits performed by a jenkins server, but how do we track the authors of original modifications? > In a normal git based development, there would be feature branches integrated/merged in trunk/master by whatever process. > But in current process i fail to capture such information... > > This gives a taste of under-powered use of the tools, and I wander if being visible in these conditions is a good thing: we don't expose the best practices.

Jan. 7, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by Esteban A. Maringolo

2016-01-07 16:54 GMT-03:00 stepharo <stepharo(a)free.fr>: > This is not to be visible. > This is to educate you guys :) > The point is how much time does it take esteban to fix FFI > How much worth is that? > All these questions and like that you know what esteban is doing for > real when you put money > in the consortium. Oh, I see. Well... Esteban is very proficient, any money spent on him will pay more than on any other developer. His commits speak by themselves. Regards! Esteban A. Maringolo

Jan. 7, 2016

Re: [Pharo-dev] Atomic commits

by stepharo

I agree (see my mails about sending diffs to the mailing-lists.) People do not listen to me so ... Le 6/1/16 19:13, Nicolas Cellier a Ã©crit : > Hi, > I wish the commits were much more atomic than they currently are... > With current practice, reviewing the changes is near to impossible: > - it requires far too much concentration > - it's just impossible through github web interface > > For example, I did wander if the structure fields were correclty > aligned in: > https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8… > because I see no code for aligning the offsets... > > But I cannot even navigate in the history... If I do so, > https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405… > > the page tells me > "Sorry, we could not display the entire diff because too many files > (2,121) changed" > and I couldn't find a way of displaying the portion of interest. > > I thus loose the ability to deposit a comment. > > I can still open a fresh Pharo image and browse and review the whole > code snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs > and navigating a bit in history without replicating the repository, I > can't. > > While ranting, it's nice to have the commits performed by a jenkins > server, but how do we track the authors of original modifications? > In a normal git based development, there would be feature branches > integrated/merged in trunk/master by whatever process. > But in current process i fail to capture such information... > > This gives a taste of under-powered use of the tools, and I wander if > being visible in these conditions is a good thing: we don't expose the > best practices.

Jan. 7, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by stepharo

This is not to be visible. This is to educate you guys :) The point is how much time does it take esteban to fix FFI How much worth is that? All these questions and like that you know what esteban is doing for real when you put money in the consortium. Stef Le 7/1/16 18:48, Esteban A. Maringolo a Ã©crit : > Nice! > > However I wouldn't say you're not visible in the community. ;-) > > Esteban A. Maringolo > > > 2016-01-07 14:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> On 07 Jan 2016, at 18:18, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi, >> >> Stef told me I need to make a bit more visibility my work, and while being >> in Togo I sketched an application I tested last few days and seems to be >> working fina. >> Of course, easiest way would be to use twitter as a work log, but I was not >> satisfied with the idea. Why? wellâ¦ some reasons are explained in the source >> page: >> >> - You can add formatting using pillar >> - You do not have 140 characters max (probably you will not need much more, >> but anyway, the limitation is annoying :P) >> - You can disqus (http://disqus.com) posts. >> - Posts are interpreted and links are detected and listed (so is easy to >> find them) >> - Since is made for my own work, it understand links like *case:12345* as a >> link to pharo fogbugz case 12345. >> - It has a command line! >> >> but another reason was because I wanted to try it (and I was bored in Togo >> waiting for the planes) >> I donât know how this experiment will work, but letâs give it a try :) >> >> http://log.smallworks.eu >> http://log.smallworks.eu/rss (you can suscribe with your reader, so you do >> not need to go to the page) >> https://github.com/estebanlm/worklog >> >> Enjoy stalking me :) >> >> Esteban >> >> >> btw is very possible that you took it downâ¦ I never tested with other than >> my self. >> â¦ this is running in Pharo 5 with spur (I wanted to test stability too) :P >> >> Esteban >> >

Jan. 7, 2016