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

Re: [Pharo-project] Pharo changing the game

by StÃ©phane Ducasse

Send code and it will be fixed in one hour. Stef > I think the really tragic thing is that nothing in Smalltalk remains stable. > > It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. > > By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. > > The 16rff issue is a fine example of an absolutely stupid incompatibility. > > Just my $.04 > > -Todd Blanchard > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 13, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by StÃ©phane Ducasse

Hi miguel what is the solution? I remember that I saw passing some code to support nanos but I'm not sure that it was integrated. Now let us fix it if possible. Stef On Feb 13, 2010, at 1:32 AM, Miguel Enrique CobÃ¡ Martinez wrote: > El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribiÃ³: >> With the Mac VM 5.4b1 I have a microsecond clock. >> http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html >> >> zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh? > > > Thanks that indeed shown a difference in my machine. > > But, then other question, why the default implementation of DateAndTime > now and TimeStamp now isn't smaller than a second. > By sending now I get a DateAndTime object but by sending > millesecondClockValue a get a SmallInteger representing the number of > milliseconds. > > But there isn't in the class side of both classes and neither in Time > class a method to build a DateAndTime, a TimeStamp or a Time from > milliseconds. So to convert this value to a date again I will have to > trunk the time to a second resolution. Is this analysis correct? > > Of course I could index my objects in the list with the millis number > but I would be happier if I could index them with a real date object. > > Anyway, not that that is a show stopper, is just that when creating > objects I'm assigning a creation date and I would like to find what > objects are older that others created at about the same lapse, without > resorting to use their position in an external data structure (i.e. the > OrderedCollection, an array or the line number in a file). > > Thanks to everyone for the answers. > >> >> >> On 2010-02-12, at 12:46 PM, csrabak(a)bol.com.br wrote: >> >>> Miguel, >>> >>> Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse: >>> >>> {DateAndTime. TimeStamp } collect: [ :class | >>> | list | >>> list := OrderedCollection new. >>> 1 to: 1000 do: [ :each | >>> value := class millisecondClockValue. >>> list add: value ]. >>> list last - list first ]. >>> >>> I get an Array (1 1). >>> >>> Changing from 1000 to 100000 (hundred fold) I got #(77 141). >>> >>> HTH >>> >>> -- >>> Cesar Rabak >>> >>> Em 12/02/2010 17:02, Miguel Enrique CobÃ¡ Martinez < miguel.coba(a)gmail.com > escreveu: >>> I am noticing that both >>> >>> DateAndTime now >>> TimeStamp now >>> >>> have a precision of seconds, that is, the nanos is always 0. >>> >>> I am doing a bulk data creation and inserting them in a list with a >>> timestamp for each insertion but this isn't working because several >>> entries have the very same DateAndTime or Timestamp. >>> >>> For example: >>> >>> {DateAndTime. TimeStamp } collect: [ :class | >>> | list | >>> list := OrderedCollection new. >>> 1 to: 1000 do: [ :each | >>> value := class now. >>> list add: value ]. >>> list last - list first ] >>> >>> gives an Array(0:00:00:00 0:00:00:00) >>> >>> How can achieve smaller than a second timestamping in Pharo? >>> -- >>> Miguel CobÃ¡ >>> http://miguel.leugim.com.mx >>> >>> >>> _______________________________________________ >>> 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 >> >> -- >> =========================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> =========================================================================== >> >> >> >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 13, 2010

Re: [Pharo-project] Pharo changing the game

by Eagle Offshore

I think the really tragic thing is that nothing in Smalltalk remains stable. It would seem to me that in a language that has been around thirty years or so that core data types like numbers, dates, times, and (hopefully, although adoption of unicode was disruptive) strings would be the same across all the dialects. By now, there should be some chunks of the system that we can deem fully mature and then learn to LEAVE ALONE. The 16rff issue is a fine example of an absolutely stupid incompatibility. Just my $.04 -Todd Blanchard

Feb. 13, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Miguel Enrique CobÃ¡ Martinez

El vie, 12-02-2010 a las 14:58 -0800, John M McIntosh escribiÃ³: > With the Mac VM 5.4b1 I have a microsecond clock. > http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html > > zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh? Thanks that indeed shown a difference in my machine. But, then other question, why the default implementation of DateAndTime now and TimeStamp now isn't smaller than a second. By sending now I get a DateAndTime object but by sending millesecondClockValue a get a SmallInteger representing the number of milliseconds. But there isn't in the class side of both classes and neither in Time class a method to build a DateAndTime, a TimeStamp or a Time from milliseconds. So to convert this value to a date again I will have to trunk the time to a second resolution. Is this analysis correct? Of course I could index my objects in the list with the millis number but I would be happier if I could index them with a real date object. Anyway, not that that is a show stopper, is just that when creating objects I'm assigning a creation date and I would like to find what objects are older that others created at about the same lapse, without resorting to use their position in an external data structure (i.e. the OrderedCollection, an array or the line number in a file). Thanks to everyone for the answers. > > > On 2010-02-12, at 12:46 PM, csrabak(a)bol.com.br wrote: > > > Miguel, > > > > Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse: > > > > {DateAndTime. TimeStamp } collect: [ :class | > > | list | > > list := OrderedCollection new. > > 1 to: 1000 do: [ :each | > > value := class millisecondClockValue. > > list add: value ]. > > list last - list first ]. > > > > I get an Array (1 1). > > > > Changing from 1000 to 100000 (hundred fold) I got #(77 141). > > > > HTH > > > > -- > > Cesar Rabak > > > > Em 12/02/2010 17:02, Miguel Enrique CobÃ¡ Martinez < miguel.coba(a)gmail.com > escreveu: > > I am noticing that both > > > > DateAndTime now > > TimeStamp now > > > > have a precision of seconds, that is, the nanos is always 0. > > > > I am doing a bulk data creation and inserting them in a list with a > > timestamp for each insertion but this isn't working because several > > entries have the very same DateAndTime or Timestamp. > > > > For example: > > > > {DateAndTime. TimeStamp } collect: [ :class | > > | list | > > list := OrderedCollection new. > > 1 to: 1000 do: [ :each | > > value := class now. > > list add: value ]. > > list last - list first ] > > > > gives an Array(0:00:00:00 0:00:00:00) > > > > How can achieve smaller than a second timestamping in Pharo? > > -- > > Miguel CobÃ¡ > > http://miguel.leugim.com.mx > > > > > > _______________________________________________ > > 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 > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > 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

Feb. 13, 2010

[Pharo-project] [ANN] HelpSystem (was ProfStef)

by Torsten Bergmann

Page order is now defined using a method #pages. Also more help texts are added. Just try: --------------------------------------------------------- Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfHelpSystem'; load. (Smalltalk at: #ConfigurationOfHelpSystem) load. HelpSystem reset. HelpBrowser open --------------------------------------------------------- Have fun, T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

Feb. 12, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by John M McIntosh

With the Mac VM 5.4b1 I have a microsecond clock. http://n4.nabble.com/microsecond-timing-for-GC-work-td1016253.html zero feedback, maybe it's too fast and you never get above 1 millisecond in testing eh? On 2010-02-12, at 12:46 PM, csrabak(a)bol.com.br wrote: > Miguel, > > Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse: > > {DateAndTime. TimeStamp } collect: [ :class | > | list | > list := OrderedCollection new. > 1 to: 1000 do: [ :each | > value := class millisecondClockValue. > list add: value ]. > list last - list first ]. > > I get an Array (1 1). > > Changing from 1000 to 100000 (hundred fold) I got #(77 141). > > HTH > > -- > Cesar Rabak > > Em 12/02/2010 17:02, Miguel Enrique CobÃ¡ Martinez < miguel.coba(a)gmail.com > escreveu: > I am noticing that both > > DateAndTime now > TimeStamp now > > have a precision of seconds, that is, the nanos is always 0. > > I am doing a bulk data creation and inserting them in a list with a > timestamp for each insertion but this isn't working because several > entries have the very same DateAndTime or Timestamp. > > For example: > > {DateAndTime. TimeStamp } collect: [ :class | > | list | > list := OrderedCollection new. > 1 to: 1000 do: [ :each | > value := class now. > list add: value ]. > list last - list first ] > > gives an Array(0:00:00:00 0:00:00:00) > > How can achieve smaller than a second timestamping in Pharo? > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Martin McClure

StÃ©phane Ducasse wrote: > >> However, since VW already implements immutability, it would probably >> be beneficial to chose an API that is close to the VW implementation. > > Yes this is the idea. I hope the interface is good. The interface in base VW is, I'm afraid, not good, and should not be emulated. However, the WriteBarriers parcel, in preview in VW 7.7, is a start at a better API for this. The basic problem is that the underlying VM "immutability" feature is useful for many things besides immutability. But the API is designed only for immutability, and using it for anything else is very ugly. It was probably a mistake to name the VM feature "immutability" in the first place. It's really "trap on write" and when you get a trap you can do many things -- reject the modification, conditionally allow it, notify then allow... Regards, -Martin

