February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue #112: Enhanced colors

by StÃ©phane Ducasse

you know one is check licensing status so it is an autofilling one :) But add report and cs :) to other issues. Stef On Feb 28, 2009, at 11:16 AM, Igor Stasenko wrote: > 2009/2/28 Adrian Lienhard <adi(a)netstyle.ch>: >> ok, I changed the status of the report to WontFix. >> >> Adrian >> >> BTW, 30 issues left for Pharo 1.0 >> > You must be kidding! > Want me to add some more? :) > >> On Feb 28, 2009, at 02:19 , Igor Stasenko wrote: >> >>> +1 to package >>> >>> 2009/2/28 Rob Rothwell <r.j.rothwell(a)gmail.com>: >>>> I kind of like that Package idea...although I have years of >>>> QBColor(13) to >>>> overcome...! >>>> >>>> On Fri, Feb 27, 2009 at 9:18 AM, StÃ©phane Ducasse >>>> <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>> http://code.google.com/p/pharo/issues/detail?id=112 >>>>>> >>>>>> Who thinks that we should add these colors? These are more than >>>>>> 100 >>>>>> additional named colors like #paleGoldenrod, #mediumOrchid, >>>>>> #thistle, >>>>>> etc. >>>>>> >>>>>> I'd vote against adding them since I don't see their merit. >>>>>> >>>>>> Other opinions? >>>>> >>>>> we could keep them as a package. >>>>> Having colors is useful for us >>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> Adrian >>>>>> >>>>>> ___________________ >>>>>> http://www.adrian-lienhard.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 >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 28, 2009

Re: [Pharo-project] lisencing

by StÃ©phane Ducasse

thanks !!! Stef On Feb 28, 2009, at 2:58 AM, Matthew Fulmer wrote: > On Fri, Feb 27, 2009 at 10:38:43AM +0100, St?phane Ducasse wrote: >> Ideally we should check that the guy sign the squeak MIT agreement >> but >> this is not clear where this information here to me >> Matthew? do you know? > > The most up-to-date list of ok contributors is at > > http://www.squeaksource.com/311/MethodAuthorship-kph.17.mcz > > See the class-side methods in Authorship, category data > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 28, 2009

[Pharo-project] Sophie rome vs a cairo binding

by StÃ©phane Ducasse

Hi I would like to understand the difference between rome (the package in sophie) and a cairo binding such that one of squeak-GTK. Thanks Stef

Feb. 28, 2009

Re: [Pharo-project] Issue #112: Enhanced colors

by Igor Stasenko

2009/2/28 Adrian Lienhard <adi(a)netstyle.ch>: > ok, I changed the status of the report to WontFix. > > Adrian > > BTW, 30 issues left for Pharo 1.0 > You must be kidding! Want me to add some more? :) > On Feb 28, 2009, at 02:19 , Igor Stasenko wrote: > >> +1 to package >> >> 2009/2/28 Rob Rothwell <r.j.rothwell(a)gmail.com>: >>> I kind of like that Package idea...although I have years of >>> QBColor(13) to >>> overcome...! >>> >>> On Fri, Feb 27, 2009 at 9:18 AM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>> http://code.google.com/p/pharo/issues/detail?id=112 >>>>> >>>>> Who thinks that we should add these colors? These are more than 100 >>>>> additional named colors like #paleGoldenrod, #mediumOrchid, >>>>> #thistle, >>>>> etc. >>>>> >>>>> I'd vote against adding them since I don't see their merit. >>>>> >>>>> Other opinions? >>>> >>>> we could keep them as a package. >>>> Having colors is useful for us >>>> >>>>> >>>>> >>>>> Cheers, >>>>> Adrian >>>>> >>>>> ___________________ >>>>> http://www.adrian-lienhard.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 >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2009

Re: [Pharo-project] Issue #112: Enhanced colors

by Adrian Lienhard

ok, I changed the status of the report to WontFix. Adrian BTW, 30 issues left for Pharo 1.0 On Feb 28, 2009, at 02:19 , Igor Stasenko wrote: > +1 to package > > 2009/2/28 Rob Rothwell <r.j.rothwell(a)gmail.com>: >> I kind of like that Package idea...although I have years of >> QBColor(13) to >> overcome...! >> >> On Fri, Feb 27, 2009 at 9:18 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>>> http://code.google.com/p/pharo/issues/detail?id=112 >>>> >>>> Who thinks that we should add these colors? These are more than 100 >>>> additional named colors like #paleGoldenrod, #mediumOrchid, >>>> #thistle, >>>> etc. >>>> >>>> I'd vote against adding them since I don't see their merit. >>>> >>>> Other opinions? >>> >>> we could keep them as a package. >>> Having colors is useful for us >>> >>>> >>>> >>>> Cheers, >>>> Adrian >>>> >>>> ___________________ >>>> http://www.adrian-lienhard.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 >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2009

Re: [Pharo-project] Text editing (was: Re: Aaah, the pain or ParagraphEditor refactoring)

by Luigi PAnzeri

