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

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

by Dale Henrichs

Feb. 24, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by Igor Stasenko

2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> >> >> Can i put my 5 cents in it? >> >> - collect all such overrides into a separate package, named Morphic :) > > lol > > probably part of the solution is there :) and its a good chance to take an overview of them, check duplicates/unnecessary code & overall design. Mostly the same things Pharo is currently concerned with :) > Stef -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2009

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

by Igor Stasenko

2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > This is the OB based debugger? > Yeah, OTDebugger btw, how i can switch to old one? > Stef > On Feb 24, 2009, at 10:00 PM, Igor Stasenko wrote: > >> one more thing: >> pressing 'restart' does not restarts evaluation from choosen context, >> and also throws me an error, when i previously created a new method by >> 'create method' button. >> >> (*sarcasm*) I think this build should be renamed to pharo-dev-dev , to >> indicate that this image is suitable for developing a development >> tools, like Debugger >> (*sarcasm end*) >> >> Nevertheless, you doing a great job guys! :) >> >> >> -- >> 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. 24, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by StÃ©phane Ducasse

> >> > > Can i put my 5 cents in it? > > - collect all such overrides into a separate package, named Morphic :) lol probably part of the solution is there :) Stef > > > >> 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. 24, 2009

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

by StÃ©phane Ducasse

This is the OB based debugger? Stef On Feb 24, 2009, at 10:00 PM, Igor Stasenko wrote: > one more thing: > pressing 'restart' does not restarts evaluation from choosen context, > and also throws me an error, when i previously created a new method by > 'create method' button. > > (*sarcasm*) I think this build should be renamed to pharo-dev-dev , to > indicate that this image is suitable for developing a development > tools, like Debugger > (*sarcasm end*) > > Nevertheless, you doing a great job guys! :) > > > -- > 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. 24, 2009

Re: [Pharo-project] Towards Pharo 1.0

by StÃ©phane Ducasse

On Feb 24, 2009, at 9:23 PM, Michael Rueger wrote: > Schwab,Wilhelm K wrote: >> FFI has (it seems to me) long been viewed as an evil in the Squeak >> community. I have no idea whether that is justified, but I have to >> say that the analogous features in Dolphin have been essential. > > The motiviation behind not including FFI in the "standard" image was > security. FFI allows you to circumvent the Squeak sandbox. by sandboxing you mean protected from squeak. You cannot access the file system if you do not have FFI Because one day we will have also to think about sandboxing pharo from its own downloaded code. > Which is only > really interesting for Squeak applications that download untrusted > code > from somewhere (e.g. etoys projects). > >> >> Unless there is a very good reason to exclude it, I would ask for FFI >> in 1.0. For myself, the next big hurdle is underscores, largely >> because so many of the external entities to which I would be mapping >> contain them. > > I would support that, if it wasn't for Alien, which should be > replacing > FFI any time now :-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2009

Re: [Pharo-project] Dealing with incompatibility (was: Re: MIMEdatabase fix?)

by StÃ©phane Ducasse

On Feb 24, 2009, at 9:21 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> On Feb 24, 2009, at 7:35 PM, Michael Rueger wrote: >> >>> slightly shorter it is the fork in the road: >>> >>> are you committing to Pharo or Squeak? >> >> I did not get that? >> commited :)? to pharo? > > Well, yes :-) > Basically meaning we need to maintain packages explicitly for Pharo. Yes! >> For MIME I would like to hear if seasider have an alternative to KOM: >> is swazoo an ok alternative? > > The problem with MIME and Kom is that Kom changes quite a few things, > which basically require to revert most of the MIME changes. > The recursion with the mimeType method is one of them. Arggh ok now I understand. Stef > > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 24, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by Igor Stasenko

2009/2/24 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi gary > > We discussed yesterday and we would like to know how we could reduce > the overrides > made by polymorph because we will get in trouble in the long run. > What is your view on that? > Can i put my 5 cents in it? - collect all such overrides into a separate package, named Morphic :) > 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. 24, 2009

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

by Igor Stasenko

one more thing: pressing 'restart' does not restarts evaluation from choosen context, and also throws me an error, when i previously created a new method by 'create method' button. (*sarcasm*) I think this build should be renamed to pharo-dev-dev , to indicate that this image is suitable for developing a development tools, like Debugger (*sarcasm end*) Nevertheless, you doing a great job guys! :) -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2009

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

by Igor Stasenko

This is mostly feedback on using Debugger - on DNU, if i press 'create a method' debugger opens, and shows extra (debugger related) context frames up to the method context which is just created. (while writing this, i found that it shows these extra contexts even if i simply press 'debug') : -------------- Process>>suspend OTToolset class>>debug:context:label:contents:fullView: OTToolset class>>debugError: [] in DEVToolSet class>>debugError: {[:obtools | obtools debugError: anError]} [] in DEVToolSet class>>ifOBTools:else: {[:obtools | aBlock value: obtools]} OTToolset class(Object)>>ifNil:ifNotNilDo: DEVToolSet class>>ifOBTools:else: DEVToolSet class>>debugError: ToolSet class>>debugError: UnhandledError>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: Error>>defaultAction UndefinedObject>>handleSignal: Error(Exception)>>pass [] in PasteUpMorph>>becomeActiveDuring: {[:ex | ActiveWorld := priorWorld. ActiveEvent := priorEvent. ActiveHand :...]} BlockContext>>valueWithPossibleArgs: [] in MethodContext(ContextPart)>>handleSignal: {[(self tempAt: 2) valueWithPossibleArgs: {exception}]} BlockContext>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Error(Exception)>>signal Error(Exception)>>signal: ...... only here starts the context i'm interested in ..... ------------ - mistakenly clicked on 'proceed' while not saved the method caused a losing unsaved work - i'll be happy, to have 'create a method' button, when code throws #subclassResponsibility error :) -- Best regards, Igor Stasenko AKA sig.

Feb. 24, 2009