December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] SUnit

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > Niall Ross <nfr@...> > they published them on squeaksource but I do not know where Found them in http://squeaksource/SUnit 28 tests, I am ... underwhelmed. Guess copy pasting the test resource fixes from the slide will do the job. --AA

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > I think it is this:Â Â http://www.squeaksource.com/Testing 53 tests, hmm... > http://wiki.squeak.org/squeak/SUnit%20for%203.10 28 tests, I am ... underwhelmed. > And there is also some extensions made by HernÃ¡n Wilkinson. Looks they are already in Pharo, some under other names. Thanks. --AA

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Adrian Kuhn

Lukas Renggli <renggli@...> writes: > I know a lot of SUnit tests override #runCase. Basically all tests > that need to setup a dynamic environment (e.g. to simulate a session). For cases such as `Whatever while: [ super runCase ]` that cannot be split into setUp and tearDown method. Good point, added to requirements list. --AA

Dec. 22, 2009

Re: [Pharo-project] ImageSegment vs SmartRefStream

by Mariano Martinez Peck

Sorry, and I forgot another one: 3) Which is the difference between ReferenceStream and SmartRefStream ? Cheers mariano On Tue, Dec 22, 2009 at 2:02 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi folks. I have been analyzing the code and trying to understand what > ImageSegment does and how. After that, I came up to SmartRefStream and here > is where I have some questions: > > 1) which is the difference between ImageSegment and SmartRefStream ? what > does each of them do ? > > 2) Who uses who ? ImageSegment uses SmartRefStream or vice-versa? each one > use the other? > > Thank you for any hints you can give me. > > Mariano >

Dec. 22, 2009

[Pharo-project] ImageSegment vs SmartRefStream

by Mariano Martinez Peck

Hi folks. I have been analyzing the code and trying to understand what ImageSegment does and how. After that, I came up to SmartRefStream and here is where I have some questions: 1) which is the difference between ImageSegment and SmartRefStream ? what does each of them do ? 2) Who uses who ? ImageSegment uses SmartRefStream or vice-versa? each one use the other? Thank you for any hints you can give me. Mariano

Dec. 22, 2009

Re: [Pharo-project] ISSUE #1647: TheTrunk-KernelTests-bs.121

by StÃ©phane Ducasse

Thanks alex. More context is important :) Thanks for the slice. Stef >>> Pharo image: Pharo-core >>> Pharo core version: 11110 >>> Virtual machine used: Squeak 4.2.1beta1U >>> >>> This email takes the fixes sent in the email having the subjet: >>> - [squeak-dev] The Trunk: KernelTests-bs.121.mcz >>> - [squeak-dev] The Trunk: Kernel-bs.330.mcz >> >> Alex what was the fix for? > > "The Trunk: Kernel-bs.330.mcz" fixes a bug in > AdditionalMethodState>>at:put: > "The Thunk: KernelTests-bs.121.mcz" defines a small test method that > is green only with the bug in at:put: fixed > > The bug that has been identified by Andreas is that when you add twice > the same binding, then you have an infinite loop at the second addition. > >>> After loading the .cs, we have for MethodPropertiesTest: >>> 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 >>> unexpected passes >> >> and before? > > Before the fix: > 10 run, 4 passes, 5 expected failures, 0 failures, 1 errors, 0 > unexpected passes > > After loading the .cs file: > 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 > unexpected passes > > (I use a 11110 core for this) > >>> The error left is for testAnalogousCode, not related to this fix. >>> >>> Thanks to Andreas Raab for the fix. >>> >>> Note to the reviewer: I put a .cs file on google code. Is that okay >>> with you? Or do you prefer a SLICE in the Inbox? >> >> What is nice with slice I that we can merge easily and see them in >> the inbox. > > > Ok, it is now as a slice. > SLICE-FixAndTesstForAdditionalMethodStateAtPut-Alexandre_Bergel.1 > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 22, 2009

Re: [Pharo-project] Keeping released version image up to date (was Re: did you check in 1.1 how the old browser now support the creation of new method cat)

