FMParser improvment for DLTK Freemarker plugin

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

FMParser improvment for DLTK Freemarker plugin

angelozerr
Hi,

Today I'm developing a lot of features (like preview, run, debug,
model provider, configuration provider...) for the DLTK Freeemarker
plugin but I have not a lot worked on the basic Template editor
features :

* Error syntaxic
* Color syntaxic.
* Completion.

Indead I can't work about this important features because the first
problem is that FMParser is very restrictive : it stop on the first
error. I have studied another DLTK implementation (javascript, ruby,
python...) and each parser can manage serveral errors to display a
list of errors (and not the only one error).

DLTK use AST structure that it can be used after for refactoring,
search engine, outline....So the idea is to build an AST DLTK
Freemarker template to use it for refactoring, completion....

My first idea was to create FMParser and build AST structure form the
FMParser (by using freemarker.core.ast.ASTVisitor) :

User type some content in the template Editor -> FMParser -> AST
Freemarker DLTK.

But I think it's shame to do that, to improve performance we could having :

User type some content in the template Editor -> FMParser (wich create
AST DLTK structure).

To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
it's very dangerous to have 2 grammar (a grammar for standard FMParser
and a grammar for FMParser- AST DLTK). To resolve this problem, I
think we should having

1. Interface AST instead of Class AST (ex : having IOrExpression
interface instead of OrExpression class)
2 use factory into the grammar to create OrExpression :

Instead doing that :

----------
Expression Exp() :
{
Expression exp;
}
{
exp=OrExpression() {return exp;}
}----------

We could do that :

----------
IExpression Exp() :
{
IExpression exp;
}
{
exp=factory.newOrExpression() {return exp;}
}----------

factory could be implemented with AST Freemarker structure or with AST
DLTK structure

I know it's a big work and I tell me if you like this idea and if you
could help me to do that. I know that Jonathan prefer use FreeCC, but
he's very busy and I don't know which decision I must take.

Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
Jonathan to say that) that my work on the DLTK Freemarker plugin will
never used because Freemarker trunk will never done.

Daniel, Jonathan or Attila, could you help me with FMParser improvment ?

Thank a lot.

Regards Angelo

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

revusky
On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:

> Hi,
>
> Today I'm developing a lot of features (like preview, run, debug,
> model provider, configuration provider...) for the DLTK Freeemarker
> plugin but I have not a lot worked on the basic Template editor
> features :
>
> * Error syntaxic
> * Color syntaxic.
> * Completion.
>
> Indead I can't work about this important features because the first
> problem is that FMParser is very restrictive : it stop on the first
> error.

Yes, I am aware of these problems and I know I have to help you.

》I have studied another DLTK implementation (javascript, ruby,
> python...) and each parser can manage serveral errors to display a
> list of errors (and not the only one error).

I have developed some machinery to handle this actually, but I need to
look at how to make it work for you.

>
> DLTK use AST structure that it can be used after for refactoring,
> search engine, outline....So the idea is to build an AST DLTK
> Freemarker template to use it for refactoring, completion....

There should be the ability to build an AST even when there are some
errors. And that is feasible in reality. It is just a question of
having an AST element that is erroneous. Actually, it is basically two
kinds of erroneous element, an erroneous expression and an erroneous
directive.

But like, with an erroneous expression, if somebody writes:

<#if x == 2*(a+b >
...

note that the parenthesis is unclosed, one is able nonetheless to
store the invalid expression in an AST and still parse the whole
template into a tree.

I have already a lot of the machinery to do this. It is a question of
setting a switch so that the parser builds the tree and stores the
errors.

>
> My first idea was to create FMParser and build AST structure form the
> FMParser (by using freemarker.core.ast.ASTVisitor) :
>
> User type some content in the template Editor -> FMParser -> AST
> Freemarker DLTK.
>
> But I think it's shame to do that, to improve performance we could having :
>
> User type some content in the template Editor -> FMParser (wich create
> AST DLTK structure).

Well, I have anticipated a lot of this and there is a lot of the
machinery already.

By the way, this is another reason that was in the back of my mind for
working against the codebase in the SVN trunk. A lot of this kind of
stuff is already present (at least partially) because I was
anticipating making the whole thing more tool-friendly.

>
> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
> it's very dangerous to have 2 grammar (a grammar for standard FMParser
> and a grammar for FMParser- AST DLTK). To resolve this problem, I
> think we should having

No, there is no reason really for a separate grammar. We simply can
have the same parser with two modes of operation, one in which it
stops on errors and the other in which it keeps going, building a
tree, except that some of the elements in the tree are element types
that represent invalid directives or expressions.

>
> 1. Interface AST instead of Class AST (ex : having IOrExpression
> interface instead of OrExpression class)
> 2 use factory into the grammar to create OrExpression :

Yes, I see the lines you are thinking on and I have thought (it was a
while ago though and I have to remember what I did) about this. So, in
the next while, I'll try to go over my work from a couple of years ago
and explain what I did, what the approach was.

>
> Instead doing that :
>
> ----------
> Expression Exp() :
> {
> Expression exp;
> }
> {
> exp=OrExpression() {return exp;}
> }----------
>
> We could do that :
>
> ----------
> IExpression Exp() :
> {
> IExpression exp;
> }
> {
> exp=factory.newOrExpression() {return exp;}
> }----------
>
> factory could be implemented with AST Freemarker structure or with AST
> DLTK structure
>
> I know it's a big work and I tell me if you like this idea and if you
> could help me to do that. I know that Jonathan prefer use FreeCC, but
> he's very busy and I don't know which decision I must take.
>
> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
> Jonathan to say that) that my work on the DLTK Freemarker plugin will
> never used because Freemarker trunk will never done.

Well, the fact is that it really is done. We don't have the best test
suite in the world, but it actually does pass all the unit tests. Just
run ant test on it and you will see that.

Somehow, this community has talked itself into a state of paralysis on
the whole question. But in any case, if we work on things in the core
of 3.0 to support tooling like what you are doing, whatever bugs are
there will gradually be exposed.

However, the idea that this codebase is somehow so terribly buggy or
terribly incomplete is actually a fiction. It has not been exposed to
anything like the real-world stress-testing of 2.3.x, but that is kind
of a circular problem.

JR


>
> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>
> Thank a lot.
>
> Regards Angelo
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

Attila Szegedi-3
Yup, the parsing error recovery in 3.0 codebase is really nice. I think Angelo will like that very much :-)

Attila.

On 2010.06.23., at 12:32, Jonathan Revusky wrote:

