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

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 Stan Shepherd

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.

Dec. 22, 2009

Re: [Pharo-project] SUnit

by Lukas Renggli

>> 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? > > you cut some line. 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). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 22, 2009

Re: [Pharo-project] [update 1.1] #11111

by Marcus Denker

On Dec 22, 2009, at 10:03 AM, StÃ©phane Ducasse wrote: > marcus did you push the updates.list file :) > ups. Done (too early... :-) Marcus > > On Dec 22, 2009, at 9:08 AM, Marcus Denker wrote: > >> 11111 >> ----- >> >> Issue 1646: SLICE-PreferencesReferencesRemovalPart2 >> * remove all remaining Preferences references >> * also fix a DiffMorph bug introduced by previous SLICE-PreferencesReferencesRemovalPart1 >> (send of #setting instead of #settings) >> Thanks, Alain! >> Issue 1649: Workspace cannot print object whose class does not inherit from Behavior >> Thanks to Adrian Kuhn >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > 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] [update 1.1] #11111

by StÃ©phane Ducasse

marcus did you push the updates.list file :) On Dec 22, 2009, at 9:08 AM, Marcus Denker wrote: > 11111 > ----- > > Issue 1646: SLICE-PreferencesReferencesRemovalPart2 > * remove all remaining Preferences references > * also fix a DiffMorph bug introduced by previous SLICE-PreferencesReferencesRemovalPart1 > (send of #setting instead of #settings) > Thanks, Alain! > Issue 1649: Workspace cannot print object whose class does not inherit from Behavior > Thanks to Adrian Kuhn > _______________________________________________ > 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

Stan 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. Mariano we should update the web page how to submit a bug... >>> >> > > Hi Mariano, I suppose my question was mainly about how to keep that 1.0 > version up with its current fixes. Is it a question of watching out for a > new release on the downloads page. > > It would be preferable to pick up all updates (semi)automatically, in which > case you know that a bug you hit is still a bug. > > I know I have seen bugs such as the one I just logged, but felt they were > likely already in the works, or caused by something I'd done. If I can > easily keep an image as the 'gold standard' of where a patched up to date > image should be, I'm more likely to decide something really is a bug and log > it. > > Cheeers, ...Stan > > -- > 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

Re: [Pharo-project] can we include this in NewInspector ?? (WAS) Fwd: [ANN] MagmaBrowser

by StÃ©phane Ducasse

Fred this is cool !! Now I was thinking if you could not reuse this block and use it to add the visual before the [1] : Form... as int he explorer Stef > Form allInstances

Dec. 22, 2009

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

by StÃ©phane Ducasse

On Dec 22, 2009, at 12:00 AM, Alexandre Bergel wrote: > 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? > > After loading the .cs, we have for MethodPropertiesTest: > 11 run, 5 passes, 5 expected failures, 0 failures, 1 errors, 0 > unexpected passes and before? > 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. > > 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

[Pharo-project] [update 1.1] #11111

by Marcus Denker

11111 ----- Issue 1646: SLICE-PreferencesReferencesRemovalPart2 * remove all remaining Preferences references * also fix a DiffMorph bug introduced by previous SLICE-PreferencesReferencesRemovalPart1 (send of #setting instead of #settings) Thanks, Alain! Issue 1649: Workspace cannot print object whose class does not inherit from Behavior Thanks to Adrian Kuhn

Dec. 22, 2009

Re: [Pharo-project] SUnit

by StÃ©phane Ducasse

On Dec 22, 2009, at 4:34 AM, Julian Fitzell wrote: > On Mon, Dec 21, 2009 at 4:15 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: >> Julian Fitzell <jfitzell@...> writes: >> >>> Well, the second may require working *with* SUnit maintainers on other >>> platforms. :) >> >> Where can I find their names? > > Dunno... guess this is a start: http://sunit.sourceforge.net/people.htm I would not go down this road :) Just define a new one that is compatible. > >>> I guess I don't know exactly what you define as >>> "internal representation" but from Seaside's point of view it is >>> absolutely essential that unit tests be runnable the same way on all >>> platforms - it's the cornerstone of portability. >> >> Good point. Added as a requirement: current test should remain runnable, and >> it should be possible to limit oneself to a set features that runs on all >> platforms. >> >> One problem I see with legacy tests though is that TestCase serves currently >> two purposes: a the superclass of all classes that contain tests, and as the >> implementation of the internal logic that runs the tests. I don't how common >> it is to override internal methods of test case in subclass (as eg #runCase >> etc). In Seaside, eg, are you doing this? > > It seems we do not, though we do override #performTest in two cases. > Both are cases where we need to wrap the execution in an exception > handler. > >>> Although now I've said it, why not just start from scratch? There's >>> not a lot of code there... implement something that works the way you >>> want, build it using Grease/Slime so we can port it easily to >>> everywhere else, and that's something Seaside could use (assuming it >>> was compellingly better). And suddenly we'd have a test framework that >>> *did* run everywhere with a common code base. >> >> Compelling, but can this be done without being a cross-platform expert? I >> recall the pain of getting Fame to run in both VW and Squeak, eventually I >> gave up. Cross-platform integration server, anyone? >> >> What is Grease/Slime? > > I don't know - we've become pseudo-experts for Seaside but it doesn't > seem to be that tough in our case - just a matter of avoiding lots of > things that aren't compatible. > > Grease is the light-weight compatibility layer we have ended up > developing out of the Seaside project. I also used it to port Magritte > and Pier to VA Smalltalk and Colin and I are now beginning to use it > for MC2. > > Slime is a set of lint rules - currently some of them are > Seaside-specific but others are essentially a counterpart to Grease - > detecting things that you cannot do if you want your code to be > portable. > > The hope is that others can leverage the experience we've developed > and our porters' efforts getting Grease running on their platforms. I > still need to finish a write-up on what Grease is and post it > somewhere - on my todo list for the holidays. > > Julian > > _______________________________________________ > 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] SUnit

by StÃ©phane Ducasse

On Dec 22, 2009, at 1:16 AM, Adrian Kuhn wrote: > StÃ©phane Ducasse <stephane.ducasse@...> writes: > >> BTW I do not know what is the status of the recent SUnit changes made by >> Nial. I know that at ESUG they published a squeak version so it would be >> good to start there. > > Where can I find these changes? > Niall Ross <nfr(a)bigwig.net> they published them on squeaksource but I do not know where > --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