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

Re: [Pharo-project] ProgressDisplay package features

by Mariano Martinez Peck

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(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 2, 2010

Re: [Pharo-project] Poll: missing libraries to support business

by Norbert Hartl

Here are some of the things I'm missing: fulltext search/text retrieval ---------------------------------------- - fuzzy search (http://en.wikipedia.org/wiki/Approximate_string_matching) - proximity search (http://en.wikipedia.org/wiki/Proximity_search_(text)) - stemming (http://en.wikipedia.org/wiki/Stemming) - faceted search (http://en.wikipedia.org/wiki/Faceted_search) If there were a good support or integration with collections that could ease a lot of use cases especially in web environments. At the moment I'm serializing objects to XML documents and put this into SOLR (http://lucene.apache.org/solr/) Before tsearch2 on postgresql spatial data services ------------------------------ - quad-tree (http://de.wikipedia.org/wiki/Quadtree) - r-tree (http://en.wikipedia.org/wiki/R-tree) Again nice integration with collections would be very powerful. Spatial data are more and more important. There is support for google maps and such but no support to store spatial data. Back then I used postGis (on postgresql) for that. authentication frameworks -------------------------------------- - OAuth (http://oauth.net/) - open-id (http://openid.net/) To ease the authentication of users and web APIs those two mentioned are quite important (needs checking) That are the ones I miss on a regular basis. hope this helps, Norbert On 02.08.2010, at 21:50, StÃ©phane Ducasse wrote: > Hi guys > > with the experience around the XMLRPC project, ESUG wants to change strategy to help growing business at the technical > level. So what are the key areas where you think that effort should be supported to help you making business in smalltalk? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2010

Re: [Pharo-project] Test Runner 'File out results' button

by Mariano Martinez Peck

maybe becaue it is not very user friendly?? I wasn't completly aware at all. I was 5 minutes trying to see where to do the double click. Do you think that this is user friendly? why would you click on an empty area? are we talking about the same? I attach screenshot Cheers mariano On Mon, Aug 2, 2010 at 10:09 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Aug 2, 2010, at 5:14 PM, laurent laffont wrote: > > > > > On Mon, Aug 2, 2010 at 4:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Recently the button 'File out results' was added to the test runner. > > > > I find this button extremely annoying because it is something i don't > > use daily and it doesn't fit into the group of run-action like all the > > other buttons. I keep on accidentally clicking it. > > > > Why wasn't this action added to the context menu on the test results > > that already has related items like 'History', 'Store results', 'Show > > progress'? > > > > Because the issue was "Button in TestRunner to fileout the test results" > :) > > http://code.google.com/p/pharo/issues/detail?id=1281 > > > > For myself, I don't really care. Anyone for context menu ? > > yes > > the idea is that doing and making mistake is more important than talking > so we are allowed to change and fix :) > > > > > > Laurent > > > > > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 2, 2010

Re: [Pharo-project] ProgressDisplay package features

by StÃ©phane Ducasse

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2010

Re: [Pharo-project] Test Runner 'File out results' button

by StÃ©phane Ducasse

On Aug 2, 2010, at 5:14 PM, laurent laffont wrote: > > On Mon, Aug 2, 2010 at 4:30 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Recently the button 'File out results' was added to the test runner. > > I find this button extremely annoying because it is something i don't > use daily and it doesn't fit into the group of run-action like all the > other buttons. I keep on accidentally clicking it. > > Why wasn't this action added to the context menu on the test results > that already has related items like 'History', 'Store results', 'Show > progress'? > > Because the issue was "Button in TestRunner to fileout the test results" :) > http://code.google.com/p/pharo/issues/detail?id=1281 > > For myself, I don't really care. Anyone for context menu ? yes the idea is that doing and making mistake is more important than talking so we are allowed to change and fix :) > > Laurent > > > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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

Aug. 2, 2010

Re: [Pharo-project] about ToolBuilder

by StÃ©phane Ducasse

where? > See Gilad's text about least common denominator in UI-widgetery

Aug. 2, 2010

Re: [Pharo-project] about ToolBuilder

by StÃ©phane Ducasse

> I agree that it should be removed, but this means that many tools need > to be rewritten in plain morphic. do you know which ones? Because a lot of buildwith: methods are not used in fact. > Lukas > > 2010/8/2 Richard Durr <richard.durr(a)googlemail.com>: >> +1. >> See Gilad's text about least common denominator in UI-widgetery >> >> On Fri, Jul 30, 2010 at 12:20 PM, stephane ducasse >> <stephane.ducasse(a)free.fr> wrote: >>> >>> Hi guys >>> >>> during the sprint I discussed with Gary about ToolBuilder and we think >>> that it would be better to remove it >>> since a lot of new widgets are not covered so this means that we will be >>> constantly limiting ourselves. >>> Of course ToolBuilder is a nice idea (if we would have several UI >>> framework). So far we got only one >>> and we would have several we would have to take the smallest common >>> denominator. >>> Another idea would be to extend toolBuilder to support new widgets. >>> So what do you think? >>> >>> Stef >>> _______________________________________________ >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2010

Re: [Pharo-project] Pharo 1.1 host menu os x

by StÃ©phane Ducasse

But I checked and this is clearly not the case and I do not like that. Stef On Aug 2, 2010, at 10:03 PM, StÃ©phane Ducasse wrote: > this is strange because I thought that we get the complete history chain in the Pharo folder since we always > merge and republish. > > Stef > > On Aug 2, 2010, at 2:43 PM, Michael Roberts wrote: > >> Hi, >> i am trying to publish a fix, but I get MC error can't find >> HostMenus-LaurentLaffont.53. It is the ancestor of >> HostMenus-MarcusDenker.54 but does not seem to be in the /Pharo >> package. Where did it go? >> >> thanks, >> Mike >> >> _______________________________________________ >> 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

Aug. 2, 2010

Re: [Pharo-project] Pharo 1.1 host menu os x

by StÃ©phane Ducasse

this is strange because I thought that we get the complete history chain in the Pharo folder since we always merge and republish. Stef On Aug 2, 2010, at 2:43 PM, Michael Roberts wrote: > Hi, > i am trying to publish a fix, but I get MC error can't find > HostMenus-LaurentLaffont.53. It is the ancestor of > HostMenus-MarcusDenker.54 but does not seem to be in the /Pharo > package. Where did it go? > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2010

Re: [Pharo-project] Limitation of number os literals in a method?

by StÃ©phane Ducasse

a suggestion lblImage does not read well in Smalltalk labelImage is way better and you only need two extra characters. Favor readibility. Stef On Aug 2, 2010, at 2:53 PM, nullPointer wrote: > > Finnally I call for each widget another method spec for configure it. Is > possible now reproduce the same error, but is much more difficult. > > http://paste.lisp.org/display/113020#1 > > I wait that version it seems less revolting to Randal xD > > I will upload that fix in SqueakSource UIBuilder project. > > Anyway I donÂ´t understant really the problem of limitation at 256 literals. > Is for VM? yes. The problem is where do you store literals (nil, 'mystring' #asymbol #+) that are in a method. The solution is that a method is composed on bytecode (stack language) and its store its literal in a literal frame. So far nothing special. Now the problem is that there are byte code to access literal objects and this bytecode is limited. so you cannot store too many literals in a method. > > Regards > -- > View this message in context: http://forum.world.st/Limitation-of-number-os-literals-in-a-method-tp230874… > 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

Aug. 2, 2010