March 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Case statement and lazy comparison in Pharo
by nullPointer March 16, 2010

March 16, 2010

Well, perhaps is a theme worked in another times but... is possible for Pharo have a basic Case or elseIf statement? I know is easy create you own structure control, but not is more useful have a "standard" for everybody? IÂ´m tired of write code like that... (self currentRow == sortedRows last and: [ self currentCell isNil ]) ifTrue: [ self navigationKey: event ] ifFalse: [ (self currentRow notNil and: [ self currentCell isNil ]) ifTrue: [ self setCurrentRowToNext. ] ifFalse: [ (self currentRow notNil and: [ self currentCell notNil ]) ifTrue: [ self setCurrentCellToNext. self currentCell notNil ifTrue: [ self currentCell performKeyFocus: event inCellBounds: (self pvtGetCellBounds: self currentCell). ]. ]. ]. ]. Write code with that format is pathetical :( Is valid too have a "and" and "or" lazy? Exists a not lazy with #& and #| , but could exists an #&& and #|| . Is more easy... value1 == value2 and:[ <condition> ] and: [<condition>] ...... or value1 == value2 && <condition> && <condition> ......... ??? Well, perhaps is a stupid question but I miss a more complete way for write code. If in Smalltalk is possible do easy that and include it in "core" why not do it? Is a reasonable desire :) Regards -- View this message in context: http://n4.nabble.com/Case-statement-and-lazy-comparison-in-Pharo-tp1594080p… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

6 5

[Pharo-project] [enh] Cleaning of and test for MessageTally
by Alexandre Bergel March 16, 2010

March 16, 2010

Waiting in PharoInbox. This fix has been developed in a 11271. SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 This slices comprises an update for two packages, Tools and ToolsTest. The new version of Tools clean MessageTally. A user of MessageTally may now decide whether he wants to close the tally. Although it is convenient to close it (in order to not keep a reference of the compiled method and the class), this behavior is not always wished. Especially when test have to be written! The user has now the option to not open the result window. ToolsTest contains few and simple tests. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 7

[Pharo-project] About long tests.
by stephane ducasse March 16, 2010

March 16, 2010

Hi jorge did you publish the cleans for the tests you did during the sprint? Thanks Stef

5 9

[Pharo-project] Fixed strange coloring in TestRunner
by Lukas Renggli March 16, 2010

March 16, 2010

Name: SUnitGUI-LukasRenggli.61 Author: lr Time: 16 March 2010, 7:42:35 pm UUID: afa7782a-a37f-4607-8d44-6d03d0f847d6 Ancestors: SUnitGUI-StephaneDucasse.60 - fixed priority of coloring test result: if there are errors then red else if there are failures then yellow else -> green -- Lukas Renggli http://www.lukas-renggli.ch

2 1

[Pharo-project] What is the best way to...
by Hernan Wilkinson March 16, 2010

March 16, 2010

generate a document with the source code of a package? We will use pharo at the university and I want to find an easy way for the students to print out the source code of their work. Thanks. Hernan.

5 7

[Pharo-project] [update 1.1] #11275
by StÃ©phane Ducasse March 16, 2010

March 16, 2010

11275 ----- - Issue 2156: Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again.

1 0

Re: [Pharo-project] about long tests
by Ralph Boland March 16, 2010

March 16, 2010

I read a few Pharo posts lately about long tests. In this regard allow me to describe briefly some code I am now writing. I will eventually release this code to SqueakSource and, if the Pharo group is interested, I will port it to run on Pharo as well. I use long tests a lot in development. These tests are not really suitable as SUnit tests because they are too slow and some of them are parameterizable. These tests are meant for finding bugs during development; less so for verifying code still works before a release. However, I decided to use the SUnit idea and code to enhance running these tests. First, I refactored TestCase by giving is a superclass and moving all the TestCase code into its superclass. I then created a class RunnCase which has the same parent class as TestCase. The reason for refactoring TestCase this way is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. I now put my long tests into RunnCase subclasses. Note that I believe that TestCase should be so refactored even if you are not interested in using the tools I am building because it allows others to build their own tools just as I am doing. I then subclassed TestRunner with subclass TestPlusRunner. TestPlusRunner allows running the same tests as TestRunner. TestPlusRunner is like TestRunner with a few minor changes including: 1) an extra window that displays individual test case methods when only one class is selected. Subsets of test cases from an single class can be selected and run. 2) (Ignore this paragraph is you like) it has as some additional buttons. Currently the buttons are there but not the functionality. The intent of the buttons is to be able distribute the running of a set of tests over a number of computers and return to one computer only the tests that failed so they can be debugged. Specifically, the intent is to be able to file out a set of tests, send them to another user/computer, have that user/computer run those tests and send back a file containing all the tests that fail, and then be able to load the failed test and debug them. I then subclassed TestPlusRunner with subclass RunnRunner. RunnRunner runs tests of subclasses of RunnTest. RunnRunner is like TestPlusRunner with the ability to set parameters that can affect the running of tests. Currently the only parameter that can be set are a list of size values. For example, if this parameter is set to '3-5,7,9-12' then the tests that are run will be given this parameter and then use this parameter however they want but presumably either ignore it or run the test once with each of the size values: 3,4,5,7,9,10,11,12. Several other parameters are also planned: 1) seed. The seed is a value with which to initialize a random number generator that the tests can optionally use in the generation of test data for the tests. 2) number of subtests. A test may have the ability to generate and run a number of subtests (probably using 1)). This parameters indicates how many subtests to run. 3) subtest start. If a test runs 1000 subtests and then detects a failure then the user may not want to rerun the first 999 subtests before running subtest 1000 again. This parameter allow the subtests to be run starting at subtest #1000. Feedback on this work is most welcome either positive or negative (but constructive). Regardless of opinions, it would be great if the refactoring of TestCase described above were done. It is the way it should have been written in the first place. Note that some additional minor refactoring of TestCase and TestRunner is required. Email me if you want details. Regards, Ralph Boland

