Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
You can also use the cluster layout:
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
You can also use the cluster layout:
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Oh… sorry. Was not my intention
Alexandre
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout:
<Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout:
<Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
You likely have a very extensive folder structure underneath. The script collects all files from all nested folders and that can be slow and you image will be blocked in the meantime.
Cheers, Doru
On Wed, Jul 29, 2015 at 9:33 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel < alexandre.bergel@me.com> wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout:
<Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders.
On Wed, Jul 29, 2015 at 10:50 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
You likely have a very extensive folder structure underneath. The script collects all files from all nested folders and that can be slow and you image will be blocked in the meantime.
Cheers, Doru
On Wed, Jul 29, 2015 at 9:33 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel alexandre.bergel@me.com wrote:
Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel < alexandre.bergel@me.com> wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel < alexandre.bergel@me.com> wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout:
<Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel alexandre.bergel@me.com wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel alexandre.bergel@me.com wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel alexandre.bergel@me.com wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground:
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com
wrote:
well i can send you the image tommorow because its huge (200 MB ziped)
for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with
pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new
configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Are you using windows? I know it may has problems regarding the source
code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com
wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b
but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis kilon.alios@gmail.com
wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a
playground:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color
red.
b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a
file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com
wrote:
well i can send you the image tommorow because its huge (200 MB ziped)
for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with
pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new
configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Are you using windows? I know it may has problems regarding the source
code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis kilon.alios@gmail.com
wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the
b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a
playground:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color
red.
b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on
a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com
wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com
wrote:
well i can send you the image tommorow because its huge (200 MB ziped)
for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with
pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new
configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Are you using windows? I know it may has problems regarding the source
code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the
b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Hi!
Just to share a couple of experiment. I have tried the following in
a playground:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color red.
b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on
a file may show you the content and other things.
<Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com
wrote:
well i can send you the image tommorow because its huge (200 MB
ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with
pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new
configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Are you using windows? I know it may has problems regarding the
source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect
the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
> > that was a nice way to freeze my image, thank you :D > > On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> Hi! > > Just to share a couple of experiment. I have tried the following in
a playground:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > b := RTMondrian new. > > b shape rectangle > if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color red.
> b nodes: FileLocator documents allChildren. > b edges connectFrom: #parent. > b normalizer > normalizeSize: #size using: #sqrt. > b layout tree. > b > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > It shows a tree of the file system. Thanks to GT, simply clicking
on a file may show you the content and other things.
> <Screen Shot 2015-07-29 at 10.23.51 AM.png> > > You can also use the cluster layout: > <Screen Shot 2015-07-29 at 10.25.11 AM.png> > > I have tried this on OS X, since the pointed folder is ~/Documents. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák i.uhnak@gmail.com wrote:
Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com
wrote:
Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com
wrote:
well i can send you the image tommorow because its huge (200 MB
ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with
pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new
configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
Are you using windows? I know it may has problems regarding the
source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
> > thats ok it unfroze after 20 minutes or so . I managed to inspect
the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
> > On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
> Oh… sorry. Was not my intention > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com> wrote:
>> >> that was a nice way to freeze my image, thank you :D >> >> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <
alexandre.bergel@me.com> wrote:
>> Hi! >> >> Just to share a couple of experiment. I have tried the following
in a playground:
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> b := RTMondrian new. >> >> b shape rectangle >> if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color red.
>> b nodes: FileLocator documents allChildren. >> b edges connectFrom: #parent. >> b normalizer >> normalizeSize: #size using: #sqrt. >> b layout tree. >> b >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> It shows a tree of the file system. Thanks to GT, simply clicking
on a file may show you the content and other things.
>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >> You can also use the cluster layout: >> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >> I have tried this on OS X, since the pointed folder is ~/Documents. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I tried also in UBUNTU with a Pharo 5 image I downloaded the above example but it gives me an error:
Error: Could not find accessor for the variable named "aModuleName" in Nativeboost>>#loadModule:
NBFFICallout>>loaderForArgNamed: NBFFICallout>>loaderForArgNamed:indirectIndex: NBFFICallout>>argName:indirectIndex:type:ptrArity: NBFnSpecParser>>parseArgument NBFnSpecParser>>parseArguments NBFnSpecParser>>parseAnonFunction: NBFFICallout>>anonSpec: [ :arg3 | | tmp2 | tmp2 := arg3. tmp2 useEmitCall; callType: conv; sender: context; parseOptions: options; anonSpec: arg1; generate: arg2 ] in NBFFICalloutAPI>>function:emit: in Block: [ :arg3 | ... [ tmp5 := arg1 value: (self newForMethod: tmp1) ] in NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [ tmp5 := arg1 value: (self newForMethod: tmp1) ] BlockClosure>>on:do: NBRecursionDetect class>>in:during: NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode: NBFFICalloutAPI>>function:emit: NativeBoostLinux32(NativeBoost)>>loadModule: CairoLibraryLoader class>>loadCairoLibrary CairoLibraryLoader class>>getLibraryHandle AthensCairoSurface class>>nbLibraryNameOrHandle AthensCairoSurface class(Object)>>nbCall: AthensCairoSurface class>>primImage:width:height: AthensCairoSurface class>>extent:format: AthensCairoSurface class>>extent: TRCanvas>>initialize TRCanvas class(Behavior)>>new RTView>>initialize RTView class(Behavior)>>new RTMondrian(RTBuilder)>>createView RTMondrian>>createView RTMondrian(RTBuilder)>>initialize RTMondrian>>initialize
On Thu, Jul 30, 2015 at 11:51 AM Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák i.uhnak@gmail.com wrote:
Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
> On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com wrote: > > well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
> I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters. > > I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser). > > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: > Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible. > > Can I have a look at your image? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote: >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ? >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: >> Oh… sorry. Was not my intention >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis < kilon.alios@gmail.com> wrote: >>> >>> that was a nice way to freeze my image, thank you :D >>> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: >>> Hi! >>> >>> Just to share a couple of experiment. I have tried the following in a playground: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> b := RTMondrian new. >>> >>> b shape rectangle >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. >>> b nodes: FileLocator documents allChildren. >>> b edges connectFrom: #parent. >>> b normalizer >>> normalizeSize: #size using: #sqrt. >>> b layout tree. >>> b >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>> >>> You can also use the cluster layout: >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>> >>> I have tried this on OS X, since the pointed folder is ~/Documents. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Thu, Jul 30, 2015 at 10:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
I usually do it because time to save an image increases with image size (so instead of ~instant for 60MB it takes couple seconds for 600 MB)... since I have HDD.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
We already sort of have that: TestAsserter>>should: aBlock notTakeMoreThanMilliseconds: anInteger
Although I see a problem that each machine will have a different performance. So it would need to establish a baseline and then base the execution time on that. (e.g. execution shouldn't take more than 300% of a baseline).
Peter
Good point on both remarks. Obviously if the image size can be shrank down it is an advantage and most likely will boost performance as well making pharo experience snappier. That was my experience using Cuis ( http://www.jvuletich.org/Cuis/Index.html ) . About the benchmarks maybe use a common pharo command as a reference point (like Transcipt >> open) and then do the benchmark relative to that so the benchmark does not rely on absolute values that may differ from machine to machine.
On Thu, Jul 30, 2015 at 12:28 PM Peter Uhnák i.uhnak@gmail.com wrote:
On Thu, Jul 30, 2015 at 10:51 AM, Dimitris Chloupis <kilon.alios@gmail.com
wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
I usually do it because time to save an image increases with image size (so instead of ~instant for 60MB it takes couple seconds for 600 MB)... since I have HDD.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
We already sort of have that: TestAsserter>>should: aBlock notTakeMoreThanMilliseconds: anInteger
Although I see a problem that each machine will have a different performance. So it would need to establish a baseline and then base the execution time on that. (e.g. execution shouldn't take more than 300% of a baseline).
Peter _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
Is it possible to use a treemap layout?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
You should be able to specify all layouts available in roassal...
b layout tree. b layout cluster. b layout force. ...
Peter
-----Original Message----- From: "H. Hirzel" hannes.hirzel@gmail.com Sent: 7/30/2015 8:40 PM To: "Moose-related development" moose-dev@iam.unibe.ch; "pharo-users@lists.pharo.org" pharo-users@lists.pharo.org Subject: Re: [Pharo-users] [Moose-dev] Re: Script of the day
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
thanks, layout force is very nice.
But my question is about a tree map.
Like the one here https://en.wikipedia.org/wiki/File:Gradient_grouped_treemap.jpg
treemap is not known.
--Hannes
On 7/30/15, Peter Uhnak i.uhnak@gmail.com wrote:
You should be able to specify all layouts available in roassal...
b layout tree. b layout cluster. b layout force. ...
Peter
-----Original Message----- From: "H. Hirzel" hannes.hirzel@gmail.com Sent: 7/30/2015 8:40 PM To: "Moose-related development" moose-dev@iam.unibe.ch; "pharo-users@lists.pharo.org" pharo-users@lists.pharo.org Subject: Re: [Pharo-users] [Moose-dev] Re: Script of the day
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
[image: Inline image 1]
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the
obsession
to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
<
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must
perform
under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how
much
RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised
if
each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take
me
1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress
to
maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a
lot
of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84
items
are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect
the b
but its incredible slow to navigate and use . Even moving the
inspector
around is incredible slow. My Documents folder contains 84 items,
maybe
it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in
a
playground:
b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color
red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking
on a
file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
that was a nice way to freeze my image, thank you :D
On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. <Screen Shot 2015-07-29 at 10.23.51 AM.png>
You can also use the cluster layout: <Screen Shot 2015-07-29 at 10.25.11 AM.png>
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
1. A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
2. The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
3. Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation
for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <kilon.alios@gmail.com
wrote:
Frankly I dont mind big images or big data , neither I share the
obsession
to shrink things down to few mbs in a time that we are talking in TBs
.
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
<
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit
tests
that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must
perform
under a strict timetable specific tasks, this way CI may alert not
only
unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how
much
RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save =>
237
MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I
am
saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered
that
with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be
surprised if
each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned
folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will
take me
1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file
structures
to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB
ziped)
for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would
compress to
maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store
a lot
of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84
items
are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the
source
code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote:
thats ok it unfroze after 20 minutes or so . I managed to inspect
the b
but its incredible slow to navigate and use . Even moving the
inspector
around is incredible slow. My Documents folder contains 84 items,
maybe
it cant handle so well this amount of datea ?
On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Oh… sorry. Was not my intention
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
> mailto:kilon.alios@gmail.com> wrote: > > that was a nice way to freeze my image, thank you :D > > On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > Hi! > > Just to share a couple of experiment. I have tried the following
in a
> playground: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > b := RTMondrian new. > > b shape rectangle > if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color
> red. > b nodes: FileLocator documents allChildren. > b edges connectFrom: #parent. > b normalizer > normalizeSize: #size using: #sqrt. > b layout tree. > b > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > It shows a tree of the file system. Thanks to GT, simply clicking
on a
> file may show you the content and other things. > <Screen Shot 2015-07-29 at 10.23.51 AM.png> > > You can also use the cluster layout: > <Screen Shot 2015-07-29 at 10.25.11 AM.png> > > I have tried this on OS X, since the pointed folder is
~/Documents.
> > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Excellent! We will work on this!
Alexandre
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory * nesting:* #directories * leaves: *#files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of
nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the
size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This
should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation
for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <
kilon.alios@gmail.com>
wrote:
Frankly I dont mind big images or big data , neither I share the
obsession
to shrink things down to few mbs in a time that we are talking in
TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
<
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit
tests
that check for behaviour of the code to have also benchmark tests
that
will have to pass specific standards so that specific method must
perform
under a strict timetable specific tasks, this way CI may alert not
only
unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than
how much
RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save =>
237
MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and
I am
saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup
the
folder first. Plus is cache really necessary? I mean it's a cache. .image +
.changes
should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered
that
with this:
"ah ok then its normal. Yes the structure is extensive, its 13
folders
(the rest 71 are files some of them very big), I would not be
surprised if
each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned
folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will
take me
1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down
is
normal.
Afterall I am sure you can test it yourselves on complex file
structures
to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote:
well i can send you the image tommorow because its huge (200 MB
ziped)
for my pathetically slow internet connection at home. I will send
it
from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would
compress to
maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store
a lot
of data.
Maybe something else is wrong that would explain the slowness.
I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84
items
are folders that contain many sub folders. No idea if that matters.
I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser).
On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: Are you using windows? I know it may has problems regarding the
source
code. You have 84 items and the visualization is slow? How is this possible.
Can I have a look at your image?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
> mailto:kilon.alios@gmail.com> wrote: > > thats ok it unfroze after 20 minutes or so . I managed to inspect
the b
> but its incredible slow to navigate and use . Even moving the
inspector
> around is incredible slow. My Documents folder contains 84 items,
maybe
> it cant handle so well this amount of datea ? > > On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > Oh… sorry. Was not my intention > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> >> that was a nice way to freeze my image, thank you :D >> >> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> Hi! >> >> Just to share a couple of experiment. I have tried the following
in a
>> playground: >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> b := RTMondrian new. >> >> b shape rectangle >> if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color
>> red. >> b nodes: FileLocator documents allChildren. >> b edges connectFrom: #parent. >> b normalizer >> normalizeSize: #size using: #sqrt. >> b layout tree. >> b >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> It shows a tree of the file system. Thanks to GT, simply
clicking on a
>> file may show you the content and other things. >> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >> You can also use the cluster layout: >> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >> I have tried this on OS X, since the pointed folder is
~/Documents.
>> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b
* color: Color transparent;* * borderColor: Color black;* * leafColor: [ :f | color scale: f size sqrt ];* leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote:
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory
- nesting:* #directories
- leaves: *#files.
b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of
nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the
size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This
should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation
for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <
kilon.alios@gmail.com>
wrote:
Frankly I dont mind big images or big data , neither I share the
obsession
to shrink things down to few mbs in a time that we are talking in
TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
<
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit
tests
that check for behaviour of the code to have also benchmark tests
that
will have to pass specific standards so that specific method must
perform
under a strict timetable specific tasks, this way CI may alert not
only
unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than
how much
RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long
time
without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save =>
237
MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19
windows
opened inside most of them with opened roassal visualization... and
I am
saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup
the
folder first. Plus is cache really necessary? I mean it's a cache. .image +
.changes
should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered
that
with this:
"ah ok then its normal. Yes the structure is extensive, its 13
folders
(the rest 71 are files some of them very big), I would not be
surprised if
each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned
folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will
take me
1-2 hours to upload on this connection. So if you guys still need
the
image i can upload tommorow from work, though it seems my slow down
is
normal.
Afterall I am sure you can test it yourselves on complex file
structures
to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <
sven@stfx.eu
mailto:sven@stfx.eu> wrote:
> On 29 Jul 2015, at 21:33, Dimitris Chloupis <
kilon.alios@gmail.com
> mailto:kilon.alios@gmail.com> wrote: > > well i can send you the image tommorow because its huge (200 MB
ziped)
> for my pathetically slow internet connection at home. I will send
it
> from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would
compress to
maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to
store a lot
of data.
Maybe something else is wrong that would explain the slowness.
> I can tell you that I am on MacOS Yosemite , I get my image with > pharolauncher, the image was dowloaded at 27-07-15 some of the 84
items
> are folders that contain many sub folders. No idea if that
matters.
> > I got Roassal 2 using the Package Browser in Pharo 5 (the new > configuration browser). > > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > Are you using windows? I know it may has problems regarding the
source
> code. You have 84 items and the visualization is slow? How is this > possible. > > Can I have a look at your image? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> >> thats ok it unfroze after 20 minutes or so . I managed to
inspect the b
>> but its incredible slow to navigate and use . Even moving the
inspector
>> around is incredible slow. My Documents folder contains 84
items, maybe
>> it cant handle so well this amount of datea ? >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> Oh… sorry. Was not my intention >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
>>> mailto:kilon.alios@gmail.com> wrote: >>> >>> that was a nice way to freeze my image, thank you :D >>> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>>> Hi! >>> >>> Just to share a couple of experiment. I have tried the
following in a
>>> playground: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> b := RTMondrian new. >>> >>> b shape rectangle >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color:
Color
>>> red. >>> b nodes: FileLocator documents allChildren. >>> b edges connectFrom: #parent. >>> b normalizer >>> normalizeSize: #size using: #sqrt. >>> b layout tree. >>> b >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> It shows a tree of the file system. Thanks to GT, simply
clicking on a
>>> file may show you the content and other things. >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>> >>> You can also use the cluster layout: >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>> >>> I have tried this on OS X, since the pointed folder is
~/Documents.
>>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote: Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this:
b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ].
This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: > I gave a try, and I did not find anything weird. > I guess your document folder contains many files, as Doru said > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com >> wrote: >> >> Frankly I dont mind big images or big data , neither I share the obsession >> to shrink things down to few mbs in a time that we are talking in TBs . >> >> Anyway you asked for the image and this is a link to it >> >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >> >> I dont think you will find anything abnormal about it though. >> >> I was wondering whether it would worth the effort beyond the unit tests >> that check for behaviour of the code to have also benchmark tests that >> will have to pass specific standards so that specific method must perform >> under a strict timetable specific tasks, this way CI may alert not only >> unit tests that fail but also benchmarks that fail , automagically. >> >> Maybe some food for thought. >> >> Personally I am far more worried how much CPU Pharo consumes than how much >> RAM. >> >> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com >> mailto:i.uhnak@gmail.com> wrote: >> Not sure if there is any downside (I've been using it for a long time >> without problems), but image cleanup often does wonders for me. >> >> Moose image >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 >> MB >> and I even had situations where it went from ~600 MB to ~60 MB. >> (As to why my images are so massive... right now there are 19 windows >> opened inside most of them with opened roassal visualization... and I am >> saving like every five minutes... but that is just a guess.) >> >> But image cleanup is supposed to break things, so better to backup the >> folder first. >> Plus is cache really necessary? I mean it's a cache. .image + .changes >> should usually suffice. >> >> Peter >> >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> Tudor I dont know if you received my message but I already answered that >> with this: >> >> "ah ok then its normal. Yes the structure is extensive, its 13 folders >> (the rest 71 are files some of them very big), I would not be surprised if >> each contains 100 files in its own subfolders." >> >> >> >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com >> mailto:tudor@tudorgirba.com> wrote: >> Hi, >> >> But, do you confirm that you have many files under the mentioned folder? >> >> Cheers, >> Doru >> >> >> >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> the image is 180 mb, changes are another 15, there are several other >> folders that raise the total size to 250 mb, monticello-cache and >> github-cache prodominately. >> >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me >> 1-2 hours to upload on this connection. So if you guys still need the >> image i can upload tommorow from work, though it seems my slow down is >> normal. >> >> Afterall I am sure you can test it yourselves on complex file structures >> to see if it has delays as long as 20 minutes. >> >> >> >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu >> mailto:sven@stfx.eu> wrote: >> >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com >> > mailto:kilon.alios@gmail.com> wrote: >> > >> > well i can send you the image tommorow because its huge (200 MB ziped) >> > for my pathetically slow internet connection at home. I will send it >> > from work which is 8 times faster. >> >> If the image is 200 MB zipped, how large is it in its normal state ? >> >> For me, a 100 MB image file is already quite large, that would compress to >> maybe 20/30 MB. >> >> This doesn't sound right to me, unless you explicitly tried to store a lot >> of data. >> >> Maybe something else is wrong that would explain the slowness. >> >> > I can tell you that I am on MacOS Yosemite , I get my image with >> > pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items >> > are folders that contain many sub folders. No idea if that matters. >> > >> > I got Roassal 2 using the Package Browser in Pharo 5 (the new >> > configuration browser). >> > >> > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >> > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >> > Are you using windows? I know it may has problems regarding the source >> > code. You have 84 items and the visualization is slow? How is this >> > possible. >> > >> > Can I have a look at your image? >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com >> >> mailto:kilon.alios@gmail.com> wrote: >> >> >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >> >> but its incredible slow to navigate and use . Even moving the inspector >> >> around is incredible slow. My Documents folder contains 84 items, maybe >> >> it cant handle so well this amount of datea ? >> >> >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >> >> Oh… sorry. Was not my intention >> >> >> >> Alexandre >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com >> >>> mailto:kilon.alios@gmail.com> wrote: >> >>> >> >>> that was a nice way to freeze my image, thank you :D >> >>> >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >> >>> Hi! >> >>> >> >>> Just to share a couple of experiment. I have tried the following in a >> >>> playground: >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> b := RTMondrian new. >> >>> >> >>> b shape rectangle >> >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >> >>> red. >> >>> b nodes: FileLocator documents allChildren. >> >>> b edges connectFrom: #parent. >> >>> b normalizer >> >>> normalizeSize: #size using: #sqrt. >> >>> b layout tree. >> >>> b >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> >> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a >> >>> file may show you the content and other things. >> >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >>> >> >>> You can also use the cluster layout: >> >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >>> >> >>> I have tried this on OS X, since the pointed folder is ~/Documents. >> >>> >> >>> Cheers, >> >>> Alexandre >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com http://www.tudorgirba.com/ >> >> "Every thing has its own flow" >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
[image: Imágenes integradas 1]
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b
- color: Color transparent;*
- borderColor: Color black;*
- leafColor: [ :f | color scale: f size sqrt ];*
leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote:
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory
- nesting:* #directories
- leaves: *#files.
b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of
nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want
the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This
should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Of course, it is. In fact, a treemap is a better suited
representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <
kilon.alios@gmail.com>
> wrote: > > Frankly I dont mind big images or big data , neither I share the
obsession
> to shrink things down to few mbs in a time that we are talking in
TBs .
> > Anyway you asked for the image and this is a link to it > >
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
> <
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
> > I dont think you will find anything abnormal about it though. > > I was wondering whether it would worth the effort beyond the unit
tests
> that check for behaviour of the code to have also benchmark tests
that
> will have to pass specific standards so that specific method must
perform
> under a strict timetable specific tasks, this way CI may alert not
only
> unit tests that fail but also benchmarks that fail , automagically. > > Maybe some food for thought. > > Personally I am far more worried how much CPU Pharo consumes than
how much
> RAM. > > On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com > mailto:i.uhnak@gmail.com> wrote: > Not sure if there is any downside (I've been using it for a long
time
> without problems), but image cleanup often does wonders for me. > > Moose image > 410 MB => cleanup (World -> System -> Do Image Cleanup) => save
=> 237
> MB > and I even had situations where it went from ~600 MB to ~60 MB. > (As to why my images are so massive... right now there are 19
windows
> opened inside most of them with opened roassal visualization...
and I am
> saving like every five minutes... but that is just a guess.) > > But image cleanup is supposed to break things, so better to backup
the
> folder first. > Plus is cache really necessary? I mean it's a cache. .image +
.changes
> should usually suffice. > > Peter > > On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
> mailto:kilon.alios@gmail.com> wrote: > Tudor I dont know if you received my message but I already
answered that
> with this: > > "ah ok then its normal. Yes the structure is extensive, its 13
folders
> (the rest 71 are files some of them very big), I would not be
surprised if
> each contains 100 files in its own subfolders." > > > > On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com > mailto:tudor@tudorgirba.com> wrote: > Hi, > > But, do you confirm that you have many files under the mentioned
folder?
> > Cheers, > Doru > > > > On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
> mailto:kilon.alios@gmail.com> wrote: > the image is 180 mb, changes are another 15, there are several
other
> folders that raise the total size to 250 mb, monticello-cache and > github-cache prodominately. > > Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will
take me
> 1-2 hours to upload on this connection. So if you guys still need
the
> image i can upload tommorow from work, though it seems my slow
down is
> normal. > > Afterall I am sure you can test it yourselves on complex file
structures
> to see if it has delays as long as 20 minutes. > > > > On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <
sven@stfx.eu
> mailto:sven@stfx.eu> wrote: > > > On 29 Jul 2015, at 21:33, Dimitris Chloupis <
kilon.alios@gmail.com
> > mailto:kilon.alios@gmail.com> wrote: > > > > well i can send you the image tommorow because its huge (200 MB
ziped)
> > for my pathetically slow internet connection at home. I will
send it
> > from work which is 8 times faster. > > If the image is 200 MB zipped, how large is it in its normal state
?
> > For me, a 100 MB image file is already quite large, that would
compress to
> maybe 20/30 MB. > > This doesn't sound right to me, unless you explicitly tried to
store a lot
> of data. > > Maybe something else is wrong that would explain the slowness. > > > I can tell you that I am on MacOS Yosemite , I get my image with > > pharolauncher, the image was dowloaded at 27-07-15 some of the
84 items
> > are folders that contain many sub folders. No idea if that
matters.
> > > > I got Roassal 2 using the Package Browser in Pharo 5 (the new > > configuration browser). > > > > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel > > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
> > Are you using windows? I know it may has problems regarding the
source
> > code. You have 84 items and the visualization is slow? How is
this
> > possible. > > > > Can I have a look at your image? > > > > Cheers, > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
> >> mailto:kilon.alios@gmail.com> wrote: > >> > >> thats ok it unfroze after 20 minutes or so . I managed to
inspect the b
> >> but its incredible slow to navigate and use . Even moving the
inspector
> >> around is incredible slow. My Documents folder contains 84
items, maybe
> >> it cant handle so well this amount of datea ? > >> > >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel > >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
> >> Oh… sorry. Was not my intention > >> > >> Alexandre > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
> >>> mailto:kilon.alios@gmail.com> wrote: > >>> > >>> that was a nice way to freeze my image, thank you :D > >>> > >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel > >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
> >>> Hi! > >>> > >>> Just to share a couple of experiment. I have tried the
following in a
> >>> playground: > >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>> b := RTMondrian new. > >>> > >>> b shape rectangle > >>> if: [ :aFile | aFile path basename beginsWith: '.' ]
color: Color
> >>> red. > >>> b nodes: FileLocator documents allChildren. > >>> b edges connectFrom: #parent. > >>> b normalizer > >>> normalizeSize: #size using: #sqrt. > >>> b layout tree. > >>> b > >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>> > >>> It shows a tree of the file system. Thanks to GT, simply
clicking on a
> >>> file may show you the content and other things. > >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> > >>> > >>> You can also use the cluster layout: > >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> > >>> > >>> I have tried this on OS X, since the pointed folder is
~/Documents.
> >>> > >>> Cheers, > >>> Alexandre > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.com http://www.tudorgirba.com/ > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote:
Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
[image: Imágenes integradas 1]
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b
- color: Color transparent;*
- borderColor: Color black;*
- leafColor: [ :f | color scale: f size sqrt ];*
leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote:
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory
- nesting:* #directories
- leaves: *#files.
b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of
nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want
the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This
should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Of course, it is. In fact, a treemap is a better suited
representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: > I gave a try, and I did not find anything weird. > I guess your document folder contains many files, as Doru said > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <
kilon.alios@gmail.com>
>> wrote: >> >> Frankly I dont mind big images or big data , neither I share the
obsession
>> to shrink things down to few mbs in a time that we are talking in
TBs .
>> >> Anyway you asked for the image and this is a link to it >> >>
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
>> <
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
>> >> I dont think you will find anything abnormal about it though. >> >> I was wondering whether it would worth the effort beyond the unit
tests
>> that check for behaviour of the code to have also benchmark tests
that
>> will have to pass specific standards so that specific method must
perform
>> under a strict timetable specific tasks, this way CI may alert
not only
>> unit tests that fail but also benchmarks that fail ,
automagically.
>> >> Maybe some food for thought. >> >> Personally I am far more worried how much CPU Pharo consumes than
how much
>> RAM. >> >> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com >> mailto:i.uhnak@gmail.com> wrote: >> Not sure if there is any downside (I've been using it for a long
time
>> without problems), but image cleanup often does wonders for me. >> >> Moose image >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save
=> 237
>> MB >> and I even had situations where it went from ~600 MB to ~60 MB. >> (As to why my images are so massive... right now there are 19
windows
>> opened inside most of them with opened roassal visualization...
and I am
>> saving like every five minutes... but that is just a guess.) >> >> But image cleanup is supposed to break things, so better to
backup the
>> folder first. >> Plus is cache really necessary? I mean it's a cache. .image +
.changes
>> should usually suffice. >> >> Peter >> >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> Tudor I dont know if you received my message but I already
answered that
>> with this: >> >> "ah ok then its normal. Yes the structure is extensive, its 13
folders
>> (the rest 71 are files some of them very big), I would not be
surprised if
>> each contains 100 files in its own subfolders." >> >> >> >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <
tudor@tudorgirba.com
>> mailto:tudor@tudorgirba.com> wrote: >> Hi, >> >> But, do you confirm that you have many files under the mentioned
folder?
>> >> Cheers, >> Doru >> >> >> >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> the image is 180 mb, changes are another 15, there are several
other
>> folders that raise the total size to 250 mb, monticello-cache and >> github-cache prodominately. >> >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still
will take me
>> 1-2 hours to upload on this connection. So if you guys still need
the
>> image i can upload tommorow from work, though it seems my slow
down is
>> normal. >> >> Afterall I am sure you can test it yourselves on complex file
structures
>> to see if it has delays as long as 20 minutes. >> >> >> >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <
sven@stfx.eu
>> mailto:sven@stfx.eu> wrote: >> >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis <
kilon.alios@gmail.com
>> > mailto:kilon.alios@gmail.com> wrote: >> > >> > well i can send you the image tommorow because its huge (200 MB
ziped)
>> > for my pathetically slow internet connection at home. I will
send it
>> > from work which is 8 times faster. >> >> If the image is 200 MB zipped, how large is it in its normal
state ?
>> >> For me, a 100 MB image file is already quite large, that would
compress to
>> maybe 20/30 MB. >> >> This doesn't sound right to me, unless you explicitly tried to
store a lot
>> of data. >> >> Maybe something else is wrong that would explain the slowness. >> >> > I can tell you that I am on MacOS Yosemite , I get my image with >> > pharolauncher, the image was dowloaded at 27-07-15 some of the
84 items
>> > are folders that contain many sub folders. No idea if that
matters.
>> > >> > I got Roassal 2 using the Package Browser in Pharo 5 (the new >> > configuration browser). >> > >> > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >> > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> > Are you using windows? I know it may has problems regarding the
source
>> > code. You have 84 items and the visualization is slow? How is
this
>> > possible. >> > >> > Can I have a look at your image? >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> >> mailto:kilon.alios@gmail.com> wrote: >> >> >> >> thats ok it unfroze after 20 minutes or so . I managed to
inspect the b
>> >> but its incredible slow to navigate and use . Even moving the
inspector
>> >> around is incredible slow. My Documents folder contains 84
items, maybe
>> >> it cant handle so well this amount of datea ? >> >> >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> >> Oh… sorry. Was not my intention >> >> >> >> Alexandre >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
>> >>> mailto:kilon.alios@gmail.com> wrote: >> >>> >> >>> that was a nice way to freeze my image, thank you :D >> >>> >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> >>> Hi! >> >>> >> >>> Just to share a couple of experiment. I have tried the
following in a
>> >>> playground: >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> b := RTMondrian new. >> >>> >> >>> b shape rectangle >> >>> if: [ :aFile | aFile path basename beginsWith: '.' ]
color: Color
>> >>> red. >> >>> b nodes: FileLocator documents allChildren. >> >>> b edges connectFrom: #parent. >> >>> b normalizer >> >>> normalizeSize: #size using: #sqrt. >> >>> b layout tree. >> >>> b >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> >> >>> It shows a tree of the file system. Thanks to GT, simply
clicking on a
>> >>> file may show you the content and other things. >> >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >>> >> >>> You can also use the cluster layout: >> >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >>> >> >>> I have tried this on OS X, since the pointed folder is
~/Documents.
>> >>> >> >>> Cheers, >> >>> Alexandre >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/
>> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com http://www.tudorgirba.com/ >> >> "Every thing has its own flow" >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ah, one more wish:
It is often interesting to map a shade of a color to the nesting level of a treemap node. The first implementation by Roberto had this ability, and I think this is cool. So, we could have a simple method like:
- borderShadedByNesting, or - borderShadedByNestingWithColor:
What do you think?
Cheers, Doru
On Mon, Aug 24, 2015 at 8:44 PM, Tudor Girba tudor@tudorgirba.com wrote:
Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote:
Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
[image: Imágenes integradas 1]
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b
- color: Color transparent;*
- borderColor: Color black;*
- leafColor: [ :f | color scale: f size sqrt ];*
leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote:
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory
- nesting:* #directories
- leaves: *#files.
b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind
of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want
the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes.
This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
> On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote: > > Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system. > > Here it is: > http://ws.stfx.eu/C9RM2EURHKMI > > <file-treemap.png> > > Cheers, > Doru > > On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: > Is it possible to use a tree map? > > --Hannes > > On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: > > I gave a try, and I did not find anything weird. > > I guess your document folder contains many files, as Doru said > > > > Alexandre > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis < kilon.alios@gmail.com> > >> wrote: > >> > >> Frankly I dont mind big images or big data , neither I share the obsession > >> to shrink things down to few mbs in a time that we are talking in TBs . > >> > >> Anyway you asked for the image and this is a link to it > >> > >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 > >> < https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 > > >> > >> I dont think you will find anything abnormal about it though. > >> > >> I was wondering whether it would worth the effort beyond the unit tests > >> that check for behaviour of the code to have also benchmark tests that > >> will have to pass specific standards so that specific method must perform > >> under a strict timetable specific tasks, this way CI may alert not only > >> unit tests that fail but also benchmarks that fail , automagically. > >> > >> Maybe some food for thought. > >> > >> Personally I am far more worried how much CPU Pharo consumes than how much > >> RAM. > >> > >> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com > >> mailto:i.uhnak@gmail.com> wrote: > >> Not sure if there is any downside (I've been using it for a long time > >> without problems), but image cleanup often does wonders for me. > >> > >> Moose image > >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 > >> MB > >> and I even had situations where it went from ~600 MB to ~60 MB. > >> (As to why my images are so massive... right now there are 19 windows > >> opened inside most of them with opened roassal visualization... and I am > >> saving like every five minutes... but that is just a guess.) > >> > >> But image cleanup is supposed to break things, so better to backup the > >> folder first. > >> Plus is cache really necessary? I mean it's a cache. .image + .changes > >> should usually suffice. > >> > >> Peter > >> > >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis < kilon.alios@gmail.com > >> mailto:kilon.alios@gmail.com> wrote: > >> Tudor I dont know if you received my message but I already answered that > >> with this: > >> > >> "ah ok then its normal. Yes the structure is extensive, its 13 folders > >> (the rest 71 are files some of them very big), I would not be surprised if > >> each contains 100 files in its own subfolders." > >> > >> > >> > >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba < tudor@tudorgirba.com > >> mailto:tudor@tudorgirba.com> wrote: > >> Hi, > >> > >> But, do you confirm that you have many files under the mentioned folder? > >> > >> Cheers, > >> Doru > >> > >> > >> > >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis < kilon.alios@gmail.com > >> mailto:kilon.alios@gmail.com> wrote: > >> the image is 180 mb, changes are another 15, there are several other > >> folders that raise the total size to 250 mb, monticello-cache and > >> github-cache prodominately. > >> > >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me > >> 1-2 hours to upload on this connection. So if you guys still need the > >> image i can upload tommorow from work, though it seems my slow down is > >> normal. > >> > >> Afterall I am sure you can test it yourselves on complex file structures > >> to see if it has delays as long as 20 minutes. > >> > >> > >> > >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe < sven@stfx.eu > >> mailto:sven@stfx.eu> wrote: > >> > >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis < kilon.alios@gmail.com > >> > mailto:kilon.alios@gmail.com> wrote: > >> > > >> > well i can send you the image tommorow because its huge (200 MB ziped) > >> > for my pathetically slow internet connection at home. I will send it > >> > from work which is 8 times faster. > >> > >> If the image is 200 MB zipped, how large is it in its normal state ? > >> > >> For me, a 100 MB image file is already quite large, that would compress to > >> maybe 20/30 MB. > >> > >> This doesn't sound right to me, unless you explicitly tried to store a lot > >> of data. > >> > >> Maybe something else is wrong that would explain the slowness. > >> > >> > I can tell you that I am on MacOS Yosemite , I get my image with > >> > pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items > >> > are folders that contain many sub folders. No idea if that matters. > >> > > >> > I got Roassal 2 using the Package Browser in Pharo 5 (the new > >> > configuration browser). > >> > > >> > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel > >> > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > >> > Are you using windows? I know it may has problems regarding the source > >> > code. You have 84 items and the visualization is slow? How is this > >> > possible. > >> > > >> > Can I have a look at your image? > >> > > >> > Cheers, > >> > Alexandre > >> > -- > >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > > >> > > >> > > >> >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis < kilon.alios@gmail.com > >> >> mailto:kilon.alios@gmail.com> wrote: > >> >> > >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b > >> >> but its incredible slow to navigate and use . Even moving the inspector > >> >> around is incredible slow. My Documents folder contains 84 items, maybe > >> >> it cant handle so well this amount of datea ? > >> >> > >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel > >> >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > >> >> Oh… sorry. Was not my intention > >> >> > >> >> Alexandre > >> >> -- > >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> >> > >> >> > >> >> > >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis < kilon.alios@gmail.com > >> >>> mailto:kilon.alios@gmail.com> wrote: > >> >>> > >> >>> that was a nice way to freeze my image, thank you :D > >> >>> > >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel > >> >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > >> >>> Hi! > >> >>> > >> >>> Just to share a couple of experiment. I have tried the following in a > >> >>> playground: > >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >> >>> b := RTMondrian new. > >> >>> > >> >>> b shape rectangle > >> >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color > >> >>> red. > >> >>> b nodes: FileLocator documents allChildren. > >> >>> b edges connectFrom: #parent. > >> >>> b normalizer > >> >>> normalizeSize: #size using: #sqrt. > >> >>> b layout tree. > >> >>> b > >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >> >>> > >> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a > >> >>> file may show you the content and other things. > >> >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> > >> >>> > >> >>> You can also use the cluster layout: > >> >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> > >> >>> > >> >>> I have tried this on OS X, since the pointed folder is ~/Documents. > >> >>> > >> >>> Cheers, > >> >>> Alexandre > >> >>> -- > >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> >>> Alexandre Bergel http://www.bergel.eu < http://www.bergel.eu/%3E > >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> >>> > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> Moose-dev mailing list > >> >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> >> > >> >> _______________________________________________ > >> >> Moose-dev mailing list > >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> >> _______________________________________________ > >> >> Moose-dev mailing list > >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > > >> > _______________________________________________ > >> > Moose-dev mailing list > >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > _______________________________________________ > >> > Moose-dev mailing list > >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com http://www.tudorgirba.com/ > >> > >> "Every thing has its own flow" > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> _______________________________________________ > >> Moose-dev mailing list > >> Moose-dev@iam.unibe.ch > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Doru, do you have an example? A screenshots for example. I think it will help
Cheers, Alexandre
On Aug 26, 2015, at 11:13 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ah, one more wish:
It is often interesting to map a shade of a color to the nesting level of a treemap node. The first implementation by Roberto had this ability, and I think this is cool. So, we could have a simple method like:
- borderShadedByNesting, or
- borderShadedByNestingWithColor:
What do you think?
Cheers, Doru
On Mon, Aug 24, 2015 at 8:44 PM, Tudor Girba tudor@tudorgirba.com wrote: Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote: Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
<image.png>
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote: Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
<image.png>
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
<image.png>
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this:
b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ].
This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com mailto:i.uhnak@gmail.com> wrote: Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com mailto:tudor@tudorgirba.com> wrote: Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com mailto:kilon.alios@gmail.com> wrote: the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu mailto:sven@stfx.eu> wrote:
> On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com > mailto:kilon.alios@gmail.com> wrote: > > well i can send you the image tommorow because its huge (200 MB ziped) > for my pathetically slow internet connection at home. I will send it > from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
> I can tell you that I am on MacOS Yosemite , I get my image with > pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items > are folders that contain many sub folders. No idea if that matters. > > I got Roassal 2 using the Package Browser in Pharo 5 (the new > configuration browser). > > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: > Are you using windows? I know it may has problems regarding the source > code. You have 84 items and the visualization is slow? How is this > possible. > > Can I have a look at your image? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >> but its incredible slow to navigate and use . Even moving the inspector >> around is incredible slow. My Documents folder contains 84 items, maybe >> it cant handle so well this amount of datea ? >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >> Oh… sorry. Was not my intention >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com >>> mailto:kilon.alios@gmail.com> wrote: >>> >>> that was a nice way to freeze my image, thank you :D >>> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>> Hi! >>> >>> Just to share a couple of experiment. I have tried the following in a >>> playground: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> b := RTMondrian new. >>> >>> b shape rectangle >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >>> red. >>> b nodes: FileLocator documents allChildren. >>> b edges connectFrom: #parent. >>> b normalizer >>> normalizeSize: #size using: #sqrt. >>> b layout tree. >>> b >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a >>> file may show you the content and other things. >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>> >>> You can also use the cluster layout: >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>> >>> I have tried this on OS X, since the pointed folder is ~/Documents. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com http://www.tudorgirba.com/
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Here, for example, I was using an heat scale from blue to red to display where the user interacted in the system. Super old work, though.
Cheers, R
On 26 Aug 2015, at 17:19, Alexandre Bergel alexandre.bergel@me.com wrote:
Doru, do you have an example? A screenshots for example. I think it will help
Cheers, Alexandre
On Aug 26, 2015, at 11:13 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ah, one more wish:
It is often interesting to map a shade of a color to the nesting level of a treemap node. The first implementation by Roberto had this ability, and I think this is cool. So, we could have a simple method like:
- borderShadedByNesting, or
- borderShadedByNestingWithColor:
What do you think?
Cheers, Doru
On Mon, Aug 24, 2015 at 8:44 PM, Tudor Girba tudor@tudorgirba.com wrote: Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote: Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
<image.png>
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote: Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
<image.png>
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
<image.png>
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this:
b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like
weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com > wrote: > > Frankly I dont mind big images or big data , neither I share the obsession > to shrink things down to few mbs in a time that we are talking in TBs . > > Anyway you asked for the image and this is a link to it > > https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 > https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 > > I dont think you will find anything abnormal about it though. > > I was wondering whether it would worth the effort beyond the unit tests > that check for behaviour of the code to have also benchmark tests that > will have to pass specific standards so that specific method must perform > under a strict timetable specific tasks, this way CI may alert not only > unit tests that fail but also benchmarks that fail , automagically. > > Maybe some food for thought. > > Personally I am far more worried how much CPU Pharo consumes than how much > RAM. > > On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com > mailto:i.uhnak@gmail.com> wrote: > Not sure if there is any downside (I've been using it for a long time > without problems), but image cleanup often does wonders for me. > > Moose image > 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 > MB > and I even had situations where it went from ~600 MB to ~60 MB. > (As to why my images are so massive... right now there are 19 windows > opened inside most of them with opened roassal visualization... and I am > saving like every five minutes... but that is just a guess.) > > But image cleanup is supposed to break things, so better to backup the > folder first. > Plus is cache really necessary? I mean it's a cache. .image + .changes > should usually suffice. > > Peter > > On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com > mailto:kilon.alios@gmail.com> wrote: > Tudor I dont know if you received my message but I already answered that > with this: > > "ah ok then its normal. Yes the structure is extensive, its 13 folders > (the rest 71 are files some of them very big), I would not be surprised if > each contains 100 files in its own subfolders." > > > > On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com > mailto:tudor@tudorgirba.com> wrote: > Hi, > > But, do you confirm that you have many files under the mentioned folder? > > Cheers, > Doru > > > > On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com > mailto:kilon.alios@gmail.com> wrote: > the image is 180 mb, changes are another 15, there are several other > folders that raise the total size to 250 mb, monticello-cache and > github-cache prodominately. > > Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me > 1-2 hours to upload on this connection. So if you guys still need the > image i can upload tommorow from work, though it seems my slow down is > normal. > > Afterall I am sure you can test it yourselves on complex file structures > to see if it has delays as long as 20 minutes. > > > > On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu > mailto:sven@stfx.eu> wrote: > >> On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> >> well i can send you the image tommorow because its huge (200 MB ziped) >> for my pathetically slow internet connection at home. I will send it >> from work which is 8 times faster. > > If the image is 200 MB zipped, how large is it in its normal state ? > > For me, a 100 MB image file is already quite large, that would compress to > maybe 20/30 MB. > > This doesn't sound right to me, unless you explicitly tried to store a lot > of data. > > Maybe something else is wrong that would explain the slowness. > >> I can tell you that I am on MacOS Yosemite , I get my image with >> pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items >> are folders that contain many sub folders. No idea if that matters. >> >> I got Roassal 2 using the Package Browser in Pharo 5 (the new >> configuration browser). >> >> On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >> Are you using windows? I know it may has problems regarding the source >> code. You have 84 items and the visualization is slow? How is this >> possible. >> >> Can I have a look at your image? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com >>> mailto:kilon.alios@gmail.com> wrote: >>> >>> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >>> but its incredible slow to navigate and use . Even moving the inspector >>> around is incredible slow. My Documents folder contains 84 items, maybe >>> it cant handle so well this amount of datea ? >>> >>> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>> Oh… sorry. Was not my intention >>> >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com >>>> mailto:kilon.alios@gmail.com> wrote: >>>> >>>> that was a nice way to freeze my image, thank you :D >>>> >>>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>> Hi! >>>> >>>> Just to share a couple of experiment. I have tried the following in a >>>> playground: >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> b := RTMondrian new. >>>> >>>> b shape rectangle >>>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >>>> red. >>>> b nodes: FileLocator documents allChildren. >>>> b edges connectFrom: #parent. >>>> b normalizer >>>> normalizeSize: #size using: #sqrt. >>>> b layout tree. >>>> b >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> It shows a tree of the file system. Thanks to GT, simply clicking on a >>>> file may show you the content and other things. >>>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>>> >>>> You can also use the cluster layout: >>>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>>> >>>> I have tried this on OS X, since the pointed folder is ~/Documents. >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > > -- > www.tudorgirba.comhttp://www.tudorgirba.com http://www.tudorgirba.com/ > > "Every thing has its own flow" > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks Roberto,
We will look into this
Alexandre
On Aug 26, 2015, at 1:32 PM, roberto.minelli@usi.ch wrote:
Hi,
Here, for example, I was using an heat scale from blue to red to display where the user interacted in the system. Super old work, though.
Cheers, R
On 26 Aug 2015, at 17:19, Alexandre Bergel alexandre.bergel@me.com wrote:
Doru, do you have an example? A screenshots for example. I think it will help
Cheers, Alexandre
On Aug 26, 2015, at 11:13 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ah, one more wish:
It is often interesting to map a shade of a color to the nesting level of a treemap node. The first implementation by Roberto had this ability, and I think this is cool. So, we could have a simple method like:
- borderShadedByNesting, or
- borderShadedByNestingWithColor:
What do you think?
Cheers, Doru
On Mon, Aug 24, 2015 at 8:44 PM, Tudor Girba tudor@tudorgirba.com wrote: Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote: Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
<image.png>
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote: Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
<image.png>
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
<image.png>
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this:
b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like
weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote:
Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: > I gave a try, and I did not find anything weird. > I guess your document folder contains many files, as Doru said > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com >> wrote: >> >> Frankly I dont mind big images or big data , neither I share the obsession >> to shrink things down to few mbs in a time that we are talking in TBs . >> >> Anyway you asked for the image and this is a link to it >> >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >> >> I dont think you will find anything abnormal about it though. >> >> I was wondering whether it would worth the effort beyond the unit tests >> that check for behaviour of the code to have also benchmark tests that >> will have to pass specific standards so that specific method must perform >> under a strict timetable specific tasks, this way CI may alert not only >> unit tests that fail but also benchmarks that fail , automagically. >> >> Maybe some food for thought. >> >> Personally I am far more worried how much CPU Pharo consumes than how much >> RAM. >> >> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com >> mailto:i.uhnak@gmail.com> wrote: >> Not sure if there is any downside (I've been using it for a long time >> without problems), but image cleanup often does wonders for me. >> >> Moose image >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 >> MB >> and I even had situations where it went from ~600 MB to ~60 MB. >> (As to why my images are so massive... right now there are 19 windows >> opened inside most of them with opened roassal visualization... and I am >> saving like every five minutes... but that is just a guess.) >> >> But image cleanup is supposed to break things, so better to backup the >> folder first. >> Plus is cache really necessary? I mean it's a cache. .image + .changes >> should usually suffice. >> >> Peter >> >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> Tudor I dont know if you received my message but I already answered that >> with this: >> >> "ah ok then its normal. Yes the structure is extensive, its 13 folders >> (the rest 71 are files some of them very big), I would not be surprised if >> each contains 100 files in its own subfolders." >> >> >> >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com >> mailto:tudor@tudorgirba.com> wrote: >> Hi, >> >> But, do you confirm that you have many files under the mentioned folder? >> >> Cheers, >> Doru >> >> >> >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com >> mailto:kilon.alios@gmail.com> wrote: >> the image is 180 mb, changes are another 15, there are several other >> folders that raise the total size to 250 mb, monticello-cache and >> github-cache prodominately. >> >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me >> 1-2 hours to upload on this connection. So if you guys still need the >> image i can upload tommorow from work, though it seems my slow down is >> normal. >> >> Afterall I am sure you can test it yourselves on complex file structures >> to see if it has delays as long as 20 minutes. >> >> >> >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu >> mailto:sven@stfx.eu> wrote: >> >>> On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com >>> mailto:kilon.alios@gmail.com> wrote: >>> >>> well i can send you the image tommorow because its huge (200 MB ziped) >>> for my pathetically slow internet connection at home. I will send it >>> from work which is 8 times faster. >> >> If the image is 200 MB zipped, how large is it in its normal state ? >> >> For me, a 100 MB image file is already quite large, that would compress to >> maybe 20/30 MB. >> >> This doesn't sound right to me, unless you explicitly tried to store a lot >> of data. >> >> Maybe something else is wrong that would explain the slowness. >> >>> I can tell you that I am on MacOS Yosemite , I get my image with >>> pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items >>> are folders that contain many sub folders. No idea if that matters. >>> >>> I got Roassal 2 using the Package Browser in Pharo 5 (the new >>> configuration browser). >>> >>> On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>> Are you using windows? I know it may has problems regarding the source >>> code. You have 84 items and the visualization is slow? How is this >>> possible. >>> >>> Can I have a look at your image? >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>>> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com >>>> mailto:kilon.alios@gmail.com> wrote: >>>> >>>> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >>>> but its incredible slow to navigate and use . Even moving the inspector >>>> around is incredible slow. My Documents folder contains 84 items, maybe >>>> it cant handle so well this amount of datea ? >>>> >>>> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>> Oh… sorry. Was not my intention >>>> >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com >>>>> mailto:kilon.alios@gmail.com> wrote: >>>>> >>>>> that was a nice way to freeze my image, thank you :D >>>>> >>>>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >>>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>>> Hi! >>>>> >>>>> Just to share a couple of experiment. I have tried the following in a >>>>> playground: >>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>> b := RTMondrian new. >>>>> >>>>> b shape rectangle >>>>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >>>>> red. >>>>> b nodes: FileLocator documents allChildren. >>>>> b edges connectFrom: #parent. >>>>> b normalizer >>>>> normalizeSize: #size using: #sqrt. >>>>> b layout tree. >>>>> b >>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> It shows a tree of the file system. Thanks to GT, simply clicking on a >>>>> file may show you the content and other things. >>>>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>>>> >>>>> You can also use the cluster layout: >>>>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>>>> >>>>> I have tried this on OS X, since the pointed folder is ~/Documents. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.comhttp://www.tudorgirba.com http://www.tudorgirba.com/ >> >> "Every thing has its own flow" >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<dflow-treemap.pdf>_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
No problem ;)
As Doru said, my original implementation had this (and other similar) abilities :)
Cheers, R
On 26 Aug 2015, at 19:08, Alexandre Bergel alexandre.bergel@me.com wrote:
Thanks Roberto,
We will look into this
Alexandre
On Aug 26, 2015, at 1:32 PM, roberto.minelli@usi.ch wrote:
Hi,
Here, for example, I was using an heat scale from blue to red to display where the user interacted in the system. Super old work, though.
Cheers, R
On 26 Aug 2015, at 17:19, Alexandre Bergel alexandre.bergel@me.com wrote:
Doru, do you have an example? A screenshots for example. I think it will help
Cheers, Alexandre
On Aug 26, 2015, at 11:13 AM, Tudor Girba tudor@tudorgirba.com wrote:
Ah, one more wish:
It is often interesting to map a shade of a color to the nesting level of a treemap node. The first implementation by Roberto had this ability, and I think this is cool. So, we could have a simple method like:
- borderShadedByNesting, or
- borderShadedByNestingWithColor:
What do you think?
Cheers, Doru
On Mon, Aug 24, 2015 at 8:44 PM, Tudor Girba tudor@tudorgirba.com wrote: Is this not beautiful? :)
Thanks a lot, Doru
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote: Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
<image.png>
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote: Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
<image.png>
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
<image.png>
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com: Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this:
b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like
weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel alexandre.bergel@me.com wrote: Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
> On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com wrote: > > Of course, it is. In fact, a treemap is a better suited representation for understanding the size of a file system. > > Here it is: > http://ws.stfx.eu/C9RM2EURHKMI > > <file-treemap.png> > > Cheers, > Doru > > On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com wrote: > Is it possible to use a tree map? > > --Hannes > > On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: >> I gave a try, and I did not find anything weird. >> I guess your document folder contains many files, as Doru said >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com >>> wrote: >>> >>> Frankly I dont mind big images or big data , neither I share the obsession >>> to shrink things down to few mbs in a time that we are talking in TBs . >>> >>> Anyway you asked for the image and this is a link to it >>> >>> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >>> https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 >>> >>> I dont think you will find anything abnormal about it though. >>> >>> I was wondering whether it would worth the effort beyond the unit tests >>> that check for behaviour of the code to have also benchmark tests that >>> will have to pass specific standards so that specific method must perform >>> under a strict timetable specific tasks, this way CI may alert not only >>> unit tests that fail but also benchmarks that fail , automagically. >>> >>> Maybe some food for thought. >>> >>> Personally I am far more worried how much CPU Pharo consumes than how much >>> RAM. >>> >>> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com >>> mailto:i.uhnak@gmail.com> wrote: >>> Not sure if there is any downside (I've been using it for a long time >>> without problems), but image cleanup often does wonders for me. >>> >>> Moose image >>> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 >>> MB >>> and I even had situations where it went from ~600 MB to ~60 MB. >>> (As to why my images are so massive... right now there are 19 windows >>> opened inside most of them with opened roassal visualization... and I am >>> saving like every five minutes... but that is just a guess.) >>> >>> But image cleanup is supposed to break things, so better to backup the >>> folder first. >>> Plus is cache really necessary? I mean it's a cache. .image + .changes >>> should usually suffice. >>> >>> Peter >>> >>> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <kilon.alios@gmail.com >>> mailto:kilon.alios@gmail.com> wrote: >>> Tudor I dont know if you received my message but I already answered that >>> with this: >>> >>> "ah ok then its normal. Yes the structure is extensive, its 13 folders >>> (the rest 71 are files some of them very big), I would not be surprised if >>> each contains 100 files in its own subfolders." >>> >>> >>> >>> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <tudor@tudorgirba.com >>> mailto:tudor@tudorgirba.com> wrote: >>> Hi, >>> >>> But, do you confirm that you have many files under the mentioned folder? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <kilon.alios@gmail.com >>> mailto:kilon.alios@gmail.com> wrote: >>> the image is 180 mb, changes are another 15, there are several other >>> folders that raise the total size to 250 mb, monticello-cache and >>> github-cache prodominately. >>> >>> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me >>> 1-2 hours to upload on this connection. So if you guys still need the >>> image i can upload tommorow from work, though it seems my slow down is >>> normal. >>> >>> Afterall I am sure you can test it yourselves on complex file structures >>> to see if it has delays as long as 20 minutes. >>> >>> >>> >>> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <sven@stfx.eu >>> mailto:sven@stfx.eu> wrote: >>> >>>> On 29 Jul 2015, at 21:33, Dimitris Chloupis <kilon.alios@gmail.com >>>> mailto:kilon.alios@gmail.com> wrote: >>>> >>>> well i can send you the image tommorow because its huge (200 MB ziped) >>>> for my pathetically slow internet connection at home. I will send it >>>> from work which is 8 times faster. >>> >>> If the image is 200 MB zipped, how large is it in its normal state ? >>> >>> For me, a 100 MB image file is already quite large, that would compress to >>> maybe 20/30 MB. >>> >>> This doesn't sound right to me, unless you explicitly tried to store a lot >>> of data. >>> >>> Maybe something else is wrong that would explain the slowness. >>> >>>> I can tell you that I am on MacOS Yosemite , I get my image with >>>> pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items >>>> are folders that contain many sub folders. No idea if that matters. >>>> >>>> I got Roassal 2 using the Package Browser in Pharo 5 (the new >>>> configuration browser). >>>> >>>> On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>> Are you using windows? I know it may has problems regarding the source >>>> code. You have 84 items and the visualization is slow? How is this >>>> possible. >>>> >>>> Can I have a look at your image? >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>>> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <kilon.alios@gmail.com >>>>> mailto:kilon.alios@gmail.com> wrote: >>>>> >>>>> thats ok it unfroze after 20 minutes or so . I managed to inspect the b >>>>> but its incredible slow to navigate and use . Even moving the inspector >>>>> around is incredible slow. My Documents folder contains 84 items, maybe >>>>> it cant handle so well this amount of datea ? >>>>> >>>>> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >>>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>>> Oh… sorry. Was not my intention >>>>> >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <kilon.alios@gmail.com >>>>>> mailto:kilon.alios@gmail.com> wrote: >>>>>> >>>>>> that was a nice way to freeze my image, thank you :D >>>>>> >>>>>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >>>>>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com> wrote: >>>>>> Hi! >>>>>> >>>>>> Just to share a couple of experiment. I have tried the following in a >>>>>> playground: >>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>>> b := RTMondrian new. >>>>>> >>>>>> b shape rectangle >>>>>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color >>>>>> red. >>>>>> b nodes: FileLocator documents allChildren. >>>>>> b edges connectFrom: #parent. >>>>>> b normalizer >>>>>> normalizeSize: #size using: #sqrt. >>>>>> b layout tree. >>>>>> b >>>>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>>>> >>>>>> It shows a tree of the file system. Thanks to GT, simply clicking on a >>>>>> file may show you the content and other things. >>>>>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>>>>> >>>>>> You can also use the cluster layout: >>>>>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>>>>> >>>>>> I have tried this on OS X, since the pointed folder is ~/Documents. >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> >>> -- >>> www.tudorgirba.comhttp://www.tudorgirba.com http://www.tudorgirba.com/ >>> >>> "Every thing has its own flow" >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > > > -- > www.tudorgirba.comhttp://www.tudorgirba.com > > "Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.comhttp://www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
<dflow-treemap.pdf>_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I remember that we have done similar simulation with Quicksilver http://scg.unibe.ch/research/quicksilver during Pharoconf in Berne.
On Mon, Aug 24, 2015 at 7:38 PM, milton mamani akevalion@gmail.com wrote:
Done, check with the last version of Roassal
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color gray. Color red }. b color: Color transparent; borderColor: Color black; leafColor: [ :f | color scale: f size sqrt ]; leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b view
[image: Imágenes integradas 1]
Cheers, Milton
2015-08-23 9:37 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Make sense to me
Alexandre
Le 23 août 2015 à 07:32, Tudor Girba tudor@tudorgirba.com a écrit :
It looks great.
The only place which still requires the if now is the specification of color.
I think that for this builder, given that the shape is predefined, it makes sense to provide direct color manipulation in the builder:
| b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b
- color: Color transparent;*
- borderColor: Color black;*
- leafColor: [ :f | color scale: f size sqrt ];*
leafWeight: [:f | f size sqrt ]; explore: FileSystem disk workingDirectory nesting: #directories leaves: #files. b build. ^ b
What do you think?
Cheers, Doru
On Fri, Aug 21, 2015 at 12:52 AM, milton mamani akevalion@gmail.com wrote:
Hi Tudor,
I've been working on this. The next piece of code shows an example in the file system.
.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.= | b color | b := RTTreeMapBuilder new. color := RTScale linear domain: { 0. 12000.}; range: { Color green. Color red }. b shape color: Color transparent; borderColor: Color black; if: [ :f | f isFile ] color: [ :f | color scale: f size sqrt ]. b *leafWeight: *[:f | f size sqrt ]; *explore:* FileSystem disk workingDirectory
- nesting:* #directories
- leaves: *#files.
b build. ^ b view .=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=.=
#explore:nesting:leaves: is related to the point 1, please tell me is that what you expected? #leaftWeight: selector is related to the point 2 and the point 3,
The result for RTTreeMapBuilder
[image: Imágenes integradas 2]
the color means red = big file.
This is the result for RTCircularTreeMapBuilder
[image: Imágenes integradas 3]
Cheers, Milton
2015-07-31 9:16 GMT-04:00 Alexandre Bergel alexandre.bergel@me.com:
Excellent! We will work on this!
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 31, 2015, at 5:06 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I use it quite often.
The builder is Ok, but I would improve some things to make it elegant:
- A treemap works well when there is a nested structure of one kind of
nodes and the leaves are of a different kind. So, folder/file, packages/classes. Thus, having only one traversal will inevitably lead to an if inside. I would rather be interested in having a higher level constructs that allow us to state what is the nested structure, and what are the leaves. Perhaps like this: b buildFrom: aRootNestingObject nesting: [ :aNestingObject | aNestingObject childNestedObjects ] leaves: [ :aNestingObject | aNestingObject childLeaves]
- The aggregation of metrics should be built in. Typically, you want
the size of the nested structure to be deduced by the aggregate size of the inner leaves. Thus, ideally, there should be a way to specify the weight only for the leaves and let the engine do the rest of calculations. For example, in the case of the file system visualization, the weight block looks like weight: [ :each | each isFile ifTrue: [each size max: 1] ifFalse: [(each allChildren sumNumbers: #size) max: 1 ] ]. This means that I will traverse and compute the size of files needlessly multiple times for each of the parent folder. To make it faster, I would have to build a cache for the size of files and look it up in the block. This should be offered by the engine because it is the default use case. So, I should only say: b leafWeight: [:file | file size]
- Talking about weights, if the weight is 0, the builder crashes. This
should be made more robust. In my scripts, I always add a "max: 1", but this is clumsy. This should be built in.
The same remarks apply for the RTTreeMapBuilder.
Cheers, Doru
On Fri, Jul 31, 2015 at 12:38 AM, Alexandre Bergel < alexandre.bergel@me.com> wrote:
Excellent!
By the way, you told me you use the treemap builder quite a lot. This means you are happy about it right ? Do you have anything to change?
Alexandre
On Jul 30, 2015, at 5:35 PM, Tudor Girba tudor@tudorgirba.com
wrote:
Of course, it is. In fact, a treemap is a better suited
representation for understanding the size of a file system.
Here it is: http://ws.stfx.eu/C9RM2EURHKMI
<file-treemap.png>
Cheers, Doru
On Thu, Jul 30, 2015 at 8:40 PM, H. Hirzel hannes.hirzel@gmail.com
wrote:
Is it possible to use a tree map?
--Hannes
On 7/30/15, Alexandre Bergel alexandre.bergel@me.com wrote: > I gave a try, and I did not find anything weird. > I guess your document folder contains many files, as Doru said > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis <
kilon.alios@gmail.com>
>> wrote: >> >> Frankly I dont mind big images or big data , neither I share the
obsession
>> to shrink things down to few mbs in a time that we are talking in
TBs .
>> >> Anyway you asked for the image and this is a link to it >> >>
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
>> <
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
>> >> I dont think you will find anything abnormal about it though. >> >> I was wondering whether it would worth the effort beyond the unit
tests
>> that check for behaviour of the code to have also benchmark tests
that
>> will have to pass specific standards so that specific method must
perform
>> under a strict timetable specific tasks, this way CI may alert
not only
>> unit tests that fail but also benchmarks that fail ,
automagically.
>> >> Maybe some food for thought. >> >> Personally I am far more worried how much CPU Pharo consumes than
how much
>> RAM. >> >> On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <i.uhnak@gmail.com >> mailto:i.uhnak@gmail.com> wrote: >> Not sure if there is any downside (I've been using it for a long
time
>> without problems), but image cleanup often does wonders for me. >> >> Moose image >> 410 MB => cleanup (World -> System -> Do Image Cleanup) => save
=> 237
>> MB >> and I even had situations where it went from ~600 MB to ~60 MB. >> (As to why my images are so massive... right now there are 19
windows
>> opened inside most of them with opened roassal visualization...
and I am
>> saving like every five minutes... but that is just a guess.) >> >> But image cleanup is supposed to break things, so better to
backup the
>> folder first. >> Plus is cache really necessary? I mean it's a cache. .image +
.changes
>> should usually suffice. >> >> Peter >> >> On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> Tudor I dont know if you received my message but I already
answered that
>> with this: >> >> "ah ok then its normal. Yes the structure is extensive, its 13
folders
>> (the rest 71 are files some of them very big), I would not be
surprised if
>> each contains 100 files in its own subfolders." >> >> >> >> On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba <
tudor@tudorgirba.com
>> mailto:tudor@tudorgirba.com> wrote: >> Hi, >> >> But, do you confirm that you have many files under the mentioned
folder?
>> >> Cheers, >> Doru >> >> >> >> On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> mailto:kilon.alios@gmail.com> wrote: >> the image is 180 mb, changes are another 15, there are several
other
>> folders that raise the total size to 250 mb, monticello-cache and >> github-cache prodominately. >> >> Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still
will take me
>> 1-2 hours to upload on this connection. So if you guys still need
the
>> image i can upload tommorow from work, though it seems my slow
down is
>> normal. >> >> Afterall I am sure you can test it yourselves on complex file
structures
>> to see if it has delays as long as 20 minutes. >> >> >> >> On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <
sven@stfx.eu
>> mailto:sven@stfx.eu> wrote: >> >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis <
kilon.alios@gmail.com
>> > mailto:kilon.alios@gmail.com> wrote: >> > >> > well i can send you the image tommorow because its huge (200 MB
ziped)
>> > for my pathetically slow internet connection at home. I will
send it
>> > from work which is 8 times faster. >> >> If the image is 200 MB zipped, how large is it in its normal
state ?
>> >> For me, a 100 MB image file is already quite large, that would
compress to
>> maybe 20/30 MB. >> >> This doesn't sound right to me, unless you explicitly tried to
store a lot
>> of data. >> >> Maybe something else is wrong that would explain the slowness. >> >> > I can tell you that I am on MacOS Yosemite , I get my image with >> > pharolauncher, the image was dowloaded at 27-07-15 some of the
84 items
>> > are folders that contain many sub folders. No idea if that
matters.
>> > >> > I got Roassal 2 using the Package Browser in Pharo 5 (the new >> > configuration browser). >> > >> > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel >> > <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> > Are you using windows? I know it may has problems regarding the
source
>> > code. You have 84 items and the visualization is slow? How is
this
>> > possible. >> > >> > Can I have a look at your image? >> > >> > Cheers, >> > Alexandre >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis <
kilon.alios@gmail.com
>> >> mailto:kilon.alios@gmail.com> wrote: >> >> >> >> thats ok it unfroze after 20 minutes or so . I managed to
inspect the b
>> >> but its incredible slow to navigate and use . Even moving the
inspector
>> >> around is incredible slow. My Documents folder contains 84
items, maybe
>> >> it cant handle so well this amount of datea ? >> >> >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel >> >> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> >> Oh… sorry. Was not my intention >> >> >> >> Alexandre >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu http://www.bergel.eu/ >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <
kilon.alios@gmail.com
>> >>> mailto:kilon.alios@gmail.com> wrote: >> >>> >> >>> that was a nice way to freeze my image, thank you :D >> >>> >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> >>> <alexandre.bergel@me.com mailto:alexandre.bergel@me.com>
wrote:
>> >>> Hi! >> >>> >> >>> Just to share a couple of experiment. I have tried the
following in a
>> >>> playground: >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> b := RTMondrian new. >> >>> >> >>> b shape rectangle >> >>> if: [ :aFile | aFile path basename beginsWith: '.' ]
color: Color
>> >>> red. >> >>> b nodes: FileLocator documents allChildren. >> >>> b edges connectFrom: #parent. >> >>> b normalizer >> >>> normalizeSize: #size using: #sqrt. >> >>> b layout tree. >> >>> b >> >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >>> >> >>> It shows a tree of the file system. Thanks to GT, simply
clicking on a
>> >>> file may show you the content and other things. >> >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >> >>> >> >>> You can also use the cluster layout: >> >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >> >>> >> >>> I have tried this on OS X, since the pointed folder is
~/Documents.
>> >>> >> >>> Cheers, >> >>> Alexandre >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/
>> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Moose-dev mailing list >> >>> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> www.tudorgirba.com http://www.tudorgirba.com/ >> >> "Every thing has its own flow" >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >
-- www.tudorgirba.com
"Every thing has its own flow"
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
I also did my tests and it appears that an image with the things i installed including roassal 2 is a mere 52 mbs so the rest 130mb must be the data generated by your example .
I did manage to calculate the total amount of files and total amount of subfolders files: 64014 (sub)folders: 10073 total size of Documents folder: 101,64 GB total size of HD: 1 TB
On Thu, Jul 30, 2015 at 6:32 PM Alexandre Bergel alexandre.bergel@me.com wrote:
I gave a try, and I did not find anything weird. I guess your document folder contains many files, as Doru said
Alexandre
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Jul 30, 2015, at 5:51 AM, Dimitris Chloupis kilon.alios@gmail.com wrote:
Frankly I dont mind big images or big data , neither I share the obsession to shrink things down to few mbs in a time that we are talking in TBs .
Anyway you asked for the image and this is a link to it
https://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0
I dont think you will find anything abnormal about it though.
I was wondering whether it would worth the effort beyond the unit tests that check for behaviour of the code to have also benchmark tests that will have to pass specific standards so that specific method must perform under a strict timetable specific tasks, this way CI may alert not only unit tests that fail but also benchmarks that fail , automagically.
Maybe some food for thought.
Personally I am far more worried how much CPU Pharo consumes than how much RAM.
On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák i.uhnak@gmail.com wrote:
Not sure if there is any downside (I've been using it for a long time without problems), but image cleanup often does wonders for me.
Moose image 410 MB => cleanup (World -> System -> Do Image Cleanup) => save => 237 MB and I even had situations where it went from ~600 MB to ~60 MB. (As to why my images are so massive... right now there are 19 windows opened inside most of them with opened roassal visualization... and I am saving like every five minutes... but that is just a guess.)
But image cleanup is supposed to break things, so better to backup the folder first. Plus is cache really necessary? I mean it's a cache. .image + .changes should usually suffice.
Peter
On Wed, Jul 29, 2015 at 10:45 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
Tudor I dont know if you received my message but I already answered that with this:
"ah ok then its normal. Yes the structure is extensive, its 13 folders (the rest 71 are files some of them very big), I would not be surprised if each contains 100 files in its own subfolders."
On Wed, Jul 29, 2015 at 11:30 PM Tudor Girba tudor@tudorgirba.com wrote:
Hi,
But, do you confirm that you have many files under the mentioned folder?
Cheers, Doru
On Wed, Jul 29, 2015 at 10:25 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote:
the image is 180 mb, changes are another 15, there are several other folders that raise the total size to 250 mb, monticello-cache and github-cache prodominately.
Hmm ok my bad, the size of the zip is 89 MB not 200 mb. Still will take me 1-2 hours to upload on this connection. So if you guys still need the image i can upload tommorow from work, though it seems my slow down is normal.
Afterall I am sure you can test it yourselves on complex file structures to see if it has delays as long as 20 minutes.
On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe sven@stfx.eu wrote:
> On 29 Jul 2015, at 21:33, Dimitris Chloupis kilon.alios@gmail.com wrote: > > well i can send you the image tommorow because its huge (200 MB ziped) for my pathetically slow internet connection at home. I will send it from work which is 8 times faster.
If the image is 200 MB zipped, how large is it in its normal state ?
For me, a 100 MB image file is already quite large, that would compress to maybe 20/30 MB.
This doesn't sound right to me, unless you explicitly tried to store a lot of data.
Maybe something else is wrong that would explain the slowness.
> I can tell you that I am on MacOS Yosemite , I get my image with pharolauncher, the image was dowloaded at 27-07-15 some of the 84 items are folders that contain many sub folders. No idea if that matters. > > I got Roassal 2 using the Package Browser in Pharo 5 (the new configuration browser). > > On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: > Are you using windows? I know it may has problems regarding the source code. You have 84 items and the visualization is slow? How is this possible. > > Can I have a look at your image? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jul 29, 2015, at 12:26 PM, Dimitris Chloupis < kilon.alios@gmail.com> wrote: >> >> thats ok it unfroze after 20 minutes or so . I managed to inspect the b but its incredible slow to navigate and use . Even moving the inspector around is incredible slow. My Documents folder contains 84 items, maybe it cant handle so well this amount of datea ? >> >> On Wed, Jul 29, 2015 at 5:55 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: >> Oh… sorry. Was not my intention >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis < kilon.alios@gmail.com> wrote: >>> >>> that was a nice way to freeze my image, thank you :D >>> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel < alexandre.bergel@me.com> wrote: >>> Hi! >>> >>> Just to share a couple of experiment. I have tried the following in a playground: >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> b := RTMondrian new. >>> >>> b shape rectangle >>> if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. >>> b nodes: FileLocator documents allChildren. >>> b edges connectFrom: #parent. >>> b normalizer >>> normalizeSize: #size using: #sqrt. >>> b layout tree. >>> b >>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>> >>> It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things. >>> <Screen Shot 2015-07-29 at 10.23.51 AM.png> >>> >>> You can also use the cluster layout: >>> <Screen Shot 2015-07-29 at 10.25.11 AM.png> >>> >>> I have tried this on OS X, since the pointed folder is ~/Documents. >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Very nice! Thank you, Alexandre.
--Hannes
On 7/29/15, Alexandre Bergel alexandre.bergel@me.com wrote:
Hi!
Just to share a couple of experiment. I have tried the following in a playground: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= b := RTMondrian new.
b shape rectangle if: [ :aFile | aFile path basename beginsWith: '.' ] color: Color red. b nodes: FileLocator documents allChildren. b edges connectFrom: #parent. b normalizer normalizeSize: #size using: #sqrt. b layout tree. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
It shows a tree of the file system. Thanks to GT, simply clicking on a file may show you the content and other things.
You can also use the cluster layout:
I have tried this on OS X, since the pointed folder is ~/Documents.
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-
Alexandre Bergel -
Dimitris Chloupis -
H. Hirzel -
milton mamani -
Peter Uhnak -
Peter Uhnák
-
roberto.minelli＠usi.ch -
Serge Stinckwich -
Sven Van Caekenberghe -
Tudor Girba