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

Re: [Pharo-project] Spell check test cases

by Stan Shepherd

Mariano Martinez Peck wrote: > > Hi: I want to include this tests in next PharoDev as I did with the rest > of > the projects. > > The problem is known problem with MC and packages. If I load the packages > from > > http://www.squeaksource.com/RBBugFixes > > It has the packages: > > Refactoring-Spelling-BugFixes > Refactoring-Tests-Spelling > > The first one is interpreted as a part of the package Refactoring-Spelling > and the second one as Refactoring-Tests > Thus, those packages are "dirty" in compare to the repository: > http://www.squeaksource.com/rb > > This is really problematic. A quick solution is to rename both packages to > something like this: > > BugFixes-Refactoring-Spelling > Refactoring-SpellingTests > > Any other has a better solution? > > Thanks > > Mariano > > On Tue, Jan 12, 2010 at 5:14 PM, Stan Shepherd > <stan.shepherd414(a)gmail.com>wrote: > >> >> >> Lukas Renggli wrote: >> > >> > Hi Stan, >> > >> >> Some are failing, as there are $' characters being passed through from >> >> the >> >> parser. Also, the literals check sees to be checking the node, rather >> >> than >> >> the node value. >> > >> > You are right, the code that extracted arguments and temps >> > unnecessarily put the names into $' characters. This is totally wrong >> > and also breaks the highlighting in the browser. Instead of changing >> > the tokenizer (as you proposed) I fixed the places where the nodes >> > were collected. Like this there should be no more $' characters in the >> > strings that are checked. >> > >> > Name: Refactoring-Spelling-lr.10 >> > Author: lr >> > Time: 12 January 2010, 12:16:16 am >> > UUID: b40774a4-8371-42f4-883c-469d6fe1e020 >> > Ancestors: Refactoring-Spelling-lr.9 >> > >> > - fixed the bug pointed out by Stan Shepherd that temps and arguments >> > were not properly checked >> > - this also fixes the issue of not highlighting typos in temps and >> > arguments (which I looked into earlier today, but couldn't figure out >> > the real cause) >> > >> >> There are some suggested changes in the same repository, that make the >> >> tests >> >> run green, and don't appear to affect the rest of Refactoring-Tests. >> > >> > The tests are really cool. I would like to add them to the main >> > repository, but two are broken depending on what checker is used: >> > >> > RBMacSpellChecker: #testLiteralValues and #testPoolVariable >> > RBInternalSpellChecker: #testLiteralValues and #testClassComments >> > >> > Maybe that could be fixed by always using the internal one for the >> > tests, but then I don't understand why the tests break. Does my fix >> > not solve the whole problem? >> > >> > Lukas >> > >> >> Hi, there are still $' present. Don't know if it's possible to strip them >> out earlier again. >> >> The following methods again strip leading and trailing '. They validate >> correctly, including 'don''t'. >> They are in Squeaksource RBBugFixes. So is a new version of the tests, >> that >> test spelling of 'don''t'. It also checks all the tests are run- one got >> lost in transcription last time. >> >> Also, the name of the Pool Dictionary test got reverted. >> >> ...Stan >> >> >> >> >> RBSpellChecker>>normalize: aString >> "Filter out non alphabetical characters, remove prefixes as >> commonly >> found >> in class names, split camel case expressions and filter out one character >> words." >> >> | result input output activeString | >> result := Set new. >> input := aString readStream. >> output := WriteStream on: (String new: 128). >> [ input atEnd ] whileFalse: [ >> [ input atEnd not and: [ input peek isLetter or: [ input >> peek = $' ] ] ] >> whileTrue: [ output nextPut: input next ]. >> output position = 0 >> ifTrue: [ input next ] >> ifFalse: [ >> | stream | >> stream := output contents readStream. >> [ stream atEnd ] whileFalse: [ >> output reset; nextPut: stream >> next. >> [ stream atEnd not and: [ stream >> peek isLowercase or: [ stream peek = >> $' ] ] ] >> whileTrue: [ output >> nextPut: >> stream next ]. >> >> "at this point we have allowed >> through $' to allow don't. We can also >> have leading or trailing $', >> if a comment contains eg 'WB' or >> 'NASA' " >> activeString := self >> copyWithoutLeadingTrailingSingleQuotes: output >> contents . >> activeString size > 1 >> ifTrue: [ result add: >> activeString ] ] ]. >> output reset ]. >> ^ result >> >> >> RBSpellChecker>>copyWithoutLeadingTrailingSingleQuotes: aByteString >> | startPosition endPosition | >> startPosition := 1. >> [ (aByteString at: startPosition) = $' ] >> whileTrue: >> [ startPosition := startPosition + 1. >> startPosition > aByteString size >> ifTrue: [ ^ '' ] ]. >> endPosition := aByteString size. >> [ (aByteString at: endPosition) = $' ] >> whileTrue: >> [ endPosition := endPosition - 1. >> endPosition < 1 >> ifTrue: [ ^ '' ] ]. >> ^ aByteString copyFrom: startPosition to: endPosition >> > Hi Mariano, probably best to wait til the tests are in the main rb repository. At the moment they would fail, as there is still a discrepancy with what comes through from the parser. ...Stan -- View this message in context: http://n2.nabble.com/Spell-check-test-cases-tp4288633p4406315.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 16, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Mariano Martinez Peck

