Smalltalk › Squeak › Squeak - Dev

[squeak-dev] Questionable constraint in ProportionalSplitterMorph

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Trygve

[squeak-dev] Questionable constraint in ProportionalSplitterMorph

Squeak3.10.gamma.7159, WinXP/SP2

I have a window with four panes:
    top left: LayoutFrame fractions: (0@0 corner: [hidden email])).
    top right pane: LayoutFrame fractions: (0.2@0 corner: [hidden email]).
    bottom left pane: LayoutFrame fractions: ([hidden email] corner: 0.19@1).
    bottom right pane: LayoutFrame fractions: ([hidden email] corner: 1@1).

self addPaneSplitters does its impressive magic;
    a horizontal pane splitter right across the window at y=0.5
    two vertical pane splitters one between top left and top right and another between bottom left and bottom right.
(The latter two has 'splitsTopAndBottom'=false)

The curious thing is that the two vertical pane splitters are linked; any one of them cannot be moved past the other one. The constraint is in these methods
ProportionalSplitterMorph>>
    normalizedX: x
             ^ (x max: self leftBoundary) min: self rightBoundary
    rightBoundary
            ^ (self splitterRight ifNil: [self containingWindow panelRect right] ifNotNil: [self splitterRight left]) - 50
    splitterRight
        | splitters |
        splitters _ ((self siblingSplitters select: [:each | each x > self x]) asSortedCollection: [:a :b | a x < b x]).
        ^ splitters ifEmpty: nil ifNotEmpty: [splitters first]
    siblingSplitters
        ^ self owner submorphsSatisfying: [:each | (each isKindOf: self class) and: [self splitsTopAndBottom = each splitsTopAndBottom] and: [each ~= self]]

Does anybody know the motivation for this curious behavior? The easiest workaround would be to hack siblingSplitters to return an empty collection. Perhaps it would be better with a new preference? (Subclassing ProportionalSplitterMorph does not seem practicable).

I'll be grateful for enlightenment about this curious behavior.
--Trygve

--
--

Trygve Reenskaug mailto: [hidden email]

Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver

N-0378 Oslo Tel: (+47) 22 49 57 27

Norway

Gary Chambers-4

RE: [squeak-dev] Questionable constraint in ProportionalSplitterMorph

The UI Enhancements package contains modifications to provide the behaviour you are expecting.

http://wiki.squeak.org/squeak/6005

Regards, Gary.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]On Behalf Of Trygve Reenskaug
Sent: 01 June 2008 8:53 PM
To: The general-purpose Squeak developers list
Subject: [squeak-dev] Questionable constraint in ProportionalSplitterMorph

Squeak3.10.gamma.7159, WinXP/SP2

I have a window with four panes:
    top left: LayoutFrame fractions: (0@0 corner: [hidden email])).
    top right pane: LayoutFrame fractions: (0.2@0 corner: [hidden email]).
    bottom left pane: LayoutFrame fractions: ([hidden email] corner: 0.19@1).
    bottom right pane: LayoutFrame fractions: ([hidden email] corner: 1@1).

self addPaneSplitters does its impressive magic;
    a horizontal pane splitter right across the window at y=0.5
    two vertical pane splitters one between top left and top right and another between bottom left and bottom right.
(The latter two has 'splitsTopAndBottom'=false)

The curious thing is that the two vertical pane splitters are linked; any one of them cannot be moved past the other one. The constraint is in these methods
ProportionalSplitterMorph>>
    normalizedX: x
             ^ (x max: self leftBoundary) min: self rightBoundary
    rightBoundary
            ^ (self splitterRight ifNil: [self containingWindow panelRect right] ifNotNil: [self splitterRight left]) - 50
    splitterRight
        | splitters |
        splitters _ ((self siblingSplitters select: [:each | each x > self x]) asSortedCollection: [:a :b | a x < b x]).
        ^ splitters ifEmpty: nil ifNotEmpty: [splitters first]
    siblingSplitters
        ^ self owner submorphsSatisfying: [:each | (each isKindOf: self class) and: [self splitsTopAndBottom = each splitsTopAndBottom] and: [each ~= self]]

