October 2013 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] daebc0: 30475

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: daebc0fed40fccf6a683d3ef4efde5b2a566a3af https://github.com/pharo-project/pharo-core/commit/daebc0fed40fccf6a683d3ef… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-12 (Sat, 12 Oct 2013) Changed paths: M Morphic-Base-DockingBar.package/DockingBarMorph.class/instance/private - accessing/usedHeightByPredominantDockingBarsOfChastes_.st M Morphic-Base-DockingBar.package/DockingBarMorph.class/instance/private - accessing/usedWidthByPredominantDockingBarsOfChastes_.st M Morphic-Base-DockingBar.package/DockingBarMorph.class/instance/private - layout/updateExtent.st A Morphic-Base-DockingBar.package/DockingBarMorph.class/instance/private - layout/updatePosition.st R Polymorph-Widgets.package/extension/DockingBarMorph/instance/updatePosition.st M Refactoring-Critics.package/RBTransformationRule.class/class/accessing/recursiveSelfRule.st R Refactoring-Critics.package/RBTransformationRule.class/class/as yet unclassified/cleanUp.st A Refactoring-Critics.package/RBTransformationRule.class/class/cleanup/cleanUp.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script130.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30475.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Tools-Browser.package/extension/SystemNavigation/instance/allStoresInto_of_.st M Tools-Browser.package/extension/SystemNavigation/instance/browseAllStoresInto_from_.st Log Message: ----------- 30475 11855 Code Critic tests failing https://pharo.fogbugz.com/f/cases/11855 11611 Pharo3.0 DockingBarMorph>>updatePosition error (Compiler problem ?) https://pharo.fogbugz.com/f/cases/11611 11836 add #allStoresInto: instVarName of: aClass to SystemNavigation https://pharo.fogbugz.com/f/cases/11836 http://files.pharo.org/image/30/30475.zip

Oct. 12, 2013

[pharo-project/pharo-core]

by GitHub

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

Oct. 12, 2013

Re: [Pharo-dev] permission denied http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main ?

by Sean P. DeNigris

StÃ©phane Ducasse wrote > nicolas should push a change to Smalltalkhub so that people can publish > freely in inbox Not that this is nico's responsibility, sthub is a wonderful gift for the community :) And... +100. This is really important. It is not the people who ask for access that bothers me, it's wondering how many people wanted to contribute, but there were too many barriers in the way, and gave up silently... ----- Cheers, Sean -- View this message in context: http://forum.world.st/permission-denied-http-smalltalkhub-com-mc-Pharo-Phar… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 12, 2013

Re: [Pharo-dev] [squeak-dev] Re: Small text composition bench

by Nicolas Cellier

I also tried composition in Cuis4.2 which is interesting because it uses the primitive 103, but is around 111ms for other reasons | text | text := Compiler evaluate: (FileStream fileNamed: 'text_cuis.st') contentsOfEntireFile. MessageTally spyOn: [[100 timesRepeat: [(TextComposer new) composeLinesFrom: 1 to: text size delta: 0 into: OrderedCollection new priorLines: OrderedCollection new atY: 0 text: text extentForComposing: ( 569@9999999)]] timeToRun ]. 2013/10/11 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > It's COG that's impressive in this case (well, as long as Spur is not > ready). > Indeed, the latest squeak still spends 713ms with a 4.10.10 interpreter > VM, so primitive 103 makes a difference... > On the Pi, it still makes sense to try and restore primitive 103 - for the > simple case of StrikeFont and ByteString... > > > 2013/10/11 David T. Lewis <lewis(a)mail.msen.com> > > On Thu, Oct 10, 2013 at 05:02:56PM -0700, tim Rowledge wrote: >> > It looks like we can feel good about the last week or so's work. Thanks >> for joining in and doing such good work. >> > >> >> Really impressive! >> >> Dave >> >> >> >

Oct. 12, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation/label=wi… 1 regressions found. Zinc.Tests.ZnServerTests.testEntityTooLarge

Oct. 12, 2013

Re: [Pharo-dev] Mocketry problems in 3.0

by StÃ©phane Ducasse

