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

[Pharo-project] Smalltalk (Pharo) and String equality

by laurent laffont

Hi, Something strange to me: '2' = '2'. -> true (OK) (2 asString) = (2 asString). -> true (OK) (2 asString) == (2 asString). -> false (OK) '2' == '2'. -> true ????? Laurent

Jan. 17, 2010

Re: [Pharo-project] About versions on PharoInbox

by Miguel Enrique CobÃ¡ Martinez

El dom, 17-01-2010 a las 09:51 +0100, Levente Uzonyi escribiÃ³: > Sure, 1.0 and 1.1 shares the same inbox. > > Oh, :) that explains it. Thanks -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 17, 2010

Re: [Pharo-project] us the vm -memory in an image ?

by HernÃ¡n Morales Durand

Hi John, 2010/1/16 John M McIntosh <johnmci(a)smalltalkconsulting.com>: > > On 2010-01-16, at 4:08 PM, csrabak(a)bol.com.br wrote: > >> >> Is there a way to download a file of the presentation (be it powerpoint or PDF)? > > A subset at > http://www.esug.org/data/ESUG2006/pres/gctalkjohnmacintosh.pdf > > Generally I give a talk on the current paper to clients who pay for GC consulting. It takes about 3-4 hours to give at the moment. > Have you started experiments or do you plan to include information about (dead) timestamped garbage collection mechanisms? I don't understand some of the statistical graphics (pages 80, 82-86), have you used MMU or BMU curves to display the GC responsiveness? (just thinking, it would be cool to show application-centric GC metrics) Best regards, HernÃ¡n

Jan. 17, 2010

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

by Schwab,Wilhelm K

Stef, I don't care too much, and I have described how I will handle it if it again arises in my work. To do what you are describing, there needs to be a second argument specifying the pivot year for the cleanup/guess. A useful variant would be to specify instead the date on which the data was recorded, with an algorithm to arrive at a likely pivot date. 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: Sunday, January 17, 2010 9:36 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' Thanks david Now I think that we could have Date readFromTwoDigitYear: or something like that. And that Date readFromString: always reads a coherent 4 digits year. > This seems to have been more controversial than I expected. I'm going > to write this post in which I will: > > - try to make the case for supporting 2-digit years in some sensible > way > - answer some of the counter-arguments and questions that people have > raised > > ... at which point I intend to withdraw, and the community will no > doubt reach some sensible conclusion. > > David > > The case for accepting 2-digit years is, I think, very simple: it's useful. > Like it or not, data sometimes comes that way and this has to be dealt with. > > Granted, this means that we have to introduce some heuristic to guess > which century is intended. But we can have clever vs. explicit readFrom: '06-jan-30' what is it 1930 or 2030 readFrom: '06-jan-30' usingBaseForYear: 2000 -> 2030 I prefer explicit because it produces more robust code. > However, I don't see that this is so bad. Amongst the possible > approaches are: > > - Following the Posix standard for strptime, the date is assumed to > be between 1969 and 2068 (see > http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html) > Python goes this way, for example. > > - the date is assumed to be between 80 years in the past and 20 years > in the future (eg Java's SimpleDateFormat, see > http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html) > > - allow the 100 year-period in which 2-digit years will be placed to > be specified (eg the Java SimpleDateFormat also allows this) > . Year: For formatting, if the number of pattern letters is 2, the year is truncated to 2 digits; otherwise it is interpreted as a number. For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D. For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn't all digits (for example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC. http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html > > > Now I will address some concerns that people have raised. > > The first is essentially aesthetic: this kind of cleverness should not > be there, and everyone should always use four-digit years. I've some > sympathy with this, and it would be wonderful if everyone was as > principled as we are. But, alas, it is not so! My judgment is that > it's worth a little ugliness to be able to deal with the common case of two-digit years. > > A second objection was that the code was right all along: '6-Jan-10' > should correctly be parsed as 6th January 1910. This seems to me > peculiar. I understand a position that says that two-digit years > should not be accepted at all, but arguing that they should be > accepted and should be interpreted to be 100 or more years ago... > well, this seems unlikely to be the most useful approach. > > A third objection was that this is the thin end of the wedge: if we > start accepting two-digit years, who knows where the madness will end? > We will have to deal with all kinds of crazy situation! > > I think that this objection is just wrong. Noone is arguing for > three-digit dates, or hexadecimal dates, or any other crazy stuff. > Two-digits are commonplace. Other crazy things are not commonplace. > Let's draw the line where it makes sense to draw the line: to my mind > handling two-digit years clearly falls on the 'useful' side and not the 'crazy' side. > > Finally, I must note the irony of one poster declaring that we should > only accept well-formed strings, and pointing us at RFC822 for > reference. Years in RFC822 are defined to have two digits. The RFC > does not say what century they should fall in. (This has been > obsoleted by RFC2822, which uses four-digit years). > > > > "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message > news:78E0F3D1-D169-43D9-B12E-6C9D4E2860C5@inria.fr... >> 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: >> <day> <monthName> <year> (5 April 1982; 5-APR-82) <monthName> <day> >> <year> (April 5, 1982) <monthNumber> <day> <year> (4/5/82) >> <day><monthName><year> (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