by StÃ©phane Ducasse

Yes in an ideal world. Now either we can script the bugreport to generate that list automatically or we will not have the resources to do it. Then I do not imagine somebody patient enough to read a log full of bug descriptions. :) But may be I'm just too lazy. Stef On Dec 22, 2009, at 10:24 AM, Stan Shepherd wrote: > > > StÃ©phane Ducasse wrote: >> >> >> >> The process we have in mind is that if the bug is **really** important >> then it will be fixed in 1.1 and 1.0. >> We did that in the past for Squeak 3.9. >> Now normal improvements changes.... will not be retro-ported because we >> simply cannot. >> And you are right to report a bug it is important in the future that >> people check if the bug is already fixed >> in the current unstable else we will not be able to make process and we >> will spend our time testing. >> >> > It sounds like the periodic 1.0 releases need to include a known problems > file, which would include all bugs fixed in 1.1 alpha but not planned to be > retrofitted. > And it's probably important to make clear that, if in doubt, we should log a > bug and risk it being a duplicate. Because the people with a genius for > finding bugs are new users, and they may not be able to tell whether or not > it's the same bug. > > -- > View this message in context: http://n2.nabble.com/Re-did-you-check-in-1-1-how-the-old-browser-now-suppor… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 22, 2009

[Pharo-project] Fwd: [squeak-dev] ANN: NanoTraits v0.5

by StÃ©phane Ducasse

this is interesting. I had on my todo to look at the old implementation of andreas since years. Adrian it would be really interesting to check because having a smaller/with less impact traits implementation would be cool. Stef > > My experiments with a simpler traits implementation are starting to bear results. Attached a version of NanoTraits which is the smallest implementation of traits that I could come up with. Making it loadable inside a current trunk image has been a bit of a challenge since it needs to operate side-by-side with the existing traits during load (apologies for the various isKindOf:'s), but it seems to work fairly well now (fingers crossed). There are few differences to the Berne trait implementation including: > > - TraitDescription is a subclass of ClassDescription. This is the main simplification since it avoids creating a dual trait/class hierarchy. It comes at the "cost" of having potentially support for instance variables in traits (i.e., stateful traits) but since this isn't exposed there is very little actual overhead. > > - NanoClassTrait is the class of NanoTrait (i.e., the same meta structure that classes have). Since this models exactly the structure that classes have, it makes browser integration significantly simpler (NanoTraits would work fine in 3.8 for example without changing browsers etc) and allows us to remove the (now unecessary) additional tool support. > > - Methods used from other traits retain a "method home" reference so that for any method in a class you can tell whether it was defined locally or in some other trait. This makes several things *a lot* easier and will allow us to get rid of all the localSelectors stuff in ClassDescription in the next pass (Igor - this gives you the information where a method is from without poking in other places; just ask i.e., (ClassDescription>>#addSelectorSilently:withMethod:) methodHome ==> TAccessingMethodDictDescription) > > - Some previously invalid trait composition are now valid, in particular T - {#x} - {#y} (meaning T- {#x. #y}) as well as T @ {#x->#y} @ (#a -> #b} (meaning T @ { #x -> #y. #a -> #b}. > > - You can't mix Berne and Nano traits. If you try it, things will blow up (incompatible internals). > > - You can't mix Berne and Nano traits tests. I don't know why but if you run them at the same time things go wrong. > > To install NanoTraits: > * Load NanoTraits-Kernel.st > * Load NanoTraits-Tests.st > * Load NanoTraits-Extensions.cs > * Run the NanoTraits-Tests > * (assuming all tests are green) execute: NanoTraits install. > > This will make NanoTraits the default traits implementation and convert any existing traits. I've successfully played with Nile (the only other traits stuff I was aware about besides the class kernel which is a bit difficult to experiment with) but from what I can tell everything should work just fine. > > The one extra thing I'm seriously considering after our recent discussions is to change NanoTraits to actually use mixins to implement traits composition. What this would mean is that instead of adding trait methods to a class directly, they would be added to a (hidden) superclass. Composition rules would be unaffected by this change but it would solve the issue of trait methods messing up the methods *actually* defined in a class, showing a seven times when looking for implementors and more. > > Consider this my holiday gift to the community :-) > > Cheers, > - Andreas > > >

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Mariano Martinez Peck

On Tue, Dec 22, 2009 at 1:37 AM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > - get the same API (I think that sharing code amongst smalltalk is a too > > large constraint but having the same API is important) > > Yes, legacy tests should keep running. > > On the other hand, what is an API in Smalltalk? We just got methods, and > they > are *all* public. So when cleaning SUnit we have to draw a line. No doubt, > #assert: and friends are API, but what about eg #runCase? > > > - integrate key features of extensions so that SUNIT and SUNITExtended is > > cooler. > > Is "SUNITExtended" a project for Pharo? > > > - check what keith did on his Sunit extensions > > Where can I find those? Which keith, email? > I think it is this: http://www.squeaksource.com/Testing http://wiki.squeak.org/squeak/SUnit%20for%203.10 And there is also some extensions made by HernÃ¡n Wilkinson. Maybe they are of help. They are here: http://www.squeaksource.com/SUnitExtensions Cheers Mariano > > - have expected failures > > - have the possibility to know whether a test was red or green when it > was > > saved and now when I run it, is it my fault or what is just before like > that > > +1 ... no, +100 :) > > > > - add expectations matchers as used in behavior-driven testing > > Please not keep this separated or in another package. > > Users should be free to choose between assertions and expectations. > Assertions > will stay. > > > > - break testcase into two classes, and to run the test and one to store > the > > > result (no more #cleanUpInstanceVariables hack to avoid memory leaks) > > > > what would be the impact on existing subclasses? > > There should be none. > > Tools however might have to be changed, since a test result will contain > test > descriptions rather than zombified test cases. > > > I suggest the following > > - clean and get a strong core > > - make sure that all the tests still run > > - get a set of extensions that people can load > > To me, the effort of cleaning up Sunit is worthwhile if we get a strong > core > with support for test dependencies in the core. Phexample as an extension > that > people can load is what we have now. What I imagine is a simple core with > clearly defined API, that allows other to write their own runners for > their > test classes. For example, I would like to separate the role of running > tests > and of containing tests (see my comment on class TestCase in the reply to > Julien.) This should allow better extensibility for everyone. > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 22, 2009

Re: [Pharo-project] ISSUE #1647: TheTrunk-KernelTests-bs.121

by Alexandre Bergel

>> Pharo image: Pharo-core >> Pharo core version: 11110 >> Virtual machine used: Squeak 4.2.1beta1U >> >> This email takes the fixes sent in the email having the subjet: >> - [squeak-dev] The Trunk: KernelTests-bs.121.mcz >> - [squeak-dev] The Trunk: Kernel-bs.330.mcz > > Alex what was the fix for? "The Trunk: Kernel-bs.330.mcz" fixes a bug in AdditionalMethodState>>at:put: "The Thunk: KernelTests-bs.121.mcz" defines a small test method that is green only with the bug in at:put: fixed The bug that has been identified by Andreas is that when you add twice the same binding, then you have an infinite loop at the second addition. >> After loading the .cs, we have for MethodPropertiesTest: >> 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 >> unexpected passes > > and before? Before the fix: 10 run, 4 passes, 5 expected failures, 0 failures, 1 errors, 0 unexpected passes After loading the .cs file: 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 unexpected passes (I use a 11110 core for this) >> The error left is for testAnalogousCode, not related to this fix. >> >> Thanks to Andreas Raab for the fix. >> >> Note to the reviewer: I put a .cs file on google code. Is that okay >> with you? Or do you prefer a SLICE in the Inbox? > > What is nice with slice I that we can merge easily and see them in > the inbox. Ok, it is now as a slice. SLICE-FixAndTesstForAdditionalMethodStateAtPut-Alexandre_Bergel.1 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 22, 2009