Hi all,
I have a small parser written in PetitParser ;) I would like to call
it from a non smalltalk application (e.g., Java, javascript) or, more
generally, from a Unix command line. Something like:
./myParser -i fileToParse.txt -o outputFile.txt
Is there any possibility to do that? Can a headless Pharo be a
solution? If so, how can I start and use a headless Pharo? Is there
any useful documentation/email about it?
Thank you a lot for any help.
Cheers,
Alberto
Hi all,
I'm new to using moose for analyzing a rather large smalltalk project
developed during the last 16-17 years.
I hope that using Moose framework will give positive insights on the
hot-spots of the system in order to improve its structure, and make it more
maintainable.
The project name is Madeo (http://stiff.univ-brest.fr/BINIOU/MADEO) a FPGA
design-automation toolkit developed mainly by one of my PhD supervisors (Loic
Lagadec <http://stiff.univ-brest.fr/~llagadec>).
To start the evaluation I believe that the overview pyramid is a very good
starting point in order to get a generic idea about the system.
However, I was not able to find any smalltalk threshold values in the moose
image.
So my question is if there is somebody having some idea about the
smalltalk threshold values for the OverviewPyramid.
If yes, could you provide me these figures, and eventually point me to a
scientific paper presenting these results.
If not, I'm willing to try to get these figures myself... however I don't
really know which smalltalk projects I could use to get good results.
Thank you very much for your attention.
Best wishes,
--
PhDc Ciprian TEODOROV
Lab-STICC/AS CNRS UMR 3192
University of Brest
phone: (+33)(0) 6 08 54 73 48
mail: ciprian.teodorov(a)univ-brest.fr
www.teodorov.ro
Hi!
I played with the matrix in EyeSee in a Pharo image. I found some problems:
- #new:withAll: and #new: seems to raise an emergency debugger, whatever the value we provide
- Many references are made that do not belong to EyeSee. For example #zero that refers to MalMatrixCoercion
I also found other problems (e.g., hash).
I added some tests for those.
I produced version 0.9.2
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
hello all,
I am trying to create a distribution map for a moose model representing
Citezen. Now, for each class, I am trying to color it according to its
authors information. The following script should work for me:
|model packages|
model := (MooseModel root allModels) first.
packages := model allPackages.
(DistributionMap onContainers: packages elements: (model allModelClasses)
properties: [:cl | cl authors > 10] )
render
open.
However, the method "authors" that I am invoking on cl (a FamixClass) is
not defined by FamixClass but it is described by ClassDescription. Is there
anyway to connect a FamixClass to its corresponding Smalltalk class?
I am thinking of getting the name of the FamixClass and somehow ask pharo
to give me its corresponding Smalltalk class?
Any ideas if that should work?
thanx in advance,
Usman
Status: New
Owner: ----
CC: anquetil...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-VerveineJ
New issue 733 by tu...(a)tudorgirba.com: VerveineJ does not export modifiers
http://code.google.com/p/moose-technology/issues/detail?id=733
public abstract class A { ... }
should appear as
(
(FAMIX.Class
(name 'A')
(modifiers 'public' 'abstract')
)
Similar things should happen to methods and attributes.
Hi,
Class extensions is at the core of the design of Moose. For example, for a class we have as extensions:
- numberOfMethods
- isJUnit4TestCase
- viewBlueprint and viewBlueprintOn:
Now, the question is, when to extend an existing class and when not, given that it might lead to a very large amount of methods. To answer this, let's start from the reason for having the extensions in the first place.
We want extensions to unify the scripting and the user interface world. For example:
- if we are in a MooseFinder, we can see numberOfMethods in the properties pane, because it is meta-described, and we can use it easily in scripting (each numberOfMethods > 10).
- The isJUnit4TestCase is not meta-described, but it's meant to be used as a query facility.
- viewBlueprint appears in the menu and it is also meant to be used from the inspector.
- viewBlueprintOn: this is particularly useful when it is used inside other Mondrian or Glamour scripts
So, all in all, you extend when you have:
- a meta-described property
- a query method (the best kind are unary ones)
- a menu entry
- a compose-able script
Now, when not to extend? Basically, when you do not fall in the above categories :).
Here are some examples:
- FAMIXClass>>viewMethods: aCollection inBlueprintLayerNamed: aString on: view
I can safely provide this as an example, because created it. This is a method that basically only makes sense in the context of the class blueprint. So, it should be bundled together in a separate helper class.
- FAMIXPackage>>configurationOfECell
This is basically just a helper method that only makes sense in the context of DSM, so it should better be placed there.
Cheers,
Doru
--
www.tudorgirba.com
"Next time you see your life passing by, say 'hi' and get to know her."
Hello,
I have two simple questions. In the code below:
public MemberTypeBinding(char[][] compoundName, ClassScope scope,
SourceTypeBinding enclosingType) {
super(compoundName, scope, enclosingType);
...
}
How many Accesses and References do I have? (do the parameters contain 2
References and the super 3 Accesses).
Thanks!
--
Andre Hora
FAMIXType is a generic class representing a type in an object-oriented language.
As such a type can have multiple subtypes or supertypes. These are represented by instances of FAMIXInheritance.
A type defines methods (operations), attributes.
It is also defined in a container often a FAMIXNamespace or a FAMIXPackage, depending of the language.
It may also be a class (in case of nested classes).
It can also define behavioursWithDeclaredType structuresWithDeclaredType
I have a question:
what are behavioursWithDeclaredType and structuresWithDeclaredType
structure I guess a bit.
behaviroWithDeclaredType is for parametrized subclasses?
Stef
we have
FAMIXPackage represents a package in the source language.
A package is different from a namespace (FAMIXNamespace). They both provide a scope, but the namespace does it from a language perspective. For example, in Java concept of package maps both on the FAMIXNamespace and on a FAMIXPackage:
- it is a FAMIXNamespace because it provides a lexical scope for the contained entities, and
- it is a FAMIXPackage because it describes the physical structure of the system.
I propose
FAMIXPackage represents a package in the source language, but when the language only mean grouping of entities without scoping.
The scoping aspect is captured by FAMIXNamespace.
A package is different from a namespace (FAMIXNamespace). A package defines simply a group of entities. A namespace scopes a group of entities (it may implement
an import, a name lookup). For example, in Java concept of package maps both on the FAMIXNamespace and on a FAMIXPackage:
- it is a FAMIXNamespace because it provides a lexical scope for the contained entities, and
- it is a FAMIXPackage because it describes the physical structure of the system.
FAMIX extractor usually map Java package to FAMIXNamespace for these reasons.
proposition:
FAMIXClass represents an entity which can build new instances. A FAMIXClass is a FAMIXType, therefore it belongs to a super/sub lattice (depending on the language) and it holds attributes, methods, structures.
FAMIX does not model explicitly interfaces and nested classes.
But a FAMIXClass can represent a Java interface (see isInterface query method).
Java extractors can nest classes into classes and classes in namespaces.
For anonymous classes, classes are simply defined in methods.
Hi,
The amount of unit tests run by ci.moosetechnology.org got to 5012. I know it does not say much, but it sounds cool :)
Cheers,
Doru
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Hi doru
I want to start working on
- producing a good FAMIX30
-> So will continue to go over the comments
- probably adding package: java at the right places.
Now I was thinking that to ease the transition I will duplicate the program
MSE
FM
so that code can continue to work and then later we remove MSE* ones.
stef
Hi guys
MooseElement>>mooseName
"Returns an unique identifier of this entity. This method is mandatory, and must
return a Symbol or Integer that uniquely identifies this entity within its model (but
not within the entire Moose enivronment, see MooseElement>>mooseID). The return
value must not be nil, and must never change. The implementation should be fast,
as this key may be used extensivley by the MooseModel or similar facilities."
^self mooseID asString "asSymbol -- check if this really works with Integers
as well, else change sender!"
was like that
and now MooseEntity>>mooseName
mooseName
| stream |
^ self privateState
propertyAt: #mooseName
ifAbsentPut:
[ stream := (String new: 64) writeStream.
self mooseNameOn: stream.
^ stream contents asSymbol ]
so why the comment got lost?
Stef
Hi,
The other week I was at GOTO Aarhus. This was a great conference. And I got to talk about humane assessment with Moose.
The presentation seemed to have captured some attention:http://martinfowler.com/bliki/gotoAarhus2011.html
I think it's great that a project that was built mostly on the research side of the world can capture industry attention. This shows what can be achieved when innovation is married with long-term engineering effort. And it's not that we did not publish anything in the meantime either -- some more than 200 publications stand witness that science was not neglected.
Even if I was the one presenting, the value of the work comes from many contributors. If we were to count, the effort around Moose totals more than 200 man-years of research and development. Moose has long passed the research prototype state.
The philosophy behind Moose is to reinvent software and data analysis by making it accessible and tailorable. We lived this philosophy in one way or another, but it was never quite explicit. Now we have name for it: humane assessment. This is a new approach in the software engineering arena, and it can have a significant practical impact.
So, here is my call. Invest in Moose. Let's change the status quo. Again from Smalltalk.
How?
• Just play with it. Take an afternoon and load your system into Moose, build a browser, play with a visualization. And get back to us with questions, suggestions, documentation or code.
• Take an hour to read through humane-assessment.com. And get back to us.
• Help us reshape the http://moosetechnology.org webpage.
• Just get involved. There is always room for a contribution. You do not have to be a specialist. In fact, given that we aim to invent what does not yet exist, none of us are.
Cheers,
Doru
--
www.tudorgirba.com
"Don't give to get. Just give."
Hi!
I was not able to download inFamix. Apparently, it says that I need to accept the license before doing so. But no idea how to accept it...
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
There is a small bug in the MooseMonticelloHTTPImporter>>#onURL: method.
This method recursively calls itself.
onURL: anHTTPURL
"
(self new onURL: 'http://www.squeaksource.com/PersonalSetting')
importFileNamed: 'PersonalSetting-simon_denier.16.mcz'
"
^ (self onURL: anHTTPURL) import
The fix would be to change it to something like:
*onURL: anHTTPURL*
* ^self new onURL: anHTTPURL; import*
--
PhDc Ciprian TEODOROV
Lab-STICC/AS CNRS UMR 3192
University of Brest
phone: (+33)(0) 6 08 54 73 48
mail: ciprian.teodorov(a)univ-brest.fr
www.teodorov.ro
Hi,
No celebration just yet. The errors appear randomly. We need to take a look at them.
Andre, would you have time?
Cheers,
Doru
On 20 Oct 2011, at 22:26, Alexandre Bergel wrote:
> Yahhoo!!!
>
> Alexandre
>
>
> On 20 Oct 2011, at 17:26, admin(a)moosetechnology.org wrote:
>
>> See <http://hudson.moosetechnology.org/job/moose-latest-dev/662/>
>>
>>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
--
www.tudorgirba.com
"From an abstract enough point of view, any two things are similar."
As part of testing and removing bug #728 (placing methods in the wrong class), I migrated to Eclipse 3.7.
For VerveineJ, this implies that the org.eclipse.* jars (in the "lib" subdir) have been updated to the corresponding new versions
Still as part of this bug, I stumble on the fact that in Java, enums are implicit subtype of the "java.lang.Enum<E>" class.
VerveineJ now reflect this in the exported model (although more work is still required on this)
Finally, after all these changes, one test was red and has been commented out for now.
Hopefully I will be able to correct it soon.
nicolas
Hi,
A short while ago I upgraded the CompositePresentation to be able to use it as an entry point to a Glamour script.
The idea here is that we can now use Glamour like we use Mondrian: we instantiate the GLMCompositePresentation once and then we always pass it to other methods.
For example:
buildBrowser
| browser |
browser := GLMTabulator new.
browser ...
==>
buildIn: composer
composer tabulator with: [:t |
t ...
]
The old way still works, of course. The nice thing about this solution is that it works better with the editor (you are given the composer).
For a live example, see:
http://www.humane-assessment.com/blog/building-a-simple-code-browser
Let me know what you think.
Cheers,
Doru
--
www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Hi Usman,
I saw that you added the port code to the MooseAlgos repo. Thanks.
Now, during your changes, you inherited the Lattice and the Node from MONode.
This caused Moose to be unloadable and it is wrong from two points of view:
1. MONode is not meant to be inherited at all. You are supposed to use Mondrian as a transformation from your domain into the internal Mondrian model.
2. MooseAlgos is a basic set of algorithms with no dependencies. Mondrian is higher level. Thus, MooseAlgos cannot depend on Mondrian.
For these reasons, I now removed the inheritance from MONode.
Furthermore, we also need tests for FCA.
Cheers,
Doru
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
Hi Usman,
I see that you are hacking on the Lattice. Good :)
The Moose build fails becauseyou added an extension to MalLattice in
Moose-MondrianPaintings, but when this package gets loaded, the MalLattice
is not present. The reason is that ConfigurationOfMooseAlgos does not know
about the newly created package: Moose-Algo-Lattice.
So, you have to add this package to the ConfigurationOfMooseAlgos>>default:
But, before you do that, you should rename the package to
Moose-Algos-Lattice.
Cheers,
Doru
---------- Forwarded message ----------
From: <admin(a)moosetechnology.org>
Date: Fri, Oct 21, 2011 at 3:48 PM
Subject: Build failed in Jenkins: moose-latest-dev #664
To: tudor(a)tudorgirba.com, simon.denier(a)gmail.com, cy.delaunay(a)gmail.com,
alexandre(a)bergel.eu, stephane.ducasse(a)inria.fr, jannik.laval(a)gmail.com
See <http://hudson.moosetechnology.org/job/moose-latest-dev/664/>
------------------------------------------
Started by user girba
[workspace] $ /bin/sh -xe /tmp/hudson5079168647777384641.sh
+ rm -rf <http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose> <
http://hudson.moosetechnology.org/job/moose-latest-dev/ws/moose-tests> <
http://hudson.moosetechnology.org/job/moose-latest-dev/664/artifact/moose_s…
>
+ /srv/hudson.moosetechnology.org/builder/build.sh -i Pharo-1.3 -s moose -s
glamorous-theme -s glamorous-toolkit -s moose-clean -s cleanupforrelease -o
moose
build.sh: error loading code (/srv/pharo/coglinux2382/squeak)
*** Warning: Warning: This package depends on the following classes:
MalLattice
You must resolve these dependencies before you will be able to load these
definitions:
MalLattice>>viewLattice:
Recording test results
Archiving artifacts
--
--
www.tudorgirba.com
"Every thing has its own flow"