- Pharo-dev - lists.pharo.org

Re: [Pharo-project] good news of the year

by csrabak＠bol.com.br

Yes! +1! Em 11/12/2010 16:04, Igor Stasenko < siguctua(a)gmail.com > escreveu: On 11 December 2010 18:57, StÃ©phane Ducasse wrote: > > On Dec 11, 2010, at 6:40 PM, Igor Stasenko wrote: > >> Thanks everyone. >> >> I had very warm and friendly greeting here in Lille. And atmosphere is >> very cool (everyone around you using pharo). >> I am a full of enthusiasm and energy to put in Pharo, as never before. ;) > > ;) > excellent! > and I will make more time to pair program :) > :) Oh, i think we missed on VERY important thing we should also pay attention: good internationalization support throughout all the system layers, which includes: - input/output - locales > Stef > > -- Best regards, Igor Stasenko AKA sig.

Dec. 11, 2010

Re: [Pharo-project] About using pragma for help like in setting

by Sean P. DeNigris

I'm trying to wrap my mind around the issue... StÃ©phane Ducasse wrote: > > yesterday on the irc we got a discussion on the dependency introduced when > using HelpSystem. > On the chat, it seemed that the main objection was depending on an external class. Since HelpSystem is now part of core, what is the problem there? Isn't it just like Tests depending on TestCase? StÃ©phane Ducasse wrote: > > Some proposed to used pragmas... and we can also browse help with > implementors. > Again, if HelpSystem is in core, how does it help to browse with implementors? Sean -- View this message in context: http://forum.world.st/About-using-pragma-for-help-like-in-setting-tp3078978… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 11, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Veronica Isabel Uquillas Gomez

Hi, this is valuable info... Thank you!! On 11 Dec 2010, at 04:17, Yanni Chiu wrote: > On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: >> Dear all, >> >> I am currently working on the *Ring*, an unifying and foundational model >> infrastructure for Pharo. >> The goals are: >> - Provide a common API at structural and runtime level >> - Allow tools to interact and integrate directly with the host >> environment (Pharo) >> - Support history analysis >> >> I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, >> Smalltalk itself and Ginsu, as a basic to build the Ring. >> So far I have implemented the main classes including the ones that >> should replace MethodReference and the Pseudo classes. >> >> An unified API will imply changes in most of the ones mentioned above >> (as most of them are non-polymorphic). >> As a first step, I would like to have your opinion about the proposal >> for replacing MethodReference (attached file). > > I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names. > > Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like. > > The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta. > > classSymbol --> className - yes > methodSymbol --> selector - yes > > sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used. > > source --> formattedSource - yes > > stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name > > I don't understand the talk about methodClass, objectClass, variableClass, commentClass. > > Hope that helps. > >

Dec. 11, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Veronica Isabel Uquillas Gomez

On 11 Dec 2010, at 10:33, StÃ©phane Ducasse wrote: > > On Dec 11, 2010, at 6:47 AM, Francisco Ortiz PeÃ±aloza wrote: > >> hi, i really like the idea, quite a challenge :) >> >> But since you ask for our opinion I really dont like some of the methods' names specially the ones using "the" as prefix. > > what is the alternative? > class? #itsClass #parentClass (suggested by Tudor) > No it does not work > (Point>>#x) class -> CompiledMethod > and we want > (Point>>#x) theClass -> Point > > > (Point>>#x) asMethodDefinition class -> MethodDefinition > and we want > (Point>>#x) asMethodDefinition theClass -> aClassDefinition for Point > > >> >> Regards, >> Francisco >> >> On Sat, Dec 11, 2010 at 1:17 AM, Yanni Chiu <yanni(a)rogers.com> wrote: >> On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: >> Dear all, >> >> I am currently working on the *Ring*, an unifying and foundational model >> infrastructure for Pharo. >> The goals are: >> - Provide a common API at structural and runtime level >> - Allow tools to interact and integrate directly with the host >> environment (Pharo) >> - Support history analysis >> >> I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, >> Smalltalk itself and Ginsu, as a basic to build the Ring. >> So far I have implemented the main classes including the ones that >> should replace MethodReference and the Pseudo classes. >> >> An unified API will imply changes in most of the ones mentioned above >> (as most of them are non-polymorphic). >> As a first step, I would like to have your opinion about the proposal >> for replacing MethodReference (attached file). >> >> I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names. >> >> Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like. >> >> The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta. >> >> classSymbol --> className - yes >> methodSymbol --> selector - yes >> >> sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used. >> >> source --> formattedSource - yes >> >> stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name >> >> I don't understand the talk about methodClass, objectClass, variableClass, commentClass. >> >> Hope that helps. >> >> >> > >

Dec. 11, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Veronica Isabel Uquillas Gomez

Hi, On 11 Dec 2010, at 12:24, Tudor Girba wrote: > Hi, > > Nice initiative. I added my comments below. > > On 11 Dec 2010, at 04:17, Yanni Chiu wrote: > >> On 10/12/10 8:32 AM, Veronica Isabel Uquillas Gomez wrote: >>> Dear all, >>> >>> I am currently working on the *Ring*, an unifying and foundational model >>> infrastructure for Pharo. >>> The goals are: >>> - Provide a common API at structural and runtime level >>> - Allow tools to interact and integrate directly with the host >>> environment (Pharo) >>> - Support history analysis >>> >>> I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, >>> Smalltalk itself and Ginsu, as a basic to build the Ring. >>> So far I have implemented the main classes including the ones that >>> should replace MethodReference and the Pseudo classes. >>> >>> An unified API will imply changes in most of the ones mentioned above >>> (as most of them are non-polymorphic). >>> As a first step, I would like to have your opinion about the proposal >>> for replacing MethodReference (attached file). >> >> I'm not clear on what "Ring" is going to be, and I've looked at MethodReference for the first time, just now. Coming up with the names for things is a big part of creating an object information model (i.e. analysis model). The context of how ORCompiledMethodDefinition fits into the overall model would help to figure out the names. >> >> Generally, I use "theSomething" as a last resort. And, typically it's for a temp var or method argument - rarely, if ever, for an object attribute (a.k.a. instVar). So, actualClass --> theClass, is a don't like. > > I would suggest parentClass. I have an alternative #itsClass, but #parentClass is a good suggestion. > >> The method definition is neither meta nor non-meta - the associated class can be meta. Suppose the meta-class hierarchy were eliminated, should the method definition still make sense in that scenario. I think classIsMeta is more clear than isMeta. > > In Moose we have isMetaSide / isInstanceSide. > >> classSymbol --> className - yes >> methodSymbol --> selector - yes >> >> sourceString, sourceCode --> source - no, why not keep sourceCode, and avoid the confusion of redefining "source". Or, maybe rawSource and formattedSource could be used. > > I also agree that sourceCode is better. > >> source --> formattedSource - yes >> >> stringVersion --> fullName - not sure, but if there's version info in the name, I think "version" should be used in the name > > #fullName implies that you will get a meaningful name, but the version is not part of the name. > > But, why do we actually need this stringVersion method? Why not have a #timestamp method instead, and then use that when you want to print the information? No version or time info is kept in stringVersion.. This name is completely wrong. > >> I don't understand the talk about methodClass, objectClass, variableClass, commentClass. > > I would rename is #methodClass to #parentClass. I would keep or rename the followings: > #methodReference -> #reference > #methodNode -> #node > Like the idea.. > As for #methodClassAssociation:, I think it is better to keep it like it is, but my question is why do we actually need this ugly method. > A compilation process defined in Behavior is using it.. Maybe I will change it and remove #methodClassAssociation > Cheers, > Doru > > Thanks :) > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > >

Dec. 11, 2010

Re: [Pharo-project] good news of the year

by Igor Stasenko

On 11 December 2010 18:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 11, 2010, at 6:40 PM, Igor Stasenko wrote: > >> Thanks everyone. >> >> I had very warm and friendly greeting here in Lille. And atmosphere is >> very cool (everyone around you using pharo). >> I am a full of enthusiasm and energy to put in Pharo, as never before. ;) > > ;) > excellent! > and I will make more time to pair program :) > :) Oh, i think we missed on VERY important thing we should also pay attention: good internationalization support throughout all the system layers, which includes: - input/output - locales > Stef > > -- Best regards, Igor Stasenko AKA sig.

Dec. 11, 2010

Re: [Pharo-project] Issue 3396 in pharo: System Change Notification broken

by pharo＠googlecode.com

Comment #6 on issue 3396 by stephane.ducasse: System Change Notification broken http://code.google.com/p/pharo/issues/detail?id=3396 Strange. Thanks lukas. Cyrille is working on RPackage and we will see normally we should be able to emit announcement in parallel and rethink a bit everything but it will shake the system once more.

Dec. 11, 2010

Re: [Pharo-project] good news of the year

by Alexandre Bergel

Really cool! Alexandre On 11 Dec 2010, at 06:46, StÃ©phane Ducasse wrote: > Hi all > > We have a really good news for pharo. Igor got a job as engineer in our team for two years. > We are really thankful to INRIA for that. Since we want to be transparent here is the way we plan to work. > We asked igor to help fixing bug fixes for about 20% of his time. > And to focus on larger items. Here is a list based on the brainstorming we did and what we told INRIA > igor would do. > Now if you want to help and join effort with us this is even better. > > Now igor started to work on OPAL because we would like to have it for a beta in january, when we will get a new unstable > stream. > > Stef > > -- Set nil > -- Hashed Collection > -- dictionary are slower > -- Generalize stream protocol #readInto:startingAt:count: > > -- WeakStructure > -- Finalizer > -- Chapter on Finalizer > > -- Better integration process > > -- EventSensor > polling > - publish a windows VM that support it > > -- ClassBuilder rewrite > > -- Helping improving the VM > - cleaner code > > -- Cleaning events/annoucement > check CUIS > on:send: > changed:/update > > -- SystemChangeNotification -> announcement > sync with Cyrille > review with Cyrille > > -- Using RPackage in Monticello > sync with cyrille > > -- iSqueak New event hierarchy > Alain imported that > Multitouch? > > -- New compiler > -- debug > -- Decompiler IR -> AST > -- Cleanups > -- API > -- Environment > > -- ROME API > - API stablisation: openVG > - system rewrite to use API > > -- Ephemerons ?? > > -- Announcement with weak structure > > -- Networks > - may be use WeakFinalizer here. > - looking at Andreas fixes in Squeak > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 11, 2010

[Pharo-project] [update 1.2] #12276

by StÃ©phane Ducasse

12276 ----- - Issue 1213: Unable to type some czech characters. Thanks George Herolyant - Issue 3390: SimpleMorphic in core. Thanks ESUG. I started to fix it to make sure that we can load it with MC and added a class for general comments. More to come.... we should close all these 1.2 bug entries and start having fun with 1.3 unstable :)

Dec. 11, 2010

Re: [Pharo-project] Issue 3283 in pharo: Symbol dependent on Scanner

by pharo＠googlecode.com

Updates: Summary: Symbol dependent on Scanner Comment #9 on issue 3283 by stephane.ducasse: Symbol dependent on Scanner http://code.google.com/p/pharo/issues/detail?id=3283 (No comment was entered for this change.)

Dec. 11, 2010