- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Feature request for Opal
by StÃ©phane Ducasse Sept. 29, 2010

Sept. 29, 2010

Thanks! Marcus was fast on this one. Already in the box :) On Sep 29, 2010, at 8:34 AM, Lukas Renggli wrote: > Ok, the change was rather trivial, most of the functionality was still there. > > I committed > > Name: Compiler-LukasRenggli.242 > Author: lr > Time: 29 September 2010, 8:29:05 am > UUID: 5e237cdd-b72f-44ae-a6c9-402623dfb670 > Ancestors: Compiler-MarcusDenker.241 > > - use pragmas to make primitives extensible > > to the Pharo inbox and the issue tracker > (http://code.google.com/p/pharo/issues/detail?id=3014) Image > recompiles without problems. Same tests fail as before. > > For the other Smalltalk that use the same infrastructure I've attached > a change-set. > > Lukas > > On 28 September 2010 18:29, Lukas Renggli <renggli(a)gmail.com> wrote: >> Thanks Eliot, I will look into it. I should have some time this week. >> >> Lukas >> >> 2010/9/28 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> Hi Lukas, >>> >>> On Tue, Sep 28, 2010 at 12:46 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> >>>> What you ask for was present in my original pragma implementation. The >>>> compiler dispatched pragmas that were declared as compiler pragmas >>>> (using pragmas and thus extensible) to the compiler. >>>> >>>> That mechanism got lost with the closure changes to the compiler. It >>>> should be relatively easy to re-integrate again. >>> >>> Please do. This is the way it should be done and I'm sure would be very >>> nice to use. It would give me pleasure to review the code. >>>> >>>> I never bother to do so, because the mechanism was never adopted by >>>> the only potential client at that time as the author didn't like >>>> pragmas and preferred to patch the compiler :-) >>>> >>>> Lukas >>> >>> best >>> Eliot >>> >>>> >>>> -- >>>> Lukas Renggli >>>> www.lukas-renggli.ch >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > <3014-UsePragmasForExtensiblePrimitives.1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] ('a' == 'a') == true ?
by StÃ©phane Ducasse Sept. 29, 2010

Sept. 29, 2010

+1 discussions are important because they spread knowledge. Stef >> 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] How to subclass Process and have it used by spawned blocks?
by Stefan Marr Sept. 29, 2010

Sept. 29, 2010

Hi: The naive approach of subclassing Process and writing my own fork/spawn does not seem to work for some reason. I tried: Erlang>>spawn: aBlock "Answer an ErlProcess running the code given in the parameter. The process is scheduled." | proc | proc := ErlProcess forContext: [aBlock value. Processor terminateActive] asContext priority: Processor activePriority. proc resume. ^ proc This is basically what happens in BlockClosure newProcess. However, since I do not want to modify BlockClosure, it is not operating on self anymore ('self value' became 'aBlock value', which seems to pose a problem. For some reason, the created process crashes on accessing aBlock, were I would expect it to be available since the block is a closure, right? Looks to me like asContext is doing something I would have to replicate, too. Has someone done something similar before? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

1 0

[Pharo-project] [update 1.2] #12153
by Marcus Denker Sept. 29, 2010

Sept. 29, 2010

12153 ----- Issue 3014: Use pragmas to make primitives extensible Issue 3013: SystemVersion deprecate #version: -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Feature request for Opal
by Igor Stasenko Sept. 29, 2010

Sept. 29, 2010

I want an API for easy plugging in an arbitrary pragma handler, which could then either completely intercept parser/compiler output or modify output. This is userful for things like clean implementation of FFI pragmas, without patching the Parser as well as for scenarios like: myMethod: myArg <myLanguage> foo|<bar**baz so, once pragma <myLanguage> parsed, and handled, an input source stream redirected to completely different parser/compier pair which, of course, should produce a compiled method as a result, but may use any syntax. -- Best regards, Igor Stasenko AKA sig.

4 5

Re: [Pharo-project] After loading a package...all changes with "revision changed"
by StÃ©phane Ducasse Sept. 29, 2010

Sept. 29, 2010

it would be nice to have a simple case that we can reproduce. Stef On Sep 27, 2010, at 10:42 PM, Mariano Martinez Peck wrote: > > > 2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > We had a similar problem in squeaknos package, but just for some kind of classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers. > > > Thanks. It is good to know I am not the only one. This bug is REAAAAALY annoying since you cannot see your changes. > > I've checked and I have no #initialize at class level :( > > The only thing I found is class side #new implementd something like: > > new > > ^super new initialize. > > can this be the problem? > > where could I put a halt to see the problem ? > > thanks in advance > > mariano > > > regards, > javier. > > 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > > FYI I encountered the same problem in gemstone. The only thing I know is that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it. > > Norbert > > > Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >> >> > Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed. >> > >> > To reproduce: >> > >> > - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX >> > - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :) >> >> May be the image used to save the package got a problem and changed the timestamp of the methods. >> So when you merge you get changed methods. >> >> I've just tried commiting and load them in a clean image...same problem. >> >> And if it were what you say...is there a solution? >> >> thanks >> >> mariano >> >> >> > >> > Any help is really appreaciated. >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > 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 >> >> _______________________________________________ >> 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 > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > > _______________________________________________ > 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

2 1

[Pharo-project] [update 1.2] #12152
by Marcus Denker Sept. 28, 2010

Sept. 28, 2010

12152 ----- Issue 3000: StandardFileStream >> recategorization of browser plugin supporting methods Issue 2952: Shift-selection in new TextEditor Issue 2947: SmalltalkEditor doent handle ESC key Issue 2553: SystemVersion lost its state in 1.2 -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-project] Settings for Shout syntax highlighting
by Simon Denier Sept. 28, 2010

Sept. 28, 2010

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

1 0

[Pharo-project] Settings for Shout syntax highlighting
by Simon Denier Sept. 28, 2010

Sept. 28, 2010

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

5 7

Re: [Pharo-project] pharo sprint at lille
by Marcus Denker Sept. 28, 2010

Sept. 28, 2010

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.

1 0