From alexandre at bergel.eu Fri Jan 1 07:35:39 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 1 Jan 2010 07:35:39 +0100 Subject: [Moose-dev] Re: .MSE file generation In-Reply-To: <9af4151f0912311432w6470621fv622145eafbdd6e71@mail.gmail.com> References: <9af4151f0912311432w6470621fv622145eafbdd6e71@mail.gmail.com> Message-ID: <5D9EAE4F-E5A5-4954-9FDA-83BC7EFEB549@bergel.eu> Hello, You need to use inFusion (http://www.moosetechnology.org/download). You cannot directly generate the MSE file from Eclipse using inFusion. You need to have a reference to the .java files. Unzip the downloaded file, and use inFusion/tools/inFusion/java2mse.* Cheers, Alexandre On 31 Dec 2009, at 23:32, Arif Iftikhar wrote: > How to generate MSE file for Java code in eclipse. > > -- > Thanks & Regards > > Arif Iftikhar > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From richard.wettel at usi.ch Fri Jan 1 16:17:45 2010 From: richard.wettel at usi.ch (Richard Wettel) Date: Fri, 1 Jan 2010 16:17:45 +0100 Subject: [Moose-dev] Re: Problem generating a mse with infusion In-Reply-To: <1FDC8C04-14AD-4E24-873D-6DAE00C823F9@gmail.com> References: <1432E431-E6BE-4E94-AB4A-B6C9D7C7648A@inria.fr> <35773E51-55A6-4E51-BF9E-955E6F82DC91@gmail.com> <3AA41B25-C541-43E6-94F6-585B0C504CBE@inria.fr> <65C7ECD3-6E7D-4F8A-9826-6AD09E730BB7@inria.fr> <1FDC8C04-14AD-4E24-873D-6DAE00C823F9@gmail.com> Message-ID: <294AACB6-DE34-40AC-8FDA-2B04324DEAC8@usi.ch> Hi, Does it mean that inFusion works well with the latest Java release? Cheers, Ricky On Dec 26, 2009, at 9:38 PM, Tudor Girba wrote: > Hi Simon, > > Indeed, it seems that the distribution has a problem. I tried on the > development version. > > It looks like the latest inFusion does not have this problem anymore. > > Cheers, > Doru > > > On 26 Dec 2009, at 15:05, Simon Denier wrote: > >> >> On 26 d?c. 2009, at 13:19, Tudor Girba wrote: >> >>> Hi Simon, >>> >>> It works fine on my computer. I am also using 7.2.6, but I did not >>> update the JVM. >> >> >> Apparently, it is a problem with my setup, I cant import java >> projects anymore. Maybe it's a problem related with classpath or >> related, but I dont remember changing my conf recently. >> >> When running through the infusion UI, I got this exception. Maybe >> the line can give an indication about what it is looking for. >> >> --Export started-- >> FAMIX 3.0 MSE Exporter could not be run ! >> java.lang.NullPointerException >> at >> com >> .intooitus >> .infusion >> .util.FAMIX30MSEExporter.visitMethod(FAMIX30MSEExporter.java:171) >> >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> On 26 Dec 2009, at 13:04, Simon Denier wrote: >>> >>>> >>>> On 26 d?c. 2009, at 12:13, Tudor Girba wrote: >>>> >>>>> Hi Simon, >>>>> >>>>> Strange, that should not happen. I would need to see the sources >>>>> to debug this. >>>> >>>> >>>> Here you go. It compiles against Java 6 on Mac Os platform, but I >>>> didnt install the latest release. >>>> >>>> Also I used infusion 7.2.6 >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 26 Dec 2009, at 11:49, Simon Denier wrote: >>>>> >>>>>> Hi all >>>>>> >>>>>> I'm trying to generate a mse file for a java project with >>>>>> infusion. >>>>>> >>>>>> It stops somewhere with this error: >>>>>> Writing the MSE file for the path: /Users/deniersi/workspace/ >>>>>> GecO/src >>>>>> --Export started-- >>>>>> MSE file generation aborted! >>>>>> >>>>>> which does not give much help. >>>>>> >>>>>> Last lines in the mse describe beginning of a method >>>>>> >>>>>> (FAMIX.Method (id: 4318) >>>>>> (sourceAnchor (ref: 9706)) >>>>>> (parentType (ref: 3)) >>>>>> >>>>>> ref 9706 is '_unknown_path\_unknown_file' >>>>>> >>>>>> Any idea about how to debug? >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "It's not what we do that matters most, it's how we do it." >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Be rather willing to give than demanding to get." >>> >>> >>> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Obvious things are difficult to teach." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Fri Jan 1 16:41:10 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 1 Jan 2010 16:41:10 +0100 Subject: [Moose-dev] Re: Problem generating a mse with infusion In-Reply-To: <294AACB6-DE34-40AC-8FDA-2B04324DEAC8@usi.ch> References: <1432E431-E6BE-4E94-AB4A-B6C9D7C7648A@inria.fr> <35773E51-55A6-4E51-BF9E-955E6F82DC91@gmail.com> <3AA41B25-C541-43E6-94F6-585B0C504CBE@inria.fr> <65C7ECD3-6E7D-4F8A-9826-6AD09E730BB7@inria.fr> <1FDC8C04-14AD-4E24-873D-6DAE00C823F9@gmail.com> <294AACB6-DE34-40AC-8FDA-2B04324DEAC8@usi.ch> Message-ID: Yes Alexandre On 1 Jan 2010, at 16:17, Richard Wettel wrote: > Hi, > > Does it mean that inFusion works well with the latest Java release? > > Cheers, > Ricky > > On Dec 26, 2009, at 9:38 PM, Tudor Girba wrote: > >> Hi Simon, >> >> Indeed, it seems that the distribution has a problem. I tried on the >> development version. >> >> It looks like the latest inFusion does not have this problem anymore. >> >> Cheers, >> Doru >> >> >> On 26 Dec 2009, at 15:05, Simon Denier wrote: >> >>> >>> On 26 d?c. 2009, at 13:19, Tudor Girba wrote: >>> >>>> Hi Simon, >>>> >>>> It works fine on my computer. I am also using 7.2.6, but I did not >>>> update the JVM. >>> >>> >>> Apparently, it is a problem with my setup, I cant import java >>> projects anymore. Maybe it's a problem related with classpath or >>> related, but I dont remember changing my conf recently. >>> >>> When running through the infusion UI, I got this exception. Maybe >>> the line can give an indication about what it is looking for. >>> >>> --Export started-- >>> FAMIX 3.0 MSE Exporter could not be run ! >>> java.lang.NullPointerException >>> at >>> com >>> .intooitus >>> .infusion >>> .util.FAMIX30MSEExporter.visitMethod(FAMIX30MSEExporter.java:171) >>> >>> >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 26 Dec 2009, at 13:04, Simon Denier wrote: >>>> >>>>> >>>>> On 26 d?c. 2009, at 12:13, Tudor Girba wrote: >>>>> >>>>>> Hi Simon, >>>>>> >>>>>> Strange, that should not happen. I would need to see the sources >>>>>> to debug this. >>>>> >>>>> >>>>> Here you go. It compiles against Java 6 on Mac Os platform, but I >>>>> didnt install the latest release. >>>>> >>>>> Also I used infusion 7.2.6 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 26 Dec 2009, at 11:49, Simon Denier wrote: >>>>>> >>>>>>> Hi all >>>>>>> >>>>>>> I'm trying to generate a mse file for a java project with >>>>>>> infusion. >>>>>>> >>>>>>> It stops somewhere with this error: >>>>>>> Writing the MSE file for the path: /Users/deniersi/workspace/ >>>>>>> GecO/src >>>>>>> --Export started-- >>>>>>> MSE file generation aborted! >>>>>>> >>>>>>> which does not give much help. >>>>>>> >>>>>>> Last lines in the mse describe beginning of a method >>>>>>> >>>>>>> (FAMIX.Method (id: 4318) >>>>>>> (sourceAnchor (ref: 9706)) >>>>>>> (parentType (ref: 3)) >>>>>>> >>>>>>> ref 9706 is '_unknown_path\_unknown_file' >>>>>>> >>>>>>> Any idea about how to debug? >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "It's not what we do that matters most, it's how we do it." >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Be rather willing to give than demanding to get." >>>> >>>> >>>> >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From arififtikhar at gmail.com Mon Jan 4 09:49:58 2010 From: arififtikhar at gmail.com (Arif Iftikhar) Date: Mon, 4 Jan 2010 13:49:58 +0500 Subject: [Moose-dev] MSE File Parser Message-ID: <9af4151f1001040049x6887f80v3067c07948b916d4@mail.gmail.com> While loading MSE File in Moose i get the error attached. If i proceed it loads 0 entities in moose.Is there any special version of moose for such mse file. -- Thanks & Regards Arif Iftikhar -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: moose error.JPG Type: image/jpeg Size: 148261 bytes Desc: not available URL: From tudor.girba at gmail.com Mon Jan 4 12:20:10 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 4 Jan 2010 12:20:10 +0100 Subject: [Moose-dev] Re: MSE File Parser In-Reply-To: <9af4151f1001040049x6887f80v3067c07948b916d4@mail.gmail.com> References: <9af4151f1001040049x6887f80v3067c07948b916d4@mail.gmail.com> Message-ID: Hi Arif, It looks like the MSE that you give as input as an incorrect syntax. How did you obtain this MSE? Cheers, Doru On 4 Jan 2010, at 09:49, Arif Iftikhar wrote: > While loading MSE File in Moose i get the error attached. If i > proceed it loads 0 entities in moose.Is there any special version of > moose for such mse file. > > -- > Thanks & Regards > > Arif Iftikhar > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Value is always contextual." From Simon.Denier at inria.fr Mon Jan 4 13:06:34 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 4 Jan 2010 13:06:34 +0100 Subject: [Moose-dev] Re: Java exporter In-Reply-To: <6C904AD6-C6AE-411D-BB8A-E0D9EEC83CFF@dcc.uchile.cl> References: <716651510912292250sc292a67qf0f269f24d7a7444@mail.gmail.com> <6329F0A2-E0D6-4386-A8BA-E6FA4477B9B9@gmail.com> <6C904AD6-C6AE-411D-BB8A-E0D9EEC83CFF@dcc.uchile.cl> Message-ID: On 30 d?c. 2009, at 16:47, Johan Fabry wrote: > Hi all, > > I was just thinking about the Java import for moose, I am wondering how many people are using moose to analyze Java code. I think an interesting alternative to using infusion would be an Eclipse plugin that exports to mse-famix3. Is there any interest here for such a plugin? Johan Brichau is doing something *different* with eclipse: he can import eclipse project directly within moose (in VW). Porting under Pharo was in progress last time I heard of it. It might be interesting to exchange with him on the subject. > > On 30 Dec 2009, at 07:03, Tudor Girba wrote: > >> Hi, >> >> Here are the instructions: >> http://www.moosetechnology.org/docs/faq/importJavaWithinFusion >> >> Cheers, >> Doru >> >> >> On 30 Dec 2009, at 08:47, Laval Jannik wrote: >> >>> Hi Usman, >>> >>> You can use inFusion (http://www.intooitus.com/inFusion-tryit.html). >>> It allows us one to import in mse-famix2 for VW and in mse-famix3 for Pharo. >>> >>> Cheers, >>> Jannik >>> >>> On Dec 30, 2009, at 07:50 , Usman Bhatti wrote: >>> >>>> I am looking for a Java Exporter for Moose. Earlier I had tried IPlasma but I am getting some problems in its interface so I cannot use it. I also tried J2Moose but the format generated by the tool is not accepted by moose. Is there a Java exporter for moose that is compatible with the current MSE file format? >>>> >>>> thanx in advance, >>>> >>>> Usman >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Mon Jan 4 20:39:46 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 4 Jan 2010 20:39:46 +0100 Subject: [Moose-dev] Re: MSE File Parser In-Reply-To: <2d4c545a1001040702x470dd477t9c14562808ba3e30@mail.gmail.com> References: <9af4151f1001040049x6887f80v3067c07948b916d4@mail.gmail.com> <2d4c545a1001040702x470dd477t9c14562808ba3e30@mail.gmail.com> Message-ID: Hi, Please use the 4.0-beta.4 release of Moose. As it was mentioned in the announcement mail, this release solves the PrimitiveType problem. Cheers, Doru On 4 Jan 2010, at 16:02, Usman Bhatti wrote: > Hi Doru, > > I have similar problem here. I have generated an MSE file with > InFusion. Moose (moose-suite-4_0-beta.app) fails to load the file... > A bit of troubleshooting shows that moose is having a problem with > PrimitiveType expressions present in mse file. I removed them from > the generated file and it worked... > > I am sending you the problematic MSE file for bug replication > purposes... > > regards, > > > On Mon, Jan 4, 2010 at 4:20 PM, Tudor Girba > wrote: > Hi Arif, > > It looks like the MSE that you give as input as an incorrect syntax. > How did you obtain this MSE? > > Cheers, > Doru > > > > On 4 Jan 2010, at 09:49, Arif Iftikhar wrote: > > While loading MSE File in Moose i get the error attached. If i > proceed it loads 0 entities in moose.Is there any special version of > moose for such mse file. > > -- > Thanks & Regards > > Arif Iftikhar > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > > > > -- > Dr. Muhammad Usman Bhatti > Assistant Professor, FAST-NU LHR > Office MS-Block > Ext : 273 > -- www.tudorgirba.com "Sometimes the best solution is not the best solution." From marco.dambros at usi.ch Tue Jan 5 09:31:27 2010 From: marco.dambros at usi.ch (Marco D'Ambros) Date: Tue, 5 Jan 2010 09:31:27 +0100 Subject: [Moose-dev] Selection in Mondrian Message-ID: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> Hi, perhaps this is a naive question, but anyway: I was wondering if it is possible to select multiple figures in mondrian and if so, how to access the selection to spawn another view. thanks! Marco From jannik.laval at gmail.com Tue Jan 5 10:19:21 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Tue, 5 Jan 2010 10:19:21 +0100 Subject: [Moose-dev] Smalltalk importer bug Message-ID: Hi all, When I try to load packages Collection-Weak and Collection-Support, SmalltalkImporter have a bug on the character "_". Is there any way to fix this easily ? Cheers --- Jannik Laval --- From marco.dambros at usi.ch Tue Jan 5 15:39:09 2010 From: marco.dambros at usi.ch (Marco D'Ambros) Date: Tue, 5 Jan 2010 15:39:09 +0100 Subject: [Moose-dev] MOFormsBuilder Message-ID: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> Hi all, I am trying to understand how to use the MOForms builder in the following script in the context of a FAMIXClassGroup view shape rectangle height: [ :cls | cls numberOfMethods ]; width: [ :cls | cls numberOfAttributes ]; ]. view nodes: self entities forEach: [:each | | builder | view shape rectangle. builder := MOFormsBuilder new. builder column ; fill. builder row; fill ; row ; fill. builder x: 1 y: 1 add: MORectangleShape new. builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: view). view layout: builder asLayout. ]. view edges: self entities from: [ :cls | cls superclass ]. view treeLayout where the method #viewMethodsForClass:onView: is as follows: viewMethodsForClass: class onView: view view shape rectangle. ^view node: class forIt: [ view shape rectangle. view nodes: class methods. view gridLayout.] What I would like to get is, for each class, a composite figure with - a label on top - a composite figure where each subfigure represent a method Ideally the label and the composite should also be centrally aligned. However, with my script I get figure attached. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: mondrianFig.jpg Type: image/jpg Size: 49978 bytes Desc: not available URL: -------------- next part -------------- Marco From jfabry at dcc.uchile.cl Tue Jan 5 15:49:00 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 5 Jan 2010 11:49:00 -0300 Subject: [Moose-dev] Re: Glamour: Browser titles, selections, bug In-Reply-To: <62FCDE81-F5AC-4083-B58D-7D3CC379F783@gmail.com> References: <9594793B-2250-4EA4-A69E-FA9895C06A94@dcc.uchile.cl> <0F6C7167-EC99-4377-A871-8C47266D1B00@dcc.uchile.cl> <605F768D-F493-4A04-8E75-A846781046E3@inria.fr> <749201CF-83E7-4FB0-AD28-5B6B924A5A3E@dcc.uchile.cl> <62FCDE81-F5AC-4083-B58D-7D3CC379F783@gmail.com> Message-ID: Ok, this works for me. Thanks Doru! On 30 Dec 2009, at 20:34, Tudor Girba wrote: > Hi, > > The allowNil problem is solved in the latest Glamour-Core: > - allowNil always means that at least one origin port must be notNil > - otherwise, all must be notNil > > Cheers, > Doru -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From Simon.Denier at inria.fr Tue Jan 5 16:36:53 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 5 Jan 2010 16:36:53 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> Message-ID: <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> Hi Marcos Try this, it's a start: view nodes: self entities forEach: [:each | | builder | view shape rectangle text: [:e | e name]. builder := MOFormsBuilder new. builder column ; fill. builder row; fill ; row ; fill. builder x: 1 y: 1 add: (view node: each). builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: view). view layout: builder asLayout. ]. The most important thing is that #x:y:add: expects a MONode as last argument, that is you always have something like: builder x:1 y: 1 add: (view node: each) builder x:1 y: 1 add: (view nodes: nodes) builder x:1 y: 1 add: (view node: each forIt: ....) builder x:1 y: 1 add: (view nodes: each forEach: ...) and not builder x:1 y: 1 add: view shape rectangle.... MOFormsBuilder is a beast difficult to work with. Unfortunately it is often the solution for more complex layout (the other is embedding nodes in horizontal/vertical layouts). If someone comes with a better API, he is welcome. You can take a look at MOMatrixRenderer, which uses a FormsBuilder but with a specialized API for matrix. It shows how to work with FormsBuilder (and provide a better API for some task :) ) On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: > Hi all, > > I am trying to understand how to use the MOForms builder in the following script in the context of a FAMIXClassGroup > > view shape rectangle > height: [ :cls | cls numberOfMethods ]; > width: [ :cls | cls numberOfAttributes ]; > ]. > > view nodes: self entities forEach: [:each | | builder | > view shape rectangle. > > builder := MOFormsBuilder new. > builder column ; fill. > builder row; fill ; row ; fill. > builder x: 1 y: 1 add: MORectangleShape new. > builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). > builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: view). > > view layout: builder asLayout. > ]. > view > edges: self entities > from: [ :cls | cls superclass ]. > view treeLayout > > where the method #viewMethodsForClass:onView: is as follows: > > viewMethodsForClass: class onView: view > view shape rectangle. > ^view node: class forIt: [ > view shape rectangle. > view nodes: class methods. > view gridLayout.] > > > What I would like to get is, for each class, a composite figure with > - a label on top > - a composite figure where each subfigure represent a method > Ideally the label and the composite should also be centrally aligned. > > However, with my script I get figure attached. > > Thanks! > Marco > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Tue Jan 5 16:48:20 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 16:48:20 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> Message-ID: <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> Hi, It's incorrect to say that x:y:add: expects an MONode. FormsBuilder is supposed to be a generic algorithm for placing elements that have size in a grid that can be scaled both horizontally and vertically. In Mondrian it has two applications: 1. for building a complex shape. In this case x:y:add: accepts a Shape. You can see an example in UMLClassDiagram>>umlShape. You obtain the shape from the builder by sending #shape. 2. for laying out the nodes in a graph. This is achieved by passing MONodes in x:y:add: and by sending asLayout to the FormsBuilder and as you see in the MOMatrixRenderer. It appears to me that Marco wants the first solution. Cheers, Doru On 5 Jan 2010, at 16:36, Simon Denier wrote: > Hi Marcos > > Try this, it's a start: > > view nodes: self entities forEach: [:each | | builder | > view shape rectangle text: [:e | e name]. > > builder := MOFormsBuilder new. > builder column ; fill. > builder row; fill ; row ; fill. > builder x: 1 y: 1 add: (view node: each). > builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: > view). > > view layout: builder asLayout. > ]. > > > > The most important thing is that #x:y:add: expects a MONode as last > argument, that is you always have something like: > > builder x:1 y: 1 add: (view node: each) > builder x:1 y: 1 add: (view nodes: nodes) > builder x:1 y: 1 add: (view node: each forIt: ....) > builder x:1 y: 1 add: (view nodes: each forEach: ...) > > and not > builder x:1 y: 1 add: view shape rectangle.... > > > MOFormsBuilder is a beast difficult to work with. Unfortunately it > is often the solution for more complex layout (the other is > embedding nodes in horizontal/vertical layouts). If someone comes > with a better API, he is welcome. > You can take a look at MOMatrixRenderer, which uses a FormsBuilder > but with a specialized API for matrix. It shows how to work with > FormsBuilder (and provide a better API for some task :) ) > > > On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: > >> Hi all, >> >> I am trying to understand how to use the MOForms builder in the >> following script in the context of a FAMIXClassGroup >> >> view shape rectangle >> height: [ :cls | cls numberOfMethods ]; >> width: [ :cls | cls numberOfAttributes ]; >> ]. >> >> view nodes: self entities forEach: [:each | | builder | >> view shape rectangle. >> >> builder := MOFormsBuilder new. >> builder column ; fill. >> builder row; fill ; row ; fill. >> builder x: 1 y: 1 add: MORectangleShape new. >> builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). >> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >> view). >> >> view layout: builder asLayout. >> ]. >> view >> edges: self entities >> from: [ :cls | cls superclass ]. >> view treeLayout >> >> where the method #viewMethodsForClass:onView: is as follows: >> >> viewMethodsForClass: class onView: view >> view shape rectangle. >> ^view node: class forIt: [ >> view shape rectangle. >> view nodes: class methods. >> view gridLayout.] >> >> >> What I would like to get is, for each class, a composite figure with >> - a label on top >> - a composite figure where each subfigure represent a method >> Ideally the label and the composite should also be centrally aligned. >> >> However, with my script I get figure attached. >> >> Thanks! >> Marco >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Some battles are better lost than fought." From tudor.girba at gmail.com Tue Jan 5 16:51:28 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 16:51:28 +0100 Subject: [Moose-dev] call for projects Message-ID: Hi, I would like to update the list of tools around Moose that are present in Pharo. If you are working on such a tool, I would appreciate if you could send around the following info: - Project Name - Authors and Short Description - License - Monticello repository and loading script Cheers, Doru -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." From Simon.Denier at inria.fr Tue Jan 5 17:04:46 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 5 Jan 2010 17:04:46 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> Message-ID: OK then it should be described in the class comment, because I never remember and end up using the form I already used (the second). On 5 janv. 2010, at 16:48, Tudor Girba wrote: > Hi, > > It's incorrect to say that x:y:add: expects an MONode. > > FormsBuilder is supposed to be a generic algorithm for placing elements that have size in a grid that can be scaled both horizontally and vertically. > > In Mondrian it has two applications: > > 1. for building a complex shape. In this case x:y:add: accepts a Shape. You can see an example in UMLClassDiagram>>umlShape. You obtain the shape from the builder by sending #shape. > > 2. for laying out the nodes in a graph. This is achieved by passing MONodes in x:y:add: and by sending asLayout to the FormsBuilder and as you see in the MOMatrixRenderer. > > It appears to me that Marco wants the first solution. > > Cheers, > Doru > > > On 5 Jan 2010, at 16:36, Simon Denier wrote: > >> Hi Marcos >> >> Try this, it's a start: >> >> view nodes: self entities forEach: [:each | | builder | >> view shape rectangle text: [:e | e name]. >> >> builder := MOFormsBuilder new. >> builder column ; fill. >> builder row; fill ; row ; fill. >> builder x: 1 y: 1 add: (view node: each). >> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: view). >> >> view layout: builder asLayout. >> ]. >> >> >> >> The most important thing is that #x:y:add: expects a MONode as last argument, that is you always have something like: >> >> builder x:1 y: 1 add: (view node: each) >> builder x:1 y: 1 add: (view nodes: nodes) >> builder x:1 y: 1 add: (view node: each forIt: ....) >> builder x:1 y: 1 add: (view nodes: each forEach: ...) >> >> and not >> builder x:1 y: 1 add: view shape rectangle.... >> >> >> MOFormsBuilder is a beast difficult to work with. Unfortunately it is often the solution for more complex layout (the other is embedding nodes in horizontal/vertical layouts). If someone comes with a better API, he is welcome. >> You can take a look at MOMatrixRenderer, which uses a FormsBuilder but with a specialized API for matrix. It shows how to work with FormsBuilder (and provide a better API for some task :) ) >> >> >> On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: >> >>> Hi all, >>> >>> I am trying to understand how to use the MOForms builder in the following script in the context of a FAMIXClassGroup >>> >>> view shape rectangle >>> height: [ :cls | cls numberOfMethods ]; >>> width: [ :cls | cls numberOfAttributes ]; >>> ]. >>> >>> view nodes: self entities forEach: [:each | | builder | >>> view shape rectangle. >>> >>> builder := MOFormsBuilder new. >>> builder column ; fill. >>> builder row; fill ; row ; fill. >>> builder x: 1 y: 1 add: MORectangleShape new. >>> builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). >>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: view). >>> >>> view layout: builder asLayout. >>> ]. >>> view >>> edges: self entities >>> from: [ :cls | cls superclass ]. >>> view treeLayout >>> >>> where the method #viewMethodsForClass:onView: is as follows: >>> >>> viewMethodsForClass: class onView: view >>> view shape rectangle. >>> ^view node: class forIt: [ >>> view shape rectangle. >>> view nodes: class methods. >>> view gridLayout.] >>> >>> >>> What I would like to get is, for each class, a composite figure with >>> - a label on top >>> - a composite figure where each subfigure represent a method >>> Ideally the label and the composite should also be centrally aligned. >>> >>> However, with my script I get figure attached. >>> >>> Thanks! >>> Marco >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Tue Jan 5 17:15:08 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 17:15:08 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> Message-ID: Ok, I updated the comment. Cheers, Doru On 5 Jan 2010, at 17:04, Simon Denier wrote: > > OK then it should be described in the class comment, because I never > remember and end up using the form I already used (the second). > > > On 5 janv. 2010, at 16:48, Tudor Girba wrote: > >> Hi, >> >> It's incorrect to say that x:y:add: expects an MONode. >> >> FormsBuilder is supposed to be a generic algorithm for placing >> elements that have size in a grid that can be scaled both >> horizontally and vertically. >> >> In Mondrian it has two applications: >> >> 1. for building a complex shape. In this case x:y:add: accepts a >> Shape. You can see an example in UMLClassDiagram>>umlShape. You >> obtain the shape from the builder by sending #shape. >> >> 2. for laying out the nodes in a graph. This is achieved by passing >> MONodes in x:y:add: and by sending asLayout to the FormsBuilder and >> as you see in the MOMatrixRenderer. >> >> It appears to me that Marco wants the first solution. >> >> Cheers, >> Doru >> >> >> On 5 Jan 2010, at 16:36, Simon Denier wrote: >> >>> Hi Marcos >>> >>> Try this, it's a start: >>> >>> view nodes: self entities forEach: [:each | | builder | >>> view shape rectangle text: [:e | e name]. >>> >>> builder := MOFormsBuilder new. >>> builder column ; fill. >>> builder row; fill ; row ; fill. >>> builder x: 1 y: 1 add: (view node: each). >>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >>> view). >>> >>> view layout: builder asLayout. >>> ]. >>> >>> >>> >>> The most important thing is that #x:y:add: expects a MONode as >>> last argument, that is you always have something like: >>> >>> builder x:1 y: 1 add: (view node: each) >>> builder x:1 y: 1 add: (view nodes: nodes) >>> builder x:1 y: 1 add: (view node: each forIt: ....) >>> builder x:1 y: 1 add: (view nodes: each forEach: ...) >>> >>> and not >>> builder x:1 y: 1 add: view shape rectangle.... >>> >>> >>> MOFormsBuilder is a beast difficult to work with. Unfortunately it >>> is often the solution for more complex layout (the other is >>> embedding nodes in horizontal/vertical layouts). If someone comes >>> with a better API, he is welcome. >>> You can take a look at MOMatrixRenderer, which uses a FormsBuilder >>> but with a specialized API for matrix. It shows how to work with >>> FormsBuilder (and provide a better API for some task :) ) >>> >>> >>> On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: >>> >>>> Hi all, >>>> >>>> I am trying to understand how to use the MOForms builder in the >>>> following script in the context of a FAMIXClassGroup >>>> >>>> view shape rectangle >>>> height: [ :cls | cls numberOfMethods ]; >>>> width: [ :cls | cls numberOfAttributes ]; >>>> ]. >>>> >>>> view nodes: self entities forEach: [:each | | builder | >>>> view shape rectangle. >>>> >>>> builder := MOFormsBuilder new. >>>> builder column ; fill. >>>> builder row; fill ; row ; fill. >>>> builder x: 1 y: 1 add: MORectangleShape new. >>>> builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). >>>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >>>> view). >>>> >>>> view layout: builder asLayout. >>>> ]. >>>> view >>>> edges: self entities >>>> from: [ :cls | cls superclass ]. >>>> view treeLayout >>>> >>>> where the method #viewMethodsForClass:onView: is as follows: >>>> >>>> viewMethodsForClass: class onView: view >>>> view shape rectangle. >>>> ^view node: class forIt: [ >>>> view shape rectangle. >>>> view nodes: class methods. >>>> view gridLayout.] >>>> >>>> >>>> What I would like to get is, for each class, a composite figure >>>> with >>>> - a label on top >>>> - a composite figure where each subfigure represent a method >>>> Ideally the label and the composite should also be centrally >>>> aligned. >>>> >>>> However, with my script I get figure attached. >>>> >>>> Thanks! >>>> Marco >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We are all great at making mistakes." From stephane.ducasse at inria.fr Tue Jan 5 19:19:48 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 5 Jan 2010 19:19:48 +0100 Subject: [Moose-dev] Re: Smalltalk importer bug In-Reply-To: References: Message-ID: probably but what does it do? On Jan 5, 2010, at 10:19 AM, Laval Jannik wrote: > Hi all, > > When I try to load packages Collection-Weak and Collection-Support, SmalltalkImporter have a bug on the character "_". > Is there any way to fix this easily ? > > Cheers > > --- > Jannik Laval > --- > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Tue Jan 5 20:22:39 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 5 Jan 2010 16:22:39 -0300 Subject: [Moose-dev] Glamour: MNU on GLMPane>>notingPresentationChangeDo: Message-ID: Hi all, I did a ConfigurationOfGlamour loadDefault in a pretty fresh image (pharo 10502 + moose + aspectmaps) to get the latest bugfixes, and now I get a MNU. Cause is that (GLMPresentationsChanged new) returns AnObsoleteGLMPresentationsChanged. I guess something went wrong in the load. How do I fix this ? -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From jannik.laval at gmail.com Tue Jan 5 20:42:02 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Tue, 5 Jan 2010 20:42:02 +0100 Subject: [Moose-dev] Re: Smalltalk importer bug In-Reply-To: References: Message-ID: marcus answers: In system>Settings>Compiler there is a "allow underscore as assignment". So, this is not a bug of SmalltalkImporter. Cheers, Jannik On Jan 5, 2010, at 19:19 , St?phane Ducasse wrote: > probably but what does it do? > > On Jan 5, 2010, at 10:19 AM, Laval Jannik wrote: > >> Hi all, >> >> When I try to load packages Collection-Weak and Collection-Support, SmalltalkImporter have a bug on the character "_". >> Is there any way to fix this easily ? >> >> Cheers >> >> --- >> Jannik Laval >> --- >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Tue Jan 5 23:37:11 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 23:37:11 +0100 Subject: [Moose-dev] Re: Selection in Mondrian In-Reply-To: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> References: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> Message-ID: Hi Marco, Right now, there is no support for multiple selection in Mondrian :(. However, it should not be difficult to add :). For dealing with interaction between multiple views, I suggest to use Glamour. You can find examples by browsing: GLMBasicExamples browseExamples A Mondrian specific example can be found in: GLMBasicExamples>>simpleMondrianPainting (you have to update to the latest Glamour-Examples first) Cheers, Doru On 5 Jan 2010, at 09:31, Marco D'Ambros wrote: > Hi, > > perhaps this is a naive question, but anyway: I was wondering if it > is possible to select multiple figures in mondrian and if so, how to > access the selection to spawn another view. > > thanks! > Marco > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Don't give to get. Just give." From marco.dambros at usi.ch Tue Jan 5 23:46:58 2010 From: marco.dambros at usi.ch (Marco D'Ambros) Date: Tue, 5 Jan 2010 23:46:58 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> Message-ID: <8110C774-FB13-4553-8CA1-A02FB31AAE3E@usi.ch> Hi, On Jan 5, 2010, at 4:48 PM, Tudor Girba wrote: > Hi, > > It's incorrect to say that x:y:add: expects an MONode. > > FormsBuilder is supposed to be a generic algorithm for placing > elements that have size in a grid that can be scaled both horizontally > and vertically. > > In Mondrian it has two applications: > > 1. for building a complex shape. In this case x:y:add: accepts a > Shape. You can see an example in UMLClassDiagram>>umlShape. You obtain > the shape from the builder by sending #shape. > > 2. for laying out the nodes in a graph. This is achieved by passing > MONodes in x:y:add: and by sending asLayout to the FormsBuilder and as > you see in the MOMatrixRenderer. > > It appears to me that Marco wants the first solution. Yes, I was trying to create a complex shape and indeed I took inspiration from #umlShape ;) Cheers, Marco > > Cheers, > Doru > > > On 5 Jan 2010, at 16:36, Simon Denier wrote: > >> Hi Marcos >> >> Try this, it's a start: >> >> view nodes: self entities forEach: [:each | | builder | >> view shape rectangle text: [:e | e name]. >> >> builder := MOFormsBuilder new. >> builder column ; fill. >> builder row; fill ; row ; fill. >> builder x: 1 y: 1 add: (view node: each). >> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >> view). >> >> view layout: builder asLayout. >> ]. >> >> >> >> The most important thing is that #x:y:add: expects a MONode as last >> argument, that is you always have something like: >> >> builder x:1 y: 1 add: (view node: each) >> builder x:1 y: 1 add: (view nodes: nodes) >> builder x:1 y: 1 add: (view node: each forIt: ....) >> builder x:1 y: 1 add: (view nodes: each forEach: ...) >> >> and not >> builder x:1 y: 1 add: view shape rectangle.... >> >> >> MOFormsBuilder is a beast difficult to work with. Unfortunately it >> is often the solution for more complex layout (the other is >> embedding nodes in horizontal/vertical layouts). If someone comes >> with a better API, he is welcome. >> You can take a look at MOMatrixRenderer, which uses a FormsBuilder >> but with a specialized API for matrix. It shows how to work with >> FormsBuilder (and provide a better API for some task :) ) >> >> >> On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: >> >>> Hi all, >>> >>> I am trying to understand how to use the MOForms builder in the >>> following script in the context of a FAMIXClassGroup >>> >>> view shape rectangle >>> height: [ :cls | cls numberOfMethods ]; >>> width: [ :cls | cls numberOfAttributes ]; >>> ]. >>> >>> view nodes: self entities forEach: [:each | | builder | >>> view shape rectangle. >>> >>> builder := MOFormsBuilder new. >>> builder column ; fill. >>> builder row; fill ; row ; fill. >>> builder x: 1 y: 1 add: MORectangleShape new. >>> builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). >>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >>> view). >>> >>> view layout: builder asLayout. >>> ]. >>> view >>> edges: self entities >>> from: [ :cls | cls superclass ]. >>> view treeLayout >>> >>> where the method #viewMethodsForClass:onView: is as follows: >>> >>> viewMethodsForClass: class onView: view >>> view shape rectangle. >>> ^view node: class forIt: [ >>> view shape rectangle. >>> view nodes: class methods. >>> view gridLayout.] >>> >>> >>> What I would like to get is, for each class, a composite figure with >>> - a label on top >>> - a composite figure where each subfigure represent a method >>> Ideally the label and the composite should also be centrally aligned. >>> >>> However, with my script I get figure attached. >>> >>> Thanks! >>> Marco >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Some battles are better lost than fought." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From marco.dambros at usi.ch Tue Jan 5 23:48:15 2010 From: marco.dambros at usi.ch (Marco D'Ambros) Date: Tue, 5 Jan 2010 23:48:15 +0100 Subject: [Moose-dev] Re: Selection in Mondrian In-Reply-To: References: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> Message-ID: That's cool, I will definitely play with Glamour then. cheers, Marco On Jan 5, 2010, at 11:37 PM, Tudor Girba wrote: > Hi Marco, > > Right now, there is no support for multiple selection in Mondrian :(. > However, it should not be difficult to add :). > > For dealing with interaction between multiple views, I suggest to use > Glamour. You can find examples by browsing: > GLMBasicExamples browseExamples > > A Mondrian specific example can be found in: > GLMBasicExamples>>simpleMondrianPainting (you have to update to the > latest Glamour-Examples first) > > Cheers, > Doru > > > On 5 Jan 2010, at 09:31, Marco D'Ambros wrote: > >> Hi, >> >> perhaps this is a naive question, but anyway: I was wondering if it >> is possible to select multiple figures in mondrian and if so, how to >> access the selection to spawn another view. >> >> thanks! >> Marco >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Tue Jan 5 23:51:57 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 23:51:57 +0100 Subject: [Moose-dev] Re: MOFormsBuilder In-Reply-To: <8110C774-FB13-4553-8CA1-A02FB31AAE3E@usi.ch> References: <81064AD2-57B4-4E8E-AD67-6A168907A480@usi.ch> <158048C2-843A-4726-9974-84BC16E8A2B2@inria.fr> <5FD3451E-7042-4EA6-842F-997731FE206F@gmail.com> <8110C774-FB13-4553-8CA1-A02FB31AAE3E@usi.ch> Message-ID: <566DCE77-37DF-47B1-9665-30223DCB1BE7@gmail.com> Hi, Do you still have problems? Cheers, Doru On 5 Jan 2010, at 23:46, Marco D'Ambros wrote: > Hi, > > > On Jan 5, 2010, at 4:48 PM, Tudor Girba wrote: > >> Hi, >> >> It's incorrect to say that x:y:add: expects an MONode. >> >> FormsBuilder is supposed to be a generic algorithm for placing >> elements that have size in a grid that can be scaled both >> horizontally >> and vertically. >> >> In Mondrian it has two applications: >> >> 1. for building a complex shape. In this case x:y:add: accepts a >> Shape. You can see an example in UMLClassDiagram>>umlShape. You >> obtain >> the shape from the builder by sending #shape. >> >> 2. for laying out the nodes in a graph. This is achieved by passing >> MONodes in x:y:add: and by sending asLayout to the FormsBuilder and >> as >> you see in the MOMatrixRenderer. >> >> It appears to me that Marco wants the first solution. > > Yes, I was trying to create a complex shape and indeed I took > inspiration from #umlShape ;) > > Cheers, > Marco > >> >> Cheers, >> Doru >> >> >> On 5 Jan 2010, at 16:36, Simon Denier wrote: >> >>> Hi Marcos >>> >>> Try this, it's a start: >>> >>> view nodes: self entities forEach: [:each | | builder | >>> view shape rectangle text: [:e | e name]. >>> >>> builder := MOFormsBuilder new. >>> builder column ; fill. >>> builder row; fill ; row ; fill. >>> builder x: 1 y: 1 add: (view node: each). >>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >>> view). >>> >>> view layout: builder asLayout. >>> ]. >>> >>> >>> >>> The most important thing is that #x:y:add: expects a MONode as last >>> argument, that is you always have something like: >>> >>> builder x:1 y: 1 add: (view node: each) >>> builder x:1 y: 1 add: (view nodes: nodes) >>> builder x:1 y: 1 add: (view node: each forIt: ....) >>> builder x:1 y: 1 add: (view nodes: each forEach: ...) >>> >>> and not >>> builder x:1 y: 1 add: view shape rectangle.... >>> >>> >>> MOFormsBuilder is a beast difficult to work with. Unfortunately it >>> is often the solution for more complex layout (the other is >>> embedding nodes in horizontal/vertical layouts). If someone comes >>> with a better API, he is welcome. >>> You can take a look at MOMatrixRenderer, which uses a FormsBuilder >>> but with a specialized API for matrix. It shows how to work with >>> FormsBuilder (and provide a better API for some task :) ) >>> >>> >>> On 5 janv. 2010, at 15:39, Marco D'Ambros wrote: >>> >>>> Hi all, >>>> >>>> I am trying to understand how to use the MOForms builder in the >>>> following script in the context of a FAMIXClassGroup >>>> >>>> view shape rectangle >>>> height: [ :cls | cls numberOfMethods ]; >>>> width: [ :cls | cls numberOfAttributes ]; >>>> ]. >>>> >>>> view nodes: self entities forEach: [:each | | builder | >>>> view shape rectangle. >>>> >>>> builder := MOFormsBuilder new. >>>> builder column ; fill. >>>> builder row; fill ; row ; fill. >>>> builder x: 1 y: 1 add: MORectangleShape new. >>>> builder x: 1 y: 1 add: (MOLabelShape new text: [ :e | e name ]). >>>> builder x: 1 y: 2 add: (self viewMethodsForClass: each onView: >>>> view). >>>> >>>> view layout: builder asLayout. >>>> ]. >>>> view >>>> edges: self entities >>>> from: [ :cls | cls superclass ]. >>>> view treeLayout >>>> >>>> where the method #viewMethodsForClass:onView: is as follows: >>>> >>>> viewMethodsForClass: class onView: view >>>> view shape rectangle. >>>> ^view node: class forIt: [ >>>> view shape rectangle. >>>> view nodes: class methods. >>>> view gridLayout.] >>>> >>>> >>>> What I would like to get is, for each class, a composite figure >>>> with >>>> - a label on top >>>> - a composite figure where each subfigure represent a method >>>> Ideally the label and the composite should also be centrally >>>> aligned. >>>> >>>> However, with my script I get figure attached. >>>> >>>> Thanks! >>>> Marco >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Some battles are better lost than fought." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." From tudor.girba at gmail.com Tue Jan 5 23:54:08 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 5 Jan 2010 23:54:08 +0100 Subject: [Moose-dev] Re: Selection in Mondrian In-Reply-To: References: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> Message-ID: <77D8EDF0-DA5A-4D01-AE86-D41BCEDDC74F@gmail.com> You can get a short introductory tutorial at: http://www.tudorgirba.com/blog/glimpse-of-glamour Cheers, Doru On 5 Jan 2010, at 23:48, Marco D'Ambros wrote: > That's cool, I will definitely play with Glamour then. > > cheers, > Marco > > > On Jan 5, 2010, at 11:37 PM, Tudor Girba wrote: > >> Hi Marco, >> >> Right now, there is no support for multiple selection in Mondrian :(. >> However, it should not be difficult to add :). >> >> For dealing with interaction between multiple views, I suggest to use >> Glamour. You can find examples by browsing: >> GLMBasicExamples browseExamples >> >> A Mondrian specific example can be found in: >> GLMBasicExamples>>simpleMondrianPainting (you have to update to the >> latest Glamour-Examples first) >> >> Cheers, >> Doru >> >> >> On 5 Jan 2010, at 09:31, Marco D'Ambros wrote: >> >>> Hi, >>> >>> perhaps this is a naive question, but anyway: I was wondering if it >>> is possible to select multiple figures in mondrian and if so, how to >>> access the selection to spawn another view. >>> >>> thanks! >>> Marco >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Don't give to get. Just give." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Reasonable is what we are accustomed with." From Simon.Denier at inria.fr Wed Jan 6 15:16:51 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 15:16:51 +0100 Subject: [Moose-dev] Mondrian: Padding within a shape Message-ID: Hi there Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? thanks in advance -- Simon From alexandre at bergel.eu Wed Jan 6 16:08:47 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 12:08:47 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: References: Message-ID: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> I am not sure to understand. It does not work using node:forIt: ? Alexandre On 6 Jan 2010, at 11:16, Simon Denier wrote: > > Hi there > > Is there a way to add some padding around the text inside a shape > (for example, inside a MORectangleShape)? > > thanks in advance > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Wed Jan 6 16:12:31 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 12:12:31 -0300 Subject: [Moose-dev] Re: Selection in Mondrian In-Reply-To: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> References: <8B15EAEC-57E0-4606-8AA3-960C1EDE5570@usi.ch> Message-ID: <3F38E1D9-5AE3-44E1-BFCE-B0D16ADDFB78@bergel.eu> Multiple selection is on my todo list for some times already. My time allocated for Mondrian was essentially filled with bug fixes and highly-wanted features. I will work on this soon. Alexandre On 5 Jan 2010, at 05:31, Marco D'Ambros wrote: > Hi, > > perhaps this is a naive question, but anyway: I was wondering if it > is possible to select multiple figures in mondrian and if so, how to > access the selection to spawn another view. > > thanks! > Marco > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From cy.delaunay at gmail.com Wed Jan 6 16:19:02 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Wed, 6 Jan 2010 16:19:02 +0100 Subject: [Moose-dev] How to have the number of lines of code of a C file Message-ID: Hi, I would like to retrieve the number of lines of code of a file when importing C code in moose. Here is what I do once the code loaded in moose: - I inspect a FAMIXFile from the MooseFinder -> when printing 'self numberOfLinesOfText' , it returns '0' (while the corresponding file is not empty). This is my first problem, - Then, I try to retrieve the object CAImplementation (from CAnalyzer) correspondind by inspecting 'self entities first' (is it the good way?) -> when printing 'self numberOfLinesOfText', it returns '-1' (-> even if I inspect directly a CAImplementation object from the moose finder, it returns -1) So is there somethings wrong or is the problem coming from the xml files generated bu srcml? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Wed Jan 6 16:21:39 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 16:21:39 +0100 Subject: [Moose-dev] Re: call for projects In-Reply-To: References: Message-ID: On 5 janv. 2010, at 16:51, Tudor Girba wrote: > Hi, > > I would like to update the list of tools around Moose that are present in Pharo. > > If you are working on such a tool, I would appreciate if you could send around the following info: > - Project Name > - Authors and Short Description > - License > - Monticello repository and loading script Hi Doru, here are the projects I am involved in (except Moose itself :)) CAnalyzer Alexandre Bergel, Simon Denier C programs analysis and visualization No license yet http://www.squeaksource.com/CAnalyzer Aspix / AspectMaps Johan Fabry, Simon Denier, Andy Kellens Famix extension for AspectJ metamodel / aspect visualization No license yet http://www.squeaksource.com/AspectMaps Moqam Simon Denier, Jannik Laval, Karine Mordal-Manet MOose QuAlity Model, research vehicle for our work with Squale http://www.squale.org/ No license yet http://www.squeaksource.com/moqam There is also DSM and Orion, but Jannik is doing the hard work on those :) DSM Jannik Laval (main author), Simon Denier Analysis and visualizations of cyclic dependencies between packages BSD license http://www.squeaksource.com/dsm Orion Jannik Laval (main author) and Simon Denier Interactive prospection of code changes No license yet http://www.squeaksource.com/Orion -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Wed Jan 6 16:39:58 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 16:39:58 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: Message-ID: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> On 6 janv. 2010, at 16:19, Cyrille Delaunay wrote: > Hi, > > I would like to retrieve the number of lines of code of a file when importing C code in moose. Here is what I do once the code loaded in moose: Isn't there a numberOfLinesOfCode on CAImplementation? And it's easy to define a redirection from FamixFile to CAImplementation (there is a 1-1 relationship) > > - I inspect a FAMIXFile from the MooseFinder > -> when printing 'self numberOfLinesOfText' , it returns '0' (while the corresponding file is not empty). This is my first problem, > - Then, I try to retrieve the object CAImplementation (from CAnalyzer) correspondind by inspecting 'self entities first' (is it the good way?) > -> when printing 'self numberOfLinesOfText', it returns '-1' > (-> even if I inspect directly a CAImplementation object from the moose finder, it returns -1) > > So is there somethings wrong or is the problem coming from the xml files generated bu srcml? > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From Simon.Denier at inria.fr Wed Jan 6 16:42:19 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 16:42:19 +0100 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> Message-ID: <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: > I am not sure to understand. > It does not work using node:forIt: ? I dont know, but if I can avoid the extra complexity of embedding a node into another, that's good. It could be in the shape, then the shape knows how much extra space it adds around its content. > > Alexandre > > > On 6 Jan 2010, at 11:16, Simon Denier wrote: > >> >> Hi there >> >> Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? >> >> thanks in advance >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From cy.delaunay at gmail.com Wed Jan 6 16:48:54 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Wed, 6 Jan 2010 16:48:54 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: 2010/1/6 Simon Denier > > On 6 janv. 2010, at 16:19, Cyrille Delaunay wrote: > > > Hi, > > > > I would like to retrieve the number of lines of code of a file when > importing C code in moose. Here is what I do once the code loaded in moose: > > > Isn't there a numberOfLinesOfCode on CAImplementation? > > And it's easy to define a redirection from FamixFile to CAImplementation > (there is a 1-1 relationship) > Yes, it is what I do , but it doesn't return me what I expect (see below, the end of the mail) > > > > > > - I inspect a FAMIXFile from the MooseFinder > > -> when printing 'self numberOfLinesOfText' , it returns '0' > (while the corresponding file is not empty). This is my first problem, > > - Then, I try to retrieve the object CAImplementation (from CAnalyzer) > correspondind by inspecting 'self entities first' (is it the good way?) > > -> when printing 'self numberOfLinesOfText', it returns '-1' > > (-> even if I inspect directly a CAImplementation object from the > moose finder, it returns -1) > > > > So is there somethings wrong or is the problem coming from the xml files > generated bu srcml? > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev at iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfabry at dcc.uchile.cl Wed Jan 6 16:51:25 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 6 Jan 2010 12:51:25 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> Message-ID: <70ED968C-3A20-4939-BC8F-C853A4811B96@dcc.uchile.cl> +1 on this. On 06 Jan 2010, at 12:42, Simon Denier wrote: > > On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: > >> I am not sure to understand. >> It does not work using node:forIt: ? > > > I dont know, but if I can avoid the extra complexity of embedding a > node into another, that's good. It could be in the shape, then the > shape knows how much extra space it adds around its content. > > > >> >> Alexandre >> >> >> On 6 Jan 2010, at 11:16, Simon Denier wrote: >> >>> >>> Hi there >>> >>> Is there a way to add some padding around the text inside a shape >>> (for example, inside a MORectangleShape)? >>> >>> thanks in advance >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From alexandre at bergel.eu Wed Jan 6 16:58:33 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 12:58:33 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> Message-ID: <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> You can easy add space character before and after. You can also set a height: and a width: bigger than the text. Alexandre On 6 Jan 2010, at 12:42, Simon Denier wrote: > > On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: > >> I am not sure to understand. >> It does not work using node:forIt: ? > > > I dont know, but if I can avoid the extra complexity of embedding a > node into another, that's good. It could be in the shape, then the > shape knows how much extra space it adds around its content. > > > >> >> Alexandre >> >> >> On 6 Jan 2010, at 11:16, Simon Denier wrote: >> >>> >>> Hi there >>> >>> Is there a way to add some padding around the text inside a shape >>> (for example, inside a MORectangleShape)? >>> >>> thanks in advance >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Wed Jan 6 17:09:46 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 17:09:46 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: On 6 janv. 2010, at 16:48, Cyrille Delaunay wrote: > > > 2010/1/6 Simon Denier > > On 6 janv. 2010, at 16:19, Cyrille Delaunay wrote: > > > Hi, > > > > I would like to retrieve the number of lines of code of a file when importing C code in moose. Here is what I do once the code loaded in moose: > > > Isn't there a numberOfLinesOfCode on CAImplementation? > > And it's easy to define a redirection from FamixFile to CAImplementation (there is a 1-1 relationship) > > Yes, it is what I do , but it doesn't return me what I expect (see below, the end of the mail) I didnt check, but I think that CAnalyzer needs to access the source and xml files to compute lines of code. How did you import your model? Where is it on disk? Did you generate new xml files or use old ones? > > > > > > - I inspect a FAMIXFile from the MooseFinder > > -> when printing 'self numberOfLinesOfText' , it returns '0' (while the corresponding file is not empty). This is my first problem, > > - Then, I try to retrieve the object CAImplementation (from CAnalyzer) correspondind by inspecting 'self entities first' (is it the good way?) > > -> when printing 'self numberOfLinesOfText', it returns '-1' > > (-> even if I inspect directly a CAImplementation object from the moose finder, it returns -1) > > > > So is there somethings wrong or is the problem coming from the xml files generated bu srcml? > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev at iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From cy.delaunay at gmail.com Wed Jan 6 17:20:42 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Wed, 6 Jan 2010 17:20:42 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: 2010/1/6 Simon Denier > > On 6 janv. 2010, at 16:48, Cyrille Delaunay wrote: > > > > 2010/1/6 Simon Denier > >> >> On 6 janv. 2010, at 16:19, Cyrille Delaunay wrote: >> >> > Hi, >> > >> > I would like to retrieve the number of lines of code of a file when >> importing C code in moose. Here is what I do once the code loaded in moose: >> >> >> Isn't there a numberOfLinesOfCode on CAImplementation? >> >> And it's easy to define a redirection from FamixFile to CAImplementation >> (there is a 1-1 relationship) >> > > Yes, it is what I do , but it doesn't return me what I expect (see below, > the end of the mail) > > > > I didnt check, but I think that CAnalyzer needs to access the source and > xml files to compute lines of code. How did you import your model? Where is > it on disk? Did you generate new xml files or use old ones? > I used the old ones about Linux kernel . I retrieved it from lse svn > > > >> >> > >> > - I inspect a FAMIXFile from the MooseFinder >> > -> when printing 'self numberOfLinesOfText' , it returns '0' >> (while the corresponding file is not empty). This is my first problem, >> > - Then, I try to retrieve the object CAImplementation (from CAnalyzer) >> correspondind by inspecting 'self entities first' (is it the good way?) >> > -> when printing 'self numberOfLinesOfText', it returns '-1' >> > (-> even if I inspect directly a CAImplementation object from the >> moose finder, it returns -1) >> > >> > So is there somethings wrong or is the problem coming from the xml files >> generated bu srcml? >> > >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev at iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Wed Jan 6 17:32:18 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 17:32:18 +0100 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> Message-ID: <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: > You can easy add space character before and after. You can also set a height: and a width: bigger than the text. Yep height: [:model | model name..... ] but how I can compute the text width and height? There are textWidthFor: and textHeightFor: but those are internal methods. > > Alexandre > > > On 6 Jan 2010, at 12:42, Simon Denier wrote: > >> >> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >> >>> I am not sure to understand. >>> It does not work using node:forIt: ? >> >> >> I dont know, but if I can avoid the extra complexity of embedding a node into another, that's good. It could be in the shape, then the shape knows how much extra space it adds around its content. >> >> >> >>> >>> Alexandre >>> >>> >>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>> >>>> >>>> Hi there >>>> >>>> Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? >>>> >>>> thanks in advance >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From alexandre at bergel.eu Wed Jan 6 17:56:58 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 13:56:58 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> Message-ID: Just to make sure that I fully understand, you want to have the effect of the second node, without nesting it? view shape rectangle withText. view node: 'hello world!'. view node: #foo forIt: [ view shape label. view interaction forwarder. view node: 'hello world!'. ] Something like: view shape label padding: 5. view node: 'hello world!'. ? Alexandre On 6 Jan 2010, at 13:32, Simon Denier wrote: > > On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: > >> You can easy add space character before and after. You can also set >> a height: and a width: bigger than the text. > > Yep > > height: [:model | model name..... ] > > but how I can compute the text width and height? There are > textWidthFor: and textHeightFor: but those are internal methods. > > >> >> Alexandre >> >> >> On 6 Jan 2010, at 12:42, Simon Denier wrote: >> >>> >>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>> >>>> I am not sure to understand. >>>> It does not work using node:forIt: ? >>> >>> >>> I dont know, but if I can avoid the extra complexity of embedding >>> a node into another, that's good. It could be in the shape, then >>> the shape knows how much extra space it adds around its content. >>> >>> >>> >>>> >>>> Alexandre >>>> >>>> >>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>> >>>>> >>>>> Hi there >>>>> >>>>> Is there a way to add some padding around the text inside a >>>>> shape (for example, inside a MORectangleShape)? >>>>> >>>>> thanks in advance >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Wed Jan 6 20:40:26 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 16:40:26 -0300 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: > I didnt check, but I think that CAnalyzer needs to access the source > and xml files to compute lines of code. How did you import your > model? Where is it on disk? Did you generate new xml files or use > old ones? No, you do not need the original source code for computing the lines of code. There is a bijection between srcML XML files and original source code. This is a great strenght of srcML. Cyrille, did you solve the problem? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Wed Jan 6 20:44:11 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 6 Jan 2010 16:44:11 -0300 Subject: [Moose-dev] Re: call for projects In-Reply-To: References: Message-ID: <762F109A-A09E-4F7E-9624-3E3FB39D607B@bergel.eu> For me: Project name: Adore Authors: Alexandre Bergel & Sebastien Mosser Short description: Activity moDel suppOrting oRchestration Evolution (www.adore-design.org ) Loading script: Gofer new squeaksource: 'Adore'; addPackage: 'ConfigurationOfAdore'; load. (Smalltalk at: #ConfigurationOfAdore) perform: #loadDefault License: MIT Project name: ProcessModel Authors: Julio Hurtado, Alexandre Bergel Short description: Importing SPEM specified process models in Moose Loading script: Gofer new squeaksource: 'ProcessModel'; addPackage: 'ConfigurationOfProcessModel'; load. (Smalltalk at: #ConfigurationOfProcessModel) perform: #loadDefault License: MIT Cheers, Alexandre On 5 Jan 2010, at 12:51, Tudor Girba wrote: > Hi, > > I would like to update the list of tools around Moose that are > present in Pharo. > > If you are working on such a tool, I would appreciate if you could > send around the following info: > - Project Name > - Authors and Short Description > - License > - Monticello repository and loading script > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that > happen. They both matter." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jfabry at dcc.uchile.cl Wed Jan 6 21:01:39 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 6 Jan 2010 17:01:39 -0300 Subject: [Moose-dev] Gofer install warning Message-ID: <1E9C0A70-B5B2-4C30-9334-A19EF9E19991@dcc.uchile.cl> Hi all, rebuilding a new image from scratch... Loading Moose using the code on the website in the 'Install from Monticello' page. This gives me 2 warnings that addPackage: has been replaced by package: It would be nice to clean that up. Reported as issue 274 http://code.google.com/p/moose-technology/issues/detail?id=274&colspec=ID%20Status%20Summary%20Owner%20Type%20Opened%20Modified%20Milestone%20Component%20Reporter -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From jannik.laval at gmail.com Wed Jan 6 21:45:48 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Wed, 6 Jan 2010 21:45:48 +0100 Subject: [Moose-dev] Re: Gofer install warning In-Reply-To: <1E9C0A70-B5B2-4C30-9334-A19EF9E19991@dcc.uchile.cl> References: <1E9C0A70-B5B2-4C30-9334-A19EF9E19991@dcc.uchile.cl> Message-ID: <53912CD4-E1E3-4A6B-8DC1-60404288BC41@gmail.com> Hi Johan, It is fixed in ConfigurationOfMoose-jannik_laval.52 Cheers, Jannik On Jan 6, 2010, at 21:01 , Johan Fabry wrote: > Hi all, > > rebuilding a new image from scratch... Loading Moose using the code on the website in the 'Install from Monticello' page. This gives me 2 warnings that addPackage: has been replaced by package: It would be nice to clean that up. > > Reported as issue 274 http://code.google.com/p/moose-technology/issues/detail?id=274&colspec=ID%20Status%20Summary%20Owner%20Type%20Opened%20Modified%20Milestone%20Component%20Reporter > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Jannik Laval --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Wed Jan 6 22:07:34 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 6 Jan 2010 22:07:34 +0100 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> Message-ID: On 6 janv. 2010, at 17:56, Alexandre Bergel wrote: > Just to make sure that I fully understand, you want to have the effect of the second node, without nesting it? > > view shape rectangle withText. > view node: 'hello world!'. > > view node: #foo forIt: [ > view shape label. > view interaction forwarder. > view node: 'hello world!'. > ] Yes, exactly, this gives the visual effect I want. > > Something like: > view shape label padding: 5. > view node: 'hello world!'. yes, this the code I want to write (at least in simple case like a Shape which can have a label) also view shape rectangle padding: 5; text: 'hello world!'. view node: #hello > ? > > Alexandre > > > On 6 Jan 2010, at 13:32, Simon Denier wrote: > >> >> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: >> >>> You can easy add space character before and after. You can also set a height: and a width: bigger than the text. >> >> Yep >> >> height: [:model | model name..... ] >> >> but how I can compute the text width and height? There are textWidthFor: and textHeightFor: but those are internal methods. >> >> >>> >>> Alexandre >>> >>> >>> On 6 Jan 2010, at 12:42, Simon Denier wrote: >>> >>>> >>>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>>> >>>>> I am not sure to understand. >>>>> It does not work using node:forIt: ? >>>> >>>> >>>> I dont know, but if I can avoid the extra complexity of embedding a node into another, that's good. It could be in the shape, then the shape knows how much extra space it adds around its content. >>>> >>>> >>>> >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>>> >>>>>> >>>>>> Hi there >>>>>> >>>>>> Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? >>>>>> >>>>>> thanks in advance >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From jfabry at dcc.uchile.cl Wed Jan 6 22:26:53 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 6 Jan 2010 18:26:53 -0300 Subject: [Moose-dev] Re: Gofer install warning In-Reply-To: <53912CD4-E1E3-4A6B-8DC1-60404288BC41@gmail.com> References: <1E9C0A70-B5B2-4C30-9334-A19EF9E19991@dcc.uchile.cl> <53912CD4-E1E3-4A6B-8DC1-60404288BC41@gmail.com> Message-ID: <8FEE614E-9EA9-4870-B07D-791DD716D735@dcc.uchile.cl> Great, however the website should also be updated, because the code there uses addPackage: (I reopened the bugreport). On 06 Jan 2010, at 17:45, Laval Jannik wrote: > Hi Johan, > > It is fixed in ConfigurationOfMoose-jannik_laval.52 > > Cheers, > Jannik > > On Jan 6, 2010, at 21:01 , Johan Fabry wrote: > >> Hi all, >> >> rebuilding a new image from scratch... Loading Moose using the code >> on the website in the 'Install from Monticello' page. This gives me >> 2 warnings that addPackage: has been replaced by package: It would >> be nice to clean that up. >> >> Reported as issue 274 http://code.google.com/p/moose-technology/issues/detail?id=274&colspec=ID%20Status%20Summary%20Owner%20Type%20Opened%20Modified%20Milestone%20Component%20Reporter >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > --- > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor.girba at gmail.com Thu Jan 7 00:35:02 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 00:35:02 +0100 Subject: [Moose-dev] Re: Gofer install warning In-Reply-To: <8FEE614E-9EA9-4870-B07D-791DD716D735@dcc.uchile.cl> References: <1E9C0A70-B5B2-4C30-9334-A19EF9E19991@dcc.uchile.cl> <53912CD4-E1E3-4A6B-8DC1-60404288BC41@gmail.com> <8FEE614E-9EA9-4870-B07D-791DD716D735@dcc.uchile.cl> Message-ID: I updated the webpage. Cheers, Doru On 6 Jan 2010, at 22:26, Johan Fabry wrote: > > Great, however the website should also be updated, because the code > there uses addPackage: (I reopened the bugreport). > > On 06 Jan 2010, at 17:45, Laval Jannik wrote: > >> Hi Johan, >> >> It is fixed in ConfigurationOfMoose-jannik_laval.52 >> >> Cheers, >> Jannik >> >> On Jan 6, 2010, at 21:01 , Johan Fabry wrote: >> >>> Hi all, >>> >>> rebuilding a new image from scratch... Loading Moose using the >>> code on the website in the 'Install from Monticello' page. This >>> gives me 2 warnings that addPackage: has been replaced by package: >>> It would be nice to clean that up. >>> >>> Reported as issue 274 http://code.google.com/p/moose-technology/issues/detail?id=274&colspec=ID%20Status%20Summary%20Owner%20Type%20Opened%20Modified%20Milestone%20Component%20Reporter >>> >>> -- >>> Johan Fabry >>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> --- >> Jannik Laval >> --- >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing should have the right to be different." From tudor.girba at gmail.com Thu Jan 7 00:36:23 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 00:36:23 +0100 Subject: [Moose-dev] Re: call for projects In-Reply-To: <762F109A-A09E-4F7E-9624-3E3FB39D607B@bergel.eu> References: <762F109A-A09E-4F7E-9624-3E3FB39D607B@bergel.eu> Message-ID: <3422F966-601F-49E8-9875-BFDEAD4D2D37@gmail.com> Hi Alex and Simon, These projects sound great. Could you add a page for each of these tools here: http://www.moosetechnology.org/tools If you encounter problems with the Pier site, please let me know. Cheers, Doru On 6 Jan 2010, at 20:44, Alexandre Bergel wrote: > For me: > > Project name: Adore > Authors: Alexandre Bergel & Sebastien Mosser > Short description: Activity moDel suppOrting oRchestration Evolution > (www.adore-design.org) > Loading script: Gofer new squeaksource: 'Adore'; addPackage: > 'ConfigurationOfAdore'; load. (Smalltalk at: #ConfigurationOfAdore) > perform: #loadDefault > License: MIT > > Project name: ProcessModel > Authors: Julio Hurtado, Alexandre Bergel > Short description: Importing SPEM specified process models in Moose > Loading script: Gofer new squeaksource: 'ProcessModel'; addPackage: > 'ConfigurationOfProcessModel'; load. (Smalltalk at: > #ConfigurationOfProcessModel) perform: #loadDefault > License: MIT > > Cheers, > Alexandre > > > > On 5 Jan 2010, at 12:51, Tudor Girba wrote: > >> Hi, >> >> I would like to update the list of tools around Moose that are >> present in Pharo. >> >> If you are working on such a tool, I would appreciate if you could >> send around the following info: >> - Project Name >> - Authors and Short Description >> - License >> - Monticello repository and loading script >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that >> happen. They both matter." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From tudor.girba at gmail.com Thu Jan 7 00:37:23 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 00:37:23 +0100 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: References: Message-ID: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> Unfortunately, I have no idea how this happened. Is the problem still around? Cheers, Doru On 5 Jan 2010, at 20:22, Johan Fabry wrote: > Hi all, > > I did a ConfigurationOfGlamour loadDefault in a pretty fresh image > (pharo 10502 + moose + aspectmaps) to get the latest bugfixes, and > now I get a MNU. Cause is that (GLMPresentationsChanged new) returns > AnObsoleteGLMPresentationsChanged. > > I guess something went wrong in the load. How do I fix this ? > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." From Simon.Denier at inria.fr Thu Jan 7 01:03:05 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 7 Jan 2010 01:03:05 +0100 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> References: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> Message-ID: On 7 janv. 2010, at 00:37, Tudor Girba wrote: > Unfortunately, I have no idea how this happened. Is the problem still around? > > Cheers, > Doru > > > On 5 Jan 2010, at 20:22, Johan Fabry wrote: > >> Hi all, >> >> I did a ConfigurationOfGlamour loadDefault in a pretty fresh image (pharo 10502 + moose + aspectmaps) to get the latest bugfixes, and now I get a MNU. Cause is that (GLMPresentationsChanged new) returns AnObsoleteGLMPresentationsChanged. >> >> I guess something went wrong in the load. How do I fix this ? Sounds like you had a glamour browser opened when performing the update. >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the right one." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From jfabry at dcc.uchile.cl Thu Jan 7 02:44:12 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 6 Jan 2010 22:44:12 -0300 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> References: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> Message-ID: <3344CAAF-0C61-4DDB-9D6F-6A6386E22B43@dcc.uchile.cl> Yes, it is still happening (without any glamour browser open). Note that the image itself turned out to be kind of buggy in other respects due to font problems. Do you want me to put the image online for you somewhere so you can try it yourself? On 06 Jan 2010, at 20:37, Tudor Girba wrote: > Unfortunately, I have no idea how this happened. Is the problem > still around? > > Cheers, > Doru > > > On 5 Jan 2010, at 20:22, Johan Fabry wrote: > >> Hi all, >> >> I did a ConfigurationOfGlamour loadDefault in a pretty fresh image >> (pharo 10502 + moose + aspectmaps) to get the latest bugfixes, and >> now I get a MNU. Cause is that (GLMPresentationsChanged new) >> returns AnObsoleteGLMPresentationsChanged. >> >> I guess something went wrong in the load. How do I fix this ? >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting > is the right one." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Thu Jan 7 08:01:21 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 08:01:21 +0100 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: <3344CAAF-0C61-4DDB-9D6F-6A6386E22B43@dcc.uchile.cl> References: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> <3344CAAF-0C61-4DDB-9D6F-6A6386E22B43@dcc.uchile.cl> Message-ID: <1094A4DB-835F-403D-9C58-EBE34BC988D8@gmail.com> It does not sound Moose specific. If the error persists in a new image, then maybe we can take a closer look. Otherwise, I would rather not invest effort in this :) Cheers, Doru On 7 Jan 2010, at 02:44, Johan Fabry wrote: > > Yes, it is still happening (without any glamour browser open). Note > that the image itself turned out to be kind of buggy in other > respects due to font problems. Do you want me to put the image > online for you somewhere so you can try it yourself? > > On 06 Jan 2010, at 20:37, Tudor Girba wrote: > >> Unfortunately, I have no idea how this happened. Is the problem >> still around? >> >> Cheers, >> Doru >> >> >> On 5 Jan 2010, at 20:22, Johan Fabry wrote: >> >>> Hi all, >>> >>> I did a ConfigurationOfGlamour loadDefault in a pretty fresh image >>> (pharo 10502 + moose + aspectmaps) to get the latest bugfixes, and >>> now I get a MNU. Cause is that (GLMPresentationsChanged new) >>> returns AnObsoleteGLMPresentationsChanged. >>> >>> I guess something went wrong in the load. How do I fix this ? >>> >>> -- >>> Johan Fabry >>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Every now and then stop and ask yourself if the war you're >> fighting is the right one." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Live like you mean it." From tudor.girba at gmail.com Thu Jan 7 08:06:43 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 08:06:43 +0100 Subject: [Moose-dev] Re: call for projects In-Reply-To: <3422F966-601F-49E8-9875-BFDEAD4D2D37@gmail.com> References: <762F109A-A09E-4F7E-9624-3E3FB39D607B@bergel.eu> <3422F966-601F-49E8-9875-BFDEAD4D2D37@gmail.com> Message-ID: <5EDAB3C9-F58E-431E-97AF-AA6D33F182D1@gmail.com> Hi again, I updated the development page ( http://www.moosetechnology.org/development/commits ) to aggregate RSS feeds from the following projects: http://www.squeaksource.com/Moose/feed.rss http://www.squeaksource.com/Glamour/feed.rss http://www.squeaksource.com/Mondrian/feed.rss http://www.squeaksource.com/SmallDude/feed.rss http://www.squeaksource.com/CAnalyzer/feed.rss http://www.squeaksource.com/dsm/feed.rss http://www.squeaksource.com/AspectMaps/feed.rss http://www.squeaksource.com/moqam/feed.rss http://www.squeaksource.com/ProcessModel/feed.rss http://www.squeaksource.com/Adore/feed.rss Cheers, Doru On 7 Jan 2010, at 00:36, Tudor Girba wrote: > Hi Alex and Simon, > > These projects sound great. Could you add a page for each of these > tools here: > http://www.moosetechnology.org/tools > > If you encounter problems with the Pier site, please let me know. > > Cheers, > Doru > > > On 6 Jan 2010, at 20:44, Alexandre Bergel wrote: > >> For me: >> >> Project name: Adore >> Authors: Alexandre Bergel & Sebastien Mosser >> Short description: Activity moDel suppOrting oRchestration >> Evolution (www.adore-design.org) >> Loading script: Gofer new squeaksource: 'Adore'; addPackage: >> 'ConfigurationOfAdore'; load. (Smalltalk at: #ConfigurationOfAdore) >> perform: #loadDefault >> License: MIT >> >> Project name: ProcessModel >> Authors: Julio Hurtado, Alexandre Bergel >> Short description: Importing SPEM specified process models in Moose >> Loading script: Gofer new squeaksource: 'ProcessModel'; addPackage: >> 'ConfigurationOfProcessModel'; load. (Smalltalk at: >> #ConfigurationOfProcessModel) perform: #loadDefault >> License: MIT >> >> Cheers, >> Alexandre >> >> >> >> On 5 Jan 2010, at 12:51, Tudor Girba wrote: >> >>> Hi, >>> >>> I would like to update the list of tools around Moose that are >>> present in Pharo. >>> >>> If you are working on such a tool, I would appreciate if you could >>> send around the following info: >>> - Project Name >>> - Authors and Short Description >>> - License >>> - Monticello repository and loading script >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that >>> happen. They both matter." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > -- www.tudorgirba.com "Value is always contextual." From cy.delaunay at gmail.com Thu Jan 7 13:23:58 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Thu, 7 Jan 2010 13:23:58 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: No, the problem is still present. The xml file corresponding to the file for which I want to retrieve the information seems to be well-formed. So, it is maybe a problem from CAnalyzer. 2010/1/6 Alexandre Bergel > I didnt check, but I think that CAnalyzer needs to access the source and >> xml files to compute lines of code. How did you import your model? Where is >> it on disk? Did you generate new xml files or use old ones? >> > > No, you do not need the original source code for computing the lines of > code. There is a bijection between srcML XML files and original source code. > This is a great strenght of srcML. > > Cyrille, did you solve the problem? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfabry at dcc.uchile.cl Thu Jan 7 13:37:18 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Thu, 7 Jan 2010 09:37:18 -0300 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: <1094A4DB-835F-403D-9C58-EBE34BC988D8@gmail.com> References: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> <3344CAAF-0C61-4DDB-9D6F-6A6386E22B43@dcc.uchile.cl> <1094A4DB-835F-403D-9C58-EBE34BC988D8@gmail.com> Message-ID: <94335028-4388-4C0F-B618-0890D5600F93@dcc.uchile.cl> OK no problem, I understand :-) On 07 Jan 2010, at 04:01, Tudor Girba wrote: > It does not sound Moose specific. If the error persists in a new > image, then maybe we can take a closer look. Otherwise, I would > rather not invest effort in this :) > > Cheers, > Doru > > > On 7 Jan 2010, at 02:44, Johan Fabry wrote: > >> >> Yes, it is still happening (without any glamour browser open). Note >> that the image itself turned out to be kind of buggy in other >> respects due to font problems. Do you want me to put the image >> online for you somewhere so you can try it yourself? >> >> On 06 Jan 2010, at 20:37, Tudor Girba wrote: >> >>> Unfortunately, I have no idea how this happened. Is the problem >>> still around? >>> >>> Cheers, >>> Doru >>> >>> >>> On 5 Jan 2010, at 20:22, Johan Fabry wrote: >>> >>>> Hi all, >>>> >>>> I did a ConfigurationOfGlamour loadDefault in a pretty fresh >>>> image (pharo 10502 + moose + aspectmaps) to get the latest >>>> bugfixes, and now I get a MNU. Cause is that >>>> (GLMPresentationsChanged new) returns >>>> AnObsoleteGLMPresentationsChanged. >>>> >>>> I guess something went wrong in the load. How do I fix this ? >>>> >>>> -- >>>> Johan Fabry >>>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>>> PLEIAD Lab - Computer Science Department (DCC) - University of >>>> Chile >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every now and then stop and ask yourself if the war you're >>> fighting is the right one." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From Simon.Denier at inria.fr Thu Jan 7 14:54:37 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 7 Jan 2010 14:54:37 +0100 Subject: [Moose-dev] Re: call for projects In-Reply-To: <5EDAB3C9-F58E-431E-97AF-AA6D33F182D1@gmail.com> References: <762F109A-A09E-4F7E-9624-3E3FB39D607B@bergel.eu> <3422F966-601F-49E8-9875-BFDEAD4D2D37@gmail.com> <5EDAB3C9-F58E-431E-97AF-AA6D33F182D1@gmail.com> Message-ID: I forgot Moose Algorithms Authors: Moose team Generic libraries for analysis algorithms. Right now only there is a small graph library, but things from SCG Algorithm should go there once ported (formal concept analysis, information retrieval...) BSD License http://www.squeaksource.com/MooseAlgos On 7 janv. 2010, at 08:06, Tudor Girba wrote: > Hi again, > > I updated the development page ( http://www.moosetechnology.org/development/commits ) to aggregate RSS feeds from the following projects: > http://www.squeaksource.com/Moose/feed.rss > http://www.squeaksource.com/Glamour/feed.rss > http://www.squeaksource.com/Mondrian/feed.rss > http://www.squeaksource.com/SmallDude/feed.rss > http://www.squeaksource.com/CAnalyzer/feed.rss > http://www.squeaksource.com/dsm/feed.rss > http://www.squeaksource.com/AspectMaps/feed.rss > http://www.squeaksource.com/moqam/feed.rss > http://www.squeaksource.com/ProcessModel/feed.rss > http://www.squeaksource.com/Adore/feed.rss > > Cheers, > Doru > > On 7 Jan 2010, at 00:36, Tudor Girba wrote: > >> Hi Alex and Simon, >> >> These projects sound great. Could you add a page for each of these tools here: >> http://www.moosetechnology.org/tools >> >> If you encounter problems with the Pier site, please let me know. >> >> Cheers, >> Doru >> >> >> On 6 Jan 2010, at 20:44, Alexandre Bergel wrote: >> >>> For me: >>> >>> Project name: Adore >>> Authors: Alexandre Bergel & Sebastien Mosser >>> Short description: Activity moDel suppOrting oRchestration Evolution (www.adore-design.org) >>> Loading script: Gofer new squeaksource: 'Adore'; addPackage: 'ConfigurationOfAdore'; load. (Smalltalk at: #ConfigurationOfAdore) perform: #loadDefault >>> License: MIT >>> >>> Project name: ProcessModel >>> Authors: Julio Hurtado, Alexandre Bergel >>> Short description: Importing SPEM specified process models in Moose >>> Loading script: Gofer new squeaksource: 'ProcessModel'; addPackage: 'ConfigurationOfProcessModel'; load. (Smalltalk at: #ConfigurationOfProcessModel) perform: #loadDefault >>> License: MIT >>> >>> Cheers, >>> Alexandre >>> >>> >>> >>> On 5 Jan 2010, at 12:51, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I would like to update the list of tools around Moose that are present in Pharo. >>>> >>>> If you are working on such a tool, I would appreciate if you could send around the following info: >>>> - Project Name >>>> - Authors and Short Description >>>> - License >>>> - Monticello repository and loading script >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> > > -- > www.tudorgirba.com > > "Value is always contextual." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Thu Jan 7 14:59:00 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 7 Jan 2010 14:59:00 +0100 Subject: [Moose-dev] http://www.moosetechnology.org/docs/famix/3.0 Message-ID: <42717E53-8C50-4A05-B341-2876B8B0F663@inria.fr> The figure seems a bit outdated (no SourcedEntity for example) Also it would be cool if the image could downloaded or zoomed, because it is not readable right now. -- Simon From alexandre at bergel.eu Thu Jan 7 18:33:02 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 7 Jan 2010 14:33:02 -0300 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: Ok, I will provide a solution soon. Alexandre On 7 Jan 2010, at 09:23, Cyrille Delaunay wrote: > No, the problem is still present. The xml file corresponding to the > file for which I want to retrieve the information seems to be well- > formed. So, it is maybe a problem from CAnalyzer. > > 2010/1/6 Alexandre Bergel > I didnt check, but I think that CAnalyzer needs to access the source > and xml files to compute lines of code. How did you import your > model? Where is it on disk? Did you generate new xml files or use > old ones? > > No, you do not need the original source code for computing the lines > of code. There is a bijection between srcML XML files and original > source code. This is a great strenght of srcML. > > Cyrille, did you solve the problem? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Thu Jan 7 19:59:21 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 7 Jan 2010 15:59:21 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> Message-ID: Ok, give me a few hours. Alexandre On 6 Jan 2010, at 18:07, Simon Denier wrote: > > On 6 janv. 2010, at 17:56, Alexandre Bergel wrote: > >> Just to make sure that I fully understand, you want to have the >> effect of the second node, without nesting it? >> >> view shape rectangle withText. >> view node: 'hello world!'. >> >> view node: #foo forIt: [ >> view shape label. >> view interaction forwarder. >> view node: 'hello world!'. >> ] > > Yes, exactly, this gives the visual effect I want. > >> >> Something like: >> view shape label padding: 5. >> view node: 'hello world!'. > > yes, this the code I want to write (at least in simple case like a > Shape which can have a label) > > also > > view shape rectangle padding: 5; text: 'hello world!'. > view node: #hello > > >> ? >> >> Alexandre >> >> >> On 6 Jan 2010, at 13:32, Simon Denier wrote: >> >>> >>> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: >>> >>>> You can easy add space character before and after. You can also >>>> set a height: and a width: bigger than the text. >>> >>> Yep >>> >>> height: [:model | model name..... ] >>> >>> but how I can compute the text width and height? There are >>> textWidthFor: and textHeightFor: but those are internal methods. >>> >>> >>>> >>>> Alexandre >>>> >>>> >>>> On 6 Jan 2010, at 12:42, Simon Denier wrote: >>>> >>>>> >>>>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>>>> >>>>>> I am not sure to understand. >>>>>> It does not work using node:forIt: ? >>>>> >>>>> >>>>> I dont know, but if I can avoid the extra complexity of >>>>> embedding a node into another, that's good. It could be in the >>>>> shape, then the shape knows how much extra space it adds around >>>>> its content. >>>>> >>>>> >>>>> >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>>>> >>>>>>> >>>>>>> Hi there >>>>>>> >>>>>>> Is there a way to add some padding around the text inside a >>>>>>> shape (for example, inside a MORectangleShape)? >>>>>>> >>>>>>> thanks in advance >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Thu Jan 7 21:52:47 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 7 Jan 2010 17:52:47 -0300 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> Message-ID: <679007E8-D900-40A4-AFC3-C316F11EA836@bergel.eu> This is now in! New version of Mondrian: Mondrian-Alexandre_Bergel.334 Comment: Added text padding: - MORectangleShape>>textPadding: - MORectangleShape>>textHorizontalPadding: - MORectangleShape>>textVerticalPadding: - MOViewRendererTest>>testLabel6Padding, testLabel7HorizontalPadding, testLabel8VerticalPadding Example: view shape rectangle withText; textPadding: 5. view node: 'hello world!'. Cheers, Alexandre On 6 Jan 2010, at 18:07, Simon Denier wrote: > > On 6 janv. 2010, at 17:56, Alexandre Bergel wrote: > >> Just to make sure that I fully understand, you want to have the >> effect of the second node, without nesting it? >> >> view shape rectangle withText. >> view node: 'hello world!'. >> >> view node: #foo forIt: [ >> view shape label. >> view interaction forwarder. >> view node: 'hello world!'. >> ] > > Yes, exactly, this gives the visual effect I want. > >> >> Something like: >> view shape label padding: 5. >> view node: 'hello world!'. > > yes, this the code I want to write (at least in simple case like a > Shape which can have a label) > > also > > view shape rectangle padding: 5; text: 'hello world!'. > view node: #hello > > >> ? >> >> Alexandre >> >> >> On 6 Jan 2010, at 13:32, Simon Denier wrote: >> >>> >>> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: >>> >>>> You can easy add space character before and after. You can also >>>> set a height: and a width: bigger than the text. >>> >>> Yep >>> >>> height: [:model | model name..... ] >>> >>> but how I can compute the text width and height? There are >>> textWidthFor: and textHeightFor: but those are internal methods. >>> >>> >>>> >>>> Alexandre >>>> >>>> >>>> On 6 Jan 2010, at 12:42, Simon Denier wrote: >>>> >>>>> >>>>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>>>> >>>>>> I am not sure to understand. >>>>>> It does not work using node:forIt: ? >>>>> >>>>> >>>>> I dont know, but if I can avoid the extra complexity of >>>>> embedding a node into another, that's good. It could be in the >>>>> shape, then the shape knows how much extra space it adds around >>>>> its content. >>>>> >>>>> >>>>> >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>>>> >>>>>>> >>>>>>> Hi there >>>>>>> >>>>>>> Is there a way to add some padding around the text inside a >>>>>>> shape (for example, inside a MORectangleShape)? >>>>>>> >>>>>>> thanks in advance >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Thu Jan 7 22:22:37 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 7 Jan 2010 22:22:37 +0100 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: <679007E8-D900-40A4-AFC3-C316F11EA836@bergel.eu> References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> <679007E8-D900-40A4-AFC3-C316F11EA836@bergel.eu> Message-ID: On 7 janv. 2010, at 21:52, Alexandre Bergel wrote: > This is now in! > > New version of Mondrian: Mondrian-Alexandre_Bergel.334 > > Comment: > Added text padding: > - MORectangleShape>>textPadding: > - MORectangleShape>>textHorizontalPadding: > - MORectangleShape>>textVerticalPadding: > - MOViewRendererTest>>testLabel6Padding, testLabel7HorizontalPadding, testLabel8VerticalPadding > > Example: > view shape rectangle withText; textPadding: 5. > view node: 'hello world!'. Thanks Alex, that's really neat. > > Cheers, > Alexandre > > On 6 Jan 2010, at 18:07, Simon Denier wrote: > >> >> On 6 janv. 2010, at 17:56, Alexandre Bergel wrote: >> >>> Just to make sure that I fully understand, you want to have the effect of the second node, without nesting it? >>> >>> view shape rectangle withText. >>> view node: 'hello world!'. >>> >>> view node: #foo forIt: [ >>> view shape label. >>> view interaction forwarder. >>> view node: 'hello world!'. >>> ] >> >> Yes, exactly, this gives the visual effect I want. >> >>> >>> Something like: >>> view shape label padding: 5. >>> view node: 'hello world!'. >> >> yes, this the code I want to write (at least in simple case like a Shape which can have a label) >> >> also >> >> view shape rectangle padding: 5; text: 'hello world!'. >> view node: #hello >> >> >>> ? >>> >>> Alexandre >>> >>> >>> On 6 Jan 2010, at 13:32, Simon Denier wrote: >>> >>>> >>>> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: >>>> >>>>> You can easy add space character before and after. You can also set a height: and a width: bigger than the text. >>>> >>>> Yep >>>> >>>> height: [:model | model name..... ] >>>> >>>> but how I can compute the text width and height? There are textWidthFor: and textHeightFor: but those are internal methods. >>>> >>>> >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On 6 Jan 2010, at 12:42, Simon Denier wrote: >>>>> >>>>>> >>>>>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>>>>> >>>>>>> I am not sure to understand. >>>>>>> It does not work using node:forIt: ? >>>>>> >>>>>> >>>>>> I dont know, but if I can avoid the extra complexity of embedding a node into another, that's good. It could be in the shape, then the shape knows how much extra space it adds around its content. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>>>>> >>>>>>>> >>>>>>>> Hi there >>>>>>>> >>>>>>>> Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? >>>>>>>> >>>>>>>> thanks in advance >>>>>>>> >>>>>>>> -- >>>>>>>> Simon >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From alexandre at bergel.eu Thu Jan 7 22:25:53 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 7 Jan 2010 18:25:53 -0300 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: Hi Cyrille, I cannot reproduce the problem. I added a new method FAMIXFile>>numberOfLinesOfCode as an extension of CAnalyzer. The following test goes green: -=-=-=-=-=-=-=-=-=-=-=-= testSourceCode2 | filename1 importer | filename1 := 'file1.c.xml'. self removeFileIfPresent: filename1. self createFile: filename1 with: self sourceFile1XML. mooseModel := MooseModel new. importer := CXMLFileImporter inModel: mooseModel. importer loadXMLFilesNamed: {filename1}. self assert: (mooseModel entityNamed: 'file1.cunit::foo()') numberOfLinesOfCode = 2. self assert: (mooseModel entityNamed: 'file1.cunit::main()') numberOfLinesOfCode = 6. self assert: ((mooseModel entityNamed: #'file1.c') numberOfLinesOfCode = 19). self assert: ((mooseModel entityNamed: 'file1.cunit') numberOfLinesOfCode = 19). -=-=-=-=-=-=-=-=-=-=-=-= The two last lines are probably the most interesting for you. Cheers, Alexandre On 7 Jan 2010, at 09:23, Cyrille Delaunay wrote: > No, the problem is still present. The xml file corresponding to the > file for which I want to retrieve the information seems to be well- > formed. So, it is maybe a problem from CAnalyzer. > > 2010/1/6 Alexandre Bergel > I didnt check, but I think that CAnalyzer needs to access the source > and xml files to compute lines of code. How did you import your > model? Where is it on disk? Did you generate new xml files or use > old ones? > > No, you do not need the original source code for computing the lines > of code. There is a bijection between srcML XML files and original > source code. This is a great strenght of srcML. > > Cyrille, did you solve the problem? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Thu Jan 7 22:30:29 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 7 Jan 2010 22:30:29 +0100 Subject: [Moose-dev] Re: Mondrian: Padding within a shape In-Reply-To: References: <507FF83A-0DBF-43C2-B24A-E68447FA9784@bergel.eu> <30AAD709-8E2F-4EEE-8B5F-0B46A5D875FD@inria.fr> <44DEDC57-C51E-423E-879F-30E3BBB93F0A@bergel.eu> <715A5BE2-7AD5-4834-AB02-3EEFEBF8EB22@inria.fr> <679007E8-D900-40A4-AFC3-C316F11EA836@bergel.eu> Message-ID: <446A2C00-B6D7-41A6-9339-0EB9C132185A@inria.fr> Yes! Good night now :) On Jan 7, 2010, at 10:22 PM, Simon Denier wrote: > > On 7 janv. 2010, at 21:52, Alexandre Bergel wrote: > >> This is now in! >> >> New version of Mondrian: Mondrian-Alexandre_Bergel.334 >> >> Comment: >> Added text padding: >> - MORectangleShape>>textPadding: >> - MORectangleShape>>textHorizontalPadding: >> - MORectangleShape>>textVerticalPadding: >> - MOViewRendererTest>>testLabel6Padding, testLabel7HorizontalPadding, testLabel8VerticalPadding >> >> Example: >> view shape rectangle withText; textPadding: 5. >> view node: 'hello world!'. > > > Thanks Alex, that's really neat. > >> >> Cheers, >> Alexandre >> >> On 6 Jan 2010, at 18:07, Simon Denier wrote: >> >>> >>> On 6 janv. 2010, at 17:56, Alexandre Bergel wrote: >>> >>>> Just to make sure that I fully understand, you want to have the effect of the second node, without nesting it? >>>> >>>> view shape rectangle withText. >>>> view node: 'hello world!'. >>>> >>>> view node: #foo forIt: [ >>>> view shape label. >>>> view interaction forwarder. >>>> view node: 'hello world!'. >>>> ] >>> >>> Yes, exactly, this gives the visual effect I want. >>> >>>> >>>> Something like: >>>> view shape label padding: 5. >>>> view node: 'hello world!'. >>> >>> yes, this the code I want to write (at least in simple case like a Shape which can have a label) >>> >>> also >>> >>> view shape rectangle padding: 5; text: 'hello world!'. >>> view node: #hello >>> >>> >>>> ? >>>> >>>> Alexandre >>>> >>>> >>>> On 6 Jan 2010, at 13:32, Simon Denier wrote: >>>> >>>>> >>>>> On 6 janv. 2010, at 16:58, Alexandre Bergel wrote: >>>>> >>>>>> You can easy add space character before and after. You can also set a height: and a width: bigger than the text. >>>>> >>>>> Yep >>>>> >>>>> height: [:model | model name..... ] >>>>> >>>>> but how I can compute the text width and height? There are textWidthFor: and textHeightFor: but those are internal methods. >>>>> >>>>> >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 6 Jan 2010, at 12:42, Simon Denier wrote: >>>>>> >>>>>>> >>>>>>> On 6 janv. 2010, at 16:08, Alexandre Bergel wrote: >>>>>>> >>>>>>>> I am not sure to understand. >>>>>>>> It does not work using node:forIt: ? >>>>>>> >>>>>>> >>>>>>> I dont know, but if I can avoid the extra complexity of embedding a node into another, that's good. It could be in the shape, then the shape knows how much extra space it adds around its content. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>> >>>>>>>> On 6 Jan 2010, at 11:16, Simon Denier wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> Hi there >>>>>>>>> >>>>>>>>> Is there a way to add some padding around the text inside a shape (for example, inside a MORectangleShape)? >>>>>>>>> >>>>>>>>> thanks in advance >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Simon >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Thu Jan 7 22:39:41 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 7 Jan 2010 18:39:41 -0300 Subject: [Moose-dev] Re: Glamour: MNU on GLMPane>>notingPresentationChangeDo: In-Reply-To: <94335028-4388-4C0F-B618-0890D5600F93@dcc.uchile.cl> References: <1D2A55CD-C721-4E70-8E5B-15A730463750@gmail.com> <3344CAAF-0C61-4DDB-9D6F-6A6386E22B43@dcc.uchile.cl> <1094A4DB-835F-403D-9C58-EBE34BC988D8@gmail.com> <94335028-4388-4C0F-B618-0890D5600F93@dcc.uchile.cl> Message-ID: <18B9272E-F383-4763-88C7-739225CED4C9@bergel.eu> Johan, we can have a look at it together on Monday. Alexandre On 7 Jan 2010, at 09:37, Johan Fabry wrote: > > OK no problem, I understand :-) > > On 07 Jan 2010, at 04:01, Tudor Girba wrote: > >> It does not sound Moose specific. If the error persists in a new >> image, then maybe we can take a closer look. Otherwise, I would >> rather not invest effort in this :) >> >> Cheers, >> Doru >> >> >> On 7 Jan 2010, at 02:44, Johan Fabry wrote: >> >>> >>> Yes, it is still happening (without any glamour browser open). >>> Note that the image itself turned out to be kind of buggy in other >>> respects due to font problems. Do you want me to put the image >>> online for you somewhere so you can try it yourself? >>> >>> On 06 Jan 2010, at 20:37, Tudor Girba wrote: >>> >>>> Unfortunately, I have no idea how this happened. Is the problem >>>> still around? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 5 Jan 2010, at 20:22, Johan Fabry wrote: >>>> >>>>> Hi all, >>>>> >>>>> I did a ConfigurationOfGlamour loadDefault in a pretty fresh >>>>> image (pharo 10502 + moose + aspectmaps) to get the latest >>>>> bugfixes, and now I get a MNU. Cause is that >>>>> (GLMPresentationsChanged new) returns >>>>> AnObsoleteGLMPresentationsChanged. >>>>> >>>>> I guess something went wrong in the load. How do I fix this ? >>>>> >>>>> -- >>>>> Johan Fabry >>>>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>>>> PLEIAD Lab - Computer Science Department (DCC) - University of >>>>> Chile >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every now and then stop and ask yourself if the war you're >>>> fighting is the right one." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Johan Fabry >>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Thu Jan 7 23:46:39 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 7 Jan 2010 23:46:39 +0100 Subject: [Moose-dev] Re: http://www.moosetechnology.org/docs/famix/3.0 In-Reply-To: <42717E53-8C50-4A05-B341-2876B8B0F663@inria.fr> References: <42717E53-8C50-4A05-B341-2876B8B0F663@inria.fr> Message-ID: Hi, You can edit the MSE behind the picture to update it :). Indeed, it would be nice if we would have a zooming application, but until then the picture is actually large (1600 pixels) and zooming with Firefox and Safari will enlarge the picture. Also, any picture is downloadable by simply dragging and dropping it and when this one lands on your desktop you will see that the gif is actually 1600 pixels wide. Cheers, Doru On 7 Jan 2010, at 14:59, Simon Denier wrote: > The figure seems a bit outdated (no SourcedEntity for example) > > Also it would be cool if the image could downloaded or zoomed, > because it is not readable right now. > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From Simon.Denier at inria.fr Fri Jan 8 11:31:14 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 8 Jan 2010 11:31:14 +0100 Subject: [Moose-dev] Re: http://www.moosetechnology.org/docs/famix/3.0 In-Reply-To: References: <42717E53-8C50-4A05-B341-2876B8B0F663@inria.fr> Message-ID: On 7 janv. 2010, at 23:46, Tudor Girba wrote: > Hi, > > You can edit the MSE behind the picture to update it :). Oh, I thought it was a screenshot. > > Indeed, it would be nice if we would have a zooming application, but until then the picture is actually large (1600 pixels) and zooming with Firefox and Safari will enlarge the picture. > > Also, any picture is downloadable by simply dragging and dropping it and when this one lands on your desktop you will see that the gif is actually 1600 pixels wide. The problem is that for some reason (Pier? Seaside?), the picture does not behave like I am used to in a browser. When I right-click, I got the usual "Open image in new tab" and "Save image to Downloads" but neither works as expected: a file named 'www.moosetechnology.org' is saved on my disk in both cases. This file is actually the picture but the name is misleading so it's very easy to dismiss this as a bug. > > Cheers, > Doru > > On 7 Jan 2010, at 14:59, Simon Denier wrote: > >> The figure seems a bit outdated (no SourcedEntity for example) >> >> Also it would be cool if the image could downloaded or zoomed, because it is not readable right now. >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From cy.delaunay at gmail.com Fri Jan 8 12:48:27 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Fri, 8 Jan 2010 12:48:27 +0100 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: Yes, now I have retest in a new image and reloading the C code in moose and it works. Maybe the problem was due to a 'bad importation' of the C code. Thanks a lot alex. 2010/1/7 Alexandre Bergel > Hi Cyrille, > > I cannot reproduce the problem. I added a new method > FAMIXFile>>numberOfLinesOfCode as an extension of CAnalyzer. > The following test goes green: > -=-=-=-=-=-=-=-=-=-=-=-= > testSourceCode2 > | filename1 importer | > filename1 := 'file1.c.xml'. > self removeFileIfPresent: filename1. > self createFile: filename1 with: self sourceFile1XML. > > mooseModel := MooseModel new. > importer := CXMLFileImporter inModel: mooseModel. > importer loadXMLFilesNamed: {filename1}. > > self assert: (mooseModel entityNamed: 'file1.cunit::foo()') > numberOfLinesOfCode = 2. > self assert: (mooseModel entityNamed: 'file1.cunit::main()') > numberOfLinesOfCode = 6. > > self assert: ((mooseModel entityNamed: #'file1.c') > numberOfLinesOfCode = 19). > self assert: ((mooseModel entityNamed: 'file1.cunit') > numberOfLinesOfCode = 19). > -=-=-=-=-=-=-=-=-=-=-=-= > > The two last lines are probably the most interesting for you. > > Cheers, > > Alexandre > > > On 7 Jan 2010, at 09:23, Cyrille Delaunay wrote: > > No, the problem is still present. The xml file corresponding to the file >> for which I want to retrieve the information seems to be well-formed. So, it >> is maybe a problem from CAnalyzer. >> >> 2010/1/6 Alexandre Bergel >> I didnt check, but I think that CAnalyzer needs to access the source and >> xml files to compute lines of code. How did you import your model? Where is >> it on disk? Did you generate new xml files or use old ones? >> >> No, you do not need the original source code for computing the lines of >> code. There is a bijection between srcML XML files and original source code. >> This is a great strenght of srcML. >> >> Cyrille, did you solve the problem? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Fri Jan 8 13:55:00 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 8 Jan 2010 09:55:00 -0300 Subject: [Moose-dev] Re: How to have the number of lines of code of a C file In-Reply-To: References: <27086169-2374-4583-88A9-0A2A32EF7C63@inria.fr> Message-ID: > Yes, now I have retest in a new image and reloading the C code in > moose and it works. Maybe the problem was due to a 'bad > importation' of the C code. Thanks a lot alex. No problem. Let me know how it goes. Alexandre > > 2010/1/7 Alexandre Bergel > Hi Cyrille, > > I cannot reproduce the problem. I added a new method > FAMIXFile>>numberOfLinesOfCode as an extension of CAnalyzer. > The following test goes green: > -=-=-=-=-=-=-=-=-=-=-=-= > testSourceCode2 > | filename1 importer | > filename1 := 'file1.c.xml'. > self removeFileIfPresent: filename1. > self createFile: filename1 with: self sourceFile1XML. > > mooseModel := MooseModel new. > importer := CXMLFileImporter inModel: mooseModel. > importer loadXMLFilesNamed: {filename1}. > > self assert: (mooseModel entityNamed: 'file1.cunit::foo()') > numberOfLinesOfCode = 2. > self assert: (mooseModel entityNamed: 'file1.cunit::main()') > numberOfLinesOfCode = 6. > > self assert: ((mooseModel entityNamed: #'file1.c') > numberOfLinesOfCode = 19). > self assert: ((mooseModel entityNamed: 'file1.cunit') > numberOfLinesOfCode = 19). > -=-=-=-=-=-=-=-=-=-=-=-= > > The two last lines are probably the most interesting for you. > > Cheers, > > Alexandre > > > On 7 Jan 2010, at 09:23, Cyrille Delaunay wrote: > > No, the problem is still present. The xml file corresponding to the > file for which I want to retrieve the information seems to be well- > formed. So, it is maybe a problem from CAnalyzer. > > 2010/1/6 Alexandre Bergel > I didnt check, but I think that CAnalyzer needs to access the source > and xml files to compute lines of code. How did you import your > model? Where is it on disk? Did you generate new xml files or use > old ones? > > No, you do not need the original source code for computing the lines > of code. There is a bijection between srcML XML files and original > source code. This is a great strenght of srcML. > > Cyrille, did you solve the problem? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Fri Jan 8 21:44:11 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 8 Jan 2010 17:44:11 -0300 Subject: [Moose-dev] ConfigurationOfXXX Message-ID: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> Dear List, The package management in Pharo is getting more centralized. I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. It would be great if you follow this convention. I load the tools I need using the script: -=-=-=-=-=-=-=-=-= #('Mondrian' 'CAnalyzer' 'Spy') do: [:t | | name | name := 'ConfigurationOf', t. Gofer new squeaksource: 'MetacelloRepository'; package: name; load. (Smalltalk at: name asSymbol) perform: #loadDefault ]. -=-=-=-=-=-=-=-=-= Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Fri Jan 8 22:09:34 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 8 Jan 2010 22:09:34 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> Message-ID: On 8 janv. 2010, at 21:44, Alexandre Bergel wrote: > Dear List, > > The package management in Pharo is getting more centralized. > I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. > It would be great if you follow this convention. I am not sure this is a good move. This special repository is great for projects with high visibility and external to the Pharo sphere, like the packages for the dev image. Besides, we are using Metacello configurations in some strange ways and continue to bend Metacello. I understand that this repository is mostly to track stable configurations, while we will soon starting to track our branches and development with Configurations. For our own projects, I prefer we keep them in our repository (I dont have the rights on Metacello repository). > > I load the tools I need using the script: > > -=-=-=-=-=-=-=-=-= > #('Mondrian' 'CAnalyzer' 'Spy') > do: [:t | > | name | > name := 'ConfigurationOf', t. > Gofer new > squeaksource: 'MetacelloRepository'; > package: name; > load. > (Smalltalk at: name asSymbol) perform: #loadDefault ]. > -=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From alexandre at bergel.eu Fri Jan 8 22:16:04 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 8 Jan 2010 18:16:04 -0300 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> Message-ID: <5864ADD7-10F6-4632-8E7E-DB7ED825C6BB@bergel.eu> >> The package management in Pharo is getting more centralized. >> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >> ConfigurationOfMondrian in the SqueakSource package >> MetacelloRepository. >> It would be great if you follow this convention. > > > I am not sure this is a good move. This special repository is great > for projects with high visibility and external to the Pharo sphere, > like the packages for the dev image. I asked a number of times already, and apparently all metacello configurations must be in MetacelloRepository. I cannot find an argument why ConfigurationOfMoose should not be in. Esteban is working on a kind of apt-get mechanism based on this repository. It is not clear so far that we have something to gain by remaining outside. Especially since this will not change our habits at all. MetacelloRepository contains configurations for applications that are not part of PharoDev (e.g., Seaside, Glorp, Pier, ...) > Besides, we are using Metacello configurations in some strange ways > and continue to bend Metacello. I understand that this repository is > mostly to track stable configurations, while we will soon starting > to track our branches and development with Configurations. For our > own projects, I prefer we keep them in our repository (I dont have > the rights on Metacello repository). MetacelloRepository has a global read and write. Alexandre > > >> >> I load the tools I need using the script: >> >> -=-=-=-=-=-=-=-=-= >> #('Mondrian' 'CAnalyzer' 'Spy') >> do: [:t | >> | name | >> name := 'ConfigurationOf', t. >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: name; >> load. >> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >> -=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Fri Jan 8 22:52:46 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 8 Jan 2010 22:52:46 +0100 Subject: [Moose-dev] 10496 / 10502 mismatch with Moose conf Message-ID: One of my teammate followed straight the indications on Pharo and Moose to get a Moose image and got a DNU on Gofer#package: What happened? He went to the Pharo website to download the latest Pharo, but he noticed the following: Pharo 09.12.2 (10502) The above version, 09.12.2, has several issues. Until they are resolved, please use the older version Pharo 09.11.4 (10496). Then he went to the Moose website where he saw the following script: Gofer new squeaksource: 'Moose'; package: 'ConfigurationOfMoose'; load. (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault As some of you may quickly notice, we change #addPackage: to #package: recently to follow 10502 with the latest Gofer changes, while the recommended version is still 10496. I just hope that the final 1.0 will be soon out so that we can get past all those things :) -- Simon From Simon.Denier at inria.fr Fri Jan 8 23:07:44 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 8 Jan 2010 23:07:44 +0100 Subject: [Moose-dev] Lint rules to check Fame/FAMIX metamodel Message-ID: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> Hi there Today we finally pushed the final fix for Issue 143 If you open the metamodel browser, then you get a new command in the contextual menu, 'Check metamodel rules'. It opens an ORLintBrowser which runs over the browsed metamodel and check the classes. Currently there are 5 rules, 3 about Fame metamodel consistency, 2 about Famix conventions (those 2 are still a bit broken, dont take the results seriously). We already fix some inconsistencies in Famix-Core, but it appears there are more in extensions of Famix. -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Fri Jan 8 23:11:32 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 8 Jan 2010 19:11:32 -0300 Subject: [Moose-dev] Re: Lint rules to check Fame/FAMIX metamodel In-Reply-To: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> References: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> Message-ID: <8D085974-F25B-4F46-A6CD-AD672BDFB6FA@bergel.eu> Excellent idea ! Alexandre On 8 Jan 2010, at 19:07, Simon Denier wrote: > Hi there > > Today we finally pushed the final fix for Issue 143 > > If you open the metamodel browser, then you get a new command in the > contextual menu, 'Check metamodel rules'. It opens an ORLintBrowser > which runs over the browsed metamodel and check the classes. > Currently there are 5 rules, 3 about Fame metamodel consistency, 2 > about Famix conventions (those 2 are still a bit broken, dont take > the results seriously). > > We already fix some inconsistencies in Famix-Core, but it appears > there are more in extensions of Famix. > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Fri Jan 8 23:13:19 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 8 Jan 2010 23:13:19 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <5864ADD7-10F6-4632-8E7E-DB7ED825C6BB@bergel.eu> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <5864ADD7-10F6-4632-8E7E-DB7ED825C6BB@bergel.eu> Message-ID: On 8 janv. 2010, at 22:16, Alexandre Bergel wrote: >>> The package management in Pharo is getting more centralized. >>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. >>> It would be great if you follow this convention. >> >> >> I am not sure this is a good move. This special repository is great for projects with high visibility and external to the Pharo sphere, like the packages for the dev image. > > I asked a number of times already, and apparently all metacello configurations must be in MetacelloRepository. I cannot find an argument why ConfigurationOfMoose should not be in. > Esteban is working on a kind of apt-get mechanism based on this repository. It is not clear so far that we have something to gain by remaining outside. Especially since this will not change our habits at all. We still have to figure out some usage of Metacello within Moose, and I think we will a very specific usage concerned with tracking development changes. Until we have this figured out and until Esteban has figured its own project, I dont feel the urge to put both together. > > MetacelloRepository contains configurations for applications that are not part of PharoDev (e.g., Seaside, Glorp, Pier, ...) > >> Besides, we are using Metacello configurations in some strange ways and continue to bend Metacello. I understand that this repository is mostly to track stable configurations, while we will soon starting to track our branches and development with Configurations. For our own projects, I prefer we keep them in our repository (I dont have the rights on Metacello repository). > > MetacelloRepository has a global read and write. I was talking about admin rights :) > > Alexandre > > >> >> >>> >>> I load the tools I need using the script: >>> >>> -=-=-=-=-=-=-=-=-= >>> #('Mondrian' 'CAnalyzer' 'Spy') >>> do: [:t | >>> | name | >>> name := 'ConfigurationOf', t. >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: name; >>> load. >>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>> -=-=-=-=-=-=-=-=-= >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From stephane.ducasse at inria.fr Sat Jan 9 09:17:08 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 9 Jan 2010 09:17:08 +0100 Subject: [Moose-dev] Re: 10496 / 10502 mismatch with Moose conf In-Reply-To: References: Message-ID: It will we are working on it ;) But nothing is that simple and everything takes times. Stef On Jan 8, 2010, at 10:52 PM, Simon Denier wrote: > > One of my teammate followed straight the indications on Pharo and Moose to get a Moose image and got a DNU on Gofer#package: > > What happened? > > He went to the Pharo website to download the latest Pharo, but he noticed the following: > > Pharo 09.12.2 (10502) > The above version, 09.12.2, has several issues. Until they are resolved, please use the older version Pharo 09.11.4 (10496). > > > Then he went to the Moose website where he saw the following script: > Gofer new > squeaksource: 'Moose'; > package: 'ConfigurationOfMoose'; > load. > (Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault > > As some of you may quickly notice, we change #addPackage: to #package: recently to follow 10502 with the latest Gofer changes, while the recommended version is still 10496. > > > I just hope that the final 1.0 will be soon out so that we can get past all those things :) > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Sat Jan 9 09:17:58 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 9 Jan 2010 09:17:58 +0100 Subject: [Moose-dev] Re: Lint rules to check Fame/FAMIX metamodel In-Reply-To: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> References: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> Message-ID: <9D3CBCB9-2574-4E47-8A3D-930906E3E327@inria.fr> coooooooooooooooooooooooooool the software at the service of the engineer something we sometimes forget On Jan 8, 2010, at 11:07 PM, Simon Denier wrote: > Hi there > > Today we finally pushed the final fix for Issue 143 > > If you open the metamodel browser, then you get a new command in the contextual menu, 'Check metamodel rules'. It opens an ORLintBrowser which runs over the browsed metamodel and check the classes. Currently there are 5 rules, 3 about Fame metamodel consistency, 2 about Famix conventions (those 2 are still a bit broken, dont take the results seriously). > > We already fix some inconsistencies in Famix-Core, but it appears there are more in extensions of Famix. > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Sat Jan 9 09:19:35 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 9 Jan 2010 09:19:35 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> Message-ID: <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> We can copy configuration there but we should not move them. Each project should still have its own local copy. Having a global entry is good but it is not incompatible with the notion of locality Stef On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: > Dear List, > > The package management in Pharo is getting more centralized. > I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. > It would be great if you follow this convention. > > I load the tools I need using the script: > > -=-=-=-=-=-=-=-=-= > #('Mondrian' 'CAnalyzer' 'Spy') > do: [:t | > | name | > name := 'ConfigurationOf', t. > Gofer new > squeaksource: 'MetacelloRepository'; > package: name; > load. > (Smalltalk at: name asSymbol) perform: #loadDefault ]. > -=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Sat Jan 9 18:03:31 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Sat, 9 Jan 2010 18:03:31 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> Message-ID: <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: > We can copy configuration there but we should not move them. > Each project should still have its own local copy. > Having a global entry is good but it is not incompatible with the notion of locality Yep, we can make a copy whenever a new stable/beta is released. > > > Stef > > On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: > >> Dear List, >> >> The package management in Pharo is getting more centralized. >> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. >> It would be great if you follow this convention. >> >> I load the tools I need using the script: >> >> -=-=-=-=-=-=-=-=-= >> #('Mondrian' 'CAnalyzer' 'Spy') >> do: [:t | >> | name | >> name := 'ConfigurationOf', t. >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: name; >> load. >> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >> -=-=-=-=-=-=-=-=-= >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Sun Jan 10 14:42:08 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 10 Jan 2010 14:42:08 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> Message-ID: <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> I was thinking too about the MetacelloRepository. The problem is that a configuration without being completely up to date is not of much use. So, let's try as Simon suggests to continue to work on the project repository and copy them when a release is done. Cheers, Doru On 9 Jan 2010, at 18:03, Simon Denier wrote: > > On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: > >> We can copy configuration there but we should not move them. >> Each project should still have its own local copy. >> Having a global entry is good but it is not incompatible with the >> notion of locality > > > Yep, we can make a copy whenever a new stable/beta is released. > > >> >> >> Stef >> >> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >> >>> Dear List, >>> >>> The package management in Pharo is getting more centralized. >>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >>> ConfigurationOfMondrian in the SqueakSource package >>> MetacelloRepository. >>> It would be great if you follow this convention. >>> >>> I load the tools I need using the script: >>> >>> -=-=-=-=-=-=-=-=-= >>> #('Mondrian' 'CAnalyzer' 'Spy') >>> do: [:t | >>> | name | >>> name := 'ConfigurationOf', t. >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: name; >>> load. >>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>> -=-=-=-=-=-=-=-=-= >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Live like you mean it." From tudor.girba at gmail.com Sun Jan 10 14:49:31 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 10 Jan 2010 14:49:31 +0100 Subject: [Moose-dev] package blueprint Message-ID: <60F47161-B5F1-4C71-A91B-75D3CBBFDD9A@gmail.com> Hi, Package blueprint tests raise 12 errors at this moment. The problem seems to be the nonexistent OrderedSet. Is anyone taking charge of this? I presume it is this related to this issue: http://code.google.com/p/moose-technology/issues/detail?id=160 Cheers, Doru -- www.tudorgirba.com "Live like you mean it." From tudor at tudorgirba.com Sun Jan 10 14:59:18 2010 From: tudor at tudorgirba.com (Tudor Girba) Date: Sun, 10 Jan 2010 14:59:18 +0100 Subject: [Moose-dev] mondrian text related tests Message-ID: <1820CAC1-0315-4AA0-9102-F4B87DBE7374@tudorgirba.com> Hi, Mondrian has a number of tests related to the bounds of text nodes. I am not sure why these fail. Is it because they were created with a specific font in mind? Alex? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow." From Simon.Denier at inria.fr Sun Jan 10 16:51:49 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Sun, 10 Jan 2010 16:51:49 +0100 Subject: [Moose-dev] Re: package blueprint In-Reply-To: <60F47161-B5F1-4C71-A91B-75D3CBBFDD9A@gmail.com> References: <60F47161-B5F1-4C71-A91B-75D3CBBFDD9A@gmail.com> Message-ID: <2CA4F161-ACDC-4E01-83CB-C0F2994F24E3@inria.fr> On 10 janv. 2010, at 14:49, Tudor Girba wrote: > Hi, > > Package blueprint tests raise 12 errors at this moment. The problem seems to be the nonexistent OrderedSet. Yes, Jean-R?my is trying to learn Moose/Mondrian while porting Package Blueprint. OrderedSet should probably be put in collection-extensions for now. > > Is anyone taking charge of this? I presume it is this related to this issue: > http://code.google.com/p/moose-technology/issues/detail?id=160 > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Live like you mean it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Sun Jan 10 17:56:19 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 10 Jan 2010 17:56:19 +0100 Subject: [Moose-dev] Re: package blueprint In-Reply-To: <2CA4F161-ACDC-4E01-83CB-C0F2994F24E3@inria.fr> References: <60F47161-B5F1-4C71-A91B-75D3CBBFDD9A@gmail.com> <2CA4F161-ACDC-4E01-83CB-C0F2994F24E3@inria.fr> Message-ID: <85B0317E-6995-43B5-A504-46D9F2012F6F@gmail.com> Hi, >> Hi, >> >> Package blueprint tests raise 12 errors at this moment. The problem >> seems to be the nonexistent OrderedSet. > > Yes, Jean-R?my is trying to learn Moose/Mondrian while porting > Package Blueprint. > > OrderedSet should probably be put in collection-extensions for now. Excellent! But, in the meantime I suggest removing this from the default configuration. When it's done, we can add it back. Cheers, Doru >> >> Is anyone taking charge of this? I presume it is this related to >> this issue: >> http://code.google.com/p/moose-technology/issues/detail?id=160 >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From tudor.girba at gmail.com Sun Jan 10 20:41:49 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 10 Jan 2010 20:41:49 +0100 Subject: [Moose-dev] Re: Lint rules to check Fame/FAMIX metamodel In-Reply-To: <9D3CBCB9-2574-4E47-8A3D-930906E3E327@inria.fr> References: <8BF998D4-06E5-446C-89B6-6EA807262339@inria.fr> <9D3CBCB9-2574-4E47-8A3D-930906E3E327@inria.fr> Message-ID: <171CEB65-10FB-427B-A46E-1B644DDB940E@gmail.com> Excellent. I moved the lint checking action to the browser menu/toolbar because it is a global action. Cheers, Doru On 9 Jan 2010, at 09:17, St?phane Ducasse wrote: > coooooooooooooooooooooooooool the software at the service of the > engineer something we sometimes forget > > On Jan 8, 2010, at 11:07 PM, Simon Denier wrote: > >> Hi there >> >> Today we finally pushed the final fix for Issue 143 >> >> If you open the metamodel browser, then you get a new command in >> the contextual menu, 'Check metamodel rules'. It opens an >> ORLintBrowser which runs over the browsed metamodel and check the >> classes. Currently there are 5 rules, 3 about Fame metamodel >> consistency, 2 about Famix conventions (those 2 are still a bit >> broken, dont take the results seriously). >> >> We already fix some inconsistencies in Famix-Core, but it appears >> there are more in extensions of Famix. >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From tudor.girba at gmail.com Sun Jan 10 21:01:00 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 10 Jan 2010 21:01:00 +0100 Subject: [Moose-dev] MooseGlamorousPanel Message-ID: Hi, I implemented a Moose Panel based on Glamour. It integrates both the list of models and the finder. You can get it by executing: MoosePanel open. The list of models is now updated using a new basic means to update a Glamour presentation. The importing actions are rendered as toolbar buttons based on the specs from the MoosePaneCommand. The pane commands that do not specify an icon, are rendered as menu that is spawned by pressing the "..." toolbar button. Please let me know what you think. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." From stephane.ducasse at inria.fr Mon Jan 11 08:15:30 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 11 Jan 2010 08:15:30 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> Message-ID: <433CA15A-6D67-4AA1-8B97-53F2AC1EA092@inria.fr> I think that this should be the pattern for all the projects else the repository will be a big mess Stef On Jan 10, 2010, at 2:42 PM, Tudor Girba wrote: > I was thinking too about the MetacelloRepository. The problem is that a configuration without being completely up to date is not of much use. > > So, let's try as Simon suggests to continue to work on the project repository and copy them when a release is done. > > Cheers, > Doru > > > On 9 Jan 2010, at 18:03, Simon Denier wrote: > >> >> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >> >>> We can copy configuration there but we should not move them. >>> Each project should still have its own local copy. >>> Having a global entry is good but it is not incompatible with the notion of locality >> >> >> Yep, we can make a copy whenever a new stable/beta is released. >> >> >>> >>> >>> Stef >>> >>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> The package management in Pharo is getting more centralized. >>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. >>>> It would be great if you follow this convention. >>>> >>>> I load the tools I need using the script: >>>> >>>> -=-=-=-=-=-=-=-=-= >>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>> do: [:t | >>>> | name | >>>> name := 'ConfigurationOf', t. >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: name; >>>> load. >>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>> -=-=-=-=-=-=-=-=-= >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Mon Jan 11 13:56:54 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 09:56:54 -0300 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> Message-ID: The problem is that you cannot just copy them. You need to change reference from Moose to MetacelloRepository when loading dependent ConfigurationOfYYY. Cheers, Alexandre On 10 Jan 2010, at 10:42, Tudor Girba wrote: > I was thinking too about the MetacelloRepository. The problem is > that a configuration without being completely up to date is not of > much use. > > So, let's try as Simon suggests to continue to work on the project > repository and copy them when a release is done. > > Cheers, > Doru > > > On 9 Jan 2010, at 18:03, Simon Denier wrote: > >> >> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >> >>> We can copy configuration there but we should not move them. >>> Each project should still have its own local copy. >>> Having a global entry is good but it is not incompatible with the >>> notion of locality >> >> >> Yep, we can make a copy whenever a new stable/beta is released. >> >> >>> >>> >>> Stef >>> >>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> The package management in Pharo is getting more centralized. >>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >>>> ConfigurationOfMondrian in the SqueakSource package >>>> MetacelloRepository. >>>> It would be great if you follow this convention. >>>> >>>> I load the tools I need using the script: >>>> >>>> -=-=-=-=-=-=-=-=-= >>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>> do: [:t | >>>> | name | >>>> name := 'ConfigurationOf', t. >>>> Gofer new >>>> squeaksource: 'MetacelloRepository'; >>>> package: name; >>>> load. >>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>> -=-=-=-=-=-=-=-=-= >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Mon Jan 11 14:46:58 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 11 Jan 2010 14:46:58 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> Message-ID: On Jan 11, 2010, at 1:56 PM, Alexandre Bergel wrote: > The problem is that you cannot just copy them. You need to change reference from Moose to MetacelloRepository when loading dependent ConfigurationOfYYY. why? you click on the MC package and copy to another repository > Cheers, > Alexandre > > > On 10 Jan 2010, at 10:42, Tudor Girba wrote: > >> I was thinking too about the MetacelloRepository. The problem is that a configuration without being completely up to date is not of much use. >> >> So, let's try as Simon suggests to continue to work on the project repository and copy them when a release is done. >> >> Cheers, >> Doru >> >> >> On 9 Jan 2010, at 18:03, Simon Denier wrote: >> >>> >>> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >>> >>>> We can copy configuration there but we should not move them. >>>> Each project should still have its own local copy. >>>> Having a global entry is good but it is not incompatible with the notion of locality >>> >>> >>> Yep, we can make a copy whenever a new stable/beta is released. >>> >>> >>>> >>>> >>>> Stef >>>> >>>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>>> >>>>> Dear List, >>>>> >>>>> The package management in Pharo is getting more centralized. >>>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. >>>>> It would be great if you follow this convention. >>>>> >>>>> I load the tools I need using the script: >>>>> >>>>> -=-=-=-=-=-=-=-=-= >>>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>>> do: [:t | >>>>> | name | >>>>> name := 'ConfigurationOf', t. >>>>> Gofer new >>>>> squeaksource: 'MetacelloRepository'; >>>>> package: name; >>>>> load. >>>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>>> -=-=-=-=-=-=-=-=-= >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Live like you mean it." >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Mon Jan 11 14:49:17 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 10:49:17 -0300 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: <7AD8640C-0025-47B3-B976-4DC85F31A0B1@bergel.eu> Yeah! Excellent! It is really nice! Some times ago I had some layout problem. Apparently they disappeared. Really cool! Alexandre On 10 Jan 2010, at 17:01, Tudor Girba wrote: > Hi, > > I implemented a Moose Panel based on Glamour. It integrates both the > list of models and the finder. You can get it by executing: > MoosePanel open. > > The list of models is now updated using a new basic means to update > a Glamour presentation. > > The importing actions are rendered as toolbar buttons based on the > specs from the MoosePaneCommand. The pane commands that do not > specify an icon, are rendered as menu that is spawned by pressing > the "..." toolbar button. > > Please let me know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Mon Jan 11 14:57:05 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 10:57:05 -0300 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> Message-ID: I meant that the loading script has to be updated with the new repository (Moose -> MetacelloRepository). In the long method ConfigurationOfMoose>>baseline40beta3:, I had to change spec project: 'Mondrian for Moose' with: [ spec className: 'ConfigurationOfMondrian'; file: 'ConfigurationOfMondrian'; version: 'default'; repository: 'http://www.squeaksource.com/Mondrian' ]. into spec project: 'Mondrian for Moose' with: [ spec className: 'ConfigurationOfMondrian'; file: 'ConfigurationOfMondrian'; version: 'default'; repository: 'http://www.squeaksource.com/MetacelloRepository' ]. Alexandre On 11 Jan 2010, at 10:46, St?phane Ducasse wrote: > > On Jan 11, 2010, at 1:56 PM, Alexandre Bergel wrote: > >> The problem is that you cannot just copy them. You need to change >> reference from Moose to MetacelloRepository when loading dependent >> ConfigurationOfYYY. > > why? > you click on the MC package and copy to another repository > > >> Cheers, >> Alexandre >> >> >> On 10 Jan 2010, at 10:42, Tudor Girba wrote: >> >>> I was thinking too about the MetacelloRepository. The problem is >>> that a configuration without being completely up to date is not of >>> much use. >>> >>> So, let's try as Simon suggests to continue to work on the project >>> repository and copy them when a release is done. >>> >>> Cheers, >>> Doru >>> >>> >>> On 9 Jan 2010, at 18:03, Simon Denier wrote: >>> >>>> >>>> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >>>> >>>>> We can copy configuration there but we should not move them. >>>>> Each project should still have its own local copy. >>>>> Having a global entry is good but it is not incompatible with >>>>> the notion of locality >>>> >>>> >>>> Yep, we can make a copy whenever a new stable/beta is released. >>>> >>>> >>>>> >>>>> >>>>> Stef >>>>> >>>>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>>>> >>>>>> Dear List, >>>>>> >>>>>> The package management in Pharo is getting more centralized. >>>>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >>>>>> ConfigurationOfMondrian in the SqueakSource package >>>>>> MetacelloRepository. >>>>>> It would be great if you follow this convention. >>>>>> >>>>>> I load the tools I need using the script: >>>>>> >>>>>> -=-=-=-=-=-=-=-=-= >>>>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>>>> do: [:t | >>>>>> | name | >>>>>> name := 'ConfigurationOf', t. >>>>>> Gofer new >>>>>> squeaksource: 'MetacelloRepository'; >>>>>> package: name; >>>>>> load. >>>>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>>>> -=-=-=-=-=-=-=-=-= >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Live like you mean it." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Mon Jan 11 15:45:11 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 11 Jan 2010 15:45:11 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> Message-ID: <68018894-13DB-4C1F-9A3E-612B29B90643@gmail.com> Hi Alex, As the main script will remain in the Moose repository, you do not have to change anything. It will work just as it is. Cheers, Doru On 11 Jan 2010, at 14:57, Alexandre Bergel wrote: > I meant that the loading script has to be updated with the new > repository (Moose -> MetacelloRepository). > In the long method ConfigurationOfMoose>>baseline40beta3:, I had to > change > spec project: 'Mondrian for Moose' with: [ > spec > className: 'ConfigurationOfMondrian'; > file: 'ConfigurationOfMondrian'; > version: 'default'; > repository: 'http://www.squeaksource.com/Mondrian' ]. > > into > spec project: 'Mondrian for Moose' with: [ > spec > className: 'ConfigurationOfMondrian'; > file: 'ConfigurationOfMondrian'; > version: 'default'; > repository: 'http://www.squeaksource.com/MetacelloRepository' ]. > > Alexandre > > On 11 Jan 2010, at 10:46, St?phane Ducasse wrote: > >> >> On Jan 11, 2010, at 1:56 PM, Alexandre Bergel wrote: >> >>> The problem is that you cannot just copy them. You need to change >>> reference from Moose to MetacelloRepository when loading dependent >>> ConfigurationOfYYY. >> >> why? >> you click on the MC package and copy to another repository >> >> >>> Cheers, >>> Alexandre >>> >>> >>> On 10 Jan 2010, at 10:42, Tudor Girba wrote: >>> >>>> I was thinking too about the MetacelloRepository. The problem is >>>> that a configuration without being completely up to date is not >>>> of much use. >>>> >>>> So, let's try as Simon suggests to continue to work on the >>>> project repository and copy them when a release is done. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> On 9 Jan 2010, at 18:03, Simon Denier wrote: >>>> >>>>> >>>>> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >>>>> >>>>>> We can copy configuration there but we should not move them. >>>>>> Each project should still have its own local copy. >>>>>> Having a global entry is good but it is not incompatible with >>>>>> the notion of locality >>>>> >>>>> >>>>> Yep, we can make a copy whenever a new stable/beta is released. >>>>> >>>>> >>>>>> >>>>>> >>>>>> Stef >>>>>> >>>>>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> The package management in Pharo is getting more centralized. >>>>>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >>>>>>> ConfigurationOfMondrian in the SqueakSource package >>>>>>> MetacelloRepository. >>>>>>> It would be great if you follow this convention. >>>>>>> >>>>>>> I load the tools I need using the script: >>>>>>> >>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>>>>> do: [:t | >>>>>>> | name | >>>>>>> name := 'ConfigurationOf', t. >>>>>>> Gofer new >>>>>>> squeaksource: 'MetacelloRepository'; >>>>>>> package: name; >>>>>>> load. >>>>>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Live like you mean it." >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." From alexandre at bergel.eu Mon Jan 11 15:57:05 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 11:57:05 -0300 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <68018894-13DB-4C1F-9A3E-612B29B90643@gmail.com> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> <68018894-13DB-4C1F-9A3E-612B29B90643@gmail.com> Message-ID: <36FB8EA2-540F-4652-9DF2-F403358E13CE@bergel.eu> Ok, but it cannot be just 'copied' to the Metacello repository. Alexandre On 11 Jan 2010, at 11:45, Tudor Girba wrote: > Hi Alex, > > As the main script will remain in the Moose repository, you do not > have to change anything. It will work just as it is. > > Cheers, > Doru > > > On 11 Jan 2010, at 14:57, Alexandre Bergel wrote: > >> I meant that the loading script has to be updated with the new >> repository (Moose -> MetacelloRepository). >> In the long method ConfigurationOfMoose>>baseline40beta3:, I had to >> change >> spec project: 'Mondrian for Moose' with: [ >> spec >> className: 'ConfigurationOfMondrian'; >> file: 'ConfigurationOfMondrian'; >> version: 'default'; >> repository: 'http://www.squeaksource.com/Mondrian' ]. >> >> into >> spec project: 'Mondrian for Moose' with: [ >> spec >> className: 'ConfigurationOfMondrian'; >> file: 'ConfigurationOfMondrian'; >> version: 'default'; >> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >> >> Alexandre >> >> On 11 Jan 2010, at 10:46, St?phane Ducasse wrote: >> >>> >>> On Jan 11, 2010, at 1:56 PM, Alexandre Bergel wrote: >>> >>>> The problem is that you cannot just copy them. You need to change >>>> reference from Moose to MetacelloRepository when loading >>>> dependent ConfigurationOfYYY. >>> >>> why? >>> you click on the MC package and copy to another repository >>> >>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 10 Jan 2010, at 10:42, Tudor Girba wrote: >>>> >>>>> I was thinking too about the MetacelloRepository. The problem is >>>>> that a configuration without being completely up to date is not >>>>> of much use. >>>>> >>>>> So, let's try as Simon suggests to continue to work on the >>>>> project repository and copy them when a release is done. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> On 9 Jan 2010, at 18:03, Simon Denier wrote: >>>>> >>>>>> >>>>>> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >>>>>> >>>>>>> We can copy configuration there but we should not move them. >>>>>>> Each project should still have its own local copy. >>>>>>> Having a global entry is good but it is not incompatible with >>>>>>> the notion of locality >>>>>> >>>>>> >>>>>> Yep, we can make a copy whenever a new stable/beta is released. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>>>>>> >>>>>>>> Dear List, >>>>>>>> >>>>>>>> The package management in Pharo is getting more centralized. >>>>>>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, >>>>>>>> ConfigurationOfMondrian in the SqueakSource package >>>>>>>> MetacelloRepository. >>>>>>>> It would be great if you follow this convention. >>>>>>>> >>>>>>>> I load the tools I need using the script: >>>>>>>> >>>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>>>>>> do: [:t | >>>>>>>> | name | >>>>>>>> name := 'ConfigurationOf', t. >>>>>>>> Gofer new >>>>>>>> squeaksource: 'MetacelloRepository'; >>>>>>>> package: name; >>>>>>>> load. >>>>>>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Alexandre >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Live like you mean it." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Mon Jan 11 16:35:45 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 11 Jan 2010 16:35:45 +0100 Subject: [Moose-dev] Re: ConfigurationOfXXX In-Reply-To: <36FB8EA2-540F-4652-9DF2-F403358E13CE@bergel.eu> References: <224F3D04-78A0-4817-B97A-4C63444F88FA@bergel.eu> <229DEB18-8626-4712-A595-CA58AFBEC45C@inria.fr> <4D04B7B8-F549-4C7C-ADEB-1E97E3FB49FF@inria.fr> <4392F675-8321-42F0-8C4F-681B4CEFBCAF@gmail.com> <68018894-13DB-4C1F-9A3E-612B29B90643@gmail.com> <36FB8EA2-540F-4652-9DF2-F403358E13CE@bergel.eu> Message-ID: why? We copy a spec that says where the package should be loaded from. > Ok, but it cannot be just 'copied' to the Metacello repository. > > Alexandre > > > On 11 Jan 2010, at 11:45, Tudor Girba wrote: > >> Hi Alex, >> >> As the main script will remain in the Moose repository, you do not have to change anything. It will work just as it is. I got confused. Am'I correct? The repository: can be 'http://www.squeaksource.com/Mondrian' even if the configuration is saved in 'http://www.squeaksource.com/MetacelloRepository Stef >> On 11 Jan 2010, at 14:57, Alexandre Bergel wrote: >> >>> I meant that the loading script has to be updated with the new repository (Moose -> MetacelloRepository). >>> In the long method ConfigurationOfMoose>>baseline40beta3:, I had to change >>> spec project: 'Mondrian for Moose' with: [ >>> spec >>> className: 'ConfigurationOfMondrian'; >>> file: 'ConfigurationOfMondrian'; >>> version: 'default'; >>> repository: 'http://www.squeaksource.com/Mondrian' ]. >>> >>> into >>> spec project: 'Mondrian for Moose' with: [ >>> spec >>> className: 'ConfigurationOfMondrian'; >>> file: 'ConfigurationOfMondrian'; >>> version: 'default'; >>> repository: 'http://www.squeaksource.com/MetacelloRepository' ]. >>> >>> Alexandre >>> >>> On 11 Jan 2010, at 10:46, St?phane Ducasse wrote: >>> >>>> >>>> On Jan 11, 2010, at 1:56 PM, Alexandre Bergel wrote: >>>> >>>>> The problem is that you cannot just copy them. You need to change reference from Moose to MetacelloRepository when loading dependent ConfigurationOfYYY. >>>> >>>> why? >>>> you click on the MC package and copy to another repository >>>> >>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> On 10 Jan 2010, at 10:42, Tudor Girba wrote: >>>>> >>>>>> I was thinking too about the MetacelloRepository. The problem is that a configuration without being completely up to date is not of much use. >>>>>> >>>>>> So, let's try as Simon suggests to continue to work on the project repository and copy them when a release is done. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> On 9 Jan 2010, at 18:03, Simon Denier wrote: >>>>>> >>>>>>> >>>>>>> On 9 janv. 2010, at 09:19, St?phane Ducasse wrote: >>>>>>> >>>>>>>> We can copy configuration there but we should not move them. >>>>>>>> Each project should still have its own local copy. >>>>>>>> Having a global entry is good but it is not incompatible with the notion of locality >>>>>>> >>>>>>> >>>>>>> Yep, we can make a copy whenever a new stable/beta is released. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> On Jan 8, 2010, at 9:44 PM, Alexandre Bergel wrote: >>>>>>>> >>>>>>>>> Dear List, >>>>>>>>> >>>>>>>>> The package management in Pharo is getting more centralized. >>>>>>>>> I moved ConfigurationOfMoose, ConfigurationOfCAnalyzer, ConfigurationOfMondrian in the SqueakSource package MetacelloRepository. >>>>>>>>> It would be great if you follow this convention. >>>>>>>>> >>>>>>>>> I load the tools I need using the script: >>>>>>>>> >>>>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>>>> #('Mondrian' 'CAnalyzer' 'Spy') >>>>>>>>> do: [:t | >>>>>>>>> | name | >>>>>>>>> name := 'ConfigurationOf', t. >>>>>>>>> Gofer new >>>>>>>>> squeaksource: 'MetacelloRepository'; >>>>>>>>> package: name; >>>>>>>>> load. >>>>>>>>> (Smalltalk at: name asSymbol) perform: #loadDefault ]. >>>>>>>>> -=-=-=-=-=-=-=-=-= >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Alexandre >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Moose-dev mailing list >>>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Moose-dev mailing list >>>>>>>> Moose-dev at iam.unibe.ch >>>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>>> >>>>>>> -- >>>>>>> Simon >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Live like you mean it." >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "To lead is not to demand things, it is to make them happen." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Mon Jan 11 19:48:13 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 11 Jan 2010 15:48:13 -0300 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: The panel looks really cool! Can you give a brief HOWTO on using the new updating mechanism? Also, there is an issue: on creating, moving closing ... a browser I get a bunch of 'MessageNotUnderstood: receiver of "@" is nil' messages in the Transcript. On 10 Jan 2010, at 17:01, Tudor Girba wrote: > Hi, > > I implemented a Moose Panel based on Glamour. It integrates both the > list of models and the finder. You can get it by executing: > MoosePanel open. > > The list of models is now updated using a new basic means to update > a Glamour presentation. > > The importing actions are rendered as toolbar buttons based on the > specs from the MoosePaneCommand. The pane commands that do not > specify an icon, are rendered as menu that is spawned by pressing > the "..." toolbar button. > > Please let me know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From jfabry at dcc.uchile.cl Mon Jan 11 19:51:56 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 11 Jan 2010 15:51:56 -0300 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: <05ADBB3B-46A7-43F6-84F2-302399664343@dcc.uchile.cl> Forget that, my fault: I had an old Glamour browser open, hidden under a bunch of other windows. Closing that resolved the problem. Apologies for the spam ... On 11 Jan 2010, at 15:48, Johan Fabry wrote: > Also, there is an issue: on creating, moving closing ... a browser I > get a bunch of 'MessageNotUnderstood: receiver of "@" is nil' > messages in the Transcript. -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From Simon.Denier at inria.fr Mon Jan 11 18:18:48 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 11 Jan 2010 18:18:48 +0100 Subject: [Moose-dev] MOEasel: previous scripts in the menu... Message-ID: <3309ECAC-EE72-4296-B8AC-4E2355E10C42@inria.fr> Hi Alex The title says it all :) I like the way we can finally access common actions from the menu, as it enables discoverability. Why not add the 'previous scripts' command? -- Simon From tudor.girba at gmail.com Mon Jan 11 20:23:05 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 11 Jan 2010 20:23:05 +0100 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: <4DAE2F10-B2EB-4767-8023-E7A44B9D5D13@gmail.com> Hi, I will follow up with more details about the latest changes in Glamour. But, I still need to fix a couple of issues that I introduced lately. Cheers, Doru On 11 Jan 2010, at 19:48, Johan Fabry wrote: > The panel looks really cool! Can you give a brief HOWTO on using the > new updating mechanism? > > Also, there is an issue: on creating, moving closing ... a browser I > get a bunch of 'MessageNotUnderstood: receiver of "@" is nil' > messages in the Transcript. > > On 10 Jan 2010, at 17:01, Tudor Girba wrote: > >> Hi, >> >> I implemented a Moose Panel based on Glamour. It integrates both >> the list of models and the finder. You can get it by executing: >> MoosePanel open. >> >> The list of models is now updated using a new basic means to update >> a Glamour presentation. >> >> The importing actions are rendered as toolbar buttons based on the >> specs from the MoosePaneCommand. The pane commands that do not >> specify an icon, are rendered as menu that is spawned by pressing >> the "..." toolbar button. >> >> Please let me know what you think. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From tudor.girba at gmail.com Mon Jan 11 20:50:01 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 11 Jan 2010 20:50:01 +0100 Subject: [Moose-dev] glamour - work in progress Message-ID: <097E06E7-615A-43E3-9A89-8145502D3D37@gmail.com> Hi, I just wanted to let you know that the latest version of Glamour will bring up an unstable version. I will get back to you once it stabilizes. Cheers, Doru -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." From alexandre at bergel.eu Tue Jan 12 00:46:12 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 20:46:12 -0300 Subject: [Moose-dev] Re: mondrian text related tests In-Reply-To: <1820CAC1-0315-4AA0-9102-F4B87DBE7374@tudorgirba.com> References: <1820CAC1-0315-4AA0-9102-F4B87DBE7374@tudorgirba.com> Message-ID: Hi Doru, I cannot reproduce the problem. In my 10502 all the 182 tests are green. Cheers, Alexandre On 10 Jan 2010, at 10:59, Tudor Girba wrote: > Hi, > > Mondrian has a number of tests related to the bounds of text nodes. > I am not sure why these fail. Is it because they were created with a > specific font in mind? Alex? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Tue Jan 12 00:56:27 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 11 Jan 2010 20:56:27 -0300 Subject: [Moose-dev] Re: MOEasel: previous scripts in the menu... In-Reply-To: <3309ECAC-EE72-4296-B8AC-4E2355E10C42@inria.fr> References: <3309ECAC-EE72-4296-B8AC-4E2355E10C42@inria.fr> Message-ID: <29F37C36-DDD1-4245-AA40-244282FFA333@bergel.eu> Name: Mondrian-Alexandre_Bergel.336 Author: Alexandre Bergel Time: 11 January 2010, 8:55:58 pm UUID: 919b92f5-c1d5-4de1-9645-b4cc6fadf9b1 Ancestors: Mondrian-Alexandre_Bergel.335 ISSUE #278 The previous script action is now accessible from the MOEasel menu. Alexandre On 11 Jan 2010, at 14:18, Simon Denier wrote: > Hi Alex > > The title says it all :) > I like the way we can finally access common actions from the menu, > as it enables discoverability. Why not add the 'previous scripts' > command? > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Tue Jan 12 11:39:26 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 12 Jan 2010 11:39:26 +0100 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: On 10 janv. 2010, at 21:01, Tudor Girba wrote: > Hi, > > I implemented a Moose Panel based on Glamour. It integrates both the list of models and the finder. You can get it by executing: MoosePanel open. That's good news to see this panel finally going public! We should move more stuff to the toolbar (browseMeta, initialize meta descriptions...) I havent checked yet, but is there a way to create menu buttons in the toolbar (other thant the '...') Problem: the meta browser does not display anything. How is this related to the last changes in Glamour? > > The list of models is now updated using a new basic means to update a Glamour presentation. > > The importing actions are rendered as toolbar buttons based on the specs from the MoosePaneCommand. The pane commands that do not specify an icon, are rendered as menu that is spawned by pressing the "..." toolbar button. > > Please let me know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Tue Jan 12 11:58:33 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 12 Jan 2010 11:58:33 +0100 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: Hi Simon, >> Hi, >> >> I implemented a Moose Panel based on Glamour. It integrates both >> the list of models and the finder. You can get it by executing: >> MoosePanel open. > > > That's good news to see this panel finally going public! We should > move more stuff to the toolbar (browseMeta, initialize meta > descriptions...) > > I havent checked yet, but is there a way to create menu buttons in > the toolbar (other thant the '...') Sure. This was always possible by adding actions to the browser. > Problem: the meta browser does not display anything. How is this > related to the last changes in Glamour? Very related. Glamour is under heavy construction. The work is related to the introduction of a composite presentation and to getting clearer semantics of how presentations are passed around. I hope I can pull it through this week, if not, I will revert to a previous version :). Cheers, Doru > >> >> The list of models is now updated using a new basic means to update >> a Glamour presentation. >> >> The importing actions are rendered as toolbar buttons based on the >> specs from the MoosePaneCommand. The pane commands that do not >> specify an icon, are rendered as menu that is spawned by pressing >> the "..." toolbar button. >> >> Please let me know what you think. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From jfabry at dcc.uchile.cl Tue Jan 12 14:54:22 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 12 Jan 2010 10:54:22 -0300 Subject: [Moose-dev] Re: MooseGlamorousPanel In-Reply-To: References: Message-ID: On 12 Jan 2010, at 07:58, Tudor Girba wrote: > Very related. Glamour is under heavy construction. The work is > related to the introduction of a composite presentation and to > getting clearer semantics of how presentations are passed around. I > hope I can pull it through this week, if not, I will revert to a > previous version :). Hi Doru, I'm all for the above, you have my (moral) support! :-) -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From simon.denier at inria.fr Wed Jan 13 16:13:22 2010 From: simon.denier at inria.fr (Simon Denier) Date: Wed, 13 Jan 2010 16:13:22 +0100 Subject: [Moose-dev] Cyclic dependencies between packages in Glamour Message-ID: <0A687CFA-B608-4712-BBE0-2FA88B1CDE5C@inria.fr> Hi there With Jannik, we are looking at cyclic dependencies between Moose packages. Here a few things about Glamour 1) Glamour-Core <-> Glamour-Helpers Glamour-Helpers extends Object with asGlamourousMultivalue, which references GLMMultiValue defined in Glamour-Core (Glamour-Core itself relying on Glamour-Helpers of course). Suggestions: - make #asGlamourousMultivalue an extension of Glamour-Core or - move GLMMultiValue in Glamour-Helpers Neither should create an unwanted dependency 2) Glamour-Browsers <-> Glamour-Scripting There are two methods initializeScriptingDefaults in the package Glamour-Browsers which could be moved to Glamour-Scripting. This should remove all circuits between packages in Glamour. -- Simon From tudor.girba at gmail.com Wed Jan 13 17:49:51 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 13 Jan 2010 17:49:51 +0100 Subject: [Moose-dev] Re: Cyclic dependencies between packages in Glamour In-Reply-To: <0A687CFA-B608-4712-BBE0-2FA88B1CDE5C@inria.fr> References: <0A687CFA-B608-4712-BBE0-2FA88B1CDE5C@inria.fr> Message-ID: <158E6B26-7E13-44C1-BE7E-67672A7197E7@gmail.com> Thanks for the report. I created an issue: http://code.google.com/p/moose-technology/issues/detail?id=280 Cheers, Doru On 13 Jan 2010, at 16:13, Simon Denier wrote: > Hi there > > With Jannik, we are looking at cyclic dependencies between Moose > packages. Here a few things about Glamour > > 1) Glamour-Core <-> Glamour-Helpers > Glamour-Helpers extends Object with asGlamourousMultivalue, which > references GLMMultiValue defined in Glamour-Core (Glamour-Core > itself relying on Glamour-Helpers of course). > Suggestions: > - make #asGlamourousMultivalue an extension of Glamour-Core > or > - move GLMMultiValue in Glamour-Helpers > Neither should create an unwanted dependency > > 2) Glamour-Browsers <-> Glamour-Scripting > There are two methods initializeScriptingDefaults in the package > Glamour-Browsers which could be moved to Glamour-Scripting. > > This should remove all circuits between packages in Glamour. > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" From tudor.girba at gmail.com Wed Jan 13 17:53:38 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 13 Jan 2010 17:53:38 +0100 Subject: [Moose-dev] Re: Cyclic dependencies between packages in Glamour In-Reply-To: <158E6B26-7E13-44C1-BE7E-67672A7197E7@gmail.com> References: <0A687CFA-B608-4712-BBE0-2FA88B1CDE5C@inria.fr> <158E6B26-7E13-44C1-BE7E-67672A7197E7@gmail.com> Message-ID: <3915DA8B-EB1C-4C10-B39D-B1D59BFD866E@gmail.com> It should be fixed now :) Cheers, Doru On 13 Jan 2010, at 17:49, Tudor Girba wrote: > Thanks for the report. > > I created an issue: > http://code.google.com/p/moose-technology/issues/detail?id=280 > > Cheers, > Doru > > > On 13 Jan 2010, at 16:13, Simon Denier wrote: > >> Hi there >> >> With Jannik, we are looking at cyclic dependencies between Moose >> packages. Here a few things about Glamour >> >> 1) Glamour-Core <-> Glamour-Helpers >> Glamour-Helpers extends Object with asGlamourousMultivalue, which >> references GLMMultiValue defined in Glamour-Core (Glamour-Core >> itself relying on Glamour-Helpers of course). >> Suggestions: >> - make #asGlamourousMultivalue an extension of Glamour-Core >> or >> - move GLMMultiValue in Glamour-Helpers >> Neither should create an unwanted dependency >> >> 2) Glamour-Browsers <-> Glamour-Scripting >> There are two methods initializeScriptingDefaults in the package >> Glamour-Browsers which could be moved to Glamour-Scripting. >> >> This should remove all circuits between packages in Glamour. >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From Simon.Denier at inria.fr Wed Jan 13 18:08:34 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 13 Jan 2010 18:08:34 +0100 Subject: [Moose-dev] inferNamespaceParentsBasedOnNames Message-ID: I never understood the purpose of this method. I see that is is in Moose-Core. Should it be placed in Famix-Extensions or even better, Famix-Java? It would remove two direct cycles :) (between Moose-Core, Famix-Core, Famix-Extensions) BTW, FamixAnnotationType>>annotatedEntities should also be moved to Famix-Java. -- Simon From tudor.girba at gmail.com Wed Jan 13 18:18:06 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 13 Jan 2010 18:18:06 +0100 Subject: [Moose-dev] Re: inferNamespaceParentsBasedOnNames In-Reply-To: References: Message-ID: <0B0E0CD2-E8C3-4259-BF73-468243BEF745@gmail.com> Hi, On 13 Jan 2010, at 18:08, Simon Denier wrote: > I never understood the purpose of this method. The idea is that Java exporters do not provide nesting of namespaces, while we can leverage this information. So, I use this script to create a nesting of namespaces. > I see that is is in Moose-Core. Should it be placed in Famix- > Extensions or even better, Famix-Java? It would remove two direct > cycles :) (between Moose-Core, Famix-Core, Famix-Extensions) Indeed, it should not be in Moose-Core. It should be in Famix-Core, because it is actually not specific to Java, but only to the naming conventions of namespaces. > BTW, FamixAnnotationType>>annotatedEntities should also be moved to > Famix-Java. Not really. This should be useful as well to model Smalltalk pragmas. Cheers, Doru -- www.tudorgirba.com "When people care, great things can happen." From Simon.Denier at inria.fr Wed Jan 13 18:33:06 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 13 Jan 2010 18:33:06 +0100 Subject: [Moose-dev] Re: inferNamespaceParentsBasedOnNames In-Reply-To: <0B0E0CD2-E8C3-4259-BF73-468243BEF745@gmail.com> References: <0B0E0CD2-E8C3-4259-BF73-468243BEF745@gmail.com> Message-ID: <8FB2BCFD-AA08-4196-A934-4059A346DB6E@inria.fr> On 13 janv. 2010, at 18:18, Tudor Girba wrote: > Hi, > > On 13 Jan 2010, at 18:08, Simon Denier wrote: > >> I never understood the purpose of this method. > > The idea is that Java exporters do not provide nesting of namespaces, while we can leverage this information. So, I use this script to create a nesting of namespaces. > >> I see that is is in Moose-Core. Should it be placed in Famix-Extensions or even better, Famix-Java? It would remove two direct cycles :) (between Moose-Core, Famix-Core, Famix-Extensions) > > Indeed, it should not be in Moose-Core. It should be in Famix-Core, because it is actually not specific to Java, but only to the naming conventions of namespaces. cant be Famix-Core, but can be Famix-Extensions > >> BTW, FamixAnnotationType>>annotatedEntities should also be moved to Famix-Java. > > Not really. This should be useful as well to model Smalltalk pragmas. Then, the class FamixAnnotationType and related should be defined in another package than Famix-Java. -- Simon From tudor.girba at gmail.com Wed Jan 13 20:26:54 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 13 Jan 2010 20:26:54 +0100 Subject: [Moose-dev] Re: inferNamespaceParentsBasedOnNames In-Reply-To: <8FB2BCFD-AA08-4196-A934-4059A346DB6E@inria.fr> References: <0B0E0CD2-E8C3-4259-BF73-468243BEF745@gmail.com> <8FB2BCFD-AA08-4196-A934-4059A346DB6E@inria.fr> Message-ID: <65D9344C-A8C4-43FF-9813-F41E3F3DF1F6@gmail.com> Hi, >> Hi, >> >> On 13 Jan 2010, at 18:08, Simon Denier wrote: >> >>> I never understood the purpose of this method. >> >> The idea is that Java exporters do not provide nesting of >> namespaces, while we can leverage this information. So, I use this >> script to create a nesting of namespaces. >> >>> I see that is is in Moose-Core. Should it be placed in Famix- >>> Extensions or even better, Famix-Java? It would remove two direct >>> cycles :) (between Moose-Core, Famix-Core, Famix-Extensions) >> >> Indeed, it should not be in Moose-Core. It should be in Famix-Core, >> because it is actually not specific to Java, but only to the naming >> conventions of namespaces. > > cant be Famix-Core, but can be Famix-Extensions You are right, it's Famix-Extensions. >> >>> BTW, FamixAnnotationType>>annotatedEntities should also be moved >>> to Famix-Java. >> >> Not really. This should be useful as well to model Smalltalk pragmas. > > Then, the class FamixAnnotationType and related should be defined in > another package than Famix-Java. Right :). Probably Famix-Extensions. Cheers, Doru -- www.tudorgirba.com "Reasonable is what we are accustomed with." From Simon.Denier at inria.fr Thu Jan 14 13:23:24 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 14 Jan 2010 13:23:24 +0100 Subject: [Moose-dev] Issue 287: allModelPackages does not retrieve pure extension packages Message-ID: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> Hi there I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension packages One proposed solution is to set the isStub flag on package/namespace imported because of stub classes (i.e., not specifically requested by the user). For now, this is a smalltalk specific problem. However, it would be good if the semantic is clearly agreed between the importers. -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Thu Jan 14 20:24:14 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 14 Jan 2010 16:24:14 -0300 Subject: [Moose-dev] [Mondrian] Thought about MOGraphElement Message-ID: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> Hi! Now that some of you are building complex and interactive visualizations, I feel the need to add some annotations on things that are displayed. I am not talking about the model here, but really annotation on the view. For example, assume that I want the size of a node to increase (e.g., to see its method inside) when I double click on it. Where do I store the information that the node has been expanded ? I started to have this need with popupView:. A node needs to know whether its popupview is on or not. I added a variable popup in MOGraphElement which solve this. But more complex interaction requires a generalization of this. I am about to introduce a variable annotation in MOGraphElement that will lazily create a dictionary. Any comment? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Thu Jan 14 22:19:29 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 14 Jan 2010 22:19:29 +0100 Subject: [Moose-dev] Re: [Mondrian] Thought about MOGraphElement In-Reply-To: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> References: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> Message-ID: <676D026D-4447-44EF-A994-850AD5696E49@inria.fr> it is probably not related. but today when coding with jr for a new version of blueprint we saw that it would be nice to have the possibility to share information either other all the packageBlueprints (we did that using a class) or between all the blueprints displayed inside a canvas. (this was for the color of the marked surfaces and knowing which one was selected). For the marked surface we took the easy road: we said ok the color table can be a class var and we will have one table for all the blueprint. Now for the selection (when we click on a bp head ) may be this is better to have the effect local to easel. So what I want to say is that your annotations should be accessible from the scripts and it would be good to have - node - view - all nodes Stef > Hi! > > Now that some of you are building complex and interactive visualizations, I feel the need to add some annotations on things that are displayed. I am not talking about the model here, but really annotation on the view. For example, assume that I want the size of a node to increase (e.g., to see its method inside) when I double click on it. Where do I store the information that the node has been expanded ? > > I started to have this need with popupView:. A node needs to know whether its popupview is on or not. I added a variable popup in MOGraphElement which solve this. But more complex interaction requires a generalization of this. > > I am about to introduce a variable annotation in MOGraphElement that will lazily create a dictionary. > > Any comment? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Fri Jan 15 00:05:29 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Thu, 14 Jan 2010 20:05:29 -0300 Subject: [Moose-dev] Re: [Mondrian] Thought about MOGraphElement In-Reply-To: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> References: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> Message-ID: <794CE90C-29BB-4E65-B479-76BCADA18424@dcc.uchile.cl> Hi, No to be negative, but I actually like the way I do it now, which is as follows: - I visualize famix elements (namespaces, classes, methods, ...) - each of these implements a method that is responsible for adding its representation to the view - each of these has a status (a famix property) responsible for keeping its visualisation state I like this because - I dont need to add vars to the classes - the visualisation state is permanent: if I do a full refresh nothing is lost - closing-opeing an element returns the element to its previous state although all the contained entities are redrawn The only (minor) downside to this is that if I would have 2 visualisations on the same data they will show the same expansion state. I see no problem with this. Now the popupview is interesting as well. Are there any other use cases ? On 14 Jan 2010, at 16:24, Alexandre Bergel wrote: > Hi! > > Now that some of you are building complex and interactive > visualizations, I feel the need to add some annotations on things > that are displayed. I am not talking about the model here, but > really annotation on the view. For example, assume that I want the > size of a node to increase (e.g., to see its method inside) when I > double click on it. Where do I store the information that the node > has been expanded ? > > I started to have this need with popupView:. A node needs to know > whether its popupview is on or not. I added a variable popup in > MOGraphElement which solve this. But more complex interaction > requires a generalization of this. > > I am about to introduce a variable annotation in MOGraphElement that > will lazily create a dictionary. > > Any comment? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Fri Jan 15 03:45:08 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 03:45:08 +0100 Subject: [Moose-dev] glamour update Message-ID: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> Hi, Glamour is in a usable state again. The one thing is not working correctly is the update of the overall browser from inside the browser. For example, the mechanism in the MooseModel browseMeta to select a property and then trigger "Focus" from the contextual menu does not update the properties pane again. Things will continue to move in the next period, but it already looks pretty much Ok. Here are a couple of major changes: 1. A pane now can control the rendering of multiple presentations through a CompositePresentation. You can now have different arrangements: tabbed, accordion or stacked. You can find an example at: GLMBasicExamples new differentComposites openOn: (1 to: 100) 2. You can specify titles for a composite and this gets rendered as a groupbox 3. New syntax. To control the composite I introduced a new syntax. - "browser showOn: ; from: ; using: [ browser list]" -> "browser transmit from: ; to: ; andShow: [ :a | a list ]" - "browser sendTo: from:" -> "browser transmit from: ; to:" 4. Simple transmissions and bundle transmissions can have multiple origins and can define transformations per origin port. For example you can have: browser transmit from: #one ; from: #two transformed: [:x | ...] ; to: #three. 5. Presentations can now update using a basic mechanism (first implemented by Jorge and Philipp). For example: a list updateYourselfOn: SomeAnnouncement from: [:entity | some announcer]; The only catch here is that the entity object should point to the objects that gets changed. You can also force an update explicitly from an action: a list act: [:presentation | presentation update] entitled: 'some action'. 6. When updating a presentation, it might be that the selection from the old presentation does not make sense in the new context. To enable a checking you can now specify that you want validation for each change in the ports (in particular for selection). For example: a list shouldValidate: true 7. Finder can now properly embed a browser. This is actually pretty neat :) 8. Finder now remembers the title of the last active presentation and it will favor this one in the new tab Please have a look and let me know if you encounter problems. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." From tudor.girba at gmail.com Fri Jan 15 03:51:58 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 03:51:58 +0100 Subject: [Moose-dev] moose finder and meta browser update Message-ID: Hi, I played a bit with the finder and the meta browser to add titles for each pane. You need the latest Moose-Finder and Glamour for this. MoosePanel open. MooseModel browseMeta. Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish." From tudor.girba at gmail.com Fri Jan 15 10:27:21 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 10:27:21 +0100 Subject: [Moose-dev] Re: Issue 287: allModelPackages does not retrieve pure extension packages In-Reply-To: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> References: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> Message-ID: <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> Hi Simon, A long time ago, we decided that isStub should reflect exactly the intention of an analyst of including that entity or not. So, the interpretation would be that if we choose to import an explicit package A, then all packages that extend the classes from A should be stub packages. If we choose the classes in A then all the packages that extend these classes will not be stub. If more semantics are wanted, we could have other properties, like isDerivedAsStub (bad name :)). Maybe an idea would be to add an option in the importing context to allow us to specify what kind of strategy we would want for isStub. Cheers, Doru On 14 Jan 2010, at 13:23, Simon Denier wrote: > Hi there > > I would like your opinion on Issue 287: allModelPackages does not > retrieve pure extension packages > > One proposed solution is to set the isStub flag on package/namespace > imported because of stub classes (i.e., not specifically requested > by the user). > For now, this is a smalltalk specific problem. However, it would be > good if the semantic is clearly agreed between the importers. > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." From stephane.ducasse at inria.fr Fri Jan 15 10:53:05 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 15 Jan 2010 10:53:05 +0100 Subject: [Moose-dev] Re: Issue 287: allModelPackages does not retrieve pure extension packages In-Reply-To: <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> References: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> Message-ID: <31906478-CA03-42F4-89FB-9C4A76F44FC8@inria.fr> On Jan 15, 2010, at 10:27 AM, Tudor Girba wrote: > Hi Simon, > > A long time ago, we decided that isStub should reflect exactly the intention of an analyst of including that entity or not. > > So, the interpretation would be that if we choose to import an explicit package A, then all packages that extend the classes from A should be stub packages. If we choose the classes in A then all the packages that extend these classes will not be stub. > > If more semantics are wanted, we could have other properties, like isDerivedAsStub (bad name :)). > > Maybe an idea would be to add an option in the importing context to allow us to specify what kind of strategy we would want for isStub. I would not change the meaning of isStub. And add a new property like I suggested to hani and doru :) to denote that the entity is not completely imported. > > Cheers, > Doru > > > On 14 Jan 2010, at 13:23, Simon Denier wrote: > >> Hi there >> >> I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension packages >> >> One proposed solution is to set the isStub flag on package/namespace imported because of stub classes (i.e., not specifically requested by the user). >> For now, this is a smalltalk specific problem. However, it would be good if the semantic is clearly agreed between the importers. >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Fri Jan 15 11:00:17 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 15 Jan 2010 11:00:17 +0100 Subject: [Moose-dev] Re: Issue 287: allModelPackages does not retrieve pure extension packages In-Reply-To: <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> References: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> Message-ID: On 15 janv. 2010, at 10:27, Tudor Girba wrote: > Hi Simon, > > A long time ago, we decided that isStub should reflect exactly the intention of an analyst of including that entity or not. > > So, the interpretation would be that if we choose to import an explicit package A, then all packages that extend the classes from A should be stub packages. If we choose the classes in A then all the packages that extend these classes will not be stub. Not sure I get the rationale for the second case. I know that there is this ambiguity between things such as isStub and isComplete. At one point, St?phane started to do something about this but we never completely clarified nor finished. - isStub indicates that the entity is imported through reference by another entity, and not explicitely chosen by the analyst as you say - isComplete should indicate that all properties in this entity are not imported (for example, a class can be a non-stub yet not complete if we choose not to import method body) - isStub => not isComplete Anyway, in the case of packages and given the current importer, we are always in the first case : we explicitly chose packages to import. All other packages should be stub. > > If more semantics are wanted, we could have other properties, like isDerivedAsStub (bad name :)). > > Maybe an idea would be to add an option in the importing context to allow us to specify what kind of strategy we would want for isStub. > > Cheers, > Doru > > > On 14 Jan 2010, at 13:23, Simon Denier wrote: > >> Hi there >> >> I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension packages >> >> One proposed solution is to set the isStub flag on package/namespace imported because of stub classes (i.e., not specifically requested by the user). >> For now, this is a smalltalk specific problem. However, it would be good if the semantic is clearly agreed between the importers. >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From tudor.girba at gmail.com Fri Jan 15 11:11:25 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 11:11:25 +0100 Subject: [Moose-dev] Re: Issue 287: allModelPackages does not retrieve pure extension packages In-Reply-To: References: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> Message-ID: <760C7159-AC8F-4DBB-A14C-97AA756CA642@gmail.com> Hi Simon, >> Hi Simon, >> >> A long time ago, we decided that isStub should reflect exactly the >> intention of an analyst of including that entity or not. >> >> So, the interpretation would be that if we choose to import an >> explicit package A, then all packages that extend the classes from >> A should be stub packages. If we choose the classes in A then all >> the packages that extend these classes will not be stub. > > Not sure I get the rationale for the second case. I actually meant that "if we explicitly choose directly classes (and not packages) that happen to also be in A then all the packages that extend these classes will not be stub " > I know that there is this ambiguity between things such as isStub > and isComplete. At one point, St?phane started to do something about > this but we never completely clarified nor finished. > - isStub indicates that the entity is imported through reference by > another entity, and not explicitely chosen by the analyst as you say > - isComplete should indicate that all properties in this entity are > not imported (for example, a class can be a non-stub yet not > complete if we choose not to import method body) > - isStub => not isComplete I do not like the implication of isComplete, because a model will not be complete unless it contains all details of the subject. > Anyway, in the case of packages and given the current importer, we > are always in the first case : we explicitly chose packages to > import. All other packages should be stub. Yes. Doru > >> >> If more semantics are wanted, we could have other properties, like >> isDerivedAsStub (bad name :)). >> >> Maybe an idea would be to add an option in the importing context to >> allow us to specify what kind of strategy we would want for isStub. >> >> Cheers, >> Doru >> >> >> On 14 Jan 2010, at 13:23, Simon Denier wrote: >> >>> Hi there >>> >>> I would like your opinion on Issue 287: allModelPackages does not >>> retrieve pure extension packages >>> >>> One proposed solution is to set the isStub flag on package/ >>> namespace imported because of stub classes (i.e., not specifically >>> requested by the user). >>> For now, this is a smalltalk specific problem. However, it would >>> be good if the semantic is clearly agreed between the importers. >>> >>> -- >>> Simon >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "One cannot do more than one can do." From tudor.girba at gmail.com Fri Jan 15 11:29:54 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 11:29:54 +0100 Subject: [Moose-dev] Re: Questions about Glamour In-Reply-To: References: <21D317D0-59E9-49E8-8E6C-724338BF3292@inria.fr> Message-ID: <35173637-9890-4B49-A1A0-1A6FB24B0109@gmail.com> Hi Jannik, You can now use: a tree rootsExpanded. a tree allExpanded. Cheers, Doru On 15 Jan 2010, at 03:19, Tudor Girba wrote: > Hi Jannik, > > 1. It is not yet possible to do that, but I created an issue: > http://code.google.com/p/moose-technology/issues/detail?id=292 > > 2. To me it looks like it should work if the system variable points > to the root object that was affected by the change. In any case, you > do not have to do the announce dance when you want to explicitly > force an update. Just send #update to the presentation (the first > parameter of the act block). > > If it does not work, I would need an executable code including the > objects. Best would be to create a dummy example with simple objects > (like it is in the GLMBasicExamples). > > Cheers, > Doru > > > On 14 Jan 2010, at 16:59, Laval Jannik wrote: > >> Hi Doru, >> sorry for duplicated mail. >> >> Here is a part of my code which does not work. >> >> ===== >> | browser announcer | >> >> browser := GLMTabulator new. >> announcer := Announcer new. >> >> browser column: #versions. >> >> browser showOn: #versions; using: [ >> browser tree >> format:[:system | system name]; >> display: [:each | each orionModels select:[:om | om parentModel >> = nil]]; >> children: [:each | each childrenModel]; >> act: [:each | each selection createNewChildVersion. announcer >> announce: OrionModelAdded] entitled: 'create a child'; >> updateYourselfOn: OrionModelAdded from: [announcer]; >> shouldValidate: true; >> registerAnnouncements. >> ]. >> >> ^ browser >> ========== >> >> Cheers, >> Jannik >> >> On Jan 14, 2010, at 16:53 , Laval Jannik wrote: >> >>> Hi Doru, >>> >>> I have two questions for you about Glamour :) >>> >>> - the simple one: is it possible to open a tree-pane with an >>> opened tree: in my case, I always use the last item of the tree, >>> so it is slow to open each level. >>> >>> - the second one: I try to use updateYourselfOn:from: on a treePane. >>> In a previous version of Glamour (I don't know which one, but a >>> recent one), it works but it is unstable. In the latest version of >>> Glamour, it does not work. >>> In your example, this method works on a list-pane. >>> The question is: do you know this issue ? if no, I can try to do >>> an example... but maybe it is my code which does not work also... >>> >>> Cheers, >>> >>> --- >>> Jannik Laval >>> --- >>> >> >> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > -- www.tudorgirba.com "Presenting is storytelling." From alexandre at bergel.eu Fri Jan 15 13:35:09 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 15 Jan 2010 09:35:09 -0300 Subject: [Moose-dev] Re: glamour update In-Reply-To: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> References: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> Message-ID: <7B16D5D9-319C-4F36-8E63-6C036ACD1E4E@bergel.eu> Hi! > 1. A pane now can control the rendering of multiple presentations > through a CompositePresentation. You can now have different > arrangements: tabbed, accordion or stacked. You can find an example > at: > GLMBasicExamples new differentComposites openOn: (1 to: 100) I obtain the following: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture 4.png Type: image/png Size: 25494 bytes Desc: not available URL: -------------- next part -------------- I do not know whether this is the expected behavior. Before executing the expression, I did a Gofer new squeaksource: 'Glamour'; addPackage: 'ConfigurationOfGlamour'; load. (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Fri Jan 15 13:43:27 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 13:43:27 +0100 Subject: [Moose-dev] Re: glamour update In-Reply-To: <7B16D5D9-319C-4F36-8E63-6C036ACD1E4E@bergel.eu> References: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> <7B16D5D9-319C-4F36-8E63-6C036ACD1E4E@bergel.eu> Message-ID: Please try in a fresh image. Cheers, Doru On 15 Jan 2010, at 13:35, Alexandre Bergel wrote: > Hi! > >> 1. A pane now can control the rendering of multiple presentations >> through a CompositePresentation. You can now have different >> arrangements: tabbed, accordion or stacked. You can find an example >> at: >> GLMBasicExamples new differentComposites openOn: (1 to: 100) > > > I obtain the following: > > > I do not know whether this is the expected behavior. Before > executing the expression, I did a > Gofer new > squeaksource: 'Glamour'; > addPackage: 'ConfigurationOfGlamour'; > load. > (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault > > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What we can governs what we wish." From tudor.girba at gmail.com Fri Jan 15 15:44:33 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 15:44:33 +0100 Subject: [Moose-dev] updating mondrian Message-ID: Hi Alex, I am trying to debug the problem of embedding Mondrian in Glamour and I have a question. Why exactly does Mondrian need to know the window to update? Why is it not enough to just know the Canvas morph? Cheers, Doru -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." From alexandre at bergel.eu Fri Jan 15 16:29:06 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 15 Jan 2010 12:29:06 -0300 Subject: [Moose-dev] Re: updating mondrian In-Reply-To: References: Message-ID: <81F5D752-05EB-4728-80E8-C351476D75C7@bergel.eu> Hi! After an interaction from the user (e.g., node dragging, node selection), the announcement MOContentChanged is emitted by MORoot>>updateWindow. When I scroll an MOCanvas (e.g., as it occurs when in an easel or a view renderer the picture is larger than the visible window), when a window containing a MOCanvas is dragged, moved, resize, the event WindowAnnouncement is emitted. I made a dedicated method, called MOViewRenderer>>setDefaultHandlerForWindow: systemWindow that register relevant announcement handlers for a number of announcement, including node dragging, key down, MOContentChanged and WindowAnnouncement. The only thing to do to have a proper update should be to use setDefaultHandlerForWindow: Cheers, Alexandre NB: When writing this email, I realized that the handler of WindowAnnouncement was set in a different location than MOContentChanged, which is odd. I produced a new version of Mondrian that reflect this. NB2: now that I thinking about this, maybe MORoot>>updateWindow is not an ideal name since the root is not aware of the window in which it is (indirectly) embedded. On 15 Jan 2010, at 11:44, Tudor Girba wrote: > Hi Alex, > > I am trying to debug the problem of embedding Mondrian in Glamour > and I have a question. > > Why exactly does Mondrian need to know the window to update? Why is > it not enough to just know the Canvas morph? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of > problem understanding." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Fri Jan 15 16:41:17 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 15 Jan 2010 12:41:17 -0300 Subject: [Moose-dev] Re: [Mondrian] Thought about MOGraphElement In-Reply-To: <794CE90C-29BB-4E65-B479-76BCADA18424@dcc.uchile.cl> References: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> <794CE90C-29BB-4E65-B479-76BCADA18424@dcc.uchile.cl> Message-ID: <5EA671E7-26B2-4843-8DC5-5834AD7EA38E@bergel.eu> > No to be negative, but I actually like the way I do it now, which is > as follows: > - I visualize famix elements (namespaces, classes, methods, ...) > - each of these implements a method that is responsible for adding > its representation to the view Yep, this is the way that we used in Moose > - each of these has a status (a famix property) responsible for > keeping its visualisation state But you're relying on properties in the model. Which could not always be the case. For example, imagine I deal now with numbers, plain instance of SmallInteger. Numbers cannot be annotated. Where would I store the fact that a node is expanded or not? Moreover, by using the properties of FAMIX objects to store the "state" of the visualization (i.e., node that are expanded), your model is somehow aware of the visualization. This is not what can be called a clean separation of concerns :-) > I like this because > - I dont need to add vars to the classes Right, but your model support properties. > - the visualisation state is permanent: if I do a full refresh > nothing is lost Good point! This is something I will have to take care of > - closing-opeing an element returns the element to its previous > state although all the contained entities are redrawn What I am proposing will have the same benefit > The only (minor) downside to this is that if I would have 2 > visualisations on the same data they will show the same expansion > state. I see no problem with this. this is a no-surprise since you have one unique model for two different visualization and your model is aware of your visualization. > Now the popupview is interesting as well. Are there any other use > cases ? Node expansion is one. Another is highlighting. For example. Try this: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= view interaction highlightWhenOver: [:v | {v - 1 . v + 1. v + 4 . v - 4}]. view shape rectangle width: 40; height: 30; withText. view nodes: (1 to: 16). view gridLayout gapSize: 2. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= When the mouse leaves a node, it set back the border to black! (set in MOAnnouncer>>highlightWhenOver:). And if you want to highlight nodes that have a non black border color, then the highlight will not behave the way it should be. The annotation mechanism should not have any impact on your existing code by the way. More I think about it, more I am think this is the way it should be. Cheers, Alexandre > > On 14 Jan 2010, at 16:24, Alexandre Bergel wrote: > >> Hi! >> >> Now that some of you are building complex and interactive >> visualizations, I feel the need to add some annotations on things >> that are displayed. I am not talking about the model here, but >> really annotation on the view. For example, assume that I want the >> size of a node to increase (e.g., to see its method inside) when I >> double click on it. Where do I store the information that the node >> has been expanded ? >> >> I started to have this need with popupView:. A node needs to know >> whether its popupview is on or not. I added a variable popup in >> MOGraphElement which solve this. But more complex interaction >> requires a generalization of this. >> >> I am about to introduce a variable annotation in MOGraphElement >> that will lazily create a dictionary. >> >> Any comment? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Fri Jan 15 21:05:11 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 21:05:11 +0100 Subject: [Moose-dev] Re: updating mondrian In-Reply-To: <81F5D752-05EB-4728-80E8-C351476D75C7@bergel.eu> References: <81F5D752-05EB-4728-80E8-C351476D75C7@bergel.eu> Message-ID: <5376830C-2ACA-44A4-99EC-12D1D6809143@gmail.com> Hi Alex, That is all fine, but the problem is that I now have to write: view setDefaultHandlerForWindow: window. The problem is that window is a special morph and it is not meant to be embedded in another morph. It would be much better if for example the canvas would be in a more regular morph (maybe a panel or even in the scroller) and this container to raise the announcement. Like this I can build a Mondrian morph and then place it in any context and it would still work. As it is now, I have to always have access to the window which means that I cannot just construct the Mondrian morph as standalone. Would that not work? Cheers, Doru On 15 Jan 2010, at 16:29, Alexandre Bergel wrote: > Hi! > > After an interaction from the user (e.g., node dragging, node > selection), the announcement MOContentChanged is emitted by > MORoot>>updateWindow. > When I scroll an MOCanvas (e.g., as it occurs when in an easel or a > view renderer the picture is larger than the visible window), when a > window containing a MOCanvas is dragged, moved, resize, the event > WindowAnnouncement is emitted. > > I made a dedicated method, called > MOViewRenderer>>setDefaultHandlerForWindow: systemWindow that > register relevant announcement handlers for a number of > announcement, including node dragging, key down, MOContentChanged > and WindowAnnouncement. > > The only thing to do to have a proper update should be to use > setDefaultHandlerForWindow: > > Cheers, > Alexandre > > NB: When writing this email, I realized that the handler of > WindowAnnouncement was set in a different location than > MOContentChanged, which is odd. I produced a new version of Mondrian > that reflect this. > > NB2: now that I thinking about this, maybe MORoot>>updateWindow is > not an ideal name since the root is not aware of the window in which > it is (indirectly) embedded. > > > On 15 Jan 2010, at 11:44, Tudor Girba wrote: > >> Hi Alex, >> >> I am trying to debug the problem of embedding Mondrian in Glamour >> and I have a question. >> >> Why exactly does Mondrian need to know the window to update? Why is >> it not enough to just know the Canvas morph? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of >> problem understanding." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From stephane.ducasse at inria.fr Fri Jan 15 21:20:01 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 15 Jan 2010 21:20:01 +0100 Subject: [Moose-dev] Re: Issue 287: allModelPackages does not retrieve pure extension packages In-Reply-To: <760C7159-AC8F-4DBB-A14C-97AA756CA642@gmail.com> References: <33C6EAAC-9BE0-4DD5-BB7C-181E8C806DBA@inria.fr> <0B92289A-C108-44C6-8760-2494D1BD7D8F@gmail.com> <760C7159-AC8F-4DBB-A14C-97AA756CA642@gmail.com> Message-ID: >>> Hi Simon, >>> >>> A long time ago, we decided that isStub should reflect exactly the intention of an analyst of including that entity or not. >>> >>> So, the interpretation would be that if we choose to import an explicit package A, then all packages that extend the classes from A should be stub packages. If we choose the classes in A then all the packages that extend these classes will not be stub. >> >> Not sure I get the rationale for the second case. > > I actually meant that "if we explicitly choose directly classes (and not packages) that happen to also be in A then all the packages that extend these classes will not be stub " > >> I know that there is this ambiguity between things such as isStub and isComplete. At one point, St?phane started to do something about this but we never completely clarified nor finished. yes pharo + project writing is sucking all my time. >> - isStub indicates that the entity is imported through reference by another entity, and not explicitely chosen by the analyst as you say >> - isComplete should indicate that all properties in this entity are not imported (for example, a class can be a non-stub yet not complete if we choose not to import method body) >> - isStub => not isComplete > > I do not like the implication of isComplete, because a model will not be complete unless it contains all details of the subject. If we look in the archive I imagine I suggested something like uncomplete or something like that to hani. > >> Anyway, in the case of packages and given the current importer, we are always in the first case : we explicitly chose packages to import. All other packages should be stub. > > Yes. > > Doru > >> >>> >>> If more semantics are wanted, we could have other properties, like isDerivedAsStub (bad name :)). >>> >>> Maybe an idea would be to add an option in the importing context to allow us to specify what kind of strategy we would want for isStub. >>> >>> Cheers, >>> Doru >>> >>> >>> On 14 Jan 2010, at 13:23, Simon Denier wrote: >>> >>>> Hi there >>>> >>>> I would like your opinion on Issue 287: allModelPackages does not retrieve pure extension packages >>>> >>>> One proposed solution is to set the isStub flag on package/namespace imported because of stub classes (i.e., not specifically requested by the user). >>>> For now, this is a smalltalk specific problem. However, it would be good if the semantic is clearly agreed between the importers. >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of problem understanding." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor at tudorgirba.com Fri Jan 15 21:45:42 2010 From: tudor at tudorgirba.com (Tudor Girba) Date: Fri, 15 Jan 2010 21:45:42 +0100 Subject: [Moose-dev] famix changes related to modifiers Message-ID: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> Hi, I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. Did I miss something? In general, we have to be more careful with changes at such core levels :) Cheers, Doru -- www.tudorgirba.com "One cannot do more than one can do." From jfabry at dcc.uchile.cl Fri Jan 15 21:51:09 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Fri, 15 Jan 2010 17:51:09 -0300 Subject: [Moose-dev] Re: [Mondrian] Thought about MOGraphElement In-Reply-To: <5EA671E7-26B2-4843-8DC5-5834AD7EA38E@bergel.eu> References: <00D5DAA8-7E05-4878-93F7-59413B122FAD@bergel.eu> <794CE90C-29BB-4E65-B479-76BCADA18424@dcc.uchile.cl> <5EA671E7-26B2-4843-8DC5-5834AD7EA38E@bergel.eu> Message-ID: On 15 Jan 2010, at 12:41, Alexandre Bergel wrote: >> - each of these has a status (a famix property) responsible for >> keeping its visualisation state > > But you're relying on properties in the model. Which could not > always be the case. For example, imagine I deal now with numbers, > plain instance of SmallInteger. Numbers cannot be annotated. Where > would I store the fact that a node is expanded or not? > > Moreover, by using the properties of FAMIX objects to store the > "state" of the visualization (i.e., node that are expanded), your > model is somehow aware of the visualization. This is not what can be > called a clean separation of concerns :-) > >> I like this because >> - I dont need to add vars to the classes > > Right, but your model support properties. You are right on both points ... >> - the visualisation state is permanent: if I do a full refresh >> nothing is lost > > Good point! This is something I will have to take care of In that case your solution would be cleaner, yes. > [...] > The annotation mechanism should not have any impact on your existing > code by the way. More I think about it, more I am think this is the > way it should be. Go for it then ;-) -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From stephane.ducasse at inria.fr Fri Jan 15 22:03:20 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 15 Jan 2010 22:03:20 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> Message-ID: <105CC381-6219-4A5A-A2E6-584050272F88@inria.fr> On Jan 15, 2010, at 9:45 PM, Tudor Girba wrote: > Hi, > > I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. > > Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. Really? Are you sure about that? I looks strange to me. final means that you cannot subclass > > Did I miss something? > > In general, we have to be more careful with changes at such core levels :) > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "One cannot do more than one can do." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Fri Jan 15 22:10:03 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 22:10:03 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: <105CC381-6219-4A5A-A2E6-584050272F88@inria.fr> References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <105CC381-6219-4A5A-A2E6-584050272F88@inria.fr> Message-ID: Hi, >> Hi, >> >> I noticed that isPackage, isPrivate, isProtected were removed from >> FAMIXNamedEntity in Famix-Core. It's true that perhaps these >> methods should be in Famix-Extensions, but they should not be >> removed. >> >> Also, isFinal was moved in Famix-Java. This is a Java specific, >> because it has a meaning also for C++ programs where isFinal is >> everything that is not explicitly defined as virtual. > > Really? > Are you sure about that? > I looks strange to me. > final means that you cannot subclass I am pretty sure in C++ virtual means that you can override :). By default you cannot. Cheers, Doru >> >> Did I miss something? >> >> In general, we have to be more careful with changes at such core >> levels :) >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "One cannot do more than one can do." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From Simon.Denier at inria.fr Fri Jan 15 22:12:15 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 15 Jan 2010 22:12:15 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> Message-ID: <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> On 15 janv. 2010, at 21:45, Tudor Girba wrote: > Hi, > > I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. My bad, it seems like I forget to commit Famix-extensions. I can do that on Monday. > > Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. Does someone right now have a use case in C++? Because if not, I would leave it in Java and not care about "what if..." Besides, it's this kind of things for which we will start to use traits in Famix - to avoid semantic confusion between features of different languages. > > Did I miss something? > > In general, we have to be more careful with changes at such core levels :) -- Simon From tudor.girba at gmail.com Fri Jan 15 22:16:27 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 22:16:27 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> Message-ID: Hi Simon, On 15 Jan 2010, at 22:12, Simon Denier wrote: > > On 15 janv. 2010, at 21:45, Tudor Girba wrote: > >> Hi, >> >> I noticed that isPackage, isPrivate, isProtected were removed from >> FAMIXNamedEntity in Famix-Core. It's true that perhaps these >> methods should be in Famix-Extensions, but they should not be >> removed. > > > My bad, it seems like I forget to commit Famix-extensions. I can do > that on Monday. > > >> >> Also, isFinal was moved in Famix-Java. This is a Java specific, >> because it has a meaning also for C++ programs where isFinal is >> everything that is not explicitly defined as virtual. > > > Does someone right now have a use case in C++? Because if not, I > would leave it in Java and not care about "what if..." > Besides, it's this kind of things for which we will start to use > traits in Famix - to avoid semantic confusion between features of > different languages. The inFusion C++ exporter exports this semantics. Cheers, Doru > >> >> Did I miss something? >> >> In general, we have to be more careful with changes at such core >> levels :) > > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." From tudor.girba at gmail.com Fri Jan 15 22:17:12 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 15 Jan 2010 22:17:12 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> Message-ID: <2E8EDB2C-05D0-470F-9AAF-619D45D77D38@gmail.com> Hi, >>> I noticed that isPackage, isPrivate, isProtected were removed from >>> FAMIXNamedEntity in Famix-Core. It's true that perhaps these >>> methods should be in Famix-Extensions, but they should not be >>> removed. >> >> >> My bad, it seems like I forget to commit Famix-extensions. I can do >> that on Monday. Excellent :) Thanks, Doru >> >>> >>> Also, isFinal was moved in Famix-Java. This is a Java specific, >>> because it has a meaning also for C++ programs where isFinal is >>> everything that is not explicitly defined as virtual. >> >> >> Does someone right now have a use case in C++? Because if not, I >> would leave it in Java and not care about "what if..." >> Besides, it's this kind of things for which we will start to use >> traits in Famix - to avoid semantic confusion between features of >> different languages. > > The inFusion C++ exporter exports this semantics. > > Cheers, > Doru > > >> >>> >>> Did I miss something? >>> >>> In general, we have to be more careful with changes at such core >>> levels :) >> >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From stephane.ducasse at inria.fr Fri Jan 15 22:21:57 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 15 Jan 2010 22:21:57 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <105CC381-6219-4A5A-A2E6-584050272F88@inria.fr> Message-ID: On Jan 15, 2010, at 10:10 PM, Tudor Girba wrote: > Hi, > >>> Hi, >>> >>> I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. >>> >>> Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. >> >> Really? >> Are you sure about that? >> I looks strange to me. >> final means that you cannot subclass > > I am pretty sure in C++ virtual means that you can override :). By default you cannot. but isFinal in java does not mean that you cannot add method to the class too because in C++ may be your method is final but you can add a method? So in c++ you can have a private final or a private virtual and a lot more combination I like this language and I hope Java and CSharp will get inspiration. I'm waiting eagerly for template in Java, it would be so cool. > > Cheers, > Doru > >>> >>> Did I miss something? >>> >>> In general, we have to be more careful with changes at such core levels :) >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "One cannot do more than one can do." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Fri Jan 15 22:22:32 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 15 Jan 2010 22:22:32 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> Message-ID: <45393E69-BFBC-4154-B87F-94666B372A0E@inria.fr> I imgaine that radu knows pretty well C++ semantics :) On Jan 15, 2010, at 10:16 PM, Tudor Girba wrote: > Hi Simon, > > On 15 Jan 2010, at 22:12, Simon Denier wrote: > >> >> On 15 janv. 2010, at 21:45, Tudor Girba wrote: >> >>> Hi, >>> >>> I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. >> >> >> My bad, it seems like I forget to commit Famix-extensions. I can do that on Monday. >> >> >>> >>> Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. >> >> >> Does someone right now have a use case in C++? Because if not, I would leave it in Java and not care about "what if..." >> Besides, it's this kind of things for which we will start to use traits in Famix - to avoid semantic confusion between features of different languages. > > The inFusion C++ exporter exports this semantics. > > Cheers, > Doru > > >> >>> >>> Did I miss something? >>> >>> In general, we have to be more careful with changes at such core levels :) >> >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Fri Jan 15 22:40:55 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 15 Jan 2010 22:40:55 +0100 Subject: [Moose-dev] Re: famix changes related to modifiers In-Reply-To: References: <41E90AAB-7D6E-4579-9ECA-8908BD3E0222@tudorgirba.com> <7385D55E-AEF3-434B-B952-843C93F06A56@inria.fr> Message-ID: On 15 janv. 2010, at 22:16, Tudor Girba wrote: > Hi Simon, > > On 15 Jan 2010, at 22:12, Simon Denier wrote: > >> >> On 15 janv. 2010, at 21:45, Tudor Girba wrote: >> >>> Hi, >>> >>> I noticed that isPackage, isPrivate, isProtected were removed from FAMIXNamedEntity in Famix-Core. It's true that perhaps these methods should be in Famix-Extensions, but they should not be removed. >> >> >> My bad, it seems like I forget to commit Famix-extensions. I can do that on Monday. >> >> >>> >>> Also, isFinal was moved in Famix-Java. This is a Java specific, because it has a meaning also for C++ programs where isFinal is everything that is not explicitly defined as virtual. >> >> >> Does someone right now have a use case in C++? Because if not, I would leave it in Java and not care about "what if..." >> Besides, it's this kind of things for which we will start to use traits in Famix - to avoid semantic confusion between features of different languages. > > The inFusion C++ exporter exports this semantics. > For now we can move it to Famix-extensions -- Simon From alexandre.bergel at inria.fr Fri Jan 15 23:22:46 2010 From: alexandre.bergel at inria.fr (Alexandre Bergel) Date: Fri, 15 Jan 2010 19:22:46 -0300 Subject: [Moose-dev] Re: updating mondrian In-Reply-To: <5376830C-2ACA-44A4-99EC-12D1D6809143@gmail.com> References: <81F5D752-05EB-4728-80E8-C351476D75C7@bergel.eu> <5376830C-2ACA-44A4-99EC-12D1D6809143@gmail.com> Message-ID: <61E9AD24-61F4-4913-9645-EA3E64D4DE50@inria.fr> > The problem is that window is a special morph and it is not meant to > be embedded in another morph. It would be much better if for example > the canvas would be in a more regular morph (maybe a panel or even > in the scroller) and this container to raise the announcement. I see. I will investigate on this. I hope to come back to you shortly. Alexandre > > > On 15 Jan 2010, at 16:29, Alexandre Bergel wrote: > >> Hi! >> >> After an interaction from the user (e.g., node dragging, node >> selection), the announcement MOContentChanged is emitted by >> MORoot>>updateWindow. >> When I scroll an MOCanvas (e.g., as it occurs when in an easel or a >> view renderer the picture is larger than the visible window), when >> a window containing a MOCanvas is dragged, moved, resize, the event >> WindowAnnouncement is emitted. >> >> I made a dedicated method, called >> MOViewRenderer>>setDefaultHandlerForWindow: systemWindow that >> register relevant announcement handlers for a number of >> announcement, including node dragging, key down, MOContentChanged >> and WindowAnnouncement. >> >> The only thing to do to have a proper update should be to use >> setDefaultHandlerForWindow: >> >> Cheers, >> Alexandre >> >> NB: When writing this email, I realized that the handler of >> WindowAnnouncement was set in a different location than >> MOContentChanged, which is odd. I produced a new version of >> Mondrian that reflect this. >> >> NB2: now that I thinking about this, maybe MORoot>>updateWindow is >> not an ideal name since the root is not aware of the window in >> which it is (indirectly) embedded. >> >> >> On 15 Jan 2010, at 11:44, Tudor Girba wrote: >> >>> Hi Alex, >>> >>> I am trying to debug the problem of embedding Mondrian in Glamour >>> and I have a question. >>> >>> Why exactly does Mondrian need to know the window to update? Why >>> is it not enough to just know the Canvas morph? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Problem solving efficiency grows with the abstractness level of >>> problem understanding." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "It's not what we do that matters most, it's how we do it." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Fri Jan 15 23:54:40 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 15 Jan 2010 23:54:40 +0100 Subject: [Moose-dev] Deleting old packages on Moose squeaksource Message-ID: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> What do you think of deleting old packages which are completely useless, even for historical purposes. Some are actually from early attempt to port Moose but we have moved on since. A few examples: Moose-Installer Smart-Collections Monticello SLICE-* Merlin (has its own project now) TestWizard (now part of Merlin?) MooseGlamourBrowser (early attempt) Moose-UI (early attempt) Moose-Test-PackageBlueprint (old, duplication) PackageBlueprintOld Moose-PackageBlueprint (deprecated) Moose-NewBlueprint (deprecated) Moose-PB* (deprecated) Moose-NP* (deprecated) Moose-LANTests (old stuff) Moose-Importer-Tests (old stuff) I dont want to delete some deprecated packages which still have a lot of versions, might be interesting for historical purposes. Browsing the Moose repository from MC often feels sluggish : I suspect this is because of the high number of files. Maybe one day we should split between a Moose project and a Famix project. -- Simon From alexandre.bergel at inria.fr Sat Jan 16 00:18:44 2010 From: alexandre.bergel at inria.fr (Alexandre Bergel) Date: Fri, 15 Jan 2010 20:18:44 -0300 Subject: [Moose-dev] Re: glamour update In-Reply-To: References: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> <7B16D5D9-319C-4F36-8E63-6C036ACD1E4E@bergel.eu> Message-ID: <6D287981-FE26-462E-BC93-D5F0BE5982A7@inria.fr> I loaded Glamour in a fresh image, it works as expected. However, if I move the scrollbar on the right-most list, the text field below get resized without doing anything. Looks like to a bug no? Alexandre On 15 Jan 2010, at 09:43, Tudor Girba wrote: > Please try in a fresh image. > > Cheers, > Doru > > > On 15 Jan 2010, at 13:35, Alexandre Bergel wrote: > >> Hi! >> >>> 1. A pane now can control the rendering of multiple presentations >>> through a CompositePresentation. You can now have different >>> arrangements: tabbed, accordion or stacked. You can find an >>> example at: >>> GLMBasicExamples new differentComposites openOn: (1 to: 100) >> >> >> I obtain the following: >> >> >> I do not know whether this is the expected behavior. Before >> executing the expression, I did a >> Gofer new >> squeaksource: 'Glamour'; >> addPackage: 'ConfigurationOfGlamour'; >> load. >> (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault >> >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What we can governs what we wish." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Sat Jan 16 00:24:19 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 00:24:19 +0100 Subject: [Moose-dev] Re: glamour update In-Reply-To: <6D287981-FE26-462E-BC93-D5F0BE5982A7@inria.fr> References: <728398E0-9ADB-4102-BA1C-82ABDA8CE493@gmail.com> <7B16D5D9-319C-4F36-8E63-6C036ACD1E4E@bergel.eu> <6D287981-FE26-462E-BC93-D5F0BE5982A7@inria.fr> Message-ID: Hi, Indeed, I noticed this problem, too, but I do not know what exactly causes it. Cheers, Doru On 16 Jan 2010, at 00:18, Alexandre Bergel wrote: > I loaded Glamour in a fresh image, it works as expected. > However, if I move the scrollbar on the right-most list, the text > field below get resized without doing anything. Looks like to a bug > no? > > Alexandre > > On 15 Jan 2010, at 09:43, Tudor Girba wrote: > >> Please try in a fresh image. >> >> Cheers, >> Doru >> >> >> On 15 Jan 2010, at 13:35, Alexandre Bergel wrote: >> >>> Hi! >>> >>>> 1. A pane now can control the rendering of multiple presentations >>>> through a CompositePresentation. You can now have different >>>> arrangements: tabbed, accordion or stacked. You can find an >>>> example at: >>>> GLMBasicExamples new differentComposites openOn: (1 to: 100) >>> >>> >>> I obtain the following: >>> >>> >>> I do not know whether this is the expected behavior. Before >>> executing the expression, I did a >>> Gofer new >>> squeaksource: 'Glamour'; >>> addPackage: 'ConfigurationOfGlamour'; >>> load. >>> (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault >>> >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From tudor.girba at gmail.com Sat Jan 16 01:52:55 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 01:52:55 +0100 Subject: [Moose-dev] Re: Deleting old packages on Moose squeaksource In-Reply-To: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> References: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> Message-ID: Hi Simon, I very much agree with this. I think you can add: MooseCook, Moose-CookFamix3 (was moved in Famix-Extensions) Moose-UI (old UI) MooseLoader (replaced by ConfigurationOfMoose) Moose-OBBrowser (old UI) Moose-All I would suggest to actually move this code into a dedicated repository. I created a MooseDeprecated repository: MCHttpRepository location: 'http://www.squeaksource.com/MooseDeprecated' user: '' password: '' Anyone up for this task? :) Cheers, Doru On 15 Jan 2010, at 23:54, Simon Denier wrote: > What do you think of deleting old packages which are completely > useless, even for historical purposes. Some are actually from early > attempt to port Moose but we have moved on since. > > A few examples: > > Moose-Installer > Smart-Collections > Monticello > SLICE-* > Merlin (has its own project now) > TestWizard (now part of Merlin?) > MooseGlamourBrowser (early attempt) > Moose-UI (early attempt) > Moose-Test-PackageBlueprint (old, duplication) > PackageBlueprintOld > Moose-PackageBlueprint (deprecated) > Moose-NewBlueprint (deprecated) > Moose-PB* (deprecated) > Moose-NP* (deprecated) > Moose-LANTests (old stuff) > Moose-Importer-Tests (old stuff) > > > I dont want to delete some deprecated packages which still have a > lot of versions, might be interesting for historical purposes. > > > Browsing the Moose repository from MC often feels sluggish : I > suspect this is because of the high number of files. Maybe one day > we should split between a Moose project and a Famix project. > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Beauty is where we see it." From tudor.girba at gmail.com Sat Jan 16 02:07:48 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 02:07:48 +0100 Subject: [Moose-dev] MooseFinder Message-ID: Hi, The implementation of the Moose Finder from the Object>>inMoose started to be way too large to, so I moved it into an own class MooseFinder. Cheers, Doru -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." From alexandre.bergel at inria.fr Sat Jan 16 02:14:20 2010 From: alexandre.bergel at inria.fr (Alexandre Bergel) Date: Fri, 15 Jan 2010 22:14:20 -0300 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: References: Message-ID: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> I wasn't aware of this method. If I execute "10 inMoose", then I have a DNU: SmallInteger does not understand #description. Maybe you can provide a default Object>>description method? Cheers, Alexandre On 15 Jan 2010, at 22:07, Tudor Girba wrote: > Hi, > > The implementation of the Moose Finder from the Object>>inMoose > started to be way too large to, so I moved it into an own class > MooseFinder. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Not knowing how to do something is not an argument for how it > cannot be done." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Sat Jan 16 12:25:13 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 16 Jan 2010 12:25:13 +0100 Subject: [Moose-dev] Re: Deleting old packages on Moose squeaksource In-Reply-To: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> References: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> Message-ID: On Jan 15, 2010, at 11:54 PM, Simon Denier wrote: > What do you think of deleting old packages which are completely useless, even for historical purposes. Some are actually from early attempt to port Moose but we have moved on since. > > A few examples: > > Moose-Installer > Smart-Collections > Monticello > SLICE-* > Merlin (has its own project now) > TestWizard (now part of Merlin?) > MooseGlamourBrowser (early attempt) > Moose-UI (early attempt) > Moose-Test-PackageBlueprint (old, duplication) > PackageBlueprintOld > Moose-PackageBlueprint (deprecated) > Moose-NewBlueprint (deprecated) > Moose-PB* (deprecated) > Moose-NP* (deprecated) simon I think that this really important to clean now are you sure that is deprecated? Moose-NewBlueprint (deprecated) > Moose-LANTests (old stuff) > Moose-Importer-Tests (old stuff) > > > I dont want to delete some deprecated packages which still have a lot of versions, might be interesting for historical purposes. create a MooseDeprecated and move them there. I do not that all the time with pharo inbox (so exicting) > > Browsing the Moose repository from MC often feels sluggish : I suspect this is because of the high number of files. Maybe one day we should split between a Moose project and a Famix project. > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Sat Jan 16 12:39:24 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Sat, 16 Jan 2010 12:39:24 +0100 Subject: [Moose-dev] Re: Deleting old packages on Moose squeaksource In-Reply-To: References: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> Message-ID: <6CDC4277-3923-4BBA-B714-E34D627AB00A@inria.fr> On 16 janv. 2010, at 12:25, St?phane Ducasse wrote: > > On Jan 15, 2010, at 11:54 PM, Simon Denier wrote: > >> What do you think of deleting old packages which are completely useless, even for historical purposes. Some are actually from early attempt to port Moose but we have moved on since. >> >> A few examples: >> >> Moose-Installer >> Smart-Collections >> Monticello >> SLICE-* >> Merlin (has its own project now) >> TestWizard (now part of Merlin?) >> MooseGlamourBrowser (early attempt) >> Moose-UI (early attempt) >> Moose-Test-PackageBlueprint (old, duplication) >> PackageBlueprintOld >> Moose-PackageBlueprint (deprecated) >> Moose-NewBlueprint (deprecated) >> Moose-PB* (deprecated) >> Moose-NP* (deprecated) > > > simon I think that this really important to clean > now are you sure that is deprecated? > Moose-NewBlueprint (deprecated) Yep, we continued to clean up the code yesterday and as a result, we moved it back to MondrianPaintings as OutgoingPackageBlueprint Also added a launch script on FamixPackage>>viewOutgoingPackageBlueprint in the Finder > >> Moose-LANTests (old stuff) >> Moose-Importer-Tests (old stuff) >> >> >> I dont want to delete some deprecated packages which still have a lot of versions, might be interesting for historical purposes. > > create a MooseDeprecated and move them there. > I do not that all the time with pharo inbox (so exicting) ok, starting now -- Simon From tudor.girba at gmail.com Sat Jan 16 12:45:00 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 12:45:00 +0100 Subject: [Moose-dev] Re: Deleting old packages on Moose squeaksource In-Reply-To: <6CDC4277-3923-4BBA-B714-E34D627AB00A@inria.fr> References: <1231C214-4F70-4645-8F69-2BADF2D00BC2@inria.fr> <6CDC4277-3923-4BBA-B714-E34D627AB00A@inria.fr> Message-ID: Thanks a lot, Simon. I added you as an admin to MooseDeprecated. Doru On 16 Jan 2010, at 12:39, Simon Denier wrote: > > On 16 janv. 2010, at 12:25, St?phane Ducasse wrote: > >> >> On Jan 15, 2010, at 11:54 PM, Simon Denier wrote: >> >>> What do you think of deleting old packages which are completely >>> useless, even for historical purposes. Some are actually from >>> early attempt to port Moose but we have moved on since. >>> >>> A few examples: >>> >>> Moose-Installer >>> Smart-Collections >>> Monticello >>> SLICE-* >>> Merlin (has its own project now) >>> TestWizard (now part of Merlin?) >>> MooseGlamourBrowser (early attempt) >>> Moose-UI (early attempt) >>> Moose-Test-PackageBlueprint (old, duplication) >>> PackageBlueprintOld >>> Moose-PackageBlueprint (deprecated) >>> Moose-NewBlueprint (deprecated) >>> Moose-PB* (deprecated) >>> Moose-NP* (deprecated) >> >> >> simon I think that this really important to clean >> now are you sure that is deprecated? >> Moose-NewBlueprint (deprecated) > > > Yep, we continued to clean up the code yesterday and as a result, we > moved it back to MondrianPaintings as OutgoingPackageBlueprint > Also added a launch script on > FamixPackage>>viewOutgoingPackageBlueprint in the Finder > >> >>> Moose-LANTests (old stuff) >>> Moose-Importer-Tests (old stuff) >>> >>> >>> I dont want to delete some deprecated packages which still have a >>> lot of versions, might be interesting for historical purposes. >> >> create a MooseDeprecated and move them there. >> I do not that all the time with pharo inbox (so exicting) > > > ok, starting now > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Being happy is a matter of choice." From stephane.ducasse at inria.fr Sat Jan 16 12:47:09 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 16 Jan 2010 12:47:09 +0100 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> Message-ID: <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> But may be it makes no sense to do that may be inMoose only works on MooseAbtsractENtity and as such should not be in Object. Stef On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: > I wasn't aware of this method. If I execute "10 inMoose", then I have a DNU: SmallInteger does not understand #description. Maybe you can provide a default Object>>description method? > > Cheers, > Alexandre > > > On 15 Jan 2010, at 22:07, Tudor Girba wrote: > >> Hi, >> >> The implementation of the Moose Finder from the Object>>inMoose started to be way too large to, so I moved it into an own class MooseFinder. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Not knowing how to do something is not an argument for how it cannot be done." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Sat Jan 16 12:52:33 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 12:52:33 +0100 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> Message-ID: Hi, openInMoose should work on Object, it's just that indeed the MooseFinder has a couple of messages that are specific to MooseEntity. We should refactor that, but description will surely not get in Object :). The other two messages are: - complexPropertySelectors - this should be in the MetaDescription - propertiesToDisplay: which then depends on "asMooseFinderItemNamed: aString in: aMooseEntity" Cheers, Doru On 16 Jan 2010, at 12:47, St?phane Ducasse wrote: > But may be > it makes no sense to do that > > may be inMoose only works on MooseAbtsractENtity and as such should > not be in Object. > > Stef > > On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: > >> I wasn't aware of this method. If I execute "10 inMoose", then I >> have a DNU: SmallInteger does not understand #description. Maybe >> you can provide a default Object>>description method? >> >> Cheers, >> Alexandre >> >> >> On 15 Jan 2010, at 22:07, Tudor Girba wrote: >> >>> Hi, >>> >>> The implementation of the Moose Finder from the Object>>inMoose >>> started to be way too large to, so I moved it into an own class >>> MooseFinder. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Not knowing how to do something is not an argument for how it >>> cannot be done." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." From stephane.ducasse at inria.fr Sat Jan 16 12:58:43 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 16 Jan 2010 12:58:43 +0100 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> Message-ID: <672F00C1-EBD6-4FC5-A55E-D5843E47AB49@inria.fr> a question what kind of object do you expect to be displayed in Moose via openInMoose? Because your answer confused me. Stef On Jan 16, 2010, at 12:52 PM, Tudor Girba wrote: > Hi, > > openInMoose should work on Object, it's just that indeed the MooseFinder has a couple of messages that are specific to MooseEntity. We should refactor that, but description will surely not get in Object :). The other two messages are: > - complexPropertySelectors - this should be in the MetaDescription > - propertiesToDisplay: which then depends on "asMooseFinderItemNamed: aString in: aMooseEntity" > > > Cheers, > Doru > > On 16 Jan 2010, at 12:47, St?phane Ducasse wrote: > >> But may be >> it makes no sense to do that >> >> may be inMoose only works on MooseAbtsractENtity and as such should not be in Object. >> >> Stef >> >> On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: >> >>> I wasn't aware of this method. If I execute "10 inMoose", then I have a DNU: SmallInteger does not understand #description. Maybe you can provide a default Object>>description method? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 15 Jan 2010, at 22:07, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> The implementation of the Moose Finder from the Object>>inMoose started to be way too large to, so I moved it into an own class MooseFinder. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Sat Jan 16 13:04:17 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 13:04:17 +0100 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: <672F00C1-EBD6-4FC5-A55E-D5843E47AB49@inria.fr> References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> <672F00C1-EBD6-4FC5-A55E-D5843E47AB49@inria.fr> Message-ID: <993AAC7A-F4DB-48D1-BD05-5F2E575BAAB8@gmail.com> Hi, At this moment you can just say "someentity openInMoose" and this will spawn a MooseFinder with that entity as an input. It's like saying inspect only with information that depend on mooseDescription. Given that any Object understands mooseDescription, we should be able to browse meta-described objects that are not necessarily subclasses of MooseEntity. Is this better as an explanation? Doru On 16 Jan 2010, at 12:58, St?phane Ducasse wrote: > a question what kind of object do you expect to be displayed in Moose > via openInMoose? > Because your answer confused me. > > Stef > On Jan 16, 2010, at 12:52 PM, Tudor Girba wrote: > >> Hi, >> >> openInMoose should work on Object, it's just that indeed the >> MooseFinder has a couple of messages that are specific to >> MooseEntity. We should refactor that, but description will surely >> not get in Object :). The other two messages are: >> - complexPropertySelectors - this should be in the MetaDescription >> - propertiesToDisplay: which then depends on >> "asMooseFinderItemNamed: aString in: aMooseEntity" >> >> >> Cheers, >> Doru >> >> On 16 Jan 2010, at 12:47, St?phane Ducasse wrote: >> >>> But may be >>> it makes no sense to do that >>> >>> may be inMoose only works on MooseAbtsractENtity and as such >>> should not be in Object. >>> >>> Stef >>> >>> On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: >>> >>>> I wasn't aware of this method. If I execute "10 inMoose", then I >>>> have a DNU: SmallInteger does not understand #description. Maybe >>>> you can provide a default Object>>description method? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 15 Jan 2010, at 22:07, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> The implementation of the Moose Finder from the Object>>inMoose >>>>> started to be way too large to, so I moved it into an own class >>>>> MooseFinder. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Not knowing how to do something is not an argument for how it >>>>> cannot be done." >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that >> happen. They both matter." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Reasonable is what we are accustomed with." From stephane.ducasse at inria.fr Sat Jan 16 13:41:06 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Sat, 16 Jan 2010 13:41:06 +0100 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: <993AAC7A-F4DB-48D1-BD05-5F2E575BAAB8@gmail.com> References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> <672F00C1-EBD6-4FC5-A55E-D5843E47AB49@inria.fr> <993AAC7A-F4DB-48D1-BD05-5F2E575BAAB8@gmail.com> Message-ID: yes On Jan 16, 2010, at 1:04 PM, Tudor Girba wrote: > Hi, > > At this moment you can just say "someentity openInMoose" and this will spawn a MooseFinder with that entity as an input. It's like saying inspect only with information that depend on mooseDescription. > > Given that any Object understands mooseDescription, we should be able to browse meta-described objects that are not necessarily subclasses of MooseEntity. > > Is this better as an explanation? > > Doru > > > > On 16 Jan 2010, at 12:58, St?phane Ducasse wrote: > >> a question what kind of object do you expect to be displayed in Moose >> via openInMoose? >> Because your answer confused me. >> >> Stef >> On Jan 16, 2010, at 12:52 PM, Tudor Girba wrote: >> >>> Hi, >>> >>> openInMoose should work on Object, it's just that indeed the MooseFinder has a couple of messages that are specific to MooseEntity. We should refactor that, but description will surely not get in Object :). The other two messages are: >>> - complexPropertySelectors - this should be in the MetaDescription >>> - propertiesToDisplay: which then depends on "asMooseFinderItemNamed: aString in: aMooseEntity" >>> >>> >>> Cheers, >>> Doru >>> >>> On 16 Jan 2010, at 12:47, St?phane Ducasse wrote: >>> >>>> But may be >>>> it makes no sense to do that >>>> >>>> may be inMoose only works on MooseAbtsractENtity and as such should not be in Object. >>>> >>>> Stef >>>> >>>> On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: >>>> >>>>> I wasn't aware of this method. If I execute "10 inMoose", then I have a DNU: SmallInteger does not understand #description. Maybe you can provide a default Object>>description method? >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> On 15 Jan 2010, at 22:07, Tudor Girba wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> The implementation of the Moose Finder from the Object>>inMoose started to be way too large to, so I moved it into an own class MooseFinder. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre.bergel at inria.fr Sat Jan 16 18:41:30 2010 From: alexandre.bergel at inria.fr (Alexandre Bergel) Date: Sat, 16 Jan 2010 14:41:30 -0300 Subject: [Moose-dev] Re: MooseFinder In-Reply-To: References: <12D982DB-EBC1-4F33-AF6F-0CA5542886D5@inria.fr> <6F26ECCD-EA45-4A4A-A6FB-EAFF05FE16D7@inria.fr> Message-ID: > openInMoose should work on Object, it's just that indeed the > MooseFinder has a couple of messages that are specific to > MooseEntity. We should refactor that, but description will surely > not get in Object :). The other two messages are: > - complexPropertySelectors - this should be in the MetaDescription > - propertiesToDisplay: which then depends on > "asMooseFinderItemNamed: aString in: aMooseEntity" I think that #inMoose should not raise a "random" error. Cheers, Alexandre > > > Cheers, > Doru > > On 16 Jan 2010, at 12:47, St?phane Ducasse wrote: > >> But may be >> it makes no sense to do that >> >> may be inMoose only works on MooseAbtsractENtity and as such should >> not be in Object. >> >> Stef >> >> On Jan 16, 2010, at 2:14 AM, Alexandre Bergel wrote: >> >>> I wasn't aware of this method. If I execute "10 inMoose", then I >>> have a DNU: SmallInteger does not understand #description. Maybe >>> you can provide a default Object>>description method? >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 15 Jan 2010, at 22:07, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> The implementation of the Moose Finder from the Object>>inMoose >>>> started to be way too large to, so I moved it into an own class >>>> MooseFinder. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Not knowing how to do something is not an argument for how it >>>> cannot be done." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that > happen. They both matter." > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > From abergel at dcc.uchile.cl Sat Jan 16 19:17:33 2010 From: abergel at dcc.uchile.cl (Alexandre Bergel) Date: Sat, 16 Jan 2010 15:17:33 -0300 Subject: [Moose-dev] Mondrian health report Message-ID: As the regular sanity check, here is the mondrian health report for this month. I created a squeaksource HealthReportProducer. I have in mind plenty of improvements for it (e.g., check of architectural rules, speed progress measurement). I will slowly work on this... Edges got slower to render. I need to dive a bit into the recent changes to understand why. Report produced on 2010-01-16T14:49:26+00:00 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 15 ms 200 nodes => 53 ms 300 nodes => 113 ms 400 nodes => 201 ms 500 nodes => 345 ms 600 nodes => 457 ms 700 nodes => 760 ms 800 nodes => 812 ms 900 nodes => 1137 ms 1000 nodes => 1243 ms 1600 nodes => 3855 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 2 ms 20 edges => 7 ms 30 edges => 43 ms 40 edges => 33 ms 50 edges => 54 ms 60 edges => 139 ms 70 edges => 146 ms 80 edges => 196 ms 90 edges => 314 ms 100 edges => 385 ms 200 edges => 5565 ms 300 edges => 40862 ms 55.65 % of methods are covered by unit tests Progress from last time: +0.57 % Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre.bergel at inria.fr Sat Jan 16 19:31:55 2010 From: alexandre.bergel at inria.fr (Alexandre Bergel) Date: Sat, 16 Jan 2010 15:31:55 -0300 Subject: [Moose-dev] Glamour health report Message-ID: A significant slowdown may be noticed when compared with the previous glamourous report (sent on October 23). Details at the end of the amil. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Report produced on 2010-01-16T15:19:06+00:00 ------------------ Opening Browser Benchmark: 15 openings => 2620 ms ------------------ ------------------ Selecting Item in Browser Benchmark 100 size and selections => 2569 ms 200 size and selections => 4359 ms 300 size and selections => 6912 ms 400 size and selections => 8298 ms 500 size and selections => 10414 ms 600 size and selections => 12462 ms 700 size and selections => 14019 ms 800 size and selections => 16123 ms 900 size and selections => 19234 ms 1000 size and selections => 19984 ms 1500 size and selections => 30812 ms 2000 size and selections => 45497 ms ------------------ ------------------ Selecting in finder item Benchmark 1 size and selections => 166 ms 5 size and selections => 897 ms 10 size and selections => 1949 ms 15 size and selections => 2968 ms 20 size and selections => 4008 ms 25 size and selections => 5112 ms 30 size and selections => 11714 ms 35 size and selections => 7686 ms 40 size and selections => 8963 ms 45 size and selections => 10428 ms 50 size and selections => 12471 ms ------------------ 50.66 % of methods are covered from unit tests Progress from last time: +17.19 % -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From the report generated on Oct 23, we had: Selecting Item Benchmark: 2000 size and selections => 2729 ms Selecting in finder item Benchmark: 50 size and selections => 1881 ms The new version is one magnitude slower. However, opening a browser is slightly faster. The first health report indicated: 15 openings => 3622 ms Cheers, Alexandre From tudor.girba at gmail.com Sat Jan 16 20:26:55 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 16 Jan 2010 20:26:55 +0100 Subject: [Moose-dev] Re: Glamour health report In-Reply-To: References: Message-ID: <86213EA4-FFCE-43E7-AFF8-8225A3487618@gmail.com> Hmm, this does not sound quite right because such a slowdown should be noticeable from the UI as well, but that does not really happen. Cheers, Doru On 16 Jan 2010, at 19:31, Alexandre Bergel wrote: > A significant slowdown may be noticed when compared with the > previous glamourous report (sent on October 23). Details at the end > of the amil. > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-= > Report produced on 2010-01-16T15:19:06+00:00 > ------------------ > Opening Browser Benchmark: > 15 openings => 2620 ms > ------------------ > > ------------------ > Selecting Item in Browser Benchmark > 100 size and selections => 2569 ms > 200 size and selections => 4359 ms > 300 size and selections => 6912 ms > 400 size and selections => 8298 ms > 500 size and selections => 10414 ms > 600 size and selections => 12462 ms > 700 size and selections => 14019 ms > 800 size and selections => 16123 ms > 900 size and selections => 19234 ms > 1000 size and selections => 19984 ms > 1500 size and selections => 30812 ms > 2000 size and selections => 45497 ms > ------------------ > > ------------------ > Selecting in finder item Benchmark > 1 size and selections => 166 ms > 5 size and selections => 897 ms > 10 size and selections => 1949 ms > 15 size and selections => 2968 ms > 20 size and selections => 4008 ms > 25 size and selections => 5112 ms > 30 size and selections => 11714 ms > 35 size and selections => 7686 ms > 40 size and selections => 8963 ms > 45 size and selections => 10428 ms > 50 size and selections => 12471 ms > ------------------ > > 50.66 % of methods are covered from unit tests > Progress from last time: +17.19 % > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-= > > From the report generated on Oct 23, we had: > Selecting Item Benchmark: > 2000 size and selections => 2729 ms > Selecting in finder item Benchmark: > 50 size and selections => 1881 ms > > The new version is one magnitude slower. > > However, opening a browser is slightly faster. The first health > report indicated: > 15 openings => 3622 ms > > Cheers, > Alexandre > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." From tudor.girba at gmail.com Sun Jan 17 15:40:36 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 17 Jan 2010 15:40:36 +0100 Subject: [Moose-dev] Re: Glamour health report In-Reply-To: <86213EA4-FFCE-43E7-AFF8-8225A3487618@gmail.com> References: <86213EA4-FFCE-43E7-AFF8-8225A3487618@gmail.com> Message-ID: <7F134EE4-32FD-4FCD-A661-ED6318AEE673@gmail.com> Hi Alex, Alain Plantec improved the speed of selection in MorphTreeMorph yesterday (however, I might have a faster computer than you 2.8 GHz Intel Core 2 Duo). The overall performance increased, but the figures still show a significant slowdown from your October report. Cheers, Doru Report produced on 2010-01-17T13:35:38+00:00 ------------------ Opening Browser Benchmark: 15 openings => 1806 ms ------------------ ------------------ Selecting Item in Browser Benchmark 100 size and selections => 1894 ms 200 size and selections => 3455 ms 300 size and selections => 4638 ms 400 size and selections => 6333 ms 500 size and selections => 7329 ms 600 size and selections => 8720 ms 700 size and selections => 10423 ms 800 size and selections => 11718 ms 900 size and selections => 13037 ms 1000 size and selections => 14470 ms 1500 size and selections => 21524 ms 2000 size and selections => 28685 ms ------------------ ------------------ Selecting in finder item Benchmark 1 size and selections => 138 ms 5 size and selections => 713 ms 10 size and selections => 1477 ms 15 size and selections => 2187 ms 20 size and selections => 3001 ms 25 size and selections => 3813 ms 30 size and selections => 4634 ms 35 size and selections => 5523 ms 40 size and selections => 6750 ms 45 size and selections => 7493 ms 50 size and selections => 8310 ms ------------------ Cheers, Doru On 16 Jan 2010, at 20:26, Tudor Girba wrote: > Hmm, this does not sound quite right because such a slowdown should > be noticeable from the UI as well, but that does not really happen. > > Cheers, > Doru > > > On 16 Jan 2010, at 19:31, Alexandre Bergel wrote: > >> A significant slowdown may be noticed when compared with the >> previous glamourous report (sent on October 23). Details at the end >> of the amil. >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-= >> Report produced on 2010-01-16T15:19:06+00:00 >> ------------------ >> Opening Browser Benchmark: >> 15 openings => 2620 ms >> ------------------ >> >> ------------------ >> Selecting Item in Browser Benchmark >> 100 size and selections => 2569 ms >> 200 size and selections => 4359 ms >> 300 size and selections => 6912 ms >> 400 size and selections => 8298 ms >> 500 size and selections => 10414 ms >> 600 size and selections => 12462 ms >> 700 size and selections => 14019 ms >> 800 size and selections => 16123 ms >> 900 size and selections => 19234 ms >> 1000 size and selections => 19984 ms >> 1500 size and selections => 30812 ms >> 2000 size and selections => 45497 ms >> ------------------ >> >> ------------------ >> Selecting in finder item Benchmark >> 1 size and selections => 166 ms >> 5 size and selections => 897 ms >> 10 size and selections => 1949 ms >> 15 size and selections => 2968 ms >> 20 size and selections => 4008 ms >> 25 size and selections => 5112 ms >> 30 size and selections => 11714 ms >> 35 size and selections => 7686 ms >> 40 size and selections => 8963 ms >> 45 size and selections => 10428 ms >> 50 size and selections => 12471 ms >> ------------------ >> >> 50.66 % of methods are covered from unit tests >> Progress from last time: +17.19 % >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> =-=-= >> >> From the report generated on Oct 23, we had: >> Selecting Item Benchmark: >> 2000 size and selections => 2729 ms >> Selecting in finder item Benchmark: >> 50 size and selections => 1881 ms >> >> The new version is one magnitude slower. >> >> However, opening a browser is slightly faster. The first health >> report indicated: >> 15 openings => 3622 ms >> >> Cheers, >> Alexandre >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know > her." > > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution." From tudor at tudorgirba.com Mon Jan 18 16:02:27 2010 From: tudor at tudorgirba.com (Tudor Girba) Date: Mon, 18 Jan 2010 16:02:27 +0100 Subject: [Moose-dev] new browser type: accumulator Message-ID: <5CDBE3E0-690B-4D83-8E99-85051C718BA7@tudorgirba.com> Hi, I am happy to announce a new feature in Glamour in the form of the Accumulator browser. This browser is an implicit one that just takes the input entity and creates a new pane for it. It is called an Accumulator, because it accumulates panes as you provide a new input. These panes are then displayed as tabs. A complementary feature is in a new way bundle transmissions are passed around. You can pass it like before with andShow:, or you can do it with andShowWithoutOverride:. It's not a very nice name, but the idea is that it only transmits the presentation if the same presentations were not already found in the target pane. Using Accumulator you can now emulate browsers that behave like the Eclipse central pane. An example can be found here: GLMBasicExamples new accumulator openOn: 42. This feature is now also used in the MooseFinder and MoosePanel. If you open the Panel and select a model, you open it in a new tab. From the Finder, if you double click on an item in a list you get it in a new tab. I hope you like it. Cheers, Doru -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." From Simon.Denier at inria.fr Mon Jan 18 16:17:00 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 18 Jan 2010 16:17:00 +0100 Subject: [Moose-dev] Re: new browser type: accumulator In-Reply-To: <5CDBE3E0-690B-4D83-8E99-85051C718BA7@tudorgirba.com> References: <5CDBE3E0-690B-4D83-8E99-85051C718BA7@tudorgirba.com> Message-ID: Hi Doru Can you provide a screenshot? I already did an update this morning and I dont want to do another one now :) Anyway, I really like the new look of the Moose finder with tabs, and the return of the custom selection in the list widget. We should also move more things in the toolbar (like initialize meta-descriptions or browse meta). Last week was good: we broke some cyclic dependencies using DSM and Orion (which also starts to look nice), the Package blueprint is now back (even if it's a first version)... On 18 janv. 2010, at 16:02, Tudor Girba wrote: > Hi, > > I am happy to announce a new feature in Glamour in the form of the Accumulator browser. This browser is an implicit one that just takes the input entity and creates a new pane for it. It is called an Accumulator, because it accumulates panes as you provide a new input. These panes are then displayed as tabs. > > A complementary feature is in a new way bundle transmissions are passed around. You can pass it like before with andShow:, or you can do it with andShowWithoutOverride:. It's not a very nice name, but the idea is that it only transmits the presentation if the same presentations were not already found in the target pane. > > Using Accumulator you can now emulate browsers that behave like the Eclipse central pane. An example can be found here: > > GLMBasicExamples new accumulator openOn: 42. > > This feature is now also used in the MooseFinder and MoosePanel. If you open the Panel and select a model, you open it in a new tab. From the Finder, if you double click on an item in a list you get it in a new tab. > > I hope you like it. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From jfabry at dcc.uchile.cl Mon Jan 18 16:58:05 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 12:58:05 -0300 Subject: [Moose-dev] Glamour: using the new features Message-ID: Hi all, first of all: Thanks Doru for implementing the new features! They are very useful to me. Below is a screenshot of the AspectMaps UI that is using these features. I have a bunch of questions related to this and I would be very grateful if you could help me out. The code of the UI is also below. Very big method, I know, but I did it this way to avoid ambiguities in this mail. Questions: - How do I update the top mondrian panel using the new update mechanism? I want it to redraw itself completely when some of the buttons are pressed and on some of the menu actions of the aspects menu. - The last 2 columns specify the metrics used in the polymetric view. With a transmission I always get the last selections made, but I need to know all selections made in that column so I can print it in the selectionstatus text box. How is this possible? Also, if no selection at all is made I would like to show that in the box (now the box is removed). - The last 3 columns actually do not use any input, but I specify them with "transmit to: ; andShow:" Is there a cleaner way to do this? -------------- next part -------------- A non-text attachment was scrubbed... Name: am.png Type: image/png Size: 107991 bytes Desc: not available URL: -------------- next part -------------- The code is below: ----snip--- open |browser colors colorizer| "for aspect colors, both automatic assignment and manual selection in menu" colorizer := MOCircularColors new. colors := OrderedCollection new. 1 to: 10 do: [:num| colors add: colorizer nextColor]. browser := GLMTabulator new. browser title: 'AspectMaps Window'. browser row: #mpanel span: 3. browser row:[:r| r column: #models span:2 ; column: #aspectsel span: 2; column: [:c| c row: #buttons span: 4. c row: #selectionstatus.]span: 2; column: #hprop; column: #wprop] span: 2. browser transmit to: #mpanel; from: #models; andShow: [:a | a mondrian painting: [:view :model| model allNamespaces do: [:ns| ns currentShapeFor: view withProperties: self]. view gridLayout.]]. browser transmit to: #models; andShow: [:a | a stackedVerticallyArrangement. a tree title: 'Available projects'; children: [:model | (SortedCollection sortBlock: [:x :y | x name <= y name]) addAll: model allNamespaces asOrderedCollection; yourself ]; act: [:tree | tree selection inspect ] on: $i entitled: 'Inspect'; format: [:model | (model name) copyReplaceAll: '::' with:'.' ]]. browser transmit to: #aspectsel; from: #models transformed: [:model | |topmodel| topmodel := model mooseModel = MooseModel root ifTrue: [model] ifFalse:[model mooseModel]. topmodel allAspects do:[:asp | asp color ifNil: [asp color: colorizer nextColor]]. topmodel allAspects ]; andShow: [:a| a stackedVerticallyArrangement. a tree title: 'Aspects in Project'; format: [:asp | Text string: ((asp show ifTrue: ['(ON) '] ifFalse: ['(OFF) ']), asp name) attribute: (TextColor color: asp color).]; act: [:tree | tree inspect ] on: $i entitled: 'Inspect (i)'; act: [:tree | |asp ann| asp := tree selection. asp show: (asp show not). tree update.] on: $t entitled: 'Toggle On/Off (t)'; actions: [:tree | colors collect: [:col | GLMAction new title: col asString; action: [tree selection color: col. tree update]; category: 'Color']]]. browser transmit to: #buttons; andShow: [:a | a actionList act: [:entity | entity inspect] entitled: 'Vizualize'; act: [:entity | entity inspect] entitled: 'Max Zoom Out'; act: [:entity | entity inspect] entitled: 'Max Zoom In'; act: [:entity | entity inspect] entitled: 'Multiple Aspects Zoom'; act: [:entity | entity inspect] entitled: 'Zoom by Query'. ]. browser transmit to: #hprop; andShow: [:a | a accordionArrangement. a list title: 'Classes Height'; display: self cprops; allowDeselection. a list title: 'Aspects Height'; display: self aprops; allowDeselection. a list title: 'Methods Height'; display: self mprops; allowDeselection. ]. browser transmit to: #wprop; andShow: [:a | a accordionArrangement. a list title: 'Classes Width'; display: self cprops; allowDeselection. a list title: 'Aspects Width'; display: self aprops; allowDeselection. a list title: 'Methods Width'; display: self mprops; allowDeselection. ]. browser transmit to: #selectionstatus; from: #hprop; from: #wprop; andShow: [:a | a text display: [:x :y| x asString , ' ', y asString]; allowNil]. browser openOn: MooseModel root allModels asOrderedCollection ----snip--- -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Mon Jan 18 17:31:06 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 18 Jan 2010 17:31:06 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: References: Message-ID: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> Hi Johan, On 18 Jan 2010, at 16:58, Johan Fabry wrote: > Hi all, > > first of all: Thanks Doru for implementing the new features! They > are very useful to me. I am glad. > Below is a screenshot of the AspectMaps UI that is using these > features. I have a bunch of questions related to this and I would be > very grateful if you could help me out. The code of the UI is also > below. Very big method, I know, but I did it this way to avoid > ambiguities in this mail. Pretty cool. It would be cool to add a picture like this in a dedicated page under: http://www.moosetechnology.org/tools Please send me your desired username to give you access. > Questions: > - How do I update the top mondrian panel using the new update > mechanism? I want it to redraw itself completely when some of the > buttons are pressed and on some of the menu actions of the aspects > menu. I do not understand. The update mechanism is for updating a presentation based on changes in the model. If you want to deal with the UI, you do it with a transmission. > - The last 2 columns specify the metrics used in the polymetric > view. With a transmission I always get the last selections made, but > I need to know all selections made in that column so I can print it > in the selectionstatus text box. How is this possible? A pane models one state: one entity, one selection etc. If you want multiple states, you need multiple panes :). So, you need multiple panes there and then have a transmission from all of them. > Also, if no selection at all is made I would like to show that in > the box (now the box is removed). Unfortunately, that is not possible. > - The last 3 columns actually do not use any input, but I specify > them with "transmit to: ; andShow:" Is there a cleaner way to do this? Nope. That is the desired way. Perhaps I will add a shortcut method, but until then, this is Ok. Cheers, Doru > > > > The code is below: > > ----snip--- > > open > |browser colors colorizer| > > "for aspect colors, both automatic assignment and manual selection > in menu" > colorizer := MOCircularColors new. > colors := OrderedCollection new. > 1 to: 10 do: [:num| colors add: colorizer nextColor]. > > browser := GLMTabulator new. > browser title: 'AspectMaps Window'. > browser row: #mpanel span: 3. > browser row:[:r| > r column: #models span:2 ; > column: #aspectsel span: 2; > column: [:c| c row: #buttons span: 4. c row: > #selectionstatus.]span: 2; > column: #hprop; > column: #wprop] span: 2. > > browser transmit to: #mpanel; from: #models; andShow: [:a | > a mondrian painting: [:view :model| > model allNamespaces do: [:ns| ns currentShapeFor: view > withProperties: self]. > view gridLayout.]]. > > browser transmit to: #models; andShow: [:a | > a stackedVerticallyArrangement. > a tree title: 'Available projects'; > children: [:model | (SortedCollection sortBlock: [:x :y | x name > <= y name]) addAll: model allNamespaces asOrderedCollection; > yourself ]; > act: [:tree | tree selection inspect ] on: $i entitled: 'Inspect'; > format: [:model | (model name) copyReplaceAll: '::' with:'.' ]]. > > browser transmit to: #aspectsel; from: #models transformed: [:model > | |topmodel| > topmodel := model mooseModel = MooseModel root ifTrue: [model] > ifFalse:[model mooseModel]. > topmodel allAspects do:[:asp | asp color ifNil: [asp color: > colorizer nextColor]]. > topmodel allAspects ]; > andShow: [:a| > a stackedVerticallyArrangement. > a tree title: 'Aspects in Project'; > format: [:asp | Text string: ((asp show ifTrue: ['(ON) '] > ifFalse: ['(OFF) ']), > asp name) attribute: (TextColor color: asp color).]; > act: [:tree | tree inspect ] on: $i entitled: 'Inspect (i)'; > act: [:tree | |asp ann| > asp := tree selection. asp show: (asp show not). > tree update.] on: $t entitled: 'Toggle On/Off (t)'; > actions: [:tree | colors collect: [:col | GLMAction new title: > col asString; action: [tree selection color: col. tree update]; > category: 'Color']]]. > > browser transmit to: #buttons; andShow: [:a | > a actionList > act: [:entity | entity inspect] entitled: 'Vizualize'; > act: [:entity | entity inspect] entitled: 'Max Zoom Out'; > act: [:entity | entity inspect] entitled: 'Max Zoom In'; > act: [:entity | entity inspect] entitled: 'Multiple Aspects Zoom'; > act: [:entity | entity inspect] entitled: 'Zoom by Query'. > ]. > > browser transmit to: #hprop; andShow: [:a | > a accordionArrangement. > a list title: 'Classes Height'; display: self cprops; > allowDeselection. > a list title: 'Aspects Height'; display: self aprops; > allowDeselection. > a list title: 'Methods Height'; display: self mprops; > allowDeselection. > ]. > > browser transmit to: #wprop; andShow: [:a | > a accordionArrangement. > a list title: 'Classes Width'; display: self cprops; > allowDeselection. > a list title: 'Aspects Width'; display: self aprops; > allowDeselection. > a list title: 'Methods Width'; display: self mprops; > allowDeselection. > ]. > > browser transmit to: #selectionstatus; from: #hprop; from: #wprop; > andShow: [:a | > a text display: [:x :y| x asString , ' ', y asString]; allowNil]. > > browser openOn: MooseModel root allModels asOrderedCollection > > ----snip--- > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "No matter how many recipes we know, we still value a chef." From jfabry at dcc.uchile.cl Mon Jan 18 18:00:21 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 14:00:21 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> Message-ID: <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> On 18 Jan 2010, at 13:31, Tudor Girba wrote: > Pretty cool. It would be cool to add a picture like this in a > dedicated page under: > http://www.moosetechnology.org/tools > > Please send me your desired username to give you access. Thanks! Let me fix some bugs here and there and then I'll make some movies, we can then add everything to a moose page.. >> - How do I update the top mondrian panel using the new update >> mechanism? I want it to redraw itself completely when some of the >> buttons are pressed and on some of the menu actions of the aspects >> menu. > > I do not understand. The update mechanism is for updating a > presentation based on changes in the model. If you want to deal with > the UI, you do it with a transmission. I want to update the mondrian presentation based on changes made in the model (either by a specific menu action or by clicking on a button). The mondrian presentation should basically redraw itself completely. >> - The last 2 columns specify the metrics used in the polymetric >> view. With a transmission I always get the last selections made, >> but I need to know all selections made in that column so I can >> print it in the selectionstatus text box. How is this possible? > > A pane models one state: one entity, one selection etc. If you want > multiple states, you need multiple panes :). So, you need multiple > panes there and then have a transmission from all of them. :-( that is going to use a lot of space. Is there a way to have the multiple panes do the same collapse trick as in the code that I have now? >> Also, if no selection at all is made I would like to show that in >> the box (now the box is removed). > > Unfortunately, that is not possible. > >> - The last 3 columns actually do not use any input, but I specify >> them with "transmit to: ; andShow:" Is there a cleaner way to do >> this? > > Nope. That is the desired way. Perhaps I will add a shortcut method, > but until then, this is Ok. OK, thanks! -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Mon Jan 18 18:52:24 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 18 Jan 2010 18:52:24 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> Message-ID: <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> Hi, >> Pretty cool. It would be cool to add a picture like this in a >> dedicated page under: >> http://www.moosetechnology.org/tools >> >> Please send me your desired username to give you access. > > Thanks! Let me fix some bugs here and there and then I'll make some > movies, we can then add everything to a moose page.. Cool. >>> - How do I update the top mondrian panel using the new update >>> mechanism? I want it to redraw itself completely when some of the >>> buttons are pressed and on some of the menu actions of the aspects >>> menu. >> >> I do not understand. The update mechanism is for updating a >> presentation based on changes in the model. If you want to deal >> with the UI, you do it with a transmission. > > I want to update the mondrian presentation based on changes made in > the model (either by a specific menu action or by clicking on a > button). The mondrian presentation should basically redraw itself > completely. Well, there are two ways: - either listen to an announcement, or - if you want to trigger it from a menu item, you should just send update to the presentation. However, I have the problem with Mondrian in that I am not passing the presentation, but directly the ViewRenderer in the painting. It is long on my to do list to fix this. I will look into it. >>> - The last 2 columns specify the metrics used in the polymetric >>> view. With a transmission I always get the last selections made, >>> but I need to know all selections made in that column so I can >>> print it in the selectionstatus text box. How is this possible? >> >> A pane models one state: one entity, one selection etc. If you want >> multiple states, you need multiple panes :). So, you need multiple >> panes there and then have a transmission from all of them. > > :-( that is going to use a lot of space. Is there a way to have the > multiple panes do the same collapse trick as in the code that I have > now? It is on my to do list :). You can use tabs for now. Cheers, Doru >>> Also, if no selection at all is made I would like to show that in >>> the box (now the box is removed). >> >> Unfortunately, that is not possible. >> >>> - The last 3 columns actually do not use any input, but I specify >>> them with "transmit to: ; andShow:" Is there a cleaner way to do >>> this? >> >> Nope. That is the desired way. Perhaps I will add a shortcut >> method, but until then, this is Ok. > > OK, thanks! > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "One cannot do more than one can do." From jfabry at dcc.uchile.cl Mon Jan 18 19:35:56 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 15:35:56 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> Message-ID: <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> On 18 Jan 2010, at 14:52, Tudor Girba wrote: >> I want to update the mondrian presentation based on changes made in >> the model (either by a specific menu action or by clicking on a >> button). The mondrian presentation should basically redraw itself >> completely. > > Well, there are two ways: > - either listen to an announcement, or > - if you want to trigger it from a menu item, you should just send > update to the presentation. However, I have the problem with > Mondrian in that I am not passing the presentation, but directly the > ViewRenderer in the painting. It is long on my to do list to fix > this. I will look into it. OK, thanks, please keep me posted. This is quite crucial so that AspectMaps can work as intended ... -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Mon Jan 18 22:26:58 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 18 Jan 2010 22:26:58 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> Message-ID: <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> Hi, It's done in two ways :). 1. The actions defined on the Mondrian presentations now appear as a menu on the root in the view. With this you can trigger update. See: GLMBasicExamples new updatableBrowser (execute "self add: 4" in the inspector and then see what happens in the views) 2. The painting block now gets after the entity variables an entry to the mondrian presentation. So, you can use it for manipulating the presentation from inside the mondrian script: a mondrian painting: [:view :entity :mondrianPresentation | ... ] Cheers, Doru On 18 Jan 2010, at 19:35, Johan Fabry wrote: > > On 18 Jan 2010, at 14:52, Tudor Girba wrote: > >>> I want to update the mondrian presentation based on changes made >>> in the model (either by a specific menu action or by clicking on a >>> button). The mondrian presentation should basically redraw itself >>> completely. >> >> Well, there are two ways: >> - either listen to an announcement, or >> - if you want to trigger it from a menu item, you should just send >> update to the presentation. However, I have the problem with >> Mondrian in that I am not passing the presentation, but directly >> the ViewRenderer in the painting. It is long on my to do list to >> fix this. I will look into it. > > > OK, thanks, please keep me posted. This is quite crucial so that > AspectMaps can work as intended ... > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From stephane.ducasse at inria.fr Mon Jan 18 22:45:21 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 18 Jan 2010 22:45:21 +0100 Subject: [Moose-dev] Re: new browser type: accumulator In-Reply-To: References: <5CDBE3E0-690B-4D83-8E99-85051C718BA7@tudorgirba.com> Message-ID: <53EF4232-8234-4670-A41C-864D9B1AA6ED@inria.fr> I'm forcing myself not to touch pharo or moose and read papers and write papers.... but tomorrow I want to see that. Stef On Jan 18, 2010, at 4:17 PM, Simon Denier wrote: > Hi Doru > > Can you provide a screenshot? > I already did an update this morning and I dont want to do another one now :) > > Anyway, I really like the new look of the Moose finder with tabs, and the return of the custom selection in the list widget. We should also move more things in the toolbar (like initialize meta-descriptions or browse meta). Last week was good: we broke some cyclic dependencies using DSM and Orion (which also starts to look nice), the Package blueprint is now back (even if it's a first version)... > > > On 18 janv. 2010, at 16:02, Tudor Girba wrote: > >> Hi, >> >> I am happy to announce a new feature in Glamour in the form of the Accumulator browser. This browser is an implicit one that just takes the input entity and creates a new pane for it. It is called an Accumulator, because it accumulates panes as you provide a new input. These panes are then displayed as tabs. >> >> A complementary feature is in a new way bundle transmissions are passed around. You can pass it like before with andShow:, or you can do it with andShowWithoutOverride:. It's not a very nice name, but the idea is that it only transmits the presentation if the same presentations were not already found in the target pane. >> >> Using Accumulator you can now emulate browsers that behave like the Eclipse central pane. An example can be found here: >> >> GLMBasicExamples new accumulator openOn: 42. >> >> This feature is now also used in the MooseFinder and MoosePanel. If you open the Panel and select a model, you open it in a new tab. From the Finder, if you double click on an item in a list you get it in a new tab. >> >> I hope you like it. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "The coherence of a trip is given by the clearness of the goal." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Mon Jan 18 23:44:37 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 19:44:37 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> Message-ID: <95DD805D-0AD7-44F7-87BE-5F8C63333F24@dcc.uchile.cl> I did a ConfigurationOfMoose updateDefault and now opening the updatableBrowser example gives me a MNU:LazyMorphTreeMorph>>multiSelection: (and of course the same happens when opening AspectMaps) :-( Did I do anything wrong (again) ? On 18 Jan 2010, at 18:26, Tudor Girba wrote: > Hi, > > It's done in two ways :). > > 1. The actions defined on the Mondrian presentations now appear as a > menu on the root in the view. With this you can trigger update. See: > GLMBasicExamples new updatableBrowser > (execute "self add: 4" in the inspector and then see what happens in > the views) > > 2. The painting block now gets after the entity variables an entry > to the mondrian presentation. So, you can use it for manipulating > the presentation from inside the mondrian script: > > a mondrian > painting: [:view :entity :mondrianPresentation | ... ] > > Cheers, > Doru -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Mon Jan 18 23:48:32 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 18 Jan 2010 23:48:32 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <95DD805D-0AD7-44F7-87BE-5F8C63333F24@dcc.uchile.cl> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> <95DD805D-0AD7-44F7-87BE-5F8C63333F24@dcc.uchile.cl> Message-ID: <0E7A9634-4C33-4AF6-8162-F94537B4E421@gmail.com> Hi, It looks like MorphTreeMorph in the Momo10 repository was not updated. Please do it manually and try again. Let me know if it works. Cheers, Doru On 18 Jan 2010, at 23:44, Johan Fabry wrote: > > I did a ConfigurationOfMoose updateDefault and now opening the > updatableBrowser example gives me a > MNU:LazyMorphTreeMorph>>multiSelection: (and of course the same > happens when opening AspectMaps) :-( Did I do anything wrong (again) ? > > On 18 Jan 2010, at 18:26, Tudor Girba wrote: > >> Hi, >> >> It's done in two ways :). >> >> 1. The actions defined on the Mondrian presentations now appear as >> a menu on the root in the view. With this you can trigger update. >> See: >> GLMBasicExamples new updatableBrowser >> (execute "self add: 4" in the inspector and then see what happens >> in the views) >> >> 2. The painting block now gets after the entity variables an entry >> to the mondrian presentation. So, you can use it for manipulating >> the presentation from inside the mondrian script: >> >> a mondrian >> painting: [:view :entity :mondrianPresentation | ... ] >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution." From jfabry at dcc.uchile.cl Tue Jan 19 00:09:51 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 20:09:51 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <0E7A9634-4C33-4AF6-8162-F94537B4E421@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> <95DD805D-0AD7-44F7-87BE-5F8C63333F24@dcc.uchile.cl> <0E7A9634-4C33-4AF6-8162-F94537B4E421@gmail.com> Message-ID: <0CAAF03D-2EF9-4DDE-BA16-71D6B2BDF076@dcc.uchile.cl> I have Morphic-MorphTreeWidget-AlainPlantec.66 which is the latest version according to the browser, doing a load of it again does not change anything. :-( On 18 Jan 2010, at 19:48, Tudor Girba wrote: > Hi, > > It looks like MorphTreeMorph in the Momo10 repository was not > updated. Please do it manually and try again. > > Let me know if it works. > > Cheers, > Doru > > > On 18 Jan 2010, at 23:44, Johan Fabry wrote: > >> >> I did a ConfigurationOfMoose updateDefault and now opening the >> updatableBrowser example gives me a >> MNU:LazyMorphTreeMorph>>multiSelection: (and of course the same >> happens when opening AspectMaps) :-( Did I do anything wrong >> (again) ? >> >> On 18 Jan 2010, at 18:26, Tudor Girba wrote: >> >>> Hi, >>> >>> It's done in two ways :). >>> >>> 1. The actions defined on the Mondrian presentations now appear as >>> a menu on the root in the view. With this you can trigger update. >>> See: >>> GLMBasicExamples new updatableBrowser >>> (execute "self add: 4" in the inspector and then see what happens >>> in the views) >>> >>> 2. The painting block now gets after the entity variables an >>> entry to the mondrian presentation. So, you can use it for >>> manipulating the presentation from inside the mondrian script: >>> >>> a mondrian >>> painting: [:view :entity :mondrianPresentation | ... ] >>> >>> Cheers, >>> Doru >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving should be concentrated on describing > the problem in a way that is relevant for the solution." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Tue Jan 19 00:18:35 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 19 Jan 2010 00:18:35 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <0CAAF03D-2EF9-4DDE-BA16-71D6B2BDF076@dcc.uchile.cl> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> <95DD805D-0AD7-44F7-87BE-5F8C63333F24@dcc.uchile.cl> <0E7A9634-4C33-4AF6-8162-F94537B4E421@gmail.com> <0CAAF03D-2EF9-4DDE-BA16-71D6B2BDF076@dcc.uchile.cl> Message-ID: <1B04D0DF-945B-4B85-B1A7-30BA0DFF774A@gmail.com> Hi Johan, I was not aware that Alain committed a new version of MorphTreeWidget. You now have a fix for the problem in Glamour-Morphic-tg.246 Cheers, Doru On 19 Jan 2010, at 00:09, Johan Fabry wrote: > > I have Morphic-MorphTreeWidget-AlainPlantec.66 which is the latest > version according to the browser, doing a load of it again does not > change anything. :-( > > On 18 Jan 2010, at 19:48, Tudor Girba wrote: > >> Hi, >> >> It looks like MorphTreeMorph in the Momo10 repository was not >> updated. Please do it manually and try again. >> >> Let me know if it works. >> >> Cheers, >> Doru >> >> >> On 18 Jan 2010, at 23:44, Johan Fabry wrote: >> >>> >>> I did a ConfigurationOfMoose updateDefault and now opening the >>> updatableBrowser example gives me a >>> MNU:LazyMorphTreeMorph>>multiSelection: (and of course the same >>> happens when opening AspectMaps) :-( Did I do anything wrong >>> (again) ? >>> >>> On 18 Jan 2010, at 18:26, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> It's done in two ways :). >>>> >>>> 1. The actions defined on the Mondrian presentations now appear >>>> as a menu on the root in the view. With this you can trigger >>>> update. See: >>>> GLMBasicExamples new updatableBrowser >>>> (execute "self add: 4" in the inspector and then see what happens >>>> in the views) >>>> >>>> 2. The painting block now gets after the entity variables an >>>> entry to the mondrian presentation. So, you can use it for >>>> manipulating the presentation from inside the mondrian script: >>>> >>>> a mondrian >>>> painting: [:view :entity :mondrianPresentation | ... ] >>>> >>>> Cheers, >>>> Doru >>> >>> -- >>> Johan Fabry >>> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >>> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Problem solving should be concentrated on describing >> the problem in a way that is relevant for the solution." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." From jfabry at dcc.uchile.cl Tue Jan 19 03:20:57 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 18 Jan 2010 23:20:57 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> Message-ID: <09C10946-4977-4C1E-9E58-8ABA5C363006@dcc.uchile.cl> OK, so I got it running now, thanks! But I hit the next hurdles: - the updatableBrowser example is too complex for the glamour newbees like me. Can you make a simple example, like using a plain old OrderedCollection {1 2 3} that is shown in a list and a button where hitting the button adds the next number to the collection? - there is no menu in the mondrian presentations of updatableBrowser (and neither in the root of AspectMaps) :-( On 18 Jan 2010, at 18:26, Tudor Girba wrote: > Hi, > > It's done in two ways :). > > 1. The actions defined on the Mondrian presentations now appear as a > menu on the root in the view. With this you can trigger update. See: > GLMBasicExamples new updatableBrowser > (execute "self add: 4" in the inspector and then see what happens in > the views) > > 2. The painting block now gets after the entity variables an entry > to the mondrian presentation. So, you can use it for manipulating > the presentation from inside the mondrian script: > > a mondrian > painting: [:view :entity :mondrianPresentation | ... ] > > Cheers, > Doru -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Tue Jan 19 11:40:43 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 19 Jan 2010 11:40:43 +0100 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <09C10946-4977-4C1E-9E58-8ABA5C363006@dcc.uchile.cl> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> <09C10946-4977-4C1E-9E58-8ABA5C363006@dcc.uchile.cl> Message-ID: <3C4359D1-D3B1-4C95-A09B-8DFB6EB80E44@gmail.com> Hi, > OK, so I got it running now, thanks! > > But I hit the next hurdles: > - the updatableBrowser example is too complex for the glamour > newbees like me. Can you make a simple example, like using a plain > old OrderedCollection {1 2 3} that is shown in a list and a button > where hitting the button adds the next number to the collection? OrderedCollection does not throw announcements, that is why I use a mock collection that does throw announcements when you add and remove entities. I updated the example with a menu. > - there is no menu in the mondrian presentations of updatableBrowser > (and neither in the root of AspectMaps) :-( Yes, it does, only Mondrian shows the root menu only within the bounds of the graph. So, in the example, if you place your mouse between 1 and 2 so that no popup text appears, you will get the menu. It is not ideal, but now the ball is in the Mondrian court to deal with the root menu in the complete canvas :). Anyway, now it looks like we have a small problem in updating the list due to some changes in the MorphTreeWidget. I will look into it. Cheers, Doru > > On 18 Jan 2010, at 18:26, Tudor Girba wrote: > >> Hi, >> >> It's done in two ways :). >> >> 1. The actions defined on the Mondrian presentations now appear as >> a menu on the root in the view. With this you can trigger update. >> See: >> GLMBasicExamples new updatableBrowser >> (execute "self add: 4" in the inspector and then see what happens >> in the views) >> >> 2. The painting block now gets after the entity variables an entry >> to the mondrian presentation. So, you can use it for manipulating >> the presentation from inside the mondrian script: >> >> a mondrian >> painting: [:view :entity :mondrianPresentation | ... ] >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From jfabry at dcc.uchile.cl Wed Jan 20 03:04:15 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 19 Jan 2010 23:04:15 -0300 Subject: [Moose-dev] Re: Glamour: using the new features In-Reply-To: <3C4359D1-D3B1-4C95-A09B-8DFB6EB80E44@gmail.com> References: <302F5B42-6519-4A3E-B141-BD7F536347AD@gmail.com> <57540796-B0F8-446A-B92D-F4DBE7AB78C1@dcc.uchile.cl> <41374F13-D389-457C-9C0F-FE138A95BF14@gmail.com> <905C8FDF-0B35-458F-B427-3957A7FFDBB0@dcc.uchile.cl> <9D1173C4-5D3D-4FC2-AD24-67B2B1664E04@gmail.com> <09C10946-4977-4C1E-9E58-8ABA5C363006@dcc.uchile.cl> <3C4359D1-D3B1-4C95-A09B-8DFB6EB80E44@gmail.com> Message-ID: <26B38EB8-00F6-4960-8453-A92A89271000@dcc.uchile.cl> On 19 Jan 2010, at 07:40, Tudor Girba wrote: >> But I hit the next hurdles: >> - the updatableBrowser example is too complex for the glamour >> newbees like me. Can you make a simple example, like using a plain >> old OrderedCollection {1 2 3} that is shown in a list and a button >> where hitting the button adds the next number to the collection? > > OrderedCollection does not throw announcements, that is why I use a > mock collection that does throw announcements when you add and > remove entities. I know it does not do that. I'm sorry, it seems that I am not being clear. The problem is that the use of this mock collection is needlesly complicating the code. I am all for MVC but in this case it only serves to confuse the picture. Please simplify the example. I as a dumb Glamour user dont know how these announcements work, dont complicate it more by adding an extra layer of indirection. Let the menu item construct the right announcement and send it to where it needs to go. Please dont expect me to go looking at/stepping through the entire code of the MVC setup to find that 1 line of code that sends the update to the right place. >> - there is no menu in the mondrian presentations of >> updatableBrowser (and neither in the root of AspectMaps) :-( > > Yes, it does, only Mondrian shows the root menu only within the > bounds of the graph. So, in the example, if you place your mouse > between 1 and 2 so that no popup text appears, you will get the > menu. It is not ideal, but now the ball is in the Mondrian court to > deal with the root menu in the complete canvas :). OK, found that, thanks! -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Wed Jan 20 04:29:26 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 04:29:26 +0100 Subject: [Moose-dev] system complexity Message-ID: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> Hi, I changed the rendering of System Complexity to be computed like in the VW version with each hierarchy in a box and all the lonely classes separately. I still have to add the label on top of each hierarchy. You can also see a group of classes as selection within system complexity. This is useful when you want to relate the result of a query with the hierarchies. In the process, I also changed a bit the toolbar of the MOBrowser. The buttons still do not look nice because they need proper icons (and because buttons just do not look nice in the watery theme), but I added a menu with export to files. Cheers, Doru -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter." -------------- next part -------------- A non-text attachment was scrubbed... Name: system complexity.png Type: image/png Size: 100693 bytes Desc: not available URL: -------------- next part -------------- From stephane.ducasse at inria.fr Wed Jan 20 08:42:22 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Wed, 20 Jan 2010 08:42:22 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> Message-ID: <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> neat I like that Did you see that I pushed the new polymorph into pharo. Stef On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: > Hi, > > I changed the rendering of System Complexity to be computed like in the VW version with each hierarchy in a box and all the lonely classes separately. I still have to add the label on top of each hierarchy. > > You can also see a group of classes as selection within system complexity. This is useful when you want to relate the result of a query with the hierarchies. > > In the process, I also changed a bit the toolbar of the MOBrowser. The buttons still do not look nice because they need proper icons (and because buttons just do not look nice in the watery theme), but I added a menu with export to files. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Relationships are of two kinds: those we choose and those that happen. They both matter." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Wed Jan 20 10:25:59 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 10:25:59 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> Message-ID: <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> Hi Stef, > neat I like that > Did you see that I pushed the new polymorph into pharo. I thought that it made it only in Pharo 1.1. Or did I get it wrong? Cheers, Doru > Stef > > > On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: > >> Hi, >> >> I changed the rendering of System Complexity to be computed like in >> the VW version with each hierarchy in a box and all the lonely >> classes separately. I still have to add the label on top of each >> hierarchy. >> >> You can also see a group of classes as selection within system >> complexity. This is useful when you want to relate the result of a >> query with the hierarchies. >> >> In the process, I also changed a bit the toolbar of the MOBrowser. >> The buttons still do not look nice because they need proper icons >> (and because buttons just do not look nice in the watery theme), >> but I added a menu with export to files. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Relationships are of two kinds: those we choose and those that >> happen. They both matter." >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "We cannot reach the flow of things unless we let go." From stephane.ducasse at inria.fr Wed Jan 20 13:56:21 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Wed, 20 Jan 2010 13:56:21 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> Message-ID: On Jan 20, 2010, at 10:25 AM, Tudor Girba wrote: > Hi Stef, > >> neat I like that >> Did you see that I pushed the new polymorph into pharo. > > I thought that it made it only in Pharo 1.1. Or did I get it wrong? yes in 1.1 :) BTW we are planning a faster 1.1 release track. Stef > Cheers, > Doru > >> Stef >> >> >> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >> >>> Hi, >>> >>> I changed the rendering of System Complexity to be computed like in the VW version with each hierarchy in a box and all the lonely classes separately. I still have to add the label on top of each hierarchy. >>> >>> You can also see a group of classes as selection within system complexity. This is useful when you want to relate the result of a query with the hierarchies. >>> >>> In the process, I also changed a bit the toolbar of the MOBrowser. The buttons still do not look nice because they need proper icons (and because buttons just do not look nice in the watery theme), but I added a menu with export to files. >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Wed Jan 20 15:16:48 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Wed, 20 Jan 2010 15:16:48 +0100 Subject: [Moose-dev] Issue 225: History in Finder Evaluator pane Message-ID: Hi Doru How hard would it to implement this enhancement? I see two paths, the dirty one and the clean one: Dirty: make two panes stacked, one for the evaluator, the other a table widget with the history. The history is stored in the moose entity. Clean: make a custom widget. Problem: where to store the history (if I browse to a parent entity and lose the finder pane of the entity, then I want my query history when coming back in the browser) What do you think. -- Simon From tudor.girba at gmail.com Wed Jan 20 16:16:19 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 16:16:19 +0100 Subject: [Moose-dev] Re: Issue 225: History in Finder Evaluator pane In-Reply-To: References: Message-ID: <787589EE-C220-4511-AE61-389CA6FEE57E@gmail.com> Hi Simon, I implemented this in VW a long time ago. My solution was to actually have an external class that would store this information as methods and relate them to the types of entities that they make sense on. Afterwards, the Evaluator, instead of just displaying self it displays the result of querying this database. I might take a shot at it this evening. Cheers, Doru On 20 Jan 2010, at 15:16, Simon Denier wrote: > Hi Doru > > How hard would it to implement this enhancement? > > I see two paths, the dirty one and the clean one: > > Dirty: make two panes stacked, one for the evaluator, the other a > table widget with the history. The history is stored in the moose > entity. > > Clean: make a custom widget. Problem: where to store the history (if > I browse to a parent entity and lose the finder pane of the entity, > then I want my query history when coming back in the browser) > > > What do you think. > > -- > Simon > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one." From jfabry at dcc.uchile.cl Wed Jan 20 18:46:43 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 20 Jan 2010 14:46:43 -0300 Subject: [Moose-dev] Glamour: cross-pane updating implementation. Message-ID: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> Hi all, another case of DIY from me, so probably to be handled with care (although it should be cleaner than the last bit of code I sent to the list). All my insistance on updating in the other thread is because, fundamentally I wanted to allow a menu item/button/whatever in pane #source to trigger the update in pane #dest. Note that 'browser transmit to: #dest; from: #source' does not achieve this when in #source you do an update. The one-liner below does. Place it in the menu item/button/whatever of #source whenever you want to do the update. (Assuming browser is the instance of GLMTabulator/ GLMFinder/... that you are using). (browser paneNamed: #mpanel) presentations do: [:pres | pres update]. Doru, any chance of adding this to the API for browsers? -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From jfabry at dcc.uchile.cl Wed Jan 20 19:17:30 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 20 Jan 2010 15:17:30 -0300 Subject: [Moose-dev] Glamour: bug (?) in browser from: transformed: Message-ID: Hi all, I am using a from: transformed: at some point, and I just got the transformation block being called with a nil value when the from pane gets a selection of nothing. my showOn: block does not state allowNil, so I did not expect this to happen. Is it expected that transformation blocks always check for nil-ness of their arguments? -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Wed Jan 20 20:04:38 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 20:04:38 +0100 Subject: [Moose-dev] Re: Glamour: bug (?) in browser from: transformed: In-Reply-To: References: Message-ID: <45C67940-D3F7-49A1-95C9-75364C5290EC@gmail.com> Hi Johan, On 20 Jan 2010, at 19:17, Johan Fabry wrote: > Hi all, > > I am using a from: transformed: at some point, and I just got the > transformation block being called with a nil value when the from > pane gets a selection of nothing. my showOn: block does not state > allowNil, so I did not expect this to happen. allowNil when defined on the presentation, only controls the activation of the presentation. The information is still sent to the destination port. > Is it expected that transformation blocks always check for nil-ness > of their arguments? Yes. What is missing is the condition on a transformation. It is since long on my to do list. I created an issue: http://code.google.com/p/moose-technology/issues/detail?id=303 Cheers, Doru > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From tudor.girba at gmail.com Wed Jan 20 20:16:05 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 20:16:05 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> Message-ID: <47486C66-57FC-42CF-A815-26046784F157@gmail.com> >> Hi Stef, >> >>> neat I like that >>> Did you see that I pushed the new polymorph into pharo. >> >> I thought that it made it only in Pharo 1.1. Or did I get it wrong? > > yes in 1.1 :) > > BTW > we are planning a faster 1.1 release track. Will this be available soon? :) Doru > Stef > >> Cheers, >> Doru >> >>> Stef >>> >>> >>> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>> I changed the rendering of System Complexity to be computed like >>>> in the VW version with each hierarchy in a box and all the lonely >>>> classes separately. I still have to add the label on top of each >>>> hierarchy. >>>> >>>> You can also see a group of classes as selection within system >>>> complexity. This is useful when you want to relate the result of >>>> a query with the hierarchies. >>>> >>>> In the process, I also changed a bit the toolbar of the >>>> MOBrowser. The buttons still do not look nice because they need >>>> proper icons (and because buttons just do not look nice in the >>>> watery theme), but I added a menu with export to files. >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Relationships are of two kinds: those we choose and those that >>>> happen. They both matter." >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "We cannot reach the flow of things unless we let go." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "When people care, great things can happen." From tudor.girba at gmail.com Wed Jan 20 20:35:07 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 20:35:07 +0100 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> Message-ID: <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> Hi, > another case of DIY from me, so probably to be handled with care > (although it should be cleaner than the last bit of code I sent to > the list). > > All my insistance on updating in the other thread is because, > fundamentally I wanted to allow a menu item/button/whatever in pane > #source to trigger the update in pane #dest. Note that 'browser > transmit to: #dest; from: #source' does not achieve this when in > #source you do an update. The one-liner below does. Place it in the > menu item/button/whatever of #source whenever you want to do the > update. (Assuming browser is the instance of GLMTabulator/ > GLMFinder/... that you are using). > > (browser paneNamed: #mpanel) presentations do: [:pres | pres update]. > > Doru, any chance of adding this to the API for browsers? Not really :). This breaks the encapsulation between panes, as in our model, panes should only talk with each other via transmissions. Maybe there will be another mechanism for this, but I first need to learn more about when exactly this is needed and why it is not possible to do it via an existing mechanism. Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice." From jfabry at dcc.uchile.cl Wed Jan 20 20:55:08 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 20 Jan 2010 16:55:08 -0300 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> Message-ID: <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> On 20 Jan 2010, at 16:35, Tudor Girba wrote: >> >> Doru, any chance of adding this to the API for browsers? > > Not really :). > > This breaks the encapsulation between panes, as in our model, panes > should only talk with each other via transmissions. Maybe there will > be another mechanism for this, but I first need to learn more about > when exactly this is needed and why it is not possible to do it via > an existing mechanism. OK, then consider my case, AspectMaps (screenshot below for clarity). - All the buttons make some change to the model that is being displayed in the mondrian panel - idem for some menu items on 'aspects in project' (e.g. changing the color of a displayed aspect) So for that I do my update trick. Can I do this cleanly with transmissions? If so, how? -------------- next part -------------- A non-text attachment was scrubbed... Name: AMnow.tiff Type: image/tiff Size: 125542 bytes Desc: not available URL: -------------- next part -------------- -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Wed Jan 20 22:19:18 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 22:19:18 +0100 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> Message-ID: <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> Hi, Why is it not possible to have a single transmission from all the buttons to the mondrian pane and decide the visualization based on all provided input? Cheers, Doru On 20 Jan 2010, at 20:55, Johan Fabry wrote: > > On 20 Jan 2010, at 16:35, Tudor Girba wrote: >>> >>> Doru, any chance of adding this to the API for browsers? >> >> Not really :). >> >> This breaks the encapsulation between panes, as in our model, panes >> should only talk with each other via transmissions. Maybe there >> will be another mechanism for this, but I first need to learn more >> about when exactly this is needed and why it is not possible to do >> it via an existing mechanism. > > > OK, then consider my case, AspectMaps (screenshot below for clarity). > - All the buttons make some change to the model that is being > displayed in the mondrian panel > - idem for some menu items on 'aspects in project' (e.g. changing > the color of a displayed aspect) > > So for that I do my update trick. Can I do this cleanly with > transmissions? If so, how? > > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." From stephane.ducasse at inria.fr Wed Jan 20 20:54:37 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Wed, 20 Jan 2010 20:54:37 +0100 Subject: [Moose-dev] about ada, c and C++ extraction Message-ID: I got in contact with a person doing a lisp (that is generated to C) that is used to script GCC. I imagine that we could use it to get information out of GCC for C++, C, Ada So I will try to get in contact and C. Stef From tudor.girba at gmail.com Wed Jan 20 22:54:15 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 20 Jan 2010 22:54:15 +0100 Subject: [Moose-dev] Re: about ada, c and C++ extraction In-Reply-To: References: Message-ID: <92B0D0BF-10E7-4E2C-9E59-083A88C8E08E@gmail.com> Sounds interesting. Cheers, Doru On 20 Jan 2010, at 20:54, St?phane Ducasse wrote: > I got in contact with a person doing a lisp (that is generated to C) > that is used to script > GCC. > I imagine that we could use it to get information out of GCC for C+ > +, C, Ada > > So I will try to get in contact and C. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." From alexandre at bergel.eu Wed Jan 20 23:00:09 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 20 Jan 2010 19:00:09 -0300 Subject: [Moose-dev] Re: about ada, c and C++ extraction In-Reply-To: References: Message-ID: <64137C67-99FB-4D3F-BA7B-5D0AA100FD8F@bergel.eu> Keep us informed! Alexandre On 20 Jan 2010, at 16:54, St?phane Ducasse wrote: > I got in contact with a person doing a lisp (that is generated to C) > that is used to script > GCC. > I imagine that we could use it to get information out of GCC for C+ > +, C, Ada > > So I will try to get in contact and C. > > Stef > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Wed Jan 20 23:09:21 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Wed, 20 Jan 2010 23:09:21 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: <47486C66-57FC-42CF-A815-26046784F157@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> Message-ID: On Jan 20, 2010, at 8:16 PM, Tudor Girba wrote: >>> Hi Stef, >>> >>>> neat I like that >>>> Did you see that I pushed the new polymorph into pharo. >>> >>> I thought that it made it only in Pharo 1.1. Or did I get it wrong? >> >> yes in 1.1 :) >> >> BTW >> we are planning a faster 1.1 release track. > > Will this be available soon? :) :) soon but not sooner :) No seriously I want to have 1.1 release by June/july max because there are too many fixes already included. Stef > > Doru > >> Stef >> >>> Cheers, >>> Doru >>> >>>> Stef >>>> >>>> >>>> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >>>> >>>>> Hi, >>>>> >>>>> I changed the rendering of System Complexity to be computed like in the VW version with each hierarchy in a box and all the lonely classes separately. I still have to add the label on top of each hierarchy. >>>>> >>>>> You can also see a group of classes as selection within system complexity. This is useful when you want to relate the result of a query with the hierarchies. >>>>> >>>>> In the process, I also changed a bit the toolbar of the MOBrowser. The buttons still do not look nice because they need proper icons (and because buttons just do not look nice in the watery theme), but I added a menu with export to files. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "We cannot reach the flow of things unless we let go." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Thu Jan 21 02:11:31 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 20 Jan 2010 22:11:31 -0300 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> Message-ID: <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> I'd love to. How? Seriously. It has never been made clear to me how I myself can send a transmission from a button or menu item to a pane such that it refreshes itself. On 20 Jan 2010, at 18:19, Tudor Girba wrote: > Hi, > > Why is it not possible to have a single transmission from all the > buttons to the mondrian pane and decide the visualization based on > all provided input? > > Cheers, > Doru > -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Thu Jan 21 08:29:45 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 21 Jan 2010 08:29:45 +0100 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> Message-ID: Hi, The first parameter of an action is the presentation. And the presentation has access to its pane. So, the preferred way is for the presentation to only talk with its pane and then let transmissions deal with links between panes. So, you can do: a somePresentation act: [:p :entity | (p pane portNamed: #somePort) value: entity something] on: $x entitled: 'Update' or shorter: a somePresentation update: #somePort on: $x entitled: 'Update' with: [:p :entity | entity something] So, I guess that the buttons in your case are part of an ActionList that is placed in one pane. So, you could populate 6 different ports in that pane and then have one transmission from all ports to the mondrian pane (entity port). Is this better? Cheers, Doru On 21 Jan 2010, at 02:11, Johan Fabry wrote: > > I'd love to. How? > > Seriously. It has never been made clear to me how I myself can send > a transmission from a button or menu item to a pane such that it > refreshes itself. > > On 20 Jan 2010, at 18:19, Tudor Girba wrote: > >> Hi, >> >> Why is it not possible to have a single transmission from all the >> buttons to the mondrian pane and decide the visualization based on >> all provided input? >> >> Cheers, >> Doru >> > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Be rather willing to give than demanding to get." From jannik.laval at gmail.com Thu Jan 21 15:17:10 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Thu, 21 Jan 2010 15:17:10 +0100 Subject: [Moose-dev] Sharing menus through pragmas between MooseFinder/Mondrian/Orion... Message-ID: Hi guys, Is it a good idea to use pragmas to make generic menus in Mondrian ? Another idea is to have a generic pragma which is shared between MooseFinder/Mondrian/Orion... What are your opinion ? Cheers --- Jannik Laval --- From tudor.girba at gmail.com Thu Jan 21 15:28:56 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 21 Jan 2010 15:28:56 +0100 Subject: [Moose-dev] Re: Sharing menus through pragmas between MooseFinder/Mondrian/Orion... In-Reply-To: References: Message-ID: Hi Jannik, Moose introduces Object>>mooseMenuMorph which builds a menu based on the #menuItem: and #menuItem:category: pragmas. This should be present in every Moose tools. In Glamour, you should use Object>>mooseFinderActions which build a Glamour set of actions based on the same thing. This is very important to allow tools to interoperate smoothly. Cheers, Doru On 21 Jan 2010, at 15:17, Laval Jannik wrote: > Hi guys, > > Is it a good idea to use pragmas to make generic menus in Mondrian ? > > Another idea is to have a generic pragma which is shared between > MooseFinder/Mondrian/Orion... > > What are your opinion ? > > Cheers > --- > Jannik Laval > --- > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" From tudor.girba at gmail.com Thu Jan 21 16:38:48 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 21 Jan 2010 16:38:48 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> Message-ID: <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> At the idea of Simon, we now have a "Customizable System Complexity" view spawn-able from the Visualize menu of a ClassGroup. This is a small Glamour-based browser that allows you to choose the metrics to be mapped on the visualization. See the attached picture. Cheers, Doru -------------- next part -------------- A non-text attachment was scrubbed... Name: Customizable System Complexity.png Type: image/png Size: 66888 bytes Desc: not available URL: -------------- next part -------------- On 20 Jan 2010, at 23:09, St?phane Ducasse wrote: > > On Jan 20, 2010, at 8:16 PM, Tudor Girba wrote: > >>>> Hi Stef, >>>> >>>>> neat I like that >>>>> Did you see that I pushed the new polymorph into pharo. >>>> >>>> I thought that it made it only in Pharo 1.1. Or did I get it wrong? >>> >>> yes in 1.1 :) >>> >>> BTW >>> we are planning a faster 1.1 release track. >> >> Will this be available soon? :) > > :) > soon but not sooner :) > No seriously I want to have 1.1 release by June/july max > because there are too many fixes already included. > > > Stef >> >> Doru >> >>> Stef >>> >>>> Cheers, >>>> Doru >>>> >>>>> Stef >>>>> >>>>> >>>>> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I changed the rendering of System Complexity to be computed >>>>>> like in the VW version with each hierarchy in a box and all the >>>>>> lonely classes separately. I still have to add the label on top >>>>>> of each hierarchy. >>>>>> >>>>>> You can also see a group of classes as selection within system >>>>>> complexity. This is useful when you want to relate the result >>>>>> of a query with the hierarchies. >>>>>> >>>>>> In the process, I also changed a bit the toolbar of the >>>>>> MOBrowser. The buttons still do not look nice because they need >>>>>> proper icons (and because buttons just do not look nice in the >>>>>> watery theme), but I added a menu with export to files. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Relationships are of two kinds: those we choose and those that >>>>>> happen. They both matter." >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "We cannot reach the flow of things unless we let go." >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Be rather willing to give than demanding to get." From alexandre at bergel.eu Thu Jan 21 16:48:14 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Thu, 21 Jan 2010 12:48:14 -0300 Subject: [Moose-dev] Re: system complexity In-Reply-To: <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> Message-ID: <837343BA-4F36-44C5-A56B-FFB2F3DAC55D@bergel.eu> Excellent! Alexandre On 21 Jan 2010, at 12:38, Tudor Girba wrote: > At the idea of Simon, we now have a "Customizable System Complexity" > view spawn-able from the Visualize menu of a ClassGroup. > > This is a small Glamour-based browser that allows you to choose the > metrics to be mapped on the visualization. See the attached picture. > > Cheers, > Doru > > > > > > > > > On 20 Jan 2010, at 23:09, St?phane Ducasse wrote: > >> >> On Jan 20, 2010, at 8:16 PM, Tudor Girba wrote: >> >>>>> Hi Stef, >>>>> >>>>>> neat I like that >>>>>> Did you see that I pushed the new polymorph into pharo. >>>>> >>>>> I thought that it made it only in Pharo 1.1. Or did I get it >>>>> wrong? >>>> >>>> yes in 1.1 :) >>>> >>>> BTW >>>> we are planning a faster 1.1 release track. >>> >>> Will this be available soon? :) >> >> :) >> soon but not sooner :) >> No seriously I want to have 1.1 release by June/july max >> because there are too many fixes already included. >> >> >> Stef >>> >>> Doru >>> >>>> Stef >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I changed the rendering of System Complexity to be computed >>>>>>> like in the VW version with each hierarchy in a box and all >>>>>>> the lonely classes separately. I still have to add the label >>>>>>> on top of each hierarchy. >>>>>>> >>>>>>> You can also see a group of classes as selection within system >>>>>>> complexity. This is useful when you want to relate the result >>>>>>> of a query with the hierarchies. >>>>>>> >>>>>>> In the process, I also changed a bit the toolbar of the >>>>>>> MOBrowser. The buttons still do not look nice because they >>>>>>> need proper icons (and because buttons just do not look nice >>>>>>> in the watery theme), but I added a menu with export to files. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Relationships are of two kinds: those we choose and those >>>>>>> that happen. They both matter." >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "We cannot reach the flow of things unless we let go." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jfabry at dcc.uchile.cl Thu Jan 21 16:59:36 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Thu, 21 Jan 2010 12:59:36 -0300 Subject: [Moose-dev] Re: system complexity In-Reply-To: <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> Message-ID: Cool! Where can I find it? On 21 Jan 2010, at 12:38, Tudor Girba wrote: > At the idea of Simon, we now have a "Customizable System Complexity" > view spawn-able from the Visualize menu of a ClassGroup. > > This is a small Glamour-based browser that allows you to choose the > metrics to be mapped on the visualization. See the attached picture. > > Cheers, > Doru > > > > > -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Thu Jan 21 17:05:55 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 21 Jan 2010 17:05:55 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> Message-ID: It is in Moose-Finder: FAMIXClassGroup>>viewSystemComplexityInWizard Cheers, Doru On 21 Jan 2010, at 16:59, Johan Fabry wrote: > > Cool! Where can I find it? > > On 21 Jan 2010, at 12:38, Tudor Girba wrote: > >> At the idea of Simon, we now have a "Customizable System >> Complexity" view spawn-able from the Visualize menu of a ClassGroup. >> >> This is a small Glamour-based browser that allows you to choose the >> metrics to be mapped on the visualization. See the attached picture. >> >> Cheers, >> Doru >> >> >> >> >> > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From stephane.ducasse at inria.fr Thu Jan 21 17:09:35 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 21 Jan 2010 17:09:35 +0100 Subject: [Moose-dev] Re: system complexity In-Reply-To: <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> References: <784BDF2F-EAD1-4830-98DC-85794241D5FB@gmail.com> <9A193A01-0105-4383-8D44-C46322F6730D@inria.fr> <74BC9D90-4649-4CE2-BA4A-0BED05BD981B@gmail.com> <47486C66-57FC-42CF-A815-26046784F157@gmail.com> <0B5A7EC4-8E36-4D88-B352-9881346B9C99@gmail.com> Message-ID: feel like deja vu :) Stef On Jan 21, 2010, at 4:38 PM, Tudor Girba wrote: > At the idea of Simon, we now have a "Customizable System Complexity" view spawn-able from the Visualize menu of a ClassGroup. > > This is a small Glamour-based browser that allows you to choose the metrics to be mapped on the visualization. See the attached picture. > > Cheers, > Doru > > > > > > > > > On 20 Jan 2010, at 23:09, St?phane Ducasse wrote: > >> >> On Jan 20, 2010, at 8:16 PM, Tudor Girba wrote: >> >>>>> Hi Stef, >>>>> >>>>>> neat I like that >>>>>> Did you see that I pushed the new polymorph into pharo. >>>>> >>>>> I thought that it made it only in Pharo 1.1. Or did I get it wrong? >>>> >>>> yes in 1.1 :) >>>> >>>> BTW >>>> we are planning a faster 1.1 release track. >>> >>> Will this be available soon? :) >> >> :) >> soon but not sooner :) >> No seriously I want to have 1.1 release by June/july max >> because there are too many fixes already included. >> >> >> Stef >>> >>> Doru >>> >>>> Stef >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Jan 20, 2010, at 4:29 AM, Tudor Girba wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I changed the rendering of System Complexity to be computed like in the VW version with each hierarchy in a box and all the lonely classes separately. I still have to add the label on top of each hierarchy. >>>>>>> >>>>>>> You can also see a group of classes as selection within system complexity. This is useful when you want to relate the result of a query with the hierarchies. >>>>>>> >>>>>>> In the process, I also changed a bit the toolbar of the MOBrowser. The buttons still do not look nice because they need proper icons (and because buttons just do not look nice in the watery theme), but I added a menu with export to files. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> -- >>>>>>> www.tudorgirba.com >>>>>>> >>>>>>> "Relationships are of two kinds: those we choose and those that happen. They both matter." >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "We cannot reach the flow of things unless we let go." >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From cy.delaunay at gmail.com Fri Jan 22 11:18:25 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Fri, 22 Jan 2010 11:18:25 +0100 Subject: [Moose-dev] Private methods in C Message-ID: Hello, A thing I want to do when importing C code in moose , is to see if a function is Private or Public. After reading some documentations about C, a private function ( A function that can't be used outside the module in which it's defined) is a function declared with 'Static'. Am I wrong ? If this is ok, the first thing is: => FAMIXFunction > isPublic just check if the function is called outside the module. This does not really correspond to the description above. the secong thing is: => How can I see if a function is declared with 'static' ? For the moment I can have this information in the signatiure of the function. But to retrieve that, I have to parse the string. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Fri Jan 22 11:37:16 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 22 Jan 2010 07:37:16 -0300 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: References: Message-ID: Hi Cyrille, This is not quite exact. A static function is a function that is visible only in the file that defines it. It is true that it could be assimilated as a private function. But the privacy is also obtained by not having the function signature in the .h file. Contrary to Java, there is no such a keyword in C that says if a function is private a or public, but there is a number of technical conventions. Alexandre On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: > Hello, > > A thing I want to do when importing C code in moose , is to see if a > function is Private or Public. > After reading some documentations about C, a private function ( A > function that can't be used outside the module in which it's > defined) is a function declared with 'Static'. Am I wrong ? > > If this is ok, the first thing is: > => FAMIXFunction > isPublic just check if the function is called > outside the module. This does not really correspond to the > description above. > > the secong thing is: > => How can I see if a function is declared with 'static' ? > For the moment I can have this information in the signatiure of > the function. But to retrieve that, I have to parse the string. > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From cy.delaunay at gmail.com Fri Jan 22 11:50:52 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Fri, 22 Jan 2010 11:50:52 +0100 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: References: Message-ID: If I have a function 'int f1(void)' defined in 'file1.c'. If I declared at the begining of another file 'file2.c' : 'extern int f1(void);' , and use it later in this file (without declaring it in a '.h' file) . Will it work ? 2010/1/22 Alexandre Bergel > Hi Cyrille, > > This is not quite exact. A static function is a function that is visible > only in the file that defines it. It is true that it could be assimilated as > a private function. But the privacy is also obtained by not having the > function signature in the .h file. Contrary to Java, there is no such a > keyword in C that says if a function is private a or public, but there is a > number of technical conventions. > > Alexandre > > > > On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: > > Hello, >> >> A thing I want to do when importing C code in moose , is to see if a >> function is Private or Public. >> After reading some documentations about C, a private function ( A function >> that can't be used outside the module in which it's defined) is a function >> declared with 'Static'. Am I wrong ? >> >> If this is ok, the first thing is: >> => FAMIXFunction > isPublic just check if the function is called outside >> the module. This does not really correspond to the description above. >> >> the secong thing is: >> => How can I see if a function is declared with 'static' ? >> For the moment I can have this information in the signatiure of the >> function. But to retrieve that, I have to parse the string. >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Fri Jan 22 12:07:34 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 22 Jan 2010 08:07:34 -0300 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: References: Message-ID: <902AADB2-5328-4B5A-84C4-846ED34C70A1@bergel.eu> > If I have a function 'int f1(void)' defined in 'file1.c'. > If I declared at the begining of another file 'file2.c' : 'extern > int f1(void);' , and use it later in this file (without declaring it > in a '.h' file) . > Will it work ? He he, 'extern' is a way to say that the function is defined somewhere else. It is therefore public. http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/external.html#ExternDecls Alexandre NB: I am now away until this evening. without internet. > > 2010/1/22 Alexandre Bergel > Hi Cyrille, > > This is not quite exact. A static function is a function that is > visible only in the file that defines it. It is true that it could > be assimilated as a private function. But the privacy is also > obtained by not having the function signature in the .h file. > Contrary to Java, there is no such a keyword in C that says if a > function is private a or public, but there is a number of technical > conventions. > > Alexandre > > > > On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: > > Hello, > > A thing I want to do when importing C code in moose , is to see if a > function is Private or Public. > After reading some documentations about C, a private function ( A > function that can't be used outside the module in which it's > defined) is a function declared with 'Static'. Am I wrong ? > > If this is ok, the first thing is: > => FAMIXFunction > isPublic just check if the function is called > outside the module. This does not really correspond to the > description above. > > the secong thing is: > => How can I see if a function is declared with 'static' ? > For the moment I can have this information in the signatiure of > the function. But to retrieve that, I have to parse the string. > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Fri Jan 22 13:12:09 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 22 Jan 2010 13:12:09 +0100 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: <902AADB2-5328-4B5A-84C4-846ED34C70A1@bergel.eu> References: <902AADB2-5328-4B5A-84C4-846ED34C70A1@bergel.eu> Message-ID: <3C36A254-0BF3-4EC2-BD01-C10F5FD3092F@inria.fr> Yep, this is a topic to discuss, because the way to interpret function visibility is still unclear to me: So we have: - static functions, which really are private (visibility reduced to file) - functions defined in c file but not in header file - however, you could still find an extern declaration to this function in another file. - functions defined in c file and in header file - which is the convention for good C projects as Alex noted Anyway, by default a function is globally visible, but you have to include its declaration (through an include header or a declaration) somewhere if you want to use it in your file and it has not been defined before. Also, the convention when one finds an 'extern declaration' is to consider that the function is not defined in the corresponding c file, but in another c file. So I would suggest the following conventions: - static functions: private - functions defined but not declared (even through an extern): 'local' - functions defined and declared in corresponding header: public - functions defined and declared with extern somewhere else: global? On 22 janv. 2010, at 12:07, Alexandre Bergel wrote: >> If I have a function 'int f1(void)' defined in 'file1.c'. >> If I declared at the begining of another file 'file2.c' : 'extern int f1(void);' , and use it later in this file (without declaring it in a '.h' file) . >> Will it work ? > > He he, 'extern' is a way to say that the function is defined somewhere else. It is therefore public. > http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/external.html#ExternDecls > > Alexandre > > NB: I am now away until this evening. without internet. > >> >> 2010/1/22 Alexandre Bergel >> Hi Cyrille, >> >> This is not quite exact. A static function is a function that is visible only in the file that defines it. It is true that it could be assimilated as a private function. But the privacy is also obtained by not having the function signature in the .h file. Contrary to Java, there is no such a keyword in C that says if a function is private a or public, but there is a number of technical conventions. >> >> Alexandre >> >> >> >> On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: >> >> Hello, >> >> A thing I want to do when importing C code in moose , is to see if a function is Private or Public. >> After reading some documentations about C, a private function ( A function that can't be used outside the module in which it's defined) is a function declared with 'Static'. Am I wrong ? >> >> If this is ok, the first thing is: >> => FAMIXFunction > isPublic just check if the function is called outside the module. This does not really correspond to the description above. >> >> the secong thing is: >> => How can I see if a function is declared with 'static' ? >> For the moment I can have this information in the signatiure of the function. But to retrieve that, I have to parse the string. >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From jfabry at dcc.uchile.cl Fri Jan 22 19:28:40 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Fri, 22 Jan 2010 15:28:40 -0300 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> Message-ID: <19F61D70-DFDB-4A7C-BACF-1A112638A6AF@dcc.uchile.cl> Your first option does not work :-( portNamed: is not implemented. So I tried the following variant, intending the #mpanel to update itself but nothing happens :-( browser transmit to: #buttons; andShow:[ :a | (a actionList) act: [:p :entity | entity dooFooTransform. (p pane port: #mpanel) value: entity ] entitled: 'DoFooTransform'; ... On 21 Jan 2010, at 04:29, Tudor Girba wrote: > Hi, > > The first parameter of an action is the presentation. And the > presentation has access to its pane. So, the preferred way is for > the presentation to only talk with its pane and then let > transmissions deal with links between panes. So, you can do: > > a somePresentation > act: [:p :entity | (p pane portNamed: #somePort) value: entity > something] on: $x entitled: 'Update' > > or shorter: > > a somePresentation > update: #somePort on: $x entitled: 'Update' with: [:p :entity | > entity something] > > So, I guess that the buttons in your case are part of an ActionList > that is placed in one pane. So, you could populate 6 different ports > in that pane and then have one transmission from all ports to the > mondrian pane (entity port). > > Is this better? > > Cheers, > Doru -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Fri Jan 22 21:15:32 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 22 Jan 2010 21:15:32 +0100 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <19F61D70-DFDB-4A7C-BACF-1A112638A6AF@dcc.uchile.cl> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> <19F61D70-DFDB-4A7C-BACF-1A112638A6AF@dcc.uchile.cl> Message-ID: Hi Johan, On 22 Jan 2010, at 19:28, Johan Fabry wrote: > Your first option does not work :-( portNamed: is not implemented. Indeed, it is port:, not portNamed: > So I tried the following variant, intending the #mpanel to update > itself but nothing happens :-( Wait, #mpanel is the name of the port that you just updated. You need to have a transmission that origins in that port, and if you have it, it should trigger. Does it not happen like that? Cheers, Doru > browser transmit to: #buttons; > andShow:[ :a | > (a actionList) > act: [:p :entity | entity dooFooTransform. (p pane port: #mpanel) > value: entity ] entitled: 'DoFooTransform'; > ... > > > On 21 Jan 2010, at 04:29, Tudor Girba wrote: > >> Hi, >> >> The first parameter of an action is the presentation. And the >> presentation has access to its pane. So, the preferred way is for >> the presentation to only talk with its pane and then let >> transmissions deal with links between panes. So, you can do: >> >> a somePresentation >> act: [:p :entity | (p pane portNamed: #somePort) value: entity >> something] on: $x entitled: 'Update' >> >> or shorter: >> >> a somePresentation >> update: #somePort on: $x entitled: 'Update' with: [:p :entity | >> entity something] >> >> So, I guess that the buttons in your case are part of an ActionList >> that is placed in one pane. So, you could populate 6 different >> ports in that pane and then have one transmission from all ports to >> the mondrian pane (entity port). >> >> Is this better? >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." From tudor.girba at gmail.com Fri Jan 22 21:41:21 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 22 Jan 2010 21:41:21 +0100 Subject: [Moose-dev] smart MorphTreeWidget Message-ID: <2C1B7D70-5E6E-4DE2-AEE2-A9F9C2BDE1E9@gmail.com> Hi, I am very happy to announce that Alain Plantec produced an excellent feature to the already rich MorphTreeWidget: you can limit the amount of items visible in the list and you can expand it either incrementally or altogether once you get to the bottom of the existing items. The idea is that when you have very long lists, you most of the time do not want to see all details but just want some visual support for what is in the list. This is at least what we have in Moose. So, if you expect very long lists, you can always say in Glamour something like: a list ... showOnly: 50 An example, can be seen in GLMBasicExamples>>treeWithAmountFiltering, and of course in MoosePanel. Cheers, Doru GlamorousHealth shows a significant improvement (aprox 2-3 times faster): Report produced on 2010-01-22T21:31:14+00:00 ------------------ Opening Browser Benchmark: 15 openings => 2260 ms ------------------ ------------------ Selecting Item in Browser Benchmark 100 size and selections => 3615 ms 200 size and selections => 3147 ms 300 size and selections => 3281 ms 400 size and selections => 3249 ms 500 size and selections => 4033 ms 600 size and selections => 3341 ms 700 size and selections => 3364 ms 800 size and selections => 3576 ms 900 size and selections => 3456 ms 1000 size and selections => 3548 ms 1500 size and selections => 3823 ms 2000 size and selections => 4018 ms ------------------ ------------------ Selecting in finder item Benchmark 1 size and selections => 142 ms 5 size and selections => 787 ms 10 size and selections => 1631 ms 15 size and selections => 2458 ms 20 size and selections => 3344 ms 25 size and selections => 4206 ms 30 size and selections => 5169 ms 35 size and selections => 6329 ms 40 size and selections => 7226 ms 45 size and selections => 8078 ms 50 size and selections => 9629 ms ------------------ -- www.tudorgirba.com "Don't give to get. Just give." From tudor.girba at gmail.com Fri Jan 22 21:15:32 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 22 Jan 2010 21:15:32 +0100 Subject: [Moose-dev] Re: Glamour: cross-pane updating implementation. In-Reply-To: <19F61D70-DFDB-4A7C-BACF-1A112638A6AF@dcc.uchile.cl> References: <7756B337-23A6-4F4E-B48E-6C249D5DF4F3@dcc.uchile.cl> <3D4FCEBD-6FB9-426D-A9E4-55BB49FD1A98@gmail.com> <5405CBB4-37AC-468E-939C-F03742B3582B@dcc.uchile.cl> <75357A2A-AE3C-4E9C-8EBF-4DA6ADF0283A@gmail.com> <1D223088-369A-4923-9B8D-41A361A655F4@dcc.uchile.cl> <19F61D70-DFDB-4A7C-BACF-1A112638A6AF@dcc.uchile.cl> Message-ID: Hi Johan, On 22 Jan 2010, at 19:28, Johan Fabry wrote: > Your first option does not work :-( portNamed: is not implemented. Indeed, it is port:, not portNamed: > So I tried the following variant, intending the #mpanel to update > itself but nothing happens :-( Wait, #mpanel is the name of the port that you just updated. You need to have a transmission that origins in that port, and if you have it, it should trigger. Does it not happen like that? Cheers, Doru > browser transmit to: #buttons; > andShow:[ :a | > (a actionList) > act: [:p :entity | entity dooFooTransform. (p pane port: #mpanel) > value: entity ] entitled: 'DoFooTransform'; > ... > > > On 21 Jan 2010, at 04:29, Tudor Girba wrote: > >> Hi, >> >> The first parameter of an action is the presentation. And the >> presentation has access to its pane. So, the preferred way is for >> the presentation to only talk with its pane and then let >> transmissions deal with links between panes. So, you can do: >> >> a somePresentation >> act: [:p :entity | (p pane portNamed: #somePort) value: entity >> something] on: $x entitled: 'Update' >> >> or shorter: >> >> a somePresentation >> update: #somePort on: $x entitled: 'Update' with: [:p :entity | >> entity something] >> >> So, I guess that the buttons in your case are part of an ActionList >> that is placed in one pane. So, you could populate 6 different >> ports in that pane and then have one transmission from all ports to >> the mondrian pane (entity port). >> >> Is this better? >> >> Cheers, >> Doru > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." From stephane.ducasse at inria.fr Fri Jan 22 22:26:31 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 22 Jan 2010 22:26:31 +0100 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: <3C36A254-0BF3-4EC2-BD01-C10F5FD3092F@inria.fr> References: <902AADB2-5328-4B5A-84C4-846ED34C70A1@bergel.eu> <3C36A254-0BF3-4EC2-BD01-C10F5FD3092F@inria.fr> Message-ID: <642D603F-06EC-43FA-B1D4-D95249AAB601@inria.fr> On Jan 22, 2010, at 1:12 PM, Simon Denier wrote: > > Yep, this is a topic to discuss, because the way to interpret function visibility is still unclear to me: > > So we have: > > - static functions, which really are private (visibility reduced to file) > - functions defined in c file but not in header file - however, you could still find an extern declaration to this function in another file. > - functions defined in c file and in header file - which is the convention for good C projects as Alex noted > > Anyway, by default a function is globally visible, but you have to include its declaration (through an include header or a declaration) somewhere if you want to use it in your file and it has not been defined before. yes > Also, the convention when one finds an 'extern declaration' is to consider that the function is not defined in the corresponding c file, but in another c file. > > So I would suggest the following conventions: > - static functions: private > - functions defined but not declared (even through an extern): 'local' do they are really local? > - functions defined and declared in corresponding header: public > - functions defined and declared with extern somewhere else: global? > > > > On 22 janv. 2010, at 12:07, Alexandre Bergel wrote: > >>> If I have a function 'int f1(void)' defined in 'file1.c'. >>> If I declared at the begining of another file 'file2.c' : 'extern int f1(void);' , and use it later in this file (without declaring it in a '.h' file) . >>> Will it work ? >> >> He he, 'extern' is a way to say that the function is defined somewhere else. It is therefore public. >> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/external.html#ExternDecls >> >> Alexandre >> >> NB: I am now away until this evening. without internet. >> >>> >>> 2010/1/22 Alexandre Bergel >>> Hi Cyrille, >>> >>> This is not quite exact. A static function is a function that is visible only in the file that defines it. It is true that it could be assimilated as a private function. But the privacy is also obtained by not having the function signature in the .h file. Contrary to Java, there is no such a keyword in C that says if a function is private a or public, but there is a number of technical conventions. >>> >>> Alexandre >>> >>> >>> >>> On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: >>> >>> Hello, >>> >>> A thing I want to do when importing C code in moose , is to see if a function is Private or Public. >>> After reading some documentations about C, a private function ( A function that can't be used outside the module in which it's defined) is a function declared with 'Static'. Am I wrong ? >>> >>> If this is ok, the first thing is: >>> => FAMIXFunction > isPublic just check if the function is called outside the module. This does not really correspond to the description above. >>> >>> the secong thing is: >>> => How can I see if a function is declared with 'static' ? >>> For the moment I can have this information in the signatiure of the function. But to retrieve that, I have to parse the string. >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Fri Jan 22 22:27:13 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 22 Jan 2010 22:27:13 +0100 Subject: [Moose-dev] Re: smart MorphTreeWidget In-Reply-To: <2C1B7D70-5E6E-4DE2-AEE2-A9F9C2BDE1E9@gmail.com> References: <2C1B7D70-5E6E-4DE2-AEE2-A9F9C2BDE1E9@gmail.com> Message-ID: <055EE914-D4C1-4A31-A0A0-61263A4CABF9@inria.fr> alain is cool! Stef On Jan 22, 2010, at 9:41 PM, Tudor Girba wrote: > Hi, > > I am very happy to announce that Alain Plantec produced an excellent feature to the already rich MorphTreeWidget: you can limit the amount of items visible in the list and you can expand it either incrementally or altogether once you get to the bottom of the existing items. > > The idea is that when you have very long lists, you most of the time do not want to see all details but just want some visual support for what is in the list. This is at least what we have in Moose. > > So, if you expect very long lists, you can always say in Glamour something like: > > a list > ... > showOnly: 50 > > An example, can be seen in GLMBasicExamples>>treeWithAmountFiltering, and of course in MoosePanel. > > Cheers, > Doru > > > GlamorousHealth shows a significant improvement (aprox 2-3 times faster): > Report produced on 2010-01-22T21:31:14+00:00 > ------------------ > Opening Browser Benchmark: > 15 openings => 2260 ms > ------------------ > > ------------------ > Selecting Item in Browser Benchmark > 100 size and selections => 3615 ms > 200 size and selections => 3147 ms > 300 size and selections => 3281 ms > 400 size and selections => 3249 ms > 500 size and selections => 4033 ms > 600 size and selections => 3341 ms > 700 size and selections => 3364 ms > 800 size and selections => 3576 ms > 900 size and selections => 3456 ms > 1000 size and selections => 3548 ms > 1500 size and selections => 3823 ms > 2000 size and selections => 4018 ms > ------------------ > > ------------------ > Selecting in finder item Benchmark > 1 size and selections => 142 ms > 5 size and selections => 787 ms > 10 size and selections => 1631 ms > 15 size and selections => 2458 ms > 20 size and selections => 3344 ms > 25 size and selections => 4206 ms > 30 size and selections => 5169 ms > 35 size and selections => 6329 ms > 40 size and selections => 7226 ms > 45 size and selections => 8078 ms > 50 size and selections => 9629 ms > ------------------ > > > -- > www.tudorgirba.com > > "Don't give to get. Just give." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Sat Jan 23 00:00:59 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 23 Jan 2010 00:00:59 +0100 Subject: [Moose-dev] scam cfp References: <821d39851001220258j4e3a9e1al4c006ffe0e7545ea@mail.gmail.com> Message-ID: Perhaps this might be of interest to some of you. Cheers, Doru > Call for Papers and Tool Demo Proposals - SCAM 2010 > > Tenth IEEE International Working Conference > on Source Code Analysis and Manipulation > > 12th-13th September 2010, > Timisoara, Romania, > Co-located with ICSM 2010 > > http://www2010.ieee-scam.org/ > > Sponsored by IEEE CS (pending) > In cooperation with: > - Semantic Designs Inc., Austin, TX, USA > - Univ. "Politehnica" Timisoara, Romania > - Centre for Research in Evolution, Search and Testing (CREST), > King's College London, UK > > ---------------- > Conference aims: > ---------------- > The aim of this working conference is to bring together researchers > and > practitioners working on theory, techniques and applications which > concern analysis and/or manipulation of the source code of computer > systems. While much attention in the wider software engineering > > community is properly directed towards other aspects of systems > development and evolution, such as specification, design and > requirements engineering, it is the source code that contains the only > precise description of the behaviour of the system. The analysis and > > manipulation of source code thus remains a pressing concern. > > --------- > Keynotes: > --------- > This year SCAM will feature two outstanding keynotes: > - Mark Harman, King's College London, UK > - Andreas Zeller, Saarland University, Germany > > --------------------------------- > Covered topics and paper formats: > --------------------------------- > We welcome submission of papers that describe original and significant > work in the field of source code analysis and manipulation. Topics of > interest include, but are not limited to: > > * program transformation > * abstract interpretation > * program slicing > * source level software metrics > * decompilation > * source level testing and verification > * source level optimization > * program comprehension > > Note that SCAM explicitly solicits results from any theoretical or > technological domain that can be applied to these and similar topics. > > Submitted papers should not be longer than 10 pages. We also welcome > submission of 2 page proposals for tool demonstrations expected to be > performed live at the conference. All papers submitted should follow > IEEE Computer Society Press Proceedings Author Guidelines. The > > papers should be submitted electronically via the conference web site. > Submitted papers should not have been previously published, and should > not have been concurrently submitted elsewhere. > > ------------ > Proceedings: > ------------ > All accepted papers will appear in the proceedings which will be > published by the IEEE Computer Society Press. > > -------------- > Special Issue: > -------------- > Best papers from SCAM 2010 will be considered for revision, extension, > and publication in a special issue of the Science of Computer > Programming journal edited by Elsevier. > > ---------------- > Important Dates: > ---------------- > Deadline for submission: > Abstract due: 23rd April, 2010 > Full paper due: 30 April, 2010 > Notification: 7th June, 2010 > Working Conference: 12th-13th September 2010 > > ------------------------ > Conference Organization: > ------------------------ > > General Chair > Massimiliano Di Penta, Research Centre on Software Technology, > Universita degli Studi del Sannio, Italy > > > Program Co-Chairs > Jurgen Vinju, Centrum Wiskunde & Informatica, The Netherlands > Cristina Marinescu, Politehnica University of Timisoara, Romania > > > Publicity Chair > Zheng Li, CREST Centre, Department of Computer Science, King?s College > London, UK > > Finance Chair > Dave Binkley, Computer Science Department, Loyola College in > Maryland, USA > > Tool Demonstration Chair > Pascal Cuoq, CEA-Recherche Technologique, France > > Local Arrangements Chair > Marius Minea, Politehnica University of Timisoara, Romania > > > > ----------------------------------------- > Steering Committee and Program Committee: > ----------------------------------------- > See the conference Website > > > -- > Jurgen Vinju > - Centrum Wiskunde & Informatica - SEN1 > - INRIA Lille - ATEAMS > - Universiteit van Amsterdam > > www: http://jurgen.vinju.org,http://www.cwi.nl, http://www.meta-environment.nl > ,http://twitter.com/jurgenvinju > skype: jurgen.vinju > -- www.tudorgirba.com "Being happy is a matter of choice." -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Sat Jan 23 03:40:45 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Fri, 22 Jan 2010 23:40:45 -0300 Subject: [Moose-dev] Re: Private methods in C In-Reply-To: <3C36A254-0BF3-4EC2-BD01-C10F5FD3092F@inria.fr> References: <902AADB2-5328-4B5A-84C4-846ED34C70A1@bergel.eu> <3C36A254-0BF3-4EC2-BD01-C10F5FD3092F@inria.fr> Message-ID: <5985E597-4A96-4912-B349-0BB5D9CC6E37@bergel.eu> > So I would suggest the following conventions: > - static functions: private > - functions defined but not declared (even through an extern): 'local' > - functions defined and declared in corresponding header: public > - functions defined and declared with extern somewhere else: global? Do we need more than just public/private? Alexandre > > > > On 22 janv. 2010, at 12:07, Alexandre Bergel wrote: > >>> If I have a function 'int f1(void)' defined in 'file1.c'. >>> If I declared at the begining of another file 'file2.c' : 'extern >>> int f1(void);' , and use it later in this file (without declaring >>> it in a '.h' file) . >>> Will it work ? >> >> He he, 'extern' is a way to say that the function is defined >> somewhere else. It is therefore public. >> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/external.html#ExternDecls >> >> Alexandre >> >> NB: I am now away until this evening. without internet. >> >>> >>> 2010/1/22 Alexandre Bergel >>> Hi Cyrille, >>> >>> This is not quite exact. A static function is a function that is >>> visible only in the file that defines it. It is true that it could >>> be assimilated as a private function. But the privacy is also >>> obtained by not having the function signature in the .h file. >>> Contrary to Java, there is no such a keyword in C that says if a >>> function is private a or public, but there is a number of >>> technical conventions. >>> >>> Alexandre >>> >>> >>> >>> On 22 Jan 2010, at 07:18, Cyrille Delaunay wrote: >>> >>> Hello, >>> >>> A thing I want to do when importing C code in moose , is to see if >>> a function is Private or Public. >>> After reading some documentations about C, a private function ( A >>> function that can't be used outside the module in which it's >>> defined) is a function declared with 'Static'. Am I wrong ? >>> >>> If this is ok, the first thing is: >>> => FAMIXFunction > isPublic just check if the function is called >>> outside the module. This does not really correspond to the >>> description above. >>> >>> the secong thing is: >>> => How can I see if a function is declared with 'static' ? >>> For the moment I can have this information in the signatiure of >>> the function. But to retrieve that, I have to parse the string. >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jannik.laval at gmail.com Sat Jan 23 11:26:32 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Sat, 23 Jan 2010 11:26:32 +0100 Subject: [Moose-dev] MOEasel really slow Message-ID: <5372BC75-CED4-4E62-AD11-B98F321052F8@gmail.com> Hi, I try to do a simple visualization for a demo. In a MOEasel, the scroll bar is really slow... I use a pharodev-10505 and the last default version of Moose. The code I execute is : ===== "System complexity" | classes | classes := Collection withAllSubclasses. view shape rectangle width: [:cls | cls instVarNames size * 5]; height: [:cls | cls methods size ]; linearFillColor: [ :cls | cls methods inject: 0 into: [:sum :el | sum + el getSourceFromFile lineCount ]] within: classes. view nodes: classes. view edgesFrom: #superclass. view treeLayout ==== Has someone an idea of the problem ? Cheers, --- Jannik Laval --- From cy.delaunay at gmail.com Mon Jan 25 10:19:22 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 10:19:22 +0100 Subject: [Moose-dev] retrieve 'Memory class' in CAnalyzer Message-ID: Hello, A thing it would be cool to retrieve from C code for a function, is the thing called 'Memory class'. It is the word prefixing a function declaration: - global - local - static - extern - register I have looked at a xml file generated with srcml and a function is declared like that: static void ... So it seems to be quite simple to retrieve, what do you think ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cy.delaunay at gmail.com Mon Jan 25 10:41:02 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 10:41:02 +0100 Subject: [Moose-dev] CAnalyzer never retrieve the declaredType of a function Message-ID: When sending 'declaredType' (defined in FAMIXBehaviouralEntity) to a CAFunction, it always return nil. I have wrote a test for that but I have not the permission to commit in the squeaksource repository. If someone could add me, that would be great. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Mon Jan 25 12:54:18 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 25 Jan 2010 12:54:18 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: <83C92D4C-089D-4552-A4D4-A0350CD691AE@inria.fr> On 25 janv. 2010, at 10:19, Cyrille Delaunay wrote: > Hello, > > A thing it would be cool to retrieve from C code for a function, is the thing called 'Memory class'. It is the word prefixing a function declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is declared like that: > static void ... yep, that would be good. > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From Simon.Denier at inria.fr Mon Jan 25 12:56:12 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 25 Jan 2010 12:56:12 +0100 Subject: [Moose-dev] Re: CAnalyzer never retrieve the declaredType of a function In-Reply-To: References: Message-ID: <45F44C30-26C2-4F43-BC81-3AE10C72CD55@inria.fr> On 25 janv. 2010, at 10:41, Cyrille Delaunay wrote: > When sending 'declaredType' (defined in FAMIXBehaviouralEntity) to a CAFunction, it always return nil. > I have wrote a test for that but I have not the permission to commit in the squeaksource repository. If someone could add me, that would be great. ok done. Don't forget to open an issue in the tracker. -- Simon From alexandre at bergel.eu Mon Jan 25 13:05:05 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 09:05:05 -0300 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: Yes Cyrille, it would be great. Do you want to give a try? Let us know when done. I will review the code. Do not forget unit tests :-) Cheers, Alexandre On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > Hello, > > A thing it would be cool to retrieve from C code for a function, is > the thing called 'Memory class'. It is the word prefixing a function > declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is > declared like that: > static void type> ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Mon Jan 25 13:05:59 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 09:05:59 -0300 Subject: [Moose-dev] Re: CAnalyzer never retrieve the declaredType of a function In-Reply-To: References: Message-ID: <46FDFBCD-9D8B-4424-8BEE-322240D62D94@bergel.eu> Ideally, what would be the result for this? The package in which it is defined? Alexandre On 25 Jan 2010, at 06:41, Cyrille Delaunay wrote: > When sending 'declaredType' (defined in FAMIXBehaviouralEntity) to a > CAFunction, it always return nil. > I have wrote a test for that but I have not the permission to commit > in the squeaksource repository. If someone could add me, that would > be great. > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From cy.delaunay at gmail.com Mon Jan 25 13:09:36 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 13:09:36 +0100 Subject: [Moose-dev] Re: CAnalyzer never retrieve the declaredType of a function In-Reply-To: <46FDFBCD-9D8B-4424-8BEE-322240D62D94@bergel.eu> References: <46FDFBCD-9D8B-4424-8BEE-322240D62D94@bergel.eu> Message-ID: I would have expected the type return by the function. For a the function 'int bar()', it would be 'int'. Am I wrong? I opened an issue: http://code.google.com/p/moose-technology/issues/detail?id=308 2010/1/25 Alexandre Bergel > Ideally, what would be the result for this? > The package in which it is defined? > > Alexandre > > > > On 25 Jan 2010, at 06:41, Cyrille Delaunay wrote: > > When sending 'declaredType' (defined in FAMIXBehaviouralEntity) to a >> CAFunction, it always return nil. >> I have wrote a test for that but I have not the permission to commit in >> the squeaksource repository. If someone could add me, that would be great. >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cy.delaunay at gmail.com Mon Jan 25 13:12:06 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 13:12:06 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: Ok, let's see :) 2010/1/25 Alexandre Bergel > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, >> >> A thing it would be cool to retrieve from C code for a function, is the >> thing called 'Memory class'. It is the word prefixing a function >> declaration: >> - global >> - local >> - static >> - extern >> - register >> >> I have looked at a xml file generated with srcml and a function is >> declared like that: >> static void ... >> >> So it seems to be quite simple to retrieve, what do you think ? >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliverof at lu.unisi.ch Mon Jan 25 13:36:25 2010 From: oliverof at lu.unisi.ch (Fernando olivero) Date: Mon, 25 Jan 2010 13:36:25 +0100 Subject: [Moose-dev] ConfigurationOfGlamour: Glamour and Mondrian decoupling In-Reply-To: References: Message-ID: Tudor i think ConfigurationOfGlamour should provide groups for decoupling Glamour installation and Mondrian installation. Not everybody using scriptable browsers want to use Mondrian panes. In summary, In the default group leave out Mondrian packages dependencies and provide a metacello group for loading Glamour+Mondrian explicitly. Pros: Faster installation time and decoupling Glamour from Mondrian. Cons: people not familiar with Metacello could get puzzled, but for this you could provide convenience method in ConfigurationOfGlamour class ( like we did in ConfigurationOfAlien). What do you think? Fernando pd: In the method you provide some groups already. baseline20beta3: spec ... spec group: 'Tests' with: #( 'Glamour-Tests' 'Glamour-Examples' 'Glamour-Test-Morphic'). .... From cy.delaunay at gmail.com Mon Jan 25 14:11:37 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 14:11:37 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: Memory Class apply on Function but also on variables. The common class for both type is FAMIXNamedEntity. Is it a good idea to define an instance variable 'memoryClass' in this class ? 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. >> Do you want to give a try? Let us know when done. I will review the code. >> Do not forget unit tests :-) >> >> Cheers, >> Alexandre >> >> >> On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: >> >> Hello, >>> >>> A thing it would be cool to retrieve from C code for a function, is the >>> thing called 'Memory class'. It is the word prefixing a function >>> declaration: >>> - global >>> - local >>> - static >>> - extern >>> - register >>> >>> I have looked at a xml file generated with srcml and a function is >>> declared like that: >>> static void ... >>> >>> So it seems to be quite simple to retrieve, what do you think ? >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Mon Jan 25 14:26:28 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 10:26:28 -0300 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: I am not a FAMIX expert, but I would create class extensions on FAMIXNamedEntity and use properties to store the memory class. Providing tests are key here, if we need to change the implementation later on. Alexandre On 25 Jan 2010, at 10:11, Cyrille Delaunay wrote: > Memory Class apply on Function but also on variables. The common > class for both type is FAMIXNamedEntity. Is it a good idea to define > an instance variable 'memoryClass' in this class ? > > 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the > code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, > > A thing it would be cool to retrieve from C code for a function, is > the thing called 'Memory class'. It is the word prefixing a function > declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is > declared like that: > static void type> ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Mon Jan 25 14:41:59 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 25 Jan 2010 14:41:59 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: > Memory Class apply on Function but also on variables. The common class for both type is FAMIXNamedEntity. Is it a good idea to define an instance variable 'memoryClass' in this class ? Use the extension mechanism of MooseEntity for state. See MooseEntity>>privateState and EntityState class > > 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, > > A thing it would be cool to retrieve from C code for a function, is the thing called 'Memory class'. It is the word prefixing a function declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is declared like that: > static void ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Mon Jan 25 14:56:18 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 10:56:18 -0300 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: Yeah, this is what I meant. Alexandre On 25 Jan 2010, at 10:41, Simon Denier wrote: > > On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: > >> Memory Class apply on Function but also on variables. The common >> class for both type is FAMIXNamedEntity. Is it a good idea to >> define an instance variable 'memoryClass' in this class ? > > > Use the extension mechanism of MooseEntity for state. > > See MooseEntity>>privateState and EntityState class > > >> >> 2010/1/25 Cyrille Delaunay >> Ok, let's see :) >> >> 2010/1/25 Alexandre Bergel >> >> Yes Cyrille, it would be great. >> Do you want to give a try? Let us know when done. I will review the >> code. >> Do not forget unit tests :-) >> >> Cheers, >> Alexandre >> >> >> On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: >> >> Hello, >> >> A thing it would be cool to retrieve from C code for a function, is >> the thing called 'Memory class'. It is the word prefixing a >> function declaration: >> - global >> - local >> - static >> - extern >> - register >> >> I have looked at a xml file generated with srcml and a function is >> declared like that: >> static void> type> ... >> >> So it seems to be quite simple to retrieve, what do you think ? >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From cy.delaunay at gmail.com Mon Jan 25 17:05:30 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Mon, 25 Jan 2010 17:05:30 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: This is done. Note that the common name is 'StorageClass' and not 'MemoryClass' like I said. For the moment, if a specific storageClass is specified before a function (#static or #extern ) or a variable (#static #extern #register or #auto), it will retrieve and store it. It will help me to do what I want now. But I should complete it: -> if no class is specified, store the default one. Documentation on the web is saying a lot of different things, but I think for both (functions and variables), the default storageClass is #global -> what about other kind of entities. What is involved if I have " typedef static ..... ". I have written some tests. 2010/1/25 Alexandre Bergel > Yeah, this is what I meant. > > Alexandre > > > On 25 Jan 2010, at 10:41, Simon Denier wrote: > > >> On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: >> >> Memory Class apply on Function but also on variables. The common class >>> for both type is FAMIXNamedEntity. Is it a good idea to define an instance >>> variable 'memoryClass' in this class ? >>> >> >> >> Use the extension mechanism of MooseEntity for state. >> >> See MooseEntity>>privateState and EntityState class >> >> >> >>> 2010/1/25 Cyrille Delaunay >>> Ok, let's see :) >>> >>> 2010/1/25 Alexandre Bergel >>> >>> Yes Cyrille, it would be great. >>> Do you want to give a try? Let us know when done. I will review the code. >>> Do not forget unit tests :-) >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: >>> >>> Hello, >>> >>> A thing it would be cool to retrieve from C code for a function, is the >>> thing called 'Memory class'. It is the word prefixing a function >>> declaration: >>> - global >>> - local >>> - static >>> - extern >>> - register >>> >>> I have looked at a xml file generated with srcml and a function is >>> declared like that: >>> static void ... >>> >>> So it seems to be quite simple to retrieve, what do you think ? >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Mon Jan 25 18:01:26 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 14:01:26 -0300 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: <5E243787-77A2-4891-8018-F783D50AC4A3@bergel.eu> Ok, I will try in a few minutes. I am loading the whole stuff now... Alexandre On 25 Jan 2010, at 13:05, Cyrille Delaunay wrote: > This is done. Note that the common name is 'StorageClass' and not > 'MemoryClass' like I said. > For the moment, if a specific storageClass is specified before a > function (#static or #extern ) or a variable (#static #extern > #register or #auto), it will retrieve and store it. It will help me > to do what I want now. > But I should complete it: > -> if no class is specified, store the default one. Documentation on > the web is saying a lot of different things, but I think for both > (functions and variables), the default storageClass is #global > -> what about other kind of entities. What is involved if I have " > typedef static ..... ". > > I have written some tests. > > 2010/1/25 Alexandre Bergel > Yeah, this is what I meant. > > Alexandre > > > On 25 Jan 2010, at 10:41, Simon Denier wrote: > > > On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: > > Memory Class apply on Function but also on variables. The common > class for both type is FAMIXNamedEntity. Is it a good idea to define > an instance variable 'memoryClass' in this class ? > > > Use the extension mechanism of MooseEntity for state. > > See MooseEntity>>privateState and EntityState class > > > > 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the > code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, > > A thing it would be cool to retrieve from C code for a function, is > the thing called 'Memory class'. It is the word prefixing a function > declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is > declared like that: > static void type> ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jfabry at dcc.uchile.cl Mon Jan 25 18:03:02 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Mon, 25 Jan 2010 14:03:02 -0300 Subject: [Moose-dev] System complexity: Useful metrics? Message-ID: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> Hi all, a quick poll: which selection of metrics do you find the most useful when using a system complexity type visualisation, and what are your goals when using the visualisation? AspectMaps has this view as a part, but I am reluctant to include all the options that are in the customisable system complexity view, because this is a loooooooooot. A subset would be less intimidating to the user ... -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From alexandre at bergel.eu Mon Jan 25 18:44:39 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 14:44:39 -0300 Subject: [Moose-dev] Re: System complexity: Useful metrics? In-Reply-To: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> References: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> Message-ID: <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> I use the have the traditional ones: width = #numberOfAttributes height = #numberOfMethods color = #numberOfLinesOfCode Regarding my goals, it really depends on the situation. Alexandre On 25 Jan 2010, at 14:03, Johan Fabry wrote: > Hi all, > > a quick poll: which selection of metrics do you find the most useful > when using a system complexity type visualisation, and what are your > goals when using the visualisation? > > AspectMaps has this view as a part, but I am reluctant to include > all the options that are in the customisable system complexity view, > because this is a loooooooooot. A subset would be less intimidating > to the user ... > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Mon Jan 25 20:27:56 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 16:27:56 -0300 Subject: [Moose-dev] Mondrian Health Report : good news, we gained a significant speedup Message-ID: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> Dear List, You will find below the health report of today. I removed two important bottlenecks: node translations and computing absolute bounds. Layouting nodes is more then 100 times faster! You can now do a "view nodes: (1 to: 20000)" in an easel without having the time to take a coffee! Here is the comment of Mondrian-Alexandre_Bergel.352 -=-=-=-=-=-=-=-=-=-=-=-= Major speed improvement: - MOGraphElement>>absoluteBounds uses now a cache. This helped speeding up Mondrian by 35% - Make MORectangleShape>>display:on: use absoluteBounds instead of absoluteBoundsFor:, which speeded the UI up of 14% - optimization when translating nodes (MOGraphElement>>translatedBy:), we gained a significant speedup when layouting nodes -=-=-=-=-=-=-=-=-=-=-=-= Report produced on 2010-01-23T18:17:13+00:00 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 3 ms 200 nodes => 5 ms 300 nodes => 6 ms 400 nodes => 7 ms 500 nodes => 9 ms 600 nodes => 10 ms 700 nodes => 12 ms 800 nodes => 14 ms 900 nodes => 15 ms 1000 nodes => 17 ms 1600 nodes => 28 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 2 ms 20 edges => 6 ms 30 edges => 12 ms 40 edges => 28 ms 50 edges => 48 ms 60 edges => 74 ms 70 edges => 115 ms 80 edges => 169 ms 90 edges => 254 ms 100 edges => 335 ms 200 edges => 4356 ms 300 edges => 35919 ms 55.54 % of methods are covered Progress from last time: -0.1 % Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From stephane.ducasse at inria.fr Mon Jan 25 21:12:59 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 25 Jan 2010 21:12:59 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> Message-ID: coooool Stef On Jan 25, 2010, at 8:27 PM, Alexandre Bergel wrote: > Dear List, > > You will find below the health report of today. I removed two important bottlenecks: node translations and computing absolute bounds. Layouting nodes is more then 100 times faster! > You can now do a "view nodes: (1 to: 20000)" in an easel without having the time to take a coffee! > > Here is the comment of Mondrian-Alexandre_Bergel.352 > -=-=-=-=-=-=-=-=-=-=-=-= > Major speed improvement: > - MOGraphElement>>absoluteBounds uses now a cache. This helped speeding up Mondrian by 35% > - Make MORectangleShape>>display:on: use absoluteBounds instead of absoluteBoundsFor:, which speeded the UI up of 14% > - optimization when translating nodes (MOGraphElement>>translatedBy:), we gained a significant speedup when layouting nodes > -=-=-=-=-=-=-=-=-=-=-=-= > > Report produced on 2010-01-23T18:17:13+00:00 > Benchmark ManyNode (simple rendering of nodes) : > 100 nodes => 3 ms > 200 nodes => 5 ms > 300 nodes => 6 ms > 400 nodes => 7 ms > 500 nodes => 9 ms > 600 nodes => 10 ms > 700 nodes => 12 ms > 800 nodes => 14 ms > 900 nodes => 15 ms > 1000 nodes => 17 ms > 1600 nodes => 28 ms > Benchmark ManyEdges (simple rendering of edges) : > 10 edges => 2 ms > 20 edges => 6 ms > 30 edges => 12 ms > 40 edges => 28 ms > 50 edges => 48 ms > 60 edges => 74 ms > 70 edges => 115 ms > 80 edges => 169 ms > 90 edges => 254 ms > 100 edges => 335 ms > 200 edges => 4356 ms > 300 edges => 35919 ms > 55.54 % of methods are covered > Progress from last time: -0.1 % > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From stephane.ducasse at inria.fr Mon Jan 25 21:14:04 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Mon, 25 Jan 2010 21:14:04 +0100 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: <10BED4CD-FF0A-4B5F-9AF2-EDD3A25A6C34@inria.fr> would you mind renaming it storageKind ? because class is confusing in Smalltalk we will always think that this is a constructor. Stef On Jan 25, 2010, at 5:05 PM, Cyrille Delaunay wrote: > This is done. Note that the common name is 'StorageClass' and not 'MemoryClass' like I said. > For the moment, if a specific storageClass is specified before a function (#static or #extern ) or a variable (#static #extern #register or #auto), it will retrieve and store it. It will help me to do what I want now. > But I should complete it: > -> if no class is specified, store the default one. Documentation on the web is saying a lot of different things, but I think for both (functions and variables), the default storageClass is #global > -> what about other kind of entities. What is involved if I have " typedef static ..... ". > > I have written some tests. > > 2010/1/25 Alexandre Bergel > Yeah, this is what I meant. > > Alexandre > > > On 25 Jan 2010, at 10:41, Simon Denier wrote: > > > On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: > > Memory Class apply on Function but also on variables. The common class for both type is FAMIXNamedEntity. Is it a good idea to define an instance variable 'memoryClass' in this class ? > > > Use the extension mechanism of MooseEntity for state. > > See MooseEntity>>privateState and EntityState class > > > > 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, > > A thing it would be cool to retrieve from C code for a function, is the thing called 'Memory class'. It is the word prefixing a function declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is declared like that: > static void ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Mon Jan 25 21:45:34 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Mon, 25 Jan 2010 21:45:34 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> Message-ID: <2CE49ABA-602E-4985-B41E-9715FC25AAF7@gmail.com> Cool indeed. It even looks like the problem of the bounds while zooming is solved as well. That's great! Cheers, Doru On 25 Jan 2010, at 21:12, St?phane Ducasse wrote: > coooool > > Stef > > On Jan 25, 2010, at 8:27 PM, Alexandre Bergel wrote: > >> Dear List, >> >> You will find below the health report of today. I removed two >> important bottlenecks: node translations and computing absolute >> bounds. Layouting nodes is more then 100 times faster! >> You can now do a "view nodes: (1 to: 20000)" in an easel without >> having the time to take a coffee! >> >> Here is the comment of Mondrian-Alexandre_Bergel.352 >> -=-=-=-=-=-=-=-=-=-=-=-= >> Major speed improvement: >> - MOGraphElement>>absoluteBounds uses now a cache. This helped >> speeding up Mondrian by 35% >> - Make MORectangleShape>>display:on: use absoluteBounds instead of >> absoluteBoundsFor:, which speeded the UI up of 14% >> - optimization when translating nodes >> (MOGraphElement>>translatedBy:), we gained a significant speedup >> when layouting nodes >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Report produced on 2010-01-23T18:17:13+00:00 >> Benchmark ManyNode (simple rendering of nodes) : >> 100 nodes => 3 ms >> 200 nodes => 5 ms >> 300 nodes => 6 ms >> 400 nodes => 7 ms >> 500 nodes => 9 ms >> 600 nodes => 10 ms >> 700 nodes => 12 ms >> 800 nodes => 14 ms >> 900 nodes => 15 ms >> 1000 nodes => 17 ms >> 1600 nodes => 28 ms >> Benchmark ManyEdges (simple rendering of edges) : >> 10 edges => 2 ms >> 20 edges => 6 ms >> 30 edges => 12 ms >> 40 edges => 28 ms >> 50 edges => 48 ms >> 60 edges => 74 ms >> 70 edges => 115 ms >> 80 edges => 169 ms >> 90 edges => 254 ms >> 100 edges => 335 ms >> 200 edges => 4356 ms >> 300 edges => 35919 ms >> 55.54 % of methods are covered >> Progress from last time: -0.1 % >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From Simon.Denier at inria.fr Mon Jan 25 23:44:48 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Mon, 25 Jan 2010 23:44:48 +0100 Subject: [Moose-dev] Glamour: Making the table widget more customizable Message-ID: <2E0A1755-2382-411E-A398-CBE40AF61EE4@inria.fr> I was thinking about how to make the table widget more customizable, for example being able to dynamically add a column to a table. It just occurred to me that maybe it was even possible to do it without getting into the Morphic code, just using Glamour. So be it. It works.... sort of.... It does not refresh the table layout but the finder shows it is there. | finder | finder := GLMFinder new. finder table title: 'Number'; display: [ :x | 1 to: x ]; act: [:p| p column: 'Double' evaluated: [ :each | (each * 2) asString ]. p update ] entitled: 'add column'; actions: [ :list | self actionsFor: list ]; column: 'Even' evaluated: [ :each | each even asString ]; column: 'Odd' evaluated: [ :each | each odd asString ]. ^ finder In the end, I guess it's better to handle this in the Morphic layer, including having a button rather than a menu item to perform such a task. -- Simon From alexandre at bergel.eu Tue Jan 26 03:43:55 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Mon, 25 Jan 2010 23:43:55 -0300 Subject: [Moose-dev] Re: retrieve 'Memory class' in CAnalyzer In-Reply-To: References: Message-ID: I checked what you did. #testFunctionStorageClass looks really good! Alexandre On 25 Jan 2010, at 13:05, Cyrille Delaunay wrote: > This is done. Note that the common name is 'StorageClass' and not > 'MemoryClass' like I said. > For the moment, if a specific storageClass is specified before a > function (#static or #extern ) or a variable (#static #extern > #register or #auto), it will retrieve and store it. It will help me > to do what I want now. > But I should complete it: > -> if no class is specified, store the default one. Documentation on > the web is saying a lot of different things, but I think for both > (functions and variables), the default storageClass is #global > -> what about other kind of entities. What is involved if I have " > typedef static ..... ". > > I have written some tests. > > 2010/1/25 Alexandre Bergel > Yeah, this is what I meant. > > Alexandre > > > On 25 Jan 2010, at 10:41, Simon Denier wrote: > > > On 25 janv. 2010, at 14:11, Cyrille Delaunay wrote: > > Memory Class apply on Function but also on variables. The common > class for both type is FAMIXNamedEntity. Is it a good idea to define > an instance variable 'memoryClass' in this class ? > > > Use the extension mechanism of MooseEntity for state. > > See MooseEntity>>privateState and EntityState class > > > > 2010/1/25 Cyrille Delaunay > Ok, let's see :) > > 2010/1/25 Alexandre Bergel > > Yes Cyrille, it would be great. > Do you want to give a try? Let us know when done. I will review the > code. > Do not forget unit tests :-) > > Cheers, > Alexandre > > > On 25 Jan 2010, at 06:19, Cyrille Delaunay wrote: > > Hello, > > A thing it would be cool to retrieve from C code for a function, is > the thing called 'Memory class'. It is the word prefixing a function > declaration: > - global > - local > - static > - extern > - register > > I have looked at a xml file generated with srcml and a function is > declared like that: > static void type> ... > > So it seems to be quite simple to retrieve, what do you think ? > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Tue Jan 26 09:12:33 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 09:12:33 +0100 Subject: [Moose-dev] Re: ConfigurationOfGlamour: Glamour and Mondrian decoupling In-Reply-To: References: Message-ID: <91F700A0-5427-4527-AFE8-E9F150F7CFB4@gmail.com> Hi Fernando, That is not a bad idea, but it will probably take a while until I do it because it also implies repackaging :). Cheers, Doru On 25 Jan 2010, at 13:36, Fernando olivero wrote: > Tudor i think ConfigurationOfGlamour should provide groups for > decoupling Glamour installation and Mondrian installation. > > Not everybody using scriptable browsers want to use Mondrian panes. > > In summary, In the default group leave out Mondrian packages > dependencies and provide a metacello group for loading Glamour > +Mondrian explicitly. > > Pros: Faster installation time and decoupling Glamour from Mondrian. > > Cons: people not familiar with Metacello could get puzzled, but for > this you could provide convenience method in ConfigurationOfGlamour > class ( like we did in ConfigurationOfAlien). > > > What do you think? > > Fernando > > > > pd: In the method you provide some groups already. > > baseline20beta3: spec > ... > spec group: 'Tests' with: #( > 'Glamour-Tests' > 'Glamour-Examples' > 'Glamour-Test-Morphic'). > .... > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From tudor.girba at gmail.com Tue Jan 26 09:42:34 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 09:42:34 +0100 Subject: [Moose-dev] Re: Glamour: Making the table widget more customizable In-Reply-To: <2E0A1755-2382-411E-A398-CBE40AF61EE4@inria.fr> References: <2E0A1755-2382-411E-A398-CBE40AF61EE4@inria.fr> Message-ID: Hi Simon, Indeed, in the case of a table maybe we should also update the panes upon update. Anyway, this item is since too long an open issue and it makes metrics under used in the Moose Panel. Cheers, Doru On 25 Jan 2010, at 23:44, Simon Denier wrote: > I was thinking about how to make the table widget more customizable, > for example being able to dynamically add a column to a table. > > It just occurred to me that maybe it was even possible to do it > without getting into the Morphic code, just using Glamour. > > So be it. It works.... sort of.... It does not refresh the table > layout but the finder shows it is there. > > > | finder | > finder := GLMFinder new. > finder table > title: 'Number'; > display: [ :x | 1 to: x ]; > act: [:p| p column: 'Double' evaluated: [ :each | (each * 2) > asString ]. p update ] > entitled: 'add column'; > actions: [ :list | self actionsFor: list ]; > column: 'Even' evaluated: [ :each | each even asString ]; > column: 'Odd' evaluated: [ :each | each odd asString ]. > ^ finder > > > In the end, I guess it's better to handle this in the Morphic layer, > including having a button rather than a menu item to perform such a > task. > > > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "When people care, great things can happen." From tudor.girba at gmail.com Tue Jan 26 11:09:22 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 11:09:22 +0100 Subject: [Moose-dev] dirty morphic Message-ID: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> Hi Alex, Does Mondrian still need the Morphic changeset installed at loading time? Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling." From perin at iam.unibe.ch Tue Jan 26 12:09:41 2010 From: perin at iam.unibe.ch (Fabrizio Perin) Date: Tue, 26 Jan 2010 12:09:41 +0100 Subject: [Moose-dev] issue deleting a moose model Message-ID: Hi, yesterday I tried to delete a moose model from my image using the function Utilities>>Delete on the moose panel. The model disappear from the list but saving the image it has the same size. Executing "MooseModel allInstances" I saw that the model was still there. I tried to close all windows and then i execute "Smalltalk garbageCollect" and again the saved image has the same size because the model has not been removed. I'm working on the pharo dev image 10508, Moose-Core 215 but i detect the same error in an older image: pharo dev image 10502, Moose-Core 208. Cheers, Fabrizio From alexandre at bergel.eu Tue Jan 26 12:20:01 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 08:20:01 -0300 Subject: [Moose-dev] Re: issue deleting a moose model In-Reply-To: References: Message-ID: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> You can maybe check who is pointing to the model. There is a menu in the inspector. Alexandre On 26 Jan 2010, at 08:09, Fabrizio Perin wrote: > Hi, > yesterday I tried to delete a moose model from my image using the > function Utilities>>Delete on the moose panel. The model disappear > from the list but saving the image it has the same size. Executing > "MooseModel allInstances" I saw that the model was still there. I > tried to close all windows and then i execute "Smalltalk > garbageCollect" and again the saved image has the same size because > the model has not been removed. > > I'm working on the pharo dev image 10508, Moose-Core 215 but i > detect the same error in an older image: pharo dev image 10502, > Moose-Core 208. > > Cheers, > > Fabrizio > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Tue Jan 26 12:21:16 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 08:21:16 -0300 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> Message-ID: <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> Not anymore. I removed this from Mondrian few weeks ago. Alexandre On 26 Jan 2010, at 07:09, Tudor Girba wrote: > Hi Alex, > > Does Mondrian still need the Morphic changeset installed at loading > time? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Tue Jan 26 12:33:53 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 12:33:53 +0100 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> Message-ID: That is strange, because Morphic still appears dirty. Cheers, Doru On 26 Jan 2010, at 12:21, Alexandre Bergel wrote: > Not anymore. I removed this from Mondrian few weeks ago. > > Alexandre > > > On 26 Jan 2010, at 07:09, Tudor Girba wrote: > >> Hi Alex, >> >> Does Mondrian still need the Morphic changeset installed at loading >> time? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." From tudor.girba at gmail.com Tue Jan 26 12:46:54 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 12:46:54 +0100 Subject: [Moose-dev] Re: System complexity: Useful metrics? In-Reply-To: <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> References: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> Message-ID: <246E6883-0011-41B6-8312-F794394EB2BC@gmail.com> Exactly. Doru On 25 Jan 2010, at 18:44, Alexandre Bergel wrote: > I use the have the traditional ones: > width = #numberOfAttributes > height = #numberOfMethods > color = #numberOfLinesOfCode > > Regarding my goals, it really depends on the situation. > > Alexandre > > > On 25 Jan 2010, at 14:03, Johan Fabry wrote: > >> Hi all, >> >> a quick poll: which selection of metrics do you find the most >> useful when using a system complexity type visualisation, and what >> are your goals when using the visualisation? >> >> AspectMaps has this view as a part, but I am reluctant to include >> all the options that are in the customisable system complexity >> view, because this is a loooooooooot. A subset would be less >> intimidating to the user ... >> >> -- >> Johan Fabry >> jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut." From alexandre at bergel.eu Tue Jan 26 13:39:22 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 09:39:22 -0300 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> Message-ID: <35B908CF-559D-4606-8135-913948AF1458@bergel.eu> I am investigating Alexandre On 26 Jan 2010, at 08:33, Tudor Girba wrote: > That is strange, because Morphic still appears dirty. > > Cheers, > Doru > > On 26 Jan 2010, at 12:21, Alexandre Bergel wrote: > >> Not anymore. I removed this from Mondrian few weeks ago. >> >> Alexandre >> >> >> On 26 Jan 2010, at 07:09, Tudor Girba wrote: >> >>> Hi Alex, >>> >>> Does Mondrian still need the Morphic changeset installed at >>> loading time? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Tue Jan 26 14:14:13 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 14:14:13 +0100 Subject: [Moose-dev] Re: ConfigurationOfGlamour: Glamour and Mondrian decoupling In-Reply-To: <91F700A0-5427-4527-AFE8-E9F150F7CFB4@gmail.com> References: <91F700A0-5427-4527-AFE8-E9F150F7CFB4@gmail.com> Message-ID: Hi, I created an issue: http://code.google.com/p/moose-technology/issues/detail?id=310 Cheers, Doru On 26 Jan 2010, at 09:12, Tudor Girba wrote: > Hi Fernando, > > That is not a bad idea, but it will probably take a while until I do > it because it also implies repackaging :). > > Cheers, > Doru > > > On 25 Jan 2010, at 13:36, Fernando olivero wrote: > >> Tudor i think ConfigurationOfGlamour should provide groups for >> decoupling Glamour installation and Mondrian installation. >> >> Not everybody using scriptable browsers want to use Mondrian panes. >> >> In summary, In the default group leave out Mondrian packages >> dependencies and provide a metacello group for loading Glamour >> +Mondrian explicitly. >> >> Pros: Faster installation time and decoupling Glamour from >> Mondrian. >> >> Cons: people not familiar with Metacello could get puzzled, but for >> this you could provide convenience method in >> ConfigurationOfGlamour class ( like we did in ConfigurationOfAlien). >> >> >> What do you think? >> >> Fernando >> >> >> >> pd: In the method you provide some groups already. >> >> baseline20beta3: spec >> ... >> spec group: 'Tests' with: #( >> 'Glamour-Tests' >> 'Glamour-Examples' >> 'Glamour-Test-Morphic'). >> .... >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > -- www.tudorgirba.com "Not knowing how to do something is not an argument for how it cannot be done." From Simon.Denier at inria.fr Tue Jan 26 14:31:53 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 26 Jan 2010 14:31:53 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> Message-ID: <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> That's cool Jannik is checking the changes because DSM does not work completely. I also noticed a strange thing with colors. Open a cycletable like MOCycleTable new cycles: (MOCycleTableTest new setUp); render Notice how the fill color is desaturated (alpha: 0.5) in the two cells. Now if you fly over the cells with the mouse, the color is fully saturated once redrawn. Any idea where this comes from? -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2010-01-26 at 14.30.31.png Type: image/png Size: 20498 bytes Desc: not available URL: -------------- next part -------------- On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: > Dear List, > > You will find below the health report of today. I removed two important bottlenecks: node translations and computing absolute bounds. Layouting nodes is more then 100 times faster! > You can now do a "view nodes: (1 to: 20000)" in an easel without having the time to take a coffee! > > Here is the comment of Mondrian-Alexandre_Bergel.352 > -=-=-=-=-=-=-=-=-=-=-=-= > Major speed improvement: > - MOGraphElement>>absoluteBounds uses now a cache. This helped speeding up Mondrian by 35% > - Make MORectangleShape>>display:on: use absoluteBounds instead of absoluteBoundsFor:, which speeded the UI up of 14% > - optimization when translating nodes (MOGraphElement>>translatedBy:), we gained a significant speedup when layouting nodes > -=-=-=-=-=-=-=-=-=-=-=-= > > Report produced on 2010-01-23T18:17:13+00:00 > Benchmark ManyNode (simple rendering of nodes) : > 100 nodes => 3 ms > 200 nodes => 5 ms > 300 nodes => 6 ms > 400 nodes => 7 ms > 500 nodes => 9 ms > 600 nodes => 10 ms > 700 nodes => 12 ms > 800 nodes => 14 ms > 900 nodes => 15 ms > 1000 nodes => 17 ms > 1600 nodes => 28 ms > Benchmark ManyEdges (simple rendering of edges) : > 10 edges => 2 ms > 20 edges => 6 ms > 30 edges => 12 ms > 40 edges => 28 ms > 50 edges => 48 ms > 60 edges => 74 ms > 70 edges => 115 ms > 80 edges => 169 ms > 90 edges => 254 ms > 100 edges => 335 ms > 200 edges => 4356 ms > 300 edges => 35919 ms > 55.54 % of methods are covered > Progress from last time: -0.1 % > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From alexandre at bergel.eu Tue Jan 26 15:01:54 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 11:01:54 -0300 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> Message-ID: <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> Color problems are probably not related to my fixes. What is going wrong with DSM beside the colors? Best would be to write some tests that fails. This will give me a starting point where to start. Cheers, Alexandre On 26 Jan 2010, at 10:31, Simon Denier wrote: > > That's cool > > Jannik is checking the changes because DSM does not work completely. > > I also noticed a strange thing with colors. > > Open a cycletable like > MOCycleTable new cycles: (MOCycleTableTest new setUp); render > > Notice how the fill color is desaturated (alpha: 0.5) in the two > cells. Now if you fly over the cells with the mouse, the color is > fully saturated once redrawn. Any idea where this comes from? > > > > > > On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: > >> Dear List, >> >> You will find below the health report of today. I removed two >> important bottlenecks: node translations and computing absolute >> bounds. Layouting nodes is more then 100 times faster! >> You can now do a "view nodes: (1 to: 20000)" in an easel without >> having the time to take a coffee! >> >> Here is the comment of Mondrian-Alexandre_Bergel.352 >> -=-=-=-=-=-=-=-=-=-=-=-= >> Major speed improvement: >> - MOGraphElement>>absoluteBounds uses now a cache. This helped >> speeding up Mondrian by 35% >> - Make MORectangleShape>>display:on: use absoluteBounds instead of >> absoluteBoundsFor:, which speeded the UI up of 14% >> - optimization when translating nodes >> (MOGraphElement>>translatedBy:), we gained a significant speedup >> when layouting nodes >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> Report produced on 2010-01-23T18:17:13+00:00 >> Benchmark ManyNode (simple rendering of nodes) : >> 100 nodes => 3 ms >> 200 nodes => 5 ms >> 300 nodes => 6 ms >> 400 nodes => 7 ms >> 500 nodes => 9 ms >> 600 nodes => 10 ms >> 700 nodes => 12 ms >> 800 nodes => 14 ms >> 900 nodes => 15 ms >> 1000 nodes => 17 ms >> 1600 nodes => 28 ms >> Benchmark ManyEdges (simple rendering of edges) : >> 10 edges => 2 ms >> 20 edges => 6 ms >> 30 edges => 12 ms >> 40 edges => 28 ms >> 50 edges => 48 ms >> 60 edges => 74 ms >> 70 edges => 115 ms >> 80 edges => 169 ms >> 90 edges => 254 ms >> 100 edges => 335 ms >> 200 edges => 4356 ms >> 300 edges => 35919 ms >> 55.54 % of methods are covered >> Progress from last time: -0.1 % >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jannik.laval at gmail.com Tue Jan 26 15:22:43 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Tue, 26 Jan 2010 15:22:43 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> Message-ID: <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> Hi Alex, In DSM, I have a problem with edges: they do not appear since version 350 of Mondrian. I wonder if they are not below shapes. Cheers, Jannik On Jan 26, 2010, at 15:01 , Alexandre Bergel wrote: > Color problems are probably not related to my fixes. What is going wrong with DSM beside the colors? > Best would be to write some tests that fails. This will give me a starting point where to start. > > Cheers, > Alexandre > > > On 26 Jan 2010, at 10:31, Simon Denier wrote: > >> >> That's cool >> >> Jannik is checking the changes because DSM does not work completely. >> >> I also noticed a strange thing with colors. >> >> Open a cycletable like >> MOCycleTable new cycles: (MOCycleTableTest new setUp); render >> >> Notice how the fill color is desaturated (alpha: 0.5) in the two cells. Now if you fly over the cells with the mouse, the color is fully saturated once redrawn. Any idea where this comes from? >> >> >> >> >> >> On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: >> >>> Dear List, >>> >>> You will find below the health report of today. I removed two important bottlenecks: node translations and computing absolute bounds. Layouting nodes is more then 100 times faster! >>> You can now do a "view nodes: (1 to: 20000)" in an easel without having the time to take a coffee! >>> >>> Here is the comment of Mondrian-Alexandre_Bergel.352 >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> Major speed improvement: >>> - MOGraphElement>>absoluteBounds uses now a cache. This helped speeding up Mondrian by 35% >>> - Make MORectangleShape>>display:on: use absoluteBounds instead of absoluteBoundsFor:, which speeded the UI up of 14% >>> - optimization when translating nodes (MOGraphElement>>translatedBy:), we gained a significant speedup when layouting nodes >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> Report produced on 2010-01-23T18:17:13+00:00 >>> Benchmark ManyNode (simple rendering of nodes) : >>> 100 nodes => 3 ms >>> 200 nodes => 5 ms >>> 300 nodes => 6 ms >>> 400 nodes => 7 ms >>> 500 nodes => 9 ms >>> 600 nodes => 10 ms >>> 700 nodes => 12 ms >>> 800 nodes => 14 ms >>> 900 nodes => 15 ms >>> 1000 nodes => 17 ms >>> 1600 nodes => 28 ms >>> Benchmark ManyEdges (simple rendering of edges) : >>> 10 edges => 2 ms >>> 20 edges => 6 ms >>> 30 edges => 12 ms >>> 40 edges => 28 ms >>> 50 edges => 48 ms >>> 60 edges => 74 ms >>> 70 edges => 115 ms >>> 80 edges => 169 ms >>> 90 edges => 254 ms >>> 100 edges => 335 ms >>> 200 edges => 4356 ms >>> 300 edges => 35919 ms >>> 55.54 % of methods are covered >>> Progress from last time: -0.1 % >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Tue Jan 26 15:28:03 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 15:28:03 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> Message-ID: <2D53F3E0-671D-4D99-8F74-89B91370969F@gmail.com> It could very well happen. See issue: http://code.google.com/p/moose-technology/issues/detail?id=112 It would be helpful if you could check by inspecting the graph. Cheers, Doru On 26 Jan 2010, at 15:22, Laval Jannik wrote: > Hi Alex, > > In DSM, I have a problem with edges: they do not appear since > version 350 of Mondrian. > I wonder if they are not below shapes. > > Cheers, > Jannik > > > On Jan 26, 2010, at 15:01 , Alexandre Bergel wrote: > >> Color problems are probably not related to my fixes. What is going >> wrong with DSM beside the colors? >> Best would be to write some tests that fails. This will give me a >> starting point where to start. >> >> Cheers, >> Alexandre >> >> >> On 26 Jan 2010, at 10:31, Simon Denier wrote: >> >>> >>> That's cool >>> >>> Jannik is checking the changes because DSM does not work completely. >>> >>> I also noticed a strange thing with colors. >>> >>> Open a cycletable like >>> MOCycleTable new cycles: (MOCycleTableTest new setUp); render >>> >>> Notice how the fill color is desaturated (alpha: 0.5) in the two >>> cells. Now if you fly over the cells with the mouse, the color is >>> fully saturated once redrawn. Any idea where this comes from? >>> >>> >>> >>> >>> >>> On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> You will find below the health report of today. I removed two >>>> important bottlenecks: node translations and computing absolute >>>> bounds. Layouting nodes is more then 100 times faster! >>>> You can now do a "view nodes: (1 to: 20000)" in an easel without >>>> having the time to take a coffee! >>>> >>>> Here is the comment of Mondrian-Alexandre_Bergel.352 >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> Major speed improvement: >>>> - MOGraphElement>>absoluteBounds uses now a cache. This helped >>>> speeding up Mondrian by 35% >>>> - Make MORectangleShape>>display:on: use absoluteBounds instead >>>> of absoluteBoundsFor:, which speeded the UI up of 14% >>>> - optimization when translating nodes >>>> (MOGraphElement>>translatedBy:), we gained a significant speedup >>>> when layouting nodes >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Report produced on 2010-01-23T18:17:13+00:00 >>>> Benchmark ManyNode (simple rendering of nodes) : >>>> 100 nodes => 3 ms >>>> 200 nodes => 5 ms >>>> 300 nodes => 6 ms >>>> 400 nodes => 7 ms >>>> 500 nodes => 9 ms >>>> 600 nodes => 10 ms >>>> 700 nodes => 12 ms >>>> 800 nodes => 14 ms >>>> 900 nodes => 15 ms >>>> 1000 nodes => 17 ms >>>> 1600 nodes => 28 ms >>>> Benchmark ManyEdges (simple rendering of edges) : >>>> 10 edges => 2 ms >>>> 20 edges => 6 ms >>>> 30 edges => 12 ms >>>> 40 edges => 28 ms >>>> 50 edges => 48 ms >>>> 60 edges => 74 ms >>>> 70 edges => 115 ms >>>> 80 edges => 169 ms >>>> 90 edges => 254 ms >>>> 100 edges => 335 ms >>>> 200 edges => 4356 ms >>>> 300 edges => 35919 ms >>>> 55.54 % of methods are covered >>>> Progress from last time: -0.1 % >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> Simon >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow." From jannik.laval at gmail.com Tue Jan 26 15:54:25 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Tue, 26 Jan 2010 15:54:25 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <2D53F3E0-671D-4D99-8F74-89B91370969F@gmail.com> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> <2D53F3E0-671D-4D99-8F74-89B91370969F@gmail.com> Message-ID: <6B5A7BED-4773-4D38-A0AF-71D1B36E8829@gmail.com> Hi, yes, the graph has edges when I inspect it. I see the issue is opened since august 2009... And for DSM the bug appears in the version 350. Alex, do you have a solution ? Cheers, Jannik On Jan 26, 2010, at 15:28 , Tudor Girba wrote: > It could very well happen. See issue: > http://code.google.com/p/moose-technology/issues/detail?id=112 > > It would be helpful if you could check by inspecting the graph. > > Cheers, > Doru > > On 26 Jan 2010, at 15:22, Laval Jannik wrote: > >> Hi Alex, >> >> In DSM, I have a problem with edges: they do not appear since version 350 of Mondrian. >> I wonder if they are not below shapes. >> >> Cheers, >> Jannik >> >> >> On Jan 26, 2010, at 15:01 , Alexandre Bergel wrote: >> >>> Color problems are probably not related to my fixes. What is going wrong with DSM beside the colors? >>> Best would be to write some tests that fails. This will give me a starting point where to start. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 26 Jan 2010, at 10:31, Simon Denier wrote: >>> >>>> >>>> That's cool >>>> >>>> Jannik is checking the changes because DSM does not work completely. >>>> >>>> I also noticed a strange thing with colors. >>>> >>>> Open a cycletable like >>>> MOCycleTable new cycles: (MOCycleTableTest new setUp); render >>>> >>>> Notice how the fill color is desaturated (alpha: 0.5) in the two cells. Now if you fly over the cells with the mouse, the color is fully saturated once redrawn. Any idea where this comes from? >>>> >>>> >>>> >>>> >>>> >>>> On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: >>>> >>>>> Dear List, >>>>> >>>>> You will find below the health report of today. I removed two important bottlenecks: node translations and computing absolute bounds. Layouting nodes is more then 100 times faster! >>>>> You can now do a "view nodes: (1 to: 20000)" in an easel without having the time to take a coffee! >>>>> >>>>> Here is the comment of Mondrian-Alexandre_Bergel.352 >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> Major speed improvement: >>>>> - MOGraphElement>>absoluteBounds uses now a cache. This helped speeding up Mondrian by 35% >>>>> - Make MORectangleShape>>display:on: use absoluteBounds instead of absoluteBoundsFor:, which speeded the UI up of 14% >>>>> - optimization when translating nodes (MOGraphElement>>translatedBy:), we gained a significant speedup when layouting nodes >>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>> >>>>> Report produced on 2010-01-23T18:17:13+00:00 >>>>> Benchmark ManyNode (simple rendering of nodes) : >>>>> 100 nodes => 3 ms >>>>> 200 nodes => 5 ms >>>>> 300 nodes => 6 ms >>>>> 400 nodes => 7 ms >>>>> 500 nodes => 9 ms >>>>> 600 nodes => 10 ms >>>>> 700 nodes => 12 ms >>>>> 800 nodes => 14 ms >>>>> 900 nodes => 15 ms >>>>> 1000 nodes => 17 ms >>>>> 1600 nodes => 28 ms >>>>> Benchmark ManyEdges (simple rendering of edges) : >>>>> 10 edges => 2 ms >>>>> 20 edges => 6 ms >>>>> 30 edges => 12 ms >>>>> 40 edges => 28 ms >>>>> 50 edges => 48 ms >>>>> 60 edges => 74 ms >>>>> 70 edges => 115 ms >>>>> 80 edges => 169 ms >>>>> 90 edges => 254 ms >>>>> 100 edges => 335 ms >>>>> 200 edges => 4356 ms >>>>> 300 edges => 35919 ms >>>>> 55.54 % of methods are covered >>>>> Progress from last time: -0.1 % >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at 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 at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Tue Jan 26 16:08:06 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 12:08:06 -0300 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: <6B5A7BED-4773-4D38-A0AF-71D1B36E8829@gmail.com> References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> <2D53F3E0-671D-4D99-8F74-89B91370969F@gmail.com> <6B5A7BED-4773-4D38-A0AF-71D1B36E8829@gmail.com> Message-ID: > Alex, do you have a solution ? I am not sure to fully understand the issue actually. Should the two following scripts have the same rendering: -=-=-=-=-=-=-=-=-=-=-=-= view node: #a forIt: [ view node: 1 ]. view node: #b forIt: [ view node: 2. view edges: {1 -> 2} from: #key to: #value ]. -=-=-=-=-=-=-=-=-=-=-=-= view node: #a forIt: [ view node: 1 ]. view node: #b forIt: [ view node: 2 ]. view edges: {1 -> 2} from: #key to: #value -=-=-=-=-=-=-=-=-=-=-=-= Alexandre > > On Jan 26, 2010, at 15:28 , Tudor Girba wrote: > >> It could very well happen. See issue: >> http://code.google.com/p/moose-technology/issues/detail?id=112 >> >> It would be helpful if you could check by inspecting the graph. >> >> Cheers, >> Doru >> >> On 26 Jan 2010, at 15:22, Laval Jannik wrote: >> >>> Hi Alex, >>> >>> In DSM, I have a problem with edges: they do not appear since >>> version 350 of Mondrian. >>> I wonder if they are not below shapes. >>> >>> Cheers, >>> Jannik >>> >>> >>> On Jan 26, 2010, at 15:01 , Alexandre Bergel wrote: >>> >>>> Color problems are probably not related to my fixes. What is >>>> going wrong with DSM beside the colors? >>>> Best would be to write some tests that fails. This will give me a >>>> starting point where to start. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 26 Jan 2010, at 10:31, Simon Denier wrote: >>>> >>>>> >>>>> That's cool >>>>> >>>>> Jannik is checking the changes because DSM does not work >>>>> completely. >>>>> >>>>> I also noticed a strange thing with colors. >>>>> >>>>> Open a cycletable like >>>>> MOCycleTable new cycles: (MOCycleTableTest new setUp); render >>>>> >>>>> Notice how the fill color is desaturated (alpha: 0.5) in the two >>>>> cells. Now if you fly over the cells with the mouse, the color >>>>> is fully saturated once redrawn. Any idea where this comes from? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: >>>>> >>>>>> Dear List, >>>>>> >>>>>> You will find below the health report of today. I removed two >>>>>> important bottlenecks: node translations and computing absolute >>>>>> bounds. Layouting nodes is more then 100 times faster! >>>>>> You can now do a "view nodes: (1 to: 20000)" in an easel >>>>>> without having the time to take a coffee! >>>>>> >>>>>> Here is the comment of Mondrian-Alexandre_Bergel.352 >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> Major speed improvement: >>>>>> - MOGraphElement>>absoluteBounds uses now a cache. This helped >>>>>> speeding up Mondrian by 35% >>>>>> - Make MORectangleShape>>display:on: use absoluteBounds instead >>>>>> of absoluteBoundsFor:, which speeded the UI up of 14% >>>>>> - optimization when translating nodes >>>>>> (MOGraphElement>>translatedBy:), we gained a significant >>>>>> speedup when layouting nodes >>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>> >>>>>> Report produced on 2010-01-23T18:17:13+00:00 >>>>>> Benchmark ManyNode (simple rendering of nodes) : >>>>>> 100 nodes => 3 ms >>>>>> 200 nodes => 5 ms >>>>>> 300 nodes => 6 ms >>>>>> 400 nodes => 7 ms >>>>>> 500 nodes => 9 ms >>>>>> 600 nodes => 10 ms >>>>>> 700 nodes => 12 ms >>>>>> 800 nodes => 14 ms >>>>>> 900 nodes => 15 ms >>>>>> 1000 nodes => 17 ms >>>>>> 1600 nodes => 28 ms >>>>>> Benchmark ManyEdges (simple rendering of edges) : >>>>>> 10 edges => 2 ms >>>>>> 20 edges => 6 ms >>>>>> 30 edges => 12 ms >>>>>> 40 edges => 28 ms >>>>>> 50 edges => 48 ms >>>>>> 60 edges => 74 ms >>>>>> 70 edges => 115 ms >>>>>> 80 edges => 169 ms >>>>>> 90 edges => 254 ms >>>>>> 100 edges => 335 ms >>>>>> 200 edges => 4356 ms >>>>>> 300 edges => 35919 ms >>>>>> 55.54 % of methods are covered >>>>>> Progress from last time: -0.1 % >>>>>> >>>>>> Cheers, >>>>>> Alexandre >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> Simon >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at 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 at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jfabry at dcc.uchile.cl Tue Jan 26 16:14:21 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 26 Jan 2010 12:14:21 -0300 Subject: [Moose-dev] Re: System complexity: Useful metrics? In-Reply-To: <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> References: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> Message-ID: <2CA37035-70AD-4FF4-93D7-95E762FA6BF9@dcc.uchile.cl> On 25 Jan 2010, at 14:44, Alexandre Bergel wrote: > I use the have the traditional ones: > width = #numberOfAttributes > height = #numberOfMethods > color = #numberOfLinesOfCode OK, thanks! > Regarding my goals, it really depends on the situation. Yes, well that's kind of obvious, no? ;-) That's why I asked in the plural. Anyways, I think that in AspectMaps I will just keep the above metrics plus weightedMethodCount because it sounds cool :-P, and the amount of join point shadows. FYI: a pic of the current state of AspectMaps. I dont have time this week to make new screenshots and movies, and from next week I am away from the computer until the end of feb, so I will do those things when I am back ... -------------- next part -------------- A non-text attachment was scrubbed... Name: AM.tiff Type: image/tiff Size: 126322 bytes Desc: not available URL: -------------- next part -------------- -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From alexandre at bergel.eu Tue Jan 26 16:30:33 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 12:30:33 -0300 Subject: [Moose-dev] Re: System complexity: Useful metrics? In-Reply-To: <2CA37035-70AD-4FF4-93D7-95E762FA6BF9@dcc.uchile.cl> References: <85235E49-1E61-464E-887A-F793CE917091@dcc.uchile.cl> <8326B115-6F6C-4207-8848-1116F19043CC@bergel.eu> <2CA37035-70AD-4FF4-93D7-95E762FA6BF9@dcc.uchile.cl> Message-ID: <38E6258F-E932-4218-AAB0-96403D50AC76@bergel.eu> It looks really really cool! I am glad to see what people can do with Moose/Glamour/Mondrian. This is an excellent illustration! Alexandre On 26 Jan 2010, at 12:14, Johan Fabry wrote: > > On 25 Jan 2010, at 14:44, Alexandre Bergel wrote: > >> I use the have the traditional ones: >> width = #numberOfAttributes >> height = #numberOfMethods >> color = #numberOfLinesOfCode > > OK, thanks! > >> Regarding my goals, it really depends on the situation. > > > Yes, well that's kind of obvious, no? ;-) That's why I asked in the > plural. > > Anyways, I think that in AspectMaps I will just keep the above > metrics plus weightedMethodCount because it sounds cool :-P, and the > amount of join point shadows. > > FYI: a pic of the current state of AspectMaps. I dont have time this > week to make new screenshots and movies, and from next week I am > away from the computer until the end of feb, so I will do those > things when I am back ... > > > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Tue Jan 26 16:34:49 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 16:34:49 +0100 Subject: [Moose-dev] Re: Mondrian Health Report : good news, we gained a significant speedup In-Reply-To: References: <71B1B49A-6A47-4C67-9D38-A0CFDEF183A6@bergel.eu> <307C2A64-AA42-4009-8785-C0DC60702B4F@inria.fr> <381162C2-66F3-4E9D-BEE1-7E269EAF09EE@bergel.eu> <9896475A-8926-40C4-A57C-40D1F579E459@gmail.com> <2D53F3E0-671D-4D99-8F74-89B91370969F@gmail.com> <6B5A7BED-4773-4D38-A0AF-71D1B36E8829@gmail.com> Message-ID: Hi Alex, Yes, they should. This was indeed a feature that is implemented in the VW version and it implies a smart ordering of edges. The forces are: - an edge has to be drawn behind the origin and destination nodes - the edge must be drawn above both of the origin container and of the destination container IO digged a bit in the VW implementation, and this I found the zOrder function: Edge>>zOrder ^(self fromFigure zOrder max: self toFigure zOrder) - 1 Node>>zOrder ^self parent zOrder + 2 This function was used to order the elements to draw: AbstractFigure>>elements elements isNil ifTrue: [ | sorted | sorted := SortedCollection sortBlock: [:a :b | a zOrder < b zOrder]. self deepNodeFigures do: [:e | sorted add: e]. self deepEdgeFigures do: [:e | sorted add: e]. elements := sorted asOrderedCollection. ]. ^elements Cheers, Doru On 26 Jan 2010, at 16:08, Alexandre Bergel wrote: >> Alex, do you have a solution ? > > I am not sure to fully understand the issue actually. > > Should the two following scripts have the same rendering: > -=-=-=-=-=-=-=-=-=-=-=-= > view node: #a forIt: [ view node: 1 ]. > view node: #b forIt: [ > view node: 2. > view edges: {1 -> 2} from: #key to: #value ]. > -=-=-=-=-=-=-=-=-=-=-=-= > view node: #a forIt: [ view node: 1 ]. > view node: #b forIt: [ view node: 2 ]. > view edges: {1 -> 2} from: #key to: #value > -=-=-=-=-=-=-=-=-=-=-=-= > > Alexandre > > >> >> On Jan 26, 2010, at 15:28 , Tudor Girba wrote: >> >>> It could very well happen. See issue: >>> http://code.google.com/p/moose-technology/issues/detail?id=112 >>> >>> It would be helpful if you could check by inspecting the graph. >>> >>> Cheers, >>> Doru >>> >>> On 26 Jan 2010, at 15:22, Laval Jannik wrote: >>> >>>> Hi Alex, >>>> >>>> In DSM, I have a problem with edges: they do not appear since >>>> version 350 of Mondrian. >>>> I wonder if they are not below shapes. >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>> On Jan 26, 2010, at 15:01 , Alexandre Bergel wrote: >>>> >>>>> Color problems are probably not related to my fixes. What is >>>>> going wrong with DSM beside the colors? >>>>> Best would be to write some tests that fails. This will give me >>>>> a starting point where to start. >>>>> >>>>> Cheers, >>>>> Alexandre >>>>> >>>>> >>>>> On 26 Jan 2010, at 10:31, Simon Denier wrote: >>>>> >>>>>> >>>>>> That's cool >>>>>> >>>>>> Jannik is checking the changes because DSM does not work >>>>>> completely. >>>>>> >>>>>> I also noticed a strange thing with colors. >>>>>> >>>>>> Open a cycletable like >>>>>> MOCycleTable new cycles: (MOCycleTableTest new setUp); render >>>>>> >>>>>> Notice how the fill color is desaturated (alpha: 0.5) in the >>>>>> two cells. Now if you fly over the cells with the mouse, the >>>>>> color is fully saturated once redrawn. Any idea where this >>>>>> comes from? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 25 janv. 2010, at 20:27, Alexandre Bergel wrote: >>>>>> >>>>>>> Dear List, >>>>>>> >>>>>>> You will find below the health report of today. I removed two >>>>>>> important bottlenecks: node translations and computing >>>>>>> absolute bounds. Layouting nodes is more then 100 times faster! >>>>>>> You can now do a "view nodes: (1 to: 20000)" in an easel >>>>>>> without having the time to take a coffee! >>>>>>> >>>>>>> Here is the comment of Mondrian-Alexandre_Bergel.352 >>>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>>> Major speed improvement: >>>>>>> - MOGraphElement>>absoluteBounds uses now a cache. This >>>>>>> helped speeding up Mondrian by 35% >>>>>>> - Make MORectangleShape>>display:on: use absoluteBounds >>>>>>> instead of absoluteBoundsFor:, which speeded the UI up of 14% >>>>>>> - optimization when translating nodes >>>>>>> (MOGraphElement>>translatedBy:), we gained a significant >>>>>>> speedup when layouting nodes >>>>>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>>>>> >>>>>>> Report produced on 2010-01-23T18:17:13+00:00 >>>>>>> Benchmark ManyNode (simple rendering of nodes) : >>>>>>> 100 nodes => 3 ms >>>>>>> 200 nodes => 5 ms >>>>>>> 300 nodes => 6 ms >>>>>>> 400 nodes => 7 ms >>>>>>> 500 nodes => 9 ms >>>>>>> 600 nodes => 10 ms >>>>>>> 700 nodes => 12 ms >>>>>>> 800 nodes => 14 ms >>>>>>> 900 nodes => 15 ms >>>>>>> 1000 nodes => 17 ms >>>>>>> 1600 nodes => 28 ms >>>>>>> Benchmark ManyEdges (simple rendering of edges) : >>>>>>> 10 edges => 2 ms >>>>>>> 20 edges => 6 ms >>>>>>> 30 edges => 12 ms >>>>>>> 40 edges => 28 ms >>>>>>> 50 edges => 48 ms >>>>>>> 60 edges => 74 ms >>>>>>> 70 edges => 115 ms >>>>>>> 80 edges => 169 ms >>>>>>> 90 edges => 254 ms >>>>>>> 100 edges => 335 ms >>>>>>> 200 edges => 4356 ms >>>>>>> 300 edges => 35919 ms >>>>>>> 55.54 % of methods are covered >>>>>>> Progress from last time: -0.1 % >>>>>>> >>>>>>> Cheers, >>>>>>> Alexandre >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Moose-dev mailing list >>>>>>> Moose-dev at iam.unibe.ch >>>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>>> >>>>>> -- >>>>>> Simon >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Moose-dev mailing list >>>>>> Moose-dev at iam.unibe.ch >>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at 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 at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it." From tudor.girba at gmail.com Tue Jan 26 16:41:06 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 16:41:06 +0100 Subject: [Moose-dev] [ANN] hudson.moosetechnology.org Message-ID: <846B50C7-B2E8-4E83-AEC8-51274339924B@gmail.com> Hi, With the great help of Lukas, we installed a Hudson continuous integration server for Moose. You can find the reports at: http://hudson.moosetechnology.org At the moment, there is only one configuration that builds every night the latest development image by loading the default from the latest ConfigurationOfMoose, and by running all tests from this Configuration and from all directly included Configurations. We have 1316 tests from which 3 fail. The result is here: http://hudson.moosetechnology.org/job/moose-latest-dev/ A by-product of the build system is that you can always download the latest nightly build images. For example: http://hudson.moosetechnology.org/job/moose-latest-dev/26/artifact/ Cheers, Doru -- www.tudorgirba.com "Presenting is storytelling." From tudor.girba at gmail.com Tue Jan 26 16:59:18 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Tue, 26 Jan 2010 16:59:18 +0100 Subject: [Moose-dev] Re: issue deleting a moose model In-Reply-To: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> References: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> Message-ID: Hi, I think it has to do with Glamour. It looks like the Glamour browsers linger around in the image. I looked briefly for the possible problem, but I could not find the answer yet though :(. Cheers, Doru On 26 Jan 2010, at 12:20, Alexandre Bergel wrote: > You can maybe check who is pointing to the model. There is a menu in > the inspector. > > Alexandre > > > On 26 Jan 2010, at 08:09, Fabrizio Perin wrote: > >> Hi, >> yesterday I tried to delete a moose model from my image using the >> function Utilities>>Delete on the moose panel. The model disappear >> from the list but saving the image it has the same size. Executing >> "MooseModel allInstances" I saw that the model was still there. I >> tried to close all windows and then i execute "Smalltalk >> garbageCollect" and again the saved image has the same size because >> the model has not been removed. >> >> I'm working on the pharo dev image 10508, Moose-Core 215 but i >> detect the same error in an older image: pharo dev image 10502, >> Moose-Core 208. >> >> Cheers, >> >> Fabrizio >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." From cy.delaunay at gmail.com Tue Jan 26 17:01:50 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Tue, 26 Jan 2010 17:01:50 +0100 Subject: [Moose-dev] CAnalyzer - retrieving two time the same global variable. Message-ID: Hi, In a C file, when a global variable is first declared at the begining of the file and then redeclared to affect it a value, CAnalyzer create two differeent FAMIXGlobalVariables. For example, in this program: ' int a; ..... int a = 2; ' Two FAMIXGlobalVariable will be generated. I guess it should not be the case ? I wrote a test for that. Should I open an issue ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Denier at inria.fr Tue Jan 26 17:24:07 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 26 Jan 2010 17:24:07 +0100 Subject: [Moose-dev] Re: CAnalyzer - retrieving two time the same global variable. In-Reply-To: References: Message-ID: On 26 janv. 2010, at 17:01, Cyrille Delaunay wrote: > Hi, > > In a C file, when a global variable is first declared at the begining of the file and then redeclared to affect it a value, CAnalyzer create two differeent FAMIXGlobalVariables. > For example, in this program: > ' > int a; > > ..... > > int a = 2; > ' > Two FAMIXGlobalVariable will be generated. I guess it should not be the case ? > I wrote a test for that. Should I open an issue ? yes, open an issue > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From stephane.ducasse at inria.fr Tue Jan 26 17:25:23 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Tue, 26 Jan 2010 17:25:23 +0100 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: <35B908CF-559D-4606-8135-913948AF1458@bergel.eu> References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> <35B908CF-559D-4606-8135-913948AF1458@bergel.eu> Message-ID: <3531E825-400A-43BD-BC2F-F16212A49825@inria.fr> pay attention that the events were added to 1.1 and not 1.0 Stef On Jan 26, 2010, at 1:39 PM, Alexandre Bergel wrote: > I am investigating > > Alexandre > > > On 26 Jan 2010, at 08:33, Tudor Girba wrote: > >> That is strange, because Morphic still appears dirty. >> >> Cheers, >> Doru >> >> On 26 Jan 2010, at 12:21, Alexandre Bergel wrote: >> >>> Not anymore. I removed this from Mondrian few weeks ago. >>> >>> Alexandre >>> >>> >>> On 26 Jan 2010, at 07:09, Tudor Girba wrote: >>> >>>> Hi Alex, >>>> >>>> Does Mondrian still need the Morphic changeset installed at loading time? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Presenting is storytelling." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From jfabry at dcc.uchile.cl Tue Jan 26 18:00:28 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Tue, 26 Jan 2010 14:00:28 -0300 Subject: [Moose-dev] Re: [ANN] hudson.moosetechnology.org In-Reply-To: <846B50C7-B2E8-4E83-AEC8-51274339924B@gmail.com> References: <846B50C7-B2E8-4E83-AEC8-51274339924B@gmail.com> Message-ID: <6682F111-085F-4C0F-A468-2EB25FC1E007@dcc.uchile.cl> That is just excellent! Many thanks! That is going to save me lots of time in the future, which I appreciate a lot! On 26 Jan 2010, at 12:41, Tudor Girba wrote: > Hi, > > With the great help of Lukas, we installed a Hudson continuous > integration server for Moose. You can find the reports at: > http://hudson.moosetechnology.org > > At the moment, there is only one configuration that builds every > night the latest development image by loading the default from the > latest ConfigurationOfMoose, and by running all tests from this > Configuration and from all directly included Configurations. > > We have 1316 tests from which 3 fail. The result is here: > http://hudson.moosetechnology.org/job/moose-latest-dev/ > > A by-product of the build system is that you can always download the > latest nightly build images. For example: > http://hudson.moosetechnology.org/job/moose-latest-dev/26/artifact/ > > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From alexandre at bergel.eu Tue Jan 26 18:19:00 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 14:19:00 -0300 Subject: [Moose-dev] Re: [ANN] hudson.moosetechnology.org In-Reply-To: <6682F111-085F-4C0F-A468-2EB25FC1E007@dcc.uchile.cl> References: <846B50C7-B2E8-4E83-AEC8-51274339924B@gmail.com> <6682F111-085F-4C0F-A468-2EB25FC1E007@dcc.uchile.cl> Message-ID: <311176A4-5C83-48DA-BC2A-529C202C6EBB@bergel.eu> This is cool yes! Alexandre On 26 Jan 2010, at 14:00, Johan Fabry wrote: > > That is just excellent! Many thanks! That is going to save me lots > of time in the future, which I appreciate a lot! > > On 26 Jan 2010, at 12:41, Tudor Girba wrote: > >> Hi, >> >> With the great help of Lukas, we installed a Hudson continuous >> integration server for Moose. You can find the reports at: >> http://hudson.moosetechnology.org >> >> At the moment, there is only one configuration that builds every >> night the latest development image by loading the default from the >> latest ConfigurationOfMoose, and by running all tests from this >> Configuration and from all directly included Configurations. >> >> We have 1316 tests from which 3 fail. The result is here: >> http://hudson.moosetechnology.org/job/moose-latest-dev/ >> >> A by-product of the build system is that you can always download >> the latest nightly build images. For example: >> http://hudson.moosetechnology.org/job/moose-latest-dev/26/artifact/ >> >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Presenting is storytelling." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Johan Fabry > jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Tue Jan 26 18:21:04 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 14:21:04 -0300 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> Message-ID: <7027F3E7-3F08-48DA-A0F1-D67713E429F2@bergel.eu> Hi Doru, I think the reason is that you load Morphic extension in ConfigurationOfGlamour: spec for: #common do: [ spec blessing: #baseline. spec repository: 'http://www.squeaksource.com/Glamour'. spec package: 'Morphic-MorphTreeWidget' with: [ spec repository: 'http://www.squeaksource.com/Momo10' ]; This is what appear when I look at the differences of Morphic before and after loading Moose. Alexandre On 26 Jan 2010, at 08:33, Tudor Girba wrote: > That is strange, because Morphic still appears dirty. > > Cheers, > Doru > > On 26 Jan 2010, at 12:21, Alexandre Bergel wrote: > >> Not anymore. I removed this from Mondrian few weeks ago. >> >> Alexandre >> >> >> On 26 Jan 2010, at 07:09, Tudor Girba wrote: >> >>> Hi Alex, >>> >>> Does Mondrian still need the Morphic changeset installed at >>> loading time? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Presenting is storytelling." >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From abergel at dcc.uchile.cl Tue Jan 26 18:32:50 2010 From: abergel at dcc.uchile.cl (Alexandre Bergel) Date: Tue, 26 Jan 2010 14:32:50 -0300 Subject: [Moose-dev] FlowInLayout Message-ID: <403D3DDE-DBD7-4DEC-9DAC-47359033C885@dcc.uchile.cl> Hi! My last improvement brake the test testFlowInLayout. I will try to fix this asap... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From perin at iam.unibe.ch Tue Jan 26 18:51:36 2010 From: perin at iam.unibe.ch (Fabrizio Perin) Date: Tue, 26 Jan 2010 18:51:36 +0100 Subject: [Moose-dev] Re: issue deleting a moose model In-Reply-To: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> References: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> Message-ID: <645E98E6-7F00-4026-846E-5837CA680B1E@iam.unibe.ch> Hi, i tried to check the pointers to the model opening that menu. My machine start to work at 100% and after 3 hours i didn't have the list of pointers visualized yet. So i decide to kill the image. The system was surely into an infinite loop (or there were billions of links so i think that is useless know which they were). I will anyway try to let my machine work during the night just in the case that i'm wrong :) Meanwhile have you other suggestions? Thanks in advance. Cheers, Fabrizio On 26 Jan 2010, at 12:20, Alexandre Bergel wrote: > You can maybe check who is pointing to the model. There is a menu in the inspector. > > Alexandre > > > On 26 Jan 2010, at 08:09, Fabrizio Perin wrote: > >> Hi, >> yesterday I tried to delete a moose model from my image using the function Utilities>>Delete on the moose panel. The model disappear from the list but saving the image it has the same size. Executing "MooseModel allInstances" I saw that the model was still there. I tried to close all windows and then i execute "Smalltalk garbageCollect" and again the saved image has the same size because the model has not been removed. >> >> I'm working on the pharo dev image 10508, Moose-Core 215 but i detect the same error in an older image: pharo dev image 10502, Moose-Core 208. >> >> Cheers, >> >> Fabrizio >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev Fabrizio Perin Institut fuer Mathematik und Informatik University Bern, IAM-SCG Neubrueckstrasse 10 CH-3012 Bern, Switzerland Tel: +41 31 631 33 13 FAX: +41 31 631 33 55 -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandre at bergel.eu Tue Jan 26 21:07:45 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 17:07:45 -0300 Subject: [Moose-dev] Building package cache Message-ID: I do not have a solution, but this is really annoying. In addition to the time taken by loading Moose, it makes 10 minutes just to check what are are dependencies Mondrian has. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From Simon.Denier at inria.fr Tue Jan 26 22:03:35 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Tue, 26 Jan 2010 22:03:35 +0100 Subject: [Moose-dev] Re: Building package cache In-Reply-To: References: Message-ID: <68EDB65D-4C3C-48C5-9441-F0BBEF0F910F@inria.fr> On 26 janv. 2010, at 21:07, Alexandre Bergel wrote: > I do not have a solution, but this is really annoying. In addition to the time taken by loading Moose, it makes 10 minutes just to check what are are dependencies Mondrian has. > Well, temporary solutions sometimes become less than temporary... I fear this is the case. Maybe we can do something with an incremental, on-demand cache: whenever a class or method is imported, we check whether the cache has been built for it - if not, we built it. -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor.girba at gmail.com Wed Jan 27 00:23:22 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 27 Jan 2010 00:23:22 +0100 Subject: [Moose-dev] Re: issue deleting a moose model In-Reply-To: <645E98E6-7F00-4026-846E-5837CA680B1E@iam.unibe.ch> References: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> <645E98E6-7F00-4026-846E-5837CA680B1E@iam.unibe.ch> Message-ID: <6140EB48-B93E-475D-AC29-FB86C5F21F53@gmail.com> Hi Fabrizio, You could probably reproduce this problem in a new smaller image as well. No need to spend the time doing it on a very large one. Cheers, Doru On 26 Jan 2010, at 18:51, Fabrizio Perin wrote: > Hi, > i tried to check the pointers to the model opening that menu. My > machine start to work at 100% and after 3 hours i didn't have the > list of pointers visualized yet. So i decide to kill the image. The > system was surely into an infinite loop (or there were billions of > links so i think that is useless know which they were). I will > anyway try to let my machine work during the night just in the case > that i'm wrong :) Meanwhile have you other suggestions? Thanks in > advance. > > Cheers, > > Fabrizio > > > On 26 Jan 2010, at 12:20, Alexandre Bergel wrote: > >> You can maybe check who is pointing to the model. There is a menu >> in the inspector. >> >> Alexandre >> >> >> On 26 Jan 2010, at 08:09, Fabrizio Perin wrote: >> >>> Hi, >>> yesterday I tried to delete a moose model from my image using the >>> function Utilities>>Delete on the moose panel. The model disappear >>> from the list but saving the image it has the same size. Executing >>> "MooseModel allInstances" I saw that the model was still there. I >>> tried to close all windows and then i execute "Smalltalk >>> garbageCollect" and again the saved image has the same size >>> because the model has not been removed. >>> >>> I'm working on the pharo dev image 10508, Moose-Core 215 but i >>> detect the same error in an older image: pharo dev image 10502, >>> Moose-Core 208. >>> >>> Cheers, >>> >>> Fabrizio >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > Fabrizio Perin > Institut fuer Mathematik und Informatik > University Bern, IAM-SCG > Neubrueckstrasse 10 > CH-3012 Bern, Switzerland > Tel: +41 31 631 33 13 > FAX: +41 31 631 33 55 > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From tudor.girba at gmail.com Wed Jan 27 00:24:07 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 27 Jan 2010 00:24:07 +0100 Subject: [Moose-dev] Re: FlowInLayout In-Reply-To: <403D3DDE-DBD7-4DEC-9DAC-47359033C885@dcc.uchile.cl> References: <403D3DDE-DBD7-4DEC-9DAC-47359033C885@dcc.uchile.cl> Message-ID: Hi Alex, I would not focus much on this one. The FillInFlowLayout was not really used. It was more of an experiment. Cheers, Doru On 26 Jan 2010, at 18:32, Alexandre Bergel wrote: > Hi! > > My last improvement brake the test testFlowInLayout. > I will try to fix this asap... > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Obvious things are difficult to teach." From tudor.girba at gmail.com Wed Jan 27 00:24:41 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 27 Jan 2010 00:24:41 +0100 Subject: [Moose-dev] Re: dirty morphic In-Reply-To: <7027F3E7-3F08-48DA-A0F1-D67713E429F2@bergel.eu> References: <527646F4-5238-4977-9BD5-E609FBDA570E@gmail.com> <94E3BA02-B881-4B20-A679-357CDC4B576C@bergel.eu> <7027F3E7-3F08-48DA-A0F1-D67713E429F2@bergel.eu> Message-ID: Oh my :). Thanks! Doru On 26 Jan 2010, at 18:21, Alexandre Bergel wrote: > Hi Doru, > > I think the reason is that you load Morphic extension in > ConfigurationOfGlamour: > > spec for: #common do: [ > spec blessing: #baseline. > spec repository: 'http://www.squeaksource.com/Glamour'. > spec > package: 'Morphic-MorphTreeWidget' with: [ > spec repository: 'http://www.squeaksource.com/Momo10' ]; > > > This is what appear when I look at the differences of Morphic before > and after loading Moose. > > Alexandre > > > On 26 Jan 2010, at 08:33, Tudor Girba wrote: > >> That is strange, because Morphic still appears dirty. >> >> Cheers, >> Doru >> >> On 26 Jan 2010, at 12:21, Alexandre Bergel wrote: >> >>> Not anymore. I removed this from Mondrian few weeks ago. >>> >>> Alexandre >>> >>> >>> On 26 Jan 2010, at 07:09, Tudor Girba wrote: >>> >>>> Hi Alex, >>>> >>>> Does Mondrian still need the Morphic changeset installed at >>>> loading time? >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Presenting is storytelling." >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at >> them." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar." From alexandre at bergel.eu Wed Jan 27 01:37:11 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Tue, 26 Jan 2010 21:37:11 -0300 Subject: [Moose-dev] [Mondrian] Delay in popup Message-ID: <299F2A33-7A39-4C8E-9A19-F8AE5AE87DFC@bergel.eu> It should now be okay. Please update to Mondrian-Alexandre_Bergel.355 Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From alexandre at bergel.eu Wed Jan 27 11:23:13 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 27 Jan 2010 07:23:13 -0300 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> Message-ID: <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> Let's continue the discussion on the mailing list. Yesterday evening I imeplemented zOrder. Howerver, I haven't detected any noticiable slowdown. Here is the health report I just produced. I use a 10508 image. Execute: MondrianHealth new produceReport Do you have similar figures ? (I have a MacBook Pro). Report produced on 2010-01-27T07:19:43+00:00 Benchmark ManyNode (simple rendering of nodes) : 100 nodes => 2 ms 200 nodes => 4 ms 300 nodes => 6 ms 400 nodes => 7 ms 500 nodes => 9 ms 600 nodes => 11 ms 700 nodes => 13 ms 800 nodes => 14 ms 900 nodes => 15 ms 1000 nodes => 18 ms 1600 nodes => 29 ms Benchmark ManyEdges (simple rendering of edges) : 10 edges => 1 ms 20 edges => 6 ms 30 edges => 14 ms 40 edges => 27 ms 50 edges => 49 ms 60 edges => 77 ms 70 edges => 118 ms 80 edges => 175 ms 90 edges => 348 ms 100 edges => 362 ms 200 edges => 5349 ms 300 edges => 43118 ms 54.77 % of methods are covered Progress from last time: 0.0 % On 27 Jan 2010, at 05:25, Laval Jannik wrote: > Il fonctionne ici. > > Par contre, j'ai un comportement bizarre avec les derniers versions > de Mondrian: > Il est vraiment vraiment lent. > > Il devient impossible d'utliser DSM car tr?s difficile de scroller > ou meme d'afficher les popup: > Pour afficher une popup, je dois attendre plus de 8 secondes.... > Bouger la fenetre ou l'agrandir est aussi difficile. > > J'utilise une 10508-dev toute clean que j'ai charg? ce matin. > > Jannik > > > On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: > >> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? >> reproduire la chose. >> >> Alexandre >> >> >> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >> >>> sur all model packages dans moose, >>> tu peux utliser DSM with Zoom. >>> >>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement un >>> refresh. >>> Il fonctionne une premiere fois. >>> Ensuite, il fonctionne seulement quand je selectionne une autre >>> fenetre... >>> >>> Jannik >>> >>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>> >>>> Je suis en train de charger tout moose maintenant. Dis moi >>>> comment je peux tester >>>> >>>> Alexandre >>>> >>>> >>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>> >>>>> Salut Alex, >>>>> >>>>> J'ai enlev? le code. >>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>> >>>>> Je ne comprends pas pourquoi. >>>>> >>>>> Jannik >>>>> >>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>> >>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>> >>>>>>> Salut Alex, >>>>>>> >>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>> >>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>> Par contre, le code ne reconnait plus MorphicWindowAnnouncement. >>>>>>> >>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>> >>>>>>> Cheers, >>>>>>> Jannik >>>>>>> >>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>> >>>>>>>> Hi! >>>>>>>> >>>>>>>> Juste pour info, si tu le code: >>>>>>>> window announcer >>>>>>>> on: MorphicWindowAnnouncement >>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>> >>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela devrait >>>>>>>> marcher pareil. >>>>>>>> >>>>>>>> Alexandre >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> --- >>> Jannik Laval >>> PhD Student - Rmod Team - INRIA >>> Certified Project Management Associate (IPMA) >>> http://www.jannik-laval.eu >>> http://rmod.lille.inria.fr >>> --- >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jannik.laval at inria.fr Wed Jan 27 11:30:13 2010 From: jannik.laval at inria.fr (Laval Jannik) Date: Wed, 27 Jan 2010 11:30:13 +0100 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> Message-ID: The problem I have is not on the creation. This is when I want to use the MOViewRenderer, It is really slow. Jannik On Jan 27, 2010, at 11:23 , Alexandre Bergel wrote: > Let's continue the discussion on the mailing list. > > Yesterday evening I imeplemented zOrder. Howerver, I haven't detected any noticiable slowdown. Here is the health report I just produced. I use a 10508 image. Execute: MondrianHealth new produceReport > Do you have similar figures ? (I have a MacBook Pro). > > Report produced on 2010-01-27T07:19:43+00:00 > Benchmark ManyNode (simple rendering of nodes) : > 100 nodes => 2 ms > 200 nodes => 4 ms > 300 nodes => 6 ms > 400 nodes => 7 ms > 500 nodes => 9 ms > 600 nodes => 11 ms > 700 nodes => 13 ms > 800 nodes => 14 ms > 900 nodes => 15 ms > 1000 nodes => 18 ms > 1600 nodes => 29 ms > Benchmark ManyEdges (simple rendering of edges) : > 10 edges => 1 ms > 20 edges => 6 ms > 30 edges => 14 ms > 40 edges => 27 ms > 50 edges => 49 ms > 60 edges => 77 ms > 70 edges => 118 ms > 80 edges => 175 ms > 90 edges => 348 ms > 100 edges => 362 ms > 200 edges => 5349 ms > 300 edges => 43118 ms > 54.77 % of methods are covered > Progress from last time: 0.0 % > > > > On 27 Jan 2010, at 05:25, Laval Jannik wrote: > >> Il fonctionne ici. >> >> Par contre, j'ai un comportement bizarre avec les derniers versions de Mondrian: >> Il est vraiment vraiment lent. >> >> Il devient impossible d'utliser DSM car tr?s difficile de scroller ou meme d'afficher les popup: >> Pour afficher une popup, je dois attendre plus de 8 secondes.... >> Bouger la fenetre ou l'agrandir est aussi difficile. >> >> J'utilise une 10508-dev toute clean que j'ai charg? ce matin. >> >> Jannik >> >> >> On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: >> >>> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >>> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? reproduire la chose. >>> >>> Alexandre >>> >>> >>> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >>> >>>> sur all model packages dans moose, >>>> tu peux utliser DSM with Zoom. >>>> >>>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement un refresh. >>>> Il fonctionne une premiere fois. >>>> Ensuite, il fonctionne seulement quand je selectionne une autre fenetre... >>>> >>>> Jannik >>>> >>>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>>> >>>>> Je suis en train de charger tout moose maintenant. Dis moi comment je peux tester >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>>> >>>>>> Salut Alex, >>>>>> >>>>>> J'ai enlev? le code. >>>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>>> >>>>>> Je ne comprends pas pourquoi. >>>>>> >>>>>> Jannik >>>>>> >>>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>>> >>>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>>> >>>>>>>> Salut Alex, >>>>>>>> >>>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>>> >>>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>>> Par contre, le code ne reconnait plus MorphicWindowAnnouncement. >>>>>>>> >>>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Jannik >>>>>>>> >>>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>>> >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> Juste pour info, si tu le code: >>>>>>>>> window announcer >>>>>>>>> on: MorphicWindowAnnouncement >>>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>>> >>>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela devrait marcher pareil. >>>>>>>>> >>>>>>>>> Alexandre >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --- >>>> Jannik Laval >>>> PhD Student - Rmod Team - INRIA >>>> Certified Project Management Associate (IPMA) >>>> http://www.jannik-laval.eu >>>> http://rmod.lille.inria.fr >>>> --- >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Wed Jan 27 11:37:42 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 27 Jan 2010 07:37:42 -0300 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> Message-ID: <40F072BE-5A72-4AB4-9FFA-BB25EDE8EADE@bergel.eu> I have to be away from my computer for a couple of hours. How can I open a dsm without using the Glamour menu? I would imagine that I can send a message openInDSM to a Moose model or something? Alexandre On 27 Jan 2010, at 07:30, Laval Jannik wrote: > The problem I have is not on the creation. > This is when I want to use the MOViewRenderer, > It is really slow. > > Jannik > > > On Jan 27, 2010, at 11:23 , Alexandre Bergel wrote: > >> Let's continue the discussion on the mailing list. >> >> Yesterday evening I imeplemented zOrder. Howerver, I haven't >> detected any noticiable slowdown. Here is the health report I just >> produced. I use a 10508 image. Execute: MondrianHealth new >> produceReport >> Do you have similar figures ? (I have a MacBook Pro). >> >> Report produced on 2010-01-27T07:19:43+00:00 >> Benchmark ManyNode (simple rendering of nodes) : >> 100 nodes => 2 ms >> 200 nodes => 4 ms >> 300 nodes => 6 ms >> 400 nodes => 7 ms >> 500 nodes => 9 ms >> 600 nodes => 11 ms >> 700 nodes => 13 ms >> 800 nodes => 14 ms >> 900 nodes => 15 ms >> 1000 nodes => 18 ms >> 1600 nodes => 29 ms >> Benchmark ManyEdges (simple rendering of edges) : >> 10 edges => 1 ms >> 20 edges => 6 ms >> 30 edges => 14 ms >> 40 edges => 27 ms >> 50 edges => 49 ms >> 60 edges => 77 ms >> 70 edges => 118 ms >> 80 edges => 175 ms >> 90 edges => 348 ms >> 100 edges => 362 ms >> 200 edges => 5349 ms >> 300 edges => 43118 ms >> 54.77 % of methods are covered >> Progress from last time: 0.0 % >> >> >> >> On 27 Jan 2010, at 05:25, Laval Jannik wrote: >> >>> Il fonctionne ici. >>> >>> Par contre, j'ai un comportement bizarre avec les derniers >>> versions de Mondrian: >>> Il est vraiment vraiment lent. >>> >>> Il devient impossible d'utliser DSM car tr?s difficile de scroller >>> ou meme d'afficher les popup: >>> Pour afficher une popup, je dois attendre plus de 8 secondes.... >>> Bouger la fenetre ou l'agrandir est aussi difficile. >>> >>> J'utilise une 10508-dev toute clean que j'ai charg? ce matin. >>> >>> Jannik >>> >>> >>> On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: >>> >>>> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >>>> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? >>>> reproduire la chose. >>>> >>>> Alexandre >>>> >>>> >>>> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >>>> >>>>> sur all model packages dans moose, >>>>> tu peux utliser DSM with Zoom. >>>>> >>>>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement un >>>>> refresh. >>>>> Il fonctionne une premiere fois. >>>>> Ensuite, il fonctionne seulement quand je selectionne une autre >>>>> fenetre... >>>>> >>>>> Jannik >>>>> >>>>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>>>> >>>>>> Je suis en train de charger tout moose maintenant. Dis moi >>>>>> comment je peux tester >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>>>> >>>>>>> Salut Alex, >>>>>>> >>>>>>> J'ai enlev? le code. >>>>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>>>> >>>>>>> Je ne comprends pas pourquoi. >>>>>>> >>>>>>> Jannik >>>>>>> >>>>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>>>> >>>>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>> >>>>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>>>> >>>>>>>>> Salut Alex, >>>>>>>>> >>>>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>>>> >>>>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>>>> Par contre, le code ne reconnait plus >>>>>>>>> MorphicWindowAnnouncement. >>>>>>>>> >>>>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Jannik >>>>>>>>> >>>>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>>>> >>>>>>>>>> Hi! >>>>>>>>>> >>>>>>>>>> Juste pour info, si tu le code: >>>>>>>>>> window announcer >>>>>>>>>> on: MorphicWindowAnnouncement >>>>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>>>> >>>>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela >>>>>>>>>> devrait marcher pareil. >>>>>>>>>> >>>>>>>>>> Alexandre >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --- >>>>> Jannik Laval >>>>> PhD Student - Rmod Team - INRIA >>>>> Certified Project Management Associate (IPMA) >>>>> http://www.jannik-laval.eu >>>>> http://rmod.lille.inria.fr >>>>> --- >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From tudor.girba at gmail.com Wed Jan 27 11:44:56 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 27 Jan 2010 11:44:56 +0100 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: <40F072BE-5A72-4AB4-9FFA-BB25EDE8EADE@bergel.eu> References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> <40F072BE-5A72-4AB4-9FFA-BB25EDE8EADE@bergel.eu> Message-ID: <04BC6F9F-A9D3-4BAB-8F84-31CE96394541@gmail.com> Hi Jannik, I cannot reproduce the slowdown. What exactly do you do to get the easel slow? Does it also happen in the regular MOCanvas as well (I mean when you just open the view)? Cheers, Doru On 27 Jan 2010, at 11:37, Alexandre Bergel wrote: > I have to be away from my computer for a couple of hours. How can I > open a dsm without using the Glamour menu? I would imagine that I > can send a message openInDSM to a Moose model or something? > > Alexandre > > On 27 Jan 2010, at 07:30, Laval Jannik wrote: > >> The problem I have is not on the creation. >> This is when I want to use the MOViewRenderer, >> It is really slow. >> >> Jannik >> >> >> On Jan 27, 2010, at 11:23 , Alexandre Bergel wrote: >> >>> Let's continue the discussion on the mailing list. >>> >>> Yesterday evening I imeplemented zOrder. Howerver, I haven't >>> detected any noticiable slowdown. Here is the health report I just >>> produced. I use a 10508 image. Execute: MondrianHealth new >>> produceReport >>> Do you have similar figures ? (I have a MacBook Pro). >>> >>> Report produced on 2010-01-27T07:19:43+00:00 >>> Benchmark ManyNode (simple rendering of nodes) : >>> 100 nodes => 2 ms >>> 200 nodes => 4 ms >>> 300 nodes => 6 ms >>> 400 nodes => 7 ms >>> 500 nodes => 9 ms >>> 600 nodes => 11 ms >>> 700 nodes => 13 ms >>> 800 nodes => 14 ms >>> 900 nodes => 15 ms >>> 1000 nodes => 18 ms >>> 1600 nodes => 29 ms >>> Benchmark ManyEdges (simple rendering of edges) : >>> 10 edges => 1 ms >>> 20 edges => 6 ms >>> 30 edges => 14 ms >>> 40 edges => 27 ms >>> 50 edges => 49 ms >>> 60 edges => 77 ms >>> 70 edges => 118 ms >>> 80 edges => 175 ms >>> 90 edges => 348 ms >>> 100 edges => 362 ms >>> 200 edges => 5349 ms >>> 300 edges => 43118 ms >>> 54.77 % of methods are covered >>> Progress from last time: 0.0 % >>> >>> >>> >>> On 27 Jan 2010, at 05:25, Laval Jannik wrote: >>> >>>> Il fonctionne ici. >>>> >>>> Par contre, j'ai un comportement bizarre avec les derniers >>>> versions de Mondrian: >>>> Il est vraiment vraiment lent. >>>> >>>> Il devient impossible d'utliser DSM car tr?s difficile de >>>> scroller ou meme d'afficher les popup: >>>> Pour afficher une popup, je dois attendre plus de 8 secondes.... >>>> Bouger la fenetre ou l'agrandir est aussi difficile. >>>> >>>> J'utilise une 10508-dev toute clean que j'ai charg? ce matin. >>>> >>>> Jannik >>>> >>>> >>>> On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: >>>> >>>>> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >>>>> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? >>>>> reproduire la chose. >>>>> >>>>> Alexandre >>>>> >>>>> >>>>> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >>>>> >>>>>> sur all model packages dans moose, >>>>>> tu peux utliser DSM with Zoom. >>>>>> >>>>>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement un >>>>>> refresh. >>>>>> Il fonctionne une premiere fois. >>>>>> Ensuite, il fonctionne seulement quand je selectionne une autre >>>>>> fenetre... >>>>>> >>>>>> Jannik >>>>>> >>>>>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>>>>> >>>>>>> Je suis en train de charger tout moose maintenant. Dis moi >>>>>>> comment je peux tester >>>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>>>>> >>>>>>>> Salut Alex, >>>>>>>> >>>>>>>> J'ai enlev? le code. >>>>>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>>>>> >>>>>>>> Je ne comprends pas pourquoi. >>>>>>>> >>>>>>>> Jannik >>>>>>>> >>>>>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>>>>> >>>>>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>>>>> >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> >>>>>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>>>>> >>>>>>>>>> Salut Alex, >>>>>>>>>> >>>>>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>>>>> >>>>>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>>>>> Par contre, le code ne reconnait plus >>>>>>>>>> MorphicWindowAnnouncement. >>>>>>>>>> >>>>>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Jannik >>>>>>>>>> >>>>>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>>>>> >>>>>>>>>>> Hi! >>>>>>>>>>> >>>>>>>>>>> Juste pour info, si tu le code: >>>>>>>>>>> window announcer >>>>>>>>>>> on: MorphicWindowAnnouncement >>>>>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>>>>> >>>>>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela >>>>>>>>>>> devrait marcher pareil. >>>>>>>>>>> >>>>>>>>>>> Alexandre >>>>>>>>>>> -- >>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --- >>>>>> Jannik Laval >>>>>> PhD Student - Rmod Team - INRIA >>>>>> Certified Project Management Associate (IPMA) >>>>>> http://www.jannik-laval.eu >>>>>> http://rmod.lille.inria.fr >>>>>> --- >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge." From jannik.laval at gmail.com Wed Jan 27 12:56:14 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Wed, 27 Jan 2010 12:56:14 +0100 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: <04BC6F9F-A9D3-4BAB-8F84-31CE96394541@gmail.com> References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> <40F072BE-5A72-4AB4-9FFA-BB25EDE8EADE@bergel.eu> <04BC6F9F-A9D3-4BAB-8F84-31CE96394541@gmail.com> Message-ID: Hi, My process: --- open a pharo-dev 10508 load Moose do: MooseScripts createModelForMoose do: myModel allModelPackages viewDSM. --- Now, it is not so long to generate a dsm. But the interaction with the view is slow. Interaction is: move the window, use scrollbar, click on a shape, .... All other windows in pharo works fine. Cheers Jannik On Jan 27, 2010, at 11:44 , Tudor Girba wrote: > Hi Jannik, > > I cannot reproduce the slowdown. What exactly do you do to get the easel slow? Does it also happen in the regular MOCanvas as well (I mean when you just open the view)? > > Cheers, > Doru > > > On 27 Jan 2010, at 11:37, Alexandre Bergel wrote: > >> I have to be away from my computer for a couple of hours. How can I open a dsm without using the Glamour menu? I would imagine that I can send a message openInDSM to a Moose model or something? >> >> Alexandre >> >> On 27 Jan 2010, at 07:30, Laval Jannik wrote: >> >>> The problem I have is not on the creation. >>> This is when I want to use the MOViewRenderer, >>> It is really slow. >>> >>> Jannik >>> >>> >>> On Jan 27, 2010, at 11:23 , Alexandre Bergel wrote: >>> >>>> Let's continue the discussion on the mailing list. >>>> >>>> Yesterday evening I imeplemented zOrder. Howerver, I haven't detected any noticiable slowdown. Here is the health report I just produced. I use a 10508 image. Execute: MondrianHealth new produceReport >>>> Do you have similar figures ? (I have a MacBook Pro). >>>> >>>> Report produced on 2010-01-27T07:19:43+00:00 >>>> Benchmark ManyNode (simple rendering of nodes) : >>>> 100 nodes => 2 ms >>>> 200 nodes => 4 ms >>>> 300 nodes => 6 ms >>>> 400 nodes => 7 ms >>>> 500 nodes => 9 ms >>>> 600 nodes => 11 ms >>>> 700 nodes => 13 ms >>>> 800 nodes => 14 ms >>>> 900 nodes => 15 ms >>>> 1000 nodes => 18 ms >>>> 1600 nodes => 29 ms >>>> Benchmark ManyEdges (simple rendering of edges) : >>>> 10 edges => 1 ms >>>> 20 edges => 6 ms >>>> 30 edges => 14 ms >>>> 40 edges => 27 ms >>>> 50 edges => 49 ms >>>> 60 edges => 77 ms >>>> 70 edges => 118 ms >>>> 80 edges => 175 ms >>>> 90 edges => 348 ms >>>> 100 edges => 362 ms >>>> 200 edges => 5349 ms >>>> 300 edges => 43118 ms >>>> 54.77 % of methods are covered >>>> Progress from last time: 0.0 % >>>> >>>> >>>> >>>> On 27 Jan 2010, at 05:25, Laval Jannik wrote: >>>> >>>>> Il fonctionne ici. >>>>> >>>>> Par contre, j'ai un comportement bizarre avec les derniers versions de Mondrian: >>>>> Il est vraiment vraiment lent. >>>>> >>>>> Il devient impossible d'utliser DSM car tr?s difficile de scroller ou meme d'afficher les popup: >>>>> Pour afficher une popup, je dois attendre plus de 8 secondes.... >>>>> Bouger la fenetre ou l'agrandir est aussi difficile. >>>>> >>>>> J'utilise une 10508-dev toute clean que j'ai charg? ce matin. >>>>> >>>>> Jannik >>>>> >>>>> >>>>> On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: >>>>> >>>>>> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >>>>>> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? reproduire la chose. >>>>>> >>>>>> Alexandre >>>>>> >>>>>> >>>>>> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >>>>>> >>>>>>> sur all model packages dans moose, >>>>>>> tu peux utliser DSM with Zoom. >>>>>>> >>>>>>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement un refresh. >>>>>>> Il fonctionne une premiere fois. >>>>>>> Ensuite, il fonctionne seulement quand je selectionne une autre fenetre... >>>>>>> >>>>>>> Jannik >>>>>>> >>>>>>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>>>>>> >>>>>>>> Je suis en train de charger tout moose maintenant. Dis moi comment je peux tester >>>>>>>> >>>>>>>> Alexandre >>>>>>>> >>>>>>>> >>>>>>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>>>>>> >>>>>>>>> Salut Alex, >>>>>>>>> >>>>>>>>> J'ai enlev? le code. >>>>>>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>>>>>> >>>>>>>>> Je ne comprends pas pourquoi. >>>>>>>>> >>>>>>>>> Jannik >>>>>>>>> >>>>>>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>>>>>> >>>>>>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>>>>>> >>>>>>>>>> Alexandre >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>>>>>> >>>>>>>>>>> Salut Alex, >>>>>>>>>>> >>>>>>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>>>>>> >>>>>>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>>>>>> Par contre, le code ne reconnait plus MorphicWindowAnnouncement. >>>>>>>>>>> >>>>>>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Jannik >>>>>>>>>>> >>>>>>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi! >>>>>>>>>>>> >>>>>>>>>>>> Juste pour info, si tu le code: >>>>>>>>>>>> window announcer >>>>>>>>>>>> on: MorphicWindowAnnouncement >>>>>>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>>>>>> >>>>>>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela devrait marcher pareil. >>>>>>>>>>>> >>>>>>>>>>>> Alexandre >>>>>>>>>>>> -- >>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --- >>>>>>> Jannik Laval >>>>>>> PhD Student - Rmod Team - INRIA >>>>>>> Certified Project Management Associate (IPMA) >>>>>>> http://www.jannik-laval.eu >>>>>>> http://rmod.lille.inria.fr >>>>>>> --- >>>>>> >>>>>> -- >>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>> Alexandre Bergel http://www.bergel.eu >>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From alexandre at bergel.eu Wed Jan 27 14:16:50 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 27 Jan 2010 10:16:50 -0300 Subject: [Moose-dev] Re: DSMBrowser In-Reply-To: References: <32998E67-05D9-49A4-AB6D-C671C02D0C23@dcc.uchile.cl> <9ADB70D2-2969-488C-A86B-9CF30BD4E78B@inria.fr> <1A12D0C5-F8B0-43FC-A605-E77DB3A1EA3B@inria.fr> <6F5DC92F-2E8C-4D7F-A23C-D1A85C716050@dcc.uchile.cl> <4EFFFE06-C489-473E-9E4D-384EE9B74C72@dcc.uchile.cl> <23AA5FF2-E717-4472-A4B2-1BEFF124FEB6@bergel.eu> <40F072BE-5A72-4AB4-9FFA-BB25EDE8EADE@bergel.eu> <04BC6F9F-A9D3-4BAB-8F84-31CE96394541@gmail.com> Message-ID: <9F0E6E51-5196-4104-AB5C-CC413DDE5736@bergel.eu> Yeah, this is really slow. I am investigating Alexandre On 27 Jan 2010, at 08:56, Laval Jannik wrote: > Hi, > > My process: > --- > open a pharo-dev 10508 > load Moose > do: MooseScripts createModelForMoose > do: myModel allModelPackages viewDSM. > --- > > Now, it is not so long to generate a dsm. > But the interaction with the view is slow. > Interaction is: move the window, use scrollbar, click on a shape, .... > > All other windows in pharo works fine. > > Cheers > Jannik > > On Jan 27, 2010, at 11:44 , Tudor Girba wrote: > >> Hi Jannik, >> >> I cannot reproduce the slowdown. What exactly do you do to get the >> easel slow? Does it also happen in the regular MOCanvas as well (I >> mean when you just open the view)? >> >> Cheers, >> Doru >> >> >> On 27 Jan 2010, at 11:37, Alexandre Bergel wrote: >> >>> I have to be away from my computer for a couple of hours. How can >>> I open a dsm without using the Glamour menu? I would imagine that >>> I can send a message openInDSM to a Moose model or something? >>> >>> Alexandre >>> >>> On 27 Jan 2010, at 07:30, Laval Jannik wrote: >>> >>>> The problem I have is not on the creation. >>>> This is when I want to use the MOViewRenderer, >>>> It is really slow. >>>> >>>> Jannik >>>> >>>> >>>> On Jan 27, 2010, at 11:23 , Alexandre Bergel wrote: >>>> >>>>> Let's continue the discussion on the mailing list. >>>>> >>>>> Yesterday evening I imeplemented zOrder. Howerver, I haven't >>>>> detected any noticiable slowdown. Here is the health report I >>>>> just produced. I use a 10508 image. Execute: MondrianHealth new >>>>> produceReport >>>>> Do you have similar figures ? (I have a MacBook Pro). >>>>> >>>>> Report produced on 2010-01-27T07:19:43+00:00 >>>>> Benchmark ManyNode (simple rendering of nodes) : >>>>> 100 nodes => 2 ms >>>>> 200 nodes => 4 ms >>>>> 300 nodes => 6 ms >>>>> 400 nodes => 7 ms >>>>> 500 nodes => 9 ms >>>>> 600 nodes => 11 ms >>>>> 700 nodes => 13 ms >>>>> 800 nodes => 14 ms >>>>> 900 nodes => 15 ms >>>>> 1000 nodes => 18 ms >>>>> 1600 nodes => 29 ms >>>>> Benchmark ManyEdges (simple rendering of edges) : >>>>> 10 edges => 1 ms >>>>> 20 edges => 6 ms >>>>> 30 edges => 14 ms >>>>> 40 edges => 27 ms >>>>> 50 edges => 49 ms >>>>> 60 edges => 77 ms >>>>> 70 edges => 118 ms >>>>> 80 edges => 175 ms >>>>> 90 edges => 348 ms >>>>> 100 edges => 362 ms >>>>> 200 edges => 5349 ms >>>>> 300 edges => 43118 ms >>>>> 54.77 % of methods are covered >>>>> Progress from last time: 0.0 % >>>>> >>>>> >>>>> >>>>> On 27 Jan 2010, at 05:25, Laval Jannik wrote: >>>>> >>>>>> Il fonctionne ici. >>>>>> >>>>>> Par contre, j'ai un comportement bizarre avec les derniers >>>>>> versions de Mondrian: >>>>>> Il est vraiment vraiment lent. >>>>>> >>>>>> Il devient impossible d'utliser DSM car tr?s difficile de >>>>>> scroller ou meme d'afficher les popup: >>>>>> Pour afficher une popup, je dois attendre plus de 8 secondes.... >>>>>> Bouger la fenetre ou l'agrandir est aussi difficile. >>>>>> >>>>>> J'utilise une 10508-dev toute clean que j'ai charg? ce matin. >>>>>> >>>>>> Jannik >>>>>> >>>>>> >>>>>> On Jan 27, 2010, at 01:41 , Alexandre Bergel wrote: >>>>>> >>>>>>> C'est vraiment bizarre. Le right-click ne m'offre pas de menu. >>>>>>> J'ai essay? de voir cela avec Doru, mais il n'arrive pas ? >>>>>>> reproduire la chose. >>>>>>> >>>>>>> Alexandre >>>>>>> >>>>>>> >>>>>>> On 26 Jan 2010, at 11:33, Laval Jannik wrote: >>>>>>> >>>>>>>> sur all model packages dans moose, >>>>>>>> tu peux utliser DSM with Zoom. >>>>>>>> >>>>>>>> Dans la fenetre qui s'ouvre avec + et -, il y a normalement >>>>>>>> un refresh. >>>>>>>> Il fonctionne une premiere fois. >>>>>>>> Ensuite, il fonctionne seulement quand je selectionne une >>>>>>>> autre fenetre... >>>>>>>> >>>>>>>> Jannik >>>>>>>> >>>>>>>> On Jan 26, 2010, at 15:18 , Alexandre Bergel wrote: >>>>>>>> >>>>>>>>> Je suis en train de charger tout moose maintenant. Dis moi >>>>>>>>> comment je peux tester >>>>>>>>> >>>>>>>>> Alexandre >>>>>>>>> >>>>>>>>> >>>>>>>>> On 26 Jan 2010, at 11:15, Laval Jannik wrote: >>>>>>>>> >>>>>>>>>> Salut Alex, >>>>>>>>>> >>>>>>>>>> J'ai enlev? le code. >>>>>>>>>> Maintenant, il ne rafra?chi qu'une seule fois. >>>>>>>>>> >>>>>>>>>> Je ne comprends pas pourquoi. >>>>>>>>>> >>>>>>>>>> Jannik >>>>>>>>>> >>>>>>>>>> On Jan 23, 2010, at 15:15 , Alexandre Bergel wrote: >>>>>>>>>> >>>>>>>>>>> Enl?ve juste le code. Tu devrais quand meme avoir le refresh >>>>>>>>>>> >>>>>>>>>>> Alexandre >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 22 Jan 2010, at 08:51, Laval Jannik wrote: >>>>>>>>>>> >>>>>>>>>>>> Salut Alex, >>>>>>>>>>>> >>>>>>>>>>>> Pardon pour la r?ponse un peu tardive :) >>>>>>>>>>>> >>>>>>>>>>>> Oui c'est cod? de cette fa?on :) >>>>>>>>>>>> Par contre, le code ne reconnait plus >>>>>>>>>>>> MorphicWindowAnnouncement. >>>>>>>>>>>> >>>>>>>>>>>> Y a-t-il un package particulier ? charger ? >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Jannik >>>>>>>>>>>> >>>>>>>>>>>> On Jan 16, 2010, at 00:52 , Alexandre Bergel wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi! >>>>>>>>>>>>> >>>>>>>>>>>>> Juste pour info, si tu le code: >>>>>>>>>>>>> window announcer >>>>>>>>>>>>> on: MorphicWindowAnnouncement >>>>>>>>>>>>> do: [:ann | self root resetFormCacheResursively]. >>>>>>>>>>>>> >>>>>>>>>>>>> que tu as dans openDSM, openDSMDemo et openDemo, cela >>>>>>>>>>>>> devrait marcher pareil. >>>>>>>>>>>>> >>>>>>>>>>>>> Alexandre >>>>>>>>>>>>> -- >>>>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --- >>>>>>>> Jannik Laval >>>>>>>> PhD Student - Rmod Team - INRIA >>>>>>>> Certified Project Management Associate (IPMA) >>>>>>>> http://www.jannik-laval.eu >>>>>>>> http://rmod.lille.inria.fr >>>>>>>> --- >>>>>>> >>>>>>> -- >>>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>>>> Alexandre Bergel http://www.bergel.eu >>>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>>> Alexandre Bergel http://www.bergel.eu >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev at iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jfabry at dcc.uchile.cl Wed Jan 27 15:51:32 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 27 Jan 2010 11:51:32 -0300 Subject: [Moose-dev] Re: [Mondrian] Delay in popup In-Reply-To: <299F2A33-7A39-4C8E-9A19-F8AE5AE87DFC@bergel.eu> References: <299F2A33-7A39-4C8E-9A19-F8AE5AE87DFC@bergel.eu> Message-ID: <110267B3-9270-42E4-B8FA-61A7BF798A65@dcc.uchile.cl> Cool, popups work much better than before, thanks a lot! I however got a DNU at some point because ActiveHand was nil at some point. I think that you are forking in the wrong place: your code lets the drawing of the popup be in a separate thread, while I would have the entire process of waiting for the delay time and then drawing be in a separate thread. Just an extra pair of [] does that, see code below. As far as I can analyze the code it should not produce concurrency issues. (Although I prefer the conceptually clean solution I detailed last week) I have played around with this for some time and it works fine. But of course for concurrent code this is not a guarantee ... popupView: aBlock delay: ms "open a popup text when the mouse enter a node" "Yeah, this method is a bit scary" self unsubscribeForEvent: MOMouseEnter. self unsubscribeForEvent: MOMouseLeave. self subscribe: MOMouseEnter do: [:ann | (ann hasElement and: [(ann element isKindOf: MORoot) not]) ifTrue: [ "Note extra [" [ | oldPosition view newCanvas relativePosition | [oldPosition := ActiveHand position. (Delay forMilliseconds: ms) wait. "we compute the relative position since ActiveHand return an absolute location" relativePosition := ann position - oldPosition + ActiveHand position. "We check if we are in the same node, if yes, then we evaluate the view" (ann root notNil and: [(ann root elementAt: relativePosition) == ann current]) ifTrue: [ view := MOViewRenderer new. aBlock value: ann element model value: view. newCanvas := MOPopup showView: view. ann element popup: newCanvas. ] ]] fork. "note extra ] before fork" ] ifFalse: [ann element popup ifNotNilDo: [:v | v delete]. MOPopup remove] ]. self subscribe: MOMouseLeave do: [:ann | ann element popup ifNotNilDo: [:v | v delete]. MOPopup remove ]. On 26 Jan 2010, at 21:37, Alexandre Bergel wrote: > It should now be okay. Please update to > > Mondrian-Alexandre_Bergel.355 > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From jfabry at dcc.uchile.cl Wed Jan 27 16:00:20 2010 From: jfabry at dcc.uchile.cl (Johan Fabry) Date: Wed, 27 Jan 2010 12:00:20 -0300 Subject: [Moose-dev] Re: [Mondrian] Delay in popup In-Reply-To: <110267B3-9270-42E4-B8FA-61A7BF798A65@dcc.uchile.cl> References: <299F2A33-7A39-4C8E-9A19-F8AE5AE87DFC@bergel.eu> <110267B3-9270-42E4-B8FA-61A7BF798A65@dcc.uchile.cl> Message-ID: <7F974983-61CC-4938-8390-8EF2F257AC2B@dcc.uchile.cl> Sorry guys, forget this code, it does not work (although theoretically it should ;-) ). I did not reopen the mondrian view when I tested this version, so I was still testing Alex's version. It's a pity that the dynamism of ST & method recompilation stops when treating with Mondrian. I'm still not used to that :-( No time to figure the concurrency issue out in more detail though, sorry for that ... On 27 Jan 2010, at 11:51, Johan Fabry wrote: > As far as I can analyze the code it should not produce concurrency > issues. (Although I prefer the conceptually clean solution I > detailed last week) I have played around with this for some time and > it works fine. But of course for concurrent code this is not a > guarantee ... -- Johan Fabry jfabry at dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile From tudor.girba at gmail.com Wed Jan 27 21:20:32 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Wed, 27 Jan 2010 21:20:32 +0100 Subject: [Moose-dev] zorder Message-ID: Hi Alex, Thanks for implementing the zOrder! It works great. What's even nicer is that in the process, it looks like issue the edge clipping problem was also solved: http://code.google.com/p/moose-technology/issues/detail?id=229 Cheers, Doru -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower." From alexandre at bergel.eu Wed Jan 27 21:28:38 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Wed, 27 Jan 2010 17:28:38 -0300 Subject: [Moose-dev] Re: zorder In-Reply-To: References: Message-ID: > What's even nicer is that in the process, it looks like issue the > edge clipping problem was also solved: > http://code.google.com/p/moose-technology/issues/detail?id=229 Yes, I saw this as well. this is cool Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From cy.delaunay at gmail.com Thu Jan 28 11:34:48 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Thu, 28 Jan 2010 11:34:48 +0100 Subject: [Moose-dev] Hoe to retrieve MooseGroups from a MooseModel Message-ID: Hi, When opening a mooseModel in a mooseFinder, several groups of entities appear ('all famixaaccess' 'all famixattribute'). How can I access to this groups from the mooseModel. I have tryed to send 'entityGroups' to a moose model (generated with CAnalyzer) , but it only answer me a part of all the groups visible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tudor.girba at gmail.com Thu Jan 28 11:42:53 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Thu, 28 Jan 2010 11:42:53 +0100 Subject: [Moose-dev] Re: Hoe to retrieve MooseGroups from a MooseModel In-Reply-To: References: Message-ID: <9A5BBED9-F81A-4DC5-84F2-7670C60BFFE9@gmail.com> Hi Cyrille, > When opening a mooseModel in a mooseFinder, several groups of > entities appear ('all famixaaccess' 'all famixattribute'). How can I > access to this groups from the mooseModel. For example, aMooseModel allAttributes. You find these extensions in FAMIX-Extensions. > I have tryed to send 'entityGroups' to a moose model (generated > with CAnalyzer) , but it only answer me a part of all the groups > visible. The entities are actually all cached in the MooseModel by their type. You can access it as aMooseModel allWithType: FAMIXAttribute. Cheers, Doru > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Don't give to get. Just give." From cy.delaunay at gmail.com Thu Jan 28 14:04:32 2010 From: cy.delaunay at gmail.com (Cyrille Delaunay) Date: Thu, 28 Jan 2010 14:04:32 +0100 Subject: [Moose-dev] srcml - Message-ID: In xml files generated with srcml, we can find the balise '.. '. Does anyOne know what it represent? Because I have the impression that it represent sometimes a function declaration, But this is not assimilate to a function declaration in CAnalyzer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.ducasse at inria.fr Thu Jan 28 14:18:03 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Thu, 28 Jan 2010 14:18:03 +0100 Subject: [Moose-dev] Re: srcml - In-Reply-To: References: Message-ID: this is a program statement. Now I do not know what they put inside that. On Jan 28, 2010, at 2:04 PM, Cyrille Delaunay wrote: > In xml files generated with srcml, we can find the balise '.. '. Does anyOne know what it represent? Because I have the impression that it represent sometimes a function declaration, But this is not assimilate to a function declaration in CAnalyzer. _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From Simon.Denier at inria.fr Thu Jan 28 14:58:52 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Thu, 28 Jan 2010 14:58:52 +0100 Subject: [Moose-dev] Re: srcml - In-Reply-To: References: Message-ID: On 28 janv. 2010, at 14:18, St?phane Ducasse wrote: > this is a program statement. > Now I do not know what they put inside that. That's the problem. Cyrille found at least one case where it should be a function declaration. It's not clear why srcMl detects a program statement in this case. Also maybe we should try srcMl on the preprocessed code, because it seems we have some noise with macro in cairo. > On Jan 28, 2010, at 2:04 PM, Cyrille Delaunay wrote: > >> In xml files generated with srcml, we can find the balise '.. '. Does anyOne know what it represent? Because I have the impression that it represent sometimes a function declaration, But this is not assimilate to a function declaration in CAnalyzer. _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon From Simon.Denier at inria.fr Fri Jan 29 10:54:00 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 29 Jan 2010 10:54:00 +0100 Subject: [Moose-dev] Fwd: Building package cache References: Message-ID: okaaay, wrong reply-to, retweet.... Begin forwarded message: > From: Simon Denier > Date: 28 janvier 2010 23:45:50 HNEC > To: Simon Denier > Subject: Re: [Moose-dev] Building package cache > > > On 26 janv. 2010, at 22:03, Simon Denier wrote: > >> >> On 26 janv. 2010, at 21:07, Alexandre Bergel wrote: >> >>> I do not have a solution, but this is really annoying. In addition to the time taken by loading Moose, it makes 10 minutes just to check what are are dependencies Mondrian has. >>> >> >> Well, temporary solutions sometimes become less than temporary... I fear this is the case. >> >> Maybe we can do something with an incremental, on-demand cache: whenever a class or method is imported, we check whether the cache has been built for it - if not, we built it. > > > > After playing a bit with the idea tonight, now I remember why I choose the global cache solution. So I explain how it works in the current system: > > To build the system cache, I go over all classes and all class extensions of PackageInfos and register their most specific package. > Since I go over the whole system, I assume I know all class extensions in all classes. > Now when I ask the package for a method, there are two cases: > - either I can find it in the cache of class extensions and I return its package > - either I can't find it, so I assume it is a normal method and retrieve the package of its class (from the cache). > > Now in an incremental cache system, I can cache a class when I import it, I can even cache a package so that its class extensions are imported, as above. The big problem is then that I can't assume that I know all class extensions within the class, because other packages (which I don't necessarily import) may do some. To do that, I should ask all methods within each imported class for its most specific package. This was more or less the situation we had before the cache, which brought the system to its knees on large projects. Perhaps I will try tomorrow but I don't have high hope. We need something better than that. > > > -- > Simon > > > -- Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jannik.laval at inria.fr Fri Jan 29 15:19:01 2010 From: jannik.laval at inria.fr (Laval Jannik) Date: Fri, 29 Jan 2010 15:19:01 +0100 Subject: [Moose-dev] Small font in Mondrian Message-ID: Hi Alex, Is it possible to int?grate small fonts in Mondrian. Alain Plantec has made a package named 'DejaVue' published in squeaksource. It would be great to integrate it in Mondrian. Cheers --- Jannik Laval --- From Simon.Denier at inria.fr Fri Jan 29 18:50:58 2010 From: Simon.Denier at inria.fr (Simon Denier) Date: Fri, 29 Jan 2010 18:50:58 +0100 Subject: [Moose-dev] Issue 28 fixed Message-ID: <9108D87F-C638-4B7D-8451-E7A2C4CAE30F@inria.fr> Hi there Issue 28 is now closed. It was the last pending issue for 4.0 in Moose itself. Tests are green in Moose and we add another test for the case. So you should not notive any problem when running the importer. -- Simon & Stef -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephane.ducasse at inria.fr Fri Jan 29 20:11:11 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 29 Jan 2010 20:11:11 +0100 Subject: [Moose-dev] Re: Issue 28 fixed In-Reply-To: <9108D87F-C638-4B7D-8451-E7A2C4CAE30F@inria.fr> References: <9108D87F-C638-4B7D-8451-E7A2C4CAE30F@inria.fr> Message-ID: <85036B85-0723-41B8-BB81-4CD0E0E87370@inria.fr> Yeah we killed this bug.... :) It was somehow fun. Stef On Jan 29, 2010, at 6:50 PM, Simon Denier wrote: > Hi there > > Issue 28 is now closed. It was the last pending issue for 4.0 in Moose itself. Tests are green in Moose and we add another test for the case. So you should not notive any problem when running the importer. > > > -- > Simon & Stef > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Fri Jan 29 21:01:59 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Fri, 29 Jan 2010 21:01:59 +0100 Subject: [Moose-dev] Re: Issue 28 fixed In-Reply-To: <85036B85-0723-41B8-BB81-4CD0E0E87370@inria.fr> References: <9108D87F-C638-4B7D-8451-E7A2C4CAE30F@inria.fr> <85036B85-0723-41B8-BB81-4CD0E0E87370@inria.fr> Message-ID: <1D29ED61-2A2E-43BD-8F0B-1672861F149A@gmail.com> Nice :) Doru On 29 Jan 2010, at 20:11, St?phane Ducasse wrote: > Yeah we killed this bug.... :) > It was somehow fun. > > Stef > > On Jan 29, 2010, at 6:50 PM, Simon Denier wrote: > >> Hi there >> >> Issue 28 is now closed. It was the last pending issue for 4.0 in >> Moose itself. Tests are green in Moose and we add another test for >> the case. So you should not notive any problem when running the >> importer. >> >> >> -- >> Simon & Stef >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." From stephane.ducasse at inria.fr Fri Jan 29 21:12:40 2010 From: stephane.ducasse at inria.fr (=?iso-8859-1?Q?St=E9phane_Ducasse?=) Date: Fri, 29 Jan 2010 21:12:40 +0100 Subject: [Moose-dev] Re: Issue 28 fixed In-Reply-To: <1D29ED61-2A2E-43BD-8F0B-1672861F149A@gmail.com> References: <9108D87F-C638-4B7D-8451-E7A2C4CAE30F@inria.fr> <85036B85-0723-41B8-BB81-4CD0E0E87370@inria.fr> <1D29ED61-2A2E-43BD-8F0B-1672861F149A@gmail.com> Message-ID: <9621C67D-A397-423D-A684-6A45056B5E19@inria.fr> it was a problem due to metaclass merging and missing information in scope of the importer coupled with the fact that u do not want a double entity at the end :) Stef On Jan 29, 2010, at 9:01 PM, Tudor Girba wrote: > Nice :) > > Doru > > > On 29 Jan 2010, at 20:11, St?phane Ducasse wrote: > >> Yeah we killed this bug.... :) >> It was somehow fun. >> >> Stef >> >> On Jan 29, 2010, at 6:50 PM, Simon Denier wrote: >> >>> Hi there >>> >>> Issue 28 is now closed. It was the last pending issue for 4.0 in Moose itself. Tests are green in Moose and we add another test for the case. So you should not notive any problem when running the importer. >>> >>> >>> -- >>> Simon & Stef >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev From tudor.girba at gmail.com Sat Jan 30 00:33:50 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sat, 30 Jan 2010 00:33:50 +0100 Subject: [Moose-dev] testSorterLayer Message-ID: Hi Jannik, Sometimes the DSMMatrixTest>>testSorterLayer test is failing. Do you happen to have an idea why? Is it a problem of the code or is it actually a problem of the test? I am asking because it is the only test that crashes from time to time in the hudson builds :). Cheers, Doru -- www.tudorgirba.com "Being happy is a matter of choice." From tudor.girba at gmail.com Sun Jan 31 00:22:12 2010 From: tudor.girba at gmail.com (Tudor Girba) Date: Sun, 31 Jan 2010 00:22:12 +0100 Subject: [Moose-dev] Re: issue deleting a moose model In-Reply-To: <6140EB48-B93E-475D-AC29-FB86C5F21F53@gmail.com> References: <38E01583-6BA6-498E-9A62-B394A7202165@bergel.eu> <645E98E6-7F00-4026-846E-5837CA680B1E@iam.unibe.ch> <6140EB48-B93E-475D-AC29-FB86C5F21F53@gmail.com> Message-ID: <10DFEB11-3C72-4478-9DAA-55093F87EB01@gmail.com> Hi, It appeared that this was a critical issue. It took a bit of time to track it down, and Lukas patiently assisted me in the process :). The problem was a Glamour one and it was exhibited specifically in the case of the MoosePanel like this: Because MoosePanel registers for the announcements from MooseModel root, even if you close it, this instance of MoosePanel will still be referenced by the MooseModel root announcer. So, it does not get garbage collected. And if you opened already a model with this MoosePanel, this model will still be referenced by the Panel, and so it won't get collected. The current solution is that when the Glamour Morphic window is closed, the announcements are unregistered from all enclosed presentation. So, it means that in the case of MoosePanel, the garbage collector will do its job only after you close the MoosePanel. It's not nice, but it is the current solution. See http://code.google.com/p/moose-technology/issues/detail?id=314. I will keep it open for a while. Please let me know if you find more leakage. Cheers, Doru On 27 Jan 2010, at 00:23, Tudor Girba wrote: > Hi Fabrizio, > > You could probably reproduce this problem in a new smaller image as > well. No need to spend the time doing it on a very large one. > > Cheers, > Doru > > > On 26 Jan 2010, at 18:51, Fabrizio Perin wrote: > >> Hi, >> i tried to check the pointers to the model opening that menu. My >> machine start to work at 100% and after 3 hours i didn't have the >> list of pointers visualized yet. So i decide to kill the image. The >> system was surely into an infinite loop (or there were billions of >> links so i think that is useless know which they were). I will >> anyway try to let my machine work during the night just in the case >> that i'm wrong :) Meanwhile have you other suggestions? Thanks in >> advance. >> >> Cheers, >> >> Fabrizio >> >> >> On 26 Jan 2010, at 12:20, Alexandre Bergel wrote: >> >>> You can maybe check who is pointing to the model. There is a menu >>> in the inspector. >>> >>> Alexandre >>> >>> >>> On 26 Jan 2010, at 08:09, Fabrizio Perin wrote: >>> >>>> Hi, >>>> yesterday I tried to delete a moose model from my image using >>>> the function Utilities>>Delete on the moose panel. The model >>>> disappear from the list but saving the image it has the same >>>> size. Executing "MooseModel allInstances" I saw that the model >>>> was still there. I tried to close all windows and then i execute >>>> "Smalltalk garbageCollect" and again the saved image has the same >>>> size because the model has not been removed. >>>> >>>> I'm working on the pharo dev image 10508, Moose-Core 215 but i >>>> detect the same error in an older image: pharo dev image 10502, >>>> Moose-Core 208. >>>> >>>> Cheers, >>>> >>>> Fabrizio >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev at iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev at iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> Fabrizio Perin >> Institut fuer Mathematik und Informatik >> University Bern, IAM-SCG >> Neubrueckstrasse 10 >> CH-3012 Bern, Switzerland >> Tel: +41 31 631 33 13 >> FAX: +41 31 631 33 55 >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "In a world where everything is moving ever faster, > one might have better chances to win by moving slower." > > > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." From alexandre at bergel.eu Sun Jan 31 18:22:10 2010 From: alexandre at bergel.eu (Alexandre Bergel) Date: Sun, 31 Jan 2010 14:22:10 -0300 Subject: [Moose-dev] Re: Fwd: Building package cache In-Reply-To: References: Message-ID: ok, I see. Have you considered extending the class PackageInfo with these caches instead? Probably what would be tricky, is when to reset these caches. These could be done using the system change notification I imagine. Cheers, Alexandre On 29 Jan 2010, at 06:54, Simon Denier wrote: > > okaaay, wrong reply-to, retweet.... > > > Begin forwarded message: > >> From: Simon Denier >> Date: 28 janvier 2010 23:45:50 HNEC >> To: Simon Denier >> Subject: Re: [Moose-dev] Building package cache >> >> >> On 26 janv. 2010, at 22:03, Simon Denier wrote: >> >>> >>> On 26 janv. 2010, at 21:07, Alexandre Bergel wrote: >>> >>>> I do not have a solution, but this is really annoying. In >>>> addition to the time taken by loading Moose, it makes 10 minutes >>>> just to check what are are dependencies Mondrian has. >>>> >>> >>> Well, temporary solutions sometimes become less than temporary... >>> I fear this is the case. >>> >>> Maybe we can do something with an incremental, on-demand cache: >>> whenever a class or method is imported, we check whether the cache >>> has been built for it - if not, we built it. >> >> >> >> After playing a bit with the idea tonight, now I remember why I >> choose the global cache solution. So I explain how it works in the >> current system: >> >> To build the system cache, I go over all classes and all class >> extensions of PackageInfos and register their most specific package. >> Since I go over the whole system, I assume I know all class >> extensions in all classes. >> Now when I ask the package for a method, there are two cases: >> - either I can find it in the cache of class extensions and I >> return its package >> - either I can't find it, so I assume it is a normal method and >> retrieve the package of its class (from the cache). >> >> Now in an incremental cache system, I can cache a class when I >> import it, I can even cache a package so that its class extensions >> are imported, as above. The big problem is then that I can't assume >> that I know all class extensions within the class, because other >> packages (which I don't necessarily import) may do some. To do >> that, I should ask all methods within each imported class for its >> most specific package. This was more or less the situation we had >> before the cache, which brought the system to its knees on large >> projects. Perhaps I will try tomorrow but I don't have high hope. >> We need something better than that. >> >> >> -- >> Simon >> >> >> > > -- > Simon > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From abergel at dcc.uchile.cl Sun Jan 31 18:35:09 2010 From: abergel at dcc.uchile.cl (Alexandre Bergel) Date: Sun, 31 Jan 2010 14:35:09 -0300 Subject: [Moose-dev] Re: Small font in Mondrian In-Reply-To: References: Message-ID: <69193435-E5FB-46CE-A2F7-C1033C6B2B9A@dcc.uchile.cl> Ok, I will have a look at it once I am back from holidays, around Feb 17. Cheers, Alexandre On 29 Jan 2010, at 11:19, Laval Jannik wrote: > Hi Alex, > > Is it possible to int?grate small fonts in Mondrian. > Alain Plantec has made a package named 'DejaVue' published in > squeaksource. > > It would be great to integrate it in Mondrian. > > Cheers > > --- > Jannik Laval > --- > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. From jannik.laval at gmail.com Sun Jan 31 18:49:07 2010 From: jannik.laval at gmail.com (Laval Jannik) Date: Sun, 31 Jan 2010 18:49:07 +0100 Subject: [Moose-dev] Re: Small font in Mondrian In-Reply-To: <69193435-E5FB-46CE-A2F7-C1033C6B2B9A@dcc.uchile.cl> References: <69193435-E5FB-46CE-A2F7-C1033C6B2B9A@dcc.uchile.cl> Message-ID: Iep, the repository is: MCHttpRepository location: 'http://www.squeaksource.com/DejaVu' user: '' password: '' Cheer, Jannik On Jan 31, 2010, at 18:35 , Alexandre Bergel wrote: > Ok, I will have a look at it once I am back from holidays, around Feb 17. > > Cheers, > Alexandre > > On 29 Jan 2010, at 11:19, Laval Jannik wrote: > >> Hi Alex, >> >> Is it possible to int?grate small fonts in Mondrian. >> Alain Plantec has made a package named 'DejaVue' published in squeaksource. >> >> It would be great to integrate it in Mondrian. >> >> Cheers >> >> --- >> Jannik Laval >> --- >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev at iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev at iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---