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

Re: [Pharo-project] Settings for Shout syntax highlighting

by Simon Denier

On 28 sept. 2010, at 23:08, Mariano Martinez Peck wrote: > Simon, we could review/integrate this during the Sprint on Friday Unfortunately I will be on the road Friday. Anyway it's already integrated in the squeaksource repo. > > 2010/9/14 Simon Denier <Simon.Denier(a)inria.fr> > Following some hints from Alain, a new version (it just removes a method extension) > > Settings-Shout-simon_denier.2 > in PharoInbox > > > On 13 sept. 2010, at 11:00, Simon Denier wrote: > >> Hi >> >> A new package Settings-Shout in the Pharo Inbox for issue 1611 >> >> SLICE-Issue-1611-ShoutSettings-simon_denier.1 >> >> You can now set how (for example), instance variables, selector patterns, class references appears in the Shout pane. >> One point is that Shout comes with a list of hundred token types which can be individually customized, some of which I have no idea what they represent (externalCallTypePointerIndicator?). To keep things manageable, I defined some groups of logically related token types (like the gorup 'selector patterns' for token types patternKeyword, patternBinary, patternUnary). >> >> "Class SHGroupStyle manages settings for the Shout syntax highlighting. Token types are organized in logical groups which will share the same style. Currently, only color and emphasis can be edited through Shout settings. Text font and size are managed through the more general appearance setting. Changing a style setting on a SHGroupStyle automatically applies the style. >> >> Groups are defined in the class-side method initializeGroups. Alternatively, one can set its own style table using Shout tokens by calling #customStyleTable (see SHTextStylerST80 class>>defaultStyleTable for the format)." >> >> >> Help needed: >> 1) code review >> 2) review group definition, because I made some groups based partly on my intuition, partly on styling difference in the current difference: there may be a better partition of token types. >> 3) review description for group, setting organization... >> >> >> Thanks to Alain for helping with settings and especially polymorph widgets. >> >> -- >> Simon >> >> >> > > -- > Simon > > > > > _______________________________________________ > 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. 28, 2010

[Pharo-project] Calling Python from Pharo

by Alberto Bacchelli

Hi, Is there any way to make Pharo and Python communicate? Thanks, Alberto

Sept. 28, 2010

Re: [Pharo-project] Metacello Configuration Browser?

by Simon Denier

On 28 sept. 2010, at 21:30, Mariano Martinez Peck wrote: > What I would love is a UI for GoferProjectLoader from Esteban. I mean, we have the apt-get but we need now synaptic :) > > And....if we plan to do what I say in the email about Pharo and Metacello, having something like that is very, VERY useful. From my point of view, even more than a Metacello browser. That's too different usages, which are complementary: GoferProjectLoader is for end-users, while I'm thinking more of a browser for developers, when they have to create a new release and check there configuration is consistent. Right now it's quite a pain, ask Jannik who did the 4.1 Moose :) > > Cheers > > Mariano > > 2010/9/28 Simon Denier <Simon.Denier(a)inria.fr> > > On 28 sept. 2010, at 15:14, Guillermo Polito wrote: > >> Okok, I saw there already exists a Configuration browser :P. But it can be reaally improved. > > > Which one are you talking about? The one in 1.2? Or on Squeaksource? > > There have been multiple efforts (GTMetaceller, MooseDevBrowser...) already to try and see what we would like to do in a browser. But there are also some performance issues with Metacello right now, which makes it impractical to browser config. which Dale and Alex have started to tackle them. > > Anyway, the latest effort (started during ESUG) is there: it is basically a rewrite of what have been done in the tools above (with still some missing parts). > > MCHttpRepository > location: 'http://www.squeaksource.com/MetacelloBrowser' > user: '' > password: '' > > > Note, it requires Glamour and is more of a testbed than a fully-supported tool for now. > > > >> >> On Tue, Sep 28, 2010 at 10:00 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> I'm always reading people saying that metacello configurations are some kind of... overdesign. So, maybe we need a tool (or to modify monticello browser) wich allow us to: >> >> - know wich packages are core and dev. Sometimes using a dev image, I write things depending on Dev packages and I don't realize it. >> - create automatically or propose configurations depending on the actual state of the packages. >> - browse configurations nicely :). It's a new concept, we need a nice tool to support it. >> >> Maybe if the configs are easily created, we can have more of them, and we will be no longer so lazy. >> >> Cheers, >> Guille >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Simon > > > > > _______________________________________________ > 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. 28, 2010

Re: [Pharo-project] Settings for Shout syntax highlighting

by Mariano Martinez Peck

Simon, we could review/integrate this during the Sprint on Friday 2010/9/14 Simon Denier <Simon.Denier(a)inria.fr> > Following some hints from Alain, a new version (it just removes a method > extension) > > Settings-Shout-simon_denier.2 > in PharoInbox > > > On 13 sept. 2010, at 11:00, Simon Denier wrote: > > Hi > > A new package Settings-Shout in the Pharo Inbox for issue 1611<http://code.google.com/p/pharo/issues/detail?id=1611> > > SLICE-Issue-1611-ShoutSettings-simon_denier.1 > > You can now set how (for example), instance variables, selector patterns, > class references appears in the Shout pane. > One point is that Shout comes with a list of hundred token types which can > be individually customized, some of which I have no idea what they represent > (externalCallTypePointerIndicator?). To keep things manageable, I defined > some groups of logically related token types (like the gorup 'selector > patterns' for token types patternKeyword, patternBinary, patternUnary). > > "Class SHGroupStyle manages settings for the Shout syntax highlighting. > Token types are organized in logical groups which will share the same style. > Currently, only color and emphasis can be edited through Shout settings. > Text font and size are managed through the more general appearance setting. > Changing a style setting on a SHGroupStyle automatically applies the style. > > Groups are defined in the class-side method initializeGroups. > Alternatively, one can set its own style table using Shout tokens by calling > #customStyleTable (see SHTextStylerST80 class>>defaultStyleTable for the > format)." > > > Help needed: > 1) code review > 2) review group definition, because I made some groups based partly on my > intuition, partly on styling difference in the current difference: there may > be a better partition of token types. > 3) review description for group, setting organization... > > > Thanks to Alain for helping with settings and especially polymorph widgets. > > -- > Simon > > > > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 28, 2010

Re: [Pharo-project] pharo sprint at lille

by Marcus Denker

On Sep 28, 2010, at 10:44 PM, Johan Brichau wrote: > Did you guys move? > No... even though it gets very crowded at the RMOD office (which is in the LIFL building of the university: http://www.lifl.fr/ ) We have to wait until the new INRIA building is constructed before moving. And that will take a while. At least there is now a sign at the construction site. That's a start. (the new building will be just accross the street of the current INRIA building) Marcus > On 28 Sep 2010, at 21:42, Marcus Denker wrote: > >> >> On Sep 28, 2010, at 9:31 PM, Mariano Martinez Peck wrote: >> >>> Does someone know how to go there? which metro station is better? google map ? >>> >> It's in the main INRIA building. >> >> http://www.inria.fr/lille/CRI-en/Howtogetthere >> >> This is just "behind" the university campus in a science/industry campus ("Parc Scientifique de la Haute Borne") >> >> Best station is "4 Cantons" (the last one). >> >> From the station, walk along the tracks of the metro (the one where the metro >> car goes empty) until the big street. The go to the left along the street. >> After the CNRS IRCICA building you will see the INRIA building. (see map). >> >>> what time does it start? >>> >> >> I guess someone will be there at 9:00... or even earlier if needed. >> >>> thanks >>> >>> mariano >>> >>> >>> 2010/9/28 stephane ducasse <stephane.ducasse(a)free.fr> >>> Hi guys >>> >>> I reserved a nice room for the sprint it is in the inria building. salle du conseil. >>> We will code like crazy :) >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> _______________________________________________ >> 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 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Sept. 28, 2010

Re: [Pharo-project] pharo sprint at lille

by Johan Brichau

Did you guys move? On 28 Sep 2010, at 21:42, Marcus Denker wrote: > > On Sep 28, 2010, at 9:31 PM, Mariano Martinez Peck wrote: > >> Does someone know how to go there? which metro station is better? google map ? >> > It's in the main INRIA building. > > http://www.inria.fr/lille/CRI-en/Howtogetthere > > This is just "behind" the university campus in a science/industry campus ("Parc Scientifique de la Haute Borne") > > Best station is "4 Cantons" (the last one). > > From the station, walk along the tracks of the metro (the one where the metro > car goes empty) until the big street. The go to the left along the street. > After the CNRS IRCICA building you will see the INRIA building. (see map). > >> what time does it start? >> > > I guess someone will be there at 9:00... or even earlier if needed. > >> thanks >> >> mariano >> >> >> 2010/9/28 stephane ducasse <stephane.ducasse(a)free.fr> >> Hi guys >> >> I reserved a nice room for the sprint it is in the inria building. salle du conseil. >> We will code like crazy :) >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2010

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

by StÃ©phane Ducasse

On Sep 28, 2010, at 4:39 PM, Johan Brichau wrote: > Perhaps the discussion I wanted to raise is not about the use of '==' but about the fact that equal string literals in the same method body are optimized to be the same object. > Without immutability, such optimization is just plain wrong. In addition, it does not even seem to be a particularly useful optimization. Yes this is true. :) We will fix it with Opal. Stef > > The use of '==' in the exercise is exactly about the reflective semantics, btw. > > Johan > > On 28 Sep 2010, at 10:05, Niko Schwarz wrote: > >> But that's the point, there should be no business semantics to '=='. >> Only reflective semantics. The reflective semantics are ok. >> >> Niko >> >> On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <johan(a)inceptive.be> 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). >>> >>> 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 >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> 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. 28, 2010

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

