- Pharo-dev - lists.pharo.org

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

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