Moose-dev July 2013

moose-dev@list.inf.unibe.ch

28 participants
130 discussions

Re: PetitJava AST model status
by Stephan Eggermont 13 Jul '13

13 Jul '13

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

1 0

Hierarchical Bundle Edges
by Alexandre Bergel 13 Jul '13

13 Jul '13

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 4

PetitJava AST model status
by Chris Cunningham 12 Jul '13

12 Jul '13

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

1 0

Re: UI stuff in parsing
by Stephan Eggermont 11 Jul '13

11 Jul '13

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

1 0

UI stuff in parsing
by Vincent Blondeau 11 Jul '13

11 Jul '13

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

1 0

[ANN] Moose On Web
by Vincent Blondeau 11 Jul '13

11 Jul '13

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

4 7

Re: [ANN] Moose On Web
by Stephan Eggermont 11 Jul '13

11 Jul '13

I assume it is on smalltalkhub http://smalltalkhub.com/#!/~VincentBlondeau/MooseOnWeb/ Stephan

2 1

Re: Looking up code references in FAMIX
by Stephan Eggermont 10 Jul '13

10 Jul '13

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

1 0

Looking up code references in FAMIX
by Stephan Eggermont 10 Jul '13

10 Jul '13

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

2 1

Re: [Pharo-dev] SourceCity works
by Alexandre Bergel 09 Jul '13

09 Jul '13

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

6 9

← Newer
1
...
7
8
9
10
11
12
13
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2013