Hi,
There is not enough communication and coordination around Moose these days. Perhaps it is just the holidays, but I feel a bit lonely working on Moose.
I would be interested in knowing who is working on what these days. Or at least, who would like to work on what.
Cheers,
Doru
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
Hi!
I was pretty tired of not being able to load Glamour in different images, so
I've created a new stable #version for pharo 1.3 and, by now, saved that
configuration in the dbxtalk repo squeaksource.com/dbxtalk.
Maybe someone want to integrate it in the glamour repo :).
Cheers,
Guille
I created the configuration with last Ben improvement.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi,
I just remember that when I merged MooseElement and MooseEntity, I did not take into account the comments of the class.
If someone want to copy and paste them :)
Else I will do it tomorrow.
Cheers,
---
Jannik Laval
We get
------
FAMIXSourceLanguage
This represents the programming language in which an entity is written. It is used for dispatching entity actions for specific languages. For example, formatting a source text will be performed according to the language.
We can get
---------
I represent the programming language in which an entity is written. I'm used for dispatching entity actions for specific languages. For example, formatting a source text will be performed according to the language.
API:
format: aSourceString from: anEntity
isAttached
@@no idea what it is.@@
sourcedEntities
References to the entities saying explicitly that are written in this language
@@But it does not help me at all@@
Now I do not get why we have sourceEntities added to the source language.
Hi
I was looking for the package (FM3 one) for FAMIX or Core and Java and I could not find them.
Do you know if they got created?
I have the impression that this is another sign that pharo need manifestoClass per packages so that we
can annotate them and Moose would use them to declare them.
Now imagine that we get that (we can just start adding a FAMIXJavaManifest class in the package FAMIX-Java)
how do we annotate that this is a FM3Package because
<package: > is used to annotate properties
And I have the impression that having the distinction between definition and specialisation of annotation is better.
We have
FMPackage:
FMClass: superclass:
but we could have
FMClassDefinition: superclass
FMPackageDefinition:
FMPackaged:
Stef
We have
-------
FAMIXCustomSourceLanguage has not been documented yet. The class comment should describe the purpose of the class, its collaborations and its variables.
Instance Variables:
name <ProtoObject | PseudoContext>
We can get
---------
@@I represent specific source language that is not a language supported by default by moose?@@
Then the comment of name is unclear to me?
what is a language that is not explicitly modeled?
name
<MSEProperty: #name type: #String>
<MSEComment: 'The name of a custom language that is not modeled explicitly.'>
We have
-------
I'm an abstract class, root of the hierarchy modeling source code entities.
Any of my subclasses must define the meaning of the belongsTo, an abstract property that provides polymorphic traversal. For example, FAMIXClass defines belongsTo as being the container, while the FAMIXMethod defines belongsTo to point to the parentType.
I propose
--------
I'm an abstract class, root of the hierarchy modeling source code entities.
Any of my subclasses must define the meaning of the belongsTo property, an abstract property that provides polymorphic traversal. For example, FAMIXClass defines belongsTo as being the container, while the FAMIXMethod defines belongsTo to point to the parentType.
I support the tagging of entity as stub. Marking an entity as a stub means that the
Stubs should only be marked by importers and extractors. Stubbed entities represent the border of the modeled world as extracted. Stub tagging should not be recursive. Use other tags for such a purpose: a class may have an instance variable tagged as a stub because an importer got a memory leak or a bug. Still the class is not a stub, but extra analysis can mark it as incomplete.
When applicable, I also point to my containing package accessible via parentPackage and modifiers.
I also can return the list of invocations performed on this entity (considered as the receiver) (receivingInvocations).
Finally, I provide simple name for the entity I represent. The pattern is that name returns the local name of the entity.
