- Pharo-dev - lists.pharo.org

[Pharo-project] whileTrue: implementation
by Hernan Wilkinson Aug. 18, 2010

Aug. 18, 2010

Hi, when I'm teaching OO one of the most interesting subjects is the implementation of control flow structures with closures. Having to implement #ifTrue: only with objects and messages produces in some students the "click" we are looking for, the "ah!" that makes them see the real difference with procedural languages and most no pure object languages (java, c#, etc). When teaching the execution model, I use the #whileTrue: implementation to show them that it is also possible to implement such a thing with just objects and messages. The last semester to my surprise I saw that the #whileTrue: implementation in Pharo is cumbersome, at least for teaching porpoises, because it is based on the "hidden" detail that #whileTrue: is inlined, therefore never sent and its method never executed. The VisualWorks implementation is clearer because it is a recursive implementation that seems to work without knowing that #whileTrue: is inlined (and has a nice comment that explains that implementation detail). Anyway, just for teaching porpoises I thought that providing another implementation would be nice, an implementation based on the execution context, an implementation completely based on objects and messages. For example: whileTrue: aBlock self value ifTrue: [ aBlock value. thisContext restart ] I think it is an interesting example that allows the students to see how we can manipulate the execution environment from inside Smalltalk itself... Anyway, just a comment... not sure if it makes sense to change the implementation just because of this, but maybe putting a comment explaining this option would be nice. Bye, Hernan.

6 5

[Pharo-project] test
by Fernando olivero Aug. 18, 2010

Aug. 18, 2010

1 0

[Pharo-project] TextEditor>>possiblyChanged broke TextEditor quite well :(
by StÃ©phane Ducasse Aug. 18, 2010

Aug. 18, 2010

> > From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: August 17, 2010 10:46:05 PM GMT+02:00 > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: TextEditor>>possiblyChanged broke TextEditor quite well :( > > > Hi fernando > > apparently in TextEditor>>stateArrayPut: stateArray there is call to possiblyChanged which does not exist in pharo or Squeak > > TextEditor>>stateArrayPut: stateArray > | sel | > sel := stateArray at: 1. > self selectFrom: sel first to: sel last. > beginTypeInBlock := stateArray at: 2. > emphasisHere := stateArray at: 3. > morph possiblyChanged > > And this breaks the system when I try to integrate the ParagraphEditro replacement.... lost laready a couple of hours > > In CUIS it is defined as > > > PluggableTextMorph>>possiblyChanged > "A hook for notificating possible interested parties > Not used in base system" > > > TextMorph>>possiblyChanged > > TextMorphForEditView>>possiblyChanged > editView possiblyChanged > > > So? > Do we need that? if not we should remove all the senders > Stef > > > > > > >

2 2

[Pharo-project] About porting and using the classificationModel in Pharo
by Fernando olivero Aug. 18, 2010

Aug. 18, 2010

Hi, is there a port to Pharo1.2 of the ClassificationModel. (http://scg.unibe.ch/archive/papers/Wuyt04aClassifications.pdf) If not would the Star Browser for Squeak , be a good place to start from? http://map.squeak.org/package/9187f67b-a437-4e52-93f9-eecb9b48df78 Thanks Fernando

2 1

[Pharo-project] adding ISO-8859-15 and CP-1252 support
by Philippe Marschall Aug. 18, 2010

Aug. 18, 2010

Hi I decided to write ISO-8859-15 and CP-1252 support [1] (mostly for selfish reasons so that Seaside on Pharo would support ISO-8859-15 and CP-1252). A couple of notes: - the five unmapped bytes of CP-1252 (not ISO-8859-15, the comment is wrong) are mapped to the Unicode replacement character (U+FFFD) - a new Latin9 language environment is introduced - some minor clean up like removing unused class variables I'd appreciate it if somebody knowledgeable in these areas could review the changes. I'm especially unsure about the Latin9 language environment, but reusing Latin1 or Unicode seemed wrong. [1] http://code.google.com/p/pharo/issues/detail?id=2812 Cheers Philippe

4 5

[Pharo-project] [update 1.2] #12098
by Marcus Denker Aug. 18, 2010

Aug. 18, 2010

12098 ----- Issue 2826: add empty PluggableButtonMorphPlus Issue 2824: PluggableTextMorphWithModel is not used Issue 2333: MCSnapshotBrowser>>allClassNames would incorrectly list the classe -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Streams - a first draft
by Schwab,Wilhelm K Aug. 17, 2010

Aug. 17, 2010

Hello all, Dolphin's streams signal errors on exhaustion, with a few clear exceptions. I quickly learned to appreciate the clarity. If I tell a stream to read 10 bytes, there is probably a reason for it, and I might want to be alerted if there are not that many bytes remaining, or in the case of a socket, I might want it to wait until there are that many or until the connection is broken. If a file cannot be opened, I want to know then, rather than after the offending method has returned and I have to hunt down what went wrong. What is you want at most ten bytes? There is a way to get that: #nextAvailable:. It and friends offer clear permission from you the programmer to the computer to truncate and return. This approach sometimes requires an #atEnd check or two, but it is worth the effort. I have described the problems and solutions here: http://code.google.com/p/pharo/wiki/ProposalForConsistentStreamsBehavior http://code.google.com/p/pharo/wiki/StreamsForRobustSoftware #next is not portable, and is IMHO just plain broken on Squeak, Pharo, and VW. #next: does not work as advertised on some platforms. But there is nothing to stop me (and you) from writing code in terms of selectors such as #nextOne and #nextMany:. It is some extra typing, but it can be done now: I've been doing it the entire time I have made serious use of Pharo. I am *STILL* finding places in which file streams do annoying things (such as prompting "the user" on my server [argggggg!!!!!!<g>], but I will eventually identify them and code around them. Consider this preliminary, but here is some code: http://squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.… Bill

1 0

[Pharo-project] ODBC extension
by Schwab,Wilhelm K Aug. 17, 2010

Aug. 17, 2010

I have a small group of packages that might be of interest to people porting code from Dolphin. By far the least controversial of these packages is a small addition to the ODBC packages. I have included a few things (e.g. #sqlCleanup) that I added to my Dolphin images and either needed or simply wanted in Pharo. Use them or ignore them as you see fit. Of perhaps general interest are methods to access schema information: #tables and #columnsForTable:owner:. The package is in the inbox: http://squeaksource.com/PharoInbox/DolphinCompatibility-ODBC-BillSchwab.2.m… Bill

2 2

Aug. 17, 2010

Hi guys I'm slowly going over the changes proposed by guillermo to remove ParagraphEditor (thansk guillermo). Now I think that this is important that we do not remove instance creation methods or method deprecated too fast. This is important that we let a chance to people to migrate. This is why we will remove the deprecate method of 1.1 when we will start 1.3 and not when we started 1.2. Stef

1 0

[Pharo-project] Pharocasts: Display Picasa photos
by laurent laffont Aug. 17, 2010

Aug. 17, 2010

Learn: - how to get data from an URL - parse XML documents - build a GUI to display photos with Polymorph - how to prototype quickly with debugger and inspector http://pharocasts.blogspot.com/2010/08/see-how-to-get-data-from-url-parse-x… Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

7 16