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

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

by Adrian Lienhard

nice list! Adrian On Feb 16, 2010, at 14:16 , StÃ©phane Ducasse wrote: > Hi guys > > I had this draft in my drafts for some weeks now and I would like to share that with you. > > I'm really convinced that we could do a better job to build better tools and process to bring our software to the next level. I would like to have share with you some thoughts and analysis and also request for ideas and code of course :) > > - Bug tracking we are doing that but can we dream > - would be nice to have the stack/image and that we could get back in the bug > - scripting code.google.com would be nice too > - to publish code > - to manipulate script bug entries (any taker of that) > > - Integration server: we are getting there and I thank all the hudson experimentations. > - we should get more of that. > > - Package Management: Metacello > - I would like to have Pharo1.0 certified metacello configs. > the ideas is that people can publish in a repositories the configs that they know are working > for 1.0, then in another for 1.1.... > -> once we have configurations + integration server we should burn servers running and testing > -> what/how do we manage results > > - I would like to manage pharo (core + maintained packages with metacello) as well as pharo-dev > > > - Profiling > We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned > Now it would be good to have better way to profile applications > something like .... :) http://www.bootchart.org/images/bootchart.png > > - Documentation > I hope to get some students to produce a way to script UMLish class diagrams that could be displayed > at the level of a package. > > Package level doc > Package class comments overview browser. > I think that this is really important to get nice comments, nice instance variables, > nice temporary variables. Now we should find a way to make sure that > comments are well in sight. Any idea / code? > > > - SmallLint > Better UI and process using SmallLint > Would be nice to have a sanity package checking process. Will probably come one of these days > > - Better Unit Test support > We should look at Adrian fixes and enhancements > Better reporting of tests > > - Better merging tools > Seeing the impact of a delta between two versions on the image for example > on that topic From VW mailing-list > "1. Please make the engine highly configurable and disjoint from the UI. > 2. Please make the UI itself pluggable, extensible, augmentable, etc. > 3. To support automated merges, please allow rules for handling unresolved conflicts." > > > I'm sure that there is more. We should get to the next level ;) > > > > _______________________________________________ > 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 Luc Fabresse

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 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

Feb. 16, 2010

[Pharo-project] Using software engineering practices and tools

by StÃ©phane Ducasse

Hi guys I had this draft in my drafts for some weeks now and I would like to share that with you. I'm really convinced that we could do a better job to build better tools and process to bring our software to the next level. I would like to have share with you some thoughts and analysis and also request for ideas and code of course :) - Bug tracking we are doing that but can we dream - would be nice to have the stack/image and that we could get back in the bug - scripting code.google.com would be nice too - to publish code - to manipulate script bug entries (any taker of that) - Integration server: we are getting there and I thank all the hudson experimentations. - we should get more of that. - Package Management: Metacello - I would like to have Pharo1.0 certified metacello configs. the ideas is that people can publish in a repositories the configs that they know are working for 1.0, then in another for 1.1.... -> once we have configurations + integration server we should burn servers running and testing -> what/how do we manage results - I would like to manage pharo (core + maintained packages with metacello) as well as pharo-dev - Profiling We got MessageTally (BTW in Squeak 3.xx all the code was in... SystemDictionary) cleaned Now it would be good to have better way to profile applications something like .... :) http://www.bootchart.org/images/bootchart.png - Documentation I hope to get some students to produce a way to script UMLish class diagrams that could be displayed at the level of a package. Package level doc Package class comments overview browser. I think that this is really important to get nice comments, nice instance variables, nice temporary variables. Now we should find a way to make sure that comments are well in sight. Any idea / code? - SmallLint Better UI and process using SmallLint Would be nice to have a sanity package checking process. Will probably come one of these days - Better Unit Test support We should look at Adrian fixes and enhancements Better reporting of tests - Better merging tools Seeing the impact of a delta between two versions on the image for example on that topic From VW mailing-list "1. Please make the engine highly configurable and disjoint from the UI. 2. Please make the UI itself pluggable, extensible, augmentable, etc. 3. To support automated merges, please allow rules for handling unresolved conflicts." I'm sure that there is more. We should get to the next level ;)

Feb. 16, 2010

[Pharo-project] [update 1.1] #11213

by stephane ducasse

11213 ----- - Issue 1948: SmalltalkImage current reportCPUandRAM - Issue 1979: spyOn: fix - Issue 1969: Sender Show the Trait and all of this uses. - Issue 1980: defaultResumeValue for Exception (from Squeak) Introduce Exception>>defaultReturnValue and Exception>>defaultResumeValue to provide default values for argument-less #resume or #return. The motivation is that catch-all handler may not be aware of specific return / resume values required by some exceptions. The protocol allows these exceptions to provide a reasonable default value for those situations.

Feb. 16, 2010

Re: [Pharo-project] About new inspector

by StÃ©phane Ducasse

On Feb 16, 2010, at 11:47 AM, Denis Kudriashov wrote: > http://www.squeaksource.com/Mocketry.html > Maybe in pharo it's not work. But should be loadable > > See class MocketryProxy - #doesNotUnderstand. > > For debugging speed should not be an issue. > > For debugging yes. But that approach is issue for use such proxies in domain tasks. Any message to proxy iterates full context chain when message sent by domain ok I see. Thanks denis. We should find a simple solution for the bug. Stef > _______________________________________________ > 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] About new inspector

by Denis Kudriashov

http://www.squeaksource.com/Mocketry.html Maybe in pharo it's not work. But should be loadable See class MocketryProxy - #doesNotUnderstand. For debugging speed should not be an issue. > For debugging yes. But that approach is issue for use such proxies in domain tasks. Any message to proxy iterates full context chain when message sent by domain

Feb. 16, 2010

Re: [Pharo-project] About new inspector

by StÃ©phane Ducasse

On Feb 16, 2010, at 10:36 AM, Denis Kudriashov wrote: > Hello > > I was implement proxy for Mocketry project. My proxy (MockObject) can emulate messages sush #printOn: and others that used by tools (debbugger, workspace and others). MockObject just search some tools context in #doesNotUndarstand method context. And if message was sent by tools (not domain code) proxy evaluate it in appropriate way. For example, when #printOn: was sent by debbuger, proxy prints special name instead of record/replay this message. Cool Could you publish your code that we learn? For debugging speed should not be an issue. I remember that igor mentioned something related to printOn: / displayString a while ago. Stef > But search full context chain for each message is really cost operation. But for mock-framework it's not problem I thing. > > Maybe tools must mark process in which it work. And proxy would easilly know that message sent by tools. > > > 2010/2/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 > > > "What happens is the inspector asks for "self class allInstVarNames" > and then tries to get each value with "self instVarNamed: aName". The > problem is, self class allInstVarNames answers the instVars of the > future class, but "self instVarNamed: aName" gets passed up to the > MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an > error because of course it doesn't have the correct instant vars. > > The old inspectors weren't as intrusive and worked, these new tools > clearly still have some bugs. Since ProtoObject, the superclass for > any such proxies doesn't do #instVarNamed:, such code in the inspector > will blow up anytime one attempts to inspect any kind of proxy. I > would report this as a bug to whoever is maintaining the new inspector > tools." > > So the only way I know to produce the 'bug' is to load the SFuture class he describes > in the blogpost I mention above then run the example I posted in step two. If this > is the wrong place to report this then let me know and I'll keep looking for the > correct place. > > > Delete commentComment 4 by pdebruic, Today (14 hours ago) > The default, I think. I haven't changed anything. > > SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor > > Delete commentComment 5 by marcus.denker, Today (11 hours ago) > I think the problem is this: > > -> ProtoObject implements a *minimal* object. This way, Proxies or Futures can use #doesNotUnderstand > to implement what they implement. That is, for the example of the Proxy, every message is forwarded to the > remote object. > -> Now we do not know what exactly you want to forward. Should an inspector inspect the local proxy? Ot the > remote object? You decide. Your subclass of ProtoObject copies as many objects from Object as you want. > (often all that are needed to inspect the *proxy* vs. the remote object). > > I think Ramon fine-tuned his implementation for the normal old inspector. Now when you use another one, > it uses other methods in addition to the one implemented in the Future --> confusion. Chaos. Bug. > > But: We can not fix this. this is purely the responsibility of the implementor of the subclass of ProtoObject. > > So. next action: > -> We fix (uhm, remove) the croquet Future code that is just plain confusing. > -> We think hard if it's really a problem in the new inspector vs. a missing method on the Future. > > (and, yes, all this sucks anyway.... we are hard at work to make reflection better and solve all this in a *much* > nicer way... but that's research...) > > > Delete commentComment 6 by ramon.leon, Today (10 hours ago) > > It's not just the Future proxy that'll have problems, it's proxies in general. The > way the current inspector is written won't work with any proxy I see in my image, > SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the Glorp record proxy, > because it assume it can use #instVarNamed: on an instance using values from > "anInstance class allInstVarNames" which in the case of *any* proxy won't work unless > the proxy implements a version of #instVarNamed:. > > This is confusing because now the proxy is no longer behaving as a proxy, now > reflectively it's answering values for itself rather than the instance being proxied. > > Another solution would be if the proxy overrode #class to return the class of the > proxied instance, but I've always assumed all hell would break loose if you overrode > #class, I didn't think it safe to do, and I've not seen any other proxy class do this. > > Regardless of the ultimate solution, the inspector shouldn't blow up, it should catch > the exception and have some default rendering behavior for when it can't inspect an > object for some reason. Do you not agree? > > Delete commentComment 7 by stephane.ducasse, Today (moments ago) > Yes I agree. > We should contact frederick. > I think that the inspector should know that it is browsing a proxy and pay attention. > _______________________________________________ > 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. 16, 2010

Re: [Pharo-project] About new inspector

by Denis Kudriashov

Hello I was implement proxy for Mocketry project. My proxy (MockObject) can emulate messages sush #printOn: and others that used by tools (debbugger, workspace and others). MockObject just search some tools context in #doesNotUndarstand method context. And if message was sent by tools (not domain code) proxy evaluate it in appropriate way. For example, when #printOn: was sent by debbuger, proxy prints special name instead of record/replay this message. But search full context chain for each message is really cost operation. But for mock-framework it's not problem I thing. Maybe tools must mark process in which it work. And proxy would easilly know that message sent by tools. 2010/2/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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 > > > "What happens is the inspector asks for "self class allInstVarNames" > and then tries to get each value with "self instVarNamed: aName". > The > problem is, self class allInstVarNames answers the instVars of the > future class, but "self instVarNamed: aName" gets passed up to the > MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an > error because of course it doesn't have the correct instant vars. > > The old inspectors weren't as intrusive and worked, these new tools > clearly still have some bugs. Since ProtoObject, the superclass for > any such proxies doesn't do #instVarNamed:, such code in the > inspector > will blow up anytime one attempts to inspect any kind of proxy. I > would report this as a bug to whoever is maintaining the new > inspector > tools." > > So the only way I know to produce the 'bug' is to load the SFuture > class he describes > in the blogpost I mention above then run the example I posted in > step two. If this > is the wrong place to report this then let me know and I'll keep > looking for the > correct place. > > > Delete commentComment 4 by pdebruic, Today (14 hours ago) > The default, I think. I haven't changed anything. > > SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor > > Delete commentComment 5 by marcus.denker, Today (11 hours ago) > I think the problem is this: > > -> ProtoObject implements a *minimal* object. This way, Proxies or > Futures can use #doesNotUnderstand > to implement what they implement. That is, for the example of the > Proxy, every message is forwarded to the > remote object. > -> Now we do not know what exactly you want to forward. Should an > inspector inspect the local proxy? Ot the > remote object? You decide. Your subclass of ProtoObject copies as > many objects from Object as you want. > (often all that are needed to inspect the *proxy* vs. the remote > object). > > I think Ramon fine-tuned his implementation for the normal old > inspector. Now when you use another one, > it uses other methods in addition to the one implemented in the > Future --> confusion. Chaos. Bug. > > But: We can not fix this. this is purely the responsibility of the > implementor of the subclass of ProtoObject. > > So. next action: > -> We fix (uhm, remove) the croquet Future code that is just plain > confusing. > -> We think hard if it's really a problem in the new inspector vs. a > missing method on the Future. > > (and, yes, all this sucks anyway.... we are hard at work to make > reflection better and solve all this in a *much* > nicer way... but that's research...) > > > Delete commentComment 6 by ramon.leon, Today (10 hours ago) > > It's not just the Future proxy that'll have problems, it's proxies > in general. The > way the current inspector is written won't work with any proxy I see > in my image, > SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the > Glorp record proxy, > because it assume it can use #instVarNamed: on an instance using > values from > "anInstance class allInstVarNames" which in the case of *any* proxy > won't work unless > the proxy implements a version of #instVarNamed:. > > This is confusing because now the proxy is no longer behaving as a > proxy, now > reflectively it's answering values for itself rather than the > instance being proxied. > > Another solution would be if the proxy overrode #class to return the > class of the > proxied instance, but I've always assumed all hell would break loose > if you overrode > #class, I didn't think it safe to do, and I've not seen any other > proxy class do this. > > Regardless of the ultimate solution, the inspector shouldn't blow > up, it should catch > the exception and have some default rendering behavior for when it > can't inspect an > object for some reason. Do you not agree? > > Delete commentComment 7 by stephane.ducasse, Today (moments ago) > Yes I agree. > We should contact frederick. > I think that the inspector should know that it is browsing a proxy > and pay attention. > _______________________________________________ > 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] PhD and PostDoc topics with us at Lille :)