>> >> >>> As Markus said it is good idea to add #argumentNames to block. >>> >>> What exactly you want to see at TxText? >>> I ask because Igor make big progress on his design implementation which I think will replace my work totally. >>> So if you want to join his development you don't need my code at all (remove it) >> >> >> Not totally from what I saw and monday all the tests were green and we published the code because it was the end of >> a large refactoring to get immutable objects into place and having tests were cool. >> >> When we start a new behavior like copyText we started with tests. > > I doubt that all the tests were ever green. the one of txModel package were because we worked until there were green. So I'm sure about that :) > half of the tests never ran in 3.0: https://ci.inria.fr/pharo-contribution/job/TxText/ > Well, might just be a problem of the configuration, but that is hard to guess

Oct. 12, 2013

Re: [Pharo-dev] Mocketry problems in 3.0

by Camillo Bruni

On 2013-10-12, at 07:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 11, 2013, at 9:47 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> As Markus said it is good idea to add #argumentNames to block. >> >> What exactly you want to see at TxText? >> I ask because Igor make big progress on his design implementation which I think will replace my work totally. >> So if you want to join his development you don't need my code at all (remove it) > > > Not totally from what I saw and monday all the tests were green and we published the code because it was the end of > a large refactoring to get immutable objects into place and having tests were cool. > > When we start a new behavior like copyText we started with tests. I doubt that all the tests were ever green. half of the tests never ran in 3.0: https://ci.inria.fr/pharo-contribution/job/TxText/ Well, might just be a problem of the configuration, but that is hard to guess

Oct. 12, 2013

Re: [Pharo-dev] Small text composition bench

by Nicolas Cellier