2 1

March 16, 2010

11274 ----- - Issue 2155: Gofer test 30% faster - Issue 2153: Fixed compiler exceptions - Issue 2152: fixing Closure compiler Tests - Issue 2150: nextInto:startingAt:count: returning false count - Issue 2132: ExceptionAboutToReturn is not used - Issue 2149: MultiByteFileStreamTest forget to remove a file Stef

1 0

[Pharo-project] SqNumberParserTests green
by Nicolas Cellier March 16, 2010

March 16, 2010

PharoInbox/KernelTests-nice.217 Ancestors: KernelTests-StephaneDucasse.216 Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again.

2 1

[Pharo-project] Congratulations Norberto Manzanos! - Re: [Pkg] Installer: Installer-Core-nm.357.mcz
by Ken G. Brown March 16, 2010

March 16, 2010

Big CONGRATULATIONS to Norberto Manzanos for maintaining Installer in the proper squeaksource repository, rather than local to some fork or other. This is a breakthrough! Here's a great opportunity for developers to work out some procedures around maintaining packages external to the trunk repository, in the interest of improved modularity. Ken G. Brown At 4:15 PM +0100 3/16/10, squeak-dev-noreply(a)lists.squeakfoundation.org apparently wrote: >A new version of Installer-Core was added to project Installer: >http://www.squeaksource.com/Installer/Installer-Core-nm.357.mcz > >==================== Summary ==================== > >Name: Installer-Core-nm.357 >Author: nm >Time: 16 March 2010, 12:15:30 pm >UUID: 7e6635ca-259c-3549-8034-d3bbfcbd0f14 >Ancestors: Installer-Core-nm.357 > > - still a bug on detecting version number, due to this monticello bad design. Package with names like 'Seaside2.8a1-xx.1.mcz' will be sorted wrongly. Fixed, I think > >=============== Diff against Installer-Core-nm.357 ===============

1 0