> On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:
>> Hi,
>>
>> Today I'm developing a lot of features (like preview, run, debug,
>> model provider, configuration provider...) for the DLTK Freeemarker
>> plugin but I have not a lot worked on the basic Template editor
>> features :
>>
>> * Error syntaxic
>> * Color syntaxic.
>> * Completion.
>>
>> Indead I can't work about this important features because the first
>> problem is that FMParser is very restrictive : it stop on the first
>> error.
>
> Yes, I am aware of these problems and I know I have to help you.
>
> 》I have studied another DLTK implementation (javascript, ruby,
>> python...) and each parser can manage serveral errors to display a
>> list of errors (and not the only one error).
>
> I have developed some machinery to handle this actually, but I need to
> look at how to make it work for you.
>
>>
>> DLTK use AST structure that it can be used after for refactoring,
>> search engine, outline....So the idea is to build an AST DLTK
>> Freemarker template to use it for refactoring, completion....
>
> There should be the ability to build an AST even when there are some
> errors. And that is feasible in reality. It is just a question of
> having an AST element that is erroneous. Actually, it is basically two
> kinds of erroneous element, an erroneous expression and an erroneous
> directive.
>
> But like, with an erroneous expression, if somebody writes:
>
> <#if x == 2*(a+b >
> ...
>
> note that the parenthesis is unclosed, one is able nonetheless to
> store the invalid expression in an AST and still parse the whole
> template into a tree.
>
> I have already a lot of the machinery to do this. It is a question of
> setting a switch so that the parser builds the tree and stores the
> errors.
>
>>
>> My first idea was to create FMParser and build AST structure form the
>> FMParser (by using freemarker.core.ast.ASTVisitor) :
>>
>> User type some content in the template Editor -> FMParser -> AST
>> Freemarker DLTK.
>>
>> But I think it's shame to do that, to improve performance we could having :
>>
>> User type some content in the template Editor -> FMParser (wich create
>> AST DLTK structure).
>
> Well, I have anticipated a lot of this and there is a lot of the
> machinery already.
>
> By the way, this is another reason that was in the back of my mind for
> working against the codebase in the SVN trunk. A lot of this kind of
> stuff is already present (at least partially) because I was
> anticipating making the whole thing more tool-friendly.
>
>>
>> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
>> it's very dangerous to have 2 grammar (a grammar for standard FMParser
>> and a grammar for FMParser- AST DLTK). To resolve this problem, I
>> think we should having
>
> No, there is no reason really for a separate grammar. We simply can
> have the same parser with two modes of operation, one in which it
> stops on errors and the other in which it keeps going, building a
> tree, except that some of the elements in the tree are element types
> that represent invalid directives or expressions.
>
>>
>> 1. Interface AST instead of Class AST (ex : having IOrExpression
>> interface instead of OrExpression class)
>> 2 use factory into the grammar to create OrExpression :
>
> Yes, I see the lines you are thinking on and I have thought (it was a
> while ago though and I have to remember what I did) about this. So, in
> the next while, I'll try to go over my work from a couple of years ago
> and explain what I did, what the approach was.
>
>>
>> Instead doing that :
>>
>> ----------
>> Expression Exp() :
>> {
>> Expression exp;
>> }
>> {
>> exp=OrExpression() {return exp;}
>> }----------
>>
>> We could do that :
>>
>> ----------
>> IExpression Exp() :
>> {
>> IExpression exp;
>> }
>> {
>> exp=factory.newOrExpression() {return exp;}
>> }----------
>>
>> factory could be implemented with AST Freemarker structure or with AST
>> DLTK structure
>>
>> I know it's a big work and I tell me if you like this idea and if you
>> could help me to do that. I know that Jonathan prefer use FreeCC, but
>> he's very busy and I don't know which decision I must take.
>>
>> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
>> Jonathan to say that) that my work on the DLTK Freemarker plugin will
>> never used because Freemarker trunk will never done.
>
> Well, the fact is that it really is done. We don't have the best test
> suite in the world, but it actually does pass all the unit tests. Just
> run ant test on it and you will see that.
>
> Somehow, this community has talked itself into a state of paralysis on
> the whole question. But in any case, if we work on things in the core
> of 3.0 to support tooling like what you are doing, whatever bugs are
> there will gradually be exposed.
>
> However, the idea that this codebase is somehow so terribly buggy or
> terribly incomplete is actually a fiction. It has not been exposed to
> anything like the real-world stress-testing of 2.3.x, but that is kind
> of a circular problem.
>
> JR
>
>
>>
>> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>>
>> Thank a lot.
>>
>> Regards Angelo

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
Hi Attila, Jonathan,

Thank a lot for your answer!

My motivation is growing again:) I have so a lot of idea and I hope I
will be enable to finish this plugin. I'm waiting Jonathan answer to
start manage AST DLTK Freemarker. When AST DLTK Freemarker will be
implemented, we could have a lot of inetresting features like
overview, autocompletion syntaxic errors, refactoring, search....

Jonathan if FMParser can generate org.eclipse.dltk.ast.ASTNode
(instead of freemarker.core.parser.TemplateLocation), it should be
very great!

I'm waiting for your reply. Thank a lot for your help!

Regards Angelo

2010/6/23 Attila Szegedi <[hidden email]>:

> Yup, the parsing error recovery in 3.0 codebase is really nice. I think Angelo will like that very much :-)
>
> Attila.
>
> On 2010.06.23., at 12:32, Jonathan Revusky wrote:
>
>> On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:
>>> Hi,
>>>
>>> Today I'm developing a lot of features (like preview, run, debug,
>>> model provider, configuration provider...) for the DLTK Freeemarker
>>> plugin but I have not a lot worked on the basic Template editor
>>> features :
>>>
>>> * Error syntaxic
>>> * Color syntaxic.
>>> * Completion.
>>>
>>> Indead I can't work about this important features because the first
>>> problem is that FMParser is very restrictive : it stop on the first
>>> error.
>>
>> Yes, I am aware of these problems and I know I have to help you.
>>
>> 》I have studied another DLTK implementation (javascript, ruby,
>>> python...) and each parser can manage serveral errors to display a
>>> list of errors (and not the only one error).
>>
>> I have developed some machinery to handle this actually, but I need to
>> look at how to make it work for you.
>>
>>>
>>> DLTK use AST structure that it can be used after for refactoring,
>>> search engine, outline....So the idea is to build an AST DLTK
>>> Freemarker template to use it for refactoring, completion....
>>
>> There should be the ability to build an AST even when there are some
>> errors. And that is feasible in reality. It is just a question of
>> having an AST element that is erroneous. Actually, it is basically two
>> kinds of erroneous element, an erroneous expression and an erroneous
>> directive.
>>
>> But like, with an erroneous expression, if somebody writes:
>>
>> <#if x == 2*(a+b >
>> ...
>>
>> note that the parenthesis is unclosed, one is able nonetheless to
>> store the invalid expression in an AST and still parse the whole
>> template into a tree.
>>
>> I have already a lot of the machinery to do this. It is a question of
>> setting a switch so that the parser builds the tree and stores the
>> errors.
>>
>>>
>>> My first idea was to create FMParser and build AST structure form the
>>> FMParser (by using freemarker.core.ast.ASTVisitor) :
>>>
>>> User type some content in the template Editor -> FMParser -> AST
>>> Freemarker DLTK.
>>>
>>> But I think it's shame to do that, to improve performance we could having :
>>>
>>> User type some content in the template Editor -> FMParser (wich create
>>> AST DLTK structure).
>>
>> Well, I have anticipated a lot of this and there is a lot of the
>> machinery already.
>>
>> By the way, this is another reason that was in the back of my mind for
>> working against the codebase in the SVN trunk. A lot of this kind of
>> stuff is already present (at least partially) because I was
>> anticipating making the whole thing more tool-friendly.
>>
>>>
>>> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
>>> it's very dangerous to have 2 grammar (a grammar for standard FMParser
>>> and a grammar for FMParser- AST DLTK). To resolve this problem, I
>>> think we should having
>>
>> No, there is no reason really for a separate grammar. We simply can
>> have the same parser with two modes of operation, one in which it
>> stops on errors and the other in which it keeps going, building a
>> tree, except that some of the elements in the tree are element types
>> that represent invalid directives or expressions.
>>
>>>
>>> 1. Interface AST instead of Class AST (ex : having IOrExpression
>>> interface instead of OrExpression class)
>>> 2 use factory into the grammar to create OrExpression :
>>
>> Yes, I see the lines you are thinking on and I have thought (it was a
>> while ago though and I have to remember what I did) about this. So, in
>> the next while, I'll try to go over my work from a couple of years ago
>> and explain what I did, what the approach was.
>>
>>>
>>> Instead doing that :
>>>
>>> ----------
>>> Expression Exp() :
>>> {
>>> Expression exp;
>>> }
>>> {
>>> exp=OrExpression() {return exp;}
>>> }----------
>>>
>>> We could do that :
>>>
>>> ----------
>>> IExpression Exp() :
>>> {
>>> IExpression exp;
>>> }
>>> {
>>> exp=factory.newOrExpression() {return exp;}
>>> }----------
>>>
>>> factory could be implemented with AST Freemarker structure or with AST
>>> DLTK structure
>>>
>>> I know it's a big work and I tell me if you like this idea and if you
>>> could help me to do that. I know that Jonathan prefer use FreeCC, but
>>> he's very busy and I don't know which decision I must take.
>>>
>>> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
>>> Jonathan to say that) that my work on the DLTK Freemarker plugin will
>>> never used because Freemarker trunk will never done.
>>
>> Well, the fact is that it really is done. We don't have the best test
>> suite in the world, but it actually does pass all the unit tests. Just
>> run ant test on it and you will see that.
>>
>> Somehow, this community has talked itself into a state of paralysis on
>> the whole question. But in any case, if we work on things in the core
>> of 3.0 to support tooling like what you are doing, whatever bugs are
>> there will gradually be exposed.
>>
>> However, the idea that this codebase is somehow so terribly buggy or
>> terribly incomplete is actually a fiction. It has not been exposed to
>> anything like the real-world stress-testing of 2.3.x, but that is kind
>> of a circular problem.
>>
>> JR
>>
>>
>>>
>>> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>>>
>>> Thank a lot.
>>>
>>> Regards Angelo
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

