- Pharo-dev - lists.pharo.org

[Pharo-project] [Progress Report] Zinc HTTP Components
by Sven Van Caekenberghe May 2, 2011

May 2, 2011

Hi, It has been quite a while, but here is another progress report on the Zinc HTTP Components project. First of all, Zinc HTTP Components has found a new home: http://zn.stfx.eu and more importantly, it is now self hosted, i.e. the pages you see are served by Zn, and all testing and debugging handlers are now available live. For more information regarding this production quality deploy, please see http://zn.stfx.eu/#livedemo The documentation pages have been updated a bit to better reflect the current status of the project. Second, I thank all people who contributed by testing Zn, giving feedback as well as for some of them actual code. Thank you, CÃ©drick BÃ©ler, Philippe Marschall, Esteban Lorenzano, Jan van de Sandt, StÃ©phane Ducasse, Andy Burnett, Norbert Hartl, Paul DeBruicker, HernÃ¡n Morales Durand and Tony Fleig. (I hope I didn't forget anyone). Thanks Lukas Renggli and Marcus Denker for adding Zn to their continuous integration servers. Sven Here is a list of changes since January of this year: - introduction of ZnUrl class - improved ZnStaticFileServerDelegate - introduced #asZnMimeType on ZnMimeType, MIMEType & String - Zinc-AWS proof of concept client - added lots of comments - several fixes to Zinc's Seaside adaptor, ZnZincServerAdaptor (encoding issues) - split of ZnNetworkingUtils from ZnUtils to separate related functionality - fixed ZnClient class>>#getImageOfType:usingParser:fromUrl: to correctly report responses with unexpected mime types - promoted ZnFixedClient>>#fixedUrl: to public status and changed it to accept ZnUrl objects as well for more flexibility (allowing users to add query/fragment URL elements in addition to the path) - ZnUserAgent (and ZnHttpClient) now can follow relative redirect locations - introduced ZnMultiValueDictionary to allow multiple values to be stored under one key as an array, using it for queries and headers - changed the redirect behavior for POST/PUT requests: the common practice is to turn these into GET request, see ZnUserAgent>>#method:for:headers:data:imit: and ZnUserAgent>>#prepareRedirect: - added simple ConfigurationOfZincHTTPComponents - added ZnByteEncoder to handle single byte encodings that do not map directly to the lower Unicode section (for example Latin2, ISO-8859-2) by reusing the mapping tables from ByteTextConverter - added #handlesEncoding: and #newForEncoding: protocol to class side of ZnCharacterEncoding hierarchy - added proper content length computation to ZnMultiPartFormDataEntity (bugfix) - some code cleanup to ZnEntity content length computation - added ZnUrl>>#queryDo: ZnApplicationForUrlEncodedEntity>>#fieldsDo: - added ZnMessage>>#resetEntity: to allow overwriting content type and length when these are already set - fixed a typo in the ZnMimePart instance creation methods (formdata should be form-data) - added ZnResponse>>#serverError: - implemented ZnHTTPSocketFacade class>>#httpPostMultipart:args:accept:request: - added ZnHTTPSocketFacade class>>#constructMultiPartFormDataEntity: - extended ZnZincServerAdaptor to handle multipart formdata posts (including file uploads) - introducing exception hierarchy in Zinc-HTTP-Exceptions - added ZnResponse>>#isNotModified - bugfix to Base64 encoding that introduced newlines - changed ZnZincServerAdaptor>>#defaultCodec to GRNullCodec - added new logging framework in Zinc-HTTP-Logging, consisting of ZnLogEvent (an Announcment), ZnLogSupport and ZnLogListener and subclasses ZnTranscriptLogger, ZnMemoryLogger and ZnFileLogger - now using the new logging facilities in Zn[Single|Multi]ThreadedServer, ZnFixedClient and ZnUserAgent - now using the new logging facilities in Zn[Single|Multi]ThreadedServer, ZnFixedClient and ZnUserAgent - small fix to ZnUrl>>#printPathOn: to deal with cases where forward slashes are encoded in URLs - various small changes related to the Gemstone port (byte array literals, Unicode creation) - fixed an important bug related to reading entities upToEnd The latest version now is: Name: Zinc-HTTP-SvenVanCaekenberghe.150 Author: SvenVanCaekenberghe Time: 1 May 2011, 7:19:13 pm UUID: 8fe0b470-7728-454d-bc90-fa42d8330817 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.149

4 4

[Pharo-project] strange loop
by StÃ©phane Ducasse May 2, 2011

May 2, 2011

this is strange I was trying to code a simple list of method browser and my browser seems to MorphExtension>>valueOfProperty: aSymbol "answer the value of the receiver's property named aSymbol" ^ extension ifNotNil: [extension valueOfProperty: aSymbol] I end up in a endless loop update: aParameter |state| aParameter ifNil: [^self]. getLabelSelector ifNotNil: [ aParameter == getLabelSelector ifTrue: [ (self labelMorph respondsTo: #font) ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] ifFalse: [self label: (model perform: getLabelSelector)]]]. state := self getModelState. (state ~= (self valueOfProperty: #lastState) or: [ ^^^ when I inspect self I get a PluggableButtonMorph but the method shown in the debugger is MoprhExtension?????? getStateSelector isNil and: [aParameter == #onOffColor]]) ifTrue: [self color: self colorToUse. self setProperty: #lastState toValue: state]. aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. getColorSelector ifNotNil: [ | cc | color = (cc := model perform: getColorSelector) ifFalse: [ color := cc. self onColor: color offColor: color. self changed ]].

2 4

[Pharo-project] Best strategy for ConfigurationOfPharo using #stable
by Mariano Martinez Peck May 1, 2011

May 1, 2011

Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want that ConfigurationOfPharo doesn't explicitly load a specific version of every project but instead, the #stable. First step I need to do (I will try to do it during the weekend) is to update #stable in each of the ConfigurationOf used by ConfuigurationOfPharo. That's an easy part. Now, my question is...I don't really understand how the confs would look like after. I mean, 99% of the cases (in fact, at the beginning it will be 100% until I find a problem), the version I use will be #stable. So,the version of ConfgiruationOfPharo AND all the Configurations used by ConfgiruationOfPharo would look something like this: spec project: 'Autotest' with: #stable; project: 'Autotest Help Tests' with: #stable; project: 'MemoryMonitor' with: #stable; project: 'XMLSupport' with: #stable; I mean...every single project reference will have #stable instead of a specific version. So...is this expected? is this the way I should do it ? Finally...is there a query I can do to Metacello saying "which are the ConfigurationsOf needed for this version for this group of this Conf" ? Thanks -- Mariano http://marianopeck.wordpress.com

3 6

[Pharo-project] I need help with 13380
by StÃ©phane Ducasse May 1, 2011

May 1, 2011

Hi guys I need help. I do not know why the image is so slow at startup and also why I cannot really bring an interrupt. Tomorrow I'm traveling. So no time to look at that. Stef

3 3

[Pharo-project] suspicion update: method in MorphExtension
by StÃ©phane Ducasse May 1, 2011

May 1, 2011

Hi guys I have a problem with a PluggableButtonMorph and I end up in this MorpExtension>>update: aParameter |state| aParameter ifNil: [^self]. getLabelSelector ifNotNil: [ aParameter == getLabelSelector ifTrue: [ (self labelMorph respondsTo: #font) ifTrue: [self label: (model perform: getLabelSelector) font: self labelMorph font] ifFalse: [self label: (model perform: getLabelSelector)]]]. state := self getModelState. (state ~= (self valueOfProperty: #lastState) or: [ getStateSelector isNil and: [aParameter == #onOffColor]]) ifTrue: [self color: self colorToUse. self setProperty: #lastState toValue: state]. aParameter == getEnabledSelector ifTrue: [^self enabled: (model perform: getEnabledSelector)]. getColorSelector ifNotNil: [ | cc | color = (cc := model perform: getColorSelector) ifFalse: [ color := cc. self onColor: color offColor: color. self changed ]]. To me it looks suspicious that MorphExtension does that for all the morph.... Stef

5 6

[Pharo-project] Fwd: ServiceAction and ServiceRegistry
by StÃ©phane Ducasse May 1, 2011

May 1, 2011

Begin forwarded message: > From: Markus Fritsche <fritsche.markus(a)googlemail.com> > Date: May 1, 2011 10:33:02 PM GMT+02:00 > To: pharo-users-owner(a)lists.gforge.inria.fr > Subject: ServiceAction and ServiceRegistry > > Hello, > > looking at the 1.3 image, I see that ServiceAction/ ServiceRegistry > have been deprecated. Is there any information how they've been > replaced? > > Tia, Markus >

1 0

Re: [Pharo-project] ConfigurationOfMagma with support for Magma 1.2 and symbolic versions
by Miguel CobÃ¡ May 1, 2011

May 1, 2011

Hi Marco, this is a problem caused by running the update process on a Pharo image. The update process is enabled only on PharoCore image precisely to avoid this problem, that is, that the update process break some package installed (or some overriden method from some package) by updating the method with an uncompatible version. The problem here is that the class SHParserST80 isn't anymore in the image and is used by OContext of the package OCompetion. You can open a ticket with this problem in the issue tracker in order to not forget it. Cheers El dom, 01-05-2011 a las 10:31 -0400, Marco A. Gonzalez escribiÃ³: > First, Thank you Miguel and Chris for working to get Magma working with Pharo. > > I ran into the following problem while attempting to get Magma installed into Pharo. After updating the image to version 12351, and I try to type anything into the Workspace window, I get a dialog with the following message: > MessageNotUnderstood: AnObsoleteSHParserST80>>rangesIn:classOrMetaClass:workspace:environment: > > I don't know where to go from there. I'm stuck. What's the best way to report this? Who do I report it to? Is there another one-click that I can use Magma with? > > Here's what to do to reproduce the problem. > > 1. Download Pharo 1.2.1 one-click image (standard VM) from http://www.pharo-project.org/pharo-download/ > NOTE: I wanted to use the one-click because I know how to deploy it on my web host and I don't know how to deploy a non-one-click image. > > 2. In a Workspace window, I evaluated the following: > SystemVersion newVersion: 'Pharo1.2.2a'. > > (this didn't appear to do anything) > > 3. From the World menu, choose System > Software Update > It took a few minutes, less than 5 minutes I think. Then a dialog window titled "Information" displayed with "6 new update file(s) processed." in the content area. > > 4. Then when I went to install Magma by typing into the Workspace window, the error message appeared. > > > - Marco A. > > On Apr 27, 2011, at 12:35 PM, Miguel CobÃ¡ wrote: > > > Hi all, > > > > I'm glad to announce a new version of ConfigurationOfMagma with support > > for Magma 1.2. This configuration has been tested on > > > > PharoCore 1.1.x > > PharoCore 1.2.x > > > > Thank you very much to Chris Muller who, as always, is working hard to > > keep Magma running on Squeak and Pharo. I used the same versions of > > packages he used in his scripts for Squeak in order to update the > > configuration. > > > > You must download the latest PharoCore image or update a existing one > > before installing Magma, as Magma needs some changes that were applied > > to Pharo post-release and are available in the update stream. > > > > > > Pharo 1.1.x > > ------------ > > > > Download PharoCore 1.1.2 from: > > > > https://gforge.inria.fr/frs/download.php/28341/PharoCore-1.1.2.zip > > > > Update it if necessary and save it. > > > > > > Pharo 1.2.x > > ------------ > > > > You have two options: > > > > 1. Take a released 1.2.1 from: > > > > http://www.pharo-project.org/pharo-download/stable-core > > > > This is actually image update 12345. Evaluate: > > > > SystemVersion newVersion: 'Pharo1.2.2a'. > > > > update the image (it will update to 12350, at this time) and save it. > > > > 2. Take a snapshot of the upcoming 1.2.2 release of Pharo 1.2.x line > > from: > > > > https://gforge.inria.fr/frs/download.php/28436/PharoCore-1.2.2a-12345.zip > > > > update the image (it will update to 12350, at this time) and save it. > > > > > > Install Magma > > -------------- > > > > Ok, now you have an updated image. Load the configuration by evaluating: > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfMagma'; > > load. > > > > And depending on which of client, server or the full suite of Magma do > > you want, evaluate: > > > > - Magma client > > > > ((Smalltalk at: #ConfigurationOfMagma) > > project version: #stable) load: 'Client'. > > > > > > - Magma server > > > > ((Smalltalk at: #ConfigurationOfMagma) > > project version: #stable) load: 'Server'. > > > > - Magma tester > > > > ((Smalltalk at: #ConfigurationOfMagma) > > project version: #stable) load: 'Tester'. > > > > For example, to load the full magma suite evaluate: > > > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfMagma'; > > load. > > ((Smalltalk at: #ConfigurationOfMagma) > > project version: #stable) load: 'Tester'. > > > > This will load client, server and test of Magma. > > > > > > Running tests > > ------------- > > To run the tests evaluate: > > > > MagmaTestCase allowWriteBarrier: false. > > MagmaTestCase fullSuite maDebug. > > > > > > Stable versions > > --------------- > > > > This release of ConfigurationOfMagma includes support for Metacello's > > symbolic versions. Currently the #stable version of Magma is configured > > like this: > > > > Pharo version #stable version > > ------------- --------------- > > Pharo 1.1.x 1.2 > > Pharo 1.2.x 1.2 > > Pharo 1.3.x 1.2 > > > > That is, Magma 1.2 is the #stable version for Pharo 1.1, Pharo 1.2 and > > Pharo 1.3. > > > > Known issues > > -------------- > > > > Magma 1.2 loads correctly and appears to work for the basic things > > (create a repo, add data, commit, etc) in PharoCore 1.3 and Pharo 1.3, > > but the full suite hasn't ran correctly in the current unstable Pharo. > > So use Magma 1.2 on Pharo 1.3 on your own risk and not for production > > yet. When the issues (including the Transcript revert that should happen > > in Pharo soon) are addressed, a new announce will be made for Magma on > > Pharo 1.3 > > > > Any feedback welcome. > > > > Enjoy. > > -- > > Miguel CobÃ¡ > > http://twitter.com/MiguelCobaMtz > > http://miguel.leugim.com.mx > > > > > > > > > > > > _______________________________________________ > > Magma mailing list > > Magma(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > > > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

3 5

May 1, 2011

13179 ----- - Issue 4138: AnnouncementSpy rewritten without ToolBuilder. - Issue 4141: Cleaned a bit ChangeSorter - Issue 4139: Small CodeCritique cleanup. - Issue 4134: Package SUnitGUI is dirty and almost empty. - Issue 4137: Move more methods to Compatibility Package. Stef

1 0

[Pharo-project] Zn HTTP Clients accessing Google HTTPS using stunnel and delicious.com
by Sven Van Caekenberghe May 1, 2011

May 1, 2011

Hi, I think that I solved the underlying bug that surfaced with Esteban's problem accessing Google HTTPS using stunnel as well as Andy's problem accessing delicious.com (both were related) - for the technical details see below. The following expressions should now return true (tested with Pharo 1.2.1 on Mac OS X and Linux, Pharo Core 1.3 on Mac OS X). (ZnHttpClient new url: 'http://delicious.com'; get) includesSubString: 'Delicious' --- ; assuming stunnel is running with a config including client = yes [google] accept = 20011 connect = encrypted.google.com:443 --- (ZnHttpClient new url: 'http://127.0.0.1:20011'; get) includesSubString: 'SSL' Please let me know if your code now works as well. Thanks again, Esteban, Andy and Matt for pushing these issues ! Sven PS: please note that for now, only ZnHttpClient follows redirects, not the simpler ZnClient and the implementation of ZnHTTPSocketFacade. ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.150 Author: SvenVanCaekenberghe Time: 1 May 2011, 7:19:13 pm UUID: 8fe0b470-7728-454d-bc90-fa42d8330817 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.149 fixing a problem where responses without an explicit content-length but with an entity where not read as they should (thanks Esteban Lorenzano & Andy Burnett for reporting this): - ZnResponse>>#entityReaderOn: now extends the super entityReader with the #allowReadingUpToEnd option - ZnEntityReader>>#entityReader now swallows entities when they are #isEmpty (making them nil) - ZnStringEntity>>#readFrom: is split between #readLimitedFrom: and #readUpToEndFrom: where the last method has extra error handling to swallow ConnectionClosed exceptions (similar to what SocketStream>>#upToEnd does) - the ZnEntity hierarchy now implements #isEmpty

1 0

[Pharo-project] I am the only one who finds #assert:equals: oppostite to expected?
by Mariano Martinez Peck May 1, 2011

May 1, 2011

Hi guys. I always code my tests something like this: testBlah | universalAnswer | universalAnswer := 30. universalAnswer := universalAnswer + 11. self assert: universalAnswer equals: 42. In this case, 42 is the "expected" and "universalAnswer" is the "actual" value. I feel weird writing like this: self assert: 42 equals: universalAnswer. I don't know why...but I do..the same as when doing should: [] raise: Error. In that case you put the "actual" first and the "expected" at the end... ok....the "problem" is that assert:equals: is in fact: asserts: expected equals: actual instead of asserts: actual equals: expected So, with my test I would receive a description in the debugger that says "'Expected 41 but was 42.'" which is completely the opposite. Of course, if I write my tests in the way I don't like, that is: self assert: 42 equals: universalAnswer. then i got the correct message "'Expected 42 but was 41.'" I don't pretend pharo change this because I guess it is standard, and blah blah blah. But senders of #assert:equals: should both, some written as mine (so the message is incorrect for them) and some correct. In addition, I think it is a problem of the selector name. If we could make it clearer, the won't be necessary to confuse "actual" with "expected". Cheers -- Mariano http://marianopeck.wordpress.com

8 15