|
Tom Ball wrote: Hi Tom, Our distributed build system compares output files and only copies back the ones that have changed since the last build.Before looking the potential solution, should this not really only compile the grammar if it has changed, rather than compile every time and lok to the prior .java file? Or does the build system not preserve the intermediate code (the .Java etc in this case) - but it must as you are then comparing the output from teh last build? It seems though, that as you are then trying to determine whether it has changed after the fact, that perhaps the real thing to do is only build if anything has changed (as in normal timestamp comparison). The new -make option knows how to do this and how to calculate the dependencies and build in the correct order, and we also have the Maven plugin that only builds when the grammar or its dependencies have changed. That said, perhaps your build system isn't able to do this (we use Hudson and that works just fine) and so this is your only option. You could awk out the timestamp I suppose, but I will check with Ter and see if he is OK with a -nostamp option or something similar, that would just cause the timestamp to be empty, or perhaps the queen's birthday ;-) We've noticed that our Antlr->Java step always gets copied, for two reasons. First, because a timestamp is in the output file's header -- is that necessary as a default? More useful might be a timestamp variable that can be put a .g file if desired, and expanded during generation.Actually, it is quite probably the fact that the DFA conversion routines execute for a finite amount of time. As the JVM does not give CPU time, it uses elapsed time, defaulting to one second. If the machine is busier at sometimes than others, then it may end up with a slightly different, but perfectly good order. This is a bit of conjecture on my part, but you might see if using: -Xconversiontimeout 10000 results in a consistent output (though it might just take longer to produce a different output). Again, this generally does not matter because the rebuild is triggered on the changes observed by the -depends/-make options (-make is 3.1.3 by the way). Other possibilities might be that things are being stored in unordered List and their order is affected by the time, or something similar. I don't think that in general you would see this as in the general case the DAG and so on would guarantee the order and so the conversion routines and so on would not be allowed to rejig that. Here you are executing semantic predicate code that is being hoisted. Predicates are not allowed to have side effects, but if the order mattered, having ordered alts should do the trick I think (which you don't need for this of course): something: {input.LT(1).getText().startsWith('step')}? stepStuff | {input.LT(1).getText().startsWith('st')}? stStuff ; That said, other than having side effects in the predicates, I am having trouble coming up with anything that you would practically need to worry about such a thing for. Unless your grammar is huge (in terms of tokens, and perhaps even then), I would use real tokens rather than the string comparison, as that is going to be slow. This way, it is integer comparisons, and so when those things could be NCNAMES and not GE etc, they will be allowed (with the occasional inexpensive syntactic predicate to force the issue). You can see this (in moderation, in the latest JavaFX parser, which I presume you know where to find ;-). ncname : NCNAME | EQs | NEs | LTs .. etc; r1 : ncname (EQs|EQ) ncname ; EQ: '=='; EQs: 'eq'; There are quite a few ways to deal with this of course. Personally, I think we should go with 'quantum' tokens and am trying to get some time to implement it in a test branch before the ANTLR conference in a few weeks. Cheers, Jim
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "il-antlr-interest" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/il-antlr-interest?hl=en -~----------~----~----~----~------~----~------~--~--- |
List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
