Smalltalk › Squeak › Squeak - Dev

Trunk image size

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

32 messages Options

Igor Stasenko

Trunk image size

Hi guys,

Squeak 3.10.2-7179-basic is 14M

while the latest trunk, after update&save is 26M
(after flushing MC cache, its 20M).

I just want to tell, that maybe its time to check, if image contains
junk (obsolete classes, junky state in caches and other hung, but not
useable stuff etc)
and clean it up.

I remember fighting with hanging references using chaser.. its not
trivial thing.. and i'm not expert in this, so i am asking if anyone
can check if image in healty state,
because as to me its size is a bit high.

--
Best regards,
Igor Stasenko AKA sig.

Bert Freudenberg

Re: Trunk image size

On 10.12.2009, at 17:25, Igor Stasenko wrote:

>
> Hi guys,
>
> Squeak 3.10.2-7179-basic is 14M
>
> while the latest trunk, after update&save is 26M
> (after flushing MC cache, its 20M).
>
> I just want to tell, that maybe its time to check, if image contains
> junk (obsolete classes, junky state in caches and other hung, but not
> useable stuff etc)
> and clean it up.
>
> I remember fighting with hanging references using chaser.. its not
> trivial thing.. and i'm not expert in this, so i am asking if anyone
> can check if image in healty state,
> because as to me its size is a bit high.

The new fonts will certainly take up quite a bit of space.

- Bert -

Juan Vuletich-4

Re: Trunk image size

Bert Freudenberg wrote:

> On 10.12.2009, at 17:25, Igor Stasenko wrote:
>
>> Hi guys,
>>
>> Squeak 3.10.2-7179-basic is 14M
>>
>> while the latest trunk, after update&save is 26M
>> (after flushing MC cache, its 20M).
>>
>> I just want to tell, that maybe its time to check, if image contains
>> junk (obsolete classes, junky state in caches and other hung, but not
>> useable stuff etc)
>> and clean it up.
>>
>> I remember fighting with hanging references using chaser.. its not
>> trivial thing.. and i'm not expert in this, so i am asking if anyone
>> can check if image in healty state,
>> because as to me its size is a bit high.
>>
>
> The new fonts will certainly take up quite a bit of space.
>
> - Bert -

