- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Mocketry problems in 3.0

by Denis Kudriashov

When I look at code last time I see totally separated hierarchies of layout objects and morphs with prefix Athens. So I think my code is not planned to be used. Maybe we will separate our works at different packages. Also I almost finished my design ideas with mutable objects and active text model. At the end it will be interesting competition of our design decisions. 2013/10/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > 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. > > Stef > > > But my version (which is at configuration) is usable and works nice for > end user applications. I actually use it for my tasks. > > > > 2013/10/11 Camillo Bruni <camillobruni(a)gmail.com> > >> I recently checked the progress on TxText and I saw that half of the >> tests fail >> under 3.0 due to an incompatibility in Mocketry on >> BlockClosure>>#argumentNames >> trying to decompile the block contents. This feature is no longer >> available, >> instead you have to access the AST directly: >> >> BlockClosure >> #argumentNames >> ^ self sourceNode arguments collect: [ :each | each name ] >> >> Would it be possible to integrate that on a 3.0 branch? It's quite a pity >> to >> waste so many tests :) >> > > >

Oct. 12, 2013

http://www.zazzle.com.au/pharoshop

by Torsten Bergmann

Stef wrote on user list >I would like to thank lusy and jeff for their effort. > >>Dear All, >> >> let me introduce a new store "PharoShop" >> http://www.zazzle.com.au/pharoshop >> >> Please note the products description - >> I'm not confident in my english and ready to accept your offers for inspire the customers :) >> >> Have a great day! >> >>Lusy Hi Stef, nice - take care: this product has a typo: Pharo.OGR instead of Pharo.org: http://www.zazzle.com.au/pharo_mousepad-144390617182821879 Bye T.

Oct. 12, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by phil＠highoctane.be

I am looking at this configuration and had fun loading the Batcave thing. What is this green area and slider on the right for? Found fixIssue5656 "Issue 5656: Large fonts make tools slow http://code.google.com/p/pharo/issues/detail?id=5656" | smallerFont | smallerFont := LogicalFont familyName: 'Bitmap DejaVu Sans' pointSize: 12. StandardFonts defaultFont: smallerFont. Which I didn't knew about and for sure will help me! All the loginTo things are quite useful as I faced this kind of situation enough to care :-) Would be great to have a logout, in order to give images to other people without leaving credentials around. This pref also useful: customizeCompletion NECPreferences enabled: true; caseSensitive: true; expandPrefixes: true; useEnterToAccept: false; smartCharacters: true; smartCharactersWithDoubleSpace: '[]{}'; spaceAfterCompletion: false; popupAutomaticDelay: 100. And a lot of other things that make it clear that a simple prefs file is not enough in your case :-) Phil

Oct. 12, 2013

Re: [Pharo-dev] Small text composition bench

by Denis Kudriashov

2013/10/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > So here is the display mini bench: > > | text canvas m1 m2 | > canvas := FormCanvas extent: 569@399 depth: 32. > > text := Compiler evaluate: (FileSystem workingDirectory parent parent > parent / 'text.st' ) readStream contentsOfEntireFile . > m1 := TextMorph new. > m1 text: text textStyle: TextStyle default. > m1 wrapFlag: true. > m1 extent: 569@9999999. > MessageTally spyOn: [ 100 timesRepeat: [ > m1 drawOn: canvas]]. > m2 := TxTextMorph new. > m2 layoutStrategy: TxWrapTextStrategy new. > m2 extent: 569@9999999. > m2 newTextContents: text. > MessageTally spyOn: [ 100 timesRepeat: [ > m2 drawOn: canvas]]. > > Squeak revised BitBltDisplayScanner 1077ms / Pharo MultiDisplayScanner > 1229ms / Pharo TxText 1584ms Interesting how Athens drawing will change picture

Oct. 12, 2013

Re: [Pharo-dev] Small text composition bench

by Denis Kudriashov

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