- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] the return of the strange methods

by Jan Vrany

> What you want is a TAssertable>>#should:raise: that: > - takes a one arg block as second argument that is evaluated with the > exception thrown > - fails if no exception is raised > Then please call it #should:raise:suchThat: That's what is in upcoming SUnit 5.0 [1] Also I would avoid using traits in SUnit, this is non-portable. The TestAsserter class was introduced already in SUnit 4.0. Indeed, only if you at all care about having SUnit in sync with other dialects :-) Best, Jan [1]: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/fb932a5daa97/TestAssert…

July 10, 2013

Re: [Pharo-dev] the return of the strange methods

by Camille Teruel

On 10 juil. 2013, at 16:45, Igor Stasenko wrote: > On 9 July 2013 22:45, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> "should not raise an exceptional event whose description does not include" >> wow, who is crooked enough to use double negation ;) >> > > is it a convenience method for following: > > > [ self dosomething ] on: Error do: [:ex | > self assert: ex message includes:'whatever' ] > ? Not really, because it doesn't fails if no exception is raised. > > as to me this is more readable and intent-revealing than using strange > double-negation.. What you want is a TAssertable>>#should:raise: that: - takes a one arg block as second argument that is evaluated with the exception thrown - fails if no exception is raised > > >> Nicolas >> >> >> 2013/7/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> >>> So + 1 :) >>> >>>>>> >>>>>> - shouldnt: aBlock raise: anExceptionalEvent >>>>>> whoseDescriptionDoesNotInclude: subString description: aString >>>>>> - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: >>>>>> subString description: aString >>>>>> >>>>>> I honestly cannot wrap my head around these two methods. >>>>> >>>>> They show that the code in the block raises an _informative_ >>>>> exception. So you get a FileNotFound exception... but what was the >>>>> missing file? I don't know! Noone bothered to mention it! >>>> >>>> >>>> no it is #shouldnt: it is the inverse. >>>> the #should:... handler methods are fine, but these specific two methods >>>> are just insane. >>>> I tried to reimplement them without looking at the original definition >>>> and I cannot come up with something that matches the name :) so there is >>>> definitely something wrong with it. >>> >>> >> > > > > -- > Best regards, > Igor Stasenko. >

July 10, 2013

Re: [Pharo-dev] the return of the strange methods

by Jeff Estep

M/I/i On Jul 9, 2013 11:43 AM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: > They may be useful. Imagine you are too lazy to create a subclass of > Error, but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: > 'some strange error happened' description: 'the strange error did not > happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess > you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> > >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent >> whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: >> subString description: aString >> > >> > I honestly cannot wrap my head around these two methods. >> >> They show that the code in the block raises an _informative_ >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> >> >

July 10, 2013

Re: [Pharo-dev] the return of the strange methods

by Jeff Estep

-mgvnf mk. / On Jul 9, 2013 11:49 AM, "Max Leske" <maxleske(a)gmail.com> wrote: > > > On 09.07.2013, at 17:42, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > >> They may be useful. Imagine you are too lazy to create a subclass of Error, but not lazy enough to create a test and copy paste a String. >> Then you write in your method: >> self error: 'some strange error happened' >> And you can test it: >> self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' >> >> Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? > > > +1 > >> >> >> 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >>> >>> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> > Survey: who uses the following methods? and if yes why? >>> > >>> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString.- description: aString >>> > - shouldnt: aBlock raise: anExceptionalEvdcdvent whoseDescriptionIncludes: subString description: aString >>> > >>> > I honestly cannot wrap my head around these two methods. >>> >>> They show that the code in the block raises an _informative_ >>> exception. So you get a FileNotFound exception... but what was the >>> missing file? I don't know! Noone bothered to mention it! >>> >>> frank >>> >> >

July 10, 2013

Re: [Pharo-dev] th/m/ ''' e return of the strange methods

by Jeff Estep

'' On Jul 9, 2013 11:43 AM, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote:////,,. > > They may be useful. Imagine you are too lazy to create /a subclass of Error, but not lazy enough to create a test and copy paste a String. > Then you write in your method: > self error: 'some strange error happened' > And you can test it: > self shouldnt: [ "some strange code" ] raise: Error whoseDescriptionIncludes: 'some strange error happened' description: 'the strange error did not happen ! That's strange' > > Seriously, as you saw these methods are used only in their tests. I guess you can remove them. Open fogz bug ? > > > 2013/7/9 Frank Shearar <frank.shearar(a)gmail.com> >> >> On 9 July 2013 16:24, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> > Survey: who uses the following methods? and if yes why? >> > >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionDoesNotInclude: subString description: aString >> > - shouldnt: aBlock raise: anExceptionalEvent whoseDescriptionIncludes: subString description: aString >> > >> > I honestly cannot wrap my ojhjuj around these two methods. >>c >> ''' show that the code in the block raises an ,,''',. >> exception. So you get a FileNotFound exception... but what was the >> missing file? I don't know! Noone bothered to mention it! >> >> frank >> > Cf'

July 10, 2013

Re: [Pharo-dev] UIPainter in need of some help?

by Stephan Eggermont

Erwan wrote: >Do you know how i can replace the background of a SpecWindow ? >I would like to use UIPainterPanelMorph, which provide me drag'n drop. I would assume you can set the bindings of the SpecInterpreter to a SpecBinder with a different initializeBindings? That suggest that SpecBindings should perhaps not be a singleton Stephan

July 10, 2013

Re: [Pharo-dev] filetree jenkins job

by Christophe Demarey

Hi Dale, The introduction of Opal as the new compiler has some side effects. The problem is reported here : https://pharo.fogbugz.com/default.asp?11141 Today, Camillo and I worked on this problem and we should come with a solution soon. Once integrated in the image, you should have the same kind of output you have on Pharo 2.0. Maybe you can trigger a new build for Pharo 3.0. There was also a bug related the new classBuilder introduction and it is now fixed. Le 8 juil. 2013 Ã 05:04, Dale K. Henrichs a Ã©crit : > When I am using travis, I am looking at the log file of the run just to see if the test passed or failed, so to have a "dead stack trace" right there in the log file that I am looking at is exactly what I WANT ... most of the time the stack trace is enough for me to debug the problem... > > | And exactly in the case you describe theses fuel files can save you a > | lot of time since you can basically debug the same way you debug a > | local application. > > Except that I rarely write code in Pharo3.0, but I am interested in running tests and seeing the results of tests and seeing stack traces for failures for the code when it is run against Pharo3.0 ... These days I do the bulk of my development for FileTree, Metacello, etc. using tODE in GemStone, so I don't usually even have a Pharo development image (especially a fresh one) available to do testing ... so a stack trace actually saves me a whole lot of time... Here Camillo just pointed you a very useful mechanism you can use to debug. At the end, you are free to check stack traces and try to fix from tODE/GemStone if you prefer this way. > | In any case I see 4 failing tests on our jenkins build: > | https://ci.inria.fr/pharo-contribution/job/FileTree/PHARO=30,VERSION=stable… If you don't want to wait to have feedback from Travis with the error output fixed, this is the way to go. You can get the stack trace by clicking on each failed test. We should have the same failed tests on Travis. Christophe.

July 10, 2013

Re: [Pharo-dev] [Pharo-bugtracker] FogBugz (Case [Issue]11132) Tools - Backport to 2.0: Convert MetacelloConfigurationBrowser to Spec

by Sven Van Caekenberghe

On 10 Jul 2013, at 17:18, "Pharo Issue Tracker" <do-not-reply(a)pharo.fogbugz.com> wrote: > The new config browser: > > 1. Avoids the confusion of newbees (remember the "why is this tab named > Verified vs. Unverified" discussion). It now displays ONLY the > verified configs that are specific to Pharo 2.0 (from MetaRepoForPharo20) > but still allows you to switch repository so you load and browse > others > > 2. Switched the repo URL to "gemtalksystems" instead of "gemstone" > since SS3 moved to the new company > > 3. has a nicer look and feel with icons > > 4. Shows when a config is already loaded > > 5. is cleaner since it is based on spec Thx, Torsten, the new browser is cool, I like it. Sven

July 10, 2013

Re: [Pharo-dev] [update 3.0] #30262

by Sven Van Caekenberghe

On 10 Jul 2013, at 11:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > 30262 > ----- > > 11089 Update Zn+Zdc July 2013 > https://pharo.fogbugz.com/f/cases/11089 > Thanks, Marcus. And the versions were kept the same ;-) To bad there remain strange differences between tests passing/failing on the build servers and locally. Sven

July 10, 2013

Re: [Pharo-dev] Is it Glorp trustful enough for the encoding?

by Esteban A. Maringolo

2013/7/10 Sven Van Caekenberghe <sven(a)stfx.eu>: >> So...where should I do the conversion? At Glorp level or at database driver level? > And IMHO at the lowest possible level. If you have an SQL VARCHAR column, the driver should convert bytes to a normal Smalltalk String. An OR mapper is a client of the driver, right ? +1 Encoding should be a parameter of the Connection/Login details. And ORM should deal only with strings in whatever encoding Pharo uses for its strings, ignoring (as much as possible) what happens beneath. Regards,

July 10, 2013