by Johan Brichau

On 28 Sep 2010, at 18:00, Eliot Miranda wrote: > I think it's orthogonal to immutability. Non-immutable literals are "just plain wrong" (actually unsafe). The optimization is confusing and unexpected to the inexperienced. But I emphatically agree with the last part; it's not a particularly useful optimization. Of course, you are right: non-immutable literals are unsafe. However, when you know what you are doing and you are 'mutating' a literal in your code, I think it's surprising that the mutation also happens to what seems to be another literal in the same code (because they are written in different locations in the same method body), just because they happen to be equal. Admittedly, it's not a common issue and mutating literals might sound like dirty code (it probably is in 99% of the cases) but the flexibility also enables powerful things. I have, for example, used that in the implementation of the compiled methods for proxy java classes in JavaConnect. Anyway, I appreciate the discussion! Johan

Sept. 28, 2010

Re: [Pharo-project] [Pharo-Project] Issue 3010 and 3011. Debugger's Create button does not work when doing StepInto and StepOver

by StÃ©phane Ducasse

Thanks! Stef On Sep 28, 2010, at 6:42 PM, Hernan Wilkinson wrote: > Hi, I opened two errors: > > 3010: Create button of debugger does not appear when doing step into and step over > 3011: Create button fails when the doesNotUnderstand: context is not selected > > I uploaded the fixes to PharoInbox with slice: SLICE-Issue-3010-CreateButtonWorksWithStepIntoAndStepOver-HernanWilkinson.2 > > Bye, > Hernan > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2010

[Pharo-project] Problem with Proxies, objects and MethoDict

by Mariano Martinez Peck

Hi folks. I am trying to do something and I found a VM crash. Suppose I want to swap out a class, do a become with a proxy (that with the DNU will load the class back). In addition, I have instances of the swapped class. Example of code (will crash in the last line): o := MyObject new. o foo: 123. p := ClassProxy new. p become: MyObject. o == nil. o foo. My Object just extends Object, has an instVar 'foo', and implements the accessors. ClassProxy implements: become: aClass className := aClass name. aClass fileOut. super become: aClass and doesNotUnderstand: aMessage | reloadedClass | (FileStream fileNamed: className, '.st') fileIn. reloadedClass := Smalltalk at: className. self becomeForward: reloadedClass. ^aMessage sendTo: reloadedClass So....does someone know why the crash? how can I solve it ? Thanks in advance Mariano

Sept. 28, 2010