- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] DateAndTime and TimeStamp precision

by 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. > > Saves you quite a few system calls as well :) > > > > I think this was removed as part of speeding up date and time because it was slowing down everything. > > (long time ago) > > > > And people where thinking that this is actually not true: if you ask two times for a corse-grained > > time, you *can* get the same time twice if you ask faster than the base resolution. > > > > It would be interesting to know how other languages handle this. > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > I think the answer is as simple as you might suspect - they don't. > It doesn't really make sense to ensure now < now, so they leave it to > the developer to make sure that is the case if he really needs it. > > F.ex.: > VW uses a millisecond clock for its (default) Timestamps. It provides a > microsecondValue method as well, but no default Timestamp creation > method using it. > > Java provides currentTimeMillis() (walltime since Jan 1970, resolution > OS-dependent) > and nanoTime (since startup). > You can't really combine the two and get a Timestamp with nanosecond > precision that makes sense, so I'd say it does millisecond precision as > well. > > 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 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. ] Saves you quite a few system calls as well :) > I think this was removed as part of speeding up date and time because it was slowing down everything. > (long time ago) > > And people where thinking that this is actually not true: if you ask two times for a corse-grained > time, you *can* get the same time twice if you ask faster than the base resolution. > > It would be interesting to know how other languages handle this. > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > I think the answer is as simple as you might suspect - they don't. It doesn't really make sense to ensure now < now, so they leave it to the developer to make sure that is the case if he really needs it. F.ex.: VW uses a millisecond clock for its (default) Timestamps. It provides a microsecondValue method as well, but no default Timestamp creation method using it. Java provides currentTimeMillis() (walltime since Jan 1970, resolution OS-dependent) and nanoTime (since startup). You can't really combine the two and get a Timestamp with nanosecond precision that makes sense, so I'd say it does millisecond precision as well. Cheers, Henry

Feb. 16, 2010

Re: [Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore

by Yanni Chiu

Mariano Martinez Peck wrote: > Thank for the report. I have just commited a new version that fix > this and another couple of things. Can you tell me if it works ok > for you ? > > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfFFI'; > load. > > ((Smalltalk at: #ConfigurationOfFFI) project version: '1.0') load. > > > Sorry, It is this: > > ((Smalltalk at: #ConfigurationOfFFI) project version: '1.2') load. It works fine. Thanks.

Feb. 16, 2010

Re: [Pharo-project] Monticello browser doesn't take into account a new package

by Lukas Renggli

Click on '+Package' in the Monticello browser to create a package. Creating a matching category only is not enough. Lukas 2010/2/16 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > This is a Â Pharo1.0-10508-rc2dev10.01.2 image > > 2010/2/16 Cyrille Delaunay <cy.delaunay(a)gmail.com> >> >> Hi, >> I have try that with the last dev image on the pharo website: >> When I create a new package (right-click => add category on the default >> browser), this new package will not appear in the monticello browser. >> Therefore, you will not be able to save it in any squeaksource repository >> (?). >> The package will appear only after specific manipulations (for example, >> move a class from this new package to another one). >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 16, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by 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. I think this was removed as part of speeding up date and time because it was slowing down everything. (long time ago) And people where thinking that this is actually not true: if you ask two times for a corse-grained time, you *can* get the same time twice if you ask faster than the base resolution. It would be interesting to know how other languages handle this. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 16, 2010

Re: [Pharo-project] Monticello browser doesn't take into account a new package

by Cyrille Delaunay

This is a Pharo1.0-10508-rc2dev10.01.2 image 2010/2/16 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hi, > > I have try that with the last dev image on the pharo website: > > When I create a new package (right-click => add category on the default > browser), this new package will not appear in the monticello browser. > Therefore, you will not be able to save it in any squeaksource repository > (?). > The package will appear only after specific manipulations (for example, > move a class from this new package to another one). > > > >

Feb. 16, 2010

[Pharo-project] Monticello browser doesn't take into account a new package

by Cyrille Delaunay

Hi, I have try that with the last dev image on the pharo website: When I create a new package (right-click => add category on the default browser), this new package will not appear in the monticello browser. Therefore, you will not be able to save it in any squeaksource repository (?). The package will appear only after specific manipulations (for example, move a class from this new package to another one).

Feb. 16, 2010

Re: [Pharo-project] DateAndTime and TimeStamp precision

by Miguel Enrique CobÃ¡ Martinez

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. Thanks > > Luc > > Le 13 fÃ©vr. 10 Ã 10:46, StÃ©phane Ducasse a Ã©crit : > > > 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 > > > > > > _______________________________________________ > > 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. 16, 2010