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

Re: [Pharo-project] MethodName is now Finder
by Benjamin Van Ryseghem Sept. 27, 2010

Sept. 27, 2010

This was a cool feeling to have the opportunity to pair-program with such cool people, and to learn as much ^^ I hope it will be the same at the Pharo Sprint ;) Ben

6 11

[Pharo-project] Morphic
by DeNigris Sean Sept. 27, 2010

Sept. 27, 2010

I was doing a lot of playing with Morphic this week at ESUG in Barcelona. Many people seem to really not like it and complain about it, but it seems very vague i.e. they can't point to a specific problem with it. I think it's amazingly powerful and universally misunderstood. Many people are pushing for native widgets for end users, which I think is awesome, but serves a different role. For me, there are two use cases: 1. People (mostly Smalltalkers, including myself) interested in the UI's of the future and exploring what's possible 2. People who love their (e.g. Mac) look and feel or are in a setting (e.g. enterprise) where they have to use a particular GUI. Morphic seems ideal for group #1. I think the key questions are: * if you were implementing Morphic today, knowing what you know after it being used over the years, how would you do it? * what would it take (if possible) to get there from the current implementation? Two issues I've noticed: 1. there seems to be an explosion of classes with slightly different behavior e.g. TextMorph, TextMorphForShout, PluggableTextMorph, PluggableShoutMorph. 2. I'm not clear whether the hooks for modifying behavior are a. available in all the right places b. working c. widely understood I'm forming an informal panel to discuss this. I've reached out to Morphic's creators and some original users. A quick example of my (seemingly common) experience: For example, I'm writing an implementorsOf browser that shows the execution path as a graph of MethodMorphs connected by LineMorphs, because the standard paned browser does not capture the metaphor of drilling down through implementors. So I Created a MethodMorph and added as a submorph a PluggableShoutMorph to hold the code. At that point, I couldn't figure out a good/easy way to react to mouse events and pop out a new MethodMorph. I tried (one of these felt very satisfying): * Morph>>on:send:to:, which sounded good, but never got called * intercepting Morph>>processEvent:using: (which I was told was not a good idea) * (after seeking help), locking the submorphs and overriding the dozen or so event-related methods in the chain from my morph to TextMorphForShout (the Morph that actually handles the text and input). * subclassing TextMorphForShout and then subclassing PluggableShoutMorph to use that subclass. Sean

14 46

[Pharo-project] which Shout repository should we use?
by Mariano Martinez Peck Sept. 27, 2010

Sept. 27, 2010

Hi folks. We should discuss which Shout repository to use for the PharoDev image. Some months ago we had the same problem...which OB repository to took? the one from squeaksource or Lukas's one. We chose Lukas's one because he maintained it. Now we have the same situation with Shout. There is the SS (http://www.squeaksource.com/shout) repo for it, and Lukas' one ( http://source.lukas-renggli.ch/unsorted) in his own repo. Now...we have 3 options: 1) Start to use Lukas' one. For that, I have to update ConfigurationOfShout and start using that repo. 2) Continue to use the SS one but...someone needs to merge lukas fixes from his repo to the SS repo. I don't have time to do this. So....what do we do? As an example, Lukas committed today all the removal to Preferences, something that is needed for Pharo 1.2. Cheers Mariano

5 12

[Pharo-project] Advanced keyboard access with OB
by Simon Denier Sept. 27, 2010

Sept. 27, 2010

http://www.lukas-renggli.ch/blog/ob-completion-dialog Looks great, thanks Lukas! -- Simon

3 2

Re: [Pharo-project] [ANN] Glamour on Seaside - first version
by Simon Denier Sept. 27, 2010

Sept. 27, 2010

On 26 sept. 2010, at 23:15, Tudor Girba wrote: > Hi, > > We are happy to announce the first version of Glamour on Seaside. This work was carried out by Andrei Vasile Chis and was sponsored by ESUG. The project offers a Seaside-based rendering of Glamour browsers. In other words, once you have a browser in Glamour, you can now simply display it on the web. Thanks Andrei and Doru! I notice a slight enhancement with the seaside renderer: we can close tabs! (although, that would be good if we could also disable tab closing?) > > You can obtain the code in two ways: > - Nightly built image: > http://hudson.moosetechnology.org/job/moose-with-glamour-seaside/lastSucces… > - Metacello configuration loadable in Pharo 1.1 (not Core) > Gofer new > squeaksource: 'Glamour'; > package: 'ConfigurationOfGlamourSeaside'; > load. > (Smalltalk at: #ConfigurationOfGlamourSeaside) loadDefault. > > A couple of examples are available on the Moose server: > http://online.moosetechnology.org/glamour/basicExamples (a number of example browsers) > http://online.moosetechnology.org/moose/metaBrowser (a browser for the meta-model of Moose) > > > Several developments are planned for the near future, so stay tuned for more news. > > We would highly appreciate any kind of feedback. > > Cheers, > Andrei and Doru > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

1 0

[Pharo-project] Application Craft IDE
by Geert Claes Sept. 27, 2010

Sept. 27, 2010

I noticed a pretty cool tool on TechCrunch this morning from a startup called Application Craft (www.applicationcraft.com) I thought I'd share it here because it would be great to see a Smalttalk based tool with a cool IDE like that: http://scobleizer.com/2010/09/26/corporate-developers-exclusive-first-look-… Maybe CinCom's Web Velocity or Georg Heeg's seaBreeze could have a look at some of their concepts and its IDE. -- View this message in context: http://forum.world.st/Application-Craft-IDE-tp2715035p2715035.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

1 0

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
by StÃ©phane Ducasse Sept. 27, 2010

Sept. 27, 2010

On Sep 26, 2010, at 7:03 PM, Levente Uzonyi wrote: > On Sun, 26 Sep 2010, Mariano Martinez Peck wrote: > >> Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. >> If I just take a core image, load OCompletion and run tests, they take a lot >> of time, not acceptable. > > 7-8 seconds in Squeak using Cog. and in squeak wihout Cog? >> Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run >> OCompletion tests, the tests takes HOURS. The image seems frozen, but >> actually is working. If I interrupt I see the problem is in >> >> ECUntypedModel >> initializeSelectors >> >> the part of >> >> >> [ Smalltalk environment keysDo: >> [ :each | >> selectors add: (ECGlobalEntry >> contents: each >> type: #globalVar) ]. >> >> >> takes a lot of time > > I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage. > > > Levente

3 3

Sept. 26, 2010

I do not know exactly what you mean. We want a good, working and flexible system. We just a problem of time. Stef On Sep 26, 2010, at 7:11 PM, Schwab,Wilhelm K wrote: > Keeping things out of the change log? Does that imply that all code must be packaged? It more or less is already, though not always meaningfully. When repackaging a class or method, do you plan to take the code out of the old package's log and put it in the new one? Dolphin uses "real" packages, but it is possible to have unpackaged code - I'm not sure if that's a good thing or not. One day, I would like to see Pharo have a *hierarchy* browser as good as Dolphin's. I think it could be built absent an ability to have unpackaged classes, but I would not want to see it sabotaged by design. Probably a bigger risk would be having work lost by gaps in the packaging system when a catch-all change log would have held onto it. > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] > Sent: Sunday, September 26, 2010 11:18 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum > > On Sun, Sep 26, 2010 at 2:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >> >>> >>> Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? >> >> the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. >> This is why slowly we will have to think to get something better. >> >> Do you mean improving the change scanner parsing or throwing away and going for something different? >> > > Hi eliot > > our vision is that we would like to have > - all the code of all the squeak and pharo version in a queryable service available from the web. > for that we want a source code metamodel a la ginsu or famix > Use this metamodel to aggregate several meta models: pseudo class/rb > make sure that when possible this model as a compative API with the one of classes and friends => tools reuse > Veronica is working on that. > Hernan will probably join. > May be Colin should join. We could have a nice momentum. > > - for the changes we would like to have something else than a chunk format > because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that > and token at: 3 do that). > > xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see > > <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > but this would be much mire useful: > > <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> > > > > Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool > easily. > > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. > > BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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

2 1

[Pharo-project] In Smalltalk you can't loose code... hum
by FranÃ§ois Tanguy Sept. 26, 2010

Sept. 26, 2010

Hi, the statement is true when the code is saved in the browser. But in a workspace or in the script manager that is not true. Actually it is a feature request: You can't loose code even when you are working in the script browser. Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? Francois

4 5

Sept. 26, 2010

On Sep 26, 2010, at 8:59 PM, Igor Stasenko wrote: > On 26 September 2010 21:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> BTW, now we have Igor's method trailers we can start playing with more than >>>> two source files, e.g. /not/ appending a Monticello package's source to the >>>> changes file, but merely adding it to a special directory, e.g. sources. >>> >>> Yes. I told about potential use of new trailers, where we can implement a model >>> for storing/retrieving source code from any kind of storage. >>> >>> Unfortunately it requires some remodelling of system's source-code >>> management system, >>> to get rid of hard-wired SourceFiles code and add an abstract layer >>> for source management. >>> So we could implement different source managers, where .source and >>> .changes will be just default one. >>> >>> One of my ideas was to use CouchDB for storing everything there. It >>> opens quite interesting opportunities, >>> like being able to browse a history of some particular method up to >>> 1.0 squeak release :) >>> >>> @Stef: add this to pharo todo list :) >> >> but this one is on the path of veronica phd so we should do it fast. >> Veronica likes to work under pressure so this is good. >> > Haha.. so, when i described it sometimes ago you told that this good > for phd thesis, > you already had a plan & assignee for it :) I do not remember. doing too much stuff. Now the PhD of veronica is not one source code management. The PhD of veronica is about: how to help merging. How could we add a bit of semantics. In this topic we would like - to get changes characterization (cf ESUg talk) - to know the potential impact of a change - compare feature in the past and feature so having a good infrastructure will help everybody. We should be able to write nice and short queries to study the past and the present. Stef > > Nice. > >> stef >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0