Hi!
During my Sunday evening coding session, I worked on a spectrograph in Roassal.
Here a small example:
Each vertical line is a class. Height is the total amount of methods (class + metaclass). Red = class methods, Gray = instance methods.
The script is the following:
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| b |
b := RTSpectrograph new.
b objects: (RTLayout withAllSubclasses reverseSortedAs: #numberOfMethods).
b popupText: [ :aClass :cm | cm methodClass name, '>>', cm selector ].
b lineBlock: [ :cls | cls methods, cls class methods ].
b highlight: [ :aClass :cm | cm methodClass isMeta ].
b title: 'Proportion of class methods'.
b open.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A more sophisticated example:
Each vertical line is a class.
Green classes are Trachel classes
Gray classes are Roassal classes
Height of a class is its age, in number of days (i.e., age of the oldest methods of the class).
Each red dot is the creation of one of its method (i.e., when the method was created).
We can see that Trachel classes have not evolved that much, i.e., most of the methods have been defined on the same day.
The to obtain this visualization is the following:
-=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-=
| b now |
now := DateAndTime now.
b := RTSpectrograph new.
b objects: ((RTObject withAllSubclasses , TRObject withAllSubclasses) reverseSortedAs: #livingInDays).
b highlight: [ :cls :livingDay | cls inheritsFrom: TRObject ] color: Color lightGreen.
b highlight: [ :cls :livingDay | cls gotMethodOnDay: livingDay ].
b popupText: [ :cls :age | cls name, ' ', age printString , ' days old' ].
b lineBlock: [ :cls | 0 to: cls livingInDays ].
b open.
-=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-= -=-=-=-=
If you try this code one day after I posted it, all the classes will be one pixel higher :-)
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I am experiencing problem with the font using Athens. Am I the only one?
After using a fresh image, the problem appears after a short while. This is frustrating :-(
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
We’ve just added a new post that contains nice screenshots and (short) explanation about galaxies.
https://www.facebook.com/ObjectProfile/posts/628687443884523?stream_ref=10
Faviola is doing a truly fantastic work.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi everyone,
sorry if I missed that, but is it a known issue that code completion popup is displaced (does not appear near the cursor)? Because for me it’s very frustrating and I’d try to fix it if someone can suggest me where to start looking?
Uko
Hi!
To welcome the effort of Francisco Hafon A. and Ronie Salgado, we have posted some new picture of Roassal3d.
https://www.facebook.com/ObjectProfile/posts/629794963773771
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks Kilon for your nice words.
Currently, AstroCloud is a bit slow. For example, loading this image takes much more than it should. For now, speed is not our priority. AstroCloud has to be fast and we will make it fast. Probably relying on external library is the way to go.
Just to give a bit more context about why we are doing AstroCloud. ALMA is the largest observatory on Earth, making it the largest astronomical project in existence (http://www.almaobservatory.org). This is what humanity has best to detect life outside Earth.
ALMA is made of 66 high-precision antenas making it possible to see deep in the universe. Unfortunately, there is no good software to process these immensely complex pictures. Some tool suite naturally exist, but they were not made for ALMA, making these existing tools largely suboptimal to process complex picture of ALMA.
Faviola’s dream (and mine) is to produce a tool ready to be consumed by astronomers to process ALMA pictures. Faviola and I are currently seeking for additional resources on making this happen.
Regarding your help about documenting Roassal. It is very welcome! In one of my previous post, I said that 2014 will be the year of documenting Roassal. A book is on its way. We will need people to review it. So thanks!
Kind regards,
Alexandre
On May 6, 2014, at 2:40 PM, kilon alios <kilon.alios(a)gmail.com> wrote:
> Well then my hat off to you sir
>
> I am asking because rendering graphics is certainly an expensive (CPU and RAM) process. Rendering graphics is certainly something that interests me.
>
> Of course I dont expect Pharo to compete with C , but then thats why we have Nativeboost. But I would love to see Roassal evolve to a full blown graphics engine. Certainly motivates me more to learn Roassal as deeply as I can. I remember when you first said I should use Roassal for my vector editor , I was quite sceptical. But seeing all these new apps pop up from real scientists made me think twice and now I have put my vector editor on hold to learn more about Pharo and Roassal and of course Moose.
>
> Would love to help you document it further. Though for now I am learning it in a very slow pace. Congrats to you and all people involved with the libraries and of course to the people making the apps. You certainly changed my mind and I would love to see more apps that show the potential of these libraries.
>
> I am also wondering if you are so ambitious whether porting C libraries like imagmagick would make sense for Roassal.
>
>
>
> http://www.imagemagick.org/
>
> Or possibly other C graphics libraries.
>
>
> On Tue, May 6, 2014 at 9:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
> The picture is rendered in Roassal, but raw data is obtained from a file.
> AstroCloud, an application made on top of Roassal, does some sophisticated color mapping and transformation.
>
> Alexandre
>
>
> On May 6, 2014, at 12:40 PM, kilon alios <kilon.alios(a)gmail.com> wrote:
>
> > beautiful, I am a huge fan of astronomy and sci fi. Is the image of the galaxy rendered with Roassal or is it just an image file that Roassal is displaying ?
> >
> >
> > On Tue, May 6, 2014 at 6:56 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
> > Hi!
> >
> > We’ve just added a new post that contains nice screenshots and (short) explanation about galaxies.
> >
> > <1836600_628685437218057_2402452585680727709_o.png>
> >
> > https://www.facebook.com/ObjectProfile/posts/628687443884523?stream_ref=10
> >
> > Faviola is doing a truly fantastic work.
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-GlamorousToolkit
New issue 1038 by kurs....(a)gmail.com: Debugger Shortcuts Problems
http://code.google.com/p/moose-technology/issues/detail?id=1038
While using shortcuts in debugger, e.g. alt+t for step over, once upon a
time the focus is moved from the stack window to the code window and alt+t
starts modifying the text. One has to click back to the stack window...
How to reproduce the problem:
Just use debugger with alt+t for some time.
Additional information:
Ubuntu x64
--
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 1051 by info.lan...(a)gmail.com: MessageNotUnderstood:
GLMTextMorphForEditView>>textMorph
http://code.google.com/p/moose-technology/issues/detail?id=1051
I've been trying to execute a script in the new workspace.
This script needed a temporary variable so I clicked on : Declare new ...
And the error occurred
MessageNotUnderstood: GLMTextMorphForEditView>>textMorph
--
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-Glamour
New issue 1032 by chisvasi...(a)gmail.com:
GLMPresentation>>dynamicActionsOnSelection does not work for text
presentations
http://code.google.com/p/moose-technology/issues/detail?id=1032
Text presentations have the selection in the port 'selectedText'.
GLMPresentation>>dynamicActionsOnSelection only computes the actions if
the 'selection' port is populated. Thus, it does not work for text
presentations.
--
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 1062 by v.blonde...(a)gmail.com: The GT-Debugger doesn't declare
variables created while debugging
http://code.google.com/p/moose-technology/issues/detail?id=1062
Describe the problem: what do you get? what do you expect?
When debugging, if you define a new variable in a debugged method, the
variable is not declared when you save.
How to reproduce the problem: step by step if necessary
For example, debug :
{ 1 .2 } asOrderedCollection
Go into.
In the method asOrderedCollection, write:
temp := self as: OrderedCollection.
^ temp
After saving, the temp variable is not declared and the method is compiled
without the declaration.
Additional information: platform, context which may impact the problem
Latest Moose 5.0 - W7
Please fill in the labels with the following information:
* Type-Defect
* Component-GTDebugger
--
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 1063 by v.blonde...(a)gmail.com: Save a modified unstacked block
raise DNU: DebugContext>>codeTextMorph
http://code.google.com/p/moose-technology/issues/detail?id=1063
Describe the problem: what do you get? what do you expect?
When you modfiy a block that is not on the stack (like [ self halt ]) and
you browse it, you get:
DNU: DebugContext>>codeTextMorph
How to reproduce the problem: step by step if necessary
create a method in a class Class:
sendBlock
^ [ self halt ]
And call :
Class new sendBlock value.
It will open the debugger.
Now modify the block content (remove the halt for example)
Save, click on browse in the notification window.
You should get the error.
Additional information: platform, context which may impact the problem
W7 - Moose 5.0
Please fill in the labels with the following information:
* Type-Defect
* Component-GTDebugger
--
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 All,
I tried both ways:
1) inFusion -> segfault during startup
2) verveinJ ->
svn checkout svn+ssh://scm.gforge.inria.fr/svn/verveinej
svn: E210002: Unable to connect to a repository at URL 'svn+ssh://
scm.gforge.inria.fr/svn/verveinej'
I am using ubuntu 14.04, if it matters.
Regards,
Jan
Hi!
It often appears that compiling a method in the debugger does not work properly.
For example, if I have the method:
A>>foo
self halt
Running A new foo opens a debugger. In the debugger if I modify foo by the following broken code:
foo
| t |
[ :t | ]
The code gets compiled without giving any warning. But foo remains with “self halt”.
I would expect an error window to popup up, but not to loose my change.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello,
I started to have a look to understand if Voyage can be used to save a
moose model into a Mongo db.
This script saves the model, which can be retrieved, modified and saved.
|importer model1 |
importer := MoosePharoImporterTask new.
importer importingContext: (MooseImportingContext new
importClass; importMethod; importAccess; importInvocation;
importInheritance; mergeClassAndMetaclass; yourself).
importer candidateClass: CandidateListOperator.
importer importerClass: SmalltalkImporter.
importer model: MooseModel new; addFromPackagesNamed:
#(#'XML-Writer-Tests'); run.
model1 := importer model.
model1 name: 'a persistent model'.
model1 privateState flush.
model1 save
MooseModel selectAll.
To see the MooseModel instance that you just saved.
Or you can see other objects:
FAMIXClass selectAll
If you want to try it:
1/ Install Mongo
2/ Gofer it
url: 'http://smalltalkhub.com/mc/estebanlm/Voyage/main';
package: 'ConfigurationOfVoyageMongo';
load.
(ConfigurationOfVoyageMongo project version: '1.2-baseline') load: 'Mongo'.
3/ Gofer it
url: 'http://smalltalkhub.com/mc/usman/MooseVoyage/main';
package: 'MooseVoyageMongo';
load.
(The package contains a few necessary extension methods to tell voyage to
persist moose model and famix entities).
4/ repository := VOMongoRepository
host: VOMongoRepository defaultHost
database: 'moosedb'.
repository enableSingleton.
========================
There are some issues though:
- It takes a lot of time even to store even ordinary models.
- I don't know yet how to serialize MooseGroups.
I'll try to resolve them in my free time.
Improvements will come from the new algorithm by Esteban to automatically
break circular references in complex Graphs and he'll soon integrate and
release it with Voyage 2 :). I hope this improves performance issues.
For further info on Voyage, you can follow this book chapter:
https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces…
Please feel free to try/improve.
regards,
Usmanf
Hi!
Just to share a screenshot of what we are working on:
Result of the script:
=-=-==-=-==-=-==-=-==-=-=
| b |
b := RTGraphBuilder new.
b nodes color: Color gray.
b edges
connectTo: #dependentClasses;
color: (Color gray alpha: 0.1);
if: [ :f :t | '*Example*' match: f name ] color: (Color green alpha: 0.2).
b layout
partition: [ :c | c inheritsFrom: RTTest ];
partition: [ :c | c inheritsFrom: RTLayout ];
partition: [ :c | c inheritsFrom: RTShape ];
partition: [ :c | c inheritsFrom: RTInteraction ];
partition: [ :c | c inheritsFrom: RTBuilder ];
partition: [ :c | '*Example*' match: c name ];
partition: true;
force.
b layout circle radius: 250.
b global
normalizeSize: [ :c | c dependentClasses size ] min: 5 max: 30 using: #sqrt.
b addAll: (RTObject withAllSubclasses).
b open
=-=-==-=-==-=-==-=-==-=-=
Comments are welcome!
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I am currently analyzing 80 Pharo applications for which I need to compute for each class of these 80 applications, the lcom2 and lcom3 metrics.
Computing these metrics needs to have the attributes, methods, and access in the moose model. Which is rather heavy. I have tried to augment the memory setting given to the VM, but this does not work much. For now, I am trying to run moose as follows:
/Users/alexandrebergel/Dropbox/PharoVM/Pharo.app/Contents/MacOS/Pharo -memory 5000m /Users/alexandrebergel/Downloads/moose-5-10/moose-5.0.image
Is there an alternative to this? What I could do, is for each project, create a full model, call #lcom2 and #lcom3 on each class to compute the metric, and then trim out the model by removing what I do not need (everything except FAMIXClass). Is there an easy way to do such a transformation on a moose model?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
[Apologies for duplicate reception of this CFP]
IEEE SOFTWARE - 1ST SPECIAL ISSUE ON RELEASE ENGINEERING
Submission Deadline: 1 August 2014
Publication: March/April 2015
More Information: http://releng.polymtl.ca/RELENG2014/html/SI.html
Software used to be released in shrink-wrapped form, but the advent of agile
methodologies and the web has overhauled the landscape. For example, a project
like Mozilla Firefox releases every 6 weeks, generating updates for dozens of
existing versions on 5 desktop, 2 mobile and 3 mobile desktop platforms, each of
which for more than 80 locales. In other words, deployment of modern
applications requires coordinating the release of applications on multiple
mobile platforms, web platforms with centralized backend services, and native
desktop clients. Furthermore, concepts like continuous delivery of software are
no longer curiosities, but essential to retain a competitive edge.
Release engineering deals with all activities in between regular development and
actual usage of a software product by the end user, i.e., integration, build,
test execution, packaging and delivery of software. Although research on this
topic goes back for decades, the increasing heterogeneity and variability of
software products along with the recent trend to reduce the release cycle to
days or even hours starts to question some of the common beliefs and practices
of the field.
The IEEE Software Special Issue on Release Engineering solicits experience
reports and papers on tools, methods, practices and techniques to streamline
release engineering. We especially welcome submissions targeting recent
challenges like continuous delivery and heterogeneous platform support, but the
Special Issue is open to any of the following topics:
* best practices for code movement (branching/integration)
* continuous integration and testing
* build and configuration of software
* build system maintenance
* testing and reporting infrastructures
* package and dependency management
* legal signoff and bill-of-materials
* delivery and deployment of software
* code signing and certificate management
* continuous delivery, deployment, installation and software update
* cloud provisioning and management
* cloud service release management
* interaction with app stores
* mobile app release management
* principles and automated techniques for release planning
* release engineering for product line systems
* devops and interaction with developers, end users, etc.
* devops practices and tools
* large-scale build and test farms
* multi-platform build and test
* feedback on continuous delivery and deployment
The goals for this Special Issue are three-fold:
* making researchers aware of the challenges and research opportunities, and
practitioners aware of research in release engineering
* sharing experiences with practical approaches, tools, methods and techniques for
release engineering
* building connections between different communities involved in release engineering.
In an effort to engage with practitioners, one of the co-organizers of the
Special Issue is a release engineer at Mozilla and one half of the reviewers
will consist of release engineers, so we guarantee that each paper or abstract
submission receives at least one review from a practitioner.
Full submissions for the Special Issue must not exceed 5,400 words including
figures and tables, which count for 200 words each. Submissions in excess of
these limits may be rejected without refereeing. The articles we deem within the
theme and scope will be peer-reviewed and are subject to editing for magazine
style, clarity, organization, and space. We reserve the right to edit the title
of all submissions. Be sure to include the name of the theme or Special Issue
you are submitting for.
We also solicit short “practice” papers from practitioners that contain
experience reports. These papers do not need to make a research contribution,
but should instead present the experiences of a practitioner or practitioners by
describing things such as current release processes used, challenges faced,
solutions attempted, and/or results obtained. Practice papers should not exceed
3,500 words.
Articles should have a practical orientation and be written in a style
accessible to practitioners. Overly complex, purely research-oriented or
theoretical treatments are not appropriate. Articles should be novel. IEEE
Software does not republish material published previously in other venues,
including other periodicals and formal conference/workshop proceedings, whether
previous publication was in print or in electronic form.
For more information about the focus, please contact the Guest Editors:
* Bram Adams (http://mcis.polymtl.ca/bram.html), Polytechnique Montréal, Canada
* Stephany Bellomo (http://www.sei.cmu.edu/about/people/profile.cfm?id=bellomo_15351), SEI, USA
* Christian Bird (http://research.microsoft.com/en-us/people/cbird/), Microsoft Research, USA
* Foutse Khomh (http://www.khomh.net/), Polytechnique Montréal, Canada
* Kim Moir (http://relengofthenerds.blogspot.com/), Mozilla, Canada
For general author guidelines: http://www.computer.org/software/author.htm
For submission details: software(a)computer.org