Sounds like a good idea, if you have the time.
How do you build the AST incrementally and iteratively,
so you can show (end-user) results every day?
Stephan
Hi!
Some of you may have heard about Hierarchical Bundle Edges. If no, then use google to find their cool papers.
We will soon have a working implementation :-)
Cheers,
Hernan & Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
So, it looks like everyone that wanted to speak up has spoken up. From a
strictly numeric standpoint it looks like the consensus is tied - 3 for
strict grammar adherence, and 3 for allowing it to be looser (maybe
significantly). But, popular vote isn't really the best way to solve
technical problems.
After reviewing the arguments again, the case for following the published
grammar does make a lot of sense, especially since there is one. For my
purposes, I'll either subclass that grammar or figure out how to use it
directly (probably by extended it in my image as necessary). I still like
a more focused AST, but given that I am not a Java expert, I definitely
shouldn't be the one creating it - at least not the general one.
So, how/when should I/we go about converting the current AST over? I will
be interested in converting at least the parts that I want - which is more
than there is now, but not the entire grammar. Note that this will change
any Visitors using the AST, meaning that the Fast build will probably
continue to fail as work is progressing.
Might I suggest that a symbolic version be made against PetitJava that the
Fast job uses - that uses a static version of PetitJava. This would stop
the job from failing; the static version can be updated when you are ready
to incorporate the changes in.
Thanks,
Chris
Hi Vincent,
FMMSEParser basicRun shoudl do the trick
What's your end goal for this? Because most of what you can do with moose
is going to perform pretty bad over high latency slow bandwidth connections.
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
Stephan
Hi,
In developing moose on web, I wanted to use the MSE parsing to import by
the web an moose model.
Guillaume and I discover that the parsing trigs a job showing a progress
bar. This UI stuff is directly implemented in the parser
(FMMSEParser>>run) what is not really the way to do it according
Guillaume.... and I can't disable it easily for running the parsing on a
server...
What do you think ?
Cheers,
Vincent
Hi,
Moose on Web is on the Web !
The purpose of this project is to access the moose image across the web
through a Rest Api
I let you discover ...
You can try it at:
http://37.139.2.203
And access directly to the API at:
http://37.139.2.203/API
Cheers,
Vincent
Nicolas wrote:
>Ifg I understand correctly, you are talking about symbol resolution?
Yes, that's correct.
Though all languages have different semantics for symbol resolution,
they seem to be composed out of a small set of 'essential abstractions'
- nesting rules (Delphi has nested functions)
- interface vs implementation
- visibility restrictors
- strictness (having to define first vs first use defines)
- order (first one vs last one wins, aliasing)
And perhaps some specifics (smalltalk blocks, friend)?
Stephan
While building up the FAMIX model from the Delphi AST,
we need to connect the references to the correct entities.
We first did this with referenced types, but are now trying to
build up the call graph.
We know in Delphi that everything we want to reference
has been defined earlier, so we need to look up references
in the FAMIX model we build up so far. Currently we do that
by searching through all entities, building up moosenames.
This is very slow, and error-prone, since we should
actually use the hierarchical scope of the current code point.
We would like to be able to ask the scopingEntity to resolve
the names we encounter into a famixNamedEntity. We think
this functionality is more general, and would like to implement
it. We believe we can make an algorithm that has the right
behaviour for smalltalk, c, java and Delphi (and likely others).
To do this we'd need to add referenced scopes to scopingentity.
Do you agree this is a good idea, or do you have other
suggestions to make these connections?
Diego & Stephan
Hi Erwan and all,
Just to make a few things clear about Roassal 3d vs SourceCity.
We are currently working on Roassal 3d, which intends to be a nice layer at the top of NBOpenGL and NBXLib to easily create 3d scenes with cubes, lights, camera, interactions, zooming, translucent coloring, clicking/rotating/translating individual elements and so on. Everything that is good for Roassal is equally good for 3D Scene.
Having a city-like visualization will be one of our first objectives since (i) it is a compelling use of 3D and (ii) it is easy to implement (at least the bases). We started to work on a CityBuilder, to easily create cities from objects and provided metrics. Ideally, it would be great to have SourceCity based on our effort. Not now since we have just started Roassal 3D, but on some point we should merge (this is similar in the 2d World with Mondrian and EyeSee moving from plain Morphic to Roassal).
Our objective is to offer a great 3d framework to make a truly flying SourceCity.
Does this make sense to you?
Cheers,
Alexandre
On Jul 4, 2013, at 10:47 AM, Erwan Douaille <douailleerwan(a)gmail.com> wrote:
> https://ci.inria.fr/pharo-contribution/job/SourceCity/
>
> done
>
>
> 2013/7/4 Camillo Bruni <camillobruni(a)gmail.com>
>
> On 2013-07-04, at 15:35, Erwan Douaille <douailleerwan(a)gmail.com> wrote:
>
> > I updated the ConfigurationOfSourceCity.
> >
> > Gofer new
> > smalltalkhubUser: 'ErwanDouaille' project: 'SourceCity';
> > configuration;
> > load.
> > ConfigurationOfSourceCity loadBleedingEdge
>
> would it make sense to make a jenkins job for this?
>
>
>
>
> --
> Best regards,
>
> Douaille Erwan <douaille.erwan(a)gmail.com>
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
