Comment #5 on issue 362 by alexandr...(a)gmail.com: Add commands to
create/delete Hismo models
http://code.google.com/p/moose-technology/issues/detail?id=362
In Moose-Hismo-AlexandreBergel.57 , you can now delete an hismomodel. We
need a way to create an hismo model
Hi,
The current way of setting the Roassal platform is rather clunky. For some
reason we have to pass a string:
ROPlatform setCurrent: 'athens'.
ROPlatform setCurrent: 'morphic'.
This string is then matched against a string returned by each subclass. The
platforms are stored in a dictionary that is updated in the initialize of
each subclasses. I think this is highly complicated for what it should do.
We should simply replace this with a mechanism that goes in this direction:
ROPlatform setCurrent: ROAthensPlatform new.
ROPlatform setCurrent: ROMorphicPlatform new.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Hi,
I am trying to find a way to obtain a bitmap programmatically with a
Roassal visualization. I try this:
| view |
view := ROMondrianViewBuilder new.
view nodes: (1 to: 10).
view raw bitmap
The problem is that the nodes are not yet laid out. As far as I remember,
this used to work.
How do I trigger the layouts easily?
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 923 by benjamin...(a)gmail.com: EyeSee red-square-of-death from
ESValueLabelDecorator>>chooseNonOverlappingValues
http://code.google.com/p/moose-technology/issues/detail?id=923
ESValueLabelDecorator>>chooseNonOverlappingValues has the line...
chosenValues add: (self values minValue: [:each | each value]).
but minValue: injects (Float infinity) so that if 'self values' is empty
then (Float infinity) is added to choseValues, which later are #rounded
causing an error in the Morph drawing and subsequent RSOD for the EyeSee
morph.
I am not sure if I've done something wrong that causes 'self values' to be
empty, but in any case, this should not kill the Morph.
Just for further information, here is the triggering code...
browser transmit from: #navigationtree; to: #attributes; andShow:
[ :a |
a eyesee
title: 'Optimize' ;
diagram:
[ :renderer :input |
renderer scatterplot
diagramTitle: '@', input absorbedLoad asString , 'kW' ;
x: #ratedOutput ;
y: [ :m | m powerLossForAbsorbedLoad: input absorbedLoad ] ;
valueAxis ;
addXDecorator: ESValueLabelDecorator new ;
models: (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1
ratedOutput < m2 ratedOutput ]).
].
where if in a Workspace I do...
models:= (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1
ratedOutput < m2 ratedOutput ])'.
models collect: [ :m | m ratedOutput -> m powerLossForAbsorbedLoad: 24
] explore
...then all the data looks okay.
--
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: ----
CC: chisvasi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit Milestone-5.0
New issue 1009 by tu...(a)tudorgirba.com: GTInspector does not accept code on
CMD+s
http://code.google.com/p/moose-technology/issues/detail?id=1009
When editing code, pressing CMD+s does not trigger the accept. You have to
press on the check icon to do it.
--
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: ----
CC: alexandr...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Roassal Milestone-5.0
New issue 995 by tu...(a)tudorgirba.com: Roassal does not export the full PNG
http://code.google.com/p/moose-technology/issues/detail?id=995
Try this:
view node: 1.
view node: 2.
view horizontalLineLayout horizontalGap: 2000
And the export. If your window is less than 2000 pixels wide, you will not
see the second node.
--
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
Hi,
As you probably noticed, I am going through all open issues and cleaning
them. My goal would be to keep the tracker to less than 100 items. This
means that we have to get rid of old issues that are of no interests or
that can be fixed fast so that we can notice and treat the new ones faster.
Any help in this direction would be greatly appreciated.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-DSM
New issue 666 by jannik.l...(a)gmail.com: package name in DSM
http://code.google.com/p/moose-technology/issues/detail?id=666
The package name in DSM, specially in encaps DSM are not well placed.
Status: Accepted
Owner: ----
CC: cy.delau...(a)gmail.com
Labels: Type-Defect Priority-Medium RPackage
New issue 621 by stephane...(a)gmail.com: writing tests for removeMethod
http://code.google.com/p/moose-technology/issues/detail?id=621
writing tests for
"The bug appeared when removing two extensions methods (from the same
extending package) for a
same class. in RPackage >> removeMethod: , when removing an extension
method, we were telling the
organizer to remove the extending package for the class concerned. This
was wrong, because even if one
extension from this package has been removed, some others can still exist.
And the organizer should keep
the this package as extending package for the class. So removing the first
extension method worked
correctly, but then removing a second or more methods from the same
package was raising some errors "
Status: New
Owner: ----
Labels: Type-Enhancement Priority-Medium Component-MooseCore Milestone-4.3
New issue 527 by tudor.gi...(a)gmail.com: Add ModelInfo to hold extra
information in MSE
http://code.google.com/p/moose-technology/issues/detail?id=527
We should add a special MooseModelInfo entity that can be serialized in
MSE. Like this we would have a backward compatible solution for storing
extra information in MSE such as:
- source language
- importer version
- metamodel version
- importing date
- source version
I will give it a try for 4.3
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 771 by santiago...(a)gmail.com: Problem with tabs in Glamour
http://code.google.com/p/moose-technology/issues/detail?id=771
Running the following script:
| browser |
browser := GLMTabulator new.
browser
row: [ :r | r column: #columnA; column: #columnB ].
browser transmit to: #columnA; andShow: [ :a |
a list display: [" :model | "#('Value 1' 'Value 2' 'Value 3' 'Value 1') ]
].
browser transmit from: #columnA; to: #columnB; andShow: [ :a |
a list titleIcon: GLMUIThemeExtraIcons glamorousBrowse; display:#('data
A' 'data B' 'data C').
a text titleIcon: GLMUIThemeExtraIcons glamorousAccept;
display:'something'.
a text titleIcon: GLMUIThemeExtraIcons glamorousAdd; display:'add
something'.
].
browser openOn: MooseModel root allModels anyOne.
after selecting a value in columnA the columnB is opened in the last tab
(the one with the glamorousAdd icon). Instead it must be opened in the
first tab (the one with the glamorousBrowse icon).
Using text instead of icons, it works.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 940 by w...(a)fastmail.fm: In Pharo 2.0 the SpyWizard does not take
notice of newly added packages. Possible solution: use RPackageOrganizer
http://code.google.com/p/moose-technology/issues/detail?id=940
Describe the problem: what do you get? what do you expect?
In Pharo 2.0 the SpyWizard does not take notice of newly added packages.
How to reproduce the problem: step by step if necessary
- load Spy into Pharo 2.0
- open for example the HapaoWizard and have a look at the packages
available. Close the wizard.
- add a new package to your image
- open the HapaoWizard again: the new package does not appear in the list
of available packages.
Possible solution:
Change
SpyWizard>>packagesList
^ (PackageOrganizer default packageNames select: #isString)
asSortedCollection: [ :a :b | a < b ]
to:
SpyWizard>>packagesList
^ (RPackageOrganizer default packageNames select: #isString)
asSortedCollection: [ :a :b | a < b ]
or perhaps:
SpyWizard>>packagesList
^ (SystemNavigation default packageOrganizerClass default packageNames
select: #isString) asSortedCollection: [ :a :b | a < b ]
--
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 Milestone-5.0
New issue 1010 by tu...(a)tudorgirba.com: FAMIX should provide a
FAMIXTypeGroup
http://code.google.com/p/moose-technology/issues/detail?id=1010
Right now, we have only FAMIXClassGroup. So, at the moment, we cannot deal
with a group that contains both a FAMIXClass and a ParameterizedType.
We need a FAMIXTypeGroup that will be the superclass of FAMIXClassGroup.
This also implies that we should change the way the group type is inferred
to take into account the common superclass.
--
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
It is currently ad-hoc since we use a bitmap for the map, and locate cities with distances in pixels.
We have found description in SVG and found a couple of formulas to map longitude and latitude into pixels. So we will have something vectorial very soon.
If someone has some ideas, data, examples the we will be very happy to take them as challenges!
Alexandre
> Le 15-11-2013 à 18:39, Sven Van Caekenberghe <sven(a)stfx.eu> a écrit :
>
> Very nice, Alex, I guess you are using shape files then ?
>
> Sven
>
>> On 15 Nov 2013, at 20:56, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
>>
>> Hi!
>>
>> During our pair coding session on Friday, we worked on a new builder for Roassal.
>>
>> Here is short example:
>>
>>
>> | builder |
>> builder := ROFranceMapBuilder new.
>> builder shape circle size: 15; color: Color red; withLabel.
>> builder showCities: #('Paris' 'Lyon' 'Marseille').
>>
>> builder shape circle size: 25; color: Color blue; withLabel.
>> builder show: 'Nice'.
>>
>> builder open
>>
>> It should produce:
>> <Screen Shot 2013-11-15 at 4.53.30 PM.png>
>>
>>
>> There is no reference to external files. It runs out of the box.
>>
>> In case you got a sudden need to press a like button or do some retweet, here a bit of material:
>>
>> https://www.facebook.com/media/set/?set=a.543459092407359.1073741830.340543…
>> https://twitter.com/objectprofile/status/401433558684008448
>>
>> On our facebook account we have many more screenshots.
>>
>> Cheers,
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
Status: New
Owner: ----
CC: chisvasi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit Milestone-5.0
New issue 1008 by tu...(a)tudorgirba.com: GTDebugger should offer the
possibility of browsing the selected method
http://code.google.com/p/moose-technology/issues/detail?id=1008
Ideally, it should appear in the source pane as an icon.
--
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: ----
CC: chisvasi...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit Milestone-5.0
New issue 1007 by tu...(a)tudorgirba.com: GTDebugger should bound self to the
current object, not to context
http://code.google.com/p/moose-technology/issues/detail?id=1007
Right now, in the first pane of the inspector, self is bound to the
context. It should be bound to the current object
--
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 Component-Orion
New issue 1000 by anne.et...(a)gmail.com: Orion: retrieve entity from name,
mooseName or signature
http://code.google.com/p/moose-technology/issues/detail?id=1000
Describe the problem: what do you get? what do you expect?
A class is retrieve from its mooseName. A method is retrieve from its
signature. And sometimes, entities are retrieve from their name.
The problem comes perhaps from the creation of the entity (it is possible
but has not be checked that the converter create the entity with their name
= mooseName or signature for method, but the one that are created by
actions use a String so not the mooseName neither the signature).
Please fill in the labels with the following information:
* Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other
* Component-XXX
--
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-GlamorousToolkit
New issue 1006 by tu...(a)tudorgirba.com: GTInspector should offer completion
in the method browser based on the type of the instance
http://code.google.com/p/moose-technology/issues/detail?id=1006
When in the methods presentation, self is already bound to the current
object. Thus, the type is known. Thus, we should be able to have completion
that uses this information.
--
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
Hi,
The latest Moose image comes with GTInspector and GTDebugger installed as
default tools. GTDebugger is the result of the excellent work of Andrei. At
the moment, the GTDebugger only replicates the behavior of the default
debugger. The custom debuggers will follow soon. Both of these are part of
the GToolkit.
Just for reference:
- GT-Debugger has 499 lines of code.
- GT-Inspector has 484 lines of code.
In other words, you could read the full code in the lunch break :).
Here is a screenshot showing them:
https://www.dropbox.com/s/hzxg82nzz163gb1/2013-11-15%2019.20.42%20-%20gtdeb…
If you see issues, please report them.
Cheers,
Doru
p.s. Unfortunately, we could not install the GTInspector alone in the Pharo
image because the SpecDebugger still depends on the inspector being
implemented in Spec.
--
www.tudorgirba.com
"Every thing has its own flow"
Hi!
During our pair coding session on Friday, we worked on a new builder for Roassal.
Here is short example:
| builder |
builder := ROFranceMapBuilder new.
builder shape circle size: 15; color: Color red; withLabel.
builder showCities: #('Paris' 'Lyon' 'Marseille').
builder shape circle size: 25; color: Color blue; withLabel.
builder show: 'Nice'.
builder open
It should produce:
There is no reference to external files. It runs out of the box.
In case you got a sudden need to press a like button or do some retweet, here a bit of material:
https://www.facebook.com/media/set/?set=a.543459092407359.1073741830.340543…https://twitter.com/objectprofile/status/401433558684008448
On our facebook account we have many more screenshots.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
I have the impression that moose releases are not very much used. I agree that our development process works great (a lot of progress), and that because of this most people working on or with moose use the development version and ignore the release version. At the moment how ever, I still use a pharo 2.0 based image and cannot take the latest development version (as this is pharo 3.0 based and moose 4.9 is frozen). So I tried to revert to using the releases. And there I ran into problems. Both release 4.8 and 4.9 don't work for me.
- release 4.8 has a outdated grease version that causes the image to become unstable when you load something that uses grease. This is almost anything, so you can only use the image "as is"
- the moose panel of release 4.9 needs to be closed and reopened. Loading PetitDelphi in this image causes several packages to be imported that only work in pharo 3.0.
Note also that this is a barrier for new users.
I tried to start the discussion on the moose list before how to improve this, but I got very little response.
Note that these problems are easy to fix, but these fixes should be back ported to the release. At the moment I have no idea how I should do this, as the release is made with a snapshot, and that is hard to change. Snapshots work great to freeze, but are hard to maintain.
PetitDelphi has a configuration that refers to PetitParser (development).
PetitParser has a (loaded) configuration that refers to Glamour (development).
Glamour has a (loaded) configuration. As the development version (also for pharo 2.0) refers to the latest version of the packages that only work in pharo 3.0.
In PetitDelphi I do not want to change the version of PetitParser to the snapshot version, as here the groups not defined, and PetitDelphi only needs a part of PetitParser. So snapshotting the release, forces me to snapshot my configuration of PetitDelphi, and no longer use the configuration of PetitParser. I do not think that this is a good thing, that all projects depending on moose, should create a snapshot when moose is released. Note that this snapshot has to be made before other changes are made! Also continuing the development process on PetitDelphi would no longer work, as it uses a snapshot.
I have the feeling that a snapshot really should not be related to a release and should be considered (and modeled as) a separate concept. Because the responsibility for snapshotting is that of the using project, not the owning project.
In metaceller I made the possible to record the current loaded versions of a configuration, where it used the configuration. Meaning: of packages and used configurations in the configuration, the version is recorded (symbolic versions are replaced). I showed it to Doru and I could not convince him to use this.
I am willing to put time and effort into the moose releases to improve them, but then I want to know what you think about this.
Diego
Status: New
Owner: ----
CC: chisvasi...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-GlamorousToolkit
Milestone-5.0
New issue 1005 by tu...(a)tudorgirba.com: GTInspector should become the main
inspector
http://code.google.com/p/moose-technology/issues/detail?id=1005
Right now, we cannot install the GTInspector because the SpecDebugger from
Pharo 3.0 depends on the inspector being implemented in Spec.
The issue is reported on the Pharo tracker:
https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir…
--
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
I tried again, but from iam email account.
Cheers.
Gabi
---------- Forwarded message ----------
> From: "Gabriela Arevalo (gmail)" <gabriela.b.arevalo(a)gmail.com>
> To: Moose-related development <moose-dev(a)iam.unibe.ch>
> Cc:
> Date: Thu, 14 Nov 2013 15:00:24 -0200
> Subject: CAnalyzer or inFamix?
> Hi guys,
>
> I need to import some C code into Moose (image you can download from the
> website of Moose (http://www.moosetechnology.org/)
>
> I was checking the different tools we could find in Pharo, and there are
> two tools:
>
> - CAnalyzer, and
> - inFamix
>
> I loaded CAnalyzer in an image with Moose included in Pharo 3.0, and now
> it seems that I should get the C code in an XML format using srcML.
>
> What is the active tool you guys suggest to use? I did not try yet with
> inFamix.
>
> Cheers,
>
> Gabi -again trying to code :)
>
>
--
www.tudorgirba.com
"Every thing has its own flow"
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 999 by anne.et...(a)gmail.com: VerveineJ: management of the
anonymous class
http://code.google.com/p/moose-technology/issues/detail?id=999
Describe the problem: what do you get? what do you expect?
According to the definition of
FAMIXType >>isAnonymousClass
^ self container isMethod or: [
self name isAllDigits or: [
'*_anonymous_*' match: self name ]]
But VerveineJ does not follow the same pattern to name the anonymous
classes. Currently, there is no _ in the name of the anonymous class. So if
the container of the anonymous class is not a method, it won't be
recognized as such.
Please fill in the labels with the following information:
* Type-Defect, Type-Enhancement, Type-Engineering, Type-Review, Type-Other
* Component-XXX
--
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