November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] polymorph UI glitch

by StÃ©phane Ducasse

When I enlarged the window I got that.

Nov. 29, 2008

Re: [Pharo-project] FFI inside Pharo ?

by StÃ©phane Ducasse

Mike could you explain a bit more the scenario. would the people have to add a dll? Stef On Nov 29, 2008, at 10:25 AM, Michael Rueger wrote: > Marcus Denker wrote: >> I personally think that a good FFI is base fuctionality, e.g. it >> allows to >> move glue-code into the image that normally would be in primitives. > > The problem with FFI (and Alien) is that by using FFI and thus > having the FFI plugin installed you completely circumvent any > security you gain from the sandbox. > This is only really interesting for an environment like etoys where > you allow arbitrary scripts to be loaded. Right now we are not > supporting etoys, but the question is what, down the road, is going > to happen. > > Another question is how more use of FFI opens us up to issues other > languages have. So far Smalltalk wasn't hackable (on the server), > with FFI generally available it could be? > > If people vote this a non-issue I'm fine with it, but I wanted at > least to raise the issue at hand. > > Michael > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 29, 2008

Re: [Pharo-project] Bug when loading Seaside in 10178

by StÃ©phane Ducasse

Apparently this is a problem with PSUIManager thisContext trick. We ended up with MCdefinitino compared using = with World. Stef On Nov 29, 2008, at 2:52 PM, Damien Pollet wrote: > Just loading Seaside 2.8a1 in pharo (core or dev, using universes or > MC) 10178, we get a strange from PSUIManager >> modalMorphâ¦ not clear > if it's pharo or MC or Seaside's faultâ¦ > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 29, 2008

Re: [Pharo-project] FFI inside Pharo ?

by John M McIntosh

On 29-Nov-08, at 1:14 AM, Marcus Denker wrote: > > On 28.11.2008, at 12:35, Antony Blakey wrote: > >> >> On 28/11/2008, at 9:43 PM, Damien Cassou wrote: >> >>> On Fri, Nov 28, 2008 at 12:07 PM, Igor Stasenko >>> <siguctua(a)gmail.com> wrote: >>>> May i guess, that dev image should contain FFI package by default? >> >> Has there been any discussion about using Alien exclusively as a >> Pharo goal? > > > No discussion really, but I think this would be nice. > > I personally think that a good FFI is base fuctionality, e.g. it > allows to > move glue-code into the image that normally would be in primitives. > > Now Alien does only support intel... so it's not there yet, even > though there > has been lots of progress (very nice!). Er so what else is missing, I do hope to complete the powerpc work this week. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 29, 2008

[Pharo-project] methodChanged: bug

by StÃ©phane Ducasse

Hi guys When you remove an Trait from the use: clause you get an DNU because the item in anEvent item is nil. It would be good to fix that. Stef methodChanged: anEvent | cls sel | "cls contains the class in which the method sel has been modified" cls := anEvent item methodClass. (cls inheritsFrom: TestCase) ifFalse: [^ self]. "sel contains the method name that has been modified" sel := anEvent item selector. "this selector has to be a test" (sel beginsWith: 'test') ifFalse: [^ self]. " remove sel from the known test results" TestResult removeFromTestHistory: sel in: cls.

Nov. 29, 2008

Re: [Pharo-project] FFI inside Pharo ?

by David Pennell

+1 On Nov 29, 2008, at 3:14 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 28.11.2008, at 12:35, Antony Blakey wrote: > >> >> On 28/11/2008, at 9:43 PM, Damien Cassou wrote: >> >>> On Fri, Nov 28, 2008 at 12:07 PM, Igor Stasenko >>> <siguctua(a)gmail.com> wrote: >>>> May i guess, that dev image should contain FFI package by default? >> >> Has there been any discussion about using Alien exclusively as a >> Pharo goal? > > > No discussion really, but I think this would be nice. > > I personally think that a good FFI is base fuctionality, e.g. it > allows to > move glue-code into the image that normally would be in primitives. > > Now Alien does only support intel... so it's not there yet, even > though there > has been lots of progress (very nice!). > > So one idea could be to have both for now... and replace the old as > soon as > Alien is ready. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 29, 2008

[Pharo-project] Bug when loading Seaside in 10178

by Damien Pollet

Just loading Seaside 2.8a1 in pharo (core or dev, using universes or MC) 10178, we get a strange from PSUIManager >> modalMorphâ¦ not clear if it's pharo or MC or Seaside's faultâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Nov. 29, 2008

Re: [Pharo-project] FFI inside Pharo ?

by Igor Stasenko

2008/11/29 Michael Rueger <m.rueger(a)acm.org>: > Marcus Denker wrote: >> >> I personally think that a good FFI is base fuctionality, e.g. it allows to >> move glue-code into the image that normally would be in primitives. > > The problem with FFI (and Alien) is that by using FFI and thus having the > FFI plugin installed you completely circumvent any security you gain from > the sandbox. > This is only really interesting for an environment like etoys where you > allow arbitrary scripts to be loaded. Right now we are not supporting etoys, > but the question is what, down the road, is going to happen. > > Another question is how more use of FFI opens us up to issues other > languages have. So far Smalltalk wasn't hackable (on the server), with FFI > generally available it could be? > > If people vote this a non-issue I'm fine with it, but I wanted at least to > raise the issue at hand. > > Michael > > I suggested it only for dev images. A basic image may not have FFI. But then it shouldn't contain any package which using FFI (like freetype glue-code). > _______________________________________________ > 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.

Nov. 29, 2008

Re: [Pharo-project] RBParser

