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

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Schwab,Wilhelm K

Ok, so you're complaining that your computer is too fast... :) On a more serious note, you might be happier adding a counter field, which can be as simple as the index in the collection, a field in an RDBMS, or something that you increment and save into each object you create. Oddly enough, I encountered this same problem (again) only days ago, and have gone the implied counter route. In my case, each datum gets a line in a text file, so they are naturally ordered, and I make that concrete as I re-export the data for abuse[*] in R. Bill [*] thought for the day: if you torture data hard enough, they will confess to anything. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Miguel Enrique CobÃ¡ Martinez Sent: Friday, February 12, 2010 2:21 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] DateAndTime and TimeStamp precision El vie, 12-02-2010 a las 20:08 +0100, Mariano Martinez Peck escribiÃ³: > I have no idea. I just remember this discussion: > > http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.htm > l#a1296771 Thanks I remember reading something about in the list but couldn't find it anymore. Now, by reading it, people are talking about nanoseconds granularity. I don't want that level of granularity, but only to differentiate between two consecutive calls to time1 := DateAndTime now. time2 := DateAndTime now. self assert: [ (time2 - time1) > 0 ] I really don't care the specific granularity, only to be able to distinguish the creation of two objects without using an artificial delay between both creations. Or is this something not reasonable? Or how can I timestamp a lot of objects created in a loop inside the image? cheers > > 2010/2/12 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > 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 -- 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 Miguel Enrique CobÃ¡ Martinez

El vie, 12-02-2010 a las 20:08 +0100, Mariano Martinez Peck escribiÃ³: > I have no idea. I just remember this discussion: > > http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.html#a12… Thanks I remember reading something about in the list but couldn't find it anymore. Now, by reading it, people are talking about nanoseconds granularity. I don't want that level of granularity, but only to differentiate between two consecutive calls to time1 := DateAndTime now. time2 := DateAndTime now. self assert: [ (time2 - time1) > 0 ] I really don't care the specific granularity, only to be able to distinguish the creation of two objects without using an artificial delay between both creations. Or is this something not reasonable? Or how can I timestamp a lot of objects created in a loop inside the image? cheers > > 2010/2/12 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 12, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Miguel Enrique CobÃ¡ Martinez

The DateAndTime class comment says: I represent a point in UTC time as defined by ISO 8601. I have zero duration. My implementation uses three SmallIntegers and a Duration: jdn - julian day number. seconds - number of seconds since midnight. nanos - the number of nanoseconds since the second. offset - duration from UTC. The nanosecond attribute is almost always zero but it defined for full ISO compliance and is suitable for timestamping. This last sentence I don't understand. Is almost zero? For me is always zero. Why it say that is suitable for timestamping if only works for timestamping with seconds granularity? Some idea? Or is just a bad class comment? -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 12, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Mariano Martinez Peck

I have no idea. I just remember this discussion: http://n4.nabble.com/Nanosecond-level-profiling-in-Pharo-td1296771.html#a12… 2010/2/12 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > 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

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

by Torsten Bergmann

>How do you reorder the pages ? with pagexxx ? No, currently there is no order. As I wrote - we have to find a way. Either by providing a #pages method with the order pages #(pageMethod1 pageMethod2 ...) or by enumerating using the pragma in any method pageMethod <help: 'hello' nr: 2> First one is easier to maintain/restructure. Currently it's the order in which pragmas are given (see the code) which I think is undefined. Maybe someone has another idea. Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 12, 2010

[Pharo-project] DateAndTime and TimeStamp precision

by Miguel Enrique CobÃ¡ Martinez

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

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by Schwab,Wilhelm K