Does anybody know the motivation for this curious behavior? The easiest workaround would be to hack siblingSplitters to return an empty collection. Perhaps it would be better with a new preference? (Subclassing ProportionalSplitterMorph does not seem practicable).

I'll be grateful for enlightenment about this curious behavior.
--Trygve

--

Trygve Reenskaug       mailto: [hidden email]

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

Trygve

Re: [squeak-dev] Questionable constraint in ProportionalSplitterMorph

Many thanks, Gary.
This package seems to include a lot of stuff I have been missing in the release image.
--Trygve

On 02.06.2008 12:19, Gary Chambers wrote:

--
The UI Enhancements package contains modifications to provide the behaviour you are expecting.

http://wiki.squeak.org/squeak/6005

Regards, Gary.

-----Original Message-----
From: [hidden email] [[hidden email]]On Behalf Of Trygve Reenskaug
Sent: 01 June 2008 8:53 PM
To: The general-purpose Squeak developers list
Subject: [squeak-dev] Questionable constraint in ProportionalSplitterMorph

Squeak3.10.gamma.7159, WinXP/SP2

I have a window with four panes:
    top left: LayoutFrame fractions: (0@0 corner: [hidden email])).
    top right pane: LayoutFrame fractions: (0.2@0 corner: [hidden email]).
    bottom left pane: LayoutFrame fractions: ([hidden email] corner: 0.19@1).
    bottom right pane: LayoutFrame fractions: ([hidden email] corner: 1@1).

self addPaneSplitters does its impressive magic;
    a horizontal pane splitter right across the window at y=0.5
    two vertical pane splitters one between top left and top right and another between bottom left and bottom right.
(The latter two has 'splitsTopAndBottom'=false)

The curious thing is that the two vertical pane splitters are linked; any one of them cannot be moved past the other one. The constraint is in these methods
ProportionalSplitterMorph>>
    normalizedX: x
             ^ (x max: self leftBoundary) min: self rightBoundary
    rightBoundary
            ^ (self splitterRight ifNil: [self containingWindow panelRect right] ifNotNil: [self splitterRight left]) - 50
    splitterRight
        | splitters |
        splitters _ ((self siblingSplitters select: [:each | each x > self x]) asSortedCollection: [:a :b | a x < b x]).
        ^ splitters ifEmpty: nil ifNotEmpty: [splitters first]
    siblingSplitters
        ^ self owner submorphsSatisfying: [:each | (each isKindOf: self class) and: [self splitsTopAndBottom = each splitsTopAndBottom] and: [each ~= self]]

Does anybody know the motivation for this curious behavior? The easiest workaround would be to hack siblingSplitters to return an empty collection. Perhaps it would be better with a new preference? (Subclassing ProportionalSplitterMorph does not seem practicable).

I'll be grateful for enlightenment about this curious behavior.
--Trygve

--

Trygve Reenskaug       mailto: [hidden email]

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway
  

--
--

Trygve Reenskaug mailto: [hidden email]

Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver

N-0378 Oslo Tel: (+47) 22 49 57 27

Norway

keith1y

[squeak-dev] Hit end of changes file limit

I just, rather inconveniently, hit the end of the changes file limit.

Can someone remind me where we got to on resolving this issue?

Keith

timrowledge

Re: [squeak-dev] Hit end of changes file limit

On 2-Jun-08, at 7:30 AM, Keith Hodges wrote:

> I just, rather inconveniently, hit the end of the changes file limit.

Well obviously the first thing to do is condense the changes; assuming
you haven't just got to a state where you've broken the condensing
code. DAMHIKT.
>
>
> Can someone remind me where we got to on resolving this issue?

I was attempting to incorporate my (ancient) compiled method format
related changes that allowed arbitrary file accessor objects instead
of nasty encrypted pseudo integers. But I got confused by problems
with Traits and my (lack of) understanding of them and the tools
inadequacy and then work got in the way and I haven't been back there.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: XM: Exclusive Maybe

Herbert König

Re: [squeak-dev] Hit end of changes file limit

In reply to this post by keith1y

Hello Keith,

KH> Can someone remind me where we got to on resolving this issue?
Klaus D. Witzel has a 512MB Patch for Sources and changes posted here
28. July 2008.

