- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3401 in pharo: Comparison of Urls is not possible yet

by pharo＠googlecode.com

Status: Accepted Owner: cdrick65 Labels: Type-RequestForEnhancement New issue 3401 by cdrick65: Comparison of Urls is not possible yet http://code.google.com/p/pharo/issues/detail?id=3401 Pharo image: 1.1 dev Pharo core version: 11414 Virtual machine used: cog osx not possible to compare url's 'http://www.pharo-project.org' asUrl = 'http://www.pharo-project.org' asUrl. => false (i know asUrl is deprecated but... shorter ;) ) I actually copy/pasted = and hash from URI (common superclass ? traits ?) I also made a test for urls. if yes, is the following proposition enough ? or should it be more precise according to each subclass ? See you 'http://www.pharo-project.org' asUrl = 'http://www.pharo-project.org' asUrl. => false What about having: Url>> = anotherUrl ^self asText = anotherUrl asText Paste or attach stack trace if applicable (look at the file PharoDebug.log located in the same directory as your image): Attachments: Url-comparing.st 414 bytes UrlTest-testUrlComparison.st 733 bytes

Dec. 11, 2010

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

by Mariano Martinez Peck

This is awesome. Not only for the Pharo point of view, but it means that an important institute like INRIA has really interest in Pharo, and this is so cool. Adrian, we should post it in the pharo blog. Cheers Mariano On Sat, Dec 11, 2010 at 10:46 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> 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 > > > >

Dec. 11, 2010

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

by Oscar Nierstrasz

+1 !!! On 11 Dec 2010, at 10: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 > > >

Dec. 11, 2010

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

by Tudor Girba

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. > 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? > 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 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. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."

Dec. 11, 2010

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

by Tudor Girba

Great :) Doru On 11 Dec 2010, at 10:53, StÃ©phane Ducasse wrote: > since nobody replied I send again this mail. > We should plan that for 1.3 > > Stef > > >> Hi guys >> >> yesterday on the irc we got a discussion on the dependency introduced when using HelpSystem. >> Some proposed to used pragmas like in settings since they work well for setting and we can also browse help >> with implementors. >> >> Torsten do you have a word to say before we start to implement this solution? >> >> Stef > > -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef."

Dec. 11, 2010

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

by Mariano Martinez Peck

or maybe you can subscribe/unsubscribe...but anyway, changing the subscription type should work :( On Sat, Dec 11, 2010 at 11:34 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Dec 11, 2010 at 2:31 AM, Chip Nowacek <chip(a)nowacek.net> 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? >> >> > did you check spam? maybe it went there.... >

Dec. 11, 2010

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

by Mariano Martinez Peck

On Sat, Dec 11, 2010 at 2:31 AM, Chip Nowacek <chip(a)nowacek.net> 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? > > did you check spam? maybe it went there....

Dec. 11, 2010

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

by StÃ©phane Ducasse

since nobody replied I send again this mail. We should plan that for 1.3 Stef > Hi guys > > yesterday on the irc we got a discussion on the dependency introduced when using HelpSystem. > Some proposed to used pragmas like in settings since they work well for setting and we can also browse help > with implementors. > > Torsten do you have a word to say before we start to implement this solution? > > Stef

Dec. 11, 2010

[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