- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Some issues with Pharo-dev build #10243

by David RÃ¶thlisberger

>> Just curious: Did you load this versions by hand? Because those versions of OB are >> still alpha, so we have to expect dev-dev behavior in those. ;) > > pharo-dev is now based on #loadOBAlpha. ah. Hm, not sure whether this is convenient. I mean every commit to the OB repository has to be tested very carefully then, and I cannot commit experimental features anymore, because they automatically get loaded with #loadOBAlpha as it is right now. What is the motiviation to not longer build pharo-dev with the OB versions published in Universe? David

Feb. 27, 2009

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

by StÃ©phane Ducasse

> 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 :)

Feb. 27, 2009

[Pharo-project] About redefinedMethods

by StÃ©phane Ducasse

Hi guys I would like to add redefinedMethods in class and friend. Because this is useful. Do you know if something like that already exist? Point selectors intersection: (Point allSuperclasses inject: Set new into: [:sum :each | sum addAll: each selectors; yourself]) Stef

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Janko MivÅ¡ek

Philippe, One idea: Kom needs MIME support, Swazoo does not. So in case of Swazoo you deal with a MIME in web server adapter, right? What if you do the same, use your own MIME support in adapter for Kom as well? Best regards Janko Philippe Marschall pravi: > StÃ©phane Ducasse wrote: >> I have problems to understand why this would be not reasonable that >> people load a give kom version for seaside on squeak >> and one for seaside on pharo. > > Loading is one thing. What bothers we more is the maintenance situation. > Let's face it, there are far too resources behind something as important > as Kom. Making a fork of it cuts these resources in half. > > Maintenance is not doing a quick fix now so that it loads. Maintenance > is taking care of something for several years (!) to come, fixing issues > as they arrive, being there and responding. Removing time from other > activities instead of finding excuses. > > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Feb. 27, 2009

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

by John M McIntosh

so what about Morph's abuse of includesSelector: would it be confused by asking ProtoObject instance if it understands #lalaland: On 27-Feb-09, at 10:02 AM, StÃ©phane Ducasse wrote: > John > > normally when a method is not found I copy it from the class to the > empty copy so slowly it gets automagically filled > up. This is fun you see the result of your actions live. > So normally I should not have the problem you describe. In fact the > first thing I tried was to inspect the object and it worked > wonderfully . > > Now may be Morph is more vicious > > On Feb 27, 2009, at 6:44 PM, John M McIntosh wrote: > >> Well for the objective C bridge >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/ObjectiveCBridge2' >> user: '' >> password: '' >> >> I used ProtoObject as the super class of the ObjectiveCObject and >> supplied doesNotUnderstand: to forward messages to the >> Objective-C plugin for dispatching Obj-c messages. >> >> In attempting to work with instances of ObjectiveCObject I found I >> had >> to implement about 20 support methods >> so that you could inspect, explore, or recompile. Otherwise tapping >> inspect sends to you la-la land... >> Maybe there is a useful clue somewhere in there. >> >> >> On 27-Feb-09, at 9:31 AM, StÃ©phane Ducasse wrote: >> >>> Hi >>> >>> I wanted to see what is used in Morph so I did the following >>> >>> Define a subclass of ProtoObject and redefnied DNU as follow >>> >>> >>> doesNotUnderstand: aMessage >>> >>> | sel category | >>> sel := aMessage selector. >>> Transcript show: 'Does not understand ', aMessage selector >>> printString ; cr. >>> category := (Morph organization categoryOfElement: sel). >>> self class compile: (Morph sourceCodeAt: sel) classified: category. >>> ^ aMessage sentTo: self. >>> >>> >>> It works if I copy from Object but not from Morph >>> does any of you have an idea. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Feb. 27, 2009

Re: [Pharo-project] ENH thisContext arguments

by StÃ©phane Ducasse

On Feb 27, 2009, at 6:51 PM, Igor Stasenko wrote: > 2009/2/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> May be this can be useful to have that defined in ContextPart >> > this is definitely useful to hackers, who playing with contexts. > But code which deals with contexts is uncommon thing. but when you need it you need it :) I static generating stub that when executed recompile another method with the same name and without stopping method execution this is really fun. >> From this point i see it worth adding only to have a complete >> coverage > of ways to access context-related state. Thanks > > >> arguments >> "returns the arguments of a message invocation" >> >> | arguments numargs | >> numargs := self method numArgs. >> arguments := Array new: numargs. >> 1 to: numargs do: [:i | arguments at: i put: (self tempAt: >> i) ]. >> ^ arguments >> >> >> Let me know I can prepare a enh entry in the bug tracker. >> >> stef >> >> _______________________________________________ >> 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. 27, 2009