Hopefully you didn't hit that limit and IIRC it was important to do
something about that *before* reaching the limit.

--
Cheers,

Herbert

Herbert König

Re: [squeak-dev] Hit end of changes file limit

HK> Hello Keith,

KH>> Can someone remind me where we got to on resolving this issue?
HK> Klaus D. Witzel has a 512MB Patch for Sources and changes posted here
HK> 28. July 2008.

Sorry 2006 that was and I even managed to get it attached now :-))

--
Cheers,

Herbert

[Patch] Both source files now with 512MB capacity.TXT (2K) Download Attachment

LargeSourceFilePointers-kwl.0.cs (6K) Download Attachment

LargeSourceFilePointers-kwl.1.cs (6K) Download Attachment

Klaus D. Witzel

[squeak-dev] Re: Hit end of changes file limit

In reply to this post by Herbert König

On Mon, 02 Jun 2008 20:23:02 +0200, Herbert König wrote:

> Hello Keith,
>
>
> KH> Can someone remind me where we got to on resolving this issue?
> Klaus D. Witzel has a 512MB Patch for Sources and changes posted here
> 28. July 2008.

:)

> Hopefully you didn't hit that limit and IIRC it was important to do
> something about that *before* reaching the limit.

If you're already in trouble, I'd suggest you condense changes with a
single doIt (since doIt's write to .changes).

>
>

Klaus D. Witzel

[squeak-dev] Re: Hit end of changes file limit

In reply to this post by Herbert König

On Mon, 02 Jun 2008 20:26:23 +0200, Herbert König wrote:

>
> HK> Hello Keith,
>
>
> KH>> Can someone remind me where we got to on resolving this issue?
> HK> Klaus D. Witzel has a 512MB Patch for Sources and changes posted here
> HK> 28. July 2008.
>
> Sorry 2006 that was and I even managed to get it attached now :-))

Thanks to Philippe's tests it also became clear that any such patch to the
existing source files system should be applied *after* emptying the
.changes file.

>

Edgar J. De Cleene

Re: [squeak-dev] Hit end of changes file limit

In reply to this post by timrowledge

El 6/2/08 2:36 PM, "tim Rowledge" <[hidden email]> escribió:

> I was attempting to incorporate my (ancient) compiled method format
> related changes that allowed arbitrary file accessor objects instead
> of nasty encrypted pseudo integers. But I got confused by problems
> with Traits and my (lack of) understanding of them and the tools
> inadequacy and then work got in the way and I haven't been back there.
>
> tim

Please send this as we soon have images without Traits.

Edgar

Rob Rothwell

Re: [squeak-dev] Re: Hit end of changes file limit

In reply to this post by Klaus D. Witzel

On Mon, Jun 2, 2008 at 2:36 PM, Klaus D. Witzel <[hidden email]> wrote:

If you're already in trouble, I'd suggest you condense changes with a single doIt (since doIt's write to .changes).

As a new user wanting to avoid such an issue, would I use Smalltalk condenseChanges?

Rob

stephane ducasse

Re: [squeak-dev] Hit end of changes file limit

In reply to this post by timrowledge

Traits shared compiled method with their classes except if there is a
super (because the super refers to the superclass of the class in
which the traits is used and not the trait itself) (may be this is
just a cool hack we should not have done).
I plan to have a look at the implementation of andreas to see if we
could get less intrusive traits.
But I'm flooded with admin and esug preparation.

Stef

On Jun 2, 2008, at 7:36 PM, tim Rowledge wrote:

>
> On 2-Jun-08, at 7:30 AM, Keith Hodges wrote:
>
>> I just, rather inconveniently, hit the end of the changes file limit.
>
> Well obviously the first thing to do is condense the changes;
> assuming you haven't just got to a state where you've broken the
> condensing code. DAMHIKT.
>>
>>
>> Can someone remind me where we got to on resolving this issue?
>
> I was attempting to incorporate my (ancient) compiled method format
> related changes that allowed arbitrary file accessor objects instead
> of nasty encrypted pseudo integers. But I got confused by problems
> with Traits and my (lack of) understanding of them and the tools
> inadequacy and then work got in the way and I haven't been back there.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: XM: Exclusive Maybe
>
>
>
>

Edgar J. De Cleene

Re: [squeak-dev] Re: Hit end of changes file limit

In reply to this post by Rob Rothwell

El 6/2/08 5:28 PM, "Rob Rothwell" <[hidden email]> escribió:

> As a new user wanting to avoid such an issue, would I use Smalltalk
> condenseChanges?
>
> Rob

Normal images have small .changes files, so yes is safe use Smalltalk
condenseChanges.

Squeak3.10.gamma.7159.changes have 1.8 Mb

First SqueakLightII.7067.changes have 96 k

You need mess a lot for find such trouble :=)