by GwenaÃ«l Casaccio

Hi, I've corrected the problems in the version : AST-Gwenael_Casaccio.161.mcz Cheers, Gwenael On Tue, Nov 4, 2008 at 2:08 PM, Gwenael Casaccio <mrgwen(a)gmail.com> wrote: > Hi, > > In fact I've seen the method patch literal in the parser which transformed > the literals as strings so as we've strings in the > scanner I've take the decision to remove this method and kept the > literals as string. And off course I don't have launch the refactorings > tests :s > > Cheers, > Gwenael > > On 11/1/08 10:21 AM, Lukas Renggli wrote: >> >> On Fri, Oct 31, 2008 at 10:42 AM, Gwenael Casaccio<mrgwen(a)gmail.com> >> wrote: >>> >>> I've commit a new version I've removed all the RB*Token >> >> I've loaded your changes, but it seems to break the refactoring >> browser. All literals (numbers, symbols, true, false, nil, ...) are >> printed as strings ('123', '#foo', 'true', 'false', ...). Did I forget >> to load something, or is this a bug? >> >> Cheers, >> Lukas >> >> >>> On 10/29/08 6:21 PM, Lukas Renggli wrote: >>>>> >>>>> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've >>>>> fixed these classes and now you can parse the entire image. At this >>>>> moment >>>>> the refactoring is not yet finished but I've made some good progress. >>>> >>>> Good news. >>>> >>>> I was not aware that you were working on RBParser. Stef told me that >>>> you also improved the refactorings. I think you should commit and work >>>> on the public repository to get more attention. I guess there were >>>> many other changes going on in RB codebase in the meantime. >>>> >>>> Cheers, >>>> Lukas >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> > >

Nov. 29, 2008

[Pharo-project] [update] #10183

by Marcus Denker

-> Issue 359: Freetype: fix DNU glyphcontrast -> Cleanups -> Prefences set to more useful values Classes removed: DummyToolWorkingWithFileList FileChooser FileList2ModalDialogsTest FileListTest MultiuserTinyPaint ProjectSorterMorph Unsent Methods removed: ScriptLoader class #loadPolymorphUI TileMorph: #handReferentMorph #currentDataValue #newContents:fromCard: #setNewContentsFrom: TextFieldMorph: #currentDataValue #setNewContentsFrom: StandardScriptingSystem #acceptableSlotNameFrom:forSlotCurrentlyNamed:asSlotNameIn:world: #anyButtonPressedTiles #colorBehindTiles #customEventNamesAndHelpStringsFor: #doesOperatorWantArrows: #fontForNameEditingInScriptor #globalCustomEventNames #globalCustomEventNamesFor: #helpStringForOperator: #inspectFormDictionary #installSolidMenuForm #nameForInstanceVariablesCategory #nameForScriptsCategory #noButtonPressedTiles #patchInNewStandardPlayerForm #readFormsFromFileNamed: #readFormsFromFileNamed:andStoreIntoGlobal: #referenceAt: #referenceAt:put: #removeCustomEventNamed:for: #resetStaleScriptingReferences #restoreClassicEToyLook #restorePrivateGraphics #saveFormsToFileNamed: #setterSelectorForGetter: #smallBoldFont #standardEventStati #standardForms #statusColorSymbolFor: #stepButton #stopButton #tryButtonFor: #wordingForOperator: StandardScriptingSystem class #noteCompilationOf:meta: SketchMorph class #exampleBackgroundSketch SketchMorph #currentDataValue PluggableTextMorphWithModel #currentDataValue ImageMorph #currentDataValue #wearCostume: HandMorph #trailMorph EventHandler #forgetDispatchesTo: CollapsedMorph class #collapsedMorphOrNilFor: isMyUncollapsedMorph: ClassDescription namedTileScriptSelectors ParagraphEditor #getPluggableYellowButtonMenu: #prettyPrintWithColor #scrollRectangleHeight #sendContentsToPrinter PasteUpMorph #residesInPartsBin BorderedMorph #understandsBorderVocabulary Morph class #additionsToViewerCategory: #allAdditionsToViewerCategories! #noteCompilationOf:meta: Morph #addGraphModelYellowButtonItemsTo:event: #allowsGestureStart: #altSpecialCursor0 #altSpecialCursor2 #connections #demandsBoolean #orOwnerSuchThat:#pinkXButton #redButtonGestureDictionaryOrName: #residesInPartsBin #saveOnURL #setAsActionInButtonProperties: #specialNameInModel #startWiring #wantsEmbeddingsVocabulary MorphicModel #choosePartName #allowSubmorphExtraction #compileInitMethods #duplicate:from: #propagate:as: MorphExtension #hasOtherProperties #privateOtherProperties: StandardFileMenu #computeLabelParagraph #patternList: SoundLoopMorph #allowSubmorphExtraction ProjectNavigationMorph #findAnything PopUpMenu #computeLabelParagraph PluggableTextMorph #prettyPrintWithColor #sendContentsToPrinter PasteUpMorph #findAFileList: MessageSet #optionalButtonHeight InternalThreadNavigationMorph #editThisThread FileList2 #dirSelectionBlock: #limitedSuperSwikiDirectoryList #limitedSuperSwikiPublishDirectoryList #listForPattern: #okHitForProjectLoader #removeLinefeeds #saveLocalOnlyHit FileList #listForPattern: #optionalButtonHeight Debugger #optionalButtonHeight ChangeList #optionalButtonHeight BookMorph #allowSubmorphExtraction #buildThreadOfProjects -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Nov. 29, 2008