Beginner questions re. Moose analysis of C++ source code
I'm totally new to Moose (and effectively new to Smalltalk) and need a
pointer or two on analyzing an old application that was developed in Visual
C++ 2006. I have the complete sources, including the Visual Studio project
files, resource files, etc.
I've already got Pharo and Moose installed on my Windows system and have
been able to get the Moose playground to run, but that's about it. So far I
don't know how to get Moose to do anything else.
My initial goal is just to get this source code "loaded" into Moose.
I've seen references to VerveineC-Cpp and Famix-C but no explanation of how
to use either one.
I haven't had an opportunity yet to try VerveineC-Cpp on Windows 10 at my
On my personal Mac (i.e. not on the office system where I actually need to
do this work) I installed Eclipse Oxygen and tried to follow the very
limited directions to install VerveineC-Cpp, but Eclipse complains about the
Maybe Eclipse Mars is needed instead of Jupiter? It also looks like I might
need to use the old, deprecated Java V1.7 for MacOS, instead of a current
version of Java? (Hopefully I won't need an older version of MacOS. I'm
running Sierra V10.12 with all updates as of this writing.)
Maybe that would all be more straightforward somehow on Windows?
(I also have Linux at work, if that would be any easier.)
As for Famix-C, I see that it appears to be "built in" to the Moose
environment that I installed at work and at home. But I don't know how to
make it do anything.
I greatly appreciate any hints or suggestions. I'm very eager to begin using
Moose and to (re)learn Smalltalk, especially in the Pharo environment which
looks really fascinating.
(Trivia: Back in the early 1990's or thereabouts, while taking a graduate
course in operating system design, I learned enough Smalltalk to get me
started on writing an emulator for the simple machine specification the
professor gave us. But a single academic quarter, roughly three months, just
wasn't enough time to both learn a totally new, object oriented programming
paradigm /and/ use it to complete such a program, while also holding down a
full time job and leading a regular life. :-) But I did write a good paper
explaining my ideas and how far I'd actually been able to carry them. The
professor was understanding, liked my concept, and I managed to get a B+
grade for the course.)
Sent from: http://forum.world.st/Moose-f1310756.html
4 years, 11 months
by Tudor Girba
We were a bit silent the last couple of months. Quite a bit happened in the meantime, so here is a summary (for more fine grained announcements, you can follow us on Twitter):
- Scrolling. We finally have a good scrolling support:
This might sound like a trivial feature, but it turns out it is not. We had a bug that forced us to rethink the support quite deeply in order to be able to debug it. To do this, we now can simulate time in Bloc, which is really cool:
(as a side note, the bug we fought with was the last
- Pannable element is a combination of a scrollable element with a scalable element, and it offers the possibility either to zoom in/out + scroll, or to fit screen and resize when the parent resizes.
- PDF, SVG, PNG, JPG export (based on the underlying Moz2D support):
- Better curve support:
- Better debugging support for understanding bounds:
- We now have simple list and columned list widgets. The list is both fast and scalable and supports rows of variable heights:
- Basic tab widget:
- Looks: a mechanism for specifying element-specific composition and interaction.
- Documenter saw some major improvements. Just a reminder, Documenter is the tool that enables live programming and previews directly within Pillar documents.
We now have a capability similar to notebooks like Jupyter:
We use it extensively to document our code. For example, here is a tutorial about playing with looks in Bloc:
And we can also express whole tutorials based on Epicea:
- Diagrammer. We now have better editing support for detailed things such as arrow head:
While Diagrammer is apparently a tool for diagrams, it has a rather generic design that can be utilized for all sorts of use cases. For example, one side effect is that now all elements can be visually edited:
- Mondrian: Using the new pannable element, we can now zoom in/out and scroll, and we can also set element to fit screen. We can also drag elements around.
- Inspector: we now have an initial support for multiple views associated with an object. The support is similar to the one from the current inspector.
The feenk team
"What is more important: To be happy, or to make happy?"
Is anyone using C/C++ models
by Pavel Krivanek
the old Famix implementation has some irregularly defined relations in
parts related to C/C++ meta-metamodels and we should not move them this way
to the compatibility metamodel defined in new Famix.
So I would like to ask, is anyone of you using C/C++ models in practice
now? If not, we do not need to bother with the keeping of the backward
compatibility for every price.
roslyn2famix - C# importer
by Tudor Girba
We are happy to announce roslyn2famix, a C# importer. It is based on Roslyn, and was mainly developed by George Ganea. It is released under Apache 2.0, the same license as Roslyn:
The importer has a structure similar to the one of jdt2famix, including a Fame implementation in C#, and FAMIX code generated out of the Moose code. We also have a few CSharp specific entities that are already present in Moose-CSharp.
The importer takes as input a C# solution (.sln), and produces an MSE file that can be loaded in the latest Moose.
The feenk team
"Be rather willing to give than demanding to get."
C# importer ?
by Johan Fabry
And now it looks like I will need to analyze a part of our own code, written in C#. Is there a parser for C# in Moose and if so, how extensive/solid is it?
Johan Fabry, Senior Software Engineer.
johan(a)raincode.com | Email too brief? Here's why! http://emailcharter.org
Column width in characters?
by Luke Gorrie
I would like to make my GTInspector views work well with different font
sizes. In particular, some people find the default Pharo font too small and
want to switch to a larger one.
The main problem is that my tables have their column width specified in
pixels. The values are chosen to make good use of screen space with the
default font size, but it becomes unreadable with a larger font that
How should I solve this?
The first idea that comes to mind is to invent my own units that are scaled
according to system font size when converted to pixels. I wonder if there
is a better known solution already though.