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

[Pharo-project] About default UI
by StÃ©phane Ducasse Dec. 12, 2008

Dec. 12, 2008

Hi guys We need to do some screenshots about Pharo/Squeak for the Seaside book and I would like to know what would be the default look for pharo? I imagine that lukas/seasider will not change the default look of Phaor in the one click seaside 29 image. Stef

3 2

[Pharo-project] Fwd: About default UI
by Rob Rothwell Dec. 12, 2008

Dec. 12, 2008

Oops...trying to send this again due to changed list address... ---------- Forwarded message ---------- From: Rob Rothwell <r.j.rothwell(a)gmail.com> Date: Thu, Dec 11, 2008 at 10:40 PM Subject: Re: [Pharo-project] About default UI To: pharo-project(a)gforge.inria.fr On Thu, Dec 11, 2008 at 2:04 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > I really like the look that we use now (Watery 2). It looks > professional. Also, it shows from the aesthetics point of view that > Pharo is different to Squeak. I would agree that Watery 2 is pretty good looking, with just a few annoyances. I kind of wish that in browser type windows (OB, Universe Browser, etc...) the buttons and frames wouldn't keep reverting to their original colors! Trying to fix that is WAY beyond me, however... > What we still need to decide about are the default fonts. I still > think that the Bitstream Vera family is a good option, or as suggested > by Damien Pollet (see his mail from December 1), DejaVu. Yes, I downloaded the Bistream Vera fonts for Windows at http://ftp.gnome.org/pub/GNOME/sources/ttf-bitstream-vera/1.10/, and liked the Mono font for coding. I think I like a more basic font like Verdana or something, though, for menus, lists, buttons, etc... Take care, Rob

2 1

[Pharo-project] Interaction with Java
by Alexandre Bergel Dec. 12, 2008

Dec. 12, 2008

Dear List, Something is trotting in my head for few weeks. According to the mails exchanged on this list, it seems that interacting with C is of a high priority. I was wondering whether you had a similar need for talking to the Java world. Few months ago, I worked on Athena, a small Smalltalk VM written in Java. It can be interfaced with Squeak. This means that within Squeak, you can create Java objects and talking directly to them within Squeak. Is there anyone who need this? I am ready to continue on this, but I would like to be use case driven. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 2

Re: [Pharo-project] Interaction with Java
by Bill Schwab Dec. 12, 2008

Dec. 12, 2008

Alexandre, C has a fairly unique place among languages. We could debate how far that goes and the reasons for it, but a few that come to mind are: it arrived a long time ago; it was widely adopted; *nix lives by it. Pharo has to speak it. In most situations where I have used Dolphin's COM calling capabilities, it was either as a quick way to make something work (type libraries are pretty cool and Dolphin's type library analyzer is even cooler), or part of a desperate project-saving maneuver. As an example of the latter, I have some wrappers that do some very basic things with Word and Excel. They're ugly, but they work in a pinch. Beyond some simple device interfacing (e.g. A/D board), COM has not been of much use. COM you ask - I mean .NET, right? Don't get me started ;) Can we declare the vision of the software IC to be a complete failure? I submit that it did fail, and rather miserably. Further, I will suggest a reason for its failure: interfaces are difficult to get right, and most IDL specs I have encountered are proof of that, being cumbersome, inefficient, and never quite at the right granularity. There are exceptions, but most COMponents appear to be based on the first IDL design that didn't crash followed by a rush to market. Result == rubbish. Despite all of that, and the hideous condition of the MS Office IDL in particular, it did all come together to save my skin. Others might disagree, but I suspect a Java interface would fill a similar role: it would probably be limited to giving a rarely-used but much-needed bridge to something big. OpenOffice comes to mind, and there are probably others. When I need to do something in a static language (usually tight loops for number crunching or graphics), I end up working in C++ with extern "C". The no doubt makes my interest in C FFI all the larger, but I still maintain that it is the default. Anyone who turns to Java will of course find additional use for a Java interface. Like COM, I suspect Java would be something I would try to avoid using, but could find very useful in a pinch. Does that help? I'm trying to encourage you without overestimating the size of the "market." Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> Alexandre.Bergel(a)inria.fr 12/10/08 2:08 PM >>> Dear List, Something is trotting in my head for few weeks. According to the mails exchanged on this list, it seems that interacting with C is of a high priority. I was wondering whether you had a similar need for talking to the Java world. Few months ago, I worked on Athena, a small Smalltalk VM written in Java. It can be interfaced with Squeak. This means that within Squeak, you can create Java objects and talking directly to them within Squeak. Is there anyone who need this? I am ready to continue on this, but I would like to be use case driven. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

[Pharo-project] [update] #10189
by Marcus Denker Dec. 12, 2008

Dec. 12, 2008

10189 ----- - Issue 382: EmbeddedMenuMorph sends #startsWith: - Remove unset methods from Etoys - Clean up Preferences more - Finish revert methods in HandMorph for Hilaire - unload package 'SmaCC' - remove Preferences #collapseWindowsInPlace #clickOnLabelToEdit #alternativeWindowBoxesLook #extractFlashInHighQuality #extractFlashInHighestQuality #okToReinitializeFlaps #defaultFileOutFormatMacRoman Removed Methods in Detail: --------------------------- Viewer #nextCostume #previousCostume TileMorph #addArrows #codeString #isTileLike PhraseTileMorph #codeString #resultType #try TileLikeMorph #isTileLike Presenter #ownStandardPalette #stepDown:with: #updateViewer: Player #availableCostumesForArrows #bounce: #doScript: #emptyScript #getBorderStyle #getDropShadow #getLastKeystroke #getRadialGradientFill #getSecondColor #getShadowColor #getSpeed #getUseGradientFill #getValueFromCostume: #goToRightOf: #headDown #headLeft #headRight #headUp #includeAtCursor: #makeBounceSound: #makeNewDrawingIn: #moveToward: #overlaps: #pauseAll: #pauseScript: #rawCostume: #renderedCostume: #setAlpha: #setDropShadow: #setGraphic: #setLastKeystroke: #setLeft: #setRadialGradientFill: #setSecondColor: #setShadowColor: #setUseGradientFill: #turnToward: ListViewLine #objectRepresented: ObjectRepresentativeMorph #objectRepresented: Preferences class #alternativeWindowBoxesLook Preferences class #clickOnLabelToEdii #collapseWindowsInPlace #defaultFileOutFormatMacRoman #extractFlashInHighQuality #extractFlashInHighestQuality #okToReinitializeFlaps SystemWindow #relabelEvent: #updateBox:color: #updateBoxesColor: -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

1 0

[Pharo-project] another test ignore.
by StÃ©phane Ducasse Dec. 12, 2008

Dec. 12, 2008

3 2

[Pharo-project] Monticello Directory Repository
by Rob Rothwell Dec. 12, 2008

Dec. 12, 2008

Hello... Could someone tell me if I am just missing something so I can report this properly if I am? In a Pharo0.1 #10188 if I open Monticello and try to add a directory repository, I get a file list box but no "Ok" button! Thus, there APPEARS to be no way to select a directory. Am I just missing something? Take care,

3 2

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