What am I supposed to put as filename in sourceAnchors? I now put the full path there, but that doesn't work and makes things non-portable. In ObjectStudio each method can be in a different file, and they are actually on different drives, e.g. c:\Entwicklung\MSE\FAMIXClass.cls and o:\devtools\sunit\SUnit\SUnit\TestCase.cls.
If I remove the drive name, I can no longer find the sources, as there is only one root. If I keep the drive name, I can only use Windows (and it doesn't work because there is no root on Windows)
Of course I can work around this by moving all sources into one directory
Stephan
How feasible is it to get different attachpoints at each end of an edge?
This seems not possible at the moment since RTAbstractLine only has
a single 'attachPoint' ivar. Specifically I am wanting
from-end==>centre
and to-end==>nearestEdge.
cheers -ben
Hi,
The Chef engine needs to be revisited. The goal of this new version was to generalize the logic, and that is a good thing. However, the problem is that it does it at the expense of understandability by relying on string concatenation and perform:.
We need to iterate on this one and look for another design, while preserving the current behavior.
Would anyone be interested to dive in this area?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Speaking louder won't make the point worthier."
Hi,
The Moose build is now green.
That puts us in a good situation for a release.
Until the release I would like us to push be great to touch the followings:
- Adding the Famix packages to a separate Famix configuration. Cyril would like to help with that.
- Integrate the PetitParser compiler in the ConfigurarionOfPetitParser. @Jan: any chance to get you interested to look at this?
- Integrating SmaCC and all its parsers.
Anything else we should be aware of?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"From an abstract enough point of view, any two things are similar."
Hi,
I can arrange elements in a visualization where the size/area of an
RTBox is proportional to a specified value, like here:
or I can made all avatars (RTBitmaps) appear into this one:
But I would like to combine both, making the avatars area proportional
to a given value and present them in a RTFlowLayout. Is this possible
and how?
Thanks,
Offray
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Hi,
There is a package Famix specification that require a class of Pharo 3
(Or maybe 2).
There is no class comment inside.
Someone knows what it is? If this is useful then we should comment the
class, else we should remove the package because there is no senders.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Hi,
I went quickly through the changes from the FAMIX-C package. The Multivalue code looks good.
Here are two remarks:
1. I am not convinced about having CompilationUnit and Header be subclasses of CFile (which is a subclass of File). But, to make an opinion I would first like to see a model. @Alex, could you provide a simple MSE model to play with?
2. I would want to change is the names of the following two properties:
FAMIXCFile>>includedInFiles
<MSEProperty: #includedInFiles type: #FAMIXInclude opposite: #includesFiles> <multivalued> <derived>
<MSEComment: 'includedInFiles relationships, i.e. files that includes this file.'>
^ includedInFiles
FAMIXCFile>>includesFiles
<MSEProperty: #includesFiles type: #FAMIXInclude opposite: #includedInFiles> <multivalued> <derived>
<MSEComment: 'includesFiles relationships, i.e. files included by this file.'>
^ includingFiles
The names suggest that the result will be a collection of File objects, but it is actually a collection of Includes.
It is a bit tricky to name these selectors, but we could use the same convention we used for invocations, and we could have:
- includedInFiles ==> incomingIncludeRelations
- includesFiles ==> outgoingIncludeRelations
What do you think?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"To lead is not to demand things, it is to make them happen."
Hi all :-),
I have been playing with some mockups for an idea now that I have
finally the time for it.
As usual I start with a hand drawn mockup like this:
https://d167tapqdyj68f.cloudfront.net/offray.withknown.com/e/e/4/e/ee4e49f2…
and the I start to code the pieces with dummy data.
Here is, for example, what I call the avatar wheel:
And the arcs of it could be surround by objects that, as you can see in
the mockup, could be scaled and "pilled" as they go. The surround part
is working, "individully" as the following couple of examples show:
But, when I try to compose both surrounding avatars into the same view
and arc, things get weird:
I don't know if some one could take a look into the code or propose a
debug strategy to see what's going on.
The code is in the DataViz package[1] and the playground for running the
failing visualization or to be edited it to get the working ones is at 2
[1] http://smalltalkhub.com/#!/~Offray/Dataviz
[2] http://ws.stfx.eu/EX4NR2XBM0G0
Thanks,
Offray
