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

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

[Pharo-project] [update 1.3] #13179
by StÃ©phane Ducasse May 1, 2011

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

[Pharo-project] Fwd: Pharo support for magma repositories
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 4:56:48 PM GMT+02:00 > To: pharo-users-owner(a)lists.gforge.inria.fr, magma(a)lists.squeakfoundation.org > Subject: Pharo support for magma repositories > > Hello, > > I registered a project at squeaksource: > http://www.squeaksource.com/MagmaPharoSupport.html > > In my pharo image ;-) (I will check loading in a clean pharo image in > a bit) this enables using (local, server not yet tested) magma > repositories with the Pharo version of Monticello. It also alters the > cleanup-method of MagmaSession to be working with Pharo (PointerFinder > vs. ProtoObject>>#pointersTo). > > If anyone wants to join the project, you're welcome. > > Pharo version: > Pharo1.3a > Latest update: #13177 > > Magma: > Ma client server cmm.217 > Ma base additions cmm.187 > Magma server cmm.425 > > > Kind regards, > Markus Fritsche >

1 0

[Pharo-project] HelpBrowser takes too much time to open
by Mariano Martinez Peck May 1, 2011

May 1, 2011

MessageTally time: [HelpBrowser open] between 2 seconds in Cog and with a regular VM between 6 and 8.... is there an easy way to improve it ? Alexandre, do you want another place where to put a cache like Metacello's currentVersion? ;) Cheers -- Mariano http://marianopeck.wordpress.com

3 9

[Pharo-project] Zinc problems found
by Esteban Lorenzano May 1, 2011

May 1, 2011

Hi, I found some problems on Zinc implementation. Take this example: HTTPSocket httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' args: (Dictionary new at: 'prettyprint' put: #('true'); yourself) accept: '*/*' request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} this, if I have the correct authentication key, gives me the correct answer (an atom-xml response). Now, if I try: ZnHTTPSocketFacade httpGetDocument: 'http://127.0.0.1:333/analytics/feeds/accounts/default' args: (Dictionary new at: 'prettyprint' put: #('true'); yourself) accept: '*/*' request: ('Authorization: GoogleLogin Auth={1}{2}' format: {self authenticationKey. String crlf} (this should work, as the facade is for compatibility, I think) I have two errors, one of them easily solvable, and the other... well... I couldn't solve it in the 15' I spent on it :) 1) arguments are not in the correct way. While HTTPSocket functions expect something like this: Dictionary new at: 'prettyprint' put: #('true'); "<-- Parameter is an array" yourself. ZnHTTPSocketFacade expects something like this: Dictionary new at: 'prettyprint' put: 'true'; "<-- Parameter is a string" yourself. 2) This is the hard one. If you do the get request with parameter fixed, you should get the atom feed. But you don't. You get a ZnResponse who is OK (status 200), but entity is empty. I followed the error until this method: canReadContent ^ self hasContentLength or: [ self isChunked or: [ self allowsReadingUpToEnd ] ] who return false, because none of the questions is true. Then, no entity is filled, and I have no answer :( Hope this help :) Cheers, Esteban

2 3