- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.1] #11214
by Marcus Denker Feb. 18, 2010

Feb. 18, 2010

11214 ----- Issue 1945: registration mechanism for the menu Very nice, Alain!!! Issue 1974: remove #disableSubmorphFocusForHand: (part 1) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 2

[Pharo-project] inspiring CRUD like
by StÃ©phane Ducasse Feb. 18, 2010

Feb. 18, 2010

I think that the idea is really interesting to capture a lot of lists collection like application http://www.query-vision.com/qv.html Stef

2 2

[Pharo-project] Issue 1884: NetNameResolver doesn't work in PharoCore
by Adrian Lienhard Feb. 18, 2010

Feb. 18, 2010

http://code.google.com/p/pharo/issues/detail?id=1884 This issue probably is the last obstacle for the 1.0 release. I've added the following comment: --------- The preference proposed by Miguel does not solve the problem but puts the burden on the user that needs to change the preference depending on which implementation works for him. This will lead to many questions and frustrated users. If possible, I'd prefer to make the legacy IPv4 implementation work again until we have a proper IPv6 implementation. The problem with printing "NetNameResolver addressForName: 'www.yahoo.com'" is not that the resolution does not work correctly but that the printOn: implementation of SocketAddress assumes an IPv6 address. I suggest to change the SocketAddress>>printOn: as follows. Maybe it's just this simple change to makes IPv4 work again -- maybe more such backward compatibility code is needed. SocketAddress >>printOn: aStream NetNameResolver useOldNetwork ifTrue: [ ^ super printOn: aStream ]. aStream nextPutAll: self hostNumber; nextPut: $(; nextPutAll: self hostName; nextPut: $); nextPut: $,; nextPutAll: self serviceNumber; nextPut: $(; nextPutAll: self serviceName; nextPut: $) --------- This change makes #addressForName: work again with useOldNetwork set to true (as it is in recent PharoCore 1.0 images). Could people that experience problems with the network code update this method and check out if other parts break? Cheers, Adrian ___________________ http://www.adrian-lienhard.ch/

5 6

Re: [Pharo-project] [Seaside-dev] GROrderedCollectionTest>>#testSort
by Lukas Renggli Feb. 17, 2010

Feb. 17, 2010

> #sort you mean? Not yet... we either need to add it in Pharo, fix it > in the one click, or add it to the Grease package. OrderedCollection>>#sort and OrderedCollection>>#sort: is already part of Pharo 1.1. The Seaside tests pass in Pharo 1.1. I understand and I agree with Pharo not to implement #sort and #sort: in SequenceableCollection, because it does not make sense for most subclasses. SortedCollection, Heap and Interval are already sorted; and for LinkedList sorting does not really make sense. So I don't really know what to do to fix the Seaside test. We could ask the Pharo guys to integrate OrderedCollection>>#sort and OrderedCollection>>#sort: into Pharo 1.0, but maybe that's already too late? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

4 8

[Pharo-project] [Slightly OT] Integers smarter than me today
by Schwab,Wilhelm K Feb. 17, 2010

Feb. 17, 2010

Hello all, I am trying to make a recognizer for a communication protocol that has very likely been errantly documented. Such tasks can be difficult enough with good docs, but I'm not even sure what is supposed to be happening, so it is really interesting. One of the things that I **think** is happening, is that 12-bit two's complement data is included at one point in the stream. The bits are spread over a 16 bit word. Let's assume that I can correctly gather the 12 bits together. Could some kind soul suggest how to go from the resulting SmallInteger to the correct signed value? Smalltalk is adding a wrinkle that I am not sure how to handle: should I set the "missing" bits to 1? Out to bit 31? Any pointers/suggestions would be greatly appreciated. Bill

3 4

[Pharo-project] New version of XMLParser
by Alexandre Bergel Feb. 17, 2010

Feb. 17, 2010

Dear List, I incorporated some changes of XMLParser proposed by jaayer(a)zoho.com These changes may break some existing applications. For example, I had to adapt CAnalyzer. ConfigurationOfXMLSupport has now #version102: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 2

[Pharo-project] [update 1.1] #11212
by Marcus Denker Feb. 17, 2010

Feb. 17, 2010

11212 ----- - Issue 1962: remove FileDirectory #st and #cs - Issue 1977: fix for MethodFinder - Issue 1976: remove left over Futures code from Compiler - Issue 1975: remove more unsent etoy methods in Morph - Issue 1971: small cleanup of sort: - Issue 1972: clean ResourceCollector, ResourceManager and ResouceLocator (somehow this was not posted...) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] FileSystem question
by stephane ducasse Feb. 17, 2010

Feb. 17, 2010

|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 I like the way FSFilePluginPrims encapsulate the primitive calls. Stef

4 4

Feb. 17, 2010

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.

4 8

[Pharo-project] adding traits programatically
by Esteban Lorenzano Feb. 16, 2010

Feb. 16, 2010

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

2 1