Hi guys
I do not like the configurationOfXMLSupport because it introduces references to project using XML
and I think that it makes little sense and leads to more complex configuration.
I ported XMLWriter to SmalltalkHub and now I'm considering creating XMLParser with the parsing aspects of XMLSupport.
I do not want to manage SIXX, Pastell: they should have their own projects and configurations!
I could create a project, configuration… for Pastell for example.
Do you know know what Moose really needs?
Stef
---------- Forwarded message ----------
From: Marcus Denker <marcus.denker(a)inria.fr>
Date: Mon, Feb 25, 2013 at 10:41 AM
Subject: [Pharo-users] [JOB][Research] 16 month Postdoc "Architectural
Design Exploration"
To: "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>
Cc: The general-purpose Squeak developers list <
squeak-dev(a)lists.squeakfoundation.org>
Architectural Design Exploration
================================
About Inria and the job
-----------------------
Inria, with its academic, institutional and industrial partners, is
commited to major research and
innovation projects in the field of computational sciences. The institute
disseminates across France
thanks to its eight research centres.
The Inria Lille - Nord Europe research centre, inaugurated in 2008, employs
357 people, including 250
scientists, in its seventeen research teams. Recognised for its significant
contribution to the social
and economic development of the Nord - Pas-de-Calais region, the Inria
Lille - Nord Europe research
centre promotes a policy of close cooperation with major businesses and
small enterprises. By encouraging
synergies between researchers and industrial partners, Inria contributes to
the transfer of skills and
expertise in computational technologies and provides access to top-level
European and international
research in order to support innovation and businesses, particularly in the
region of Lille.
Whether designing innovative software for business or logistics, modelling
living cells or fusion
plasma, or developing medical simulators or interfaces to facilitate
human-computer interaction,
our research opens up new possibilities that can revolutionise common
practice and contribute to
a better understanding of the natural phenomena which surround us.
The postdoc is hosted by Team-Project RMoD. The goal of RMoD is to support
remodularization of
object-oriented applications. This objective is tackled from two
complementary perspectives:
reengineering and modularity constructs for programming languages.
In the reengineering perspective we will propose new analyses to understand
and restructure
existing large applications (specialized package metrics, adapted
visualizations, layer
identification) on top of Moose [Duca08a], [Bhat12b].
http://rmod.lille.inria.fr/web/
Mission
--------
Changes in the architecture may occur during the entire lifecycle of a
system. Some of them might
only affect local parts of a system, while others have more systemic
impact. In general, we
distinguish three types of approaches for handling change systematically,
listed in an order
of increasing severity:
- Refactoring. They correspond to improvements and concern only certain
components and connectors.
They do not alter the offered functionality of the system.
- Renovating. Sometimes, parts of the architecture are in such a bad
condition that refactoring
cannot work anymore. In such contexts, renovating the architecture – by
restoring its fundamental
principles or refreshing essential components – may be the better choice.
Renovating also deals with
only parts of the system.
- Re-architecting. When an architecture is subject to significant changes,
refactoring or renovating may
not suffice. This might be the case if for example the technology platform
is to be replaced by a new one,
if there is a large change in business scope, or if the architecture is in
such a bad shape that errors
keep emerging. In such cases, re-architecting is required. The
re-architecting process usually analyzes
the existing architecture (e.g., using a SWOT analysis) and results in a
new architecture by: a) reusing
those components worthwhile to keep, b) modifying some of the existing
components (refactoring) and c)
re-building the rest of the components (renovating).[Ieee13]
Because software engineers do not have a full understanding of the complete
source code, each kind of
changes may solve some problems (e.g. reduce some cycle between package),
while creating new problems
(e.g. creating new cycles). In this situation it would be profitable to
have a tool that allows to test a
possible new configuration (refactored, renovated or re-architectured) of
the source code to see if the
abstract property one wishes to improve, first actually improved, and
second, did not improve at the
expense of another equally important one. For this several alternatives new
configurations have to be
considered. In the RMoD team, we developed Orion [Lava10b], a tool that
uses models as abstract
representations of the program and enables the definition of several
possible alternative versions of
this program. Each version differentiates from the others by a set of
refactoring operations. Currently,
once an adequate version is selected, the user has to manually perform the
operations on the code.
Job offer description
----------------------
In this postdoc, we would like to enhance Orion in order to automatically
generate code or modify the
existing one once a version is chosen. Thus, it would be possible to study
various alternatives of
possible refactoring or restructuring of an existing program, using metrics
[Abde12a], [Mord12b] or some
other means [Hema12] to check the improvement in the "quality" of the code,
and then ask the tool to
perform the changes of the selected final solution onto the source code.
The used metamodel enables a
representation where code details are abstracted. A new metamodel for
example AST metamodel, representing
code will be introduced and the links between the two models will have to
be maintained.
Skills and profile
--------------------
The candidate should :
- hold a PhD degree in Computer Science
- be fluent in English (French is an advantage but not required)
- be knowledgeable in the domains of Software Engineering, maintenance,
code analysis
- have good programming skills in Smalltalk or be able to acquire them in a
short amount of time
Benefits
---------
- Possibility of French courses
- Help for housing
- Participation for transportation
- Scientific Resident card and help for husband/wife visa
Additional information
-----------------------
- Duration : 16 months
- Salary: 2 620,84 € gross/month
- Monthly salary after taxes : around 2 138€ (medical insurance included).
- Before applying, please contact the scientist advisor:
nicolas.anquetil(a)inria.fr
- For the first selections, please apply before March 2013, 22nd
Security and defense procedure
-------------------------------
In the interests of protecting its scientific and technological assets,
Inria is a restricted-access
establishment. Consequently, it follows special regulations for welcoming
any person who wishes to work
with the institute. The final acceptance of each candidate thus depends on
applying this security and
defense procedure.
More information:
http://rmod.lille.inria.fr/web/pier/blog/2013-02-22-2
--
www.tudorgirba.com
"Every thing has its own flow"
Hi!
What Carrack is about? I guess it is related to Moose, but http://www.squeaksource.com/Carrack.html does not say much...
The abstract of Fabrizo says it is an inferencer for dependencies. Maybe a short explanation, and even better, a very short example in the squeaksource and the moose website would be great...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
tests are red :-)
(not that much because we only took Moose-Ttests*)
1005 run, 969 passes, 0 skipped, 1 expected failures, 13 failures, 22
errors, 0 unexpected passes
nicolas
--
Nicolas Anquetil -- RMod research team (Inria)
I moved glamour to STHub
- config updated to create a baseline for pharo1.4 pointing to STHub for as
many packages as possible (roassal, Metacello, BDD is still in SS)
- loaded the baseline in 1.4 pharo...all tests green...
- created a baseline for pharo 2.0...loaded in 2.0 and ran tests, here are
the results:
357 run, 246 passes, 0 skipped, 12 expected failures, 0 failures, 99
errors, 0 unexpected passes
- I wanted to define #stable and #development but since these are already
defined with specific version info, I didn't modify these.
Doru, can you have look for the definition of symbolic versions?
I thought that we had something like that in Moose.
Begin forwarded message:
> From: Serge Stinckwich <serge.stinckwich(a)gmail.com>
> Subject: [Pharo-project] Time Series in Smalltalk
> Date: February 20, 2013 10:28:10 PM GMT+01:00
> To: Pharo Development <pharo-project(a)lists.gforge.inria.fr>
> Reply-To: Pharo-project(a)lists.gforge.inria.fr
>
> Hi all,
>
> I'm looking for a time series library available in Smalltalk.
> Something like Python Time Series Analysis : http://pytseries.sourceforge.net/
> or
> Pandas: http://pandas.pydata.org/
>
> Thank you.
> Regards,
> --
> Serge Stinckwich
> UCBN & UMI UMMISCO 209 (IRD/UPMC)
> Every DSL ends up being Smalltalk
> http://doesnotunderstand.org/
>
I sent this mail yesterday but strangely no received it, so here it is
again.
With Nicolas, we have created a first baseline of Moose based on the
projects in STHub. The baseline baseline47STHub: corresponds to the old
core-default baseline.
Loading the baseline on 1.4 works fine, here are the test results:
998 run, 991 passes, 1 expected failures, 6 failures, 0 errors, 0
unexpected passes
For each proj moved to SThub, we have tried to define two symbolic versions:
#stable: a specific version of a proj at the time of move to STHub
#bleedingEdge: load the latest packages of a proj.
Hi doru
What is blocking the release of 4.8?
Because it would be good to release Moose 4.8 as the version before migrating to STHUB
then we can work on having a version running on Pharo 2.0.
Stef
Moose-Algos is moved to SThub.
Created a new baseline that loads from SThub.
Create a bleedingEdge symbolic version that loads the latest dev
Created a version in #stable for both 1.4 and pharo 2.0.
For pharo1.4-> All tests green
For pharo 2.0- > All tests green
Hi,
I'm wondering if it's possible to configure the MSE importer of Moose to
import elements that satisfy some conditions (e.g., [ :element | element
isFamixPackage ]).
In fact, I need to import only packages/namespaces and their classes from
MSE files. Why? because I want to load many many moose models (software
versions) in one image and I'm interested in few information within those
models (e.g., packages and their classes --without methods, attributes,
references, invocations, etc.).
By reading FMMSEParser and FMParseClientFilter, I found that we may set a
filter that specify the name of elements to import. Yet I'm not sure about
this.
However, I did not find any api that we may use to set a filter that
specify the type of elements to import.
Is there a such api?
if no, is it "possible" to implement it? any suggestions?
It would be great if we can set a block filter: e.g., [ :element |
element isFamixScopingEntity and: [ element isStub not ] ]
Cheers,
Hani
Hello,
We are moving Moose to SmalltalkHub and once the projects in Moose moved
and tested, we will port Moose to Pharo 2.0. Stef has volunteered to move
XMLSupport to SThub and update configs for both Pharo 1.4 and Pharo 2.0.
What do you think because it is important to have XMLSupport on a reliable
repo.
Usman
Scenario : I have an EyeSee chart that is updated from user input.
Problem: The EyeSee chart does not update. There are two methods (AFAIK) to
update glamour browser pane and its contents: explicitly send update
message to the pane or new transmission to the port of the pane to be
updated. Now, the first method does not work for EyeSee (may be a bug, i
suggested a fix yesterday). The second method requires that transmissions
are triggered but since Merlin is outside Glamour, I have to fake a
transmission on a dummy port (I tried that but when I execute my browser,
the dummy port is nil). I spent several hours looking into ports and their
transmissions but couldn't obtain a workable solution for my problem. Here
is a mock executable code to see what I am trying to achieve.
| browser aModel myColor|
browser := GLMDashboard new.
browser title: 'Customizable EyeSee Chart Example'.
browser addPaneNamed: #chart1 extent: 600@600.
myColor := Color green.
browser transmit
to: #chart1;
andShow: [ :a |
a eyesee
title: 'Sample bar chart';
diagram: [:renderer :x |
(renderer kiviat)
borderWidth: 1;
radius: 150;
models: {#(8 10 1). #(7 2 10). #(3 10 8)};
metrics: {#first. #second. #last. [ :each | each first + 2]};
maxs: {[ :model | 10]. [ :model | 10]. [ :model | 10]. [ :model | 10].};
mins: {[ :model | 1]. [ :model | 1]. [ :model | 1]. [ :model | 1]};
roundedBorder: true;
backgroundColor: myColor;
displayLegend: true;
kiviatBackground: true;
useColors: ESAbstractDiagram strongColorsTransparent];
act: [
| wizardControl wizardPane1 dropListPart|
wizardControl := WizardControl new.
wizardControl renderer: MerlinMorphicWizardRenderer new.
wizardPane1 := WizardSinglePane new.
dropListPart := DropListPart new list: #(red black green); yourself.
wizardPane1 row: dropListPart associatedTo: #color.
wizardControl addPane: wizardPane1.
wizardControl atEndDo: [ :aDictionaryOfOutputs |
myColor := aDictionaryOfOutputs at: #color.
(browser paneNamed: #chart1) update ].
wizardControl open.
] entitled: 'Parameterize Color'.
].
browser openOn: #(1 2 3 4 5 6 7 8). "can't put color in the input model"
Can you please have a look and see if I am missing something?
regards,
Usman
Hello,
I think it would be good to include this example in GlamourExamples. There
are some more in MooseBrowsers implemented by André.
| browser aModel|
browser := GLMDashboard new.
browser title: 'Customizable EyeSee Chart Example'.
browser addPaneNamed: #firstInput; addPaneNamed: #chart1 extent: 300@300.
browser transmit to: #firstInput; andShow: [ :a |
a dropDownList
title: 'Colors';
display: [ :model | model first ];
selectedIndex: 1
].
browser transmit
to: #chart1;
fromOutsidePort: #entity; from: #firstInput;
andShow: [ :a |
a eyesee
title: 'Sample bar chart';
diagram: [:renderer :model :color |
renderer verticalBarDiagram
y: #yourself;
defaultColor: color;
models: model second;
width: 200;
height: 150;
baseAxisLine.
renderer interaction popupText: #yourself ]].
aModel := Array
with: {Color black. Color red. Color green}
with: #(1 2 3 4 5 6 7 8).
browser openOn: aModel.
I am moving EyeSee from squeaksource to SThub. EyeSee has a dependency
on ShapeST80 (ss/ShapeST80). Should I move this project to Moose team or is
this project used somewhere independent of EyeSee?
usman
As the subject suggests, moose repo on squeaksource has been completely
moved to SThub. Now, we distinguish two types of package in
squeaksource/Moose:
- the packages from the repo loaded by the current moose configuration are
moved to Moose project on SThub.
- the packages not loaded by the current moose config are moved to
MooseArchive project on SThub (to be sure that we do not lose code).
ConfigurationOfMoose cannot be updated and tested unless all peripheral
tools (Mondrian/XMLSupport/etc.) are moved to SThub.
So, we are first moving and updating leaves before updating and testing the
config of trunk.
So, now remaining projects (in the coreDefault: baseline of Moose):
Mondrian, MooseAlgos, Glamour, PetitParser, XMLSupport.
I've already downloaded all packages of Mondrian, tomorrow I'll push them
and update the config.
The ones that require more effort in terms of organization: Glamour and
PetitParser.
So, may be during of the next week we can start loading the first basic
config of moose (after some cleanup: exclude DSM, Smalldude, Nile, etc.)
loadable from STHub and it would be good to make it rapid otherwise, if
someone needs to push some changes in moose and (s)he starts doing it on
SS, it'll be a mess.
usman
Currently, an EyeSee chart does not update itself when its pane is updated
in Glamour. I think the problem comes from the fact that erroneously the
presentation is assigned a new diagram block instead of a new renderer.
This code fixes this problem. Can I integrate it in glamour?
GLMMorphicEyeSeeRenderer >> actOnPresentationUpdate: ann
"ann presentation diagram: ESDiagramRenderer new."
ann presentation eyeseeRenderer: ESDiagramRenderer new.
canvasScrollPane scroller removeMorph: canvasScrollPane scroller submorphs
first.
self eyeseeCanvasFor: ann presentation
- moved the code of the both to SThub
- updated the config
- tested in 1.4 (all tests green)
- tested in 2.0
1. Apparently, BlockContext is removed in 2.0 so eyeSeeValue: cannot be
loaded from EyeSee in 2.0.
2. All tests green except ESExamplesTest>>testSmoke
Should I open bug entries for these?
Usman