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

Re: [Pharo-project] Polymorph observations

by Schwab,Wilhelm K

Gary, Thanks for the pointers. Your point on default models is well-taken, but nothing (not much anyway) prevents their being replaced when something such as an aspect value adaptor is indicated. Changing models on the fly has long been a weakness of Dolphin; Object Arts essentially said "do as we say, not as we do." I think we can find ways to make it all work as one would hope. At a minimum, there should be alternative factory selectors that do not require the selection aspects when those do nothing besides support the user interface (which I submit is probably more often than not). Details aside, Polymorph is very impressive work - thanks for making it available to us!! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Gary Chambers Sent: Thursday, October 15, 2009 5:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Polymorph observations Thanks Bill. The "Squeak" way allows double-click just inside the first quote to select the relevant snippet of course though ;-) Perhaps default models would be a good idea though it can, with over-reliance, tend to distance things from the real model... Nothing in TEasilyThemed for splitters. Note that Polymorph only fixes issues with SystemWindow splitter usage at present, rather than arbitrary owner morphs. Given a system window: win addPaneVSplitterBetween: morph1 and: {morph2}. main splitters last color: win paneColor. Given other morphs (for the moment). aMorph addPaneVSplitterBetween: morph1 and: {morph2}. aMorph splitters last color: aMorph paneColor; addLeftOrTop: morph1; addRightOrBottom: morph2. Regards, Gary ----- Original Message ----- From: Schwab,Wilhelm K<mailto:bschwab@anest.ufl.edu> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, October 13, 2009 2:10 AM Subject: [Pharo-project] Polymorph observations Gary, I have done a little with Polymorph and am quite impressed. A small usability suggestion for the examples is to include comments with the text on a line by itself. It is a lot easier to execute something formatted as " ThisOrThat example ThisOrThat someOtherExample " than it is the (very common in Squeak) "GoAhead iChallengeYouToSelectMe andMissTheQuotes". On to more substantive things. TEasilyThemed is a big help, but some model and/or presenter classes would help. Consider a list. One has to define an aspect for the selection index and initialize it to zero. Similar comments apply to trees, with the added wrinkle of wrapping the nodes with appropriate objects. Dolphin's MVP framework creates default models that can be replaced. One weakness of the defaults is that they can take significant time to create for substantial objects. I hacked around that, and we could easily design it out of anything that we build. Dolphin lists and trees treat their selection in terms of the object selected rather than the index. One can get and set the index if needed, but it is not generally as interesting as the object behind the selection. One good thing about specifying the aspect is that one can can connect a view to an aspect of any model. Dolphin allows for the same flexibility via value adapters and type converters. Does TEasilyThemed include helpers for creating splitters? Bill ________________________________ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 15, 2009

[Pharo-project] Google code / test running

by Torsten Bergmann

The SqueakSVN pages moved to: http://www.hpi.uni-potsdam.de/hirschfeld/projects/ssvn/index.html Maybe it is of use to automate the SVN tasks ... Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Oct. 15, 2009

[Pharo-project] Google code / test running

by Torsten Bergmann

Havent tried it but there is a SqueakSVN project to get access to SVN: http://map.squeak.org/package/184ebabe-a32c-403f-8088-ff85233cabca/autovers… Read more here: http://news.squeak.org/2008/09/16/subversion-integration-for-squeak/ Bye Torsten -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02

Oct. 15, 2009

[Pharo-project] Google code / test running

by Michael Roberts

I have uploaded a GoogleCode package to PharoTaskForces. It is an improvement on the baseline test scripts. To get going have a look at PharoTestScript and modify some of the constants. If you want to participate running tests you need to first checkout the wiki using svn. You can see how that is done in the code or just follow google's help page. You need your profile password to do commits. I have a minimal svn wrapper which is intended to be hooked up to e.g OSProcess but that is just scaffolding until i can test it. The operation is basically runs all the tests, write out a wiki page, and add & commit to the wiki. There is more to do, but it is better than the original changeset. cheers, Mike

Oct. 15, 2009

Re: [Pharo-project] About TestCase >> assert:

by Alexandre Bergel

> Agreed. I prefer, though, to use BlockClosure>>assert, so usage > becomes > something like: > > [2 + 2 = 5] assert. > > I see that this is already implemented, based on Object>>assert: I agree this is more concise, there is no reference to "self" to formulate the assertion. Having to use "self" in "self assert:" has more to do with an unnecessary convention than bringing a real value. In that case, disabling assertion has to be done by modifying BlockClosure>>assert. > There are inconsistencies that bother me. > > * TestCase>>assert: in most Smalltalks accepts only a boolean. In > Pharo, > it accepts either a boolean or a block. This makes tests less > portable. > > * TestCase>>assert:equals: (a very useful method) does not accept a > block. Anyone used to giving blocks to #assert: would probably expect > this method to accept a block. The method assert:equals: should accept a block in my opinion. TestCase>>assert:equals: may be rewritten as: assert: expectedAsBlockOrValue equals: actualAsBlockOrValue | v1 v2 | v1 := expectedAsBlockOrValue value. v2 := actualAsBlockOrValue value. ^ self assert: (v1 = v2) description: (self comparingStringBetween: v1 and: v2) > * Object assert: accepts a boolean or a block. I don't know of any > standard for this. No standard as far as I know > * BlockClosure>>assert does not take any arguments, so I feel it is > very > clean. But you need to modify it to cancel runtime checks > Proposed changes: (based on earlier discussion plus personal opinion) > > TestCase>>assert: should only accept a boolean. This brings > compatibility with other Smalltalks, and consistency with > TestCase>>assert:equals:. assert:equals: could also be updated. Some test units in the image use [] as arguments to assert: and deny:. StringTest is one of them. > Object>>assert: should be removed/deprecated in favor of > BlockClosure>>assert. This removes confusion with TestCase>>assert:. Ideally, this is valuable. However, there is a number of tests that use Object>>assert: (and not only my code :-). ZipEncoderTree is an example > Object>>assert:description: and Object>>assert:descriptionBlock: > should > be removed/deprecated in favor of (new) > BlockClosure>>assertWithDescription:, which accepts either a block > or a > string. This provides convenient invariant and pre/post condition > testing. #assertWithDescription: is useful yes. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 15, 2009

Re: [Pharo-project] About TestCase >> assert:

by Martin McClure

Henrik Johansen wrote: > Why not rename Object>>assert: to should:, so it avoids breaking > polymorphism, and keep TestCase>>assert: reserved for a boolean argument > to stay compatible with SUnit in other dialects? > > On the negative side, it might not be as intuitive using should: for > pre/post-assertions, as well as inconvenient to remember the difference > between assert: and should: in TestCases. Not big enough negatives to > outweigh the benefits though, imo. > Henry, Sorry, I hadn't read this mail before making a proposal. I agree that renaming Object>>assert: to #should: would be an improvement. But I still think it's probably better to remove it altogether and send #assert to a block. It may just be me, but I've always felt that as a selector 'should' doesn't really communicate the intent as well as 'assert'. Regards, -Martin

Oct. 15, 2009

Re: [Pharo-project] About TestCase >> assert:

by Martin McClure

Alexandre Bergel wrote: >> Ah, sorry for the confusion. What I'm talking about here (and I >> assumed >> Alexandre was as well, but I could be mistaken) is indeed the use of >> #assert: or some other message to test runtime invariants. So you'd >> put >> something like: > [...] > > This is exactly what I had in mind > I regularly use assert: to describe invariant, pre and postcondition. > This complement testing pretty well in my opinion. Agreed. I prefer, though, to use BlockClosure>>assert, so usage becomes something like: [2 + 2 = 5] assert. I see that this is already implemented, based on Object>>assert: There are inconsistencies that bother me. * TestCase>>assert: in most Smalltalks accepts only a boolean. In Pharo, it accepts either a boolean or a block. This makes tests less portable. * TestCase>>assert:equals: (a very useful method) does not accept a block. Anyone used to giving blocks to #assert: would probably expect this method to accept a block. * Object assert: accepts a boolean or a block. I don't know of any standard for this. * BlockClosure>>assert does not take any arguments, so I feel it is very clean. Proposed changes: (based on earlier discussion plus personal opinion) TestCase>>assert: should only accept a boolean. This brings compatibility with other Smalltalks, and consistency with TestCase>>assert:equals:. Object>>assert: should be removed/deprecated in favor of BlockClosure>>assert. This removes confusion with TestCase>>assert:. Object>>assert:description: and Object>>assert:descriptionBlock: should be removed/deprecated in favor of (new) BlockClosure>>assertWithDescription:, which accepts either a block or a string. This provides convenient invariant and pre/post condition testing. Opinions? -Martin

Oct. 15, 2009

Re: [Pharo-project] Sprint information

by Tudor Girba

I will also see to arrive early :) My phone is: +41 76 579 0423 Cheers, Doru On 15 Oct 2009, at 15:01, Oscar Nierstrasz wrote: > > I plan to arrive early. +41 78 628 0817 > > - on > > On 15 Oct 2009, at 09:18, StÃ©phane Ducasse wrote: > >> Hi guys >> >> Here are some information about the sprint. >> >> The place is located at LIFL in a room close to our office. >> http://rmod.lille.inria.fr >> check at the bottom of the page (pay attention our physical address >> is not the same than our mail address. >> We are NOT in the INRIA building. >> >> In short you should take the metro up to Cite Scientifique and walk >> south until the round point and turn right after a moment >> you should have a parking on your left and the building is doing a >> kind of large L >> >> The entrance in the building is at the crossing of the L. >> >> Now the building will be closed on saturday and I can open the door. >> I plan to be at the lab at 9h00. >> >> Now I do not have a mobile phone... so it would be good that we share >> mobile numbers so that >> we have a base for connecting us. >> The idea is that we will write on a sheet of paper the mobile phone >> number of the first one that will arrive. >> >> 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 -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

Oct. 15, 2009

[Pharo-project] [update] #10471

by StÃ©phane Ducasse

10471 ----- - Issue 1309: Date and time speedup creation from squeaktrunk - Issue 1233: Needs changes after fix 1129 Stef

Oct. 15, 2009

Re: [Pharo-project] New items in Pharo Core merger

by Gary Chambers

Means digging into/modifying MC itself I fear... >From what I've investigated, the MCMergeResolutionRequest mechanism only handles changes to the state or what is to be merged when conflicting (within same package)... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, October 15, 2009 2:37 PM Subject: Re: [Pharo-project] New items in Pharo Core merger >I think that we should really improve the merge tool to help us > so any step in that direction is welcomed. > > Stef > > On Oct 15, 2009, at 12:52 PM, Henrik Johansen wrote: > >> Would it be possible to enable "Keep current version" (ie, don't >> install >> the version from the thing being merged) to the menu list for New >> items >> in the Monticello merger? >> It's kind of hard to f.ex. merge Squeak-trunk Collections, containing >> Base64MimeConverter, when in Pharo, that Class exists in a different >> package. >> At least as far as I can tell (haven't actually done it, as I don't >> feel >> like resolving the 260 other conflicts just to find out), applying the >> merge will result in move the class. >> Alternatively to check if the item already exists in the system, but >> in >> a different package, and mark that as a conflict. >> >> Cheers, >> Henry >> >> _______________________________________________ >> 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

Oct. 15, 2009