>> Can you explain where the performance problems are in your approach? At the current state, the problem are the followings: SafarÃ Commands, the user can invoke (e.g. uppercase words, insert char, paste, browse methods, etc.), act on meaningful pieces (ranges) of texts (words, characters, regions, smalltalk parsed expressions, etc.). At every command invokation, parsers rebuild the range database. That is fine and done right, except that in some cases I could use better algorithm (as Lukas said, first make it work, then make it fast) as a lot of simple commands has often only a local effect on the text range database, then not a full rebuild is really needed. Text is presented with different visual properties (foreground colors, underline, right font, etc.), depending on its meaning (syntax highlighting, and more). At a first stage SafarÃ drew character x character, but it was too slow. The problem is that the meaning of the text is stored into ranges that are overlapping, instead I need runs (non overlapping ranges of text) in order to present the text. So I have to implement an algorithm that rebuild and perhaps cache better the run database. I have never really completed to do that, as I stopped to work on it. The work at squeaksource about runs was coded in a sprint made at the last ESUG) Second problem: perhaps it is a bad idea to parse the whole content of the buffer at each command invokation, i.e. user input. Parsing/SyntaxHighLighting stuff should be processed in background. >> And how do you define "too slow"? Too slow to convince me to use it to code SafarÃ itself. It hangs your pc for few seconds on long texts (> 10 lines) on each insertion. All this feedbacks/rumors about SafarÃ is really motivating for me. I hope to go back working on it to make it usable. I am quite confident that I can do it and I d like to do that before the summer. Luigi Panzeri -- View this message in context: http://n2.nabble.com/Aaah%2C-the-pain-or-ParagraphEditor-refactoring---%29-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 28, 2009

Re: [Pharo-project] lisencing

by Matthew Fulmer

On Fri, Feb 27, 2009 at 10:38:43AM +0100, St?phane Ducasse wrote: > Ideally we should check that the guy sign the squeak MIT agreement but > this is not clear where this information here to me > Matthew? do you know? The most up-to-date list of ok contributors is at http://www.squeaksource.com/311/MethodAuthorship-kph.17.mcz See the class-side methods in Authorship, category data -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Feb. 28, 2009

Re: [Pharo-project] Issue #112: Enhanced colors

by Igor Stasenko

+1 to package 2009/2/28 Rob Rothwell <r.j.rothwell(a)gmail.com>: > I kind of like that Package idea...although I have years of QBColor(13) to > overcome...! > > On Fri, Feb 27, 2009 at 9:18 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> > http://code.google.com/p/pharo/issues/detail?id=112 >> > >> > Who thinks that we should add these colors? These are more than 100 >> > additional named colors like #paleGoldenrod, #mediumOrchid, #thistle, >> > etc. >> > >> > I'd vote against adding them since I don't see their merit. >> > >> > Other opinions? >> >> we could keep them as a package. >> Having colors is useful for us >> >> > >> > >> > Cheers, >> > Adrian >> > >> > ___________________ >> > http://www.adrian-lienhard.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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 28, 2009

Re: [Pharo-project] Issue #112: Enhanced colors

by Rob Rothwell

I kind of like that Package idea...although I have years of QBColor(13) to overcome...! On Fri, Feb 27, 2009 at 9:18 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > http://code.google.com/p/pharo/issues/detail?id=112 > > > > Who thinks that we should add these colors? These are more than 100 > > additional named colors like #paleGoldenrod, #mediumOrchid, #thistle, > > etc. > > > > I'd vote against adding them since I don't see their merit. > > > > Other opinions? > > we could keep them as a package. > Having colors is useful for us > > > > > > > Cheers, > > Adrian > > > > ___________________ > > http://www.adrian-lienhard.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 >

Feb. 28, 2009

Re: [Pharo-project] About little magic to support understanding

by Igor Stasenko

Hello Stef, i designed own little thingy to intercept any message sent to an object, including #DNU. See, if it can be useful for you. As an example there is a subclass (CVMsgHandlingProxy) which i'm using to write an inline code to handle messages right in place where i creating a proxy: superReceiver "lambda, when reducing , sends #perform:withArguments: , and we doing trick by evaluating perform..inSuperClass" ^ CVMsgHandlingProxy onMessage: [:msg | msg selector == #perform:withArguments: ifTrue: [ self receiver perform: msg arguments first withArguments: msg arguments second inSuperclass: self receiver class superclass ] ifFalse: [ self receiver perform: msg selector withArguments: msg arguments ] ] what is cool in this method: suppose you have a code like following: proxy := (someObject asSuperReceiver). and later you sending a messages to it: proxy foo. Now, the trick is, that in the end, a message #foo will be sent to original 'someObject' , but using its superclass (same semantics, as you using super foo). What is cool in CVMsgHandlingProxy, that you don't need to declare a separate class each time you need to have different proxy behavior.. you just write: makeProxyFor: object ^ CVMsgHandlingProxy onMessage: [:msg | msg sentTo: object ] 2009/2/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > >> so what about Morph's abuse of includesSelector: would it be >> confused by asking ProtoObject instance if it >> understands #lalaland: > > I have to think :) > Right now it freezes hard :) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2009