On Sat, Jan 16, 2010 at 10:48 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > Hi Mariano, > > From a cursory look, it seems that it would be enough. I'll try to find > some time next week to make a version that works using this infrastructure. > > Cool !! Let me know so that we can integrate this change in PharoCore and ask other people for the impact it can bring. I am not sure about that. Do you know? Cheers, > Romain > > > On Jan 16, 2010, at 11:43 AM, Mariano Martinez Peck wrote: > > Hi guys: Of course I would like having keymapper or similar working in > Pharo, but as I always say, I rather go step by step. > > Last night, I was up to 2 am trying to get this working. I was almost > there, but as I don't know everything about Morphic, I ask to you. > > What Simon said about the binary changeset of Algernon, is true. However, I > took the time to analyze the changeset and from my point of view (nil > knowledge in Morphic) it seemed a very good change. I fix it (it has > underscore assignment) and I was easily merged to Pharo. No conflicts. The > main change does the simplest modifications to HandMorph for it to support > various focus holders. And I think this is cool. > > So, suppose we integrate this changeset, Algernon, wouldn't have any > override the method sendKeyboardEvent: > > Now Romain, do you think that you can manage to get WorkingSet working with > this change without overriding? Algernon does, so maybe we can see how it do > it. I saw this: Algernon >> registerWithSystem > > There you will see it does a self activeHand addAdditionalKeyboardFocus: > self. > > That method was part of the Morphic changes. > > I commit the Mprhic changes in http://www.squeaksource.com/MarianoPhD > > Name: Morphic-MarianoMartinezPeck.396 > Author: MarianoMartinezPeck > Time: 16 January 2010, 3:42:18 pm > UUID: 3587e1b2-36b4-4751-bcdb-ca6f4073788e > Ancestors: Morphic-MarianoMartinezPeck.395 > > Romain, can you take a look and if this is not enough, how can we solve > easily this problem in Pharo? > > Thanks > > Mariano > > 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> > >> >> On 15 janv. 2010, at 23:03, Mariano Martinez Peck wrote: >> >> >> >> 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> >> >>> >>> On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: >>> >>> >>> >>> On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: >>> >>>> yes it has overrides ... >>>> >>>> that's because as far as I know, there's no keyboard shortcut management >>>> facility >>>> in Pharo. If there was one, I suppose Algernon and WorkingSet would >>>> coexist. >>>> >>> >>> >>> So...all your overrides are due to the shortcuts? I think it is not >>> fear to "forbid" a package to be included in a Dev image if we don't provide >>> from the core a way to manage shortcuts. So: >>> >>> 1) Or we let this projects to be installed in the Dev image >>> >>> 2) We fix the problem with the shortcuts. >>> >>> Romain: can you tell us where exactly the problem is ? maybe someone can >>> give you a hand. >>> >>> >>> >>> Taking a look at that, there are 2 overrides in WorkingSet >>> >> >> >> How did you detect that ? >> >> >> >> Manually, using an extension-aware browser (O2Package, MC browse package, >> or the package environment) to detect extensions, then check history in the >> versions browser. >> >> >> >> Impressive. You should be a detective :) >> >> >> >> A few years ago, I was called the human debugger during a project :) Now I >> try to restrain from this kind of sessions though, it's time consuming. >> >> >> -- >> 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 > > > -- > Romain Robbes > http://www.inf.unisi.ch/phd/robbes > >

Jan. 16, 2010

Re: [Pharo-project] Problem with OB compare versions - Issue 1033 again :(

by Mariano Martinez Peck

On Sat, Jan 16, 2010 at 11:32 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I fixed it in the latest commit. I also added a test for #definitionPanel. > > Thanks. It is fixed :) > I've never seen the command for comparing versions before. The problem > is that somebody added it without writing a test, so it is quite > obvious that it breaks. > Sorry :( I am just the messenger hahah. Do only thing I am trying to do is a PharoDev image as much stable and with more green tests as possible. Sorry if I bother you a lot :( Thanks! Mariano > > Lukas > > 2010/1/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Hi: In latest Dev version there is again this bug :( > > > > http://code.google.com/p/pharo/issues/detail?id=1033 > > > > The problem is that OBVersionBrowser DNU definitionPanel > > > > In previous versions OBBrowser has definitionPanel but in latest version > it > > doesnt. > > > > I think the fix is as putting again: > > > > OBBrowser >> definitionPanel > > ^ panels > > detect: [:ea | ea isDefinition] > > ifNone: [self error: 'No definition panel configured'] > > > > Or maybe it should be in OBVersionBrowser ? > > > > Cheers > > > > Mariano > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 16, 2010

Re: [Pharo-project] Spell check test cases

by Mariano Martinez Peck

Hi: I want to include this tests in next PharoDev as I did with the rest of the projects. The problem is known problem with MC and packages. If I load the packages from http://www.squeaksource.com/RBBugFixes It has the packages: Refactoring-Spelling-BugFixes Refactoring-Tests-Spelling The first one is interpreted as a part of the package Refactoring-Spelling and the second one as Refactoring-Tests Thus, those packages are "dirty" in compare to the repository: http://www.squeaksource.com/rb This is really problematic. A quick solution is to rename both packages to something like this: BugFixes-Refactoring-Spelling Refactoring-SpellingTests Any other has a better solution? Thanks Mariano On Tue, Jan 12, 2010 at 5:14 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Lukas Renggli wrote: > > > > Hi Stan, > > > >> Some are failing, as there are $' characters being passed through from > >> the > >> parser. Also, the literals check sees to be checking the node, rather > >> than > >> the node value. > > > > You are right, the code that extracted arguments and temps > > unnecessarily put the names into $' characters. This is totally wrong > > and also breaks the highlighting in the browser. Instead of changing > > the tokenizer (as you proposed) I fixed the places where the nodes > > were collected. Like this there should be no more $' characters in the > > strings that are checked. > > > > Name: Refactoring-Spelling-lr.10 > > Author: lr > > Time: 12 January 2010, 12:16:16 am > > UUID: b40774a4-8371-42f4-883c-469d6fe1e020 > > Ancestors: Refactoring-Spelling-lr.9 > > > > - fixed the bug pointed out by Stan Shepherd that temps and arguments > > were not properly checked > > - this also fixes the issue of not highlighting typos in temps and > > arguments (which I looked into earlier today, but couldn't figure out > > the real cause) > > > >> There are some suggested changes in the same repository, that make the > >> tests > >> run green, and don't appear to affect the rest of Refactoring-Tests. > > > > The tests are really cool. I would like to add them to the main > > repository, but two are broken depending on what checker is used: > > > > RBMacSpellChecker: #testLiteralValues and #testPoolVariable > > RBInternalSpellChecker: #testLiteralValues and #testClassComments > > > > Maybe that could be fixed by always using the internal one for the > > tests, but then I don't understand why the tests break. Does my fix > > not solve the whole problem? > > > > Lukas > > > > Hi, there are still $' present. Don't know if it's possible to strip them > out earlier again. > > The following methods again strip leading and trailing '. They validate > correctly, including 'don''t'. > They are in Squeaksource RBBugFixes. So is a new version of the tests, that > test spelling of 'don''t'. It also checks all the tests are run- one got > lost in transcription last time. > > Also, the name of the Pool Dictionary test got reverted. > > ...Stan > > > > > RBSpellChecker>>normalize: aString > "Filter out non alphabetical characters, remove prefixes as commonly > found > in class names, split camel case expressions and filter out one character > words." > > | result input output activeString | > result := Set new. > input := aString readStream. > output := WriteStream on: (String new: 128). > [ input atEnd ] whileFalse: [ > [ input atEnd not and: [ input peek isLetter or: [ input > peek = $' ] ] ] > whileTrue: [ output nextPut: input next ]. > output position = 0 > ifTrue: [ input next ] > ifFalse: [ > | stream | > stream := output contents readStream. > [ stream atEnd ] whileFalse: [ > output reset; nextPut: stream next. > [ stream atEnd not and: [ stream > peek isLowercase or: [ stream peek = > $' ] ] ] > whileTrue: [ output nextPut: > stream next ]. > > "at this point we have allowed > through $' to allow don't. We can also > have leading or trailing $', > if a comment contains eg 'WB' or > 'NASA' " > activeString := self > copyWithoutLeadingTrailingSingleQuotes: output > contents . > activeString size > 1 > ifTrue: [ result add: > activeString ] ] ]. > output reset ]. > ^ result > > > RBSpellChecker>>copyWithoutLeadingTrailingSingleQuotes: aByteString > | startPosition endPosition | > startPosition := 1. > [ (aByteString at: startPosition) = $' ] > whileTrue: > [ startPosition := startPosition + 1. > startPosition > aByteString size > ifTrue: [ ^ '' ] ]. > endPosition := aByteString size. > [ (aByteString at: endPosition) = $' ] > whileTrue: > [ endPosition := endPosition - 1. > endPosition < 1 > ifTrue: [ ^ '' ] ]. > ^ aByteString copyFrom: startPosition to: endPosition > > -- > View this message in context: > http://n2.nabble.com/Spell-check-test-cases-tp4288633p4292584.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 16, 2010

Re: [Pharo-project] Problem with OB compare versions - Issue 1033 again :(

by Lukas Renggli

I fixed it in the latest commit. I also added a test for #definitionPanel. I've never seen the command for comparing versions before. The problem is that somebody added it without writing a test, so it is quite obvious that it breaks. Lukas 2010/1/16 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi: In latest Dev version there is again this bug :( > > http://code.google.com/p/pharo/issues/detail?id=1033 > > The problem is that OBVersionBrowser DNU definitionPanel > > In previous versions OBBrowser has definitionPanel but in latest version it > doesnt. > > I think the fix is as putting again: > > OBBrowser >> definitionPanel > ^ panels > detect: [:ea | ea isDefinition] > ifNone: [self error: 'No definition panel configured'] > > Or maybe it should be in OBVersionBrowser ? > > Cheers > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 16, 2010

Re: [Pharo-project] Date fromString: '6-Jan-10'

by Schwab,Wilhelm K

Stef, +1 What do you mean by "other languages?" If dialects of Smalltalk, Dolphin defines a hierarchy of *ToText converters, including Date and Time. When appropriate (as for date and time), they accept a format string that governs how they do left to right (e.g. Date to String) and right to left conversions. Anything that does not match the format raises an error. When faced with garbage data (2-digit dates are a good example of same IMHO), I end up making multiple converters with different formats, find (in sensible order) which one accepts the input, do any post-hoc tests I feel appropriate to validate that it read what I thought it read, and then set about trying to figure out, for example, just what in the DLL 07 means for a date. I am working on a set of Dolphin-like converters as part of my UI package. It's not much yet. If you thought y2k (laziness) was bad, wait for 2037 (design by committee) =:0 Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, January 16, 2010 4:06 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' But if you deal with incomplete data why not building your own reader and control it. I think that a library class cannot be tuned to deal with all kind of crazy situation. I would prefer that Date is robust and consistent and that people implement their own custom situation. Does anybody know how it is done in other languages. Stef On Jan 16, 2010, at 9:36 PM, David Harris wrote: > I think a solution that can tuned or tweaked to it's application would > be must useful. It's all very well to insist on users using four- > digit years, but for processing historical data, for example, one > doesn't have the luxury of insisting on the data format, but has to > use what is there :-( > > Perhaps a variable that determines the transition from 19xx to 20xx > would be appropriate? > > David > PS- here in Canada we interpret 4/5/xxxx the opposite to the USA. I > always use yyyy.mm.dd.hh.ss to the appropriate resolution :-) > > > On 2010-01-16, at 10:42 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > >> Yes >> >> Date fromString: '6-Jan-03' >> -> 6 January 2003 >> >> is also wrong. So david just tried to patch this wrong behavior. >> >> Stef >> >> >> On Jan 16, 2010, at 6:02 PM, csrabak(a)bol.com.br wrote: >> >>> I'm afraid the 'fix' is trying to repair something is not broken! >>> >>> Date fromString: '6-Jan-10'. giving "6 January 1910" has not >>> anything wrong. Within five year we'll have users/programmers >>> complaining that: >>> >>> Date fromString: '6-Jan-16'. gave "6 January 1916" and *obviously* >>> it should have given "6 January 2015"!! >>> >>> Rather document that years given with two figures get counted from >>> 1900 (as it used to be in last century) and have people to use four >>> digits for years in the 2000s. >>> >>> Otherwise: >>> >>> 1) We need to get used to the concept of an epoch time for Pharo; or >>> >>> 2) the number to be tested has to be the current year! >>> >>> My 0.019999. . . >>> >>> -- >>> Cesar Rabak >>> >>> >>> Em 16/01/2010 07:57, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr >>>> escreveu: >>> >>> >>> hi guys >>> >>> can one of you give a look at the this fix because I'm confused. >>> Kernel-DavidHotham.538 >>> >>> year < 20 ifTrue: [year := 2000 + year] was year < 10 ifTrue: [year >>> := 2000 + year] >>> >>> both solutions look strange to me. >>> >>> http://code.google.com/p/pharo/issues/detail?id=1749 >>> >>> >>> readFrom: aStream >>> "Read a Date from the stream in any of the forms: >>> (5 April 1982; 5-APR-82) >>> (April 5, 1982) >>> (4/5/82) >>> (5APR82)" >>> | day month year | >>> aStream peek isDigit >>> ifTrue: [day := Integer readFrom: aStream]. >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> aStream peek isLetter >>> ifTrue: ["number/name... or name..." >>> month := (String new: 10) writeStream. >>> [aStream peek isLetter] >>> whileTrue: [month nextPut: aStream next]. >>> month := month contents. >>> day isNil >>> ifTrue: ["name/number..." >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> day := Integer readFrom: aStream]] >>> ifFalse: ["number/number..." >>> month := Month nameOfMonth: day. >>> day := Integer readFrom: aStream]. >>> [aStream peek isAlphaNumeric] >>> whileFalse: [aStream skip: 1]. >>> year := Integer readFrom: aStream. >>>>> year < 20 ifTrue: [year := 2000 + year] >>> ifFalse: [ year < 1900 ifTrue: [ year := 1900 + year]]. >>> >>> ^ self >>> year: year >>> month: month >>> day: day >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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

Jan. 16, 2010

Re: [Pharo-project] Putting Algernon and WorkingSet in a Dev image

by Romain Robbes

Hi Mariano, >From a cursory look, it seems that it would be enough. I'll try to find some time next week to make a version that works using this infrastructure. Cheers, Romain On Jan 16, 2010, at 11:43 AM, Mariano Martinez Peck wrote: > Hi guys: Of course I would like having keymapper or similar working in Pharo, but as I always say, I rather go step by step. > > Last night, I was up to 2 am trying to get this working. I was almost there, but as I don't know everything about Morphic, I ask to you. > > What Simon said about the binary changeset of Algernon, is true. However, I took the time to analyze the changeset and from my point of view (nil knowledge in Morphic) it seemed a very good change. I fix it (it has underscore assignment) and I was easily merged to Pharo. No conflicts. The main change does the simplest modifications to HandMorph for it to support various focus holders. And I think this is cool. > > So, suppose we integrate this changeset, Algernon, wouldn't have any override the method sendKeyboardEvent: > > Now Romain, do you think that you can manage to get WorkingSet working with this change without overriding? Algernon does, so maybe we can see how it do it. I saw this: Algernon >> registerWithSystem > > There you will see it does a self activeHand addAdditionalKeyboardFocus: self. > > That method was part of the Morphic changes. > > I commit the Mprhic changes in http://www.squeaksource.com/MarianoPhD > > Name: Morphic-MarianoMartinezPeck.396 > Author: MarianoMartinezPeck > Time: 16 January 2010, 3:42:18 pm > UUID: 3587e1b2-36b4-4751-bcdb-ca6f4073788e > Ancestors: Morphic-MarianoMartinezPeck.395 > > Romain, can you take a look and if this is not enough, how can we solve easily this problem in Pharo? > > Thanks > > Mariano > > 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> > > On 15 janv. 2010, at 23:03, Mariano Martinez Peck wrote: > >> >> >> 2010/1/15 Simon Denier <Simon.Denier(a)inria.fr> >> >> On 15 janv. 2010, at 21:20, Mariano Martinez Peck wrote: >> >>> >>> >>> On Fri, Jan 15, 2010 at 5:55 PM, Romain Robbes <romain.robbes(a)gmail.com> wrote: >>> yes it has overrides ... >>> >>> that's because as far as I know, there's no keyboard shortcut management facility >>> in Pharo. If there was one, I suppose Algernon and WorkingSet would coexist. >>> >>> >>> So...all your overrides are due to the shortcuts? I think it is not fear to "forbid" a package to be included in a Dev image if we don't provide from the core a way to manage shortcuts. So: >>> >>> 1) Or we let this projects to be installed in the Dev image >>> >>> 2) We fix the problem with the shortcuts. >>> >>> Romain: can you tell us where exactly the problem is ? maybe someone can give you a hand. >> >> >> Taking a look at that, there are 2 overrides in WorkingSet >> >> >> How did you detect that ? > > > Manually, using an extension-aware browser (O2Package, MC browse package, or the package environment) to detect extensions, then check history in the versions browser. > > >> >> Impressive. You should be a detective :) > > > A few years ago, I was called the human debugger during a project :) Now I try to restrain from this kind of sessions though, it's time consuming. > > > -- > 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 -- Romain Robbes http://www.inf.unisi.ch/phd/robbes

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.0 & 1.1 failing tests testFinalizationOfEquals

