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

[Pharo-project] Have PHUN Libs included ...
by stepken May 14, 2009

May 14, 2009

Hello Smalltalkers! http://www.phunland.com/wiki/Home Have a look at that Game. It's a simple - one-man show (Emil Ernerfeld), MSc- thesis, 6 man-month of work. There behind are C++ libs, written by Claude LacoursiÃ¨re), ported to Mac OS X, Linux, Windows. As far as i can see, ETOYS (perhaps CROQUET) Jono Porter: C#, .NET http://video.msn.com/video.aspx?mkt=de-de&vid=62786555-9ea2-42de-bdce-0f297… There behind: http://code.google.com/p/physics2d/ Erin Catto: http://www.box2d.org/ http://mac.softpedia.com/get/Developer-Tools/Box2D.shtml available for Flash also. See: http://www.crayonphysics.com/ Erwin Coumans Bullet 3D engine: http://www.geeks3d.com/public/jegx/200808/bullet-physics-sdk.jpg C-Engine by Scott Lembke: http://www.slembcke.net/photos/v/programming/chipmunk/ , see http://howlingmoonsoftware.com/scribball.shtml Newton Game dynamics engine, be inspired .... http://www.newtondynamics.com/downloads.html

2 1

[Pharo-project] "Memoization" techniques?
by stepken May 14, 2009

May 14, 2009

SalÃ»t! http://en.wikipedia.org/wiki/Memoization http://wiki.tcl.tk/3740 http://wiki.tcl.tk/13004 G.S.

2 1

[Pharo-project] SqueakDocs an iphone electronic book hits App store.
by John M McIntosh May 14, 2009

May 14, 2009

I was pleased to get notification that my Squeak & Pharo Smalltalk electronic books went up for sale on the App Store this afternoon. Sadly WikiServer http://www.mobilewikiserver.com a much more complex application is still stuck in the review process. Basically the two books are Seaside apps that use an altered Seaside class browser to give you a READ-ONLY view of all the source code from a 3.10.x Squeak web image, or Pharo web dev image of late April 2009. Squeak -> http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=315289375… Pharo -> http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=315254856… Unfortunately because I have to recoup the $$$ I send Apple each year for developer fees and deal with support issues means they are not free. I will discuss these apps and how they were developed in detail at ESUG 09. http://www.esug.org/Conferences/2009/Current+List+of+Talks People who need a promo coupon to review & use the app without having to pay the iTunes store can email me privately, I have a limited number of these to hand out. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

[Pharo-project] fastDragWindowsForMorphic locks up UI
by Rob Rothwell May 13, 2009

May 13, 2009

Can someone confirm that fastDragWindowForMorphic locks up the UI in 10303 as soon as you try to move a window? I'll log an issue if it's not just me... Rob

6 13

[Pharo-project] StringTest>>testUnescapePercentsWithTextEncoding is broken
by Oscar Nierstrasz May 13, 2009

May 13, 2009

While checking if tests for the Squeak by Example book still work under Pharo, I discovered that StringTest>>testUnescapePercentsWithTextEncoding is broken. Trying to track this down, I saw that Michael Rueger changed the last line of ShiftJISTextConverter>>nextFromStream: from ^ self toUnicode: result to: ^ self byteToUnicode: result which seems to break the test. I can't say that I understand what is going on here, but shouldn't we roll back this change? Else rewrite the test ... - on

2 2

[Pharo-project] Can't update OB in latest pharo image
by Oscar Nierstrasz May 13, 2009

May 13, 2009

OK, so I succeeded to update the last pharo-dev image to the latest changes. Then I tried to update OmniBrowser: ScriptLoader loadOB. This causes a MessageNotUnderstood: MIMEType>>indexOf: Can anyone reproduce this error? http://source.wiresong.ca/ is up again so it should work ... - on

1 0

[Pharo-project] Standardisation of Interfaces within Pharo/Squeak ...
by stepken May 13, 2009

May 13, 2009

Hello! Don't know, how much sense it makes, when i ask for "standardisation", portability .... There are a few (less active) projects floating around in the world wide waiste, e.g. SPORT: http://sourceforge.net/projects/sport/ http://camp.smalltalk.org/ Even within Squeak i had several incompatibilities with .pr files. I really hate that. We here have/had the smtalltalk elite at work, seeming being unable to solve such standard problems ... Second problem: Monticello is not failsafe. I slowed down my internet connection and pulled the plug from time to time during download of updates ... What happened? .... Errors, unresolvable ... I had to shut down Pharo, to repeat the update. I would call that "not transactional ...", "failsafe", "whatever" ....... Please ... you mastersmalltalkers ... this is a minimum standard to be fullfilled nowadays ... And i can't close that window "World->System->About" at 1024x768 resolution .... hmmm .... tnx, Guido Stepken

4 4

[Pharo-project] Questions about the debugger
by Hernan Wilkinson May 13, 2009

May 13, 2009

Hi, I'd like to be able to open the debugger without the notifier... when programming the notifier does help really (at least to me...). I modified StandarToolSet class>>debugError: anError to pass true as parameter to the full: keyword of #debug:title:full, but I was wondering if there was a preference to do this whitout modifying the code. Also, what does the class OTToolset do? The DevToolSet delegates to it the messages when installed, but the pharo image does not have it install. And the last question!, I'd like the debugger to open in a bigger window. I know I can press the "expand to full screen" button, but I'd like the debugger window to be 3/4 of the screen when opened automatically. I did not find a way to configure that... does it exist? if not, what is the message I should send to the debugger morph to do that? Thanks! Hernan

2 1

[Pharo-project] Preference to settings refactoring: #annotationPanes case
by Alain Plantec May 13, 2009

May 13, 2009

http://code.google.com/p/pharo/issues/detail?id=810 Alain ---------------------------------------------- annotationPanes : "if true, a thin horizontal pane is used in browsers" We have 3 implementations : Old browser and MC implementation in Pharo-core and OB one in Pharo-dev. Pharo-core Old browser implementation: It first relies on the #annotation related methods. (changed: #annotation, Browser>>annotation, ChangeList>>annotation, CodeHolder>>annotation). CodeHolder>>wantsAnnotationPane is the only user of the annotationPanes preference. CodeHolder>>addOptionalAnnotationsTo: window at: fractions plus: verticalOffset is the only user of wantsAnnotationPane. It has two senders: Browser>>openAsMorphMessageEditing: and CodeHolder>>addLowerPanesTo: window at: nominalFractions with: editString. method source with #annotation gives more interesting results such as: CodeHolder>>refreshAnnotation "If the receiver has an annotation pane that does not bear unaccepted edits, refresh it" (aPane := self dependents detect: [:m | (m inheritsFromAnyIn: #('PluggableTextView' 'PluggableTextMorph' )) and: [m getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | aPane hasUnacceptedEdits ifFalse: [aPane update: #annotation]] other "cool" pieces of code: PluggableTextMorph>>accept .... ok := self acceptTextInModel. ok == true ifTrue: [self setText: self getText. self hasUnacceptedEdits: false. (model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNilDo: [:aPane | model changed: #annotation]]. ... PluggableTextMorph>>cancel self setText: self getText. self setSelection: self getSelection. getTextSelector == #annotation ifFalse: [(aPane := model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | model changed: #annotation]] The displayed annotation is set only when a browser or message list is opened. Then, displayed information concerns only the method on which the browser is opened or only the method FROM which sender/implementor message list is opened. The annotation is never updated even a new method is selected. Pharo-core MC implementation: MCSnapshotBrowser, MCPatchBrowser, MCMergeBrowser: display (well) annotation when a method is selected. The method author initials, the date and the time of change and the category are displayed. Note that the height of the pane is sometime too thin, depending on the height of the font. When a vertical scrollbar is shown, the pane is always too thin. The implementation relies on #annotations and #annotations: methods. #annotations implementations MCCodeTool>>annotations (subclassresponsibility) ok MCConflict>>annotations ok MCPatchBrowser>>annotations ok MCSnapshotBrowser>>annotations ok MCDefinition>>annotations and MCPatchOperation>>annotations make use of Preferences class>>defaultAnnotationRequests. Preferences class>>defaultAnnotationRequests ^ Parameters at: #MethodAnnotations ifAbsent: [self setDefaultAnnotationInfo "Preferences annotationInfo"] #annotations: implementations MCDefinition>>annotations: and MCPatchOperation>>annotations: are the same MCDefinition>>annotations: requests "Answer a string for an annotation pane, trying to fulfill the annotation requests. These might include anything that Preferences defaultAnnotationRequests might return. Which includes anything in Preferences annotationInfo To edit these, use:" "Preferences editAnnotations" ^ String streamContents: [:s | self printAnnotations: requests on: s] MCSnapshotBrowser>>annotations: stuff self changed: #annotations The displayed data is given by Preferences annotationInfo which is supposed to be adaptable with the help of a specific tool opened with Preferences editAnnotations. The annotation is well updated each time a new method is selected. I didn't succeed in making Preferences editAnnotations work. Found the implementation clean except the Preferences annotationInfo/editAnnotations part. Pharo-dev OB implementation Relies on a OBAnnotationPanel for the view and on the OBSelectionChanged announcement for the annotation update. It works well. The implementation is simple and clean (The only bad point I've found is that, as for the Pharo-core MC implementation, the height of the panel is fixed whereas it should be dynamically computed from current code font height) action: Would remove the annotationPanes preference from pharo-core and make an OBBrowser specific setting. Why: because old browser implementation is really confusing and dirty and because it do not give useful feedback to the user. Would also remove MC implementation because it is not used by default and I think that MC user do not care about it. If people want to keep it, then it should not relies on a specific setting. Anyway, the Preferences annotationInfo/editAnnotations part should be removed. Consequence: Clean/remove all annotation related code from Pharo-core. Ask OB maintainers to add an OB specific settings as follow: OBCodeBrowser class>>showAnnotationPanel <setting> ^ ShowAnnotationPanel ifNil: [ShowAnnotationPanel := (SettingManager newSetting: 'Show annotation panel') default: true; parent: #obBrowsing; description: 'If true, a thin horizontal panel is used in browsers. The annotation panel is used to display useful informations about the selected method'] I will propose a .cs for the cleaning of Pharo-core when I will know what to do with MC implementation (keep, remove, ok to keep with cleaning?). Then I will propose a .cs to OB maintainers for Pharo-dev. Alain -------------------------------------

1 0

[Pharo-project] Bug in FTPClient
by Nicolas Cellier May 13, 2009

May 13, 2009

There are two bugs in this code: lookForCode: code ifDifferent: handleBlock "We are expecting a certain numeric code next. However, in the FTP protocol, multiple lines are allowed. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space. So it's possible that there are more lines left of the last response that we need to throw away. We use peekForAll: so that we don't discard the next response that is not a continuation line." | headToDiscard | "check for multi-line response" (self lastResponse size > 3 and: [(self lastResponse at: 4) = $-]) ifTrue: ["Discard continuation lines." [headToDiscard _ self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]]. ^ super lookForCode: code ifDifferent: handleBlock 1) it attempts to catch Exception, which is generally a bad idea. Error would be more appropriated. 2) but the whole ifTrue: conditions is a no-op: it simply creates a block that is not used. Maybe intention was: ifTrue: ["Discard continuation lines." headToDiscard := self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]. Is this code used?

1 0