- Pharo-dev - lists.pharo.org

Re: [Pharo-project] SmallFaces and Phantasia
by Serge Stinckwich Dec. 12, 2008

Dec. 12, 2008

Maybe a short list of working applications could be made of the future web site. 2008/12/12 Serge Stinckwich <Serge.Stinckwich(a)gmail.com>: > Maybe a short list of Squeak applications working with Pharo should be > made in the future web site. > > > 2008/12/11 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: >> Hello list, >> Just to say now SmallFaces and Phantasia should load fine in the Pharo >> image. >> Cheers. >> >> HernÃ¡n >> >> PD: http://www.squeaksource.com/SmallFaces.html >> http://www.squeaksource.com/Phantasia.html >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > IRD - UR 079 Geodes, MSI Team, Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > -- Serge Stinckwich IRD - UR 079 Geodes, MSI Team, Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

1 0

[Pharo-project] [BUG]AbstractObjectsAsMethod(Object)>>doesNotUnderstand: #getSourceFor:in:
by bstjean＠yahoo.com Dec. 12, 2008

Dec. 12, 2008

BUG 388 and testing bug 389 at the same time... 11 December 2008 7:32:18 pm VM: Win32 - a SmalltalkImage Image: Pharo0.1 [Latest update: #10188] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Program Files\Squeak\Pharo_2008-09-15 Trusted Dir C:\Program Files\Squeak\Pharo_2008-09-15\Benoit St-Jean Untrusted Dir C:\My Squeak\Benoit St-Jean AbstractObjectsAsMethod(Object)>>doesNotUnderstand: #getSourceFor:in: Receiver: an AbstractObjectsAsMethod Arguments and temporary variables: aMessage: getSourceFor: #answer42 in: TestObjectsAsMethods Receiver's instance variables: an AbstractObjectsAsMethod TestObjectsAsMethods class(Behavior)>>sourceCodeAt: Receiver: TestObjectsAsMethods Arguments and temporary variables: selector: #answer42 Receiver's instance variables: superclass: TestCase methodDict: a MethodDictionary(#add:with:->an ObjectsAsMethodsExample #answer42...etc... format: 132 instanceVariables: nil organization: ('as yet unclassified' testAddNumbers testAnswer42 testDNU) subclasses: nil name: #TestObjectsAsMethods classPool: nil sharedPools: nil environment: Smalltalk category: #'Tests-ObjectsAsMethods' traitComposition: nil localSelectors: nil [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:sel | ((each sourceCodeAt: sel) findString: aString startingAt: 1 ...]} Arguments and temporary variables: aString: 'SystemNavigation' caseSensitive: false list: a Set(a MethodReference Inspector >> #defsOfSelection a MethodReference C...etc... count: 1128 adder: [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:mrClass...etc... mrClass: ChangeSet mrSel: #fileOut bar: [] in SystemProgressMorph>>label:min:max: {[:barVal | return := nil. bar...etc... each: TestObjectsAsMethods sel: #answer42 MethodDictionary>>keysDo: Receiver: a MethodDictionary(#add:with:->an ObjectsAsMethodsExample #answer42->an AbstractObjectsAsM...etc... Arguments and temporary variables: aBlock: [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:sel | ...etc... key: #answer42 i: 2 iLimiT: 8 Receiver's instance variables: tally: 5 array: an Array(a CompiledMethod (3391) an AbstractObjectsAsMethod nil an Objec...etc... --- The full stack --- AbstractObjectsAsMethod(Object)>>doesNotUnderstand: #getSourceFor:in: TestObjectsAsMethods class(Behavior)>>sourceCodeAt: [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:sel | ((each sourceCodeAt: sel) findString: aString startingAt: 1 ...]} MethodDictionary>>keysDo: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TestObjectsAsMethods class(Behavior)>>selectorsDo: [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:each | bar value: (count := count + 1). each selectorsDo: [:sel | ((ea...]} [] in TestCase class(Behavior)>>allSubclassesDoGently: {[:cl | cl isInMemory ifTrue: [aBlock value: cl. cl allSubclassesDoGentl...]} Array(SequenceableCollection)>>do: TestCase class(Class)>>subclassesDoGently: TestCase class(Behavior)>>allSubclassesDoGently: [] in Object class(Behavior)>>allSubclassesDoGently: {[:cl | cl isInMemory ifTrue: [aBlock value: cl. cl allSubclassesDoGentl...]} Array(SequenceableCollection)>>do: Object class(Class)>>subclassesDoGently: Object class(Behavior)>>allSubclassesDoGently: [] in ProtoObject class(Behavior)>>allSubclassesDoGently: {[:cl | cl isInMemory ifTrue: [aBlock value: cl. cl allSubclassesDoGentl...]} Array(SequenceableCollection)>>do: ProtoObject class(Class)>>subclassesDoGently: ProtoObject class(Behavior)>>allSubclassesDoGently: SystemNavigation>>allBehaviorsDo: [] in SystemNavigation>>allMethodsWithSourceString:matchCase: {[:bar | count := 0. SystemNavigation default allBehaviorsDo: [:each | ...]} [] in ProgressInitiationException>>defaultAction {[result := workBlock value: progress]} BlockContext>>ensure: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: ProgressInitiationException(Exception)>>signal ProgressInitiationException>>display:at:from:to:during: ProgressInitiationException class>>display:at:from:to:during: ByteString(String)>>displayProgressAt:from:to:during: SystemNavigation>>allMethodsWithSourceString:matchCase: ...etc...

1 0

[Pharo-project] About bug reporting...
by Marcus Denker Dec. 11, 2008

Dec. 11, 2008

Hi, Please keep in mind: everyone's time is *limited*. Therefore, please do *not* report bugs in the bug tracker (nor to this mailinglist) where the problem is *clearly* not Pharo but somebody elses crappy code. Thank you. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

[Pharo-project] Alien structural change
by John M McIntosh Dec. 11, 2008

Dec. 11, 2008

For the very few folks that are working with Alien I'm about to make a structural change that is needed to support floating point arguments on PowerPC. Because of how the os-x powerpc abi works we *do* need to know what type the parameters are in order to decide if that 32bit data item is a float or long, or if 64bit a long long or double. Parms are passed based on if they are Floating point or non-floating point. This is a bit of a pain because MacIntel users still can pass integer, float, long long, double without regard to typing, yet if they expect to run on PowerPC a bit more care and typing is required. In the example below the primFFICallResult:with:with: call has no idea if the alien 1 or alien 2 are long long or double. testCallingSquenceLongLong2 | alien1 alien2 result who | alien1 := Alien newC: 8. alien2 := Alien newC: 8. alien1 signedLongLongAt: 1 put: 1. alien2 signedLongLongAt: 1 put: 42. er or is that alien1 doubleAt: 1 put: 1. alien2 doubleAt: 1 put: 42. who := Alien lookup: 'ffiTestLongLong' inLibrary: 'IA32ABI'. result := who primFFICallResult: (Alien new: 8) with: alien1 with: alien2. self should: [(result signedLongLongAt: 1) = (1+42)]. alien1 free. alien2 free. In talking to Eliot we feel this will become for Double who primFFICallResultWithFloatParms: (Alien new: 8) with: alien1 with: alien2. with: (ByteArray with: 8 with: 8) for Float who primFFICallResultWithFloatParms: (Alien new: 8) with: alien1 with: alien2. with: (ByteArray with: 4 with: 4) The last parm is a tag array that contains information about the size of the floating point object. Now in order to cheat a bit here we will allow you to say who primFFICallResult: (Alien new: 8) with: 1.0 with: 42.0. because we know the element being passed is a floating point squeak object so we will assume we should treat it as a Double parm. This of course won't work very well if you are dealing with a Float so you would need to use the who primFFICallResultWithFloatParms: (Alien new: 8) with: 1.0 with: 42.0. with: (ByteArray with: 4 with: 4) Remember if you do: who primFFICallResult: (Alien new: 8) with: oneParm with: twoParm. where oneParm/twoParm is *usually* a float you really need to take care and say who primFFICallResult: (Alien new: 8) with: oneParm asFloat with: twoParm asFloat. Lastly if you do who primFFICallResultWithFloatParms: (Alien new: 8) with: 1 with: 42. with: (ByteArray with: 4 with: 4) The we'll assume oneParm and twoParm are floats and not do any autoconversion if say you pass an integer and your results will be unexpected, or trigger an primitive failure. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] [update] #10188
by Marcus Denker Dec. 11, 2008

Dec. 11, 2008

- Issue 389: Email report from the debugger still sends emails to squeakfoundation.org - Revert some cleanups from HandMorph relating to Nebraska that broke EventRecorder (Part 1) - test for #classVarNames (issue #246) - remove unsent methods from FileList: #dirSelectionBlock: #limitedSuperSwikiDirectoryList #limitedSuperSwikiPublishDirectoryList! #listForPattern: #okHitForProjectLoader #publishingServers #removeLinefeeds #saveLocalOnlyHit ====================================================================== -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

2 1

[Pharo-project] [update] #10187
by Marcus Denker Dec. 11, 2008

Dec. 11, 2008

Hi, Just a small bug-fixing release, fixes gathered from the tracker mostly concerned with removing unimplemented sends. update #10187 -------------- Issue 379: unimplemented asFilename Issue 373: replace primitiveFail with primitiveFailed Issue 371: Fix for loading Seaside29 in ScriptManager Issue 374: unimplemented string:hasEncoding: Issue 375: DNU in FileList open, unimplemented addVolumesAndPatternPanesTo:at:plus:forFileList: Issue 377: unimplemented mvcRedisplay Issue 376: unimplemented moveYoungest:in:to: Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

Re: [Pharo-project] Fwd: news icons and navigation
by David RÃ¶thlisberger Dec. 11, 2008

Dec. 11, 2008

Hi Lukas, > Did you receive this? I got an error message from the mailing list. The list's address changed to pharo-project(a)lists.gforge.inria.fr for some reason... > You asked me ... Thanks for your feedback! >> Lukas you should have a look >> no super read >> different super black >> simple super green > > I do not understand, so I am reading <http://smallwiki.unibe.ch/hermion/icons/>: > > - What means "super method does not exit" ? Do you mean "exists"? yep, this should read "does not exist", sorry. > - What has priority if there are multiple super sends in one method? Priority has any super send to another selector than the one of the method. Afterwards we show whether the method sends super to the same selector, but there is no super method (means we don't check whether there is no implementor of a different super send selector as this gets highlighted in any case by the 'other selector' icon). Otherwise, we show the normal super send icon, distinguishing between a sub-impl. exists or not. > - What is shown when you have a sub-implementation and do a super call > to a non existing method? the icon that says "super send, but super method does not exist, w/ sub-impl." (triangle down, triangle up, red super sign) > Again there is an inconsistent mix of icons and meanings, for example: > > - The case "super send, but super method does not exists." has a big > yellow up arrow. The big yellow arrow on its own means "overrides > super class methods", however this method does not exist in the given > example. ok, that's true, right. But this would imply that we have to do a completely different icon in this case which would not be consistent with the others. Hard to tell which inconsistency is worse. > For the test icons: > > - The icons for "more red tests than green", "equal number of green > and red tests" and "more green tests than red" are cute, but > absolutely useless because inconsistant. "red", "yellow", "green" and > "black" is the only information that is valuable. Or do you plan to > add icons for all combinations like "some red tests, a few yellow and > green and most of them are not run yet"? We should probably take into account the not executed tests, I agree. Distinguishing between yellow and red would be nice too, but I think it's fair enough to just give feedback about the ratio between succeeded and not succeeded. > - Abstract test cases always remain in the state of not being run. > Maybe it is better not to show the test icon at all in that case, or > fetch the result from all the concrete subclasses (that would go > nicely with the semantics of SUnit). ok, good point. David