revusky
On Wed, Jun 23, 2010 at 2:24 PM, Angelo zerr <[hidden email]> wrote:

> Hi Attila, Jonathan,
>
> Thank a lot for your answer!
>
> My motivation is growing again:) I have so a lot of idea and I hope I
> will be enable to finish this plugin. I'm waiting Jonathan answer to
> start manage AST DLTK Freemarker. When AST DLTK Freemarker will be
> implemented, we could have a lot of inetresting features like
> overview, autocompletion syntaxic errors, refactoring, search....
>
> Jonathan if FMParser can generate org.eclipse.dltk.ast.ASTNode
> (instead of freemarker.core.parser.TemplateLocation), it should be
> very great!

It might not be very hard to use the tree-walking API to walk over the
tree and generate an equivalent tree of ASTNode objects. You would
have something like the decorator pattern, where you have your DLTK
ASTNode implementation where the objects are basically wrapping an
underlying FreeMarker AST node.

To see the tree walking working, just look at the
freemarker.core.helpers package, like DefaultTreeDumper and
CanonicalizingTreeDumper for example. Of course, you would be doing
something completely different, but the principle is the same, you
write visit(....) methods for the various nodes, and to use the
tree-walking object, you just invoke the visit(...) method on the root
element of the template's AST.

JR


>
> I'm waiting for your reply. Thank a lot for your help!
>
> Regards Angelo
>
> 2010/6/23 Attila Szegedi <[hidden email]>:
>> Yup, the parsing error recovery in 3.0 codebase is really nice. I think Angelo will like that very much :-)
>>
>> Attila.
>>
>> On 2010.06.23., at 12:32, Jonathan Revusky wrote:
>>
>>> On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> Today I'm developing a lot of features (like preview, run, debug,
>>>> model provider, configuration provider...) for the DLTK Freeemarker
>>>> plugin but I have not a lot worked on the basic Template editor
>>>> features :
>>>>
>>>> * Error syntaxic
>>>> * Color syntaxic.
>>>> * Completion.
>>>>
>>>> Indead I can't work about this important features because the first
>>>> problem is that FMParser is very restrictive : it stop on the first
>>>> error.
>>>
>>> Yes, I am aware of these problems and I know I have to help you.
>>>
>>> 》I have studied another DLTK implementation (javascript, ruby,
>>>> python...) and each parser can manage serveral errors to display a
>>>> list of errors (and not the only one error).
>>>
>>> I have developed some machinery to handle this actually, but I need to
>>> look at how to make it work for you.
>>>
>>>>
>>>> DLTK use AST structure that it can be used after for refactoring,
>>>> search engine, outline....So the idea is to build an AST DLTK
>>>> Freemarker template to use it for refactoring, completion....
>>>
>>> There should be the ability to build an AST even when there are some
>>> errors. And that is feasible in reality. It is just a question of
>>> having an AST element that is erroneous. Actually, it is basically two
>>> kinds of erroneous element, an erroneous expression and an erroneous
>>> directive.
>>>
>>> But like, with an erroneous expression, if somebody writes:
>>>
>>> <#if x == 2*(a+b >
>>> ...
>>>
>>> note that the parenthesis is unclosed, one is able nonetheless to
>>> store the invalid expression in an AST and still parse the whole
>>> template into a tree.
>>>
>>> I have already a lot of the machinery to do this. It is a question of
>>> setting a switch so that the parser builds the tree and stores the
>>> errors.
>>>
>>>>
>>>> My first idea was to create FMParser and build AST structure form the
>>>> FMParser (by using freemarker.core.ast.ASTVisitor) :
>>>>
>>>> User type some content in the template Editor -> FMParser -> AST
>>>> Freemarker DLTK.
>>>>
>>>> But I think it's shame to do that, to improve performance we could having :
>>>>
>>>> User type some content in the template Editor -> FMParser (wich create
>>>> AST DLTK structure).
>>>
>>> Well, I have anticipated a lot of this and there is a lot of the
>>> machinery already.
>>>
>>> By the way, this is another reason that was in the back of my mind for
>>> working against the codebase in the SVN trunk. A lot of this kind of
>>> stuff is already present (at least partially) because I was
>>> anticipating making the whole thing more tool-friendly.
>>>
>>>>
>>>> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
>>>> it's very dangerous to have 2 grammar (a grammar for standard FMParser
>>>> and a grammar for FMParser- AST DLTK). To resolve this problem, I
>>>> think we should having
>>>
>>> No, there is no reason really for a separate grammar. We simply can
>>> have the same parser with two modes of operation, one in which it
>>> stops on errors and the other in which it keeps going, building a
>>> tree, except that some of the elements in the tree are element types
>>> that represent invalid directives or expressions.
>>>
>>>>
>>>> 1. Interface AST instead of Class AST (ex : having IOrExpression
>>>> interface instead of OrExpression class)
>>>> 2 use factory into the grammar to create OrExpression :
>>>
>>> Yes, I see the lines you are thinking on and I have thought (it was a
>>> while ago though and I have to remember what I did) about this. So, in
>>> the next while, I'll try to go over my work from a couple of years ago
>>> and explain what I did, what the approach was.
>>>
>>>>
>>>> Instead doing that :
>>>>
>>>> ----------
>>>> Expression Exp() :
>>>> {
>>>> Expression exp;
>>>> }
>>>> {
>>>> exp=OrExpression() {return exp;}
>>>> }----------
>>>>
>>>> We could do that :
>>>>
>>>> ----------
>>>> IExpression Exp() :
>>>> {
>>>> IExpression exp;
>>>> }
>>>> {
>>>> exp=factory.newOrExpression() {return exp;}
>>>> }----------
>>>>
>>>> factory could be implemented with AST Freemarker structure or with AST
>>>> DLTK structure
>>>>
>>>> I know it's a big work and I tell me if you like this idea and if you
>>>> could help me to do that. I know that Jonathan prefer use FreeCC, but
>>>> he's very busy and I don't know which decision I must take.
>>>>
>>>> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
>>>> Jonathan to say that) that my work on the DLTK Freemarker plugin will
>>>> never used because Freemarker trunk will never done.
>>>
>>> Well, the fact is that it really is done. We don't have the best test
>>> suite in the world, but it actually does pass all the unit tests. Just
>>> run ant test on it and you will see that.
>>>
>>> Somehow, this community has talked itself into a state of paralysis on
>>> the whole question. But in any case, if we work on things in the core
>>> of 3.0 to support tooling like what you are doing, whatever bugs are
>>> there will gradually be exposed.
>>>
>>> However, the idea that this codebase is somehow so terribly buggy or
>>> terribly incomplete is actually a fiction. It has not been exposed to
>>> anything like the real-world stress-testing of 2.3.x, but that is kind
>>> of a circular problem.
>>>
>>> JR
>>>
>>>
>>>>
>>>> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>>>>
>>>> Thank a lot.
>>>>
>>>> Regards Angelo
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> FreeMarker-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
Jonathan,

