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

Re: [Pharo-project] Advanced keyboard access with OB

by Fernando olivero

Lukas, for Gaucho1.1 i've implemented a completion editor. It would allow to remove the list or to provide a quick access to the most relevant search ( just like the google-like url search field does). Once Gaucho1.1 is released i will push those additions into Pharo1.2. And maybe integrate them into you OB search entry field. Fernando pd: the two classes that are needed. SimpleEditor subclass: #CompletionEditor instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'GauchoGUI-Morphic-Widgets' EntryFieldMorph subclass: #CompletionEntryField instanceVariableNames: 'completionStrategy completion defaultContents' classVariableNames: '' poolDictionaries: '' category: 'GauchoGUI-Morphic-Widgets' On Sep 27, 2010, at 1:48 AM, Francisco Ortiz PeÃ±aloza wrote: > Love these changes, thanks! > > Francisco > > On Sun, Sep 26, 2010 at 6:30 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > http://www.lukas-renggli.ch/blog/ob-completion-dialog > > Looks great, thanks Lukas! > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > <ATT00001..txt>

Sept. 27, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Lukas Renggli

> Do I make it an issue? Yes. > Is there already an issue? (did not find one) Yes. > Am I wrong? Yes, almost always one should probably use #= instead of #==. Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 27, 2010

Re: [Pharo-project] [ANN] Glamour on Seaside - first version

by Simon Denier

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

Sept. 27, 2010

[Pharo-project] ('a' == 'a') == true ?

by Johan Brichau

I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (&Squeak) the following goes wrong imho: 'a' == 'a' -> true $a asString == $a asString -> false It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... |a b| a := 'a'. b := 'a'. a == b inspect Do I make it an issue? Is there already an issue? (did not find one) Am I wrong? Johan

Sept. 27, 2010

[Pharo-project] Application Craft IDE

by Geert Claes

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.

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Guillermo Polito

Ah, I forgot: SortedCollection no case sensitive -> 58 seconds SortedCollection case sensitive -> 56 seconds On Mon, Sep 27, 2010 at 1:43 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > My Pharo 1.1 Dev, cog image: > > OrderedCollection with an initial size of 500 and without sorting, no case > sensitive, - 23 seconds > > OrderedCollection with an initial size of 500 and without sorting, case > sensitive, - 17/18 seconds > > OrderedCollection with an initial size of 500 and sorting with #sortBy:, no > case sensitive - 25 seconds > > OrderedCollection with an initial size of 500 and sorting with #sortBy:, > case sensitive - 21 seconds > > > Hope it helps, > cheers > > Guille > > 2010/9/26 Levente Uzonyi <leves(a)elte.hu> > > On Sun, 26 Sep 2010, StÃ©phane Ducasse wrote: >> >> >>> 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? >>> >> >> 21 seconds. >> >> >> Levente >> >> >> >>> 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 >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)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 >> > >

Sept. 27, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Guillermo Polito

My Pharo 1.1 Dev, cog image: OrderedCollection with an initial size of 500 and without sorting, no case sensitive, - 23 seconds OrderedCollection with an initial size of 500 and without sorting, case sensitive, - 17/18 seconds OrderedCollection with an initial size of 500 and sorting with #sortBy:, no case sensitive - 25 seconds OrderedCollection with an initial size of 500 and sorting with #sortBy:, case sensitive - 21 seconds Hope it helps, cheers Guille 2010/9/26 Levente Uzonyi <leves(a)elte.hu> > On Sun, 26 Sep 2010, StÃ©phane Ducasse wrote: > > >> 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? >> > > 21 seconds. > > > Levente > > > >> 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 >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)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 >

Sept. 27, 2010

Re: [Pharo-project] Advanced keyboard access with OB

by Francisco Ortiz PeÃ±aloza

Love these changes, thanks! Francisco On Sun, Sep 26, 2010 at 6:30 PM, Simon Denier <Simon.Denier(a)inria.fr> wrote: > > http://www.lukas-renggli.ch/blog/ob-completion-dialog > > Looks great, thanks Lukas! > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 26, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Levente Uzonyi

On Sun, 26 Sep 2010, StÃ©phane Ducasse wrote: > > 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? 21 seconds. Levente > >>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 26, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by Schwab,Wilhelm K

Stef, About the CHB (you just have to use Dolphin's for a while to see what I mean). Most of the substantive differences are probably in deference to speed?? Maybe when Cog is mainstream, we can just "let it go." Dolphin's CHB presents the entire class hierarchy rather than showing little pieces of it here and there, which has always been my experience with Squeak's CHB. About moving code away from the change log, I am simply worried about all of the complexities that can arise. I largely don't care how the system works provide it works *really* well<g> and that it has some redundancy in case I manage to fry an image, and moving code away from the log strikes me as real time sink to get right, so I am urging caution with change where code is stored. I fully supportive of a new packaging system that has concrete packages and frees up method categories. Does that help? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Sunday, September 26, 2010 2:51 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2010