Hi!
I have MSE files generated by VerveineJ. Can I setup somehow what I want to import into the image? For example exclude invocations, or import just classes and methods, etc.?
Thank you,
Jura
Hi all,
We found some time to continue our work on the Delphi parser that builds a moose model from it. Since Delphi is hybrid OOP and structured, this means it has functions …. and I would like to be able to browse them.
When I try to browse a function in the Moose Panel I got the error that it cannot calculate the incoming invocations. I found that this is implemented in a trait, but at the level of methods, but since functions can be called also I moved the trait up in the hierarchy. The tests of FAMIX all run, so I assume this is no problem.
Cheers,
Diego
Hello guys,
Just updated in Moose a Wizard to easily load Hismo models from a
collection of Moose models related to a system history (issue 974)
To use it, go to Moose Panel and click in "Import Hismo model from MSE
files".
In the Wizard you can also:
- Filter the entities to be loaded in you Hismo model (for example, load
just methods)
- Select a strategy to load the models, for example: load the one model
per month, load one model each 20 days, etc (for that case, your mse files
should include a date in its name)
regards,
--
Andre Hora
Status: New
Owner: andreho...(a)gmail.com
Labels: Type-Enhancement Priority-Medium Component-MooseCore Milestone-4.8
New issue 974 by andreho...(a)gmail.com: Improve Hismo importer
http://code.google.com/p/moose-technology/issues/detail?id=974
We should have a wizard to load Hismo models.
Also, for the case we have several Moose models of a system history:
- We should have strategies about how to select the Moose models to be
loaded;
- Ex: load the one model per month, load one model each 20 days, etc
--
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 Doru and all,
Your recently announced dynamic features of Glamour might be handy for a
browser I am trying to build. My example code below contains a couple of
buttons. When clicked, a list or tree should appear, and be populated
(with the contents of the selection from user), below the button.
Please evaluate the following code:
| browser |
browser := GLMTabulator new.
browser
column: [: a | a row: #inputdata;
row: #dictionary;
row: #territories ];
column: [: a | a row: [ :r | r column: #start; column: #end ] span: 10;
row: #info span: 3;
row: #actions ]
span: 6.
browser transmit to: #inputdata; andShow: [ : a |
a title: 'Input Data'.
a actionList
act: [: entity | (UIManager default chooseDirectory: 'Select
directory' from: FileSystem root) ifNotNilDo: [: dir | self halt ] ]
entitled: 'Load...' ].
browser transmit to: #dictionary; andShow: [ : a |
a list title: 'Data Dictionary' ].
browser transmit to: #territories; andShow: [ : a |
a title: 'Territory Data'.
a actionList
act: [: entity | (UIManager default chooseFileMatching: #('*.txt')
label: 'Choose a TXT') ifNotNilDo: [: file | self halt ] ]
entitled: 'Load...'].
browser transmit to: #info; andShow: [:a |
a text display: [ : x | 'Select input data' ]; title: 'Log' ].
browser
title: 'My Browser';
openOn: (1 to: 10).
It seems I have two issues here:
- How to tell Glamour: "Create a list below this button".
- How to populate the list with new contents
Do you have any suggestions?
Cheers,
Hernán
Hi,
Here is a little announcement for those that like Glamour.
Andrei and I worked on making Glamour more dynamic by pushing the
presentation definition at execution, rather than at browser construction
time.
To achieve dynamic presentation creation, before you needed to use the
GLMDymamicPresentation. For example, the MooseFinder was built like:
MooseFinder>>compose
self finder show: [ :a |
a dynamic
display: [:each |
| dynamic |
dynamic := GLMCompositePresentation new.
each mooseInterestingEntity mooseFinderPresentationsIn: dynamic.
dynamic ] ].
Now, the same code becomes:
MooseFinder>>compose
self finder show: [ :a :each |
each mooseInterestingEntity mooseFinderPresentationsIn: a ].
You can see more details here:
http://www.humane-assessment.com/blog/building-dynamic-browsers-with-glamour
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
Ok just be prepared to have problem with squeaksource and its way to handle files.
As a general policy I think that Moose should not rely on external servers. So may be we should clone
OSProcess and copy your changes from time to time.
Stef
On Aug 25, 2013, at 5:55 PM, David T. Lewis <lewis(a)mail.msen.com> wrote:
> On Wed, Aug 21, 2013 at 02:12:23PM -0400, David T. Lewis wrote:
>> On Wed, Aug 21, 2013 at 05:30:44PM +0200, St?phane Ducasse wrote:
>>> Hi dave
>>>
>>> Moose needs OSProcess and squeaksource is unstable so I will move OSProcess (except if you want to do it) because
>>> we should get our build stable and I should losing teim trying to build moose.
>>>
>>> So let me know.
>>
>> Hi Stef,
>>
>> I will move OSProcess to another server by this weekend at the latest. I
>> will move CommandShell also, because I think that you are using PipeableOSProcess
>> in the ConfigurationOfOSProcess, and that is in the CommandShell package.
>> I'll check the configuration to be sure.
>>
>> Dave
>
> Hi Stef,
>
> I am now working with the SCG support team for SqueakSource to move the
> SqueakSource service to another server to maintain continued operation.
> The Squeak board is supporting this and should be able to provide the
> server (although I do not have access to this yet). I hope to be able
> to do this without any changes to URLs or Metacello configurations.
>
> For now the existing SqueakSource will stay on line at least for a little
> longer, and I am putting my attention into making the transition happen.
> If it does not work out for some reason, I will move the OSProcess
> repository at that time.
>
> Dave
>
Hi
An idea to improve roassal scalability was to split the collection
elements belonging to ROContainers and builder, into two different
collections : edges and nodes.
It would permit not to unset shape after we add new edges or nodes, and
it would save little time when asking for elementsNotEdges.
But after a little trial, it seems that it will ask a huge refactor of
roassal to see a real gain in time, with just splitting the collection
it gets worse.
For example, each time we need both nodes and edges in the same
collection we have to concatenate the new collections and it's time
consuming.
Always working with Object withAllSubclasses as benchmark, we spend 28
second in copyReplaceFrom:to:with ( concatenation ).
And it brings us from 69 sec to 136 sec... A beautiful loss of 67
seconds...
The idea came when using rawEdgesFrom:to: was long, in fact it used to
call elementsNotEdges for each iteration, then in our case a little more
than 11000 times, and that was long, but now, as we don't call it so
often it is quick enough.
That was maybe not that a good idea to split the collection.
Tell me what you think.
Regards
Mathieu