- Pharo-users - lists.pharo.org

Re: [Pharo-users] TestCase question

by StÃ©phane Ducasse

>>> >> >> >> Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: >> >> #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. >> But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. >> >> Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? > > I would never have guessed that in a million years. welcome to the time traveling machine it is a bit ugly and nobody should rely on such bad behavior. Consider that it should not exist. Stef

April 13, 2011

Re: [Pharo-users] TestCase question

by Pat Maddox

On Apr 12, 2011, at 3:24 PM, Simon Denier wrote: > > On 12 avr. 2011, at 23:47, Werner Kassens wrote: > >> hi, >> i have a testsuite that is a subclass of TestCase with this method: >> >> testStupid >> |a| >> a :=#(1). >> self assert: a first isNumber . >> a :=a at:1 put: nil. >> >> if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? > > > Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: > > #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. > But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. > > Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? I would never have guessed that in a million years. Pat

April 13, 2011

Re: [Pharo-users] TestCase question

by Werner Kassens

ah, got it! thanks werner

April 12, 2011

Re: [Pharo-users] TestCase question

by Simon Denier

On 12 avr. 2011, at 23:47, Werner Kassens wrote: > hi, > i have a testsuite that is a subclass of TestCase with this method: > > testStupid > |a| > a :=#(1). > self assert: a first isNumber . > a :=a at:1 put: nil. > > if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? Interesting, I would never have guessed the test would be broken at first sight. So maybe some people enlightened in the ways of the compiler can provide a better explanation than me. Here is my guess: #(1) is a special construct which creates a compile-time array. The compile-time makes the trick: in short the array is more or less encoded directly into the bytecodes of the method as a constant. But modifying the array with #at:put: directly modifies the bytecodes in the compiled method itself. So you create a side-effect directly into your method. Am I the only one to find this a bit dangerous and not intuitive? Is it a well-known behavior? A correct way to fix that would be to use a dynamic array {1} or define a setUp method which would initialize the array before each run. -- Simon Denier

April 12, 2011

Re: [Pharo-users] TestCase question

by Sven Van Caekenberghe

Hi Werner, On 12 Apr 2011, at 23:47, Werner Kassens wrote: > hi, > i have a testsuite that is a subclass of TestCase with this method: > > testStupid > |a| > a :=#(1). > self assert: a first isNumber . > a :=a at:1 put: nil. > > if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? > > werner You are destructively modifying a constant, the literal array #(1), of which there is one instance attached to #testStupid'd compiled method. Sven

April 12, 2011

TestCase question

by Werner Kassens

hi, i have a testsuite that is a subclass of TestCase with this method: testStupid |a| a :=#(1). self assert: a first isNumber . a :=a at:1 put: nil. if i run the test once, it succeeds, but but when i run it a second time it fails. this seems to be sligthly counterintuitive, or how do i have to understand it? werner

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by StÃ©phane Ducasse

> > Ah I thought that all code pushed to PharoInbox was already MIT by default. yes it is but we are paranoid and serious about it :) > Anyway I think I found the license agreement. Is this one still up-to-date? > <http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf> > > And is the fax number listed there i.e. 00 33 3 59 57 78 5 still the right > one? you are missing a digit Fax 33 3 59 57 78 50 > I will fax it over today. > > Thanks! > > -- > Nick > > > -- > View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > ------------------------ Dr. StÃ©phane Ducasse -- Directeur de Recherche (Senior Researcher) INRIA - USTL - CNRS UMR 8022 stephane.ducasse(a)inria.fr http://stephane.ducasse.free.fr http://rmod.lille.inria.fr/ **NEW ***Tel 00 33 (0)3 20 43 42 56 - Fax 33 3 59 57 78 50 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza, Villeneuve d'Ascq, FR-59650, France.

April 12, 2011

Re: [Pharo-users] [Seaside] [ANN] Seaside Tutorial Ready for 3.0

by Mariano Martinez Peck

This was the first tutorial I read and it was really nice. Thanks a lot for this. Mariano ---------- Forwarded message ---------- From: Michael Perscheid <michaelperscheid(a)googlemail.com> Date: Tue, Apr 12, 2011 at 3:21 PM Subject: [Seaside] [ANN] Seaside Tutorial Ready for 3.0 To: seaside(a)lists.squeakfoundation.org Hi all, I would like to announce that we have updated the Seaside tutorial of the Software Architecture Group ( http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial) Now it can be applied with the current Seaside 3.0 version without any problems. Besides a revision of all chapters, we have especially changed the persistence chapter and added new sections about SandstoneDB, PostgreSQL, and GemStone. Most of the update was done by Lauritz Thamsen and Tobias Pape. Thank you very much. If you have any feedback, please let us know. Best regards, Michael Perscheid _______________________________________________ seaside mailing list seaside(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside -- Mariano http://marianopeck.wordpress.com

April 12, 2011

Updated O2 for Pharo 1.2 [WAS] Re: Code Navigation: Navigation History in System Browser?

by Mariano Martinez Peck

> > Agreed. I've invested just a few hours already so I decided to just finish > it > up. I've made the proposed fix available at > http://code.google.com/p/pharo/issues/detail?id=3992. Perhaps some other > people > might find it useful. Perhaps not, but that's OK too. :-) > > Sure. > -- > Nick > > -- > View this message in context: > http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

April 12, 2011

Re: [Pharo-users] Code Navigation: Navigation History in System Browser?

by Nick Chen

StÃ©phane Ducasse wrote: > > excellent! > > Nick did you sign the license agreement. > > Stef > Ah I thought that all code pushed to PharoInbox was already MIT by default. Anyway I think I found the license agreement. Is this one still up-to-date? <http://pharo.gforge.inria.fr/licenseDocuments/PharoSoftwareDistributionAgreement.pdf> And is the fax number listed there i.e. 00 33 3 59 57 78 5 still the right one? I will fax it over today. Thanks! -- Nick -- View this message in context: http://forum.world.st/Code-Navigation-Navigation-History-in-System-Browser-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

April 12, 2011