I first heard of the Pascal convention in connection with Windows programming, shortly after the KT extinction. Right or wrong (MS' track record leaves me biased), they did it in the name of efficiency. It is true that we can certainly use more code for everyday tasks, but that list is somewhat long. It is unrealistic to assume that we could ever provide all needed functionality, nor is Smalltalk code always appropriate on performance grounds, so some type of callout/back facility will be essential. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Friday, February 12, 2010 12:00 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo changing the game Mariano, Unfortunately the convention is from the library provider not exactly the OS. This is a consequence of all infrastructure in present days be done in C, but in a non distant future you would also see Pascal calling convention. . . I think this aspect would be less important to user (general application programmers [instead of core or 'system' programmers]) if we had already a more complete set of libraries for typical functionality needed in the daily chores. -- Cesar Rabak Em 12/02/2010 14:26, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves(a)elte.hu> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> It is interesting to note that of course, after this was added to 3.9, >> there was >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>> >>> Who that person was is left as an exercise to the reader of course ;-) >> >> Hint: FFI has its own proprietary hardcoded pragma format. It >> unnecessary complicates the compiler even when not loaded. Not to >> mention that it breaks all tools that have their own parser, such as >> RB for example. >> > > And I hate having to write > I would love to be the same and that someone else takes care, not me (the > user). > Do you know if there is a reason for this? Â I imagine that yes. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall) while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl) So it depends on the function's calling convention which you should use (and not the OS). Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it)Â and if you don't want it (the default) just put what you want ? Cheers Mariano Levente > > >> >> 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 >> > _______________________________________________ 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

Feb. 12, 2010

Re: [Pharo-project] Pharo changing the game

by csrabak＠bol.com.br

Mariano, Unfortunately the convention is from the library provider not exactly the OS. This is a consequence of all infrastructure in present days be done in C, but in a non distant future you would also see Pascal calling convention. . . I think this aspect would be less important to user (general application programmers [instead of core or 'system' programmers]) if we had already a more complete set of libraries for typical functionality needed in the daily chores. -- Cesar Rabak Em 12/02/2010 14:26, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: On Fri, Feb 12, 2010 at 4:21 PM, Levente Uzonyi <leves(a)elte.hu> wrote: On Fri, 12 Feb 2010, Mariano Martinez Peck wrote: > On Fri, Feb 12, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> It is interesting to note that of course, after this was added to 3.9, >> there was >>> someone *very hard* arguing that adding Pragmas was a very dumb idea... >>> >>> Who that person was is left as an exercise to the reader of course ;-) >> >> Hint: FFI has its own proprietary hardcoded pragma format. It >> unnecessary complicates the compiler even when not loaded. Not to >> mention that it breaks all tools that have their own parser, such as >> RB for example. >> > > And I hate having to write > I would love to be the same and that someone else takes care, not me (the > user). > Do you know if there is a reason for this? Â I imagine that yes. AFAIK apicall: uses the stdcall calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#stdcall) while cdecl: uses the cdecl calling convention (http://en.wikipedia.org/wiki/X86_calling_conventions#cdecl) So it depends on the function's calling convention which you should use (and not the OS). Thanks Levente. I noticed what you said. But it seems that a OS usually takes one of those conventions as default or at least most commonly used. Would be cool to have the default implemented depending in the OS (no need to explicitly say it)Â and if you don't want it (the default) just put what you want ? Cheers Mariano Levente > > >> >> 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 >> > _______________________________________________ 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] [squeak-dev] Re: The Trunk: Multilingual-ar.87.mcz

by csrabak＠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). 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. > 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 :-|

Feb. 12, 2010

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

by laurent laffont

It's the first time I see pragmas in action, cool ! How do you reorder the pages ? with pagexxx ? Reordering the lessons in ProfStef was the first tedious thing. That's why I have SmalltalkSyntaxTutorial#tutorial to answer an Array of selectors. I think it should be not difficult to add something like AbstractTutorial#toHelpSystem in ProfStef ? Laurent Laffont On Fri, Feb 12, 2010 at 4:17 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Laurent Laffont wrote: > >And I was just thinking that there may be more value *now* in writing > >tutorials than in writing a full featured help browser ? > > Stef wrote: > >+1 > > > >but let us be incremental and improve step by step. > > > > OK, here is my first step: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfHelpSystem'; > load. > > (Smalltalk at: #ConfigurationOfHelpSystem) load > > > Project lives on http://squeaksource.com/HelpSystem.html (Read/Write) > If it evolves we can include it into a dev image. > > Needs improvements, but is a start. Dont know if pragmas or a #pages method > would be the way to go to define page order, ... > > Feel free to comment ... > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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