1 0

[Pharo-project] Bugs
by GwenaÃ«l Casaccio Dec. 11, 2008

Dec. 11, 2008

Hi, I've some bugs to rapports : - when I save a method with the omni-browser I've a latency of 2-3 sec (sometimes more :s) - when I click and the apple key is pressed I've a DNU : HaloMorph>>addMakeSiblingHandle: - sometimes shortcuts don't work when the mouse on the text box (when I want to inspect, do it, ...) - on the script loader don't load the last version of the ast (gwenael-casaccio-183 which is bugged) but the lastest of Lucas Renggli - And as I'm working on the RBParser some methods uses [ : myVar ] I think they should be fixed (and some methods have strange ascii code) : ECModel>>resetSelectors ECSymbols>>contains:caseSensitive:do: ECUntypeModel>>initializeSelectors FileDialogWindow>>defaultFileSortBlock FileDirectory>>withAllFilesDo:andDirectoriesDo: FileDirectory class>>baseNameFor: HostSystemMenusTest>>testMenuHandlesNewMenuAppend2 LintDialog>>testsFromCategory:inClass: Morph>>allMorphs OBCmdCreateMethodCategory>>getCategories:reject:lines: OBEnhPackageBrowser>>testDynamicInfo OBMetaNode>>childOf:ancestorOf:indexIn: OBMethodCategoryFilter>>icon:forNode: OBPaneScroller>>addPaneSplitters OBPluggableTreeMorph>>roots: OBPluggableTreeMorph>>contentsOfNode: PositionableStream>>nextLittleEndianNumber:put: RBFormater>>formatPragmasFor: RunArray>>withStartStopAndValueDo: RxMatchoptimizer>>nonPrefixTester RxParser>>test:with:expect:withSubexpressions: SendCaches>>initializeAllInstances TraitComposition>>copyTraitExpression TraitComposition>>addCompositionOnLeft: Cheers Gwenael

