- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Bug in Glorp Login >> #= ?

by Nicolas Cellier

c) store some hash of the password (MD5 or something)? The question is why do you want to store such information? 2013/7/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > Wow...after a couple of hours chasing a problem in my app, I faced a > problem with Glorp's Login. I was using a ConnectionPool that uses a > Dictionary to store Login. Each kay is a login instance and the value is an > instance of a connection pool. > > But I was getting multiple instances (entries in the dictionary and pool > instances). The problem is Login >>#= > > = aLogin > self halt. > ^self class == aLogin class and: > [self name = aLogin name and: > [self database class = aLogin database class and: > [self username = aLogin username and: > [self password = aLogin password > and: [self connectString = aLogin connectString]]]]] > > Because it expects the passwords to be equal, while Login can be "secure" > and hence, the password is nil after the login. So what happened here is > that my Login were secure (by default you have that behavior) and hence, > two Login that were created exactly with the same data will give you false > once on of them is logged. > > Solutions? > > 1) Ignore the password check when using secure connections? > > Workarounds? > > a) In my app I can try to store somewhere the Login instance and always > reuse it. > But I am not sure if this could work...because I will have multiple > PharoDatabaseAccessors pointing to the same Login instance... > > b) send a secure: false to my Login instances.... > > Of course I would try to avoid having to do b). > > Any ideas? > > > > -- > Mariano > http://marianopeck.wordpress.com >

July 9, 2013

Re: [Pharo-dev] should:raise:description:

by Frank Shearar

On 9 July 2013 19:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I continue my rant with should:raise:description: > > a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. > b) self should: [ 1 + 2 ] raise: Halt description: 'message'. > > In the first case you do not get the 'message' but 'error message'. > In the second case you get the 'message'. > > Does the description make sense in this case? > 1. if you signal Halt everything is fine > 2. Every other case is a failure > 3. In case a) an internal failure happens so the test fails anyway, fine, but no description > 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. > > Can anybody give me a convincing case for 4? > > Sorry, after this I will stop :D In case (a) I would actually expect to see something like: "message. Unexpected Error raised: 'error message'". In case (b) I'd want to see "message: no Halt raised" I can't think of why you would want a description for a success case, so #4 just seems weird! frank

July 9, 2013

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

by StÃ©phane Ducasse

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.

July 9, 2013

Bug in Glorp Login >> #= ?

by Mariano Martinez Peck

Wow...after a couple of hours chasing a problem in my app, I faced a problem with Glorp's Login. I was using a ConnectionPool that uses a Dictionary to store Login. Each kay is a login instance and the value is an instance of a connection pool. But I was getting multiple instances (entries in the dictionary and pool instances). The problem is Login >>#= = aLogin self halt. ^self class == aLogin class and: [self name = aLogin name and: [self database class = aLogin database class and: [self username = aLogin username and: [self password = aLogin password and: [self connectString = aLogin connectString]]]]] Because it expects the passwords to be equal, while Login can be "secure" and hence, the password is nil after the login. So what happened here is that my Login were secure (by default you have that behavior) and hence, two Login that were created exactly with the same data will give you false once on of them is logged. Solutions? 1) Ignore the password check when using secure connections? Workarounds? a) In my app I can try to store somewhere the Login instance and always reuse it. But I am not sure if this could work...because I will have multiple PharoDatabaseAccessors pointing to the same Login instance... b) send a secure: false to my Login instances.... Of course I would try to avoid having to do b). Any ideas? -- Mariano http://marianopeck.wordpress.com

July 9, 2013

should:raise:description:

by Camillo Bruni

I continue my rant with should:raise:description: a) self should: [ Error signal: 'error message' ] raise: Halt description: 'message'. b) self should: [ 1 + 2 ] raise: Halt description: 'message'. In the first case you do not get the 'message' but 'error message'. In the second case you get the 'message'. Does the description make sense in this case? 1. if you signal Halt everything is fine 2. Every other case is a failure 3. In case a) an internal failure happens so the test fails anyway, fine, but no description 4. A strange? case where the tests actually DO pass but we nevertheless want to print a description. Can anybody give me a convincing case for 4? Sorry, after this I will stop :D

July 9, 2013

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

by Camille Teruel

On 9 juil. 2013, at 18:42, Esteban Lorenzano wrote: > Even more important, IMHO: allowing those methods to exists is to validate an anti-pattern: if you have an specific error to throw, you should create a specific descendant of Error, not just throw Error with an explanation. > > So, +A LOT to remove them. Agree Moreover, I really don't see why we should have a special assertion for auditing the description of an Error. If you begin like that you end up with tons of highly specific assertion for tons of specific objects: self assert: aCollection hasSizeLowerThan: 10. self assert: aPoint isBelow: 2@3. self assert: myDomainObject satisfiesSomeDomainSpecificConstraintParametrizedBy: anObject and: anotherObject ... No way! > > Esteban > > On Jul 9, 2013, at 5:42 PM, 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 9, 2013

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

by Camillo Bruni

On 2013-07-09, at 18:48, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 9 July 2013 17:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> Even more important, IMHO: allowing those methods to exists is to validate >> an anti-pattern: if you have an specific error to throw, you should create a >> specific descendant of Error, not just throw Error with an explanation. >> >> So, +A LOT to remove them. > > No. Failing to specify your error messages is a colossal fail. And if > you don't _test_ your error messages, how are you going to know you > haven't just made your error messages utterly useless in that last > refactoring? That is a separate test for your Exception: MyExceptionTest >> testMessage | message | message := self targetClass new description. ... I don't see the point in testing the description string somewhere else... > And no, checking that your KeyNotFound exception's #key is correctly > set is insufficient, because you then _presume_ that the process of > reporting the exception actually bothers to record that and doesn't > just say "a KeyNotFound". I do not fully see the point of testing that a certain exception is not signaled. 1. if an exception is signaled the test will fail anyways 2. if exceptions are signaled you can easily test that using something like: self should: [ .. ] raise: (NotFound, ZeroDivide, ...) 3. If you have a test that returns different exceptions in the tests you have nondeterminism, so that basically invalidates point 2. 3. Since you have deterministic tests you know that only one kind of error is signaled hence it suffices to use the #should:raise:... methods. Hence, I really do not see the point of the complex #shouldnt:raise:whoseDescriptionIncludes: 1. #shouldnt:raise: is more less fine. Though I would expect it ignore all the other errors thrown, which it doesn't essentially limiting the use of this method. 2. #shouldnt:raise:whoseDescriptionIncludes: is too complex. 3. #shouldnt:raise:whoseDescriptionDoesNotIncludes: essentially reads like a double negation which confuses the hell out of me ----------------------------------------------------------------------------------------- Example: -------- self shouldnt: [ ... ] raise: MyException whoseDescriptionIncludes: 'PING'. What does that mean for the following blocks? 1. [ Error signal ] 2. [ Error signal: 'PING' ] 3. [ MyException signal ] 4. [ MyException signal: 'PING' ] 3 and 4 definitely fail, I assume 1 fails too, and the only one left is case 2. And the monstrous #shouldnt:raise:whoseDescriptionDoesNotInclude: will only pass in case 1? ----------------------------------------------------------------------------------------- In any case, nobody uses the complex #shouldnt:raise:whose* methods so I am removing them and simplify the implementation of TAssertable.

July 9, 2013

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

by Camillo Bruni

On 2013-07-09, at 17:30, Frank Shearar <frank.shearar(a)gmail.com> wrote: > 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! 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.

July 9, 2013

Re: [Pharo-dev] [ANN] Pharo VM now building on Pharo 2.0

by Esteban Lorenzano

On Jul 8, 2013, at 11:08 PM, phil(a)highoctane.be wrote: > I'll have to try that. > > How to run an interpreter in there? Is it possible? no idea i didn't compile an interpreter since a while. It is in my todo list, but with a priority really low :) Why do you need an interpretervm? Esteban > > Phil > > > > On Mon, Jul 8, 2013 at 9:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Today I migrated the jenkins jobs for building the PharoVM to 2.0. > Objectively, nothing changes for the VM users, but is important to move the infrastructure according to our yearly releases. > For those who are creating their own VMs and stuff, now you can move to 2.0 too, there is no need to keep using 1.4. > > jenkins builds are, as always, at: > https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > (windows build is broken due a know problem in the windows slave, not related with the VM build itself) > > Thanks Guille for doing the work and Camillo for the support :) > > Esteban >

July 9, 2013

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

by Frank Shearar

On 9 July 2013 17:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Even more important, IMHO: allowing those methods to exists is to validate > an anti-pattern: if you have an specific error to throw, you should create a > specific descendant of Error, not just throw Error with an explanation. > > So, +A LOT to remove them. No. Failing to specify your error messages is a colossal fail. And if you don't _test_ your error messages, how are you going to know you haven't just made your error messages utterly useless in that last refactoring? And no, checking that your KeyNotFound exception's #key is correctly set is insufficient, because you then _presume_ that the process of reporting the exception actually bothers to record that and doesn't just say "a KeyNotFound". By all means use a proper exception that captures semantic meaning. But, please, PLEASE actually test your logging. frank > Esteban > > On Jul 9, 2013, at 5:42 PM, 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 9, 2013