Feb. 12, 2010

Re: [Pharo-project] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

by Nicolas Cellier

2010/2/12 <csrabak(a)bol.com.br>: > Em 12/02/2010 13:16, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com > escreveu: > >> 2010/2/12 <csrabak(a)bol.com.br>: >> > Except if Â my analytical Â skills are impaired Â by being Â tired and >> >groggy due a very short sleep Â I think the solution to this is only >> >a matter of putting: >> > sourceStream peekFor: $+. >> > just Â Â before Â eneg Â Â := Â sourceStream Â Â peekFor: Â Â $-. Â in >> > SqNumberParser>>readExponent >> > Did I miss something fundamental? >> > my 0.01999. . . . >> > >> > -- Cesar Rabak >> > >> > >> Â Yes, Â it's Â Â trivial. Â Â It's Â already Â Â implemented Â in Â the >> DolphinNumberParser, Â because Dolphin syntax Â allow 1.0e+2 Â In st-80 >> and current squeak, this rather means 1.0 e + 2 (send #e to 1.0 then >> send #+ with argument 2 to the result) > > I'm may be biased here but I don't follow ST-80 behaviour as reasonable > (although sensible from the POV of Smalltalk syntax). > I guess one of st-80 goals was to have minimal syntax. With this respect, the plus sign is absolutely void (in the sense it adds no information). With this rationale, it was just useless to create rules for +2 and 1.0e+2. So it makes sense. Now, we can change this if there is consensus. I suggest in this case to also make a separator mandatory after end of sentence period. > Also, I don't know the origin of the fork, but while in Squeak performing > in Workspace: > > 1.0012e+3 + 1 rises an error about Float(Object) DNU #e, > > in Pharo (PharoCore1.0rc2 Latest update: #10509) the code above generates > the answer " 1002.23" which is what I would expect. > I don't know about Pharo1.0, but Pharo1.1 fails (DNU #e) as most Smalltalk do (but Dolphin AFAIK). >> Â Other features are not so hard Â either. Â We have to measure all the >> consequences then just decide what is worth. > > My only 'other feature' request would be to have the case sensitiveness > for the 'e' of exponent notation removed, as it would ease the import of > data from CSV files. . . > > IIRC I already mentioned that in Pharo's mailing list. > > From my exposition above, I _think_ we should fix SqNumberParser>>readExponent > in order to have a system which is consistent internally. > > This begs another question: from where Pharo converts the string in Shout > Workspace to number which has a different behaviour than SqNumberParser?? > > Mysteries of OO in Smalltalk? > > HTH > > -- > Cesar Rabak > > PS.: On a side note I would like to comment that the method 'nextNumber' > which is the one ultimately used to fetch the number from SqNumberParser > seems to me to have a non intuitive name. . . Â Sorry I cannot concoct any > better name right now to offer as a suggestion :-| > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 12, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by csrabak＠bol.com.br

Miguel, Pharo allows you to drill down to millisecond resolution, but for your 'benchmark' that's still too coarse: {DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class millisecondClockValue. list add: value ]. list last - list first ]. I get an Array (1 1). Changing from 1000 to 100000 (hundred fold) I got #(77 141). HTH -- Cesar Rabak Em 12/02/2010 17:02, Miguel Enrique CobÃ¡ Martinez < miguel.coba(a)gmail.com > escreveu: I am noticing that both DateAndTime now TimeStamp now have a precision of seconds, that is, the nanos is always 0. I am doing a bulk data creation and inserting them in a list with a timestamp for each insertion but this isn't working because several entries have the very same DateAndTime or Timestamp. For example: {DateAndTime. TimeStamp } collect: [ :class | | list | list := OrderedCollection new. 1 to: 1000 do: [ :each | value := class now. list add: value ]. list last - list first ] gives an Array(0:00:00:00 0:00:00:00) How can achieve smaller than a second timestamping in Pharo? -- Miguel CobÃ¡ http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 12, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Brent Pinkney

> time1 := DateAndTime now. > time2 := DateAndTime now. > self assert: [ (time2 - time1) > 0 ] When I implemented DateAndTime, the above was true. Has this changed ? Brent

Feb. 12, 2010