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

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

by Alexandre Bergel

Really cool!!! It works well, even though I feel it can be faster. Cheers, Alexandre On 26 Sep 2010, at 17: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. > > 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 > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 27, 2010

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

by Hannes Hirzel

On 9/26/10, Tudor Girba <tudor.girba(a)gmail.com> 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. > > 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 > Thank you. Where do I find the Seaside web server panel? http://localhost:8080 gives no answer. On which port does Seaside run? Regards --Hannes

Sept. 27, 2010

[Pharo-project] [ANN] pre-built 1.2 Core#12146

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27527/PharoCore-1.2-12146.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 27, 2010

[Pharo-project] Update Pharo image to the last version

by Dario Trussardi

Hi, i work with a Pharo image. The relative System About option report: Pharo-1.0 Latest update: #10517. Now my question is : I can update this image to the last version ? Or i need do : A) save my data B) download the last version C) restore my data Thank for any considerations, Dario

Sept. 27, 2010

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

by Schwab,Wilhelm K

"Works fine" is a value judgment that can cut both ways: one could also argue that VW lacks a useful optimization of literals. Non-literal strings should do what you want. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Monday, September 27, 2010 8:03 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ('a' == 'a') == true ? On Mon, 27 Sep 2010, Johan Brichau wrote: > > On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > >> On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>> >>>>> Am I wrong? >>>> >>>> Yes, almost always one should probably use #= instead of #==. >>> >>> I will add that to the exercise :-) >>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>> >> >> I think you can avoid using 'equal' word when describing a #== comparison. >> It can be explained as 'test whether comparands are same object or not' >> while #= is test whether two objects equal or not. > > Yes, this is exactly what the exercise is doing. > I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: > > a := #foobar. > b := #foobar. > a == b. > > a := 'foobar'. > b := 'foobar'. > a == b > > The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). If you evaluate it line by line, it will work as you expected. So you can even show how the compiler optimization works by evaluating it both ways. Levente > > Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. > > I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) > > cheers > Johan > _______________________________________________ > 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] Syntax extension for the Mercury Search bar

by Lukas Renggli

> As a remainder, this is what you can do from the search bar. Type: > Â ClassName (starts with uppercase, look up class definition) > Â #ClassName (look up references to ClassName) > Â methodName (starts with lowercase, look up implementors of methodName) > Â #methodName (look up senders of methodName) > - 'string' (look up for string in methods (not the same as look up in method source, which is much slower)) There is another one if you have the refactoring tools loaded. If the expression contains a backquote it searches for parse tree patterns, e.g. `@expr instVarNamed: `#string finds all the senders of #instVarNamed: that have a plain string-literal as its argument. > The search bar also works with completion, so it doubles as a useful launch bar actually. The fact that completion works is quite accidental and should be improved :-) > Any idea welcomed Actually, Colin and I were discussing about removing the Mercury panel. We observed that almost nobody uses or knows how to use it. I personally never use it, I find other ways to navigate much more efficient and simpler to perform without the need of typing cryptographic sequences of characters :-) The mercury panel is highly extensible, so maybe it would make sense to move it into an externally maintained package? Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 27, 2010

[Pharo-project] Syntax extension for the Mercury Search bar

by Simon Denier

OK, for those who don't know it, there is a nifty search tool in Omnibrowser, called the Mercury search bar, which comes at the top of OB (you can enabled it through Settings if it does not appear). As a remainder, this is what you can do from the search bar. Type: ClassName (starts with uppercase, look up class definition) #ClassName (look up references to ClassName) methodName (starts with lowercase, look up implementors of methodName) #methodName (look up senders of methodName) - 'string' (look up for string in methods (not the same as look up in method source, which is much slower)) The search bar also works with completion, so it doubles as a useful launch bar actually. Two things I would like to have: 1) look for package/system category 2) scope search, or environment search (open an environment on the given scope before starting the search) (3) ok a third, look for class hierarchy) Now for the first, any idea about an easy syntax to express a package search? I don't want to mix class and package search. So I was thinking of $PackageName or %PackageName, especially the first as it can not be recognized as a binary selector, but it looks weird. Second, I'm wondering about an inline syntax for scoping, like: methodName in: #PackageA -> will lookup for implementors of methodName in PackageA or simply cutting the Mercury textfield in two, with one for the search term and one for the scope) Any idea welcomed -- Simon

