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

[Pharo-project] ctlr-C in code.google.... gets on my nerves

by StÃ©phane Ducasse

Hi apparently the ctrl-C behavior has changed on the bug tracker. Does anybody know how to control that it just copy and paste and do not create a new issue? Stef

Dec. 11, 2010

Re: [Pharo-project] Issue 3400 in pharo: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable

by pharo＠googlecode.com

Comment #2 on issue 3400 by stephane.ducasse: doubled '.' at end of line in RxParserTest>>#test and #testTranlsatingMatchesUsing not portable http://code.google.com/p/pharo/issues/detail?id=3400 Dale this is strange I could not merge your file because the system does not find Regex-Tests-Core-StephaneDucasse.2 but it is in pharo/. Anyway I redid your modifications by hand.

Dec. 11, 2010

[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