by Nicolas Cellier

I opened http://code.google.com/p/pharo/issues/detail?id=1839 and reopened http://code.google.com/p/pharo/issues/detail?id=1771 All should be fixed in 1.1 now, to be checked in 1.0 Nicolas 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> Ah Ah, I found the guilty: >> >> Set>> do: Â use 1 to: array size do: [:i | (array at: i) ... >> >> But array inst. var can be overwritten inside the loop due to #rehash >> >> OK, OK, I thought I would catch it be redefining do: in WeakKeyDictionary >> >> do: aBlock >> Â Â Â Â "This needs to be redefined because array inst. var. can eventually >> be overwritten during the loop (due to rehash, due to fullCheck) and >> make super fail." >> >> Â Â Â Â tally = 0 ifTrue: [^ self]. >> Â Â Â Â array do: >> Â Â Â Â Â Â Â Â [:each | >> Â Â Â Â Â Â Â Â each ifNotNil: [aBlock value: each]] >> > > Never mind, this was a bad idea anyway, Dictionary do: should only > iterate on values > > >> But ARGHH SUPER EVIL, this method does not get executed BECAUSE : >> >> Dictionary>>associationsDo: aBlock >> Â Â Â Â "Evaluate aBlock for each of the receiver's elements (key/value >> Â Â Â Â associations)." >> >> Â Â Â Â super do: aBlock >> >> ARGHH, it really uses super do:, not my brand new #do: >> >> This is a good reason I DON'T LIKE INVOKING super WITH A DIFFERENT selector... >> >> Does not matter, I will just redefine Set>>do:, but that was my evil >> minute of the day... >> >> Nicolas >> >> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>> Oh, now it fails due to WeakIdentityKeyDictionary bug... >>> >>> Nicolas >>> >>> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> I wrote this test pre-closure. >>>> The problem with closures is that they are optimized to retain a >>>> pointer to the values of outer temporary variable they use when >>>> activated. >>>> Thus the BlockClosures forAnyTwoEqualObjects ofDifferentIdentity >>>> registeringAnActionAtFinalizationForEachObject all refer to 'hello' >>>> pointed by o1 and its copy pointed by o2. >>>> In other words, o1 and o2 are not the single pointers to the String >>>> 'hello' and its copy. >>>> thenForcingFinalizationOfObjects only clean o1 and o2, but omit to >>>> clean the closures that still point to 'hello'... >>>> Thus, 'hello' is not finalized. >>>> One possibility is to also clean the closures pointing to 'hello'. >>>> But now the code is tricky... It's aim was to be simple damned :) >>>> >>>> Nicolas >>>> >>>> >>>> here is a corrected version : >>>> >>>> >>>> testFinalizationOfEquals >>>> Â Â Â Â "self debug: #testFinalizationOfEquals" >>>> >>>> Â Â Â Â | finalizationProbe o1 o2 >>>> Â Â Â Â forAnyTwoEqualObjects >>>> Â Â Â Â ofDifferentIdentity >>>> Â Â Â Â registeringAnActionAtFinalizationForEachObject >>>> Â Â Â Â thenForcingFinalizationOfObjects >>>> Â Â Â Â implyBothRegisteredActionsAreExecuted | >>>> >>>> Â Â Â Â finalizationProbe := Set new. >>>> Â Â Â Â o1 := 'hello' copy. >>>> Â Â Â Â o2 := 'hello' copy. >>>> Â Â Â Â forAnyTwoEqualObjects := [o1 = o2]. >>>> Â Â Â Â ofDifferentIdentity := [o1 ~~ o2]. >>>> Â Â Â Â registeringAnActionAtFinalizationForEachObject := [ >>>> Â Â Â Â Â Â Â Â o1 toFinalizeSend: #add: to: finalizationProbe Â with: 'first object finalized'. >>>> Â Â Â Â Â Â Â Â o2 toFinalizeSend: #add: to: finalizationProbe Â with: 'second object >>>> finalized']. >>>> Â Â Â Â thenForcingFinalizationOfObjects := [ >>>> Â Â Â Â Â Â Â Â forAnyTwoEqualObjects := ofDifferentIdentity := >>>> registeringAnActionAtFinalizationForEachObject := nil. >>>> Â Â Â Â Â Â Â Â o1 := o2 := nil. Smalltalk garbageCollect]. >>>> Â Â Â Â implyBothRegisteredActionsAreExecuted := [finalizationProbe size = 2]. >>>> >>>> Â Â Â Â self >>>> Â Â Â Â Â Â Â Â assert: forAnyTwoEqualObjects; >>>> Â Â Â Â Â Â Â Â assert: ofDifferentIdentity; >>>> Â Â Â Â Â Â Â Â should: [ >>>> Â Â Â Â Â Â Â Â Â Â Â Â registeringAnActionAtFinalizationForEachObject value. >>>> Â Â Â Â Â Â Â Â Â Â Â Â thenForcingFinalizationOfObjects value. >>>> Â Â Â Â Â Â Â Â Â Â Â Â implyBothRegisteredActionsAreExecuted value]. >>>> >>> >> >