Jan. 17, 2010

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

by Schwab,Wilhelm K

David, There is a simpler solution: parse 6-Jan-10 as exactly what it *says* - 2000 years ago. Then let the programmer who got stuck with the garbage data figure it out. At a minimum, one should have to provide a pivot date for the conversion to happen. In my world, the most common examples of two digit years come from a computer system built and operated during the 1990s. Sad, huh. It was a pearl of user interface design, and otherwise a complete technical disaster that worked more by accident than design, but the data contained in it is priceless. An appropriate pivot date would be the date of the document, not "today." I suspect that the problem of separate context will be wide spread. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David Hotham Sent: Sunday, January 17, 2010 9:18 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Date fromString: '6-Jan-10' This seems to have been more controversial than I expected. I'm going to write this post in which I will: - try to make the case for supporting 2-digit years in some sensible way - answer some of the counter-arguments and questions that people have raised ... at which point I intend to withdraw, and the community will no doubt reach some sensible conclusion. David The case for accepting 2-digit years is, I think, very simple: it's useful. Like it or not, data sometimes comes that way and this has to be dealt with. Granted, this means that we have to introduce some heuristic to guess which century is intended. However, I don't see that this is so bad. Amongst the possible approaches are: - Following the Posix standard for strptime, the date is assumed to be between 1969 and 2068 (see http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html) Python goes this way, for example. - the date is assumed to be between 80 years in the past and 20 years in the future (eg Java's SimpleDateFormat, see http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html) - allow the 100 year-period in which 2-digit years will be placed to be specified (eg the Java SimpleDateFormat also allows this) Now I will address some concerns that people have raised. The first is essentially aesthetic: this kind of cleverness should not be there, and everyone should always use four-digit years. I've some sympathy with this, and it would be wonderful if everyone was as principled as we are. But, alas, it is not so! My judgment is that it's worth a little ugliness to be able to deal with the common case of two-digit years. A second objection was that the code was right all along: '6-Jan-10' should correctly be parsed as 6th January 1910. This seems to me peculiar. I understand a position that says that two-digit years should not be accepted at all, but arguing that they should be accepted and should be interpreted to be 100 or more years ago... well, this seems unlikely to be the most useful approach. A third objection was that this is the thin end of the wedge: if we start accepting two-digit years, who knows where the madness will end? We will have to deal with all kinds of crazy situation! I think that this objection is just wrong. Noone is arguing for three-digit dates, or hexadecimal dates, or any other crazy stuff. Two-digits are commonplace. Other crazy things are not commonplace. Let's draw the line where it makes sense to draw the line: to my mind handling two-digit years clearly falls on the 'useful' side and not the 'crazy' side. Finally, I must note the irony of one poster declaring that we should only accept well-formed strings, and pointing us at RFC822 for reference. Years in RFC822 are defined to have two digits. The RFC does not say what century they should fall in. (This has been obsoleted by RFC2822, which uses four-digit years). "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:78E0F3D1-D169-43D9-B12E-6C9D4E2860C5@inria.fr... > 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: > <day> <monthName> <year> (5 April 1982; 5-APR-82) > <monthName> <day> <year> (April 5, 1982) > <monthNumber> <day> <year> (4/5/82) > <day><monthName><year> (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

