- Pharo-dev - lists.pharo.org

[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

[Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))
by Igor Stasenko Dec. 30, 2009

Dec. 30, 2009

---------- Forwarded message ---------- From: David T. Lewis <lewis(a)mail.msen.com> Date: 2009/12/27 Subject: Re: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use)) To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> I have put the updates for large changes and sources files into the inbox. I would appreciate if someone can review this before moving into trunk. There are three mcz updates: Â Files-dtl.62 Â System-dtl.205 Â Kernel-dtl.347 Important: The changes *must* be loaded in the order listed above. This will require a configuration map update when the changes are moved to trunk. The use of ExpandedSourceFileArray takes effect after the first image restart. To change back to using the StandardSourceFileArray, the procedure is as follows: Â 1) Evaluate 'StandardSourceFileArray install' Â 2) Edit SourceFileArray class>>concreteClass to answer Â Â StandardSourceFileArray rather than ExpandedSourceFileArray. Thanks, Dave -- Best regards, Igor Stasenko AKA sig.

4 7

[Pharo-project] Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor
by StÃ©phane Ducasse Dec. 30, 2009

Dec. 30, 2009

Hi john When I'm doing /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt coral.image I get 2009-12-30 22:38:01.629 Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor Also this is strange but I have the impression that the image starts seems slower (of course I have around or more 20 app open). Stef

1 0

Re: [Pharo-project] Pharo-beginner mailing list ? (St?phane Ducasse)
by John Escobedo Dec. 30, 2009

Dec. 30, 2009

+1 Please start a beginner mailing list because Pharo is also some people's first look at smalltalk. A place to ask a mixture of question that come from being new to both would be welcome.

3 2

Dec. 30, 2009

hi igor up to 11125 it works well and after when I was trying to do the last two cs using MC in 11125 I get new ^ self trailerClass basicNew initialize trailerClass ^ TrailerClass ifNil: [ OldMethodTrailer ] in 11126 when I try to load these packages. I get CompiledMethodTrailer new does understand trailerClass Stef (now I have to run downtown with my boys and I will come back in 2hours or so). CompiledMethodTrailer class(Object)>>doesNotUnderstand: #trailerClass CompiledMethodTrailer class>>new CompiledMethod>>trailer CompiledMethod>>getSourceFor:in: Metaclass(Behavior)>>sourceCodeAt:ifAbsent: Metaclass(Behavior)>>ultimateSourceCodeAt:ifAbsent: Browser(CodeHolder)>>sourceStringPrettifiedAndDiffed Browser>>selectedMessage Browser>>contents PluggableTextMorph>>getText PluggableTextMorph>>update: [] in Browser(Object)>>changed: DependentsArray>>do: Browser(Object)>>changed: Browser(Object)>>contentsChanged Browser(CodeHolder)>>contentsChanged Browser>>messageListIndex: PluggableListMorph>>changeModelSelection: PluggableListMorph>>mouseUp: PluggableListMorph(Morph)>>handleMouseUp: MouseButtonEvent>>sentTo: PluggableListMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: PluggableListMorph(Morph)>>processEvent:using: PluggableListMorph(Morph)>>processEvent: PluggableListMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: [] in PasteUpMorph>>becomeActiveDuring: BlockClosure>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendMouseEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: Array(SequenceableCollection)>>do: WorldState>>handsDo:

2 5

Re: [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 Dale Henrichs Dec. 30, 2009

Dec. 30, 2009

2 1