Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7
New issue 777 by tudor.gi...(a)gmail.com: Pagination does not work for
ListingPresentation
http://code.google.com/p/moose-technology/issues/detail?id=777
When rendering a list with many items, specifying showOnly: does not have
any effect.
To reproduce the problem:
GLMFinder new
show: [:a |
a list display: [:x | 1 to: x ]; showOnly: 100 ];
openOn: 1000
Hi,
There is some code in moose (in FMDefaultCodeGenerator) which use
ORChangesBrowser but the class is not in the system. Was the class removed
in 1.4 or we do not load the proper package?
Cheers,
Fabrizio
can you send the mail to the moose-dev?
Because I'm busy.
Stef
On Feb 14, 2012, at 2:01 PM, Holger Hans Peter Freyther wrote:
> Hi Stephan,
>
> I took a break from my GSM work and wrap up my studies (German Diploma is
> gone, it ends up only being a Bachelor..). I tried to import Saros[1] into
> moose and ended up with Exceptions on parsing catch statements. I have
> attached a file that shows this issue and the backtrace is below:
>
>
> *** VerveineJ visitor got exception: 'fr.inria.verveine.core.gen.famix.Type
> cannot be cast to fr.inria.verveine.core.gen.famix.Class' while processing
> file:
> /home/ich/uni/bachelor-arbeit/dpp/de.fu_berlin.inf.dpp/src/de/fu_berlin/inf/dpp/Example.java
> java.lang.ClassCastException: fr.inria.verveine.core.gen.famix.Type cannot be
> cast to fr.inria.verveine.core.gen.famix.Class
> at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown Source)
> at org.eclipse.jdt.core.dom.CatchClause.accept0(CatchClause.java:162)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585)
> at org.eclipse.jdt.core.dom.TryStatement.accept0(TryStatement.java:258)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585)
> at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562)
> at org.eclipse.jdt.core.dom.IfStatement.accept0(IfStatement.java:190)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585)
> at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2562)
> at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585)
> at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2585)
> at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219)
> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2514)
> at fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(Unknown Source)
> at
> org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016)
> at
> org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628)
> at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:988)
> at fr.inria.verveine.extractor.java.VerveineJParser.parse(Unknown Source)
> at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown Source)
>
>
> I have attached a workaround but I don't understand under which circumstances
> a type might not be resolvable to a Class (wrong classpath). Somehow the code
> already accepts a nil class, so adding the exception handling only makes the
> code more ugly but might end up being correct.
>
>
>
> cheers
> holger
>
> PS: What is the license of that code?
>
>
>
>
>
> [1] http://www.saros-project.org/
> <Example.java><workaround.diff>
Hi,
I was implementing a new element as subclass of FAMIXEntity than I created
an association between these new elements as subclass of FAMIXAssociation.
By browsing these associations I was getting a weird error related to the
sourceAnchor method. Than I realized that FAMIXAssociation is subclass of
FAMIXSourceEntity and that implement the sourceAnchor method as
^self from sourceAnchor.
Now my point is:
FAMIXAssociation should be subclass of FAMIXEntity because FAMIXAssociation
should be a superclass for any association between entities not just source
entities. In this way we can also ride of the method
FAMIXAssociation>>>sourceAnchor which I found disturbing.
Anyway, in the comment of FAMIXAssociation it is written: "FAMIXAssociation
is an abstract superclass for relationships between Famix named entities".
So I would like to push FAMIXAssociation up and make it subclass of
FAMIXEntity.
If you disagree, it should be at least push down as subclass of
FAMIXNamedEntity.
What do you think?
Cheers,
Fabrizio
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-High Component-Glamour Milestone-4.7
New issue 776 by tudor.gi...(a)gmail.com: The Glamour Finder should scroll
properly
http://code.google.com/p/moose-technology/issues/detail?id=776
After the port to Pharo 1.4, the Finder does not scroll anymore. Use this
snippet to reproduce (and then click until you get 3 panes)
GLMFinder new
show: [:a | a list display: [:x | 1 to: x ]];
openOn: 100
Hi,
I saw that the method MooseBrowser>>codeWithFlawsBrowser refers to some of
the Identity Disharmonies proposed by Lanza and Marinescu in the book
"Object-Oriented Metrics in Practice". However, I couldn't find the method
to calculate if a class is for example a God Class or a BrainClass. Is this
code available somewhere?
Thanks
--
Santiago Vidal
Hi all,
I'm starting with Glamour, particularly I'm interested in the
GLMBasicExamples>>smalltalkCode example
My question is: is it possible to have access to variable bindings, in
order to show them, for instance, in an inspector?
Thanks in advance!
Nahuel
Great!
Martin
On Thu, Feb 16, 2012 at 5:42 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> Yuppee, problem solved!
>
> Thanks a lot.
>
> Cheers,
> Doru
>
> On Thu, Feb 16, 2012 at 6:07 AM, Martin Dias <tinchodias(a)gmail.com> wrote:
> > (At the moment Moose is loading from 'http://www.squeaksource.com/Fuel')
> >
> >
> > On Thu, Feb 16, 2012 at 2:05 AM, Martin Dias <tinchodias(a)gmail.com>
> wrote:
> >>
> >> I'm not sure if this solves the issue, but... Could you update the Fuel
> >> (and FuelMooseExtension) repository to 'http://ss3.gemstone.com/ss/Fuel'
> ?
> >>
> >> We have moved there.
> >>
> >> Martin
> >>
> >> On Wed, Feb 15, 2012 at 6:22 PM, Martin Dias <tinchodias(a)gmail.com>
> wrote:
> >>>
> >>> Hi Doru,
> >>>
> >>> I'll take a look now.
> >>>
> >>> Martin
> >>>
> >>>
> >>> On Wed, Feb 15, 2012 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com>
> >>> wrote:
> >>>>
> >>>> Hi Martin, hi Mariano,
> >>>>
> >>>> Loading FuelMooseExtensions 1.4 is broken because FuelContainer is no
> >>>> longer loaded.
> >>>>
> >>>> This is due to the fact that FuelContainer was taken out of the
> >>>> CoreWithExtras group from ConfigurationOfFuel 1.7.
> >>>>
> >>>> Could you take a look?
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>>
> >>>> --
> >>>> www.tudorgirba.com
> >>>>
> >>>> "Beauty is where we see it."
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
>