Sept. 27, 2010

Re: [Pharo-project] MethodName is now Finder

by Simon Denier

On 20 sept. 2010, at 20:33, StÃ©phane Ducasse wrote: > Benjamin > > I would rename patterns into example-based > Then > when on selector > I would propose classes if the guy type something that looks like a class or a part of a class name > similarly on class > I would propose selector if the guy started to type something like a selectors > The idea is to help the user as much as possible. > We did the same with the sender and implementor, you can browse a class if you type Point and press cmd-M instead of cmd-B Yep, did you have a look the Mercury search bar in OB? It has a nifty syntax to look for: - ClassName (starts with uppercase, look up class definition) - #ClassName (look up class references) - method (starts with lowercase, look up implementors) - #method (look up senders) - 'string' (look up for string in methods (not the same as look up in method source, which is much slower)) I would rename 'select classes' into something else, 'scoping classes', because it is really about the scope. Actually, I would love to extend the Mercury syntax to be able to scope things. > > Else did you try to remove the progress bar? > because this looks strange. > > Stef > >> I've fix some bug and discover how to script packages loading ^^ >> >> Now, just run >> >> >> Gofer new >> squeaksource: 'PharoTaskForces'; >> package: 'ConfigurationOfFinder'; >> load >> >> ConfigurationOfFinder loadDefault >> >> >> >> >> Ben >> _______________________________________________ >> 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 -- Simon

Sept. 27, 2010

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

by Levente Uzonyi

On Mon, 27 Sep 2010, Johan Brichau wrote: > > On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > >> On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>> >>>>> Am I wrong? >>>> >>>> Yes, almost always one should probably use #= instead of #==. >>> >>> I will add that to the exercise :-) >>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>> >> >> I think you can avoid using 'equal' word when describing a #== comparison. >> It can be explained as 'test whether comparands are same object or not' >> while #= is test whether two objects equal or not. > > Yes, this is exactly what the exercise is doing. > I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: > > a := #foobar. > b := #foobar. > a == b. > > a := 'foobar'. > b := 'foobar'. > a == b > > The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). If you evaluate it line by line, it will work as you expected. So you can even show how the compiler optimization works by evaluating it both ways. Levente > > Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. > > I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) > > cheers > Johan > _______________________________________________ > 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] ('a' == 'a') == true ?

by Schwab,Wilhelm K

#== (test for identity/same object) is perhaps most useful when verifying that objects are copying themselves as intended, or that code has or has not made a copy of an object - I lost a few hours this weekend over a glorified version of just that question :( Found it :) Literals can sometimes be confusing, being identical (courtesy of the compiler) when one might otherwise think they should be distinct but equal objects. As for whether a string and a symbol should have the same address, I am not convinced they would, but a good exercise for your students would be to make a C function that prints on stdout and/or returns the address of something passed to it, and then call it with both 'hello' and 'hello' asSymbol, #hello, etc. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Monday, September 27, 2010 5:28 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] ('a' == 'a') == true ? On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 Sep 2010, at 10:38, Lukas Renggli wrote: > >>> Am I wrong? >> >> Yes, almost always one should probably use #= instead of #==. > > I will add that to the exercise :-) > The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) > I think you can avoid using 'equal' word when describing a #== comparison. It can be explained as 'test whether comparands are same object or not' while #= is test whether two objects equal or not. Also keep in mind that #== optimized by compiler. So , even if you override it in some class, it won't behave differently. And #=, of course, can be implemented in any way you like. One of interesting example: = anObject ^ false saying 'i am not equal to anything' :) > Johan > _______________________________________________ > 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

Sept. 27, 2010