- Pharo-dev - lists.pharo.org

[Pharo-project] I need conseils for develop a grid layout
by nullPointer June 24, 2011

June 24, 2011

I want develop a universal layout in morphic. Something for work in most cases when is needed put widgets in a container in ordered way. I believe the best option is something like grid layout container from WPF. Can you give me a "start point"? I donÂ´t want work with inheritance from existent layouts, I want create a NEW mechanism for put controls, but I donÂ´t know for where begin. Many thanks for the help. -- View this message in context: http://forum.world.st/I-need-conseils-for-develop-a-grid-layout-tp3623459p3… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

2 1

[Pharo-project] [COTDC] 77 - LazyMorphTreeMorph
by laurent laffont June 24, 2011

June 24, 2011

Today: LazyMorphTreeMorph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

2 2

Re: [Pharo-project] Proposal to refactor MethodFinder with pragmas
by Carlo June 24, 2011

June 24, 2011

... because using method is old school and pragma's are new school ;) (Java annotations anyone) Arguably using pragma's is cleaner approach to specify orthogonal concerns but without full IDE support (refactorings etc to minimize unmaintained pragma's) I would argue for just using a method and package based on convention. At the end of the day both solutions will work but if we are going to aggregate all the MethodFinder acceptable selectors into a class method then we may as well drop the pragma... On 24 Jun 2011, at 3:41 PM, StÃ©phane Ducasse wrote: Yes we were wondering with igor why using pragmas and that a simple list would be enough. Stef On Jun 24, 2011, at 2:26 PM, Alexandre Bergel wrote: > Why not something like > > Magnitude class>>finderApprovedMethods > ^ {#max: . #min: . #min:max: . #< . ... } > > It is shorter and less magic is involved here. It will also be probably faster to do a query. > > Cheers, > Alexandre > > On 24 Jun 2011, at 05:25, Damien Cassou wrote: > >> Currently MethodFinder uses a list of acceptable selectors to execute. >> This list of selectors is not maintained which results in a lot of >> selectors to exist only in this list as they have been removed in the >> system. I propose to use pragmas on classes to generate this list >> automatically. >> >> Here is an example >> >> Magnitude class>>finderApprovedMethods >> <finderApproveInstanceMethod: #max:> >> <finderApproveInstanceMethod: #min:> >> <finderApproveInstanceMethod: #min:max:> >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #< > >> <finderApproveInstanceMethod: #<= > >> <finderApproveInstanceMethod: #between:and: > >> >> What do you think? >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

6 5

[Pharo-project] [ANN] hard freeze 1.3 and (slow) start of 1.4
by Marcus Denker June 24, 2011

June 24, 2011

So 1.3 seems to get stable... we added some fixes over the week, but most of them are related to Pavel's kernel, so they are just refactorings and cleanups, no real fixes. I think we should continue to test 1.3 and end of the month announce it. TODO is quite short: -> harvest the two last Full related issues -> two more Pavel Kernel fixes for core -> check one-click on hudson for release. We configured the infrastructure last week for 1.4... to get it -> update an image before 13267 and say "yes" when asked if you want to progress to 1.4 -> or download the image https://gforge.inria.fr/frs/download.php/28660/PharoCore-1.4-14000.zip -> The 1.4 stream uses a new squeaksource project (pharo14) as the other one was too large (>4000 mcz files). -> the updates are just the same as in 1.3 for now, the only difference is that ToolBuilder was unloaded. For continuous integration, 1.4 is using the new Jenkins setup: https://ci.lille.inria.fr/pharo/ No one-click yet, that will follow... the idea is to move now slowly to the new jenkins, while letting 1.2 and 1.3 on the old server (and turn it off at some point in the future). Jenkins sends out tweets for every build: http://twitter.com/#!/pharoci Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 3

Re: [Pharo-project] ConfigurationOfPhexample (was #assert:equals: feels backwards)
by laurent laffont June 24, 2011

June 24, 2011

Added: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPhexample'; load. (Smalltalk at: #ConfigurationOfPhexample) load. Actually one test is failing in PharoCore 1.3: ForExampleStack>>shouldFailWhenPopEmpty Laurent. On Thu, Jun 23, 2011 at 10:18 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Phexample does not patch SUnit at all. It adds only Object>>should, and > then everything else is 100% SUnit compatible by extending TestCase with > Phexample. > > But beside the DSL, with Phexample you also get a new way of organizing > your tests. Every test returns a value and thus becomes an example. And > examples can be based on other examples. This simple change makes the setUp > irrelevant because you can simply use an example for setting up. > > I believe this is a cool infrastructure. > > Cheers, > Doru > > > On 22 Jun 2011, at 08:38, laurent laffont wrote: > > > > > On Wed, Jun 22, 2011 at 7:58 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > > On Jun 22, 2011, at 7:44 AM, laurent laffont wrote: > > > > > Camillo and Dennis, > > > > > > Thanks for answer and yes, I think you're right about using > PhExample/Mocketry DSL, that's the way to go. > > > > except that I would not patch SUnit but have another Testing framework > for that. > > And I\m not sure that I want to write should equals:..... not enought > experience to have a good point of view > > > > > > > > I don't know about PhExample but Mocketry does not patch SUnit but > provide extensions to Object / SmallInteger / ... for the DSL part. > > > > It loads easily and also have an HelpSystem book :) > > > > Gofer it > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfMocketry'; > > load. > > > > ConfigurationOfMocketry load. > > > > 1 should equal: 1. > > > > > > I think I will use it for TWM. > > > > > > Laurent. > > > > > > > > Laurent. > > > > > > > > > On Wed, Jun 22, 2011 at 6:31 AM, Dennis Schetinin <chaetal(a)gmail.com> > wrote: > > > > > > > > > 2011/6/22 laurent laffont <laurent.laffont(a)gmail.com> > > > IMO having the expected value before is the right way ! Do you TDD ? It > makes a lot of sense for me to write assert: expected equals: actual. Am I > alone ? > > > > > > I practice TDD, and I start tests with assertions (after naming them). > But I'm not sure I specify expected value first, as I'm focused on the > result (I write the test for). Btw, I use Mocketry and exploit its sugar (or > DSL?) for specifications there. So, I write: > > > > > > actualValue should equal: expectedValue. > > > > > > That is, after I've decided on a test case and named it, I think: what > should I test? That's the actualValue. I name and write it. And only after > that, I think about the value it should haveâ¦ well, in most cases at least. > > > > > > Anyway, I'm not sure an order I use to write assertion should be > repeated by assertion messages. Just as order I use to write a test (name -> > assertion -> the way to fetch the actual value -> â¦) is not reflected by > test code. It's much more important to have a readable and understandable > (after many months) code. And for me it's much more natural to read it this > way: > > > > > > self assert: actualValue equals: expectedValue > > > > > > > > > > > > If you do TDD, you have first to decide what you expect. You don't know > how to get it because the code doesn't exist yet. So you usually I write > > > > > > self assert: 'i want this' equals: > > > > > > then stop because I have to think about the interface / selectors / > object I want. So it matches the flow of thought when I'm writing tests. > > > > > > And the other weird thing is that with this "fix" I now have to change > hundred of tests I've written to be semantically correct !!!! > > > > > > > > > Laurent. > > > > > > > > > On Wed, Jun 22, 2011 at 12:39 AM, Sean P. DeNigris < > sean(a)clipperadams.com> wrote: > > > > > > Mariano Martinez Peck wrote: > > > > > > > > I don't understand Sean's problem. > > > > > > > > > > Still using 1.2.2 :) Thanks for fixing it. > > > > > > Sean > > > > > > -- > > > View this message in context: > http://forum.world.st/assert-equals-feels-backwards-tp3614760p3615548.html > > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > > > > > > > > > > > > > > -- > > > Dennis Schetinin > > > > > > > > > > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > >

3 5

[Pharo-project] [update 1.4] #14012
by StÃ©phane Ducasse June 24, 2011

June 24, 2011

14012 ----- - Issue 4412: CompiledMethod >> #valueWithReceiver:arguments: instead of Object >> #withArgs:executeMethod:. http://code.google.com/p/pharo/issues/detail?id=4412

1 0

[Pharo-project] [update 1.4] #14011
by StÃ©phane Ducasse June 24, 2011

June 24, 2011

14011 ----- - MC Conflict cleanup: just renaming some methods.

1 0

June 24, 2011

14010 ----- - Issue 4439: Allow cherry-picking when merging. Second part removing MCConflict. http://code.google.com/p/pharo/issues/detail?id=4439 - Issue 4448: Cleaning MC conflicts Stef and Igor

1 0

[Pharo-project] ImageMap
by Pavel Krivanek June 24, 2011

June 24, 2011

Hi, I generated an image map for the latest PharoKernel image http://windmap.cz/playground/imagemap/1.html Let's hunt waste :-) -- Pavel

2 2

[Pharo-project] Proposal to refactor MethodFinder with pragmas
by Damien Cassou June 24, 2011

June 24, 2011

Currently MethodFinder uses a list of acceptable selectors to execute. This list of selectors is not maintained which results in a lot of selectors to exist only in this list as they have been removed in the system. I propose to use pragmas on classes to generate this list automatically. Here is an example Magnitude class>>finderApprovedMethods <finderApproveInstanceMethod: #max:> <finderApproveInstanceMethod: #min:> <finderApproveInstanceMethod: #min:max:> <finderApproveInstanceMethod: #< > <finderApproveInstanceMethod: #<= > <finderApproveInstanceMethod: #< > <finderApproveInstanceMethod: #<= > <finderApproveInstanceMethod: #between:and: > What do you think? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

4 5