November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] Image for #10172

by Marcus Denker

https://gforge.inria.fr/frs/download.php/11596/Pharo0.1Core-10172.zip ChangeLog ========= update10165 Stef and Damien happily adding tests to Array, OrderedCollection, Set, Bag, String, Symbol, Dictionary based on traits TIncludesTest, TCloneTest, TCopyTest ------------------------------------------------------ update10166 Simon fixes to icons tests No author pop up ------------------------------------------------------ update10167 - clean more Preferences (Marcus Denker) - Scriptloader Seaside loading methods (Torsten Bergmann) - Postscript: (Preferences preferenceAt: #allowEtoyUserCustomEvents) changeInformee: nil changeSelector: nil. Preferences removePreference: #batchPenTrails. Preferences removePreference: #allowEtoyUserCustomEvents. Preferences removePreference: #automaticViewerPlacement. Preferences removePreference: #capitalizedReferences. Preferences removePreference: #fenceEnabled. Preferences removePreference: #keepTickingWhilePainting. Preferences removePreference: #tileTranslucentDrag. Preferences removePreference: #translationWithBabel. Preferences removePreference: #useButtonProprtiesToFire. Preferences removePreference: #alphabeticalProjectMenu. Preferences removePreference: #showAdvancedNavigatorButtons. Preferences removePreference: #ignoreStyleIfOnlyBold. Preferences removePreference: #propertySheetFromHalo. ------------------------------------------------------------ 10168-10172: FreeType ' ============== -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 25, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by Antoine Marot

Le 25-nov.-08 Ã 14:00, Marcus Denker a Ã©crit : > Very strage... I think in general it is not good to use the > doesNotUnderstand trick so deeply in the system... for example, > even #hash and #= and will be taken from the wrappee (the > compiledMethod), but not #==, as it's in ProtoObject. And #class > will never get forwarded (as it's a bytecode). > > > So maybe the #hash is the problem: on the image side, #hash gets > forwarded to the wrappee, but what does the VM do? There could > be a mismatch. (and recompiling the whole image, what bytesurgeon > installer does, could change something wrt. to hashing that > this makes it a problem whereas it might not been a problem before) I think you're right. Having a CompiledMethod as wrapper instead of a class with the doesNotUnderstand trick makes it work. Your explanation perfectly fits that for me :) Thank you, Antoine

Nov. 25, 2008

[Pharo-project] [update] #10168-10172

by Marcus Denker

-> Load FreeType Plus. (no fonts defined yet, thus it looks like before). -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 25, 2008

[Pharo-project] [update] #10167

by Marcus Denker

- clean more Preferences (Marcus Denker) - Scriptloader Seaside loading methods (Torsten Bergmann) - Postscript: (Preferences preferenceAt: #allowEtoyUserCustomEvents) changeInformee: nil changeSelector: nil. Preferences removePreference: #batchPenTrails. Preferences removePreference: #allowEtoyUserCustomEvents. Preferences removePreference: #automaticViewerPlacement. Preferences removePreference: #capitalizedReferences. Preferences removePreference: #fenceEnabled. Preferences removePreference: #keepTickingWhilePainting. Preferences removePreference: #tileTranslucentDrag. Preferences removePreference: #translationWithBabel. Preferences removePreference: #useButtonProprtiesToFire. Preferences removePreference: #alphabeticalProjectMenu. Preferences removePreference: #showAdvancedNavigatorButtons. Preferences removePreference: #ignoreStyleIfOnlyBold. Preferences removePreference: #propertySheetFromHalo. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 25, 2008

Re: [Pharo-project] Wrapper bug (is ByteSurgeon the cause of it ?)

by Marcus Denker

On 14.11.2008, at 16:59, Antoine Marot wrote: > Hi all, > > I have a very strange bug when I use method wrappers. > > Here is my wrapper code (actually it does nothing but calling the > method) : > > ProtoObject variableSubclass: #Wrapper > instanceVariableNames: 'compiledMethod' > classVariableNames: '' > poolDictionaries: '' > category: 'Wrapper-Core' > > Wrapper>>#doesNotUnderstand: aMessage > ^aMessage sendTo: compiledMethod > > Wrapper>>#run: aSymbol with: arguments in: rec > ^rec > withArgs: arguments > executeMethod: compiledMethod > > Wrapper>>#compiledMethod: c > compiledMethod:=c. > ^self > > > Now I want to execute this : > > SequenceableCollection methodDict at: #copyFrom:to: put: (Wrapper > new compiledMethod: (SequenceableCollection>>#copyFrom:to:)). > Very strage... I think in general it is not good to use the doesNotUnderstand trick so deeply in the system... for example, even #hash and #= and will be taken from the wrappee (the compiledMethod), but not #==, as it's in ProtoObject. And #class will never get forwarded (as it's a bytecode). So maybe the #hash is the problem: on the image side, #hash gets forwarded to the wrappee, but what does the VM do? There could be a mismatch. (and recompiling the whole image, what bytesurgeon installer does, could change something wrt. to hashing that this makes it a problem whereas it might not been a problem before) Another thing: you need to empty the VM cashes when installing a method by calling #flushCache (or use Bahvior>>#basicAddSelector:withMethod:). Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 25, 2008

Re: [Pharo-project] Pharo-dev logo :)

by Damien Cassou

On Tue, Nov 25, 2008 at 1:21 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Really cool :-). I like it but I can't include it because in a few >> weeks there won't be pharo-dev releases anymore. >> > why so? Because Pharo will include dev tools. My work will go from a distinct distribution to the official release. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 25, 2008

Re: [Pharo-project] Pharo-dev logo :)

by Igor Stasenko

2008/11/25 Damien Cassou <damien.cassou(a)gmail.com>: > On Tue, Nov 25, 2008 at 9:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Hope it not hurts anyone's feelings.. >> Just for fun :) > > Really cool :-). I like it but I can't include it because in a few > weeks there won't be pharo-dev releases anymore. > why so? > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Nov. 25, 2008

Re: [Pharo-project] Pharo-dev logo :)

by Damien Cassou

On Tue, Nov 25, 2008 at 9:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hope it not hurts anyone's feelings.. > Just for fun :) Really cool :-). I like it but I can't include it because in a few weeks there won't be pharo-dev releases anymore. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 25, 2008

Re: [Pharo-project] cannot loadOBalpha in 10166 dev

by Alexandre Bergel

I can load it in 10156 (non-dev), 10164 (non-dev). I can loadOBAlpha in a 10166dev 08.11.6 But why would you want to load it in a dev edition? OB is already included there. Alexandre On 25 Nov 2008, at 06:56, StÃ©phane Ducasse wrote: > Hi David > > I cannot load... > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 25, 2008

Re: [Pharo-project] SUnit: history support and OB icons

by Alexandre Bergel

Oups, it works now. Forgot to update OB from wiresong. I thought that loadOBalpha would have taken care of it. Cheers, Alexandre On 22 Nov 2008, at 18:24, Simon Denier wrote: > The new update in PharoInbox should deal with the previous problem: > - no more author popup when browsing some TestCase > - update test history after running tests from OB > > SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.6.mcz > > On 22 nov. 08, at 18:33, StÃ©phane Ducasse wrote: > >> Ok I see so in that case removing the authorname can be a good >> compromised >> >> Stef >> On Nov 22, 2008, at 4:02 PM, Simon Denier wrote: >> >>> >>> On 22 nov. 08, at 13:08, Adrian Lienhard wrote: >>> >>>> The reason is that TestCase class >> #methodChanged: is executed >>>> each time a method is modified or compiled and it then creates >>>> for each test case class a new dictionary that stores the author >>>> name (and if not set, this will trigger the popup). This >>>> dictionary is then stored in another dictionary in a class >>>> variable... >>> >>> Actually this is something related. Whenever you browse a TestCase >>> class, OB scans the test history to look for previous results. If >>> test results are not present, then an empty dictionary of results >>> is sent back. But this dictionary is still initialized with a >>> timestamp and the author name, so the name box can raise. >>> >>> Do we need the author name in test results? It's good for >>> traceability, but too much hassle. Easy to fix anyway. >>> >>>> >>>> >>>> Adrian >>>> >>>> On Nov 22, 2008, at 12:43 , StÃ©phane Ducasse wrote: >>>> >>>>> simon, alex and others >>>>> can you check why the author name is asked while it should not? >>>>> This is annoying and I would like to see that fixed. >>>>> >>>>> Stef >>>>> >>>>> On Nov 19, 2008, at 10:02 PM, Simon Denier wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> Just to notify a new enhancement to review in the PharoInbox. >>>>>> >>>>>> SLICE-Issue338-SUnitHistoryAndIcons-simon_denier.2 >>>>>> >>>>>> >>>>>> Short doc: >>>>>> >>>>>> Add: >>>>>> - support history for test runs as well as progression filter >>>>>> to show test in progression, regression >>>>>> - support icons in OB to show the current state of a test: >>>>>> passed, failed, progressed, regressed... >>>>>> >>>>>> History support: >>>>>> - whenever some test cases run from the TestRunner, their >>>>>> results are stored in a class side variable TestResult >>>>>> class>>History >>>>>> - contextual menu for history in TestRunner>>error pane: >>>>>> 1) History: access submenu to TestRunner instance history: can >>>>>> save and show progress between results ran in the same >>>>>> TestRunner; lost when this particular instance of TestRunner is >>>>>> closed >>>>>> 2) Store results as progress reference: create/update a >>>>>> lastStoredRun method on the class side of each TestCase which >>>>>> have just been run, containing the results >>>>>> 3) Show progress: make a diff between the last run and the >>>>>> lastStoredRun, showing progress or regress in tests (new >>>>>> passed, new failures, new errors) >>>>>> >>>>>> The idea is that whenever you are satisfied with the current >>>>>> results of some of your tests, you can save this state as a >>>>>> reference point with the 'Store results...' action. >>>>>> This reference point can be compared with subsequent test >>>>>> results to show your progression or regression. >>>>>> >>>>>> Test results are stored in a class side variable some are kept >>>>>> local to your image. Reference results are stored in a special >>>>>> method for each TestCase, so that they are saved with their >>>>>> package and can be used as a common reference for package >>>>>> developers. So a good practice is to store the latest test >>>>>> results as reference before committing your changes. >>>>>> >>>>>> >>>>>> Icons support: >>>>>> OB Package browser now has icons for test methods in TestCase >>>>>> subclasses: >>>>>> - green circle: test has passed in the last run >>>>>> - red circle: test has failed >>>>>> - half green/half red circle: state unknown, test has no >>>>>> history or test has changed since last run >>>>>> - (no icon): test has raised an error >>>>>> - upside green arrow: test has progressed since last reference >>>>>> run >>>>>> - downside blue triangle: test has regressed since last >>>>>> reference run >>>>>> >>>>>> A test is in progression if it goes from error or failure to >>>>>> passed state. >>>>>> A test is in regression if it goes from passed to error or >>>>>> failure state. >>>>>> >>>>>> The last two icons have other meanings with methods not related >>>>>> to test, so we should change them whenever someone has better >>>>>> icons. >>>>>> >>>>>> Authors: Alexandre Bergel, Simon Denier, David RÃ¶thlisberger >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 25, 2008