The code for creating the new fonts (StrikeFont class category 'dejaVu
font data') uses 400kb. The fonts themselves use another 400kb. You can
check this by evaluating
StrikeFont allInstances do: [ :f | f setGlyphsDepthAtMost: 1 ]
and saving the image (perhaps with a different name!).

So, if you're looking for 6Mb, there must be something else...

Cheers,
Juan Vuletich

Levente Uzonyi-2

Re: Trunk image size

In reply to this post by Igor Stasenko

On Thu, 10 Dec 2009, Igor Stasenko wrote:

> Hi guys,
>
> Squeak 3.10.2-7179-basic is 14M
>

The latest available (at http://ftp.squeak.org/trunk) image's size is
18.1MB. My clean trunk image which is updated every day is 18.9MB large.
It's still less than 20MB. Also note that there are several scripts that
decrease the image size which are evaluated before a release image is
created. Try running these for example (there are a lot more and we should
clean up ReleaseBuilder too):

ReleaseBuilder >> #prepareReleaseImage
ScriptLoader >> #flushCaches
ReleaseBuilderFor3dot10 >> cleanUnwantedCs

After these my image's size is 13.6MB.

Levente

> while the latest trunk, after update&save is 26M
> (after flushing MC cache, its 20M).
>
> I just want to tell, that maybe its time to check, if image contains
> junk (obsolete classes, junky state in caches and other hung, but not
> useable stuff etc)
> and clean it up.
>
> I remember fighting with hanging references using chaser.. its not
> trivial thing.. and i'm not expert in this, so i am asking if anyone
> can check if image in healty state,
> because as to me its size is a bit high.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Igor Stasenko

Re: Trunk image size

2009/12/10 Levente Uzonyi <[hidden email]>:

> On Thu, 10 Dec 2009, Igor Stasenko wrote:
>
>> Hi guys,
>>
>> Squeak 3.10.2-7179-basic is 14M
>>
>
> The latest available (at http://ftp.squeak.org/trunk) image's size is
> 18.1MB. My clean trunk image which is updated every day is 18.9MB large.
> It's still less than 20MB. Also note that there are several scripts that
> decrease the image size which are evaluated before a release image is
> created. Try running these for example (there are a lot more and we should
> clean up ReleaseBuilder too):
>
> ReleaseBuilder >> #prepareReleaseImage
> ScriptLoader >> #flushCaches
> ReleaseBuilderFor3dot10 >> cleanUnwantedCs
>
> After these my image's size is 13.6MB.
>

That's much better! Thanks for pointers.

>
> Levente
>
>> while the latest trunk, after update&save is 26M
>> (after flushing MC cache, its 20M).
>>
>> I just want to tell, that maybe its time to check, if image contains
>> junk (obsolete classes, junky state in caches and other hung, but not
>> useable stuff etc)
>> and clean it up.
>>
>> I remember fighting with hanging references using chaser.. its not
>> trivial thing.. and i'm not expert in this, so i am asking if anyone
>> can check if image in healty state,
>> because as to me its size is a bit high.
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Edgar J. De Cleene

Re: Trunk image size

In reply to this post by Levente Uzonyi-2

On 12/10/09 3:14 PM, "Levente Uzonyi" <[hidden email]> wrote:

> The latest available (at http://ftp.squeak.org/trunk) image's size is
> 18.1MB. My clean trunk image which is updated every day is 18.9MB large.
> It's still less than 20MB. Also note that there are several scripts that
> decrease the image size which are evaluated before a release image is
> created. Try running these for example (there are a lot more and we should
> clean up ReleaseBuilder too):
>
> ReleaseBuilder >> #prepareReleaseImage
> ScriptLoader >> #flushCaches
> ReleaseBuilderFor3dot10 >> cleanUnwantedCs
>
> After these my image's size is 13.6MB.

File 'Squeak3.11.alpha.7671.image' is 17183164 bytes long.

How I get this.
1) Take Squeak3.10.gamma.7159 as starting point, put some I need , I have
one .cs produced for each thing loaded with logic of Andreas for Trunk

Like to see some realize we don't have the same Ralph and me build two
yearsago .
It's crazy each walkback start some like

MessageNotUnderstood: UndefinedObject>>scanFrom:
9 December 2009 9:56:07.517 am

VM: Mac OS - a SmalltalkImage
Image: Squeak3.10.2 [latest update: #7179]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir
/Users/edgar/SqueakRepository/imagesZip/Squeak3.10.2-Trunk-091024
Trusted Dir /foobar/tooBar/forSqueak/bogus
Untrusted Dir /Users/edgar/Library/Preferences/Squeak/Internet/My Squeak

UndefinedObject(Object)>>doesNotUnderstand: #scanFrom:
Receiver: nil
Arguments and temporary variables:
aMessage: scanFrom: MultiByteFileStream:
'/Users/edgar/Sites/LearnFromServer.4....etc...
exception: MessageNotUnderstood: UndefinedObject>>scanFrom:
resumeValue: nil
R

How you bet wich one of many possible Trunk image produce the walckback ?

By the way, I also have the full logs from update-ar.2.log to
update-nice.76.log, with the missings numbers 32,33,34 .

If you let me , could put all in the ftp squeak

Edgar

garduino

Re: Trunk image size

May be is not the right place on this thread, but I also feels that we should
have a number identifying the image.

I know that this was already commented and that it's possible to check
on Monticello, but anyway I think that each update of trunk should put
an ID to the image.....

Cheers.

2009/12/10 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 12/10/09 3:14 PM, "Levente Uzonyi" <[hidden email]> wrote:
>
>> The latest available (at http://ftp.squeak.org/trunk) image's size is
>> 18.1MB. My clean trunk image which is updated every day is 18.9MB large.
>> It's still less than 20MB. Also note that there are several scripts that
>> decrease the image size which are evaluated before a release image is
>> created. Try running these for example (there are a lot more and we should
>> clean up ReleaseBuilder too):
>>
>> ReleaseBuilder >> #prepareReleaseImage
>> ScriptLoader >> #flushCaches
>> ReleaseBuilderFor3dot10 >> cleanUnwantedCs
>>
>> After these my image's size is 13.6MB.
>
> File 'Squeak3.11.alpha.7671.image' is 17183164 bytes long.
>
> How I get this.
> 1) Take Squeak3.10.gamma.7159 as starting point, put some I need , I have
> one .cs produced for each thing loaded with logic of Andreas for Trunk
>
> Like to see some realize we don't have the same Ralph and me build two
> yearsago .
> It's crazy each walkback start some like
>
> MessageNotUnderstood: UndefinedObject>>scanFrom:
> 9 December 2009 9:56:07.517 am
>
> VM: Mac OS - a SmalltalkImage
> Image: Squeak3.10.2 [latest update: #7179]
>
> SecurityManager state:
> Restricted: false
> FileAccess: true
> SocketAccess: true
> Working Dir
> /Users/edgar/SqueakRepository/imagesZip/Squeak3.10.2-Trunk-091024
> Trusted Dir /foobar/tooBar/forSqueak/bogus
> Untrusted Dir /Users/edgar/Library/Preferences/Squeak/Internet/My Squeak
>
> UndefinedObject(Object)>>doesNotUnderstand: #scanFrom:
> Receiver: nil
> Arguments and temporary variables:
> aMessage: scanFrom: MultiByteFileStream:
> '/Users/edgar/Sites/LearnFromServer.4....etc...
> exception: MessageNotUnderstood: UndefinedObject>>scanFrom:
> resumeValue: nil
> R
>
> How you bet wich one of many possible Trunk image produce the walckback ?
>
> By the way, I also have the full logs from update-ar.2.log to
> update-nice.76.log, with the missings numbers 32,33,34 .
>
> If you let me , could put all in the ftp squeak
>
>
> Edgar
>
>
>
>
>

Andreas.Raab

Re: Trunk image size

Germán Arduino wrote:
> May be is not the right place on this thread, but I also feels that we should
> have a number identifying the image.

I don't recall anyone arguing against that. Unfortunately, I also don't
recall anyone making a real proposal.

> I know that this was already commented and that it's possible to check
> on Monticello, but anyway I think that each update of trunk should put
> an ID to the image.....

So how exactly are you proposing to do that? What should the ID define,
how does it get into the image?

Cheers,
- Andreas

Andreas.Raab

Re: Trunk image size

In reply to this post by Edgar J. De Cleene

Edgar J. De Cleene wrote:

> 1) Take Squeak3.10.gamma.7159 as starting point, put some I need , I have
> one .cs produced for each thing loaded with logic of Andreas for Trunk
>
> Like to see some realize we don't have the same Ralph and me build two
> yearsago . It's crazy each walkback start some like
>
> MessageNotUnderstood: UndefinedObject>>scanFrom:
> 9 December 2009 9:56:07.517 am
>
> VM: Mac OS - a SmalltalkImage
> Image: Squeak3.10.2 [latest update: #7179]
>
> SecurityManager state:
> Restricted: false
> FileAccess: true
> SocketAccess: true
> Working Dir
> /Users/edgar/SqueakRepository/imagesZip/Squeak3.10.2-Trunk-091024
> Trusted Dir /foobar/tooBar/forSqueak/bogus
> Untrusted Dir /Users/edgar/Library/Preferences/Squeak/Internet/My Squeak
>
> UndefinedObject(Object)>>doesNotUnderstand: #scanFrom:
> Receiver: nil
> Arguments and temporary variables:
> aMessage: scanFrom: MultiByteFileStream:
> '/Users/edgar/Sites/LearnFromServer.4....etc...
> exception: MessageNotUnderstood: UndefinedObject>>scanFrom:
> resumeValue: nil
> R
>
> How you bet wich one of many possible Trunk image produce the walckback ?

Can you send a full stack dump?

> If you let me , could put all in the ftp squeak

I do not understand what you mean.

Cheers,
- Andreas

Edgar J. De Cleene

Re: Re: Trunk image size

On 12/11/09 4:19 AM, "Andreas Raab" <[hidden email]> wrote:

> Can you send a full stack dump?
It's only a example, not a real crash.

My point is this.
The update number is not only a commodity.
If we have ...
> Image: Squeak3.10.2 [latest update: #7179]
Its unclear the point in the process the image is
But if we got
> Image: Squeak3.10.2 [latest update: #7234]

Or
> Image: Squeak3.10.2 [latest update: #7374]
W
e could fine tune which could be

>> If you let me , could put all in the ftp squeak
>
> I do not understand what you mean.
>
> Cheers,
> - Andreas
>

I have all the.cs and all the .logs.
Very sure this could be of interes to some Squeaker.
I have access to my own directories in fpt squeak, could put there or in
another convenient place.

Last point of argue
When finish 3.10.2 ? What have us chained to such number?

Edgar

Igor Stasenko

Re: Re: Trunk image size

2009/12/11 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 12/11/09 4:19 AM, "Andreas Raab" <[hidden email]> wrote:
>
>> Can you send a full stack dump?
> It's only a example, not a real crash.
>
> My point is this.
> The update number is not only a commodity.
> If we have ...
>> Image: Squeak3.10.2 [latest update: #7179]
> Its unclear the point in the process the image is
> But if we got
>> Image: Squeak3.10.2 [latest update: #7234]
>
> Or
>> Image: Squeak3.10.2 [latest update: #7374]
> W
> e could fine tune which could be
>
>>> If you let me , could put all in the ftp squeak
>>
>> I do not understand what you mean.
>>
>> Cheers,
>> - Andreas
>>
>
> I have all the.cs and all the .logs.
> Very sure this could be of interes to some Squeaker.
> I have access to my own directories in fpt squeak, could put there or in
> another convenient place.
>

Logs is useful , and .cs also, for those who wants to cherry-pick some
of the changes
adopted in trunk.
So, +1 here.

> Last point of argue
> When finish 3.10.2 ? What have us chained to such number?
>
> Edgar
>
>
>
>
>

--
Best regards,
Igor Stasenko AKA sig.

Andreas.Raab

Image Versions (Re: Trunk image size)

In reply to this post by Edgar J. De Cleene

Edgar J. De Cleene wrote:
> My point is this.
> The update number is not only a commodity.
> If we have ...
>> Image: Squeak3.10.2 [latest update: #7179]
> Its unclear the point in the process the image is
> But if we got
>> Image: Squeak3.10.2 [latest update: #7234]

I see. And I agree. But I'll have to repeat what I said earlier: We need
a workable solution to the problem. If anyone has an idea what we can do
please propose it.

> When finish 3.10.2 ? What have us chained to such number?

Nothing. Really just that we'd have to decide whether the next version
is going to be called 3.11 or 4.1 (i.e., 4.0 MIT/SFC + trunk). From my
perspective the "trunk" nomenclature relates to work in progress; it can
either be based on the last or the next version and does't make much
difference.

If people feel we should move forward we can do this at any time. So
shall we just call the current trunk 3.11 alpha? (and if we get to 4.0,
i.e., complete the SFC process, we can simply abandon 3.11 and instead
go straight to 4.1)

Does that sound like a plan?

Cheers,
- Andreas

Edgar J. De Cleene

Re: Image Versions (Re: Trunk image size)

I sent what I have.
Sure some could polish this and have some better.
But please, don't let non Squeakers excuses for they say

"You was in the same spot as two years ago"

If agree with this , or better do yours own versions, the rest is produced
automatic and go to 'updates" folder of local dir.
And all updates could be transfer to ftp , for all "old guys who was more
confortable with .cs" have a happy day.

Edgar

7167PragmaPreference.1.cs (2K) Download Attachment

7171MCConfiguration class-logToFile.1.cs (3K) Download Attachment

7178PasteUpMorph-reportPublicIP.cs (1K) Download Attachment

7180PackageInfo-hasPreamble.cs (330 bytes) Download Attachment

7179Utilites-CommonStringsRequest.1.cs (1K) Download Attachment

7173ChangeSet-fileOut.1.cs (2K) Download Attachment

7168Object-doesNotUnderstand.1.cs (1K) Download Attachment

7170ChangeSystemVersioncurrenthighestUpdate.2.cs (5K) Download Attachment

7176MCMcmUpdater.st (3K) Download Attachment

7175FileList2 class lastSelDir.1.cs (3K) Download Attachment

7177FileList2 class lastSelDir.1.cs (3K) Download Attachment

7174EdEnhancemenst.1.cs (27K) Download Attachment

7160AdvanceToThreeDotElevenAlpha.1.cs (1K) Download Attachment

7169Preferences class-doesNotUnderstand.1.cs (494 bytes) Download Attachment

7161ReleaseBuilderFor3dot11.cs (20K) Download Attachment

7181MCDiffyVersionFixes.1.cs (416 bytes) Download Attachment

7172ByteString-asJoliet.st (370 bytes) Download Attachment

7163MCConfigurationPrevious.4.cs (1K) Download Attachment

7162ReleaseBuilderFor3dot10flushCaches.1.cs (564 bytes) Download Attachment

7166MCMcmUpdater.st (3K) Download Attachment

7164InstallMonticelloConfigurations.1.cs (458 bytes) Download Attachment

garduino

Re: Re: Trunk image size

In reply to this post by Andreas.Raab

Hi:

2009/12/11 Andreas Raab <[hidden email]>:
>> I know that this was already commented and that it's possible to check
>> on Monticello, but anyway I think that each update of trunk should put
>> an ID to the image.....
>
> So how exactly are you proposing to do that? What should the ID define, how
> does it get into the image?
>

I remember a talk about this some time ago.

On my point of view, only a number identifying the latest update
applied to the image,
to distinguish it. Some sort of number as we have now with Squeak
3.10.2 latest update: #7179.

I think that is useful to know the level of the image, being that we
are having lot of changes in these days.

Cheers.

garduino

Re: Image Versions (Re: Trunk image size)

In reply to this post by Andreas.Raab

Sorry I responded the other thread before to read this.....

2009/12/11 Andreas Raab <[hidden email]>:

> Edgar J. De Cleene wrote:
>>
>> My point is this.
>> The update number is not only a commodity.
>> If we have ...
>>>
>>> Image: Squeak3.10.2 [latest update: #7179]
>>
>> Its unclear the point in the process the image is
>> But if we got
>>>
>>> Image: Squeak3.10.2 [latest update: #7234]
>
> I see. And I agree. But I'll have to repeat what I said earlier: We need a
> workable solution to the problem. If anyone has an idea what we can do
> please propose it.

Shouldn't be that each commit loaded can add 1 to the latest update number?

Or may be is so difficult to maintain this relationship (commit --
latest update number)?

>
>> When finish 3.10.2 ? What have us chained to such number?
>
> Nothing. Really just that we'd have to decide whether the next version is
> going to be called 3.11 or 4.1 (i.e., 4.0 MIT/SFC + trunk). From my
> perspective the "trunk" nomenclature relates to work in progress;

Yes, I agree with this definition that trunk is "work in progress".

> it can
> either be based on the last or the next version and does't make much
> difference.
>
> If people feel we should move forward we can do this at any time. So shall
> we just call the current trunk 3.11 alpha?

Sound ok to me.

> (and if we get to 4.0, i.e.,
> complete the SFC process, we can simply abandon 3.11 and instead go straight
> to 4.1)
>
> Does that sound like a plan?
>

Yes, 4.0/4.1 should include SFC process completed.

Cheers.
Germán.

Bert Freudenberg

Re: Image Versions (Re: Trunk image size)

In reply to this post by Andreas.Raab

On 11.12.2009, at 10:14, Andreas Raab wrote:

>
> Edgar J. De Cleene wrote:
>> My point is this.
>> The update number is not only a commodity.
>> If we have ...
>>> Image: Squeak3.10.2 [latest update: #7179]
>> Its unclear the point in the process the image is
>> But if we got
>>> Image: Squeak3.10.2 [latest update: #7234]
>
> I see. And I agree. But I'll have to repeat what I said earlier: We need a workable solution to the problem. If anyone has an idea what we can do please propose it.

My proposal is in the inbox (update trunk first).

Name: System-bf.193
Author: bf
Time: 11 December 2009, 12:38:45.256 pm
UUID: 4609ebf3-3481-4f3a-99d6-1c4e9534d2fa
Ancestors: System-nice.192

- after updating, set the current system version to the latest date found in all system packages. Also set the highest update number to the sum of version numbers.

>> When finish 3.10.2 ? What have us chained to such number?
>
> Nothing. Really just that we'd have to decide whether the next version is going to be called 3.11 or 4.1 (i.e., 4.0 MIT/SFC + trunk). From my perspective the "trunk" nomenclature relates to work in progress; it can either be based on the last or the next version and does't make much difference.
>
> If people feel we should move forward we can do this at any time. So shall we just call the current trunk 3.11 alpha? (and if we get to 4.0, i.e., complete the SFC process, we can simply abandon 3.11 and instead go straight to 4.1)
>
> Does that sound like a plan?
>
> Cheers,
> - Andreas

+1

- Bert -

Edgar J. De Cleene

Re: Image Versions (Re: Trunk image size)

On 12/11/09 9:42 AM, "Bert Freudenberg" <[hidden email]> wrote:

> My proposal is in the inbox (update trunk first).
>
> Name: System-bf.193
> Author: bf
> Time: 11 December 2009, 12:38:45.256 pm
> UUID: 4609ebf3-3481-4f3a-99d6-1c4e9534d2fa
> Ancestors: System-nice.192
>
> - after updating, set the current system version to the latest date found in
> all system packages. Also set the highest update number to the sum of version
> numbers.

Trying to reproduce this, I have a trouble and should complete by hand.
As I doing for my image and have latest update: #3770
But we start from 7159 so my proposal is 7159 + 3770 10929

Wow, is still > my Squeak3.11.alpha.7652.image. Not clear , I should check
why

And we should have one .cs for each commit

Edgar

garduino

Re: Image Versions (Re: Trunk image size)

2009/12/11 Edgar J. De Cleene <[hidden email]>:

>
>
>
> On 12/11/09 9:42 AM, "Bert Freudenberg" <[hidden email]> wrote:
>
>> My proposal is in the inbox (update trunk first).
>>
>> Name: System-bf.193
>> Author: bf
>> Time: 11 December 2009, 12:38:45.256 pm
>> UUID: 4609ebf3-3481-4f3a-99d6-1c4e9534d2fa
>> Ancestors: System-nice.192
>>
>> - after updating, set the current system version to the latest date found in
>> all system packages. Also set the highest update number to the sum of version
>> numbers.
> Trying to reproduce this, I have a trouble and should complete by hand.
> As I doing for my image and have latest update: #3770

Same here.

K. K. Subramaniam

Re: Image Versions (Re: Trunk image size)

In reply to this post by Andreas.Raab

On Friday 11 December 2009 02:44:10 pm Andreas Raab wrote:
> Nothing. Really just that we'd have to decide whether the next version
> is going to be called 3.11 or 4.1 (i.e., 4.0 MIT/SFC + trunk). From my
> perspective the "trunk" nomenclature relates to work in progress; it can
> either be based on the last or the next version and does't make much
> difference.
Why not use odd minor numbers for trunk versions (e.g. 3.11) and branch out
stable versions to even (e.g. 3.12 or 4.2) minor number and then bump the
trunk to next odd number (e.g. 3.13 or 4.3).

Subbu

Bert Freudenberg

Re: Image Versions (Re: Trunk image size)

In reply to this post by Edgar J. De Cleene

On 11.12.2009, at 12:53, Edgar J. De Cleene wrote:

>
>
>
>
> On 12/11/09 9:42 AM, "Bert Freudenberg" <[hidden email]> wrote:
>
>> My proposal is in the inbox (update trunk first).
>>
>> Name: System-bf.193
>> Author: bf
>> Time: 11 December 2009, 12:38:45.256 pm
>> UUID: 4609ebf3-3481-4f3a-99d6-1c4e9534d2fa
>> Ancestors: System-nice.192
>>
>> - after updating, set the current system version to the latest date found in
>> all system packages. Also set the highest update number to the sum of version
>> numbers.
> Trying to reproduce this, I have a trouble and should complete by hand.
> As I doing for my image and have latest update: #3770
> But we start from 7159 so my proposal is 7159 + 3770 10929

The sum of version numbers in the very first Trunk config map (update.ar-1) was 2518.

3.10.2 had as highest update 7179.

So it would make sense to use 7179 - 2518 + 1 as a base.

New update number would be sum of packet version numbers plus 4662.

I updated my package in the inbox.

- Bert -