- Moose-dev - INF Mailman

Re: Issue 506 in moose-technology: Toolbar should be rendered on the top right

by moose-technology＠googlecode.com

Updates: Summary: Toolbar should be rendered on the top right Comment #1 on issue 506 by tudor.gi...(a)gmail.com: Toolbar should be rendered on the top right http://code.google.com/p/moose-technology/issues/detail?id=506 (No comment was entered for this change.)

14 years, 5 months

1
3
0 0

Issue 511 in moose-technology: Listing presentations should populate the status port

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour New issue 511 by tudor.gi...(a)gmail.com: Listing presentations should populate the status port http://code.google.com/p/moose-technology/issues/detail?id=511 The status port is used for displaying information on the statusbar, but currently only the Mondrian presentation offers this information.

14 years, 5 months

1
0
0 0

follow moose

by Tudor Girba

Hi, If you want to follow Moose, you can do it via the following channels: - RSS feed: http://www.moosetechnology.org/news?view=PBEntriesRssView - Facebook: http://www.facebook.com/pages/moosetechnologyorg/152851281427491 - Twitter: http://twitter.com/moosetechnology Cheers, Doru -- www.tudorgirba.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

14 years, 5 months

1
0
0 0

Re: Issue 21 in moose-technology: Put author and timestamp in entity property

by moose-technology＠googlecode.com

Updates: Summary: Put author and timestamp in entity property Comment #10 on issue 21 by simon.de...(a)gmail.com: Put author and timestamp in entity property http://code.google.com/p/moose-technology/issues/detail?id=21 We quickly discussed that today, but I think it would be cool to add a switch in the importer telling whether or not we want to import such data - as well as a checkbox in the wizard. Should be easy enough. Also don't forget to meta-describe the properties (it would be cool if Fame could figure it does not need to save data which are nil)

14 years, 5 months

1
4
0 0

what is the status of FameDB

by Stéphane Ducasse

Hi guys in the past marco did a bridge to database for metadescribed but since famix was not regular we could not get famix models in databases. So I would be interested to know if there is an ongoing effort to do that? Because this would be a real plus for FameDescribed models. May be using Glorp and I was thinking that this would be good also to get all the source code of pharo in a db using Ring. And get Torch there too. Stef

14 years, 5 months

8
23
0 0

current development version is 4.3

by Tudor Girba

Hi, Just a note. We did not release a 4.2 based on Pharo 1.1.1 because we could not get the loading to work cleanly. So, we skipped 4.2 and we switched to 4.3 based on Pharo 1.2. I would focus on fixing the issues and then releasing in a couple of weeks. Here are the current open issues: http://code.google.com/p/moose-technology/issues/list?can=2&q=milestone=4.3 If you have other issues please mark them in the tracker. Cheers, Doru -- www.tudorgirba.com "Beauty is where we see it."

14 years, 5 months

2
2
0 0

Re: Issue 21 in moose-technology: Put author adn timestamp in entity property

by moose-technology＠googlecode.com

Updates: Labels: Component-VerveineJ Milestone-4.3 Comment #4 on issue 21 by jannik.l...(a)gmail.com: Put author adn timestamp in entity property http://code.google.com/p/moose-technology/issues/detail?id=21 (No comment was entered for this change.)

14 years, 5 months

1
5
0 0

Re: Issue 414 in moose-technology: Replace PackageOrganizerCache by RPackage

by moose-technology＠googlecode.com

Comment #3 on issue 414 by tudor.gi...(a)gmail.com: Replace PackageOrganizerCache by RPackage http://code.google.com/p/moose-technology/issues/detail?id=414 We should make the switch, especially given that in the future Pharo will adopt RPackage :)

14 years, 5 months

1
9
0 0

using deprecated methods in moosejee

by Tudor Girba

Hi Fabrizio, The MooseJEE fails now because I enabled the deprecation mechanism. It looks like you are using the method tag instead of name. If you want to replicate these issues, I suggest to: - download: http://hudson.moosetechnology.org/job/moosejee-latest-dev/ws/moosejee-tests… - file in the moosejee-tests.st file from the archive (this will run the tests like on the server) Cheers, Doru -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

14 years, 5 months

1
0
0 0

Re: Issue 48 in moose-technology: Smalltalk importer: fix stub

by moose-technology＠googlecode.com

Comment #5 on issue 48 by tudor.gi...(a)gmail.com: Smalltalk importer: fix stub http://code.google.com/p/moose-technology/issues/detail?id=48 I would say that we should close this issue. isStub has the meaning of "outside the scope of importing". We could add other flags if needed, but I would keep this one as it is. If no one will object, I will close the issue.

14 years, 5 months

1
2
0 0

