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

Re: [Pharo-project] DateAndTime and TimeStamp precision

by John M McIntosh

There is a microsecond clock in the macintosh vm, obviously this could be extended to give date/time back in microseconds. On 2010-02-16, at 5:39 AM, Luc Fabresse wrote: > 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. > > Luc -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 16, 2010

Re: [Pharo-project] Using software engineering practices and tools

by Michael Roberts

> They use the setup described here: > > http://github.com/renggli/builder yes, it was a question about community hardware though. > http://code.google.com/p/support/wiki/IssueTrackerAPI thanks, i had not seen that... Mike

Feb. 16, 2010

Re: [Pharo-project] Using software engineering practices and tools

by Lukas Renggli

>> - Integration server >> any more thoughts on hardware ? > > I do not know. > I will check with Moose people to know their hudson setup. They use the setup described here: http://github.com/renggli/builder >> -Bug tracking >> i'm pretty sure we can edit the issues via SVN. I think we would need >> https support for the svn client that was written for squeak, or do it >> via cmd line / OSProcess. > > I do not know if the google api require svn to script it. http://code.google.com/p/support/wiki/IssueTrackerAPI Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 16, 2010

Re: [Pharo-project] Using software engineering practices and tools

by Michael Roberts

> > I do not know if the google api require svn to script it. i don't really understand what you want to do. can you outline an example? > Why on code.google.com? only because you mentioned it.... > For me metacello on squeaksource or something like that is ok. sure, i would say it was better to be honest. code.google souce-code mgmt appears very file based. > > the problem is with crosscutting changes and their synchronisation. > It can only work if the maintainer are pulling merging actively. yes, agreed. cheers, Mike

Feb. 16, 2010

Re: [Pharo-project] Using software engineering practices and tools

by StÃ©phane Ducasse

> - Integration server > any more thoughts on hardware ? I do not know. I will check with Moose people to know their hudson setup. > -Bug tracking > i'm pretty sure we can edit the issues via SVN. I think we would need > https support for the svn client that was written for squeak, or do it > via cmd line / OSProcess. I do not know if the google api require svn to script it. > -to publish code on code.google.com > what is your vision? > we could push out 'Metacello definitions' (whatever that would look > like) via SVN but we would have a dependency on the SVN client. we > could also push the update stream out in SVN as well. Why on code.google.com? For me metacello on squeaksource or something like that is ok. > whilst we are on the subject of visions a comment Lukas made about git > style forking of repositories / pushing changes upstream was really > interesting. what would happen if we had a tree of maintainers who > each are responsible for parts of the system with their own MC repos, > and change works its way up the tree in a controlled manner. I > wondered if that would scale over the longer term rather than the > single inbox model we have at the moment? especially as we want to > break the image into more & more packages... what do you think? it is > just an idle thought at the moment. the problem is with crosscutting changes and their synchronisation. It can only work if the maintainer are pulling merging actively.

Feb. 16, 2010

Re: [Pharo-project] About new inspector

by StÃ©phane Ducasse

Thanks martin > At GemStone we work a lot with our own proxies which represent objects > in another VM. We also have our own inspectors and debuggers to inspect > these effectively. Over the years I've made a lot of design mistakes in > this area and have had to fix them. Along the way I have come to some > definite opinions about how inspectors and proxies should interact: > > * When inspecting a proxy, the proxy should look to the user like a > proxy, not like the object being proxied. To do otherwise causes great > confusion for the person using the inspector. Ideally, an inspector > offer the option to have multiple views of the same object, a basic view > which shows the low-level structure and possibly higher-level views > which show the logical structure of objects which the inspector knows > how to do special things for. So for instance sets show their real > instvars (tally, array) for the basic view but their elements and size > for a logical view. For proxies the higher-level view might be to > inspect the object being proxied. > > * Inspectors should never assume that the object being inspected can > respond to *any* message. In the case of Pharo it's probably OK to > assume that all objects inherit from ProtoObject, but IMO if debugging > tools are designed correctly ProtoObject should not be needed and proxy > classes can inherit directly from nil and implement no methods other > than #doesNotUnderstand:. To achieve this an inspector should send no > messages to an object until it knows something about how that object > will respond to the message. It is *not* safe to send a not-understood > message and catch the exception, because a proxy's response to a > not-understood message may change the state of the proxy or other > objects in the local or remote system, and debugging tools should only > change the state of the system when explicitly told to. To achieve this > you need a primitive to determine the "real" class of an object without > sending that object a message. I don't know if Pharo currently has this, > but it's very useful, and extremely simple to implement. VW has a > minimal reflection API that includes this, and GemStone recently added a > fairly complete reflection API that allows determining class and size of > an object as well as getting setting values of its instvars all without > sending the object any messages. do you mean mirror like code that eliot was mentioning recently? > This reflection facility is not really > object-oriented, since it examines and changes state of objects without > sending the object messages, breaking encapsulation. However, this is > useful, and I don't think it's any worse than the existing messages like > #instVarAt:(put:) which fulfill the same function. These existing > messages also break encapsulation and are at such a different level of > abstraction from the rest of the object's protocol that they aren't > really good object design either. > > * Once the inspector knows what the class of the inspected object is, it > can send messages to the class (which even for proxy classes inherits > from Behavior) to determine what inspecting facilities to offer. Object > class would answer only the basic inspector, Set class would override > this to add Set-specific inspector(s), Dictionary class would override > again to replace the Set-specific inspectors with Dictionary ones, and > so on. > > Some of this modularity is already in the new inspector, but the > important notion that is missing is "Send *no* messages to an object > until you know what kind of object you're dealing with". > > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Miguel Enrique CobÃ¡ Martinez

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 > 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. 16, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Henrik Johansen

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. Cheers, Henry

Feb. 16, 2010

Re: [Pharo-project] About new inspector

by Martin McClure

StÃ©phane Ducasse wrote: > there is a really nice discussion on supporting (not having an inspector breaking) when browsing > proxy. Can you have a look? > > http://code.google.com/p/pharo/issues/detail?id=1970 > Thanks for the summary. At GemStone we work a lot with our own proxies which represent objects in another VM. We also have our own inspectors and debuggers to inspect these effectively. Over the years I've made a lot of design mistakes in this area and have had to fix them. Along the way I have come to some definite opinions about how inspectors and proxies should interact: * When inspecting a proxy, the proxy should look to the user like a proxy, not like the object being proxied. To do otherwise causes great confusion for the person using the inspector. Ideally, an inspector offer the option to have multiple views of the same object, a basic view which shows the low-level structure and possibly higher-level views which show the logical structure of objects which the inspector knows how to do special things for. So for instance sets show their real instvars (tally, array) for the basic view but their elements and size for a logical view. For proxies the higher-level view might be to inspect the object being proxied. * Inspectors should never assume that the object being inspected can respond to *any* message. In the case of Pharo it's probably OK to assume that all objects inherit from ProtoObject, but IMO if debugging tools are designed correctly ProtoObject should not be needed and proxy classes can inherit directly from nil and implement no methods other than #doesNotUnderstand:. To achieve this an inspector should send no messages to an object until it knows something about how that object will respond to the message. It is *not* safe to send a not-understood message and catch the exception, because a proxy's response to a not-understood message may change the state of the proxy or other objects in the local or remote system, and debugging tools should only change the state of the system when explicitly told to. To achieve this you need a primitive to determine the "real" class of an object without sending that object a message. I don't know if Pharo currently has this, but it's very useful, and extremely simple to implement. VW has a minimal reflection API that includes this, and GemStone recently added a fairly complete reflection API that allows determining class and size of an object as well as getting setting values of its instvars all without sending the object any messages. This reflection facility is not really object-oriented, since it examines and changes state of objects without sending the object messages, breaking encapsulation. However, this is useful, and I don't think it's any worse than the existing messages like #instVarAt:(put:) which fulfill the same function. These existing messages also break encapsulation and are at such a different level of abstraction from the rest of the object's protocol that they aren't really good object design either. * Once the inspector knows what the class of the inspected object is, it can send messages to the class (which even for proxy classes inherits from Behavior) to determine what inspecting facilities to offer. Object class would answer only the basic inspector, Set class would override this to add Set-specific inspector(s), Dictionary class would override again to replace the Set-specific inspectors with Dictionary ones, and so on. Some of this modularity is already in the new inspector, but the important notion that is missing is "Send *no* messages to an object until you know what kind of object you're dealing with". Regards, -Martin

Feb. 16, 2010

Re: [Pharo-project] Using software engineering practices and tools

by Michael Roberts

- Integration server any more thoughts on hardware ? -Bug tracking i'm pretty sure we can edit the issues via SVN. I think we would need https support for the svn client that was written for squeak, or do it via cmd line / OSProcess. -to publish code on code.google.com what is your vision? we could push out 'Metacello definitions' (whatever that would look like) via SVN but we would have a dependency on the SVN client. we could also push the update stream out in SVN as well. whilst we are on the subject of visions a comment Lukas made about git style forking of repositories / pushing changes upstream was really interesting. what would happen if we had a tree of maintainers who each are responsible for parts of the system with their own MC repos, and change works its way up the tree in a controlled manner. I wondered if that would scale over the longer term rather than the single inbox model we have at the moment? especially as we want to break the image into more & more packages... what do you think? it is just an idle thought at the moment. cheers, Mike

Feb. 16, 2010