2 1

Dec. 11, 2008

> Did you receive this? I got an error message from the mailing list. yes you should use @lists... >> Lukas you should have a look >> no super read >> different super black >> simple super green > > I do not understand, so I am reading <http://smallwiki.unibe.ch/hermion/icons/ > >: > > - What means "super method does not exit" ? Do you mean "exists"? I mean super zork and zork does not exit > - What has priority if there are multiple super sends in one method? > > - What is shown when you have a sub-implementation and do a super call > to a non existing method? triangle up and down + red foot > Again there is an inconsistent mix of icons and meanings, for example: > > - The case "super send, but super method does not exists." has a big > yellow up arrow. The big yellow arrow on its own means "overrides > super class methods", however this method does not exist in the given > example. Indeed but like that we are consistent > > >> now I was thinking that it would be great to have an icon >> for a class using traits >> and a traits used so that we could navigate the same as for the >> methods >> because clicking on the icon is cool > > For the test icons: > > - The icons for "more red tests than green", "equal number of green > and red tests" and "more green tests than red" are cute, but > absolutely useless because inconsistant. "red", "yellow", "green" and > "black" is the only information that is valuable. Or do you plan to > add icons for all combinations like "some red tests, a few yellow and > green and most of them are not run yet"? Lukas it would be good that you do not have total statement. We already use the class icons and this is cool to see if all your tests are green or if some of them fail/error/ At this level this is not important to be really precise. > - Abstract test cases always remain in the state of not being run. > Maybe it is better not to show the test icon at all in that case, or > fetch the result from all the concrete subclasses (that would go > nicely with the semantics of SUnit). Yeap. One remark is that this is not absolute :) Stef

1 0

[Pharo-project] about test icons
by Torsten Bergmann Dec. 11, 2008

Dec. 11, 2008

Hi David, Great work. I like the icons too, although the "broken/filled test tube" from one of the VisualWorks addons for RB (deep in the public store repo) looked little bit cooler. However - if you select a class with such a new icon in the list there is still a white rectangle/remaining pixels from the white bounding rectangle of the icon left. Is it not possible to use transparency - so the darker selection really covers the icon and not its bounding rect? Thx Torsten -- Psssst! Schon vom neuen GMX MultiMessenger gehÃ¶rt? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

2 1