Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 840 by google....(a)ben.coman.com.au: ROCircle border only
http://code.google.com/p/moose-technology/issues/detail?id=840
Could you include in Roassal the ability to have a non-filled circle. See
attached.
Attachments:
ROCircle.1.cs 1.4 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 839 by google....(a)ben.coman.com.au: ROCenteredLabel
http://code.google.com/p/moose-technology/issues/detail?id=839
I required text to be centered within a circle, so I created
ROCenteredLabel. I think it would be generally useful. Would you consider
adding it to Roassal?
Attachments:
ROCenteredLabel-drawOnfor.st 1.0 KB
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 828 by google....(a)ben.coman.com.au: [Roassal] ROMorph>>mouseOver:
evt
http://code.google.com/p/moose-technology/issues/detail?id=828
Didn't bump into this as a runtime error, but browsing the code noticed
that ROMorph>>mouseOver:evt calls super>>mouseOver: which does not exist.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 825 by google....(a)ben.coman.com.au: Roassal extents of text does
not work with a tab character
http://code.google.com/p/moose-technology/issues/detail?id=825
Referring to the following line in ROMondrianExample>>labeledRectangleOn:
view node: ' With rectangle'.
if I use the <space> key to insert before the 'W', then the outside border
resizes fine. However if I use the <tab> key before the 'W', then the
border does not size properly and cuts over the text.
This is with ConfigurationOfRoassal.491.
Updates:
Labels: Component-Famix
Comment #2 on issue 810 by tu...(a)tudorgirba.com: Create virtual association
TypeDeclaration in MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=810
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 824 by google....(a)ben.coman.com.au: Roassal hover text should
disappear when dragging node
http://code.google.com/p/moose-technology/issues/detail?id=824
Taking for example ROMondrianExample >> labeledRectangle...
Hovering over a node shows a popup with the node text,
then moving away from the node makes the popup disappear - which is fine.
Hovering over a node shows a popup with the node text,
then dragging the node away doesn't close the popup - but I think it should.
Additionally, if you drag the node to the popup and leave it there, then
moving the mouse away does not close the popup either.
Moose47 - ConfigurationOfMondrian.485
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 823 by google....(a)ben.coman.com.au: buttons remains after
ROMondiranExample >> chooseLayout
http://code.google.com/p/moose-technology/issues/detail?id=823
From Roassal Easel > Example...
clicking "chooseLayout" then clicking "Example" doesn't cleanup the buttons
from "chooseLayout"
Moose47 - ConfigurationOfRoassal.485
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 817 by google....(a)ben.coman.com.au: Roassal overwriting window
borders
http://code.google.com/p/moose-technology/issues/detail?id=817
Referring to attached image, you can see on the right hand side the window
border is overwritten by graph. This occurs when the window is resized by
dragging the bottom right corner. This does not occur when the window is
large enough to fully encompass the graph and then inside the graph is
moved past the edge of the window.
This is with ConfigurationOfRoassal-AlexandreBergel.467 just going World >
Tools > Roassal Easel
Please fill in the labels with the following information:
* Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other
* Component-XXX
Attachments:
Roassal-overwriting-window-borders.png 67.8 KB
Updates:
Labels: Milestone-4.7
Comment #2 on issue 813 by tu...(a)tudorgirba.com: Java primitive type "int"
created as FamixType
http://code.google.com/p/moose-technology/issues/detail?id=813
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Updates:
Labels: Component-Famix Milestone-4.7
Comment #3 on issue 812 by tu...(a)tudorgirba.com: All FamixType are at
classScope in MooseChef
http://code.google.com/p/moose-technology/issues/detail?id=812
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-Famix
New issue 795 by andreho...(a)gmail.com: Metrics lcom2 and lcom3
http://code.google.com/p/moose-technology/issues/detail?id=795
Moose should have metrics such as lcom2 and lcom3.
Updates:
Labels: Milestone-4.7 Component-Famix
Comment #2 on issue 786 by tu...(a)tudorgirba.com:
MooseQueryResult>>intersection: is broken
http://code.google.com/p/moose-technology/issues/detail?id=786
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 784 by fabrizio...(a)gmail.com: opposite is missing in
FAMIXLacalVariable>>parentBehaviouralEntity
http://code.google.com/p/moose-technology/issues/detail?id=784
Hi,
I figured that parentBehaviouralEntity was implemented like that:
FAMIXLacalVariable>>parentBehaviouralEntity
<MSEProperty: #parentBehaviouralEntity type: #FAMIXBehaviouralEntity>
<MSEComment: 'Behavioural entity declaring this local variable.
belongsTo implementation'>
^parentBehaviouralEntity
The opposite is missing. Is there a reason for that?
Shouldn't it be like:
FAMIXLacalVariable>>parentBehaviouralEntity
<MSEProperty: #parentBehaviouralEntity type: #FAMIXBehaviouralEntity
opposite: #localVariables>
<MSEComment: 'Behavioural entity declaring this local variable.
belongsTo implementation'>
^parentBehaviouralEntity
Cheers,
Fabrizio
Status: New
Owner: tudor.gi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit
New issue 720 by tudor.gi...(a)gmail.com: Classic Coder should highlight the
extension categories
http://code.google.com/p/moose-technology/issues/detail?id=720
Currently, only classes and methods are shown as extensions using gray.
Categories should be grayed out as well.
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 637 by tu...(a)tudorgirba.com: VerveineJ should show an invocation
to the default constructor
http://code.google.com/p/moose-technology/issues/detail?id=637
A call to the default constructor should be modeled like:
- create a stub constructor in the target class
- create an invocation to the constructor
See the attached class for a sample.
Attachments:
DefaultConstructor.java 184 bytes
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 636 by tu...(a)tudorgirba.com: VerveineJ should set hasClassScope
http://code.google.com/p/moose-technology/issues/detail?id=636
Static fields or methods should be marked with hasClassScope=true:
public static int attributeWithClassScope;
public static void methodWithClassScope() {}
See the attached sample class.
Attachments:
ClassScope.java 179 bytes
Hi,
I just discussed with Lukas, and he agrees to move PetitParser under the Moose team in SmalltalkHub.
Who volunteers to do the moving? (I would like to do it myself, but the Glamour experience showed that it does not work from home)
Cheers,
Doru
--
www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair,
you will end up with a messy haircut."
Begin forwarded message:
From: Stéphane Ducasse <stephane.ducasse(a)inria.fr>
Subject: [Esug-list] Release of the Pharo consortium web site
Date: March 1, 2013 5:52:03 PM GMT+01:00
To: Association Pharo <association(a)pharo.org>, "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr>, A friendly place where any question about pharo is welcome <pharo-users(a)lists.gforge.inria.fr>, pharo-consortium(a)lists.gforge.inria.fr, ESUG Mailing list <esug-list(a)lists.esug.org>
Cc: Sylvain Karpf <sylvain.karpf(a)inria.fr>, David Simplot-Ryl <David.Simplot-Ryl(a)inria.fr>, Marie-Agnes Enard <marie-agnes.enard(a)inria.fr>
Hi guys
After some efforts, we are proud to announce the consortium around Pharo.
http://consortium.pharo.org
With such consortium, companies and academic partners will be able to collaborate and sustain the development of the Pharo environment and ecosystem. Today we announce the release of the beta version of the official consortium website.
Invest in your future, participate to the consortium!
Our goal is to be able to pay a couple of full-time engineers to build a bright future for everyone.
Thanks
Esteban for the effort,
lusy for the design, and
our first members:
Inria, VMWare, yesplan, 2denker, madEnvironment, BetaNine, Versus for their trust
We wish you a lot of business and success!
The Pharo Team
_______________________________________________
Esug-list mailing list
Esug-list(a)lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
I am going to work on creating a release version of Moose 4.7, because for
adapting Moose to pharo 2.0, we will start committing our changes/packages
to the new repo and we will not be able to load a 4.7 config.
I'll try to create a version with Stef's reloader and adapt it by hand, if
need be.
Stef, where can I find the latest version of the reloader?
usman
https://ci.inria.fr/moose/job/Moose-latest-dev-4.7-ST/
The build is red because RPackage is spawning lots of halt windows at the
end of load, otherwise it should be fine. Currently, its pointing to a
baseline but we will have to make it load a version with new adaptations
for Moose on pharo2.0.
usman
Hi,
I manually put together a one-click distribution. You can find it here:
https://dl.dropbox.com/u/18323746/Moose/moose-suite-4.7.zip
Please test it.
In the future, we need to rebuild the automatic job for creating the distributions. This should be a priority for 4.8.
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Hi,
Which would be the best way to model in FAMIX connections caused by
poolDictionaries?
For example:
ArrayedCollection subclass: #Text
instanceVariableNames: 'string runs'
classVariableNames: ''
poolDictionaries: 'TextConstants'
category: 'Collections-Text'
Text can access the class TextConstants becuse specified in its pool
dictionary. where should I store the information that TextConstants is in
the pool dictionary of Text?
Thanks and cheers,
Fabrizio
In the process of loading Moose on Pharo 2.0, we had to update the
ConfigurationOfPetitSQLParser to add Pharo 2.0
ConfigurationOfPetitSQLParser>>development: spec
<symbolicVersion: #development>
spec for: #'pharo1.3.x' version: '1.0-baseline'.
spec for: #'pharo1.4.x' version: '1.1-baseline'.
spec for: #'pharo2.x' version: '1.1-baseline'.
But I cannot commit the change ...
Other solution would be to change the config Of moose to not load the
developement version, but it's not the best solution
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)