[Pharo-project] ProgressDisplay package features
Cool Can you tell us some of the added features? Stef
I recently released the first draft of my package ProgressDisplay to SqueakSource. It is like SystemProgressMorph et. al. but with a lot of bells and whistles added. It is not a suitable replacement for SystemProgressMorph though because it is too large and specific for that.
Well you asked for it: 1) You can pass an applyBlock rather than a duringBlock. The progressDisplay then applies the apply block to each element to each of the users values updating the display as it does so. The users values can be the values min..max or the values of a stream. 2) You can set a jump value k such that the display is updated once for each k times a display update request is sent. The minimum time that must pass before the display is updated is settable (it is fixed with SystemProgressMorph). Finally, a check is made that a display request update will actually modify the progressBar before the modification is performed. These changes were made because with SystemProgressMoprh, in some circumstances, the progressBar could take excessive amounts of time. However the last of these changes was probably all that was needed. 3) You can set the progressDisplay to catch user interrupts. Unfortunately this doesn't work correctly currently. The interrupt is caught but not processed until the progressBar closes. :-( I don't know how to fix this so suggestions or a fix most welcome. 4) You can set the start point to be other than at the beginning. If you start not at the beginning then you can set the progressDisplay to wrap once the end is reached. This is a weird feature but I need it for when I run a large collection of tests (not SUnit tests but similar). Say I run 1000 tests and the 900th test fails. I fix the problem and rerun the tests. I don't want to start at test one, I want to start at test 900, run tests 900-1000 and then run tests 1-899. The ProgressDisplay supports this and is the main reason I created it. 5) I have added an exception EarlyCompletionExit. This exception will be caught by progressDisplay if generated and result in the current progressBar being closed cleanly. If there is only one progressBar the entire display is closed. 6) If you want you can display the current value being processed and the total. The current value can be the user's value, the count of processed values, count of the number of user values remaining to be processed, the estimate of the amount of time remaining, or the time remaining estimate alternating with one of user value, count, countDown. The current value and total can be labelled if desired. The start poin, if not the beginning, can also be labelled. 7) The display does not flicker as much as SystemProgressMorph though this could still be improved. 8) Anything else I have forgotten. There are large number of examples in class RunnProgressMorphExample which is a subclass of ExampleCase. In my image ExampleCase is an subclass of CodeCase and TestCase is also a subclass of CodeCase. Someday I hope to have TestCase refactored to have CodeCase as a superclass in Squeak/Pharo. The examples use a number of utility classes which will eventually be moved to other packages. Some of them are: 1) ArrayPermutationsStream. Generates the permutations of a SequenceableCollection in a stream. Iteration, not recursion, is used. Ordering is not Lexicographic. 2) RangeList. Stores a sorted list of values where consecutive values are stored by listing them as an Interval. Example: 1,5-9,12,15,31-90 Example: $a,$c,$k-$t,$z This class is not complete. There are two subclasses: NumberRangeList and PositiveNumberRangeList also not complete. 3) NumberRangeListStream. Stream version of NumberRangeList. 4) NumericMultiplicityPartitionStream. For a given integer n, generates all numeric partitions of n (sums of positive numbers that add up to n) in lexicographic order. This can be combined with method SequenceableCollection>>multisetPermutationsDo: to generate arrays of size n containing combinations of the elements of 1..n with replacement (i.e. duplicates allowed). In another package I plan to use this for generating large numbers of test cases. There are also a scattering of useful methods in places like Object, Nil, and SequenceableCollection. Hope this helps. Ralph Boland
thanks! I think that this is important to improve the quality of the system and libraries. I like the idea that we can have more and specialised collections. Stef On Aug 2, 2010, at 6:59 PM, Ralph Boland wrote:
Cool
Can you tell us some of the added features?
Stef
I recently released the first draft of my package ProgressDisplay to SqueakSource. It is like SystemProgressMorph et. al. but with a lot of bells and whistles added. It is not a suitable replacement for SystemProgressMorph though because it is too large and specific for that.
Well you asked for it:
1) You can pass an applyBlock rather than a duringBlock. The progressDisplay then applies the apply block to each element to each of the users values updating the display as it does so. The users values can be the values min..max or the values of a stream.
2) You can set a jump value k such that the display is updated once for each k times a display update request is sent. The minimum time that must pass before the display is updated is settable (it is fixed with SystemProgressMorph). Finally, a check is made that a display request update will actually modify the progressBar before the modification is performed. These changes were made because with SystemProgressMoprh, in some circumstances, the progressBar could take excessive amounts of time. However the last of these changes was probably all that was needed.
3) You can set the progressDisplay to catch user interrupts. Unfortunately this doesn't work correctly currently. The interrupt is caught but not processed until the progressBar closes. :-( I don't know how to fix this so suggestions or a fix most welcome.
4) You can set the start point to be other than at the beginning. If you start not at the beginning then you can set the progressDisplay to wrap once the end is reached. This is a weird feature but I need it for when I run a large collection of tests (not SUnit tests but similar). Say I run 1000 tests and the 900th test fails. I fix the problem and rerun the tests. I don't want to start at test one, I want to start at test 900, run tests 900-1000 and then run tests 1-899. The ProgressDisplay supports this and is the main reason I created it.
5) I have added an exception EarlyCompletionExit. This exception will be caught by progressDisplay if generated and result in the current progressBar being closed cleanly. If there is only one progressBar the entire display is closed.
6) If you want you can display the current value being processed and the total. The current value can be the user's value, the count of processed values, count of the number of user values remaining to be processed, the estimate of the amount of time remaining, or the time remaining estimate alternating with one of user value, count, countDown. The current value and total can be labelled if desired. The start poin, if not the beginning, can also be labelled.
7) The display does not flicker as much as SystemProgressMorph though this could still be improved.
8) Anything else I have forgotten.
There are large number of examples in class RunnProgressMorphExample which is a subclass of ExampleCase. In my image ExampleCase is an subclass of CodeCase and TestCase is also a subclass of CodeCase. Someday I hope to have TestCase refactored to have CodeCase as a superclass in Squeak/Pharo.
The examples use a number of utility classes which will eventually be moved to other packages. Some of them are:
1) ArrayPermutationsStream. Generates the permutations of a SequenceableCollection in a stream. Iteration, not recursion, is used. Ordering is not Lexicographic.
2) RangeList. Stores a sorted list of values where consecutive values are stored by listing them as an Interval. Example: 1,5-9,12,15,31-90 Example: $a,$c,$k-$t,$z This class is not complete. There are two subclasses: NumberRangeList and PositiveNumberRangeList also not complete.
3) NumberRangeListStream. Stream version of NumberRangeList.
4) NumericMultiplicityPartitionStream. For a given integer n, generates all numeric partitions of n (sums of positive numbers that add up to n) in lexicographic order. This can be combined with method SequenceableCollection>>multisetPermutationsDo: to generate arrays of size n containing combinations of the elements of 1..n with replacement (i.e. duplicates allowed). In another package I plan to use this for generating large numbers of test cases.
There are also a scattering of useful methods in places like Object, Nil, and SequenceableCollection.
Hope this helps.
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Ralph. I tried to run the examples, I started with exampleDisplayingNumericPartition for example, and they all fails with differents DNU, like isMorphic and some others. It would be great if you could test the examples in Pharo 1.1 or 1.0 (both is better!) and let us know so that we can test. In addition, there is a dependency problem when laoding it fro monticello. You should fix the dependency or use a dependency manager like Metacello. Attached screenshot cheers mariano On Mon, Aug 2, 2010 at 6:59 PM, Ralph Boland <rpboland@gmail.com> wrote:
Cool
Can you tell us some of the added features?
Stef
I recently released the first draft of my package ProgressDisplay to SqueakSource. It is like SystemProgressMorph et. al. but with a lot of bells and whistles added. It is not a suitable replacement for SystemProgressMorph though because it is too large and specific for that.
Well you asked for it:
1) You can pass an applyBlock rather than a duringBlock. The progressDisplay then applies the apply block to each element to each of the users values updating the display as it does so. The users values can be the values min..max or the values of a stream.
2) You can set a jump value k such that the display is updated once for each k times a display update request is sent. The minimum time that must pass before the display is updated is settable (it is fixed with SystemProgressMorph). Finally, a check is made that a display request update will actually modify the progressBar before the modification is performed. These changes were made because with SystemProgressMoprh, in some circumstances, the progressBar could take excessive amounts of time. However the last of these changes was probably all that was needed.
3) You can set the progressDisplay to catch user interrupts. Unfortunately this doesn't work correctly currently. The interrupt is caught but not processed until the progressBar closes. :-( I don't know how to fix this so suggestions or a fix most welcome.
4) You can set the start point to be other than at the beginning. If you start not at the beginning then you can set the progressDisplay to wrap once the end is reached. This is a weird feature but I need it for when I run a large collection of tests (not SUnit tests but similar). Say I run 1000 tests and the 900th test fails. I fix the problem and rerun the tests. I don't want to start at test one, I want to start at test 900, run tests 900-1000 and then run tests 1-899. The ProgressDisplay supports this and is the main reason I created it.
5) I have added an exception EarlyCompletionExit. This exception will be caught by progressDisplay if generated and result in the current progressBar being closed cleanly. If there is only one progressBar the entire display is closed.
6) If you want you can display the current value being processed and the total. The current value can be the user's value, the count of processed values, count of the number of user values remaining to be processed, the estimate of the amount of time remaining, or the time remaining estimate alternating with one of user value, count, countDown. The current value and total can be labelled if desired. The start poin, if not the beginning, can also be labelled.
7) The display does not flicker as much as SystemProgressMorph though this could still be improved.
8) Anything else I have forgotten.
There are large number of examples in class RunnProgressMorphExample which is a subclass of ExampleCase. In my image ExampleCase is an subclass of CodeCase and TestCase is also a subclass of CodeCase. Someday I hope to have TestCase refactored to have CodeCase as a superclass in Squeak/Pharo.
The examples use a number of utility classes which will eventually be moved to other packages. Some of them are:
1) ArrayPermutationsStream. Generates the permutations of a SequenceableCollection in a stream. Iteration, not recursion, is used. Ordering is not Lexicographic.
2) RangeList. Stores a sorted list of values where consecutive values are stored by listing them as an Interval. Example: 1,5-9,12,15,31-90 Example: $a,$c,$k-$t,$z This class is not complete. There are two subclasses: NumberRangeList and PositiveNumberRangeList also not complete.
3) NumberRangeListStream. Stream version of NumberRangeList.
4) NumericMultiplicityPartitionStream. For a given integer n, generates all numeric partitions of n (sums of positive numbers that add up to n) in lexicographic order. This can be combined with method SequenceableCollection>>multisetPermutationsDo: to generate arrays of size n containing combinations of the elements of 1..n with replacement (i.e. duplicates allowed). In another package I plan to use this for generating large numbers of test cases.
There are also a scattering of useful methods in places like Object, Nil, and SequenceableCollection.
Hope this helps.
Ralph Boland
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
Mariano Martinez Peck -
Ralph Boland -
Stéphane Ducasse