fast job is broken
Locked
 
|
Hi,
The FAST job is broken since a week: Please take a look at the problems.
Cheers, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Yeah, I know, and I already told about it week ago when PetitJava was merged. Looks like no one cares about the emails that I send about PetitJava, but I want FAST to stay green and evolve. So most likely when I will return from the vacation tomorrow I'll make a fork and will depend on it. Uko Надіслано з iPhone
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
I missed that mail :). I could not keep up with what was happening with PetitJava during my holidays, but I certainly think it is a piece that people care about (at least from a user point of view). Your and Chris's efforts are certainly appreciated. In any case, I am not sure I understand why you think that PetitJava is really the problem given that the petitjava build is green. Could you elaborate? Cheers,
Doru On Sun, Jun 30, 2013 at 12:41 PM, Yuriy Tymchuk <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Yes. So first of all build is red because of mondrian conflicts. Mondrian defines acceptVisitor: aVisitor in Object as "aVisitor visitNode: self". This way if during parsing something wasn't parsed into an AST node with defined acceptVisitor: method, or wasn't initialized properly e.i. something returns nil then we end up in the infinite loop. That's why job is red and not yellow. Now the thing about the PetitJava. I see the parsed Java AST as wrapped expressions. This way type cast wraps expression that is casts into some type, negation expression wraps an expression that is negates. Chris sees it as properties for example accessor node has a property for cast and a flag for negation. Also in his vision a node should store an array of accessors if they follow each other whereas I say that there should be a couple of nodes wrapping each other. Also I think that code should be refactored as right now accessor node has negation flag with getters and setters, same is defined for method invocation. This functionality should be moved into a common superclass, same should be applied for type cast etc... Also it's a bit frustrating that one node can be created as a result of parsing several different grammar entities (you can read my full impression in previous PetitJava discussion). It's fine that we have different views on the development as we can develop two different things. But if we want to have one project in Moose platform, other members of community should help to decide what we are developing. Uko Надіслано з iPhone
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
This also affects PetitDelphi, btw Verstuurd vanaf mijn iPhone
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In my opinion in first place we should create tools that work as close to a language specification as possible. Later we can make one more subclass of a parser to generate different AST, or use Visitor to traverse an existing AST to create a new one from it. I'm doing exactly the last mentioned thing to create FAST model that is different from PetitJava AST, but when someone uses JavaParser he expects to get something similar to what Java compile does. Uko Надіслано з iPhone
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
For what it's worth: I agree with this wholeheartedly.
The reason for me is that (a looong time ago) there was a VisualWorks AT-Tools parser specification for Java that did NOT follow the spec 100%. There were places where the developers of the parse rules tried to 'outsmart' the spec and take some 'sensible' shortcuts to have a more compact parser/AST. One example (if I remember correctly) was to skip the StatementExpression grammar rule. To make a long story short, I used that parser in my PhD, and where they did not follow the spec it was a *royal* *pain* to use the parser because I wanted to do things that were slightly different from what the designers of the parse rules had in mind. If they would have followed the language spec it would have been a piece of cake! So, yes, stick to the language spec. Some PhD student will be glad for it at some later time! (Just my 2 eurocents … :-P ) On Jun 30, 2013, at 1:42 PM, Yuriy Tymchuk <[hidden email]> wrote: > In my opinion in first place we should create tools that work as close to a language specification as possible. Later we can make one more subclass of a parser to generate different AST, or use Visitor to traverse an existing AST to create a new one from it. I'm doing exactly the last mentioned thing to create FAST model that is different from PetitJava AST, but when someone uses JavaParser he expects to get something similar to what Java compile does. > > Uko > > Надіслано з iPhone ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Johan wrote:
>So, yes, stick to the language spec. Some PhD student will be glad for it at some later time! Ok, so that problem we don't have in Delphi. There is no spec, and all available grammars are wrong. AFAIK, most languages have either that problem, or no significant implementations that follow the spec (c++, sql). Chris doesn't seem opposed to a very detailed level, as long as there are some convenience accessors in the right places. Our problem with PetitDelphi is that there is no way to know what nodes to create, without having a usecase for them. So we just started (like Chris, I guess) with what we seemed to need. Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Mon, Jul 1, 2013 at 7:45 AM, Stephan Eggermont <[hidden email]> wrote:
Yes, that is exactly what I did. And then I responded to a certain degree to criticisms (most all of which were deserved) with some changes.
Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Uko2
Hi
On Sun, Jun 30, 2013 at 7:24 AM, Yuriy Tymchuk <[hidden email]> wrote:
Thank you for writing this. It confirms to me that you do understand my position - mostly. I have attempted to remove the array of accessors from the AST nodes that I've added - these should be no nodes left like that (with an array of accessors or method invocations). Instead, each accessor or method invocation should have a 'receiver' that is is relative too, and it knows about nothing further up or down the chain. I don't think that the negation flag should be moved up the chain - from what I can tell (and I admit, unfortunately, that I am not a Java expert of any kind) is that the Java specifications do not consider variable accessors and method invocations as the same thing - rather, quite a bit different. hence the reason the negation flag was placed into two different trees by me.
That said, you did a good job of summarizing where we differ on this topic.
I agree with this, too. As Stephen guessed below, I have no opposition to the very detailed AST model. That said, I definitely don't have the personal drive to build it (that spec is huge!), and I'm sure my employer would not willingly pay for me to finish it, either. But, I would definitely like a more robust AST model - either where I have started, or where you or the community wants to go.
Thanks, Chris
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Hi Doru, I suspect part of the problem (with fast failing with petitjava is green) is that the petitjava ast parser test suite is incomplete. Very imcomplete. While this is 'bad', it isn't bad. The AST model is very incomplete at this point, and the choices are currently:
1- pick a target AST model, build the full test suite, and wait until someone gets around to building the AST model while petitjava stays red, or 2- choose an AST model that we agree on, and incrementally build the AST and tasts together.
The problem with building the tests now for the AST model is that most of what is present is a lot of arrays of stuff - the raw output of the grammer parser - which isn't that desirable in my opinion - it freezes us with a partial AST model early.
-Chris On Sun, Jun 30, 2013 at 5:43 AM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by jfabry
Hi.
On Sun, Jun 30, 2013 at 3:42 PM, Johan Fabry <[hidden email]> wrote: For what it's worth: I agree with this wholeheartedly. The parser - yes, absolutely, 100% agree. How Java compilers parse it is show we should part it.
What is less clear to me is what the AST model should look like. In PetitJava, we have a PPJavaSyntax that will parse the java file, ideally just like the compiler will. It leave a bare parse tree in it wake.
We also have a PPJavaParser, which takes that raw parsing and builds an AST representation. As was pointed out by Yuriy Tymchuk, I'd prefer a more compact representation of the parsed results instead of the more granular results. Although either would work - it's just that for my purposes, the more compact makes it easier to get at the information that I want. They should both be valid, though.
-Chris (Just my 2 eurocents … :-P ) _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Jul 1, 2013, at 12:19 PM, Chris Cunningham <[hidden email]> wrote: >> So, yes, stick to the language spec. Some PhD student will be glad for it at some later time! > The parser - yes, absolutely, 100% agree. How Java compilers parse it is show we should part it. > > What is less clear to me is what the AST model should look like. In PetitJava, we have a PPJavaSyntax that will parse the java file, ideally just like the compiler will. It leave a bare parse tree in it wake. > We also have a PPJavaParser, which takes that raw parsing and builds an AST representation. As was pointed out by Yuriy Tymchuk, I'd prefer a more compact representation of the parsed results instead of the more granular results. Although either would work - it's just that for my purposes, the more compact makes it easier to get at the information that I want. They should both be valid, though. My vote, if I would have had one as a PhD student that long ago, would be to have the bare parse tree, with a 1-to-1 correspondence with the specification. If there is a specification, of course. I'm not speaking about the case of Delphi, I have no experience with it whatsoever. I prefer no optimizations whatsoever because they come at the cost of less (or less straightforward) functionality. Of course this may not work for everybody (e.g. space & time issues when processing). So I understand the need for more compact representations. Yet one should be careful that the compact representation, if used a lot, will in the end become the 'standard' way of doing things, making the bare parse tree become the unpopular child of the family, with all the negative effects that this induces. That's all I'll comment about this subject for now, and leave you guys to actually do things. What I did that looong time ago was fun, but I have moved on to other things meanwhile, so I don't mean to drag this discussion on ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi all,
>From my work in the Delphi parser, and from my experience as java programmer, I will try to add some thoughts to the discussion. First of all, I am still struggling to get the code for Delphi clean. I try to do this by sticking to some rules in converting the "standard petit parser result" to AST nodes. I follow the following rules: 1. when I have an "or" rule ( / or | ), I do not create an AST node. I only create an AST node for the sub rules. I.E. annotationTypeElementDeclaration gets no concrete AST node. I sometimes create a abstract AST Node with subclasses for the sub rules. 2. when I have a rule that has some syntax around the interesting part, I simple cut out the syntax. i.e. arguments. 3. when I have an list of things, I give back an array of the things. I.e. expressionList. Note that in the Delphi parser, we have some helper method to do this. For a complete list, see PPDelphiLexicon convenience category, and PPDelphiParser convenience category 4. For most other parse rules, I create an AST Node, that makes sense out of the tokens. This node is create with a onTokens: because I do not want too much interpretation in my grammar. And counting in an array is not very readable. The AST Node is always named after the rule in the grammar. Secondly there are some semantic rules in Delphi I do not incorporate into my AST. For instance: in some cases an identifier is defined, and sometimes used. But in generating my AST, I do no attempt at all to make a difference between them. An identifier is simple a string that follows certain rules, and if it is a valid variable or constant or whatever, I do not care at that point. When I am generating FAMIX, I try to match names, so I can connect all things. So this means I do not parse the Delphi the same way Delphi does, and do not intend to make an attempt to do so. Because my goal is not to generate code, but to generate an analysis model. A lot of rules I make are therefore more forgiving than a Delphi parser would be. I.E. A Delphi parser will generate an error when it encounters a call to an undeclared function. I will not do so. Also I want to include all variants of the various defines ({$IFDEF}). Finally, I know java is pretty well defined with a good language spec. But when I would make a java parser, I will sometimes merge rules and/or break up rules, especially if I use petit parser. We did find some spec on Delphi that was fairly complete, that we took as base. But while parsing, we modified some of the rules, so it would make a better fit. I.E. we had several type of identifiers, we all cast back to identifier. So my advice would be not to make the language spec of java too holy, but to make the syntax and grammar rules as readable as possible, so it will be easy to match to the java spec. Diego _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |