- Pharo-dev - lists.pharo.org

Re: [Pharo-project] History and SUnit

by StÃ©phane Ducasse

Thanks I will have a look. I do not really understand what is written, this is too cryptic. Does the framework changes remove the fact that tests should start with test? Stef >> http://wiki.squeak.org/squeak/SUnit%20for%203.10 > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2008

Re: [Pharo-project] Formalised UI

by Gary Chambers

Well, I've done a bit with CSS (3.0) not fully looked though, just enough that our Report Builder file format (XML) is roughly equivalent. Just a thought about states of "widgets" I've seen in the wild... base Morphic doen't honour any of them by default... hence lots of extra code for dealing with interactive states in eveyone's subclasses/overrides. To be fair it is not appropriate to every Morph... just more common with "standard" (if you like) styles of widgets. As for ordinates, it was on IRC with Sig... tricky to track down logs, did find a link for a related dev-list email part of it though: http://www.nabble.com/Re:--squeak-dev--Subcanvas-p18270830.html Gary. ----- Original Message ----- From: "Michael Rueger" <m.rueger(a)acm.org> To: "An open mailing list to discuss any topics related to an open-sourceSmalltalk" <pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, October 02, 2008 6:42 PM Subject: Re: [Pharo-project] Formalised UI > Gary Chambers wrote: >> Just some thoughts picked up over the years. Things that all Morphs >> should have, at least, defaults for... >> >> UI States: > > how does this list compare to the list of possible CSS states? > > >> Transitions would be nice, but might be a bit overboard... Igor and I >> discussed a framework based on 4 dimensional representations being >> function based (I think we coined the phrase "Ordinates"). > > Can you say more about this? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2008

Re: [Pharo-project] Formalised UI

by Michael Rueger

Gary Chambers wrote: > Just some thoughts picked up over the years. Things that all Morphs > should have, at least, defaults for... > > UI States: how does this list compare to the list of possible CSS states? > Transitions would be nice, but might be a bit overboard... Igor and I > discussed a framework based on 4 dimensional representations being > function based (I think we coined the phrase "Ordinates"). Can you say more about this? Michael

Oct. 2, 2008

[Pharo-project] Formalised UI

by Gary Chambers

Just some thoughts picked up over the years. Things that all Morphs should have, at least, defaults for... UI States: Enabled Enabled Mouse over Enabled Mouse down inside Enabled Mouse down outside (?) Enabled Selected Enabled Selected Mouse over Enabled Selected Mouse down inside Enabled Selected Mouse down outside (?) Disabled Disabled Mouse over (?) Disabled Mouse down inside (?) Disabled Mouse down outside (?) Disabled Selected Disabled Selected Mouse over (?) Disabled Selected Mouse down inside (?) Disabled Selected Mouse down outside (?) "Inactive" (may be responsive to input, as aside from disabled) (part of non primary, up-front window) (as above) ... Transitions between states ... Perhaps it would be good to have Morph have generalised support for these (the inactive ones I've picked up from the Mac, background windows tend to have their controls in a "relatively passive look" state. Just some thoughts for moving ahead with Polymorph... Transitions would be nice, but might be a bit overboard... Igor and I discussed a framework based on 4 dimensional representations being function based (I think we coined the phrase "Ordinates"). Regards, Gary.

Oct. 2, 2008

Re: [Pharo-project] History and SUnit

by Damien Cassou

On Wed, Oct 1, 2008 at 5:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > can you tell us more? http://wiki.squeak.org/squeak/SUnit%20for%203.10 -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Oct. 2, 2008

Re: [Pharo-project] How to integrate Kernel-Extensions

by StÃ©phane Ducasse

I propose to harvest the cleaning behavior. I will go over the list and check Stef On Oct 1, 2008, at 10:53 PM, Damien Pollet wrote: > Hi list, we (with Stef) are browsing Kernel-Extensions, here are some > notes for discussion, as we think there is stuff that should be merged > in Pharo. > > Null and Split-Join could be packaged on their own since they are > well-defined features. > > Most of the cleanup methods make sense, but what's the difference > between cleanUp and freeSomeSpace ? > > AppRegistry class >> removeObsolete > "AppRegistry removeObsoleteClasses" > self registeredClasses copy do:[:cls| > (cls class isObsolete or:[cls isBehavior and:[cls isObsolete]]) > ifTrue:[self unregister: cls]]. > self subclasses do:[:cls| cls removeObsolete]. > > Behavior class >> flushObsoleteSubclasses > "Behavior flushObsoleteSubclasses" > ObsoleteSubclasses finalizeValues. > > Behavior >> sourceMatchesBytecodeAt: > > Class class >> freeSomeSpace > "Fix some problems with classes. Use Smalltalk allClassesDo: since it > does not use the subclass list, which we may be modifying during this > iteration" > Smalltalk allClassesDo: [:ea | > ea fixObsoleteSuperclass. > ea removeDuplicateSubclassEntries] > > Collection >> contains: should probably be standardized as part of > the STEPS project > Collection >> reject:thenDo: and select:thenDo: should be > included and similar enumerations reimplemented in this way too > > SystemDictionary >> forgetClass: aClass logged: aBool badly > named but interesting > "Delete the class, aClass, from the system. > Note that this doesn't do everything required to dispose of a class - > to do that use Class>>removeFromSystem." > > aBool ifTrue: [SystemChangeNotifier uniqueInstance classRemoved: > aClass fromCategory: aClass category]. > SystemOrganization removeElement: aClass name. > self removeFromStartUpList: aClass. > self removeFromShutDownList: aClass. > self removeKey: aClass name ifAbsent: []. > DataStream classRemoved: aClass. > self flushClassNameCache > > SystemDictionary >> globals needs to pay attention that compiled > methods share the associations > > Number >> to: stop do: aBlock displayingProgress: aString would be > probably nicer with the block argument last > > > === To discuss: > > Collection >> removeAll: comment should explain in which cases it > is useful > "the slow way" > ^ self removeAllSuchThat: [ :each | true ] > > SequenceableCollection >> <= smells funnyâ¦ what is it useful for ? > SequenceableCollection >> replacing:with: replaces in place, not > obvious from the name > the stream methods like putOn: â¦ convenience ? are they coherent ? > > String >> withoutTrailing: probably makes sense but then this is > mostly useful for line breaksâ¦ why not a #trimLinebreak > > Set >> likeOrAdd: ok but then that should be available for any > collection (and renamed addIfAbsent:) > "Include newObject as one of the receiver's elements, but only if > not already present. Answer the oldObject." > > > === Useless: > > ProtoObject >> iconOrThumbnailOfSize: > Object >> askFor: and askFor:ifDefault: that's a workaround > > Object >> deprecated is already here > Object >> log should be packaged in a logging package since it's a > convenience method > > SequenceableCollection >> copyReplacing:with: just to type one > space less ? > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2008

Re: [Pharo-project] Changes from COG

by StÃ©phane Ducasse

Thanks mathieu. We will include that since COG is MIT Stef On Oct 2, 2008, at 2:36 PM, Mathieu Suen wrote: > Hi, > > If you don't mind Eliot, I have taken a changeset from COG to Pharo. > You can integrate it. It should work fine > This change is for having a better CompiledMethod explorer. See > attached file. > > <BytecodeBrowsing.2.cs> > Mth > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 2, 2008

[Pharo-project] Package browser bugs

by StÃ©phane Ducasse

Hi david 2 bugs: - when I select a class in a hierarchy when I click on package, the package is not selected - the drag and drop on a package does not work with me. Let me know if you need a more precise example Stef

Oct. 2, 2008

[Pharo-project] Changes from COG

by Mathieu Suen

Hi, If you don't mind Eliot, I have taken a changeset from COG to Pharo. You can integrate it. It should work fine This change is for having a better CompiledMethod explorer. See attached file. Mth

Oct. 2, 2008

[Pharo-project] Fwd: [squeak-dev] re: Squeak 4

by StÃ©phane Ducasse

for information. I will continue to harvest etoy removals and gary/simon enh. Stef > From: Craig Latta <craig(a)netjam.org> > Date: October 1, 2008 10:49:14 PM CEDT > To: squeak-dev(a)lists.squeakfoundation.org > Subject: [squeak-dev] re: Squeak 4 > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > Hi Stef-- > > > Just out of curiosity on which version is based Squeak 4. > > Squeak 3.2? > > Well, that question is mostly meaningless when so much is > removed. :) The most recent significant thing in there is support > for weak references, which I think comes from 3.2. The VMs are all > the latest, though. > > > -C

Oct. 2, 2008