Edgar

Rob Rothwell

Re: [squeak-dev] Re: Hit end of changes file limit

On Mon, Jun 2, 2008 at 5:14 PM, Edgar J. De Cleene <[hidden email]> wrote:

Normal images have small .changes files, so yes is safe use Smalltalk
condenseChanges.

Squeak3.10.gamma.7159.changes have 1.8 Mb

First SqueakLightII.7067.changes have 96 k

You need mess a lot for find such trouble :=)

So is 23 Mb "messing a lot?!"

When should a person get worried?

Rob

keith1y

Re: [squeak-dev] Re: Hit end of changes file limit

In reply to this post by Rob Rothwell

Rob Rothwell wrote:

> On Mon, Jun 2, 2008 at 2:36 PM, Klaus D. Witzel
> <[hidden email] <mailto:[hidden email]>> wrote:
>
> If you're already in trouble, I'd suggest you condense changes
> with a single doIt (since doIt's write to .changes).
>
>
> As a new user wanting to avoid such an issue, would I use Smalltalk
> condenseChanges?
>
> Rob

Hello Rob,

I wouldn't worry about it until you need it. I was loading and reloading
a really really big package, possibly the biggest package out there.

It did give me three warnings, so there is nothing to worry about.
However this doesnt mean we shouldnt try and fix it for 3.11

Keith

p.s. 3.11 will have Traits in it. The TraitsUnload script is an option
for those that want it.

Edgar J. De Cleene

Re: [squeak-dev] Re: Hit end of changes file limit

In reply to this post by Rob Rothwell

El 6/2/08 6:51 PM, "Rob Rothwell" <[hidden email]> escribió:

> So is 23 Mb "messing a lot?!"
>
> When should a person get worried?
>
> Rob
How you go from few mb to 23 Mb (or more) ?

I guess you have a populated image, each time you dowload and install some
of any SM, Universes, Installer, Monticello, or your own .st , .cs, .sar ,
etc, .image size grows and also .changes.
Not all going to .changes is needed, if your image don't cause headaches to
you, maybe is time to do Smalltalk condenseChanges.

We have three choices when 3.10 start.
1) the Klaus 512 mb idea
2) the Dan compressedChanges idea
3) build new .sources and deliver with empty changes

Ralph comes with some Maurice Raab start to develop , but is not ready in
time , so we deliver with normal .changes and same 3.9 .sources.

With SqueakLightII I try to go wild and have a "class repository" in
compressed by Squeak way.

You could have a glimpse of how looks 2005 3.8 such repository in
ftp://[hidden email]:21/squeakros.atspace.com/CompressedClas
ses
pass is squeak , as you could guess

Edgar

Rob Rothwell

Re: [squeak-dev] Re: Hit end of changes file limit

On Mon, Jun 2, 2008 at 6:15 PM, Edgar J. De Cleene <[hidden email]> wrote:

How you go from few mb to 23 Mb (or more) ?

Actually, I started with one of the squeak-dev images, which started out around 10Mb...I'm not sure what I've done after that given the seemingly small size of the project I am working on; I seem to be having some image size expansion at a pretty good rate too, which I think I will ask the beginners list about!

Rob

Edgar J. De Cleene

Re: [squeak-dev] Re: Hit end of changes file limit

El 6/2/08 7:25 PM, "Rob Rothwell" <[hidden email]> escribió:

> Actually, I started with one of the squeak-dev images, which started out
> around 10Mb...I'm not sure what I've done after that given the seemingly small
> size of the project I am working on; I seem to be having some image size
> expansion at a pretty good rate too, which I think I will ask the beginners
> list about!
>
> Rob

Yes, I see your questions.
I still not have enough experience with Aida for help.
But taking risk, I think Aida save all in .image ,
You always could see .changes , not only from inside Squeak,
Also you could use external text editors like Ultraedit or BBEdit
I copy last lines of my own working image for example how to understand
.changes

STARTUP is the begin of work
"Discovery:Users:admin:SqueakDevelop:Squeak3.11" is the working dir
"Discovery:Users:admin:SqueakDevelop:Squeak3.11:Squeak3.10-7164WT-basic.imag
e" is the working image

Each 'From ....etc" means the image on which the code was made
Each '---End fileIn of' means the actual .st (or other)

Hope this helps.

> ----STARTUP----an Array(31 May 2008 10:12:34 am) as
> Discovery:Users:admin:SqueakDevelop:Squeak3.11:Squeak3.10-7164WT-basic.image!
>
>
> 'From FunSqueak3.10alpha of 19 November 2007 [latest update: #1] on 30 May
> 2008 at 9:45 am'!
> !MethodReference methodsFor: '*monticello' stamp: 'al 10/9/2005 20:05'!
> isLocalSelector
> ^self actualClass
> includesLocalSelector: self methodSymbol! !
>
> ----End fileIn of
> Discovery:Users:admin:SqueakRepository:imagesZip:Squeak3.9-final-7067:MethodRe
> ference-isLocalSelector.st----!
>
> 'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 31 May 2008 at
> 9:39:08 am'!
> !MethodReference methodsFor: 'queries' stamp: 'edc 5/31/2008 09:38'!
> systemPackage
> ^(Smalltalk at: self classSymbol) category ! !
>
> ----End fileIn of
> Discovery:Users:admin:SqueakRepository:imagesZip:Squeak3.9-final-7067:MethodRe
> ference-systemPackage.st----!
>
> 'From Squeak3.9 of 7 November 2006 [latest update: #7067] on 31 May 2008 at
> 9:44:15 am'!
> !PackageInfo methodsFor: 'dependencies' stamp: 'edc 5/31/2008 09:43'!
> externalPackages
> ^self externalUsers collect: [:mr | mr key systemPackage]
> ! !
>
> ----End fileIn of
> Discovery:Users:admin:SqueakRepository:imagesZip:Squeak3.9-final-7067:PackageI
> nfo-externalPackages.st----!
>
> 'From FunSqueak3.10alpha of 19 November 2007 [latest update: #1] on 30 May
> 2008 at 9:46:45 am'!
> !Behavior methodsFor: 'testing method dictionary' stamp: 'al 9/16/2005 14:16'!
> includesLocalSelector: aSymbol
> ^self basicLocalSelectors isNil
> ifTrue: [self includesSelector: aSymbol]
> ifFalse: [self localSelectors includes: aSymbol]! !
>
> ----End fileIn of
> Discovery:Users:admin:SqueakRepository:imagesZip:Squeak3.9-final-7067:Behavior
> -includesLocalSelector.st----!
>
> 'From FunSqueak3.10alpha of 19 November 2007 [latest update: #1] on 30 May
> 2008 at 9:47:31 am'!
> !Behavior methodsFor: 'accessing method dictionary' stamp: 'al 6/12/2006
> 10:48'!
> basicLocalSelectors
> "Direct accessor for the instance variable localSelectors.
> Because of hardcoded ivar indexes of Behavior and Class in the VM, Class
> and
> Metaclass declare the needed ivar and override this method as an accessor.
> By returning nil instead of declaring this method as a subclass
> responsibility,
> Behavior can be instantiated for creating anonymous classes."
>
> ^nil! !
>
> ----End fileIn of
> Discovery:Users:admin:SqueakRepository:imagesZip:Squeak3.9-final-7067:Behavior
> -basicLocalSelectors.st----!
>
> (PackageInfo named: 'Protocols') externalPackages!
>
> ----SNAPSHOT----an Array(31 May 2008 11:07:20 am)
> Squeak3.10-7164WT-basic.image priorSource: 8370532!