December 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Cannot even browse a class in web image
by Mariano Martinez Peck Jan. 1, 2010

Jan. 1, 2010

Issue: http://code.google.com/p/pharo/issues/detail?id=1724 Pharo image: pharo1.0-10502-rc1web09.12.2 Pharo core version: 10502 Virtual machine used: Squeak 4.2.2beta1U.app Class browser used if applicable: O2PackageBrowserAdaptor. Steps to reproduce: 1. Open a class browser 2. Click on the class ByteArray from the package Collection-Arrayed 'MessageNotUnderstood: ByteSymbol>>hasWideCharacterFrom:to:' I attach PharoDebug.log

5 13

[Pharo-project] Utilities >> startUp registration??
by StÃ©phane Ducasse Dec. 31, 2009

Dec. 31, 2009

does anybody know if this is of any use? startUp SystemChangeNotifier uniqueInstance notify: self ofAllSystemChangesUsing: #event:. event: anEvent "Hook for SystemChangeNotifier" (anEvent isCommented and: [anEvent itemKind = SystemChangeNotifier classKind]) ifTrue: [self noteMethodSubmission: #Comment forClass: anEvent item]. ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) ifTrue: [anEvent itemRequestor ifNotNil: [self noteMethodSubmission: anEvent itemSelector forClass: anEvent itemClass]]. ((anEvent isAdded or: [anEvent isModified]) and: [anEvent itemKind = SystemChangeNotifier methodKind]) ifTrue:[ InMidstOfFileinNotification signal ifFalse: [Utilities changed: #recentMethodSubmissions]. ].

2 1

[Pharo-project] [update 1.1] #11130
by StÃ©phane Ducasse Dec. 31, 2009

Dec. 31, 2009

11130 ----- - Cleaning Utilities... yet another step in the right direction

1 0

[Pharo-project] [update 1.1] #11129
by StÃ©phane Ducasse Dec. 31, 2009

Dec. 31, 2009

11129 ----- - Remove deprecated method from 1.0. Took 10501rc1 checked all the senders of deprecated: and removed the corresponding ones in 1.1

1 0

[Pharo-project] Fwd: New Year Edition :)
by StÃ©phane Ducasse Dec. 31, 2009

Dec. 31, 2009

Hi I uploaded a core-image 11128 https://gforge.inria.fr/frs/shownotes.php?release_id=4734 Stef

2 1

[Pharo-project] Developer guide ... ?
by Guido Stepken Dec. 31, 2009

Dec. 31, 2009

Hi folks! I really would appreciate some sort of "orientation" in this jungle of code in Pharo/Squeak ... 1. What classes are compatible to other smalltalks? When i follow mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of porting problems. Why?????? What classes should i give preference to minimize porting cost? 2. Interfaces ... hmmm, well ... there are many programmes thinking in categories of "interfaces", "libraries", "class dependencies", e.t.c. Of course, Smalltalk is something completely different, but it makes it difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk concepts. Gofer - till now, i have just a wage imagination, what it's good for ... 3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In Squeak, e.g. i simply generate my input forms with EToys, which can be replaced of course by a few lines of code typed in by hand ... But for developers coming from Java, C++ ... the first ask for a GUI builder and XAML e.t.c. There should be some documentation, that leads programmers, that are willing to switch over to Smalltalk, into the right direction. Just a few examples, e.g. how to build a form, that scrolls through some MySQL data sets, really would help. What about compatibility? Is Morphic portable to other Smalltalks? 4. Multitasking, green threads, ... There are really missing some pointers, howto code e.g. a background process that is fetching some data from e.g. MySQL or reading/writing large files, sending data over network - without freezing the GUI. 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without having a precise idea, where to find working examples to exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak ... 6. Databases: Magma seems to be fine as database, but also dog slow. I really hesitate to start serious projects with Magma. 7. Speed, Memory consumption, Quality of modern algorithms: When working with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly predictable. That makes webhosting e.g. on vservers absolutely impossible, the whole system quickly becomes unstable. IMHO in Pharo there are routines, that really waste a lot of memory, that could be programmed in a more intelligent way, expecially collection's algorithms ... ;-) Perhaps Donald Knuth books ("Art of Computer Programming") could help? Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds! so far my 0.0199999999â¬ Keep up the good work on Pharo, it's still a long way to go! regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

13 28

[Pharo-project] Link from website to pending issues is wrong
by Mariano Martinez Peck Dec. 31, 2009

Dec. 31, 2009

Where it says "See: list of open issues of PharoCore<http://code.google.com/p/pharo/issues/list?can=2&amp%20q=milestone=1.0>and additional issues of Pharo<http://code.google.com/p/pharo/issues/list?can=2&amp%20q=milestone=1.0-DevI…> ." They go to all issues, not 1.0. The links are wrong. Maybe Google changed the api of the parameters since the time the links were put. I would put something like this (at least it works for me) http://code.google.com/p/pharo/issues/list?can=2&q=label%3AMilestone-1.0 Cheers Mariano

3 2

[Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
by Mariano Martinez Peck Dec. 31, 2009

Dec. 31, 2009

Hi folks. I am really concerned about the instability of the dev and web images. WE CANNOT RELEASE a RC where you cannot even double click in a class. This cannot happens. We all know that all software can have bugs. But again, we cannot release images, and even RC images, which are supposed to be quite stable, where you cannot right click a class, you cannot refactor, you cannot even right click in the code pane. And don't told me "I use the keyboard" because I don't care what you do. A lot of people use the mouse. I have already said it several times. Most of the people don't care how nice, fast, clean, open source and well programmed is the Pharo Core image if they cannot use the Dev or Web image. Remember that our users are external users, you even don't care about the core. They just use Pharo, they are not developers. I really think we need to fix this. You are giving a bad impression of something which is not true. You are doing AN EXCELLENT work with PharoCore. Why to wast all of this for this kind of situations? It is a pity :( I don't know the best solution for this. I will only give an idea I have, but I would really like to hear you ideas and do something with this. 1) We are building a dev image per month more or lest. 5 days before en of months (more or less), the dev image should be built. 2) During 5 years, some people will use that image as a beta tester. I would ideally to have different users: different OS, different browsers, etc. This people will use that image for their work for those 5 days and report any bug that appears. Of course, not all people can do that. How is volunteer to be beta tester ? We can create a wiki page for that if you are agree with the idea. 3) After those 5 days, if the image is stable enough, it is released. If it is not, it is just not released. Nobody will kill you if one month you don't release a new image. In addition, is better not to release an unstable image that releasing it and not be able to do a single right click. In Canonical, all the employees MUST to use for one month or more each Ubuntu release. We are not employee, but we can do something similar. What do you think ? Cheers Mariano ---------- Forwarded message ---------- From: Stan Shepherd <stan.shepherd414(a)gmail.com> Date: Wed, Dec 30, 2009 at 6:26 PM Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols To: pharo-project(a)lists.gforge.inria.fr NB this logs a particular walkback, but the whole area appears to be unworkable in the web dev image. Please could the maintainers click, right click, middle click on each part of refactoring browser, take each menu item, etc. This will be much quicker than logging one bug at a time. If this turns out to be the last one, my apologies in advance. Thanks. ...Stan VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2 Class browser used (if applicable): OR2PackageBrowser. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols Receiver: OBClassNode<ShortIntegerArray> Arguments and temporary variables: aMessage: dynamicProtocols exception: MessageNotUnderstood: OBClassNode>>dynamicProtocols resumeValue: nil Receiver's instance variables: metaNode: Class #allCategory->AllMethodCategory #categories->MethodCategory #dy...etc... navigation: an O2DefaultEdgeNavigation theClass: ShortIntegerArray O2MetaEdge>>nodesForParent: Receiver: #dynamicProtocols->DynamicProtocols Arguments and temporary variables: aNode: OBClassNode<ShortIntegerArray> Receiver's instance variables: label: 'dynamicProtocols' selector: #dynamicProtocols metaNode: DynamicProtocols #methods->Method navigation: an O2DefaultEdgeNavigation isDropEdge: nil ... -- View this message in context: http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev… Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

8 22

[Pharo-project] 1.1 -- Inconsistent enumeration behavior of WeakKeyDictionary and subclasses
by Martin McClure Dec. 31, 2009

Dec. 31, 2009

If you run this in 1.1: | dict | dict := WeakKeyDictionary new. dict at: 'foo' copy put: 'bar'. Smalltalk garbageCollect. dict associationsDo: [:assoc | self halt]. dict do: [:val | self halt] It stops in the second halt, but not the first. This is because #associationsDo: does not include associations whose keys have been GCed, but #do: *does* include values whose corresponding keys have been GCed. This behavior seems inconsistent, and not particularly useful, and also seems to contradict the comments by the author in the Squeak bug from 2007, from which I'd think that #do: would not include the value which it currently does. So I *think* this is an oversight, and is easy to fix by defining WeakKeyDictionary>>do: in terms of self associationsDo:. But then there's the question of #size. The collection above answers 1 to #size, which also seems wrong. Comments? Regards, -Martin

3 4

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )
by Igor Stasenko Dec. 31, 2009

Dec. 31, 2009

2009/12/28 Andreas Raab <andreas.raab(a)gmx.de>: > Igor Stasenko wrote: >> >> 1. diff the number of lines between existing traits implementation & yours >> ? > > It's a bit tricky to get a precise comparison, since Berne traits reuse > various methods across Kernel-Classes and Traits. OTOH, there are many > methods that will be removed from Kernel due to completely unnecessary > complexities. I think the real comparison can only be done if you look at > the totals of Kernel+[Nano]Traits before and after and since I haven't done > the cleanup yet there is a bit of a problem in comparing this precisely. But > you give an idea, here is a bit of data measured as follows: > > #('Traits' 'Traits-Kernel' 'Traits-Kernel-Traits' 'Traits-Composition' > 'NanoTraits-Kernel' 'NanoTraits-Tests') do:[:pkgName| | pkg | > Â Â Â Â pkg := PackageInfo named: pkgName. > Â Â Â Â Transcript cr; show: pkg name; > Â Â Â Â Â Â Â Â tab; show: pkg classes size; > Â Â Â Â Â Â Â Â tab; show: pkg methods size. > ]. > > Package Â Â Â Â Â Â Â Â Classes Â Â Â Â Methods > Traits Â Â Â Â Â Â Â Â Â 59 Â Â Â Â Â Â Â 873 > Traits-Kernel Â Â Â Â Â 22 Â Â Â Â Â Â Â 343 > Traits-Kernel-Traits Â Â 17 Â Â Â Â Â Â Â 215 > Traits-Composition Â Â Â 7 Â Â Â Â Â Â Â 127 > NanoTraits-Kernel Â Â Â 9 Â Â Â Â Â Â Â 190 > NanoTraits-Tests Â Â Â Â 9 Â Â Â Â Â Â Â 122 > oh, that's quite a big difference. I am curious, is it because of simpler implementation or because of smaller feature set? > The "meat" for NanoTraits is 9 classes and 190 methods And, after installing > NanoTraits there will be many other methods removed in Behavior and friends > which are only the result of unnecessary complexity in Berned traits. It > will be *significantly* simpler by any measures and unloadable. > >> 2. tools support, MC, Browser etc ? > > Same as before. Slightly better on older systems (i.e., 3.8 based) because > browsers can cope with traits as is and mostly don't need special support > (i.e., using #classSide etc). > >> 3. are there some common protocols with old traits, so one could use >> traits for metaprogramming? > > As far as black-box reuse is concerned, there is no difference at all. There > is also plenty of common stuff for the internals but it's very hard to know > which protocols a particular client would use. > Well, browser should use some protocol to distingush between traits & classes, trait methods and regular ones etc.. As well as MC, SystemNotifier , changesets etc. Do you plan to fully adopt new traits in trunk (means completely replacing current ones, of course)? >> I haven't time to take a look at your code. But if it is smaller & >> less complex than current version, i will vote for it. > > Try it. Load it via: > > (Installer repository: 'http://www.squeaksource.com/NanoTraits') > Â Â Â Â install: 'NanoTraits-Kernel'; > Â Â Â Â install: 'NanoTraits-Tests'. > > then install it using: > > Â Â Â Â NanoTrait install. > > (WARNING: Be prepared to throw the image away if something goes wrong) > >> I just have some concerns about common protocols, so developers could >> use traits in both pharo & squeak without need of refactoring. > > Fair enough. I don't think there's much difficulty as far as extending the > existing protocols go. We could even add compatibility traits > (TCompilingBehavior etc) that model the old structure if people want to add > extension methods to those. > AFAIK, Pharo cleaned-up some stuff , removed this particular trait. I am however, think that putting traits in use for core classes having one VERY IMPORTANT aspect, that in this way we can decompose a bloated protocol(s) into a number a smaller ones, with well-distinguished roles, aside of code reuse. > And hey, my code is always MIT, so if the Pharo folks are interested, tell > them they're more than welcome to use and enhance it. The squeaksource > repository is world-writable. Aye, i CC this conversation to pharo list. Personally, amount of code is the major criteria for me to choose from. Especially for things in Kernel. And especially, if it doesn't having heavy tradeoffs. > > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

5 14