I have started to transform FM AST 2 DLTK AST with
AssignmentInstruction  (ex : <#assign name = true />)

You can see that here :

https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/parser/visitors/DLTKFreemarkerASTVisitor.java

Now I can display the name variable into Outline View by using DLTK
and when I click on variable name from outline it must select the name
variable from the template editor. But it doesn' works because I have
not the information about start/end offset of the variable name. See
FIXME problem :

@Override
        public void visit(AssignmentInstruction node) {

                IState root = states.peek();
                List<String> varNames = node.getVarNames();
                List<Expression> values = node.getValues();
                for (int i = 0; i < varNames.size(); i++) {
                        String varname = varNames.get(i);
                        // Expression valueExp = values.get(i);
                        // TemplateModel value = valueExp.getAsTemplateModel(null);
                        // valueExp.literalValue();

                        VariableKind variableKind = VariableKind.UNKNOWN;
                        int type = node.type;
                        switch (type) {
                        case AssignmentInstruction.GLOBAL:
                                variableKind = VariableKind.GLOBAL;
                                break;
                        case AssignmentInstruction.LOCAL:
                                variableKind = VariableKind.LOCAL;
                                break;
                        case AssignmentInstruction.NAMESPACE:
                                variableKind = VariableKind.GLOBAL;
                                break;
                        case AssignmentInstruction.SET:
                                variableKind = VariableKind.LOCAL;
                                break;
                        }

                        int start = node.getBeginColumnTabAdjusted();
                        int end = node.getEndColumnTabAdjusted();

                        // FIXME : compute start/end corretly
                        Statement left = new VariableReference(start, end, varname,
                                        variableKind);
                        // FIXME : compute start/end corretly + var value
                        Statement right = new VariableReference(6, 7, "TODO",
                                        VariableKind.ARGUMENT);
                        Assignment assignment = new Assignment(left, right);
                        root.add(assignment);
                }

        }

It exists some methods like getBeginColumnTabAdjusted, getBeginLine...
but it doesn't give me start/end offset of the variable name.

Jonathan, could you help me with this problem. Thanks

Angelo

2010/6/23 Jonathan Revusky <[hidden email]>:

> On Wed, Jun 23, 2010 at 2:24 PM, Angelo zerr <[hidden email]> wrote:
>> Hi Attila, Jonathan,
>>
>> Thank a lot for your answer!
>>
>> My motivation is growing again:) I have so a lot of idea and I hope I
>> will be enable to finish this plugin. I'm waiting Jonathan answer to
>> start manage AST DLTK Freemarker. When AST DLTK Freemarker will be
>> implemented, we could have a lot of inetresting features like
>> overview, autocompletion syntaxic errors, refactoring, search....
>>
>> Jonathan if FMParser can generate org.eclipse.dltk.ast.ASTNode
>> (instead of freemarker.core.parser.TemplateLocation), it should be
>> very great!
>
> It might not be very hard to use the tree-walking API to walk over the
> tree and generate an equivalent tree of ASTNode objects. You would
> have something like the decorator pattern, where you have your DLTK
> ASTNode implementation where the objects are basically wrapping an
> underlying FreeMarker AST node.
>
> To see the tree walking working, just look at the
> freemarker.core.helpers package, like DefaultTreeDumper and
> CanonicalizingTreeDumper for example. Of course, you would be doing
> something completely different, but the principle is the same, you
> write visit(....) methods for the various nodes, and to use the
> tree-walking object, you just invoke the visit(...) method on the root
> element of the template's AST.
>
> JR
>
>
>>
>> I'm waiting for your reply. Thank a lot for your help!
>>
>> Regards Angelo
>>
>> 2010/6/23 Attila Szegedi <[hidden email]>:
>>> Yup, the parsing error recovery in 3.0 codebase is really nice. I think Angelo will like that very much :-)
>>>
>>> Attila.
>>>
>>> On 2010.06.23., at 12:32, Jonathan Revusky wrote:
>>>
>>>> On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> Today I'm developing a lot of features (like preview, run, debug,
>>>>> model provider, configuration provider...) for the DLTK Freeemarker
>>>>> plugin but I have not a lot worked on the basic Template editor
>>>>> features :
>>>>>
>>>>> * Error syntaxic
>>>>> * Color syntaxic.
>>>>> * Completion.
>>>>>
>>>>> Indead I can't work about this important features because the first
>>>>> problem is that FMParser is very restrictive : it stop on the first
>>>>> error.
>>>>
>>>> Yes, I am aware of these problems and I know I have to help you.
>>>>
>>>> 》I have studied another DLTK implementation (javascript, ruby,
>>>>> python...) and each parser can manage serveral errors to display a
>>>>> list of errors (and not the only one error).
>>>>
>>>> I have developed some machinery to handle this actually, but I need to
>>>> look at how to make it work for you.
>>>>
>>>>>
>>>>> DLTK use AST structure that it can be used after for refactoring,
>>>>> search engine, outline....So the idea is to build an AST DLTK
>>>>> Freemarker template to use it for refactoring, completion....
>>>>
>>>> There should be the ability to build an AST even when there are some
>>>> errors. And that is feasible in reality. It is just a question of
>>>> having an AST element that is erroneous. Actually, it is basically two
>>>> kinds of erroneous element, an erroneous expression and an erroneous
>>>> directive.
>>>>
>>>> But like, with an erroneous expression, if somebody writes:
>>>>
>>>> <#if x == 2*(a+b >
>>>> ...
>>>>
>>>> note that the parenthesis is unclosed, one is able nonetheless to
>>>> store the invalid expression in an AST and still parse the whole
>>>> template into a tree.
>>>>
>>>> I have already a lot of the machinery to do this. It is a question of
>>>> setting a switch so that the parser builds the tree and stores the
>>>> errors.
>>>>
>>>>>
>>>>> My first idea was to create FMParser and build AST structure form the
>>>>> FMParser (by using freemarker.core.ast.ASTVisitor) :
>>>>>
>>>>> User type some content in the template Editor -> FMParser -> AST
>>>>> Freemarker DLTK.
>>>>>
>>>>> But I think it's shame to do that, to improve performance we could having :
>>>>>
>>>>> User type some content in the template Editor -> FMParser (wich create
>>>>> AST DLTK structure).
>>>>
>>>> Well, I have anticipated a lot of this and there is a lot of the
>>>> machinery already.
>>>>
>>>> By the way, this is another reason that was in the back of my mind for
>>>> working against the codebase in the SVN trunk. A lot of this kind of
>>>> stuff is already present (at least partially) because I was
>>>> anticipating making the whole thing more tool-friendly.
>>>>
>>>>>
>>>>> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
>>>>> it's very dangerous to have 2 grammar (a grammar for standard FMParser
>>>>> and a grammar for FMParser- AST DLTK). To resolve this problem, I
>>>>> think we should having
>>>>
>>>> No, there is no reason really for a separate grammar. We simply can
>>>> have the same parser with two modes of operation, one in which it
>>>> stops on errors and the other in which it keeps going, building a
>>>> tree, except that some of the elements in the tree are element types
>>>> that represent invalid directives or expressions.
>>>>
>>>>>
>>>>> 1. Interface AST instead of Class AST (ex : having IOrExpression
>>>>> interface instead of OrExpression class)
>>>>> 2 use factory into the grammar to create OrExpression :
>>>>
>>>> Yes, I see the lines you are thinking on and I have thought (it was a
>>>> while ago though and I have to remember what I did) about this. So, in
>>>> the next while, I'll try to go over my work from a couple of years ago
>>>> and explain what I did, what the approach was.
>>>>
>>>>>
>>>>> Instead doing that :
>>>>>
>>>>> ----------
>>>>> Expression Exp() :
>>>>> {
>>>>> Expression exp;
>>>>> }
>>>>> {
>>>>> exp=OrExpression() {return exp;}
>>>>> }----------
>>>>>
>>>>> We could do that :
>>>>>
>>>>> ----------
>>>>> IExpression Exp() :
>>>>> {
>>>>> IExpression exp;
>>>>> }
>>>>> {
>>>>> exp=factory.newOrExpression() {return exp;}
>>>>> }----------
>>>>>
>>>>> factory could be implemented with AST Freemarker structure or with AST
>>>>> DLTK structure
>>>>>
>>>>> I know it's a big work and I tell me if you like this idea and if you
>>>>> could help me to do that. I know that Jonathan prefer use FreeCC, but
>>>>> he's very busy and I don't know which decision I must take.
>>>>>
>>>>> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
>>>>> Jonathan to say that) that my work on the DLTK Freemarker plugin will
>>>>> never used because Freemarker trunk will never done.
>>>>
>>>> Well, the fact is that it really is done. We don't have the best test
>>>> suite in the world, but it actually does pass all the unit tests. Just
>>>> run ant test on it and you will see that.
>>>>
>>>> Somehow, this community has talked itself into a state of paralysis on
>>>> the whole question. But in any case, if we work on things in the core
>>>> of 3.0 to support tooling like what you are doing, whatever bugs are
>>>> there will gradually be exposed.
>>>>
>>>> However, the idea that this codebase is somehow so terribly buggy or
>>>> terribly incomplete is actually a fiction. It has not been exposed to
>>>> anything like the real-world stress-testing of 2.3.x, but that is kind
>>>> of a circular problem.
>>>>
>>>> JR
>>>>
>>>>
>>>>>
>>>>> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>>>>>
>>>>> Thank a lot.
>>>>>
>>>>> Regards Angelo
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> FreeMarker-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> FreeMarker-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

