Hi all,
a question: I have some Java models imported from intooitus generated .mse files. allNamespaces has a lot of garbage in there (java.* _anonymous _unknown_package_). I found that allModelNamespaces filters those out, but also filters out some of the namespaces that are defined in the model that I imported. I guess this is a bug, right? How does allModelNamespaces work and what is the rationale?
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
Hi!
As a result of the Software Quality lecture we are running at the DCC, Vanessa has written tests for Merlin. They are currently stored under the package Merlin in the Squeaksource repository CC68S
Can her tests be merged with Merlin?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi all,
I need some help with the Java implementation of Fame.
I am trying to implement separate parsing in VerveineJ so that one can
deal with larger project by parsing them piece by piece.
This implies loading in verveine the MSE already created to be able to
add new entities to it.
And The import method of Repository does not work for big MSE files
(that were generated by the export method of Repository BTW) :-(
It crashes with a StackOverflow:
Exception in thread "main" java.lang.StackOverflowError
at java.util.HashMap.put(HashMap.java:389)
at java.util.HashMap.putAll(HashMap.java:541)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:192)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191)
at ch.akuhn.fame.fm3.MetaDescription.collectAllAttributes(MetaDescription.java:191)
at ch.akuhn.fame.fm3.MetaDescription.allAttributes(MetaDescription.java:139)
at ch.akuhn.fame.Repository.add(Repository.java:121)
at ch.akuhn.fame.Repository.add(Repository.java:131)
at ch.akuhn.fame.Repository.add(Repository.java:131)
+ zillions of this same line, Repository.add calling itself
recursively at line 131
I looked a bit into it and think that the problem may come from line
131 into the Repository.add() method :-)
public void add(Object element) {
assert element != null;
if (elements.add(element)) {
MetaDescription meta = metamodel.getDescription(element.getClass());
assert meta != null : element.getClass();
for (PropertyDescription property : meta.allAttributes())
{ <--- line 121
if (!property.isPrimitive()) {
boolean isRoot = property.getType().isRoot();
for (Object value : property.readAll(element)) {
assert value != null : property.getFullname();
if (!(isRoot &&
(value instanceof String ||
value instanceof Boolean ||
value instanceof Number))) {
try {
this.add(value);
<--- line 131
} catch (ClassNotMetadescribedException e) {
throw new
ElementInPropertyNotMetadescribed(property);
}
}
}
}
}
}
}
My suspicion is that this recursive call is actually walking through
the entire graph of FamixEntities because every entity is related to
some other entity ...
1- Anybody want to comment on this suspicion?
2- Any idea how to correct it?
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
Hi all,
I am trying to implement a small "island parser" in PetitParser, but I have a problem.
The following is the most self contained example I can think of,
it is able to extract the word 'island' from any context.
I have the class IslandSyntax, subclass of PPCompositeParser, with the following methods:
===
IslandSyntax>>start
^world end
IslandSytntax>>world
world := PPUnresolvedParser new.
world def: (island , world) / island / (water,world) / water.
^world.
IslandSyntax>>island
^'island' asParser
IslandSyntax>>water
^((island not), #any asParser) ==> #second
===
Then, I have IslandParser a subclass of IslandSyntax:
===
IslandParser>>island
^super island ==> [:result | result inspect]
===
If I open a workspace and do:
IslandParser new parse: 'blablablaislandblablabla'.
The inspect on island is called only once,
while if I do:
IslandParser new parse: 'island'.
the inspector is called twice, probably because in the "world" production
I first put (island , world) and then (island).
Is there a way to avoid this double calling?
Am I doing anything wrong here?
Thank you!
Alberto
I redirect this to the moose list, please as there or in the pharo
list in the future.
> One thing I've noticed is the error messages (PPFailure). I like that
> it tells you what is wrong and where. What I don't like is how it
> decides to tell you that.
This can be customized.
> For instance, take your PetitSQL package. If you do:
> PPSqlGrammer new parse: 'select * form table'
> it will tell you that 'UPDATE' is expected at 0. I'd much rather it
> determine what the best match was and tell you it failed there. If
> you change the #command from that class to read:
> command
> ^ createCommand / deleteCommand / insertCommand / updateCommand / selectCommand
> and then run the above, it will instead tell you that 'FROM' expected
> at 9, which is what I would really like it to do.
The choice always reports the last error. Earlier version of
PetitParser used to report the error that consumed most input, but I
changed it because this was less predictable and less efficient than
the current implementation. You can create your own choice parser and
return the deepest failure if you think the old behavior is better.
> Is this possible out of the box? If not, can you give me some
> guidance on how I could make it work this way?
What I typically do is to insert failures at particular choices in the
grammar, for example:
PPSqlGrammer>>command
^ createCommand / deleteCommand / insertCommand / selectCommand /
updateCommand / (PPFailingParser message: 'Command expected')
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
Hi Sebastian,
I am not aware of anyone that actually did that. However, there would be two possibilities if you want to use Moose for your VASmalltalk code:
1. Migrate the Smalltalk importer, FAMIX and the Fame (from Pharo) or Meta (from VW) to VASmalltalk.
This will enable you to export an MSE file and load it on the other side
2. Get your code loaded (it does not have to work, just to load) into Pharo or VW
This will enable you to use the importer from those platforms
Regarding CodeCity, you should know that it works on the VW version only (which is Moose 3.2). The current Moose version is 4.2 and is available only in Pharo.
Cheers,
Tudor
On 8 Dec 2010, at 20:02, Sebastian Heidbrink wrote:
> Hello Tudor,
>
> there's one little question I have. I wasn't able find instructions or hint on this on the web.
>
> Do you know a solution or somebody how might know, how to handle VASmalltalk codeing with Moose and CodeCity?
> On ESUG in Amsterdam somebody mentioned that there is a way to import VASmalltalk, but there are some "adapters" needed, or need some tweaking?
> I'm not really sure anymore.
>
> I would be very grateful if you could provide me with some hints.
>
> Cheers!
> Sebastian
--
www.tudorgirba.com
"Being happy is a matter of choice."