- Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

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 >

Feb. 27, 2009

Re: [Pharo-project] ENH thisContext arguments

by Igor Stasenko

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. >From this point i see it worth adding only to have a complete coverage of ways to access context-related state. > 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.

Feb. 27, 2009

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

by John M McIntosh

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 = = = ========================================================================

Feb. 27, 2009

[Pharo-project] About little magic to support understanding

by StÃ©phane Ducasse

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.

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

>>> > With my changes to Pharo (which of course first need to be > integrated), I will integrate them this evening. > > the changed (not forked!) version of Kom and the few changes for > Seaside > (which need to be integrated) there is no need for a fork!!! > > Those versions should work on both Squeak and Pharo. > > It's not monkey patching, none of the packages touch other stuff any > more than they did before. I just changed Kom so its monkey patching > now > works on both Seaside and Pharo. > > And that's where I need you help testing. > > Michael > > > _______________________________________________ > 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

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

So you even got a solution :) Excellent! But this is also a good point because it means that for the future we will have again this kind of discussion.....exciting. Stef On Feb 27, 2009, at 6:06 PM, Michael Rueger wrote: > Philippe Marschall wrote: >> 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. > > Hmm, I think most of the discussion is simply a misunderstanding, I'm > not forking anything. > > With my changes to Pharo (which of course first need to be > integrated), > the changed (not forked!) version of Kom and the few changes for > Seaside > (which need to be integrated) there is no need for a fork!!! > > Those versions should work on both Squeak and Pharo. > > It's not monkey patching, none of the packages touch other stuff any > more than they did before. I just changed Kom so its monkey patching > now > works on both Seaside and Pharo. > > And that's where I need you help testing. > > Michael > > > _______________________________________________ > 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

Re: [Pharo-project] MIMEdatabase fix?

by StÃ©phane Ducasse

you know I guess that I know what is maintenance. >> 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. So what is your suggestion then because so far the only message we got is that we should not change network because KOM is crappy. So ****concretely**** what can we do. So far you have not been that constructive. If we do not have paths for the future then why Seasiders even think about using Pharo. May be you should get stuck in Squeak and this is ok too. Stef

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Michael Rueger

Philippe Marschall wrote: > 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. Hmm, I think most of the discussion is simply a misunderstanding, I'm not forking anything. With my changes to Pharo (which of course first need to be integrated), the changed (not forked!) version of Kom and the few changes for Seaside (which need to be integrated) there is no need for a fork!!! Those versions should work on both Squeak and Pharo. It's not monkey patching, none of the packages touch other stuff any more than they did before. I just changed Kom so its monkey patching now works on both Seaside and Pharo. And that's where I need you help testing. Michael

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

StÃ©phane Ducasse wrote: > On Feb 25, 2009, at 5:59 PM, Michael Rueger wrote: > >> Lukas Renggli wrote: >>>> what seasiders think? >>>> I would be in favor to get a KOM pharo version >>> Having two incompatible versions of Kom makes distribution even more >>> painful as it is today. I would prefer to have compatible versions if >>> this is possible. >> As I said, we are at or at least close to the point where we have to >> make the decision which version to support. If you want to have Pharo >> stay compatible with Squeak, we can just as well abandon Pharo now. >> It's as simple as that. > > No else we would not have done pharo. > The point is more how can we help people migrating to pharo. > Probably having a specific Kom version. You help people if you have a maintained version of Kom (see other mail). If you don't have a maintained web server then you are hurting people. Simply making a fork of Kom is not maintenance, on the contrary. Philippe

Feb. 27, 2009

Re: [Pharo-project] MIMEdatabase fix?

by Philippe Marschall

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

Feb. 27, 2009