Ah, thanks Denis, my first look was too superficial. I must also load a more recent version (I started with Igor's 1.0). 2013/10/12 Denis Kudriashov <dionisiydk(a)gmail.com> > Hi > > 2013/10/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> OK Igor, >> I loaded ConfigurationOfTxText and I understand what you say: >> - TxText spend more time in composing layout because it records each and >> every TxSpanInterval >> - this will later accelerate display, because no scanning is required at >> display time >> On the base that you compose once and display many, this is a Memory/CPU >> trading that would not have been a good idea the 70's (birth of >> CharacterScanner family), but is now fair. >> >> Even if that does not make much sense, composition (layout building) can >> be measured with this kind of mini bench: >> >> >> | text | >> text := Compiler evaluate: (FileSystem workingDirectory parent parent >> parent / 'text.st' ) readStream contentsOfEntireFile . >> MessageTally spyOn: [[100 timesRepeat: [(Paragraph new) >> compose: text >> style: TextStyle default copy >> from: 1 >> in: ( 0@0 corner: 569@9999999)]] timeToRun ]. >> MessageTally spyOn: [ 100 timesRepeat: [| m | >> m := TxTextMorph new. >> m layoutStrategy: TxWrapTextStrategy new. >> m extent: 569@9999999. >> m newTextContents: text]] >> >> 95ms in revised Squeak CompositionScanner / 366ms Pharo >> MultiCcompositionScanner / 347ms TxText > > > I think it is not correct code for TxText. "text" variable contains Text > instance which should be converted to TxModel first. TxModel is replacement > of Text in TxText. > > So my benches shows that TxText works better in Pharo: > > text := Compiler evaluate: (FileSystem workingDirectory / 'text.st' ) > readStream contentsOfEntireFile . > > [100 timesRepeat: [(Paragraph new) > compose: text > style: TextStyle default copy > from: 1 > in: ( 0@0 corner: 569@9999999)]] timeToRun . 236. > > txModel := TxModel new. > cursor := txModel startSpan startPosition. > cursor insert: text. > > [ 100 timesRepeat: [| m | > m := TxTextMorph new. > m layoutStrategy: TxWrapTextStrategy new. > m extent: 569@9999999. > m textModel: txModel]] timeToRun. 145. > > [ 100 timesRepeat: [| m | > m := TxTextMorph new. > m layoutStrategy: TxNativeLayoutStrategy new. "without wrapping" > m extent: 569@9999999. > m textModel: txModel]] timeToRun. 118 . > > But Squeak is champion: > > [100 timesRepeat: [(NewParagraph new) > compose: text > style: TextStyle default copy > from: 1 > in: ( 0@0 corner: 569@9999999)]] timeToRun . 84. > > Best regards, > Denis > > > > >

Oct. 12, 2013

Re: [Pharo-dev] external semaphoresâ¦again

by Norbert Hartl

So, finally it turned out that the culprit is in my own code. I was logging exception objects that have a signaler context pointing to the socket. This way every connection timeout I added the exception to a collection preventing unregistering of external resources. Norbert Am 11.10.2013 um 15:02 schrieb Norbert Hartl <norbert(a)hartl.name>: > > > Am 11.10.2013 um 10:53 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> On 11 Oct 2013, at 10:24, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I can report that the behavior is different now. There were two new vm releases this week in ppa. The first one didn't work but the second changed something. My application was never running that long. It is more than a day now having an actual external objects table size of 623 which wasn't ever reached before. So I would say that there is chance that this particular problem is gone. I monitor this further and I think that this wasn't the only problem. But then it is another problem. >> >> Yeah, but not knowing your application load, 623, which would be about 200 sockets (3 semaphores per sockets), is still a lot to be active at the same time. Can you in some way invoke a full GC externally, like using ZnReadEvalPrintDelegate and see if it eventually drops due to finalization ? It should, at least that is what I see. >> > Yes, that's what I meant. There is always only one outgoing connection at a time. Every 15 seconds one request is issued. So you see why expect more to find. > I'm travelling right now and will have a deeper look after being back > > Norbert >>> Thanks to all of you who've helped solving this. If it comes to the VM being the source of problems it is always extra annoying because it is way harder to change something there. >>> >>> Norbert >>> >>> >>> Am 08.10.2013 um 11:27 schrieb Igor Stasenko <siguctua(a)gmail.com>: >>> >>>> >>>> >>>> >>>> On 7 October 2013 18:36, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Am 07.10.2013 um 16:36 schrieb Igor Stasenko <siguctua(a)gmail.com>: >>>> >>>>> 1 thing. >>>>> >>>>> can you tell me what given expression yields for your VM/image: >>>>> >>>>> Smalltalk vm maxExternalSemaphores >>>>> >>>>> (if it gives you number less than 10000000 then i think i know what is your problem :) >>>> It is 10000000 >>>> >>>> What would be the problem if it would be smaller? >>>> >>>> >>>> that just means your VM don't have external object size cap. >>>> I changed the implementation to not have hard limit (the arbitrary large number >>>> is there just to be "compatible" with previous implementation). >>>> >>>> This means, that you can actually change in your image the check and completely ignore limits >>>> and just keep growing if it necessary. >>>> >>>> Now, since you using VM which don't have a limit, but problem still persists, >>>> it seems like it somewhere else.. :/ >>>>> i just found that after one merge, my changes get lost >>>>> we're just plugged them back in, and it should be back again with newer VMs.. >>>>> but the problem could be more than just semaphores.. if merge broken this, it may break >>>>> many other things, so we need time to check >>>> I try to look at it some more time. I'm using the pharo-vm from the launchpad build. Are the changes supposed to be in this one? >>>> >>>> Norbert >>>> >>>> Launchpad? You mean ppa? I can't say i remember all the details how changes to VM source >>>> gets into ppa distro, and how fast they get there. @Damien, can you enlighten us? >>>> >>>> >>>> Well, the VM which i downloaded recently using zero-conf script, having limit back to 256. Just some merge mistake, which now is fixed.. means that couple builds will use limit-based implementation.. but then >>>> it will be back to my implementaiton. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 7 October 2013 12:31, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>> Am 07.10.2013 um 11:28 schrieb Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>>>> >>>>>> >>>>>> On Oct 7, 2013, at 11:16 , Norbert Hartl <norbert(a)hartl.name> wrote: >>>>>> >>>>>>> As I need an image that runs longer than 24 hours I'm looking at some stuff and wonder. Can anybody explain me the rationale for a code like this >>>>>>> >>>>>>> maxExternalSemaphores: aSize >>>>>>> "This method should never be called as result of normal program >>>>>>> execution. If it is however, handle it differently: >>>>>>> - In development, signal an error to promt user to set a bigger size >>>>>>> at startup immediately. >>>>>>> - In production, accept the cost of potentially unhandled interrupts, >>>>>>> but log the action for later review. >>>>>>> >>>>>>> See comment in maxExternalObjectsSilently: why this behaviour is >>>>>>> desirable, " >>>>>>> "Can't find a place where development/production is decided. >>>>>>> Suggest Smalltalk image inProduction, but use an overridable temp >>>>>>> meanwhile. " >>>>>>> | inProduction | >>>>>>> self maxExternalSemaphores >>>>>>> ifNil: [^ 0]. >>>>>>> inProduction := false. >>>>>>> ^ inProduction >>>>>>> ifTrue: [self maxExternalSemaphoresSilently: aSize. >>>>>>> self crTrace: 'WARNING: Had to increase size of semaphore signal handling table due to many external objects concurrently in use'; >>>>>>> crTrace: 'You should increase this size at startup using #maxExternalObjectsSilently:'; >>>>>>> crTrace: 'Current table size: ' , self maxExternalSemaphores printString] >>>>>>> ifFalse: ["Smalltalk image" >>>>>>> self error: 'Not enough space for external objects, set a larger size at startup!' >>>>>>> "Smalltalk image"] >>>>>>> >>>>>>> I have reported this once but got no feedback so I like to have a few opinions. >>>>>>> >>>>>>> The report is here: https://pharo.fogbugz.com/f/cases/10839/ >>>>>>> >>>>>>> Norbert >>>>>> >>>>>> The rationale is that inProduction would be some global setting, not yet in place when the code was writtenâ¦ >>>>>> Excessive simultaneous Semaphore usage is something that should be caught during development, in which case it's better to get an active notification, than having it logged somewhere. >>>>> >>>>> Agreed. But didn't work in my case because it needed roughly 20 hours and an instable remote backend to trigger the problem. And somehow I forgot to install my logger as Transcript so there is no warning message. I saw only dead images in the morning. >>>>> This not satisfactory but on the other hand this type of problems are hard to solve anyway. My feeling tells me there is more to discover. Sockets resources get unregistered at finalization time but this didn't work either. I would have said that the unlikely situation that no garbage collection ran could be the case. But it can't because in ExternalSemaphoreTable>>#freedSlotsIn:ratherThanIncreaseSizeTo: there is explicit garbage collection. >>>>> >>>>>> If I've understood correctly, it's moot on newer Pharo VM's, where there's no limit on the semtable size, but for legacy code a startup item setting size using maxExternalObjectsSilently: (as suggested in the Warning text), is still a more proper fix than setting inProduction to true and crossing your fingers hoping no signals will be lost during table growth. >>>>> >>>>> Ah, I didn't know about the risk of loosing signals while resizing the table. Thanks for that. Don't get me wrong I wasn't proposing to set inProduction in effect. I don't think that automatically growing resource management is a proper way to design a system. There is always a range of resources you need for your use case. Not setting an upper bound for this just covers leaking behavior. >>>>> >>>>> Norbert >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >> >> >

Oct. 12, 2013

Re: [Pharo-dev] Start with a trivial improvement!

by kilon

StÃ©phane Ducasse wrote > On Oct 10, 2013, at 2:22 PM, kilon < > thekilon@.co > > wrote: > > but we are not talk ing about theory. if nobody take care about little > glitches them you will > have a house full of little borken glasses and dirt everywhere. And I do > not work to live there. > My house is cosy warm and really cool and everyday I clean it. I fix a > door handle as soon > as I see it having a problem not waiting that the door falls on the floor. You make a valid point here, I see now my post again and I dont like the way I phrased it. What I meant to say is that if the integration process is too slow , then people will more likely choose to create their own solutions than bug fix the old ones, because it would be easier for them to maintain those solutions than wait for the integration process. And I was wondering if that's true and how it could be avoided . I did not mean to imply that this is a good thing, of course its not a good thing and of course we all must help to make pharo more stable and faster. Marcus Denker-4 wrote > On Oct 12, 2013, at 6:33 AM, kilon < > thekilon@.co > > wrote: > > There is right now no problem to review and integrate more simple changesâ¦ > it's the complex stuff that sometimes takes a while. > > For simple things we are at <24 hours. > > The other thing: if there are multiple people submitting simple fixes, > these > will very quickly start to *review* simple fixes, too. One just needs to > start. > > Marcus > > signature.asc (210 bytes) > <http://forum.world.st/attachment/4713991/0/signature.asc> I am happy you prove me wrong. 24 hours sounds very fast to me, I did not realize that integration was so fast. I have to say that was the one thing that was holding me back, I just did not want to invest an effort to see my bug fix die in oblivion. And yes I agree , this will make it more inviting for the people to bug fix. I will try to have a go in a couple of "easy" bug fixes. Lets put your theory into practice , shall we ? -- View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4714014.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 12, 2013