by StÃ©phane Ducasse

The deadline for a phd defense is 31 of december. What should be done is to give a date of the defense. Stef > Hi all > > INRIA is offering some PhD positions and we are looking for candidates (note that a commitee will decide not us). > Here are the topics for our team > > Reflection and Security in Dynamic Languages > http://www.inria.fr/travailler/mrted/en/doc/details.html?id=PNGFK026203F3VB… > > Software re-modularization > http://www.inria.fr/travailler/mrted/en/doc/details.html?id=PNGFK026203F3VB… > > Deadline for applying: Mai 4 > > > > for the postdoc you should have defended your PhD by end of October (I should check) > > Reflection and Scoping in Dynamic Languages > http://www.inria.fr/travailler/mrted/en/postdoc/details.html?id=PNGFK026203… > > > Designing a pure trait-based language > http://www.inria.fr/travailler/mrted/en/postdoc/details.html?id=PNGFK026203… > > Deadline for applying: Mars 14 > > please distribute :) > > > _______________________________________________ > 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

[Pharo-project] About new inspector

by StÃ©phane Ducasse

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 "What happens is the inspector asks for "self class allInstVarNames" and then tries to get each value with "self instVarNamed: aName". The problem is, self class allInstVarNames answers the instVars of the future class, but "self instVarNamed: aName" gets passed up to the MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an error because of course it doesn't have the correct instant vars. The old inspectors weren't as intrusive and worked, these new tools clearly still have some bugs. Since ProtoObject, the superclass for any such proxies doesn't do #instVarNamed:, such code in the inspector will blow up anytime one attempts to inspect any kind of proxy. I would report this as a bug to whoever is maintaining the new inspector tools." So the only way I know to produce the 'bug' is to load the SFuture class he describes in the blogpost I mention above then run the example I posted in step two. If this is the wrong place to report this then let me know and I'll keep looking for the correct place. Delete commentComment 4 by pdebruic, Today (14 hours ago) The default, I think. I haven't changed anything. SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor Delete commentComment 5 by marcus.denker, Today (11 hours ago) I think the problem is this: -> ProtoObject implements a *minimal* object. This way, Proxies or Futures can use #doesNotUnderstand to implement what they implement. That is, for the example of the Proxy, every message is forwarded to the remote object. -> Now we do not know what exactly you want to forward. Should an inspector inspect the local proxy? Ot the remote object? You decide. Your subclass of ProtoObject copies as many objects from Object as you want. (often all that are needed to inspect the *proxy* vs. the remote object). I think Ramon fine-tuned his implementation for the normal old inspector. Now when you use another one, it uses other methods in addition to the one implemented in the Future --> confusion. Chaos. Bug. But: We can not fix this. this is purely the responsibility of the implementor of the subclass of ProtoObject. So. next action: -> We fix (uhm, remove) the croquet Future code that is just plain confusing. -> We think hard if it's really a problem in the new inspector vs. a missing method on the Future. (and, yes, all this sucks anyway.... we are hard at work to make reflection better and solve all this in a *much* nicer way... but that's research...) Delete commentComment 6 by ramon.leon, Today (10 hours ago) It's not just the Future proxy that'll have problems, it's proxies in general. The way the current inspector is written won't work with any proxy I see in my image, SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the Glorp record proxy, because it assume it can use #instVarNamed: on an instance using values from "anInstance class allInstVarNames" which in the case of *any* proxy won't work unless the proxy implements a version of #instVarNamed:. This is confusing because now the proxy is no longer behaving as a proxy, now reflectively it's answering values for itself rather than the instance being proxied. Another solution would be if the proxy overrode #class to return the class of the proxied instance, but I've always assumed all hell would break loose if you overrode #class, I didn't think it safe to do, and I've not seen any other proxy class do this. Regardless of the ultimate solution, the inspector shouldn't blow up, it should catch the exception and have some default rendering behavior for when it can't inspect an object for some reason. Do you not agree? Delete commentComment 7 by stephane.ducasse, Today (moments ago) Yes I agree. We should contact frederick. I think that the inspector should know that it is browsing a proxy and pay attention.

Feb. 16, 2010