- Pharo-dev - lists.pharo.org

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

by Yanni Chiu

Dale Henrichs wrote: > ----- "Yanni Chiu" <yanni(a)rogers.com> wrote: > > | BTW, since all FFI-Examples packages were removed from the FFI > | repository, even Metacello "versions" would fail because the package > | is > | no longer there. > > This underscores Lukas' argument that you need to create your own repository of packages that you use. I don't understand how this jives with Metacello. If I depend on a Metacello configuration then I inherit the repository dependencies of that configuration -- unless I maintain my own copy of the configuration and the packages it references. > As far as I am concerned, it is a cardinal sin to remove packages from a public repository ... I agree. I assume the reason for removing the package was to eliminate confusion caused when the latest version of the package is loaded, but doesn't work, because none of the code should be there. Another approach might have been to delete all the classes/methods from the package, and submit it as the latest version. Though I'm not sure Monticello would accept an "empty" package. > We'll have to mark the earlier versions of FFI as broken in the Metacello config unless we can recover the older files... I probably can find an old version in a package-cache, but the repository for FFI is on http://source.squeakfoundation.org, which seems to be the active code base for Squeak (correct me if I'm wrong). -- Yanni

Feb. 17, 2010

Re: [Pharo-project] FileSystem question

by Colin Putney

On 2010-02-15, at 9:36 AM, stephane ducasse wrote: > |working cache| > working := FSDiskFilesystem current working. > cache := working / 'package-cache'. > cache entry > cache entry creation. "--> 2010-02-14T10:34:31+00:00" > cache entry modification. "--> 2010-02-14T10:34:31+00:00" > cache entry size > > give me access to the file descriptor now I was wondering why we could not have > the API of description at the level of FSreference to avoid that navigation code. > > cache creation. "--> 2010-02-14T10:34:31+00:00" > cache modification. "--> 2010-02-14T10:34:31+00:00" > cache size Yes, references could provide direct access to the information in the entry. But I made it a separate object for a couple of reasons. The main one is performance. If you need to fetch several pieces of information it's more efficient to make one trip to the disk and keep all the information in one object. I ran into this problem while implementing the directory tree visitor code - it was slow, slow, slow until I implemented FSDirectoryEntry. Colin

Feb. 17, 2010

Re: [Pharo-project] About new inspector

by Igor Stasenko

My 2 cents. On 16 February 2010 19:49, Martin McClure <martin(a)hand2mouse.com> wrote: > 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. > +1. Inspectors should display proxies, not proxied objects. > * 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". > -1 here. I don't like breaking encapsulation. You gain nothing from revoking control from the object how to expose its own contents. Let me illustrate why: Suppose you want to print ivars of a proxy object without sending any messages to it. Okay, by using a primitive (which breaks encapsulation) you getting an object's class. And now you can send messages to that class.. Which is fine, except on some extreme cases one could have own class hierarchy, which not inherits from Behavior. So, you introducing a limiting factor along the way... Now, suppose that by doing such trickery you extracted some object from one of inspected object ivars. But hey, extracted object can be in own turn a proxy, and printing it may cause a side effects! Now, how you suppose to print anything without sending any message? A deadlock. So, since you can't avoid sending a message, then why doing this black voodo at all? Why not just establish a system-wide minimal protocol and say that all objects in system should respond with #mirror message, or #readOnlyMirror, if you like? Then, a) you don't have to break encapsulation b) any object could decide by itself, in what fashion to expose own contents. Problem solved. > Regards, > > -Martin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig.

Feb. 17, 2010

Re: [Pharo-project] About new inspector

by Martin McClure

StÃ©phane Ducasse wrote: >> 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? The discussion on mirror primitives on the Squeak-dev list on September 7 and December 16? Yes, exactly. -Martin

Feb. 17, 2010

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

by Dale Henrichs

Feb. 17, 2010

Re: [Pharo-project] ConfigurationOfXMLSupport...

by Alexandre Bergel

Hi Dale, Thanks for writing ConfigurationOfXMLSupport, I should have done it, but I could not find the time. I consider the package XML-Testing as obsolete. I haven't been able to run it. I think it was useful when Michael begun to develop XML-Parser. But for now, it is rather irrelevant. I added some tests some times ago to not leave this package untested. Maybe I could separate the test from the core if necessary. Cheers, Alexandre NB: Sorry for my late reply, I was on holidays On 7 Feb 2010, at 16:31, Dale Henrichs wrote: > I've just published ConfigurationOfXMLSupport to the > MetacelloRepository. It is used by several Pier addons. It _is_ just > one package, but since it can be used in a lot of different > projects, I thought it was worth adding as a configuration. > > It is based upon the code in http://www.squeaksource.com/XMLSupport. > The test package appears to be several years old and a number of the > tests failed, so I didn't include them in this version of the config. > > So if someone with a little more knowledge about XMLSupport could > comment, that would help (hint, hint, Alexandre:). > > Thanks, > > Dale > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 16, 2010

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

by Miguel Enrique CobÃ¡ Martinez

El mar, 16-02-2010 a las 13:25 -0800, Dale Henrichs escribiÃ³: > ----- "Yanni Chiu" <yanni(a)rogers.com> wrote: > > | BTW, since all FFI-Examples packages were removed from the FFI > | repository, even Metacello "versions" would fail because the package > | is > | no longer there. > > This underscores Lukas' argument that you need to create your own repository of packages that you use. > > As far as I am concerned, it is a cardinal sin to remove packages from a public repository, since folks may actually expect to use the older versions ... the repository owner can do their own thing of course and presumably have their reasons... > > We'll have to mark the earlier versions of FFI as broken in the Metacello config unless we can recover the older files... > Yes, good idea, some kind of pragma marker on a otherwise unmodified old version method in ConfigurationOfXXX will allow the tools to present the version but highlight their brokeness. cheers > Dale > > _______________________________________________ > 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] adding traits programatically

by Alexandre Bergel

Hi Esteban, traitComposition: is a low level method that should not be accessed. I believe that #setTraitComposition: is what you're looking for: NSProxy setTraitComposition: {TNSLogConsole} asTraitComposition Cheers, Alexandre On 11 Feb 2010, at 11:11, Esteban Lorenzano wrote: > Hi, > I'm trying to add/remove traits from a class programatically and I > have > a problem... > What I'm doing is, for instance: > > NSProxy traitCompostition: TNSLogConsole. > > and > > NSProxy traitComposition: TNSLogNone. > > (as a way to replace logging strategies)... but nothing happens... > bah... in the browser the class definition is affected, but the > application still works as if none changed... do I need to force a > class recompilation after changing trait composition? what I'm doing > wrong? > > Cheers, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 16, 2010

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

by Dale Henrichs

----- "Yanni Chiu" <yanni(a)rogers.com> wrote: | BTW, since all FFI-Examples packages were removed from the FFI | repository, even Metacello "versions" would fail because the package | is | no longer there. This underscores Lukas' argument that you need to create your own repository of packages that you use. As far as I am concerned, it is a cardinal sin to remove packages from a public repository, since folks may actually expect to use the older versions ... the repository owner can do their own thing of course and presumably have their reasons... We'll have to mark the earlier versions of FFI as broken in the Metacello config unless we can recover the older files... Dale

Feb. 16, 2010

Re: [Pharo-project] About String empty and others

by Michael Roberts

it is an interesting topic. I find #() more expressive than Array empty. but perhaps this is because I have learnt to recognize it deeply. Something i remember Michele Lanza talking about visualisation and the types of things (size, colour, shape) that we have a primitive recognition of http://www.se-radio.net/podcast/2009-03/episode-130-code-visualization-mich… and I am sure all the Moose folks are very familiar... I am not sure if it applies in this case or not of course... Anyway I feel that I never have to 'parse' #() but when I see Array empty, i have to read it in my head. So for me it might be more expressive but it is more verbose. I am just interested in the debate from a syntax point of view, not an optimization point of view. I feel there is a correlation between #() being physically small, about 5-10mm say on the screen with Array new, or String new which is at least 5cm with a space that breaks it up. Do you see my point? I guess I don't understand why without it, Pharo does not describe itself. You would only expect a single send of Array empty in the system (from the optimzation machinery)? If people started using it generally, i would find that a shame for the reason described above that it is not compact. If all you want is the empty array defined in a single place, I guess that is fine. but then how do you mark it private? cheers, Mike On Tue, Feb 16, 2010 at 8:57 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Feb 16, 2010, at 8:01 PM, Chris Muller wrote: > >> Even if you make the compiler change, I hope you will still consider >> leaving the two #empty methods in place for expressiveness. Â They, >> too, would answer the single canonicalized global stored in the >> compiler. Â However, the use of #empty makes the canonicalization >> explicit rather than implicit, and affords appreciation of a Pharo >> system that describes itself, e.g., associating the word "empty" with >> the notation that a new Pharo user might find cryptic. > > this changes was already integrated. > > Now your argument could work if the syntax #(a b c) would disappear. > Now since you have to teach/learn #(a b c), it should be clear that #() > is an empty array. The same argument holds for '' versus String empty. > So I do not see the real gain. > > 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