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

[Pharo-project] good news of the year

by StÃ©phane Ducasse

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

Dec. 11, 2010

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

by StÃ©phane Ducasse

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? 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 StÃ©phane Ducasse

> > I don't understand the talk about methodClass, objectClass, variableClass, commentClass. the idea is that RING represents source code entities: methodDefinition, classDefinition, ... not the object actually running but to have an API that is the same for runtime and declarative entities so that all the tools can work on representation and runtime entities. Veronica is proposing (and I like that to have always a systematic way to accessible the entity) aMethodDefinition theClass versus aMethodDefinition actualClass for everybody But more important right now in CompiledMethod we have compiledMethod>>methodClass this convention is not really good since we do not have a polymorphic message: following this pattern we would end up with methodClass, variableClass, packageClass and we would have to always test so she propose to have theClass aCompiledMethod theClass will return the class of the compiledMethod (Point>>#x:) theClass -> Point But also that aMethodDefinition theClass returns the Class represented by aMethodDefinition className And by convention aVariable theClass .... May be this is not 100% exact because I'm hurry but this is the idea: having a polymorphic way to access parent.

Dec. 11, 2010

Re: [Pharo-project] the struggling newbie about the OB Package Browser comment issue

by StÃ©phane Ducasse

describe how you get this error? Else we cannot help. Stef On Dec 11, 2010, at 2:31 AM, Chip Nowacek wrote: > Thanks for your help. Because of it, I've found a couple ways around the issue. Far more important is knowing there are folks out there.I hope to be useful to the community as I gain experience. Pharo is cool - and I am grateful Squeak has strong shoulders upon which Pharo can stand. > > Thanks again. > > PS I didn't respond directly to your responses because I signed up for the digest form of the list. Now that I want to change it from that subscription type, I can't seem to get into the list to modify my account > Error: Authentication failed. > > which is strange because I just created the account yesterday and know the password. Well, on the assumption I'm that stupid, I asked the list to send me my password. I haven't received it after asking twice. Who should I contact or should I just create another account? >

Dec. 11, 2010

Re: [Pharo-project] Issue 2353 in pharo: #findString:startingAt:caseSensitive: broken for WideStrings

by pharo＠googlecode.com

Updates: Status: Accepted Cc: siguctua Comment #6 on issue 2353 by stephane.ducasse: #findString:startingAt:caseSensitive: broken for WideStrings http://code.google.com/p/pharo/issues/detail?id=2353 Igor it would be nice if you could have a look in the coming month.

Dec. 11, 2010

Re: [Pharo-project] Ideas for HelpSystem

by Sven Van Caekenberghe

On 11 Dec 2010, at 00:18, Bernardo Ezequiel Contreras wrote: > here's a similar example > > http://soek.goodies.st.s3.amazonaws.com/index.html Very nice indeed. Never heard of the Cloudfork project, I am reading now... Sven

Dec. 11, 2010

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

by Francisco Ortiz PeÃ±aloza

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. 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 Yanni Chiu

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

[Pharo-project] the struggling newbie about the OB Package Browser comment issue

by Chip Nowacek

Thanks for your help. Because of it, I've found a couple ways around the issue. Far more important is knowing there are folks out there.I hope to be useful to the community as I gain experience. Pharo is cool - and I am grateful Squeak has strong shoulders upon which Pharo can stand. Thanks again. PS I didn't respond directly to your responses because I signed up for the digest form of the list. Now that I want to change it from that subscription type, I can't seem to get into the list to modify my account *Error: **Authentication failed.*which is strange because I just created the account yesterday and know the password. Well, on the assumption I'm that stupid, I asked the list to send me my password. I haven't received it after asking twice. Who should I contact or should I just create another account?

Dec. 11, 2010

Re: [Pharo-project] Ideas for HelpSystem

by Bernardo Ezequiel Contreras

here's a similar example http://soek.goodies.st.s3.amazonaws.com/index.html

Dec. 10, 2010