Jan. 16, 2010

Re: [Pharo-project] Pharo 1.1 failing tests testBlockNumbering

by StÃ©phane Ducasse

Thanks! I will integrate all that tomorrow morning. Stef On Jan 16, 2010, at 7:51 PM, Nicolas Cellier wrote: > By the way, I created > http://code.google.com/p/pharo/issues/detail?id=1837 for these tests > > 2010/1/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I will check. >> >> Stef >> >> On Jan 16, 2010, at 5:14 PM, Nicolas Cellier wrote: >> >>> Then blockExtentsToTempsMap values are Arrays of pairs, not exactly >>> what expected by the test... >>> >>> Nicolas >>> >>> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>> Correct message is blockExtentsToTempsMap rather than blockExtentsToTempRefs >>>> >>>> But then, method still fails because keys does not answer a Set >>>> anymore. Use keys asSet. >>>> >>>> Nicolas >>>> >>>> 2010/1/16 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >>>>> The test is incompatible with new CompiledMethod trailer >>>>> Use generate rather than generate: #(0 0 0 0) >>>>> >>>>> Then the method still fails because sending unimplemented >>>>> #blockExtentsToTempRefs >>>>> >>>>> same for testBlockNumberingForInjectInto testTempNameAccessForInjectInto >>>>> >>>>> Nicolas >>>>> >>>> >>> >>> _______________________________________________ >>> 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

Jan. 16, 2010

[Pharo-project] [update 1.1] #11165

by Marcus Denker

11165 ----- Issue 1835: Use selectorsAndMethodsDo: Issue 1837: Correct some failing tests in Pharo 1.1 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 16, 2010