El mar, 16-02-2010 a las 18:56 +0100, Henrik Johansen escribió: > > Den 16.02.2010 18:32, skrev Miguel Enrique Cobá Martinez: > > El mar, 16-02-2010 a las 18:26 +0100, Henrik Johansen escribió: > > > >> Den 16.02.2010 16:44, skrev Marcus Denker: > >> > >>> On Feb 16, 2010, at 4:39 PM, Miguel Enrique Cobá Martinez wrote: > >>> > >>> > >>> > >>>> El mar, 16-02-2010 a las 14:39 +0100, Luc Fabresse escribió: > >>>> > >>>> > >>>>> Hi, > >>>>> > >>>>> I think it is related to: > >>>>> http://code.google.com/p/pharo/issues/detail?id=982 > >>>>> If I remember well, there is no primitive with nano second accuracy > >>>>> so it is impossible to have it in real. > >>>>> > >>>>> > >>>> Yes, and indeed nano second accuracy is overkill for my current problem. > >>>> I only want some given precision so that > >>>> > >>>> DateAndTime now < DateAndTime now > >>>> > >>>> is always true, so that can be used to order events (object creation in > >>>> this case) using the date. > >>>> > >>>> > >> But it's not. DateAndTime now <= DateAndTime now. > >> If you are batching them together so close that resolution is an issue > >> why not rewrite it to something like: > >> > >> currTime:= DateAndTime now. > >> obj Count:= 0. > >> someLoop whileTrue: [ > >> newObj := aClass new time: currTime+ objCount; yourself. > >> currTime := currTime +1. > >> ] > >> > > Thank you very much! I am doing something similar to this. > > If this resembles your approach, just remember to make sure that the > function is never called frequently. > If it is, you'll have to account for (if likely enough to be a potential > problem): > a) The function being called twice in the same DateAndTime resolution > interval (code to handle this which will be different based on whether > you want to protect against sequential or concurrent calls) > b) You don't allocate so many objects you get an overflow into the next > now, then call again.
Not a problem, I am doing a seldom called (just in development that is) method to generate several thousand objects (each one with several hundred objects inside) for populating my application and test search performance in Magma. Due that in my application each object has a creation date, I wanted to emulate the creation date generated on real usage of the app. But my bulk load machine it appears to be too fast, so several hundred of objects appear to be created at the very same time. Also running my tests and comparing creation date of the object being tested respect to end time of a given operation (that supposedly takes some time in real life), are showing operations taking zero time. So the tests fail. I worked around this by artificially putting a (Delay forSeconds: 1) wait right before testing so that the tests can register operations separated by at least a second and run successfully. Anyway, thanks to everyone for the "knowledge transfer" Cheers > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
