- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] sunit failures vs errors

by Damien Cassou

On Wed, Jul 10, 2013 at 2:46 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > Does anybody here distinguish failures and errors for real when doing TDD? I don't and I would like to see if both can be merged. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 10, 2013

sunit failures vs errors

by Camillo Bruni

Does anybody here distinguish failures and errors for real when doing TDD? I do not really see the point of separating them. Besides the complexity added to the testing framework it is a burden for newcomers. I personally just see: 1) test passes => green, ok 2) test doesn't pass => red, not ok Apparently that has been done in JUnit4 http://www.devx.com/Java/Article/31983/0/page/2

July 10, 2013

Re: [Pharo-dev] Some Spec questions

by Benjamin

On Jul 9, 2013, at 11:35 PM, Clara Allende <clari.allende(a)gmail.com> wrote: > Hi folks, while working on the new debugger, I've come up with some questions... > > *is there any other implementation for dynamic widgets other that the current one? I do not get your question ... > > *right now the toolbar is a static widget, and I would like to have a dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider? It may make sense to dynamically regenerate the toolbar (or at least remove only what needs to be removed, add only what needs to be added). Then you should also think in term of user experience. Having things changing may be disturbing and counter productive :) Ben > Thanks in advance! > Cheers, > Clari > >

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Eliot Miranda

On Tue, Jul 9, 2013 at 1:27 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 9 July 2013 10:15, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello pharoers, > > > > Recently I have been looking at the Pharo thisContext capabilities, in > order > > to perhaps one day in the far future edit its implementation with the > Pharo > > dev team. Nothing is planned or confirmed, it is just to discuss. > > > > A context has instances variables (method closureOrNil receiver stackp > > sender pc) and holds the arguments and temporaries. > > > > Now I'd like to know what context's state do we modify, and what states > are > > just internal representations ? > > > > For example, it seems that you can do 'thisContext receiver: #foo', but > you > > cannot with Cog. > > > > SomeClass>>foo > > thisContext receiver: #foo. > > ^ self > > > > In workspace, evaluating: > > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] > > > > Transcript result (with Cog): > > foo > > foo > > a SomeClass > > a SomeClass > > a SomeClass > > > > Transcript result (with Stack or Vanilla): > > foo > > foo > > foo > > foo > > foo > > > > Now as no one has ever complained, I guess this feature is not used. > > > > As far as I know, the real use cases of the context seems to be: > > - setting and gettings temporaries > > - setting and getting the sender of a context > > - setting and getting the pc > > - getting method, closureOrNil, receiver, stackp, arguments but NOT > setting > > them > > > > Now setting the sender of a context seems to be used only in two cases: > > - continuations (as seaside continuations) > > - exception implementation > > > > So imagine that in the future you would have a context that can be > accessed > > in read-only, where you could only: > > - set the temporaries (but not arguments) > > - set the pc (or something equivalent, as set the currently executed ast > > node) > > - use continuations (exceptions can be implemented on top of > continuations) > > > > I would like to know if there are things that you do now and that you > would > > not be able to do with a context like that. For non meta developer (like > > enterprise app developer) I guess it will not change anything, but I > want to > > know if you implemented a framework as seaside, does it requires other > > things from the context and why ? > > > > To my thinking playing with pc is awfully evil, it should be > read-only, only to allow debugger > to map it to source code. Same goes for stack pointer. > There are good uses for this I just used it to implement basic-block coverage for methods. One can use it for exception handling (mustBeBoolean etc). I'm always wary of introducing restrictions when the system has worked fine without them for years. One exception recently was in adding bounds checking to CompiledMethod>>at:put: so one could not change arbitrary bytes in the literals via at:put:. But this was adding safety, not adding a restriction. I see no harm in allowing one to assign the pc. It is unsafe, and the system will likely crash if you get it wrong. But it is also potentially useful (e.g. I've used it to do a prototype of tail-recursion elimination). So let's be laissez faire, unless the freedoms in question really do only do harm. > > Setting receiver is less evil and it may work, if receiver belongs to > same inheritance chain > as compiled method's class. But it should not be set without checking this. > > And for method's temps, it is fine. > > > Thanks for answering, > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

July 9, 2013

Re: [Pharo-dev] thisContext usecases

by Eliot Miranda

Hi ClÃ©ment, this is a bug. Thanks for finding it. On Tue, Jul 9, 2013 at 1:15 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hello pharoers, > > Recently I have been looking at the Pharo thisContext capabilities, in > order to perhaps one day in the far future edit its implementation with the > Pharo dev team. Nothing is planned or confirmed, it is just to discuss. > > A context has instances variables (method closureOrNil > receiver stackp sender pc) and holds the arguments and temporaries. > > Now I'd like to know what context's state do we modify, and what states > are just internal representations ? > > For example, it seems that you can do 'thisContext receiver: #foo', but > you cannot with Cog. > > SomeClass>>foo > thisContext receiver: #foo. > ^ self > > In workspace, evaluating: > 1 to: 5 do: [:i | Transcript show: SomeClass new foo ] > > Transcript result (with Cog): > foo > foo > a SomeClass > a SomeClass > a SomeClass > > Transcript result (with Stack or Vanilla): > foo > foo > foo > foo > foo > > Now as no one has ever complained, I guess this feature is not used. > > As far as I know, the real use cases of the context seems to be: > - setting and gettings temporaries > - setting and getting the sender of a context > - setting and getting the pc > - getting method, closureOrNil, receiver, stackp, arguments but NOT > setting them > > Now setting the sender of a context seems to be used only in two cases: > - continuations (as seaside continuations) > - exception implementation > > So imagine that in the future you would have a context that can be > accessed in read-only, where you could only: > - set the temporaries (but not arguments) > - set the pc (or something equivalent, as set the currently executed ast > node) > - use continuations (exceptions can be implemented on top of continuations) > > I would like to know if there are things that you do now and that you > would not be able to do with a context like that. For non meta developer > (like enterprise app developer) I guess it will not change anything, but I > want to know if you implemented a framework as seaside, does it requires > other things from the context and why ? > > Thanks for answering, > -- best, Eliot

July 9, 2013

Some Spec questions

by Clara Allende

Hi folks, while working on the new debugger, I've come up with some questions... *is there any other implementation for dynamic widgets other that the current one? *right now the toolbar is a static widget, and I would like to have a dynamic one to filter out the actions that should not be available (which are a subset of the default ones). Would it make sense to regenerate the toolbar everytime the selection changes? Is there any other approach I should consider? Thanks in advance! Cheers, Clari

July 9, 2013

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

by Camillo Bruni

On 2013-07-09, at 21:23, Frank Shearar <frank.shearar(a)gmail.com> wrote: > 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! exactly! :) I agree on that ;). Now the question is on how to properly fix this for debugging. Since you actually want to debug on the unexpected Exception in case a)... I'll check my magic box..

July 9, 2013

OSDC.fr: 5th Open Source Developers Conference in France

by Damien Cassou

Call for Papers 5th Open Source Developers Conference in France Montrouge Beffroi cultural centre, Paris, October 4 & 5, 2013 OSDC.fr objective is to gather French speaking developers from different communities around innovative technologies. After two editions on our own, we are since 2011 associated to Open World Forum and its numerous partners in order to provide the best experience to our attenddees. For the 5th edition of this conference, we invite you to gather the communities dedicated to programming based on free/libre languages such as Perl, Python, Ruby, PHP, Smalltalk & much more. The aim is to learn by exploring the universe of all languages, for many concepts and techniques aren't tied to a specific environment, and therefore allow cross-pollinations. So we invite you to join us by taking part in OSDC.fr, either by submitting a talk proposal <http://act.osdc.fr/osdc2013fr/newtalk> (preferably in French, but English is acceptable), or simply by joining us on October 4 & 5, 2013, at at Montrouge Beffroi cultural centre. Entrance is free and everyone is welcome. Talks can last 25 or 45 minutes. We'll also have a lightning talks session, where talks are limited to 5 minutes max. Here is a non-exhaustive list of possible subjects: - Themes related to programming languages such as Perl, PHP, Python, Ruby, Erlang, JavaScript, node.js, Lua, Scala, Clojure, Groovy, Haskell, C, C++, Smalltalk, Java, etc. - Dynamic compilation - Interpreters and virtual machines (LLVM, JVM, CLR, Parrot, etc) - Development tools - Development best practices - Programming experience feedback - Libraries - Making of innovative languages and their implementation - Software maintenance - Integration of different languages - Teaching techniques - Modern techniques of system administration, industrialization, distributed infrastructure (*cloud*) - Big Data, OpenData Key dates: - Deadline for submitting a talk : September 6th, 2013 - Final schedule : September, 2013 - OSDC.fr conference : October 4 & 5, 2013

July 9, 2013

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

by Nicolas Cellier

And maybe it could be reclassified as a solution 2) rather than a workaround c) 2013/7/9 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > 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] the return of the strange methods

by Nicolas Cellier

"should not raise an exceptional event whose description does not include" wow, who is crooked enough to use double negation ;) 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. > > >

July 9, 2013