Jan. 17, 2010

[Pharo-project] [ANN 1.1] prebuilt core#11165

by Marcus Denker

http://gforge.inria.fr/frs/download.php/25199/PharoCore-1.1-11165-UNSTABLE.… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 17, 2010

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

by StÃ©phane Ducasse

Thanks david Now I think that we could have Date readFromTwoDigitYear: or something like that. And that Date readFromString: always reads a coherent 4 digits year. > This seems to have been more controversial than I expected. I'm going to > write this post in which I will: > > - try to make the case for supporting 2-digit years in some sensible way > - answer some of the counter-arguments and questions that people have > raised > > ... at which point I intend to withdraw, and the community will no doubt > reach some sensible conclusion. > > David > > The case for accepting 2-digit years is, I think, very simple: it's useful. > Like it or not, data sometimes comes that way and this has to be dealt with. > > Granted, this means that we have to introduce some heuristic to guess which > century is intended. But we can have clever vs. explicit readFrom: '06-jan-30' what is it 1930 or 2030 readFrom: '06-jan-30' usingBaseForYear: 2000 -> 2030 I prefer explicit because it produces more robust code. > However, I don't see that this is so bad. Amongst the > possible approaches are: > > - Following the Posix standard for strptime, the date is assumed to be > between 1969 and 2068 (see > http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html) > Python goes this way, for example. > > - the date is assumed to be between 80 years in the past and 20 years in > the future (eg Java's SimpleDateFormat, see > http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html) > > - allow the 100 year-period in which 2-digit years will be placed to be > specified (eg the Java SimpleDateFormat also allows this) > â¢ Year: For formatting, if the number of pattern letters is 2, the year is truncated to 2 digits; otherwise it is interpreted as a number. For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern "MM/dd/yyyy", "01/11/12" parses to Jan 11, 12 A.D. For parsing with the abbreviated year pattern ("y" or "yy"), SimpleDateFormat must interpret the abbreviated year relative to some century. It does this by adjusting dates to be within 80 years before and 20 years after the time the SimpleDateFormat instance is created. For example, using a pattern of "MM/dd/yy" and a SimpleDateFormat instance created on Jan 1, 1997, the string "01/11/12" would be interpreted as Jan 11, 2012 while the string "05/04/64" would be interpreted as May 4, 1964. During parsing, only strings consisting of exactly two digits, as defined by Character.isDigit(char), will be parsed into the default century. Any other numeric string, such as a one digit string, a three or more digit string, or a two digit string that isn't all digits (for example, "-1"), is interpreted literally. So "01/02/3" or "01/02/003" are parsed, using the same pattern, as Jan 2, 3 AD. Likewise, "01/02/-3" is parsed as Jan 2, 4 BC. http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html > > > Now I will address some concerns that people have raised. > > The first is essentially aesthetic: this kind of cleverness should not be > there, and everyone should always use four-digit years. I've some sympathy > with this, and it would be wonderful if everyone was as principled as we > are. But, alas, it is not so! My judgment is that it's worth a little > ugliness to be able to deal with the common case of two-digit years. > > A second objection was that the code was right all along: '6-Jan-10' should > correctly be parsed as 6th January 1910. This seems to me peculiar. I > understand a position that says that two-digit years should not be accepted > at all, but arguing that they should be accepted and should be interpreted > to be 100 or more years ago... well, this seems unlikely to be the most > useful approach. > > A third objection was that this is the thin end of the wedge: if we start > accepting two-digit years, who knows where the madness will end? We will > have to deal with all kinds of crazy situation! > > I think that this objection is just wrong. Noone is arguing for three-digit > dates, or hexadecimal dates, or any other crazy stuff. Two-digits are > commonplace. Other crazy things are not commonplace. Let's draw the line > where it makes sense to draw the line: to my mind handling two-digit years > clearly falls on the 'useful' side and not the 'crazy' side. > > Finally, I must note the irony of one poster declaring that we should only > accept well-formed strings, and pointing us at RFC822 for reference. Years > in RFC822 are defined to have two digits. The RFC does not say what century > they should fall in. (This has been obsoleted by RFC2822, which uses > four-digit years). > > > > "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in > message news:78E0F3D1-D169-43D9-B12E-6C9D4E2860C5@inria.fr... >> 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: >> <day> <monthName> <year> (5 April 1982; 5-APR-82) >> <monthName> <day> <year> (April 5, 1982) >> <monthNumber> <day> <year> (4/5/82) >> <day><monthName><year> (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

Jan. 17, 2010

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

by David Hotham

This seems to have been more controversial than I expected. I'm going to write this post in which I will: - try to make the case for supporting 2-digit years in some sensible way - answer some of the counter-arguments and questions that people have raised ... at which point I intend to withdraw, and the community will no doubt reach some sensible conclusion. David The case for accepting 2-digit years is, I think, very simple: it's useful. Like it or not, data sometimes comes that way and this has to be dealt with. Granted, this means that we have to introduce some heuristic to guess which century is intended. However, I don't see that this is so bad. Amongst the possible approaches are: - Following the Posix standard for strptime, the date is assumed to be between 1969 and 2068 (see http://www.opengroup.org/onlinepubs/009695399/functions/strptime.html) Python goes this way, for example. - the date is assumed to be between 80 years in the past and 20 years in the future (eg Java's SimpleDateFormat, see http://java.sun.com/javase/7/docs/api/java/text/SimpleDateFormat.html) - allow the 100 year-period in which 2-digit years will be placed to be specified (eg the Java SimpleDateFormat also allows this) Now I will address some concerns that people have raised. The first is essentially aesthetic: this kind of cleverness should not be there, and everyone should always use four-digit years. I've some sympathy with this, and it would be wonderful if everyone was as principled as we are. But, alas, it is not so! My judgment is that it's worth a little ugliness to be able to deal with the common case of two-digit years. A second objection was that the code was right all along: '6-Jan-10' should correctly be parsed as 6th January 1910. This seems to me peculiar. I understand a position that says that two-digit years should not be accepted at all, but arguing that they should be accepted and should be interpreted to be 100 or more years ago... well, this seems unlikely to be the most useful approach. A third objection was that this is the thin end of the wedge: if we start accepting two-digit years, who knows where the madness will end? We will have to deal with all kinds of crazy situation! I think that this objection is just wrong. Noone is arguing for three-digit dates, or hexadecimal dates, or any other crazy stuff. Two-digits are commonplace. Other crazy things are not commonplace. Let's draw the line where it makes sense to draw the line: to my mind handling two-digit years clearly falls on the 'useful' side and not the 'crazy' side. Finally, I must note the irony of one poster declaring that we should only accept well-formed strings, and pointing us at RFC822 for reference. Years in RFC822 are defined to have two digits. The RFC does not say what century they should fall in. (This has been obsoleted by RFC2822, which uses four-digit years). "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote in message news:78E0F3D1-D169-43D9-B12E-6C9D4E2860C5@inria.fr... > 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: > <day> <monthName> <year> (5 April 1982; 5-APR-82) > <monthName> <day> <year> (April 5, 1982) > <monthNumber> <day> <year> (4/5/82) > <day><monthName><year> (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

Jan. 17, 2010

Re: [Pharo-project] strange local variable problem

by Tudor Girba

Indeed, my bad. Cheers, Doru On 17 Jan 2010, at 09:57, Lukas Renggli wrote: >> I believe this is a bug. > > That's the correct behavior. This is exactly how closures should > behave. The variable declaration is outside the block you store thus > one variable slot is shared among multiple block definitions inside. > See ClosureTests for more examples of that behavior. > > Lukas > > -- > 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 -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

Jan. 17, 2010

Re: [Pharo-project] Spell check test cases

by Mariano Martinez Peck

Thanks Stan for the warning. Ok, I will then wait yet until everything is in rb repository and tests are green. Cheers Mariano On Sun, Jan 17, 2010 at 12:31 AM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 17, 2010