revusky
On Wed, Jun 23, 2010 at 11:36 PM, Angelo zerr <[hidden email]> wrote:

> Jonathan,
>
> I have started to transform FM AST 2 DLTK AST with
> AssignmentInstruction  (ex : <#assign name = true />)
>
> You can see that here :
>
> https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/parser/visitors/DLTKFreemarkerASTVisitor.java
>
> Now I can display the name variable into Outline View by using DLTK
> and when I click on variable name from outline it must select the name
> variable from the template editor. But it doesn' works because I have
> not the information about start/end offset of the variable name. See
> FIXME problem :
>
> @Override
>        public void visit(AssignmentInstruction node) {
>
>                IState root = states.peek();
>                List<String> varNames = node.getVarNames();
>                List<Expression> values = node.getValues();
>                for (int i = 0; i < varNames.size(); i++) {
>                        String varname = varNames.get(i);
>                        // Expression valueExp = values.get(i);
>                        // TemplateModel value = valueExp.getAsTemplateModel(null);
>                        // valueExp.literalValue();
>
>                        VariableKind variableKind = VariableKind.UNKNOWN;
>                        int type = node.type;
>                        switch (type) {
>                        case AssignmentInstruction.GLOBAL:
>                                variableKind = VariableKind.GLOBAL;
>                                break;
>                        case AssignmentInstruction.LOCAL:
>                                variableKind = VariableKind.LOCAL;
>                                break;
>                        case AssignmentInstruction.NAMESPACE:
>                                variableKind = VariableKind.GLOBAL;
>                                break;
>                        case AssignmentInstruction.SET:
>                                variableKind = VariableKind.LOCAL;
>                                break;
>                        }
>
>                        int start = node.getBeginColumnTabAdjusted();
>                        int end = node.getEndColumnTabAdjusted();
>
>                        // FIXME : compute start/end corretly
>                        Statement left = new VariableReference(start, end, varname,
>                                        variableKind);
>                        // FIXME : compute start/end corretly + var value
>                        Statement right = new VariableReference(6, 7, "TODO",
>                                        VariableKind.ARGUMENT);
>                        Assignment assignment = new Assignment(left, right);
>                        root.add(assignment);
>                }
>
>        }
>
> It exists some methods like getBeginColumnTabAdjusted, getBeginLine...
> but it doesn't give me start/end offset of the variable name.
>
> Jonathan, could you help me with this problem. Thanks

Okay, I'll look into it fairly soon. The problem is that the system is
only storing location information in terms of line and column, not the
absolute offset in the entire file. I think that could be
reconstructed, so one solution is to just walk the tree (as you see
the machinery for) and fill in the info in a post-parse step.

The other solution is to hack freecc so that it fills in the absolute
offset location as well as line/column. Actually that is probably the
best solution since there may be other uses of freecc where it is
useful to store absolute file offset locations.

JR


>
> Angelo
>
> 2010/6/23 Jonathan Revusky <[hidden email]>:
>> On Wed, Jun 23, 2010 at 2:24 PM, Angelo zerr <[hidden email]> wrote:
>>> Hi Attila, Jonathan,
>>>
>>> Thank a lot for your answer!
>>>
>>> My motivation is growing again:) I have so a lot of idea and I hope I
>>> will be enable to finish this plugin. I'm waiting Jonathan answer to
>>> start manage AST DLTK Freemarker. When AST DLTK Freemarker will be
>>> implemented, we could have a lot of inetresting features like
>>> overview, autocompletion syntaxic errors, refactoring, search....
>>>
>>> Jonathan if FMParser can generate org.eclipse.dltk.ast.ASTNode
>>> (instead of freemarker.core.parser.TemplateLocation), it should be
>>> very great!
>>
>> It might not be very hard to use the tree-walking API to walk over the
>> tree and generate an equivalent tree of ASTNode objects. You would
>> have something like the decorator pattern, where you have your DLTK
>> ASTNode implementation where the objects are basically wrapping an
>> underlying FreeMarker AST node.
>>
>> To see the tree walking working, just look at the
>> freemarker.core.helpers package, like DefaultTreeDumper and
>> CanonicalizingTreeDumper for example. Of course, you would be doing
>> something completely different, but the principle is the same, you
>> write visit(....) methods for the various nodes, and to use the
>> tree-walking object, you just invoke the visit(...) method on the root
>> element of the template's AST.
>>
>> JR
>>
>>
>>>
>>> I'm waiting for your reply. Thank a lot for your help!
>>>
>>> Regards Angelo
>>>
>>> 2010/6/23 Attila Szegedi <[hidden email]>:
>>>> Yup, the parsing error recovery in 3.0 codebase is really nice. I think Angelo will like that very much :-)
>>>>
>>>> Attila.
>>>>
>>>> On 2010.06.23., at 12:32, Jonathan Revusky wrote:
>>>>
>>>>> On Wed, Jun 23, 2010 at 11:35 AM, Angelo zerr <[hidden email]> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Today I'm developing a lot of features (like preview, run, debug,
>>>>>> model provider, configuration provider...) for the DLTK Freeemarker
>>>>>> plugin but I have not a lot worked on the basic Template editor
>>>>>> features :
>>>>>>
>>>>>> * Error syntaxic
>>>>>> * Color syntaxic.
>>>>>> * Completion.
>>>>>>
>>>>>> Indead I can't work about this important features because the first
>>>>>> problem is that FMParser is very restrictive : it stop on the first
>>>>>> error.
>>>>>
>>>>> Yes, I am aware of these problems and I know I have to help you.
>>>>>
>>>>> 》I have studied another DLTK implementation (javascript, ruby,
>>>>>> python...) and each parser can manage serveral errors to display a
>>>>>> list of errors (and not the only one error).
>>>>>
>>>>> I have developed some machinery to handle this actually, but I need to
>>>>> look at how to make it work for you.
>>>>>
>>>>>>
>>>>>> DLTK use AST structure that it can be used after for refactoring,
>>>>>> search engine, outline....So the idea is to build an AST DLTK
>>>>>> Freemarker template to use it for refactoring, completion....
>>>>>
>>>>> There should be the ability to build an AST even when there are some
>>>>> errors. And that is feasible in reality. It is just a question of
>>>>> having an AST element that is erroneous. Actually, it is basically two
>>>>> kinds of erroneous element, an erroneous expression and an erroneous
>>>>> directive.
>>>>>
>>>>> But like, with an erroneous expression, if somebody writes:
>>>>>
>>>>> <#if x == 2*(a+b >
>>>>> ...
>>>>>
>>>>> note that the parenthesis is unclosed, one is able nonetheless to
>>>>> store the invalid expression in an AST and still parse the whole
>>>>> template into a tree.
>>>>>
>>>>> I have already a lot of the machinery to do this. It is a question of
>>>>> setting a switch so that the parser builds the tree and stores the
>>>>> errors.
>>>>>
>>>>>>
>>>>>> My first idea was to create FMParser and build AST structure form the
>>>>>> FMParser (by using freemarker.core.ast.ASTVisitor) :
>>>>>>
>>>>>> User type some content in the template Editor -> FMParser -> AST
>>>>>> Freemarker DLTK.
>>>>>>
>>>>>> But I think it's shame to do that, to improve performance we could having :
>>>>>>
>>>>>> User type some content in the template Editor -> FMParser (wich create
>>>>>> AST DLTK structure).
>>>>>
>>>>> Well, I have anticipated a lot of this and there is a lot of the
>>>>> machinery already.
>>>>>
>>>>> By the way, this is another reason that was in the back of my mind for
>>>>> working against the codebase in the SVN trunk. A lot of this kind of
>>>>> stuff is already present (at least partially) because I was
>>>>> anticipating making the whole thing more tool-friendly.
>>>>>
>>>>>>
>>>>>> To do that, Freemarker grammar (JavaCC or Freec) must be changed, but
>>>>>> it's very dangerous to have 2 grammar (a grammar for standard FMParser
>>>>>> and a grammar for FMParser- AST DLTK). To resolve this problem, I
>>>>>> think we should having
>>>>>
>>>>> No, there is no reason really for a separate grammar. We simply can
>>>>> have the same parser with two modes of operation, one in which it
>>>>> stops on errors and the other in which it keeps going, building a
>>>>> tree, except that some of the elements in the tree are element types
>>>>> that represent invalid directives or expressions.
>>>>>
>>>>>>
>>>>>> 1. Interface AST instead of Class AST (ex : having IOrExpression
>>>>>> interface instead of OrExpression class)
>>>>>> 2 use factory into the grammar to create OrExpression :
>>>>>
>>>>> Yes, I see the lines you are thinking on and I have thought (it was a
>>>>> while ago though and I have to remember what I did) about this. So, in
>>>>> the next while, I'll try to go over my work from a couple of years ago
>>>>> and explain what I did, what the approach was.
>>>>>
>>>>>>
>>>>>> Instead doing that :
>>>>>>
>>>>>> ----------
>>>>>> Expression Exp() :
>>>>>> {
>>>>>> Expression exp;
>>>>>> }
>>>>>> {
>>>>>> exp=OrExpression() {return exp;}
>>>>>> }----------
>>>>>>
>>>>>> We could do that :
>>>>>>
>>>>>> ----------
>>>>>> IExpression Exp() :
>>>>>> {
>>>>>> IExpression exp;
>>>>>> }
>>>>>> {
>>>>>> exp=factory.newOrExpression() {return exp;}
>>>>>> }----------
>>>>>>
>>>>>> factory could be implemented with AST Freemarker structure or with AST
>>>>>> DLTK structure
>>>>>>
>>>>>> I know it's a big work and I tell me if you like this idea and if you
>>>>>> could help me to do that. I know that Jonathan prefer use FreeCC, but
>>>>>> he's very busy and I don't know which decision I must take.
>>>>>>
>>>>>> Today I'm using Freemarker trunk with FreeCC, but I'm afraid (sorry
>>>>>> Jonathan to say that) that my work on the DLTK Freemarker plugin will
>>>>>> never used because Freemarker trunk will never done.
>>>>>
>>>>> Well, the fact is that it really is done. We don't have the best test
>>>>> suite in the world, but it actually does pass all the unit tests. Just
>>>>> run ant test on it and you will see that.
>>>>>
>>>>> Somehow, this community has talked itself into a state of paralysis on
>>>>> the whole question. But in any case, if we work on things in the core
>>>>> of 3.0 to support tooling like what you are doing, whatever bugs are
>>>>> there will gradually be exposed.
>>>>>
>>>>> However, the idea that this codebase is somehow so terribly buggy or
>>>>> terribly incomplete is actually a fiction. It has not been exposed to
>>>>> anything like the real-world stress-testing of 2.3.x, but that is kind
>>>>> of a circular problem.
>>>>>
>>>>> JR
>>>>>
>>>>>
>>>>>>
>>>>>> Daniel, Jonathan or Attila, could you help me with FMParser improvment ?
>>>>>>
>>>>>> Thank a lot.
>>>>>>
>>>>>> Regards Angelo
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> FreeMarker-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>> _______________________________________________
>>> FreeMarker-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> FreeMarker-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
> Okay, I'll look into it fairly soon.
Thank you very much!

> The problem is that the system is
> only storing location information in terms of line and column, not the
> absolute offset in the entire file. I think that could be
> reconstructed, so one solution is to just walk the tree (as you see
> the machinery for) and fill in the info in a post-parse step.
>
> The other solution is to hack freecc so that it fills in the absolute
> offset location as well as line/column. Actually that is probably the
> best solution since there may be other uses of freecc where it is
> useful to store absolute file offset locations.
>

IHMO I think it should better that FreeCC manage start/end offset. I
have the same problem with syntaxic errors . The
freemarker.core.parser.Token coming from ParseException#currentToken
doesn't manage start/end offset. And I need this information to add
error Marker on the Freemarker Editor. Today, I'm computing start/end
offset by using beginLine, beginColumn, endLine, endColumn of the
Token. I must iterate each character of the template to compute it.
(see https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/parser/FreemarkerSourceParser.java
where I use https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/util/TokenUtils.java)

I would like remove this awfull TokenUtils if FreeCC managestart/end
offset. I believe Antlr manage this features (a lot of DLTK
implementation (XQuery, Ruby...) is based on Antlr and it get the
start/end location from the Antlr Token.

Angelo

> JR
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

revusky
On Thu, Jun 24, 2010 at 2:12 PM, Angelo zerr <[hidden email]> wrote:

>> Okay, I'll look into it fairly soon.
> Thank you very much!
>
>> The problem is that the system is
>> only storing location information in terms of line and column, not the
>> absolute offset in the entire file. I think that could be
>> reconstructed, so one solution is to just walk the tree (as you see
>> the machinery for) and fill in the info in a post-parse step.
>>
>> The other solution is to hack freecc so that it fills in the absolute
>> offset location as well as line/column. Actually that is probably the
>> best solution since there may be other uses of freecc where it is
>> useful to store absolute file offset locations.
>>
>
> IHMO I think it should better that FreeCC manage start/end offset. I
> have the same problem with syntaxic errors . The
> freemarker.core.parser.Token coming from ParseException#currentToken
> doesn't manage start/end offset. And I need this information to add
> error Marker on the Freemarker Editor. Today, I'm computing start/end
> offset by using beginLine, beginColumn, endLine, endColumn of the
> Token. I must iterate each character of the template to compute it.
> (see https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/parser/FreemarkerSourceParser.java
> where I use https://freemarker.svn.sourceforge.net/svnroot/freemarker/sandbox/org.eclipse.dltk.freemarker/org.eclipse.dltk.freemarker.core/src/org/eclipse/dltk/freemarker/internal/core/util/TokenUtils.java)
>
> I would like remove this awfull TokenUtils if FreeCC managestart/end
> offset. I believe Antlr manage this features (a lot of DLTK
> implementation (XQuery, Ruby...) is based on Antlr and it get the
> start/end location from the Antlr Token.

Well, it's not a difficult problem really. For now, I guess you can
calculate the absolute location of a Token or other element somehow,
just do it and store it maybe in a hash table somewhere.

But that is a temporary ad hoc solution of course. I will look into a
clean general solution fairly soon. I promise you that. :-)

JR



>
> Angelo
>
>> JR
>>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
>
> Well, it's not a difficult problem really. For now, I guess you can
> calculate the absolute location of a Token or other element somehow,
> just do it and store it maybe in a hash table somewhere.
>
> But that is a temporary ad hoc solution of course. I will look into a
> clean general solution fairly soon. I promise you that. :-)
>
Yes I prefer waiting your work before continuing to manage start/end
offset. I have a lot of work about Configuration+Model provider.
Many thanks Jonathan:)

Angelo

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit.  See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
Hi,

I would like know if you think you will have time to improve FM Parser
(Jonathan (sorry for the harass)?). I don't want have disturb with
you, but if FM Parser is not improved, I can not continue my work on
DLTK Freemarker Plugin and I will stop the development. I know you are
very busy, but I'm afraid that you (Attila for the debugger, Jonathan
for the FM Parser) you have not time to work on Freemarker project.

I have a lot learnt with you and with DLTK but I prefer stop my work
if Freemarker will not improved to manage debugger or parser. The need
is about :

1. FM Parser is :
  1.1 manage start/end offset for teh whole token (even for the
Interpolation token). I must create DLTK AST Node by using FM Parser;
This AST is used for a lot of thing (completion, refactoring,
serach...)
  1.2 : parser must be tolerant, otherwise AST Node will be broken as
soon as user type some content.

2. Debuggeur API :
  I have started to change the debugger API but I would like speak
with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
node).

Tell me you think you will have time (I'm very sorry to harass you to
improve FM Parser, but I prefer stop my work if there is no chance
that the improvment can be done. Or I will stop my work now and I'm
waiting for you will improve the FM Parser).

Regards Angelo
2010/6/24 Angelo zerr <[hidden email]>:

>>
>> Well, it's not a difficult problem really. For now, I guess you can
>> calculate the absolute location of a Token or other element somehow,
>> just do it and store it maybe in a hash table somewhere.
>>
>> But that is a temporary ad hoc solution of course. I will look into a
>> clean general solution fairly soon. I promise you that. :-)
>>
> Yes I prefer waiting your work before continuing to manage start/end
> offset. I have a lot of work about Configuration+Model provider.
> Many thanks Jonathan:)
>
> Angelo
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

revusky
On Sun, Jul 18, 2010 at 2:52 PM, Angelo zerr <[hidden email]> wrote:
> Hi,
>
> I would like know if you think you will have time to improve FM Parser
> (Jonathan (sorry for the harass)?). I don't want have disturb with
> you, but if FM Parser is not improved, I can not continue my work on
> DLTK Freemarker Plugin and I will stop the development. I know you are
> very busy, but I'm afraid that you (Attila for the debugger, Jonathan
> for the FM Parser) you have not time to work on Freemarker project.

I'm very wary of making promises now, but it is very likely I will
spend some time on this pretty soon. You see, I am going to California
on Wednesday for 6 weeks and, at least for most of the time there, I
have little to do but work on code. I will be at my parents' house
there in San Diego. (If anybody is in the area there and wants to meet
me, feel free to write.)

I do not think that the changes you need on the parser side are very
big, so once I do get into it again, it shouldn't be very long before
you have what you need.

As for Attila, obviously, I cannot speak for him. (He is actually
right here in the next room, as I write you though.)

We were talking about FreeMarker and we both agree (I am not sure what
Daniel will say) that we need to get the 2.4 (or 3.0 or whatever)
release cycle going again, and start putting out some releases.

JR

>
> I have a lot learnt with you and with DLTK but I prefer stop my work
> if Freemarker will not improved to manage debugger or parser. The need
> is about :
>
> 1. FM Parser is :
>  1.1 manage start/end offset for teh whole token (even for the
> Interpolation token). I must create DLTK AST Node by using FM Parser;
> This AST is used for a lot of thing (completion, refactoring,
> serach...)
>  1.2 : parser must be tolerant, otherwise AST Node will be broken as
> soon as user type some content.
>
> 2. Debuggeur API :
>  I have started to change the debugger API but I would like speak
> with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
> node).
>
> Tell me you think you will have time (I'm very sorry to harass you to
> improve FM Parser, but I prefer stop my work if there is no chance
> that the improvment can be done. Or I will stop my work now and I'm
> waiting for you will improve the FM Parser).
>
> Regards Angelo
> 2010/6/24 Angelo zerr <[hidden email]>:
>>>
>>> Well, it's not a difficult problem really. For now, I guess you can
>>> calculate the absolute location of a Token or other element somehow,
>>> just do it and store it maybe in a hash table somewhere.
>>>
>>> But that is a temporary ad hoc solution of course. I will look into a
>>> clean general solution fairly soon. I promise you that. :-)
>>>
>> Yes I prefer waiting your work before continuing to manage start/end
>> offset. I have a lot of work about Configuration+Model provider.
>> Many thanks Jonathan:)
>>
>> Angelo
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

Attila Szegedi-3
In reply to this post by angelozerr
On 2010.07.18., at 14:52, Angelo zerr wrote:

> 2. Debuggeur API :
>  I have started to change the debugger API but I would like speak
> with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
> node).

I don't think anyone in particular depends on that debugger code. I don't mind if you rewrite whatever needs rewriting in it. If you have some concrete concern, please voice it.

Attila.


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
In reply to this post by revusky
Thank's Jonathan for your answer. I stop my work on Freemarker Plugin
and I will restart as soon as FM Parser will be improved.

Angelo

2010/7/19 Jonathan Revusky <[hidden email]>:

> On Sun, Jul 18, 2010 at 2:52 PM, Angelo zerr <[hidden email]> wrote:
>> Hi,
>>
>> I would like know if you think you will have time to improve FM Parser
>> (Jonathan (sorry for the harass)?). I don't want have disturb with
>> you, but if FM Parser is not improved, I can not continue my work on
>> DLTK Freemarker Plugin and I will stop the development. I know you are
>> very busy, but I'm afraid that you (Attila for the debugger, Jonathan
>> for the FM Parser) you have not time to work on Freemarker project.
>
> I'm very wary of making promises now, but it is very likely I will
> spend some time on this pretty soon. You see, I am going to California
> on Wednesday for 6 weeks and, at least for most of the time there, I
> have little to do but work on code. I will be at my parents' house
> there in San Diego. (If anybody is in the area there and wants to meet
> me, feel free to write.)
>
> I do not think that the changes you need on the parser side are very
> big, so once I do get into it again, it shouldn't be very long before
> you have what you need.
>
> As for Attila, obviously, I cannot speak for him. (He is actually
> right here in the next room, as I write you though.)
>
> We were talking about FreeMarker and we both agree (I am not sure what
> Daniel will say) that we need to get the 2.4 (or 3.0 or whatever)
> release cycle going again, and start putting out some releases.
>
> JR
>
>>
>> I have a lot learnt with you and with DLTK but I prefer stop my work
>> if Freemarker will not improved to manage debugger or parser. The need
>> is about :
>>
>> 1. FM Parser is :
>>  1.1 manage start/end offset for teh whole token (even for the
>> Interpolation token). I must create DLTK AST Node by using FM Parser;
>> This AST is used for a lot of thing (completion, refactoring,
>> serach...)
>>  1.2 : parser must be tolerant, otherwise AST Node will be broken as
>> soon as user type some content.
>>
>> 2. Debuggeur API :
>>  I have started to change the debugger API but I would like speak
>> with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
>> node).
>>
>> Tell me you think you will have time (I'm very sorry to harass you to
>> improve FM Parser, but I prefer stop my work if there is no chance
>> that the improvment can be done. Or I will stop my work now and I'm
>> waiting for you will improve the FM Parser).
>>
>> Regards Angelo
>> 2010/6/24 Angelo zerr <[hidden email]>:
>>>>
>>>> Well, it's not a difficult problem really. For now, I guess you can
>>>> calculate the absolute location of a Token or other element somehow,
>>>> just do it and store it maybe in a hash table somewhere.
>>>>
>>>> But that is a temporary ad hoc solution of course. I will look into a
>>>> clean general solution fairly soon. I promise you that. :-)
>>>>
>>> Yes I prefer waiting your work before continuing to manage start/end
>>> offset. I have a lot of work about Configuration+Model provider.
>>> Many thanks Jonathan:)
>>>
>>> Angelo
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> FreeMarker-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
In reply to this post by Attila Szegedi-3
2010/7/19 Attila Szegedi <[hidden email]>:
> On 2010.07.18., at 14:52, Angelo zerr wrote:
>
>> 2. Debuggeur API :
>>  I have started to change the debugger API but I would like speak
>> with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
>> node).
>

Thank's Attila for your answer.

Sorry for my big error. I mean "like add breakpoint to a Mixed node"

> I don't think anyone in particular depends on that debugger code. I don't mind if you rewrite whatever needs rewriting in it. If you have some concrete concern, please voice it.

I have used your work and updated your code to manage any debugger.
I'm creating a new post to explain you my modification.

Angelo

>
> Attila.
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> FreeMarker-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

angelozerr
Ok Attila, I have created new post at
http://freemarker.624813.n4.nabble.com/FM-Debugger-Improvement-td2294149.html#a2294149
which explains FM Debugger API problem.

Angelo

2010/7/19 Angelo zerr <[hidden email]>:

> 2010/7/19 Attila Szegedi <[hidden email]>:
>> On 2010.07.18., at 14:52, Angelo zerr wrote:
>>
>>> 2. Debuggeur API :
>>>  I have started to change the debugger API but I would like speak
>>> with Attila. Debugger has some bugs (like ass breakpoint to a Mixed
>>> node).
>>
>
> Thank's Attila for your answer.
>
> Sorry for my big error. I mean "like add breakpoint to a Mixed node"
>
>> I don't think anyone in particular depends on that debugger code. I don't mind if you rewrite whatever needs rewriting in it. If you have some concrete concern, please voice it.
>
> I have used your work and updated your code to manage any debugger.
> I'm creating a new post to explain you my modification.
>
> Angelo
>
>>
>> Attila.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> FreeMarker-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>>
>

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: FMParser improvment for DLTK Freemarker plugin

Daniel Dekany
In reply to this post by revusky
Monday, July 19, 2010, 4:17:59 PM, Jonathan Revusky wrote:

> On Sun, Jul 18, 2010 at 2:52 PM, Angelo zerr <[hidden email]> wrote:
>> Hi,
>>
>> I would like know if you think you will have time to improve FM Parser
>> (Jonathan (sorry for the harass)?). I don't want have disturb with
>> you, but if FM Parser is not improved, I can not continue my work on
>> DLTK Freemarker Plugin and I will stop the development. I know you are
>> very busy, but I'm afraid that you (Attila for the debugger, Jonathan
>> for the FM Parser) you have not time to work on Freemarker project.
>
> I'm very wary of making promises now, but it is very likely I will
> spend some time on this pretty soon. You see, I am going to California
> on Wednesday for 6 weeks and, at least for most of the time there, I
> have little to do but work on code. I will be at my parents' house
> there in San Diego. (If anybody is in the area there and wants to meet
> me, feel free to write.)
>
> I do not think that the changes you need on the parser side are very
> big, so once I do get into it again, it shouldn't be very long before
> you have what you need.
>
> As for Attila, obviously, I cannot speak for him. (He is actually
> right here in the next room, as I write you though.)
>
> We were talking about FreeMarker and we both agree (I am not sure
> what Daniel will say) that we need to get the 2.4 (or 3.0 or
> whatever)

It's called 3.0 for a good while. 2.4 is basically 2.3 with GAE
compatibility and some legacy dependencies thrown away.

> release cycle going again, and start putting out some releases.
>
> JR

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel