Re: Continue Eclipse Freemarker DLTK?

Daniel Dekany <[email protected]> Mon, 29 Jul 2013 23:11:39 +0200
Newsgroups gmane.comp.web.freemarker.devel
Message-ID <[email protected]>
Monday, July 29, 2013, 3:57:38 PM, Angelo zerr wrote:

> Hi Daniel,
>
[snip]
> OK, so I think branch should be named with *-debug or* -tools becaus it's not linked to dltk.

(Sure, it could be "-tools". It's linked to the DLTK *development*, as
it will be only merged back when the DLTK plugin is released.)

> I would like that Freemarker improves : 
>  * debugger (add any debugger service,
>  add stepping features,

Yip.

> fix bug with debug unsert ftl

Which bug is that?

BTW, I have noticed that you have extended the DebugBreakpoint AST
node so that it can suspend after its enclosed expression (as opposed
to before it, which is how it's done normally), and that meant to be
used to support adding break-points on end-tags (</#...>, </@...>). I
think we need not allow putting break-points on end-tags, similarly as
we don't allow it on comments and such. An end-tag is purely
parse-time thing, a syntactical device for marking the end of a block
for the *parser*. Like, if you step through a template with debugger,
the curret line never will by an end-tag. Yet a break-point there will
trigger? But I'm not saying it's impossible to do. It's just that it's
not essential. In theory, such a breakpoint should trigger after the
last *nested* instruction was executed, unless that was a #break or
#return. (I guess it's not what the current implenentation does.)
Like, if you put a break-point on </@foo>, and you will see some HTML
in the output where </@foo> was, you expect the breakpoint to trigger
before that HTML is printed. With similar logic, for #list, the
end-tag breakpoint should trigger after each cycle. Also a nested
#continue should trigger it. Maybe the easiest way of implementing
this is replaceding the TemplateElement.nestedBlock with a DebugBreak,
only, some elements have a TemplateElement.nestedElements List
instead... and actually a directive doesn't have to use any of those
for its nested contents. So I suspect it's not trivial to do
correctly. (Implementing step-into on and end-tag also can be tricky.)

> (Breakpoint should stores too filename (the full path of the template)).

You mean, the template name (TemplateLoader-relative path) is not
enough, you need an absolute local filename associated with the
breakpoint? Will that file name by set by the plugin, and will only be
used by the plugin? I see no problem with that then, although I wonder
if it would be useful to simply allow associating an arbitrary
serializable object with a Breakpoint. Then that object could be a
java.io.File, or a JavaBean that stores more info that's useful for
the IDE to come back when the suspension event occurs.

>  * syntax errors (add start/end offset info of the token)

Tokens do have start/end line and column. Is it buggy or something?
AST nodes (TemplateObject-s) also have start/end location, except when
a constant expressions is substituted with a plain Java objects (like
String).

>   parser should be tolerant to displays several errors and build an
>   AST even if they are errors.

We will see... If nothing else, I hope I can make the parser to skip
until the end of the FTL tag, then make a ElementWithParsingError AST
node out of it. The lexel also will have to survive lexical errors, of
course.

>> I guess static DebuggerService.getInstance(), when first called,
>> should check the "freemarker.debug.debuggerService" system property,
>> which had to be something like "new
>> com.example.SomeDebuggerService(true) { password = 'qweqwe', port =
>> 1234 }" (where the { ... } section sets JavaBeans properties). (This
>> also means that we don't need extra properties like
>> "freemarker.debug.password".)
>
> IMHO, I'm not a big fan to set a system property valeu which contains some java code  "new
> com.example.SomeDebuggerServic.."
>
> I think we should have a DebuggerServiceRegistry which is enable to
> returns an instance of DebuggerService according configuration.
>
> I havei mplemented this idea in my private commit
> https://github.com/angelozerr/freemarker/commit/fb604a707e7d88e98f19bd0f40cbccce03080e19
> by using SPI like I have suggested you.
>
> You can see test at
> https://github.com/angelozerr/freemarker/blob/fb604a707e7d88e98f19bd0f40cbccce03080e19/src/test/java/freemarker/debug/DebuggerServiceRegistryTest.java
>
> The basic idea is to register debugger service provider with SPI
> and get the well debugger provider according the system properties
> by calling DebuggerServiceRegistry#getService() .
> The Configuration#getDebuggerService() checks fi there are debugger
> service setted (usefull for IDE) and if it's null,  use
> DebuggerServiceRegistry#getService() .

Well, it can work, but I would put some questions:

- What are the advantatges of the SPI approach over the approach that
  only uses properties (the one I have proposed)?

- If I provide "freemarker.debug.password", that will make most
  DebuggerService "accessible", how does the user contol which
  implementation will be choosen (or why is it not a problem)?

- Isn't it problematic that we are using the class-loader of FreeMarker
  to find the SPI implementations? If FreeMarker comes from a more
  generic directory than the SPI implementation, it won't be found, I
  think. Then we won't even give an error, but fall back to
  RMIDebuggerService (unlike in the properties-only solution).

- Is it setting different DebuggerService-s per Configuration useful?
  Like, does it have a known real-world use-case?

> If you like it, I will clean my code and create a pull request.

As of the clean-up, DebuggerServiceRegistry strikes me as needless,
unless it will actually become a registry in the future (in which
case, what will ot do?). Now all it does is getting a "default"
ServiceRegistry found via the SPI API. That could be done in
DebuggerService.getInstance().

And we should mind the concurrency issues, like getInstance() will
have to use synchronization of course (or use volatile tricks, under
Java 5+).

Speaking of which... the way the DebugBreak is inserted (that's
Attila's code I'm ralking about) strikes me as very much
thread-UNstafe.

Last not least, can you give me *prioritized* list of what will you
need (of the things that probably I will implement).

> Regards Angelo

-- 
Thanks,
 Daniel Dekany


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk