Beginner questions re. Moose analysis of C++ source code
by smallglt
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
office.
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
build path.
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
C# importer ?
by Johan Fabry
Hi all,
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?
TIA
--
Johan Fabry, Senior Software Engineer.
johan(a)raincode.com | Email too brief? Here's why! http://emailcharter.org
5 years
Re: [ann] gt diagrammer
by Tudor Girba
Hi,
> On Apr 18, 2018, at 9:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>
> Hi Doru,
>
> Le 18/04/2018 à 06:45, Tudor Girba a écrit :
>> Hi,
>> Sorry for the late reply. I missed this email.
>> BlInfiniteElement’s comment says:
>> "I'm an element which is supposed to contain huge amount of children and layout only those of them that are visible inside my viewport.
>> I work with DataSources to fetch data from and can present data within different Infinite Layouts.”
>
> Ok so this is a generalisation of the fasttable approach.
>
> I wanted to know if it could handle data sources where elements size is variable and unknown unless you render the element.
Yes, it does:
https://twitter.com/feenkcom/status/984744251920658432
>> It is used in both lists and in the text editor.
>
> Obvious, isn't it. A text is a list of lines...
>
>> I am not sure which variable you refer to by "currently processing a request”. Can you clarify?
>
> Can't find it, but must have been triggered when looking at variables like layoutRequestEaten. Yes, it seems like it.
>
> Interesting: found the cache used in the BLInfiniteElement (BlRecycler?). Also found a pool (BlInfinitePool) ? Couldn't find what it could be a pool of... Strange, you add things in the pool when you release them (so you fill the pool by releasing objects?). Looks like a LIFO stack to me.
I am not quite sure what you mean by filling the pool by releasing objects. Can you explain? Also, I let Alex describe the details :)
Doru
> Regards,
>
> Thierry
>
>> Cheers,
>> Doru
>>> On Apr 9, 2018, at 3:54 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>>>
>>> The only way one can review it is to reverse engineer the whole code
>>> base then. How much did you say? 2 peoples, how many months?
>>>
>>> A few questions then, after a cursory glance:
>>>
>>> - In what way an infinite BlElement is infinite?
>>> - Why does an infinite BlElement has what seems to be a sort of
>>> "currently processing a request" instance variable?
>>>
>>> Regards,
>>>
>>> Thierry
>>>
>>> 2018-04-09 14:08 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>:
>>>> Hi,
>>>>
>>>> We are doing that. We rewrote the system multiple times precisely because of these reasons. We could certainly do better, but I think that any meaningful conversation must happen around code, and we’d be happy to learn where we did not exploit all abstractions we could. Actually, I would be happy to even have a conversation about issues, even if the solution is not given. It can start by simply being pointed to code that does not sound right.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>> On Apr 9, 2018, at 1:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>>>>>
>>>>> 2018-04-09 12:00 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>:
>>>>>>
>>>>>>
>>>>>>> On 9 Apr 2018, at 11:36, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2018-04-09 11:23 GMT+02:00 Aliaksei Syrel <alex.syrel(a)gmail.com>:
>>>>>>> Hi,
>>>>>>>
>>>>>>> For the record, View class, a root class of all visual elements in Android 27 is 26'488 lines of code. It didn't hover prevent it from being used on more than 2 billion devices :)
>>>>>>>
>>>>>>> Remind me, please: what is the budget of Google for the ongoing maintenance of Android?
>>>>>>>
>>>>>>> The core of Bloc is just 14k lines of code. It would be nice to know how many lines of code should be considered too much, 5k, 7.43k or 10k.
>>>>>>>
>>>>>>> For a non-rendering core? 2k.
>>>>>>
>>>>>> I think that having a time/space efficient high quality well documented code base is definitively a goal, they are probably not there yet.
>>>>>>
>>>>>> Being the smallest out there is probably not a goal, nor is that a particularly interesting one, IMHO.
>>>>>
>>>>> Small means a real effort has been to:
>>>>>
>>>>> - not reimplement already available mechanisms,
>>>>>
>>>>> - build the most effective abstractions,
>>>>>
>>>>> - do not factor in unneeded customizations points,
>>>>>
>>>>> I value highly someone that try to reach thoses.
>>>>>
>>>>> Thierry
>>>>>
>>>>>>> Thierry
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Alex
>>>>>>>
>>>>>>> On 9 April 2018 at 11:12, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> 2018-04-09 11:02 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 9, 2018 at 9:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote:
>>>>>>> 2018-04-09 9:14 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I think it might be more interesting to start the review from the usage of it, not from the internals.
>>>>>>>
>>>>>>> Well, from the usage of it, I've seen nothing that doesn't fit into
>>>>>>> the yagt. I've seen that field evolve and try clever things, really
>>>>>>> different things, and Bloc does not look like one of thoses.
>>>>>>>
>>>>>>>> Indeed, Bloc is primarily an engineering effort. But, there are a couple of things that make it rather different from other solutions. For example:
>>>>>>>> - Only one rendering tree in all cases. This works also for graph visualizations that work with any element without imposing knowledge about edges in the base system. We think this is quite important, and especially when combined with a performant rendering, it can open new doors for UI design.
>>>>>>>
>>>>>>> Look, from the point of view of the man of the art, it doesn't seems
>>>>>>> like a breakthrough.
>>>>>>>
>>>>>>>
>>>>>>> Do we need a breakthrought for UI ?
>>>>>>> No !
>>>>>>> We need something that works that's it, stable software with good documentation and tests.
>>>>>>> After that people can build the next-UI if they want, but this is build on solid foundations.
>>>>>>>
>>>>>>> Agreed. And this is where it is critical.
>>>>>>>
>>>>>>> I used Morphic since Self 3.0, beginning of my PhD (1994, I think), followed it to the beginning of Squeak (1998). When I came back to Pharo in 2011, I was horrified by what it has became: a monster of thousands over thousands of buggy lines.
>>>>>>>
>>>>>>> And now I see a replacement, that, before going into production, is already at 45k lines? And with a planned, huge dependency on the GUI lib of another project?
>>>>>>>
>>>>>>> Do you imagine how it will be, 10 years down the line?
>>>>>>>
>>>>>>> Do you think it will be the stable foundation you're looking for?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Compared to other smalltalk-based solutions, yes, it may be seen as an
>>>>>>> improvement.
>>>>>>>
>>>>>>> I think you underestimate how advanced that field has been / is, and
>>>>>>> how far behind the state of the art are industrial solutions.
>>>>>>>
>>>>>>> There is only one development in the Smalltalk space in GUI that is
>>>>>>> worthy of interest for me: the anti-aliasing of Juan Vuletich. It
>>>>>>> would have so much impact overall (remove all dependencies on external
>>>>>>> libs, remove the need to do font anti-aliasing, scrap thousands of
>>>>>>> lines of slow and ugly Smalltalk code, simplify the FreeType
>>>>>>> infrastructure, remove MBs of external librairies, ensure long-term
>>>>>>> porting ease / code evolution).
>>>>>>>
>>>>>>> M
>>>>>>> aybe this was a breakthrought, but how many users ?
>>>>>>>
>>>>>>> Very few users. Juan has not yet implemented it.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Thierry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> --
>>>>>>> Serge Stinckwich
>>>>>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>>>>>> "Programs must be written for people to read, and only incidentally for machines to execute."
>>>>>>> http://www.doesnotunderstand.org/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Moose-dev mailing list
>>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> Moose-dev(a)list.inf.unibe.ch
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>> www.feenk.com
>>>>
>>>> "We cannot reach the flow of things unless we let go."
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)list.inf.unibe.ch
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> "Things happen when they happen,
>> not when you talk about them happening."
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.com
www.feenk.com
"Don't give to get. Just give."
5 years, 1 month
[ann] gt diagrammer
by Tudor Girba
Hi,
We are happy to announce an initial version of GT Diagrammer, an engine for constructing diagrams interactively. This is the newest addition to the next generation GT built on Bloc.
It looks like this:
https://twitter.com/feenkcom/status/976341449267531776
We chose to work on Diagrammer for multiple reasons. First, developers often need to create hand built diagrams to communicate intentions, and an integrated experience should not require us to leave our environment to create them. At the same time, Diagrammer is an application that requires a widgets and interactions, and thus it is a nice exercise for Bloc and Brick.
One requirement we had from the beginning was to make it work with any Bloc element. This means that the editing part had to be reasonably generic. To this end, we now have elements that can define visual editors. This is somewhat a combination between Magritte descriptions, and inspector extensions. An interesting side effect is that now we can edit visual properties when inspecting any element. In other words, we got the basic infrastructure of a UI painter. It looks like this:
https://twitter.com/feenkcom/status/982656456968241152
The user interface essentially relies on two widgets: scrollable list and toggle button. While the visual look of the toggle button is inspired from material design, the most interesting part is that now we have an implementation for controlling looks per element instance. A key issue here is that looks can react to events coming from the element and inject visual attributes and possible even change behavior (for example, changing an icon while pressing a button). We will post more about looks soon.
We now also have a nice solution for overlays. For example, we have an overlay showing selection and an overlay for resizing elements.
Perhaps less obvious, Diagrammer also offers a basic infrastructure for the area of visual languages. As Diagrammer works with any Bloc elements, we can simply create dedicated visual elements. As an example, Diagrammer comes with an implementation of a UML class figure. Furthermore, as the functionality does not impose a specific model, custom language semantics can be mapped on visual actions.
There are several things to do still for it to become a mature solution. An important next step is to serialize a diagram scene in a reproducible manner. Currently, the diagram (or any element) can be exported as pdf (https://twitter.com/feenkcom/status/976580153802358786), svg (https://twitter.com/feenkcom/status/976578060429484032), png, gif or jpeg by directly using the low level canvas. However, for the diagram to be truly useful we need to store the result in either code or another reloadable form such as STON. Other future directions are related to figure controlling (for example, custom anchors or line bending points) and to enhanced editors.
To play with it, the easiest way is to download the new GT in a Pharo 6.1 image:
Metacello new
baseline: 'GToolkit';
repository: 'github://feenkcom/gtoolkit/src';
load.
And then inspect:
GtDiagrammerElement new
Cheers,
The feenk team
--
www.tudorgirba.com
www.feenk.com
"Presenting is storytelling."
5 years, 1 month
C/Cpp parser
by Nicolas Anquetil
Synectique is openning the source code for a C/C++ parser based on
Eclipse CDT.
https://github.com/Synectique/VerveineC-Cpp.git
The parser was developed as an Eclipse (Mars release) plugin and is
under MIT licence.
nicolas
--
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod
5 years, 1 month
How to get a GLMRubricTextPresentation with StandardFonts codeFont ?
by Johan Fabry
Hi all,
I posted a question like this a week ago but had no response, so here we go, more explicitly:
I would like a get a GLMRubricTextPresentation using the StandardFonts codeFont. I do not see how to configure this. The text is not ST so I cannot use the different ST presentations that are available.
I have been looking for some time now, but cannot see a solution. Can anybody help me out?
--
Johan Fabry, Senior Software Engineer.
johan(a)raincode.com | Email too brief? Here's why! http://emailcharter.org
5 years, 1 month
Some simple questions
by Jannik Laval
Hello,
I am defining my own metamodel, and I am using the MSE pragmas.
I use <MSEProperty:type:opposite:> and <multivalued>
I also see the pragma <derived>. Could you explain me what it is?
And also, for example, in FAMIXReference>>target, there is a pragma
<target> (same for <source>). Is it a specific pragma ?
Is there a page explaining all the available pragmas ?
Thanks a lot for your help
Best regards,
--
~~Jannik Laval~~
Enseignant-chercheur
http://www.jannik-laval.eu
http://www.phratch.com
http://www.approchealpes.info
5 years, 1 month
roassal question
by Nicolas Anquetil
This is one that I already had several times and could not find a proper
answer:
How to have nodes grouped in containers (e.g. classes in packages) and
links from one inner node (i.e. a class) to another one possibly from a
different container (e.g. inheritance links from one package to another
one) ?
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
5 years, 1 month
Re: RTHistorgramSet does not implement xScale/yScale
by Brennan Cleveland
Alexandre,
Sure, I'm implementing pie charts and histograms for Dictionary also. Let me know what next steps might be for properly finishing the existing histogram implementation...
Brennan
-----Original Message-----
From: Moose-dev <moose-dev-bounces(a)list.inf.unibe.ch> On Behalf Of moose-dev-request(a)list.inf.unibe.ch
Sent: Thursday, March 29, 2018 5:00 AM
To: moose-dev(a)list.inf.unibe.ch
Subject: Moose-dev Digest, Vol 139, Issue 14
Send Moose-dev mailing list submissions to
moose-dev(a)list.inf.unibe.ch
To subscribe or unsubscribe via the World Wide Web, visit
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lis...
or, via email, send a message with subject or body 'help' to
moose-dev-request(a)list.inf.unibe.ch
You can reach the person managing the list at
moose-dev-owner(a)list.inf.unibe.ch
When replying, please edit your Subject line so it is more specific than "Re: Contents of Moose-dev digest..."
Today's Topics:
1. Re: RTHistorgramSet does not implement xScale/yScale
(Alexandre Bergel)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Mar 2018 22:01:47 -0300
From: Alexandre Bergel <alexandre.bergel(a)me.com>
To: Moose-related development <moose-dev(a)list.inf.unibe.ch>
Subject: [Moose-dev] Re: RTHistorgramSet does not implement
xScale/yScale
Message-ID: <C5AEA9B4-82C4-490D-B56E-D68AAEB74B75(a)me.com>
Content-Type: text/plain; charset=us-ascii
Hi Brennan,
The implementation of the histogram was never properly finished.
It would be fantastic to build a new implementation. It should not be that hard actually.
We could have discussion if you wish to help :-)
Cheers,
Alexandre
> On Mar 23, 2018, at 6:43 PM, Brennan Cleveland <cluvius2000(a)hotmail.com> wrote:
>
> Hi,
>
> The 'histogram' method on SequenceableCollection added by Roassal2 fails due to xScale/yScale not being implemented on RTHistogramSet.
>
> I added implementations of both as:
>
> ^ RTLinearTransformation instance.
>
> to RTHistogramSet which at least gets a histogram working. I'm not sure what the proper fix actually is. I thought maybe adding this implementation on RTAbstractDataset would be the right thing to do...
>
> Thanks,
>
> Brennan
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> list.inf.unibe.ch%2Flistinfo%2Fmoose-dev&data=02%7C01%7C%7C35b54e25b3a
> 7452e761a08d5955bd97b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636
> 579144077353793&sdata=6dx4HkbAFMV15PYD8ePw00zRIPAR8%2BvesZ8Z8%2Bg8KF8%
> 3D&reserved=0
------------------------------
Subject: Digest Footer
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lis...
------------------------------
End of Moose-dev Digest, Vol 139, Issue 14
******************************************
5 years, 1 month