Re: Issue 209 in moose-technology: Lazy presentations

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #2 on issue 209 by tudor.gi...(a)gmail.com: Lazy presentations http://code.google.com/p/moose-technology/issues/detail?id=209 (No comment was entered for this change.)

14 years, 5 months

1
0
0 0

Re: Issue 156 in moose-technology: Table widget for Glamour

by moose-technology＠googlecode.com

Updates: Labels: -Milestone-4.2 Comment #13 on issue 156 by tudor.gi...(a)gmail.com: Table widget for Glamour http://code.google.com/p/moose-technology/issues/detail?id=156 (No comment was entered for this change.)

14 years, 5 months

1
0
0 0

Re: Issue 141 in moose-technology: FAMIXUnknownVariable#container attribute is never set nor used

by moose-technology＠googlecode.com

Updates: Status: Invalid Cc: simon.denier tudor.girba Comment #6 on issue 141 by jannik.l...(a)gmail.com: FAMIXUnknownVariable#container attribute is never set nor used http://code.google.com/p/moose-technology/issues/detail?id=141 container does not exist anymore. There is a method belongsTo which return nil. We can close this issue.

14 years, 5 months

1
1
0 0

Issue 507 in moose-technology: Toolbar buttons should not accept keyboard navigation

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3 New issue 507 by tudor.gi...(a)gmail.com: Toolbar buttons should not accept keyboard navigation http://code.google.com/p/moose-technology/issues/detail?id=507 Currently, the buttons in the toolbar can be navigated to using tab. This is counter productive.

14 years, 5 months

1
1
0 0

Issue 506 in moose-technology: Window toolbar should be rendered on the top right

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3 New issue 506 by tudor.gi...(a)gmail.com: Window toolbar should be rendered on the top right http://code.google.com/p/moose-technology/issues/detail?id=506 Currently, the toolbar occupies an entire row below the title (either window or pane), even though it typically contains only a handful of icons. It should be displayed on the top right: - if it's in a window, it should be displayed on the top right of the window - if it's in a tab, it should be displayed on the same row as the tab group title - if it's not in a tab, then it should take the entire row, but still aligned to the right. This behavior is already offered by the Seaside rendering,

14 years, 5 months

1
0
0 0

meaningful commit comments

by Tudor Girba

Hi, I noticed that the latest commits in Mondrian are uncommented. Please use meaningful comments when committing. It significantly eases the tracking of what is happening in the various projects. Cheers, Doru -- www.tudorgirba.com "It's not what we do that matters most, it's how we do it."

14 years, 5 months

2
2
0 0

Issue 505 in moose-technology: The Smalltalk importer should not populate the default comment in FAMIXClass

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-SmalltalkImporter Milestone-4.3 New issue 505 by tudor.gi...(a)gmail.com: The Smalltalk importer should not populate the default comment in FAMIXClass http://code.google.com/p/moose-technology/issues/detail?id=505 The Smalltalk importer sets the comments to a FAMIXClass even if the comment is the default one. This is because asking ClassDescription>>comment returns the blank comment when empty.

14 years, 5 months

1
1
0 0

hudson

by Alexandre Bergel

I would love to see only green ticks :-) Maybe we can remove unnecessary projects? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 5 months

1
0
0 0

Fwd: MooseChef 1/4, a small DSL to query dependencies between famix entities

by Simon Denier

Begin forwarded message: > From: Simon Denier <simon.denier(a)gmail.com> > Date: 25 janvier 2011 23:58:09 HNEC > To: Simon Denier <simon.denier(a)gmail.com> > Subject: Re: MooseChef 1/4, a small DSL to query dependencies between famix entities > > OK, I just forgot the most important :) > To load the package > > Gofer new > squeaksource: 'Moose'; > package: 'MooseChef'; > package: 'Moose-Tests-Chef'; > load > > > On 25 janv. 2011, at 23:53, Simon Denier wrote: > >> MooseChef is a new package which provides a small DSL to query (some of the) dependencies between famix entities. It is a replacement for the current Moose Cook project, which provides 'navigation methods' between famix entities and resides in the Famix-Extensions package. >> >> Basically, MooseChef provides an API with a few methods to ask a method, a class, a package, a namespace for its dependencies (invocations, inheritance, references...) to other entities at various scope (class, package, namespace). Moose Chef comes as a small set of composable queries, with a well defined meaning, which is easy to browse and understand, and reused across Famix entities through traits. >> >> *** Source, side, and dependencies >> To start with, a query has a source (or receiver), that is the famix entity for which we require dependencies. Currently FamixMethod, FamixClass, FamixPackage, and FamixNamepace supports Chef queries. Relative to the source, a query has a side: it can be a query on either incoming or outgoing dependencies. Primitive queries returns a set of dependencies related to the source, that is instances of FamixAssociation: invocations, accesses, inheritances, references. >> >> *** Primitive queries to access dependencies as associations >> Hence, the combination of sides and dependencies define the set of primitive queries availble for any source. >> >> source query[Incoming|Outgoing][Invocations|SureInvocations|Accesses|References|Inheritances]. >> >> You can ask for example >> aFamixMethod queryIncomingInvocations >> but also >> aFamixClass queryIncomingInvocations >> aFamixPackage queryIncomingInvocations >> >> (Notice that a few queries do not make sense for some receiver, like for example asking a FamixMethod for its inheritances or it incoming references - in this case the convention is to return the neutral value, that is an empty collection). >> >> Some 'composite' queries are also defined on top: all dependencies, sure dependencies, >> static dependencies : accesses + references + inheritances >> sure dependencies : static + sure invocations >> all dependencies : static + invocations >> >> -- >> Simon Denier >> >> >> > > -- > Simon Denier > > > -- Simon Denier

14 years, 5 months

1
0
0 0

Fwd: MooseChef 2/4, querying objects and scaling

by Simon Denier

My bad, apparently I missent half of my messages Begin forwarded message: > From: Simon Denier <simon.denier(a)gmail.com> > Date: 25 janvier 2011 23:53:45 HNEC > Cc: Simon Denier <simon.denier(a)gmail.com> > Subject: MooseChef 2/4, querying objects and scaling > > Once a primitive query has been sent to a Famix entity, you can transform the query result with more refined queries. > > *** The other side of the dependencies > Primitive queries retrieve the associations. However, since we already know the source, we might be interested only by the objects on the other side of the dependency. Chef provides the #opposites selector to directly retrieve the other side of the association: that is the #from side of an incoming dependency, and the #to side of an outgoing dependency. > > For example: > aMethod queryIncomingInvocations opposites > retrieves the methods calling aMethod. > > aMethod queryOutgoingReferences opposites > retrieves the classes referenced by aMethod. > > Reminder: > - Inheritance: from Class to Class > - Access: from Method to Variable > - Invocation: from Method to Method > - Reference: from Method to Class > (Class extension: ???) > > > *** Scoping (or scaling) dependencies > Another interesting operation is to get the dependency information at a higher granularity by changing the scope. That is, one can ask for the dependencies coming from invocations as seen at the package level. This is querying for invoked or invoking packages. > > Three scope operators are available on query results: atClassScope, atPackageScope, atNamespaceScope > > aMethod queryOutgoingReferences atPackageScope > retrieves packages which contain classes referenced by the method. > > aPackage queryIncomingInvocations atClassScope > retrieves classes which 'call' the package. > > The scope operators exclude self loop by default (this was also the default in Moose Cook). That is, the query result will not contain the scope of the source (you will not get something like PackageX -> PackageX in the result) (the reason for this is that algorithms do not like graphs with self loops in general). However, this could be discussed and I could easily provide a default implementation with self loops included and a refined query #withoutSelfLoops > > > PS (mindnote) I might add some opposite operators to "scale down" results in some cases, like: > > aFamixPackage queryAllOugoingDependencies sourceClasses > retrieves classes from the packages which are involved in outgoing dependencies. Notice it returns the source, not the opposite side of the relationship. > > -- > Simon Denier > > > -- Simon Denier

14 years, 5 months

1
0
0 0

Issue 504 in moose-technology: Finder should be customized with the amount of fixed displayed panes

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Glamour Milestone-4.3 New issue 504 by tudor.gi...(a)gmail.com: Finder should be customized with the amount of fixed displayed panes http://code.google.com/p/moose-technology/issues/detail?id=504 GLMFinder should have a way to customize the amount of fixed panes displayed. For example, sometimes, it can be desirable to have one pane to fill the entire space at all time. Maybe something like: finder := GLMFinder new. finder fixedSize: 2.

14 years, 5 months

1
1
0 0

MooseChef 4/4, migration, tips and tricks

by Simon Denier

I believe MooseChef is now 100% functional, with a 95% complete API, and test coverage is good although not complete (I reused test classes from Moose Cook). I think that MooseChef should replace the navigation methods provided by MooseCook in Famix-Extensions - clean lots of stuff necessary for Moose Cook in Famix-extensions (that's a lot!) - maybe keep and rewrite a small set of some of the most generic queries of MooseCook with a MooseChef implementation (like clientClasses) to provide short names? - merge MooseChef into the Famix-extensions package? *** Tips and tricks - no test for queries on accesses right now - self loops excluded by the scoping operators, should not be? Provide a #excludeSelfLoops instead - be aware of the difference between querying a class and querying a package with respect to class extensions. By definition a class queries all its methods regardless of their package. A package will only query methods defined in itself, including class extensions to other packages, but not the one from other packages (that is only for invocations and accesses) - there is currently no relation between package and namespace? MooseChef was conceived with the intent to maximize reuse, exploit polymorphism so that the implementation is small, easy to browse, understand and debug. It is also quite verbose with long selectors so that reading the query would minimize all interpretation error. As a consequence, MooseChef is NOT: - an optimized library for querying (composing queries create at least one collection at each step) - a library with concise meaningful names What I recommend is to use MooseChef as a specification library: 1) prototype your queries with MooseChef 2) then code an optimized version (without all steps induced by the Chef dataflow, with cache...), give it a short but meaningful name (like in MooseCook) as a class extension for your application 3) test your code against the MooseChef specification (you could find bugs in your code, or in Moose Chef :)) *** Why a replacement for Moose Cook? Moose Cook was the early effort (principally by Hani) to provide a consistent API for navigation across multiple subclass of FamixEntity. As a consequence, we figure out a few choices which are outdated. - some method names ( *referenced*/*referencing* methods) are confusing as they were defined in Famix2, implies invocations, while Famix References have now been introduced in Famix 3 as first class citizens. - Moose Cook had to define many variants in each impacted class (basically one for each possible combination of the scope and filter queries above) - Moose Cook also introduced quite systematically a caching system for all queries All those points make it quite hard to understand and debug Moose Cook, as they are many methods, each defined for a specific case, which may or may not called other queries in cumulative steps. We frequently have to browse through multiple recursive calls in order to check that a query had the behavior we wanted. -- Simon Denier

14 years, 5 months

3
2
0 0

MooseChef 3/4, filtering results based on scope

by Simon Denier

*** Filtering dependencies The last common refinement is to filter some of the dependencies based on the scope. This is different from scaling in that we don't change the type of result objects, just select or reject some. aMethod queryOutgoingReferences opposites withinPackage: aPackage only retrieves referenced classes in the given package aPackage queryIncomingInvocations atClassScope outOfNamespace: aNamespace only retrieves invoked classes out of the given namespace This also works on primitive queries aMethod queryOutgoingReferences withinPackage: aPackage which retrieves FamixReferences instead of classes As for scope, there are 2x3 operators for filtering: #withinClass: #withinPackage: #withinNamespace #outOfClass: #outOfPackage: #outOfNamespace: For convenience, the following helpers are also defined: #withinMyClass #withinMyPackage #withinMyNamespace #outOfMyClass #outOfMyPackage #outOfMyNamespace aClass queryOutgoingInvocations atClassScope outOfMyPackage ---> invoked classes out of my package aMethod queryIncomingInvocations opposites withinMyClass ---> invoking methods in the same class -- Simon Denier

14 years, 5 months

1
0
0 0

MooseChef 1/4, a small DSL to query dependencies between famix entities

by Simon Denier

MooseChef is a new package which provides a small DSL to query (some of the) dependencies between famix entities. It is a replacement for the current Moose Cook project, which provides 'navigation methods' between famix entities and resides in the Famix-Extensions package. Basically, MooseChef provides an API with a few methods to ask a method, a class, a package, a namespace for its dependencies (invocations, inheritance, references...) to other entities at various scope (class, package, namespace). Moose Chef comes as a small set of composable queries, with a well defined meaning, which is easy to browse and understand, and reused across Famix entities through traits. *** Source, side, and dependencies To start with, a query has a source (or receiver), that is the famix entity for which we require dependencies. Currently FamixMethod, FamixClass, FamixPackage, and FamixNamepace supports Chef queries. Relative to the source, a query has a side: it can be a query on either incoming or outgoing dependencies. Primitive queries returns a set of dependencies related to the source, that is instances of FamixAssociation: invocations, accesses, inheritances, references. *** Primitive queries to access dependencies as associations Hence, the combination of sides and dependencies define the set of primitive queries availble for any source. source query[Incoming|Outgoing][Invocations|SureInvocations|Accesses|References|Inheritances]. You can ask for example aFamixMethod queryIncomingInvocations but also aFamixClass queryIncomingInvocations aFamixPackage queryIncomingInvocations (Notice that a few queries do not make sense for some receiver, like for example asking a FamixMethod for its inheritances or it incoming references - in this case the convention is to return the neutral value, that is an empty collection). Some 'composite' queries are also defined on top: all dependencies, sure dependencies, static dependencies : accesses + references + inheritances sure dependencies : static + sure invocations all dependencies : static + invocations -- Simon Denier

14 years, 5 months

1
0
0 0

by Alexandre Bergel

I added a tag Component-Spy Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

14 years, 5 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev