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

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

by Miguel Enrique CobÃ¡ Martinez

El dom, 17-01-2010 a las 14:17 +0000, David Hotham escribiÃ³: > 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. Yes, but it can be handled in your code, by first massaging the legacy input data and then, after is 4 digits, passing it to the smalltalk code. This way the core library doesn't get dirty with special cases and your app works correctly. So first correct your input and then proccess it. Just like a web app. Don't assume the input data is ok. Cheers > > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 17, 2010

Re: [Pharo-project] SystemWindow updatablePanes ivar

by Igor Stasenko

2010/1/17 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Jan 17, 2010, at 4:33 AM, Igor Stasenko wrote: > >> Hello, >> >> I completely lost in the logic of this thing. >> >> why a SystemWindow cares about something called panes? >> What if my window don't having/needs any of them? >> Why Object cares about #updateListsAndCodeIn: aWindow ??? >> >> If model is updated, then it should just send #changed, or self >> changed: #myPaneFoo >> and if SystemWindow's pane is dependent, it will be updated. > > May be this is related to the fact that the style gets propagated to its subcomponent. > I know I was bitten by that some years ago. > >> >> What the point in using #verifyContents... >> >> This thing needs to be cleaned up. > > yes ;) > I perusing the code in PluggableXXX classes, and i feel sick of it. All PluggableXXX classes has many repeatable patterns, like declaring getXXXSelector, which then serves for fetching the properties from model , like list, selected item, lable etc.. And this is also related to #update: method, which these morphs handling usually like: update: property property == getXXXSelector ifTrue: [ propertyXValue := model perform: getXXXSelector ] property == getYYYSelector ifTrue: [ propertyYValue := model perform: getYYYSelector ] So, each morph, which depends from model, has to pull the value from model manually. But, we could do the same, by pushing the property to dependents. MyModel>>setMyProperty: value ^ self notifyChange: #myProperty from: myProperty to: (myProperty := value ) MyModel>>notifyChange: propertyName from: oldValue to: newValue self dependents do: [:each | ( each perform: ('update', propertyName) asSymbol ) value: oldValue value: newValue MyMorph>>updateMyProperty ^ [:oldValue :newValue | self doSomethingWith: oldValue and: newValue ] in the above, a model just pushing new values, and morph handling updates directly, without need to keep getXXXSelector ivars to know, how to retrieve some property from model, or determine the correspondence between property name and way how to handle it. >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Jan. 17, 2010

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

by Nicolas Cellier

One of my first bug in st80 was strange ^('foo' writeStream) nextPutAll: '-bar'; contents. At that time, writing pastEnd did use become: But if you really have time to pick an immutability bit in Newspeak, we don't have to care anymore. Nicolas 2010/1/17 Marcus Denker <marcus.denker(a)inria.fr>: > > On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > >> Hi, >> >> Something strange to me: >> >> '2' = '2'. -> true Â (OK) >> (2 asString) = (2 asString). -> true Â (OK) >> >> (2 asString) == (2 asString). -> false Â (OK) >> '2' == '2'. -> true Â ????? >> > > Yes, the same string in the same method points to the same entry in the literalframe. > > Which explains why this method works: > > strange > Â Â Â Â 'hello world' isString ifTrue: ['hello world' become: {0}]. > Â Â Â Â 'hello world' at: 1 put: ('hello world' at:1) + 1 . > Â Â Â Â ^'hello world' Â at: 1. > > Put this method in Object, than print multiple times: > > Â Â Â Â Object new strange > > :-) > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > 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] Smalltalk (Pharo) and String equality

by Marcus Denker

On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > Hi, > > Something strange to me: > > '2' = '2'. -> true (OK) > (2 asString) = (2 asString). -> true (OK) > > (2 asString) == (2 asString). -> false (OK) > '2' == '2'. -> true ????? > Yes, the same string in the same method points to the same entry in the literalframe. Which explains why this method works: strange 'hello world' isString ifTrue: ['hello world' become: {0}]. 'hello world' at: 1 put: ('hello world' at:1) + 1 . ^'hello world' at: 1. Put this method in Object, than print multiple times: Object new strange :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 17, 2010

[Pharo-project] PrStef renamed to ProfStef

by laurent laffont

So now it's Gofer new squeaksource: 'ProfStef'; package: 'ProfStef'; load. Laurent

Jan. 17, 2010

Re: [Pharo-project] About versions on PharoInbox

by Marcus Denker

On Jan 17, 2010, at 6:22 PM, Miguel Enrique CobÃ¡ Martinez wrote: > 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. Maybe we should change that at some point... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 17, 2010

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

by laurent laffont

On Sun, Jan 17, 2010 at 6:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > this is because of an optimisation > > string inside the same methods are reused. > OK > if you want to show that string are different than symbol use two methods > returning the same strings > Hey !! Telepathy power ? You've used the force ? You master the Wakfu ? Laurent > > > > On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > > > 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 > > _______________________________________________ > > 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] Smalltalk (Pharo) and String equality

by Mariano Martinez Peck

I think the same happens in Java. It is a VM optimization. Compare "Something" == "Something" true On Sun, Jan 17, 2010 at 6:33 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > this is because of an optimisation > > string inside the same methods are reused. > > if you want to show that string are different than symbol use two methods > returning the same strings > > > > On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > > > 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 > > _______________________________________________ > > 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] Smalltalk (Pharo) and String equality

by StÃ©phane Ducasse

this is because of an optimisation string inside the same methods are reused. if you want to show that string are different than symbol use two methods returning the same strings On Jan 17, 2010, at 6:30 PM, laurent laffont wrote: > 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 > _______________________________________________ > 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] NewCompiler load on PharoCore

by Marcus Denker

On Jan 14, 2010, at 7:56 PM, Eliot Miranda wrote: > > > On Thu, Jan 14, 2010 at 12:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Elliot > > it would be realllllllly cool to have this in the squeak-vm what should be done to get it? > > I'll upload the Newspeak VMMaker package to a suitable repository. I could also try and do an extract and merge. > Alternatively someone who is interested could do the same starting from the Newspeak release. > > I would be interested to have a look at some point... maybe not the next weeks, but it would really be nice to have that. So I am sure I will find time at some point. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 17, 2010