'foo' asTime
Locked
123
123
 
|
On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote: > Odd, my 3.9 works. > > Method ByteArray>>asInteger by "len 10/15/2002 18:45" > > Regards, Gary > Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry > ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]> > To: <[hidden email]> > Sent: Monday, August 23, 2010 11:33 AM > Subject: Re: [Pharo-project] 'foo' asTime > > > > On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote: > >> He was porting his stuff from Squeak 3.9 >> >> 3107 apparently. >> >> c.f. >> #(12 35) asByteArray asInteger asByteArray > > > This is what I tried > #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. > Then a nice explicit loops should make it too. > > Stef > >> >> Unfortunately heavily used when doing low-level stuff with external devices socket data etc. >> (let us not get into endianess either though ;-) ) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]> >> To: <[hidden email]> >> Sent: Monday, August 23, 2010 11:01 AM >> Subject: Re: [Pharo-project] 'foo' asTime >> >> >>> #[12 35] asInteger >>> is not in 1.0, 1.1, and 1.2 >>> It does not work in squeak trunk either >>> did not work in 3.9 either. >>> So I'm puzzled. >>> >>> Now everybody can create his own personal package with the extensions they like. >>> >>> Stef >>> >>> On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote: >>> >>>> +1 >>>> >>>> One of our developers recently complained of #asInteger being removed from ByteArray for instance... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Brent Pinkney" <[hidden email]> >>>> To: <[hidden email]> >>>> Sent: Monday, August 23, 2010 8:00 AM >>>> Subject: Re: [Pharo-project] 'foo' asTime >>>> >>>> >>>>>> I would really like to have the approach proposed by K. Beck on conversion >>>>>> methods. Conversion methods for API compatible objects. Of course it will >>>>>> lead to less compact program (URL readFrom: 'http://' instead of 'http://' >>>>>> url) but avoids a lot of code in String (of course class extensions limit >>>>>> the plague). >>>>> >>>>> Hi, please reconsider this. There is just no way (Duration seconds: 3) is >>>>> better than '3 seconds'. >>>>> >>>>> This smacks of working for the computer instead of the other way around. >>>>> >>>>> Brent >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Indeed it would make sense.
On Aug 23, 2010, at 2:03 PM, Henrik Johansen wrote: > > On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote: > >> Odd, my 3.9 works. >> >> Method ByteArray>>asInteger by "len 10/15/2002 18:45" >> >> Regards, Gary >> > > Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. > Maybe you have the Cryptography package in your 3.9 image, and that included it? > > Cheers, > Henry > > >> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]> >> To: <[hidden email]> >> Sent: Monday, August 23, 2010 11:33 AM >> Subject: Re: [Pharo-project] 'foo' asTime >> >> >> >> On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote: >> >>> He was porting his stuff from Squeak 3.9 >>> >>> 3107 apparently. >>> >>> c.f. >>> #(12 35) asByteArray asInteger asByteArray >> >> >> This is what I tried >> #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. >> Then a nice explicit loops should make it too. >> >> Stef >> >>> >>> Unfortunately heavily used when doing low-level stuff with external devices socket data etc. >>> (let us not get into endianess either though ;-) ) >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Stéphane Ducasse" <[hidden email]> >>> To: <[hidden email]> >>> Sent: Monday, August 23, 2010 11:01 AM >>> Subject: Re: [Pharo-project] 'foo' asTime >>> >>> >>>> #[12 35] asInteger >>>> is not in 1.0, 1.1, and 1.2 >>>> It does not work in squeak trunk either >>>> did not work in 3.9 either. >>>> So I'm puzzled. >>>> >>>> Now everybody can create his own personal package with the extensions they like. >>>> >>>> Stef >>>> >>>> On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote: >>>> >>>>> +1 >>>>> >>>>> One of our developers recently complained of #asInteger being removed from ByteArray for instance... >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Brent Pinkney" <[hidden email]> >>>>> To: <[hidden email]> >>>>> Sent: Monday, August 23, 2010 8:00 AM >>>>> Subject: Re: [Pharo-project] 'foo' asTime >>>>> >>>>> >>>>>>> I would really like to have the approach proposed by K. Beck on conversion >>>>>>> methods. Conversion methods for API compatible objects. Of course it will >>>>>>> lead to less compact program (URL readFrom: 'http://' instead of 'http://' >>>>>>> url) but avoids a lot of code in String (of course class extensions limit >>>>>>> the plague). >>>>>> >>>>>> Hi, please reconsider this. There is just no way (Duration seconds: 3) is >>>>>> better than '3 seconds'. >>>>>> >>>>>> This smacks of working for the computer instead of the other way around. >>>>>> >>>>>> Brent >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> [hidden email] >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Henrik Sperre Johansen
Ar, that'd be it...
Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <[hidden email]> To: <[hidden email]> Sent: Monday, August 23, 2010 1:03 PM Subject: Re: [Pharo-project] 'foo' asTime On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote: > Odd, my 3.9 works. > > Method ByteArray>>asInteger by "len 10/15/2002 18:45" > > Regards, Gary > Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry > ----- Original Message ----- From: "Stéphane Ducasse" > <[hidden email]> > To: <[hidden email]> > Sent: Monday, August 23, 2010 11:33 AM > Subject: Re: [Pharo-project] 'foo' asTime > > > > On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote: > >> He was porting his stuff from Squeak 3.9 >> >> 3107 apparently. >> >> c.f. >> #(12 35) asByteArray asInteger asByteArray > > > This is what I tried > #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it > barks. > Then a nice explicit loops should make it too. > > Stef > >> >> Unfortunately heavily used when doing low-level stuff with external >> devices socket data etc. >> (let us not get into endianess either though ;-) ) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Stéphane Ducasse" >> <[hidden email]> >> To: <[hidden email]> >> Sent: Monday, August 23, 2010 11:01 AM >> Subject: Re: [Pharo-project] 'foo' asTime >> >> >>> #[12 35] asInteger >>> is not in 1.0, 1.1, and 1.2 >>> It does not work in squeak trunk either >>> did not work in 3.9 either. >>> So I'm puzzled. >>> >>> Now everybody can create his own personal package with the extensions >>> they like. >>> >>> Stef >>> >>> On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote: >>> >>>> +1 >>>> >>>> One of our developers recently complained of #asInteger being removed >>>> from ByteArray for instance... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Brent Pinkney" <[hidden email]> >>>> To: <[hidden email]> >>>> Sent: Monday, August 23, 2010 8:00 AM >>>> Subject: Re: [Pharo-project] 'foo' asTime >>>> >>>> >>>>>> I would really like to have the approach proposed by K. Beck on >>>>>> conversion >>>>>> methods. Conversion methods for API compatible objects. Of course it >>>>>> will >>>>>> lead to less compact program (URL readFrom: 'http://' instead of >>>>>> 'http://' >>>>>> url) but avoids a lot of code in String (of course class extensions >>>>>> limit >>>>>> the plague). >>>>> >>>>> Hi, please reconsider this. There is just no way (Duration seconds: 3) >>>>> is >>>>> better than '3 seconds'. >>>>> >>>>> This smacks of working for the computer instead of the other way >>>>> around. >>>>> >>>>> Brent >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Though not an extension in the Crypto package...
Regards, Gary ----- Original Message ----- From: "Gary Chambers" <[hidden email]> To: <[hidden email]> Sent: Monday, August 23, 2010 2:20 PM Subject: Re: [Pharo-project] 'foo' asTime Ar, that'd be it... Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <[hidden email]> To: <[hidden email]> Sent: Monday, August 23, 2010 1:03 PM Subject: Re: [Pharo-project] 'foo' asTime On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote: > Odd, my 3.9 works. > > Method ByteArray>>asInteger by "len 10/15/2002 18:45" > > Regards, Gary > Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry > ----- Original Message ----- From: "Stéphane Ducasse" > <[hidden email]> > To: <[hidden email]> > Sent: Monday, August 23, 2010 11:33 AM > Subject: Re: [Pharo-project] 'foo' asTime > > > > On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote: > >> He was porting his stuff from Squeak 3.9 >> >> 3107 apparently. >> >> c.f. >> #(12 35) asByteArray asInteger asByteArray > > > This is what I tried > #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it > barks. > Then a nice explicit loops should make it too. > > Stef > >> >> Unfortunately heavily used when doing low-level stuff with external >> devices socket data etc. >> (let us not get into endianess either though ;-) ) >> >> Regards, Gary >> >> ----- Original Message ----- From: "Stéphane Ducasse" >> <[hidden email]> >> To: <[hidden email]> >> Sent: Monday, August 23, 2010 11:01 AM >> Subject: Re: [Pharo-project] 'foo' asTime >> >> >>> #[12 35] asInteger >>> is not in 1.0, 1.1, and 1.2 >>> It does not work in squeak trunk either >>> did not work in 3.9 either. >>> So I'm puzzled. >>> >>> Now everybody can create his own personal package with the extensions >>> they like. >>> >>> Stef >>> >>> On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote: >>> >>>> +1 >>>> >>>> One of our developers recently complained of #asInteger being removed >>>> from ByteArray for instance... >>>> >>>> Regards, Gary >>>> >>>> ----- Original Message ----- From: "Brent Pinkney" <[hidden email]> >>>> To: <[hidden email]> >>>> Sent: Monday, August 23, 2010 8:00 AM >>>> Subject: Re: [Pharo-project] 'foo' asTime >>>> >>>> >>>>>> I would really like to have the approach proposed by K. Beck on >>>>>> conversion >>>>>> methods. Conversion methods for API compatible objects. Of course it >>>>>> will >>>>>> lead to less compact program (URL readFrom: 'http://' instead of >>>>>> 'http://' >>>>>> url) but avoids a lot of code in String (of course class extensions >>>>>> limit >>>>>> the plague). >>>>> >>>>> Hi, please reconsider this. There is just no way (Duration seconds: 3) >>>>> is >>>>> better than '3 seconds'. >>>>> >>>>> This smacks of working for the computer instead of the other way >>>>> around. >>>>> >>>>> Brent >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> [hidden email] >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
As an off topic of 3 seconds...
Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev?
Chalten is a great Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :)
With Chalten you could simply write: December second, 2005. If you want to try them, just evaluate: Gofer new squeaksource: 'Chalten';
package: 'Chalten'; load. Cheers, Mariano. On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <[hidden email]> wrote: 3 seconds is indeed better. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
ok here is my take on it:
- I would like to have a mini kernel where date time is just good enough for what the system needs - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos so you see I would prefer that people pick the one they like. Now people can have a different opinion and I would like to hear them :) Stef On Aug 23, 2010, at 11:45 PM, Mariano Abel Coca wrote: > As an off topic of 3 seconds... > > Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev? > > Chalten is a great Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :) > > With Chalten you could simply write: December second, 2005. > > If you want to try them, just evaluate: > > Gofer new > squeaksource: 'Chalten'; > package: 'Chalten'; > load. > > Cheers, > > Mariano. > > > On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <[hidden email]> wrote: > 3 seconds is indeed better. > Right now we are talking about string over extension. > > Stef > > On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote: > > >> I would really like to have the approach proposed by K. Beck on conversion > >> methods. Conversion methods for API compatible objects. Of course it will > >> lead to less compact program (URL readFrom: 'http://' instead of 'http://' > >> url) but avoids a lot of code in String (of course class extensions limit > >> the plague). > > > > Hi, please reconsider this. There is just no way (Duration seconds: 3) is > > better than '3 seconds'. > > > > This smacks of working for the computer instead of the other way around. > > > > Brent > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Thinking aloud. I usually don't have to write dates in my code,
because they are picked by the user. I think that a well built kernel and nice well integrated UI widgets (maybe I'm going out of the scope :P ) are enough in most of the cases. Anyway, IMHO it's very important to review Time>>fromString: because it's useful for serialization stuff. Like webservices and that kind of things a lot of people have to use. I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 On Tue, Aug 24, 2010 at 8:24 AM, Stéphane Ducasse <[hidden email]> wrote: > ok here is my take on it: > - I would like to have a mini kernel where date time is just good enough for what the system needs > - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos > so you see I would prefer that people pick the one they like. > Now people can have a different opinion and I would like to hear them :) > > Stef > > On Aug 23, 2010, at 11:45 PM, Mariano Abel Coca wrote: > >> As an off topic of 3 seconds... >> >> Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev? >> >> Chalten is a great Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :) >> >> With Chalten you could simply write: December second, 2005. >> >> If you want to try them, just evaluate: >> >> Gofer new >> squeaksource: 'Chalten'; >> package: 'Chalten'; >> load. >> >> Cheers, >> >> Mariano. >> >> >> On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <[hidden email]> wrote: >> 3 seconds is indeed better. >> Right now we are talking about string over extension. >> >> Stef >> >> On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote: >> >> >> I would really like to have the approach proposed by K. Beck on conversion >> >> methods. Conversion methods for API compatible objects. Of course it will >> >> lead to less compact program (URL readFrom: 'http://' instead of 'http://' >> >> url) but avoids a lot of code in String (of course class extensions limit >> >> the plague). >> > >> > Hi, please reconsider this. There is just no way (Duration seconds: 3) is >> > better than '3 seconds'. >> > >> > This smacks of working for the computer instead of the other way around. >> > >> > Brent >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 24 Aug 2010, at 13:51, Guillermo Polito wrote: > Thinking aloud. I usually don't have to write dates in my code, > because they are picked by the user. > I think that a well built kernel and nice well integrated UI widgets > (maybe I'm going out of the scope :P ) are enough in most of the > cases. +1 I like the libraries that support to write dates and times in neat Smalltalk ways, but they should not compromise the use of date-times when handling strings coming from the UI front-end. Having a 'xxxx' asString that does not return an error when the timestring is wrong cripples that. You would essentially need to use a separate parser-checker before trying to use the basic conversion libraries for date-times. > Anyway, IMHO it's very important to review Time>>fromString: because > it's useful for serialization stuff. Like webservices and that kind > of things a lot of people have to use. > > I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 +1 Are you already onto it? If not, I can make my hands dirty on this one ;-) _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Aug 24, 2010 at 9:55 AM, Johan Brichau <[hidden email]> wrote:
> > On 24 Aug 2010, at 13:51, Guillermo Polito wrote: > >> Thinking aloud. I usually don't have to write dates in my code, >> because they are picked by the user. >> I think that a well built kernel and nice well integrated UI widgets >> (maybe I'm going out of the scope :P ) are enough in most of the >> cases. > > +1 > I like the libraries that support to write dates and times in neat Smalltalk ways, but they should not compromise the use of date-times when handling strings coming from the UI front-end. Having a 'xxxx' asString that does not return an error when the timestring is wrong cripples that. You would essentially need to use a separate parser-checker before trying to use the basic conversion libraries for date-times. > >> Anyway, IMHO it's very important to review Time>>fromString: because >> it's useful for serialization stuff. Like webservices and that kind >> of things a lot of people have to use. >> >> I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 > > +1 > Are you already onto it? If not, I can make my hands dirty on this one ;-) All yours I think :P. > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 24 Aug 2010, at 15:01, Guillermo Polito wrote: >>> I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 >> >> +1 >> Are you already onto it? If not, I can make my hands dirty on this one ;-) > > All yours I think :P. great :-/ Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
>>>> I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 >>> >>> +1 >>> Are you already onto it? If not, I can make my hands dirty on this one ;-) >> >> All yours I think :P. > > great :-/ > > Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me. I thought that readFromString: was raising an error and that guessNumber* was returning zero _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Johan Brichau-2
readFrom: aStringOrStream base: base
"Answer an instance of one of the concrete subclasses if Integer. Initial minus sign accepted, and bases > 10 use letters A-Z. Imbedded radix specifiers not allowed; use Number class readFrom: for that. Raise an Error if there are no digits. If stringOrStream dos not start with a valid number description, answer 0 for backward compatibility. This is not clever and should better be changed." ^(SqNumberParser on: aStringOrStream) failBlock: [^0]; nextIntegerBase: base Mmm, I hate backwards compatibility ¬¬. Maybe we can... 1) create a new Integer>>fromStringOrAnotherNameThatPleaseUs: which fails when it has to :) 2) deprecate the old one? So we can change the dependants gradually. On Tue, Aug 24, 2010 at 10:16 AM, Johan Brichau <[hidden email]> wrote: > > On 24 Aug 2010, at 15:01, Guillermo Polito wrote: > >>>> I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 >>> >>> +1 >>> Are you already onto it? If not, I can make my hands dirty on this one ;-) >> >> All yours I think :P. > > great :-/ > > Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me. > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > I thought that readFromString: was raising an error and that guessNumber* was returning zero I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But: 'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error aargh :-( disclaimer: currently testing this in pharo1.1 Johan _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <[hidden email]>: > > On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > >> I thought that readFromString: was raising an error and that guessNumber* was returning zero > > I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > But: > > 'foo' asInteger = nil > Integer readFromString: 'foo' = 0 > 'foo' asNumber -> Error > > aargh :-( > > disclaimer: currently testing this in pharo1.1 > > Johan > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
2010/8/24 Stéphane Ducasse <[hidden email]>:
> ok here is my take on it: > - I would like to have a mini kernel where date time is just good enough for what the system needs > - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos > so you see I would prefer that people pick the one they like. > Now people can have a different opinion and I would like to hear them :) > I have a different opinion :) - Time is presupposed in every computer system I've seen, I would like to have or see a system without Time. Such is the influence of Kant today. - If one could remove the time and experiment teaching the system like an idealist would do, this could open doors to whole new things. - Bottom line, I would like to replace time instead of having just one mini kernel Does time exists if nothing is changed? ;) Hernán _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Nicolas Cellier
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible? So I would give a try to get readFrom: clean. Johan please give a try Stef > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <[hidden email]>: >> >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >> >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty
On Wed, Aug 25, 2010 at 4:32 AM, Stéphane Ducasse <[hidden email]> wrote: Hi nicolas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
cool now let us see where it breaks and fix.
Stef On Aug 25, 2010, at 3:58 PM, Guillermo Polito wrote: > I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty > > On Wed, Aug 25, 2010 at 4:32 AM, Stéphane Ducasse <[hidden email]> wrote: > Hi nicolas > > If I understand you correctly we are in sync. > Yes readFrom: should read or fails raising an Error > and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] > > Now we integrated your number parsers so this is strange that the behavior is not like you mention > did you make them backwards compatible? > > So I would give a try to get readFrom: clean. > Johan please give a try > > Stef > > > > > In squeak, (Integer readFromString: 'foo') ->Error > > > > Use: > > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > > - (Integer readFrom: 'foo' ifFail: []), to get nil > > > > Though it is possible, I dislike anwsering nil, because it would mean > > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > > 1) That's nonsense, readFrom:ifFail: already does the work. > > 2) you cripple the code with Error conditions and end up with > > unreadable C-looking like code > > (3 lines of Error condition crap for 1 line of underlying algorithm > > at every function call) > > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > > > But that conversation already took place many times... > > > > I'd like the readFrom:ifFail: form to be generalized to other objects, > > with default behaviour raising an Error. What do you think ? > > > > Nicolas > > > > 2010/8/24 Johan Brichau <[hidden email]>: > >> > >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: > >> > >>> I thought that readFromString: was raising an error and that guessNumber* was returning zero > >> > >> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... > >> But: > >> > >> 'foo' asInteger = nil > >> Integer readFromString: 'foo' = 0 > >> 'foo' asNumber -> Error > >> > >> aargh :-( > >> > >> disclaimer: currently testing this in pharo1.1 > >> > >> Johan > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
2010/8/25 Stéphane Ducasse <[hidden email]>:
> Hi nicolas > > If I understand you correctly we are in sync. > Yes readFrom: should read or fails raising an Error > and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] > > Now we integrated your number parsers so this is strange that the behavior is not like you mention > did you make them backwards compatible? > > So I would give a try to get readFrom: clean. > Johan please give a try > > Stef > Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting. See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format'] One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream Nicolas > > >> In squeak, (Integer readFromString: 'foo') ->Error >> >> Use: >> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >> - (Integer readFrom: 'foo' ifFail: []), to get nil >> >> Though it is possible, I dislike anwsering nil, because it would mean >> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >> 1) That's nonsense, readFrom:ifFail: already does the work. >> 2) you cripple the code with Error conditions and end up with >> unreadable C-looking like code >> (3 lines of Error condition crap for 1 line of underlying algorithm >> at every function call) >> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >> >> But that conversation already took place many times... >> >> I'd like the readFrom:ifFail: form to be generalized to other objects, >> with default behaviour raising an Error. What do you think ? >> >> Nicolas >> >> 2010/8/24 Johan Brichau <[hidden email]>: >>> >>> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >>> >>>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >>> >>> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >>> But: >>> >>> 'foo' asInteger = nil >>> Integer readFromString: 'foo' = 0 >>> 'foo' asNumber -> Error >>> >>> aargh :-( >>> >>> disclaimer: currently testing this in pharo1.1 >>> >>> Johan >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Aug 25, 2010, at 10:50 PM, Nicolas Cellier wrote: > 2010/8/25 Stéphane Ducasse <[hidden email]>: >> Hi nicolas >> >> If I understand you correctly we are in sync. >> Yes readFrom: should read or fails raising an Error >> and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] >> >> Now we integrated your number parsers so this is strange that the behavior is not like you mention >> did you make them backwards compatible? >> >> So I would give a try to get readFrom: clean. >> Johan please give a try >> >> Stef >> > > Yes, all the infrastructure is there, just change the top message to > be awkward-uncompatible ;) like Guillermo is suggesting. I integrated the changes of guillermo. But readFrom:ifFail: is a nice API. > See also my other suggestion: implement #readFrom:ifFail: in every > class instead of #readFrom: and let readFrom default implementation to > just be > ^self readFrom: aStream ifFail: [self error: 'invalid format'] > > One question I'm not sure about is whether we should distinguish 2 API's: > - one for reading a single object and bark on extra-characters - IMO, > this would be the correct Behaviour of #readFromString: > - one for reading an object in a longer sequence of objects (just keep > the stream positionned after last character read) - this would be > readFrom: aStream Yes. I was thinking about something in the same vein so that we could walk on the stream Now I think that we should get a concrete case to learn from. First raising an error instead of zero is a good behavior and it may break some code. Stef >> >> >>> In squeak, (Integer readFromString: 'foo') ->Error >>> >>> Use: >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >>> - (Integer readFrom: 'foo' ifFail: []), to get nil >>> >>> Though it is possible, I dislike anwsering nil, because it would mean >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >>> 1) That's nonsense, readFrom:ifFail: already does the work. >>> 2) you cripple the code with Error conditions and end up with >>> unreadable C-looking like code >>> (3 lines of Error condition crap for 1 line of underlying algorithm >>> at every function call) >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >>> >>> But that conversation already took place many times... >>> >>> I'd like the readFrom:ifFail: form to be generalized to other objects, >>> with default behaviour raising an Error. What do you think ? >>> >>> Nicolas >>> >>> 2010/8/24 Johan Brichau <[hidden email]>: >>>> >>>> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >>>> >>>>> I thought that readFromString: was raising an error and that guessNumber* was returning zero >>>> >>>> I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... >>>> But: >>>> >>>> 'foo' asInteger = nil >>>> Integer readFromString: 'foo' = 0 >>>> 'foo' asNumber -> Error >>>> >>>> aargh :-( >>>> >>>> disclaimer: currently testing this in pharo1.1 >>>> >>>> Johan >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |