- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Oct. 12, 2013

[pharo-project/pharo-core] 886c22: 30474

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 886c229671708465fbba9e3c6fe80ef279eb3c4e https://github.com/pharo-project/pharo-core/commit/886c229671708465fbba9e3c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-10-12 (Sat, 12 Oct 2013) Changed paths: A Deprecated30.package/extension/TabModel/instance/morph.st A Deprecated30.package/extension/TabModel/instance/morph_.st A Kernel-Methods.package/BlockClosure.class/instance/accessing/argumentNames.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script129.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30474.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Spec-Core-Widgets.package/TabModel.class/instance/deprecated-protocol/morph.st R Spec-Core-Widgets.package/TabModel.class/instance/deprecated-protocol/morph_.st M Spec-Core-Widgets.package/TreeModel.class/instance/initialize/registerEvents.st Log Message: ----------- 30474 11844 Move TabModel deprecated methods to Deprecated30 package https://pharo.fogbugz.com/f/cases/11844 11850 Add support for selectedItem in TreeModel https://pharo.fogbugz.com/f/cases/11850 -> add argumentNames to BlockClosure http://files.pharo.org/image/30/30474.zip

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.Zodiac.ZnHTTPSTests.testGetPharoVersion

Oct. 12, 2013

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

by Marcus Denker

On Oct 12, 2013, at 6:33 AM, kilon <thekilon(a)yahoo.co.uk> wrote: > This is something I was contemplating lately for my project Ephestos. The > problem I see with your approach is that it takes a long time to see those > changes integrated into Pharo cause AFAIK there are not many people to check > out those "fixes" approve them and then integrate them. Now multiple that by > 1000. Yeah right ! > 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

Oct. 12, 2013

Re: [Pharo-dev] Small text composition bench

by StÃ©phane Ducasse

Thanks Nicolas. > 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 > > But the tallies does not make sense, we should better use Andreas tallying... > > > > > 2013/10/11 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'll try to write a mini bench to measure display only on a Form with StrikeFont and BitBlt... > > > 2013/10/11 Camille Teruel <camille.teruel(a)gmail.com> > > On 11 oct. 2013, at 20:25, StÃ©phane Ducasse wrote: > > > Hi > > > > I discuss with igor and its new design precomputes everything so we will see. > > What would be good is to have another guy looking at what igor is doing because now that fernando transformed himself > > in a puff of smoke, igor is alone with me looking at it form time to time. > > Me when I come back. We have to work on the editor together anyway. > > > > Stef > > On Oct 11, 2013, at 1:08 PM, plantec <alain.plantec(a)yahoo.com> wrote: > > > >> > >> Le 11 oct. 2013 Ã 08:15, Denis Kudriashov <dionisiydk(a)gmail.com> a Ã©crit : > >> > >>> Me too. > >>> > >>> What exactly doing this code? > >>> > >>> Paragraph new compose: tm text > >>> style: tm textStyle copy > >>> from: 1 > >>> in: > >>> > >>> Is it layout building stuff at new text model? > >> > >> I think yes. > >> It composes a Text as a collection of TextLine. > >> Alain > >> > >>> > >>> > >>> 2013/10/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>> Hi Igor > >>> > >>> it would be good to see how the new text model perform. > >>> > >>> Stef > >>> > >>> > >>> Begin forwarded message: > >>> > >>>> From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >>>> Subject: Fwd: Small text composition bench > >>>> Date: October 10, 2013 10:46:42 PM GMT+02:00 > >>>> To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >>>> > >>>> > >>>> > >>>> ---------- Forwarded message ---------- > >>>> From: Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >>>> Date: 2013/10/10 > >>>> Subject: Small text composition bench > >>>> To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > >>>> > >>>> > >>>> Here is a simple bench: > >>>> > >>>> (StringHolder new contents: (Compiler evaluate: (FileStream fileNamed: 'text.st') contentsOfEntireFile )) openLabel: 'Working With Squeak 2' . > >>>> ((SystemWindow allSubInstances detect: [:e | e label = 'Working With Squeak 2']) findDeepSubmorphThat: [:m | m class = PluggableTextMorphPlus] ifAbsent: [] ) textMorph > >>>> ifNotNil: [:tm | MessageTally spyOn: [ > >>>> [100 timesRepeat: [(NewParagraph new) > >>>> compose: tm text > >>>> style: tm textStyle copy > >>>> from: 1 > >>>> in: tm container]] timeToRun]]. > >>>> > >>>> Before our changes: 162 ms > >>>> After our changes: 95 ms > >>>> And my Pharo 3.0 (#30417) (not up to date) : 364 ms > >>>> > >>>> The main gain is avoiding > >>>> - the stopConditions copy > >>>> - and the TextStopConditions indirection > >>>> - and of course the Multi* when not necessary (Pharo does not) > >>>> > >>>> Here is the test for Pharo variant: > >>>> > >>>> | text | > >>>> text := Compiler evaluate: (FileSystem workingDirectory parent parent parent / 'text.st' ) readStream contentsOfEntireFile . > >>>> (StringHolder new contents: text) openLabel: 'Working With Squeak 2' . > >>>> ((SystemWindow allSubInstances detect: [:e | e label = 'Working With Squeak 2']) findDeepSubmorphThat: [:m | m class = PluggableTextMorph] ifAbsent: [] ) textMorph > >>>> ifNotNil: [:tm | MessageTally spyOn: [ > >>>> [100 timesRepeat: [(Paragraph new) > >>>> compose: text > >>>> style: tm textStyle copy > >>>> from: 1 > >>>> in: tm container]] timeToRun]]. > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > > >

Oct. 12, 2013

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

by StÃ©phane Ducasse

On Oct 10, 2013, at 2:22 PM, kilon <thekilon(a)yahoo.co.uk> wrote: > This is something I was contemplating lately for my project Ephestos. The > problem I see with your approach is that it takes a long time to see those > changes integrated into Pharo cause AFAIK there are not many people to check > out those "fixes" approve them and then integrate them. Now multiple that by > 1000. Yeah right ! > > So I decided to follow the external library route. My initial concern about > my project was that I want a better Morphic. Now the sensible start would be > to do what you suggested, start small , fix morphic problems here and there, > tiny clean ups to the code etc. But I realised that if someone pings me back > months later about a fix he does not like and I am way forward in the > development process that could seriously mess with my code and even make it > hard to change the fix. > > So it was a great news indeed that morphic is entirely (or almost entirely > ?) written in smalltalk. I am back at studying opengl since I want to make > an opengl implementation of moprhic , but also I would also like to get rid > of things I dont like about morphic. Making it into an external lib also > makes sure I dont brake people's code but also I am tied into things I dont > like and need the approval of the community to fix. > > So yes I agree that what you say sounds ideal in theory, but its not ideal > in practice. 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. > > > > -- > View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4713655.ht… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 12, 2013

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

by StÃ©phane Ducasse

nicolas should push a change to Smalltalkhub so that people can publish freely in inbox On Oct 12, 2013, at 1:18 AM, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com> wrote: > Could someone give permission to submit a slice, please? > My username is vonbecmann. > Thanks. > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America.

Oct. 12, 2013

Re: [Pharo-dev] Mocketry problems in 3.0

by StÃ©phane Ducasse

I cannot check now (running to breakfast :)) but you should load the latest development version. > I used this one: > > Gofer it url: 'http://www.smalltalkhub.com/mc/sig/TxText/main'; > package: 'ConfigurationOfTxText'; > load. > > ((Smalltalk at:#ConfigurationOfTxText) project version: '1.0') load: #('ALL'). > > > 2013/10/11 Torsten Bergmann <astares(a)gmx.de> > Denis Kudriashov > >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) > > Where is it hosted? Any pointers to code? > > Thx > T. > >

Oct. 12, 2013

Re: [Pharo-dev] Mocketry problems in 3.0

by StÃ©phane Ducasse

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

Startup Preferences: An Alternative

by Sean P. DeNigris

Startup Preferences are great, but I felt limited by the "evaluate text files" approach, so I thought, "what's the minimum amount of code necessary to bootstrap into real smalltalk?" I came up with a really simple .st preference file that just loads a Metacello config with all my preferences. One cool thing is that this file never changes; all updates are to the packages which are loaded by the config. Talking to Ben at ESUG, I realized this might be helpful to people so I put it at http://smalltalkhub.com/#!/~SeanDeNigris/DeNigrisPreferences . There may be some stuff hardcoded, but at least you can see (and steal ;)) the approach if you find it valuable. There is more description in the project info on sthub. HTH. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 12, 2013