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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
that was a nice way to freeze my image, thank you :D On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by abergel
Very nice! Thank you, Alexandre.
--Hannes On 7/29/15, Alexandre Bergel <[hidden email]> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by kilon.alios
Oh… sorry. Was not my intention
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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. On Wed, Jul 29, 2015 at 8:17 PM Alexandre Bergel <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by kilon.alios
> On 29 Jul 2015, at 21:33, Dimitris Chloupis <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> Oh… sorry. Was not my intention >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >>> On Jul 29, 2015, at 11:24 AM, Dimitris Chloupis <[hidden email]> wrote: >>> >>> that was a nice way to freeze my image, thank you :D >>> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel <[hidden email]> 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Tudor Girba-2
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by Sven Van Caekenberghe-2
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.On Wed, Jul 29, 2015 at 11:01 PM Sven Van Caekenberghe <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 ithttps://www.dropbox.com/s/wh1071xgoo54fq7/1%20Ephestos%2027-05-15.zip?dl=0 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. On Wed, Jul 29, 2015 at 11:54 PM Peter Uhnák <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by kilon.alios
On Thu, Jul 30, 2015 at 10:51 AM, Dimitris Chloupis <[hidden email]> wrote:
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.
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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
In reply to this post by kilon.alios
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Is it possible to use a treemap layout?
--Hannes On 7/30/15, Alexandre Bergel <[hidden email]> 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 <[hidden email]> >> 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 <[hidden email] >> <mailto:[hidden email]>> 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 <[hidden email] >> <mailto:[hidden email]>> 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 <[hidden email] >> <mailto:[hidden email]>> 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 <[hidden email] >> <mailto:[hidden email]>> 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 <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> > On 29 Jul 2015, at 21:33, Dimitris Chloupis <[hidden email] >> > <mailto:[hidden email]>> 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 >> > <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] >> >> <mailto:[hidden email]>> 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 >> >> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] >> >>> <mailto:[hidden email]>> wrote: >> >>> >> >>> that was a nice way to freeze my image, thank you :D >> >>> >> >>> On Wed, Jul 29, 2015 at 4:27 PM Alexandre Bergel >> >>> <[hidden email] <mailto:[hidden email]>> 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 >> >>> [hidden email] <mailto:[hidden email]> >> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >>> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] <mailto:[hidden email]> >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> >> Moose-dev mailing list >> >> [hidden email] <mailto:[hidden email]> >> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > [hidden email] <mailto:[hidden email]> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> > _______________________________________________ >> > Moose-dev mailing list >> > [hidden email] <mailto:[hidden email]> >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] <mailto:[hidden email]> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] <mailto:[hidden email]> >> 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 >> [hidden email] <mailto:[hidden email]> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] <mailto:[hidden email]> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] <mailto:[hidden email]> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> <https://www.iam.unibe.ch/mailman/listinfo/moose-dev> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |