Well, the new release files seem to be complete and intact. If not, I'll try to fix before I go on Holiday on the 26th of Jan.
This is a compatability maintainanece release (D7, latest JCL and JVCL) with no new functionality. I am meanwhile writing some new code towards a 2.0 version.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And, this is the most desired one: Could you
completely separate engine code from UI
--please, please please :-))
This is the only way we can have any chance of
contributing. As it stands, frames get in the way
of my understanding the code.
I would like it to be able do alphabetical sorting of
variables, procedures etc. but, I dont think I can
ask you for all these --I'll try to add them when I
can understand the code without the GUI getting
in the way.
Thank you for all and on behalf of all :-)
Cheers,
Adem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Requests so noted. All of these things are possible and should happen, it just may take time.
I agree that the formatter’s internal architecture is a bit .. lacking. But I don’t think that the formatting engine was to tied to the gui to much. After all, there is a command line build. Both GUI frames and engine get their settings from setting classes. Engine does not link directly to frames.
Version 2 will be based on the following concepts (the code so far is in Sourceforge CVS, so this is fixed and proven). If you’ve studied up on these, I hope it will be easy to understand:
* Firstly, lexical grouping of source characters in to tokens, e.g. ‘begin’ or ‘:=’ This is largely unchanged from V1.
* Recursive descent parse, using a specification based on the rather incomplete BNF grammar supplied by Borland. As in V1, the intension is not to tell compliable from non-compliable source, but to be able to parse source that already compiles in Delphi. This parsing is new. It produces
* A Parse tree, with each leaf node = source token and interior nodes equivalent to higher-level parts of the unit such as “expression”, “case statement”, “procedure” or “implementation section”. This tree differs from the usual parse tree in that white space, returns and comments are not discarded. The full source will be reconstructed by reading all leaf nodes in order.
The parse engine is a group of fairly independent processes that each handles a specific task (e.g. Capitalisation, inserting returns where needed, removing spaces where not needed, etc.) Some of them generate data for later processes to use (ie X, y position of token, block nesting levels), but mostly they work in isolation. This is as in V1, however these processes are being rewritten as they now work on a different data model..
The Visitor pattern is used to apply these processes to the parse tree.
The first goal for V2 get it up to the level of features and reliability that 0.65 is at now. I.e. for me to finish writing it.
Then new features can be contemplated. Trust me – the parse tree is proving to be a win. The processes are more concise, robust and flexible. V2 will eventually be able to reliably do things that V1 would need mountains of wobbly code to accomplish.
Now that I’m settled in London, I’m off back to Cape Town for 3 weeks holiday away from the computers. See you in late February!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
In case it has slipped your attention, you might like to
take a look at www.innercircleproject.org, they have done
quite a bit of footwork in the way of parsing.
There is also the work done by Vladimir Churbanov (his
website seems to gone down, but easy to find thru Google).
#0.02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-04-15
Anthony,
V2 sounds fantastic. I am glad you are fixing the issues in the biz layer. The payback will be realized in flexability. Are you planning to allow scripting logic or formulas?
John E
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A bit of an update: I cannot spend loads of time on it, but it is making slow, steady progress. The new code is all in CVS, I will aim at packaging into a beta soon.
I'm not sure what you mean by scripting and formulas, but I aim with 2.0 to be at an equivalent level of features to 0.65, and to make changes one step at a time after that. 2.x will go much further. I don't need a roadmap, just ideas to implement :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2003-04-24
The concept is to have a formatter that can read a template of code and then replicate that format style in real code. If the template does not define a style, the formatter will not change the real code.
But, the problem with this is that you may have rules that allow two formats to be allowed. In that case, you may wish to use some type of formula to determine when each format should be used.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, the new release files seem to be complete and intact. If not, I'll try to fix before I go on Holiday on the 26th of Jan.
This is a compatability maintainanece release (D7, latest JCL and JVCL) with no new functionality. I am meanwhile writing some new code towards a 2.0 version.
Anthony,
Thank you for coming back. We did miss you :-)
I wonder if you are taking requests for v2.x, if so
here are mine:
i) A separate line for every unit in the Uses.
Such that:
Uses Windows, SysUtils, Classes;
becomes
Uses
Windows,
SysUtils,
Classes;
and not
Uses Windows,
SysUtils,
Classes;
(As DelforEx does it).
i) I am not sure if this is possible, but is it possible
to turn this kind of var declaration to
Var
SomeVar1, SomeVar2, SomeVar3: Integer;
into
SomeVar1: Integer;
SomeVar2: Integer;
SomeVar3: Integer;
iii) Unbreak lines. i.e. say you have a line like this
Procedure Something(SomeParameter: Integer;
SomeOtherParameter: String);
Could we unbreak it into
Procedure Something(SomeParameter: Integer; SomeOtherParameter: String);
[Single line]
iv) Blank line removal.
And, this is the most desired one: Could you
completely separate engine code from UI
--please, please please :-))
This is the only way we can have any chance of
contributing. As it stands, frames get in the way
of my understanding the code.
I would like it to be able do alphabetical sorting of
variables, procedures etc. but, I dont think I can
ask you for all these --I'll try to add them when I
can understand the code without the GUI getting
in the way.
Thank you for all and on behalf of all :-)
Cheers,
Adem
Hi
Requests so noted. All of these things are possible and should happen, it just may take time.
I agree that the formatter’s internal architecture is a bit .. lacking. But I don’t think that the formatting engine was to tied to the gui to much. After all, there is a command line build. Both GUI frames and engine get their settings from setting classes. Engine does not link directly to frames.
Version 2 will be based on the following concepts (the code so far is in Sourceforge CVS, so this is fixed and proven). If you’ve studied up on these, I hope it will be easy to understand:
* Firstly, lexical grouping of source characters in to tokens, e.g. ‘begin’ or ‘:=’ This is largely unchanged from V1.
* Recursive descent parse, using a specification based on the rather incomplete BNF grammar supplied by Borland. As in V1, the intension is not to tell compliable from non-compliable source, but to be able to parse source that already compiles in Delphi. This parsing is new. It produces
* A Parse tree, with each leaf node = source token and interior nodes equivalent to higher-level parts of the unit such as “expression”, “case statement”, “procedure” or “implementation section”. This tree differs from the usual parse tree in that white space, returns and comments are not discarded. The full source will be reconstructed by reading all leaf nodes in order.
The parse engine is a group of fairly independent processes that each handles a specific task (e.g. Capitalisation, inserting returns where needed, removing spaces where not needed, etc.) Some of them generate data for later processes to use (ie X, y position of token, block nesting levels), but mostly they work in isolation. This is as in V1, however these processes are being rewritten as they now work on a different data model..
The Visitor pattern is used to apply these processes to the parse tree.
The first goal for V2 get it up to the level of features and reliability that 0.65 is at now. I.e. for me to finish writing it.
Then new features can be contemplated. Trust me – the parse tree is proving to be a win. The processes are more concise, robust and flexible. V2 will eventually be able to reliably do things that V1 would need mountains of wobbly code to accomplish.
Now that I’m settled in London, I’m off back to Cape Town for 3 weeks holiday away from the computers. See you in late February!
Hi,
In case it has slipped your attention, you might like to
take a look at www.innercircleproject.org, they have done
quite a bit of footwork in the way of parsing.
There is also the work done by Vladimir Churbanov (his
website seems to gone down, but easy to find thru Google).
#0.02
Anthony,
V2 sounds fantastic. I am glad you are fixing the issues in the biz layer. The payback will be realized in flexability. Are you planning to allow scripting logic or formulas?
John E
A bit of an update: I cannot spend loads of time on it, but it is making slow, steady progress. The new code is all in CVS, I will aim at packaging into a beta soon.
I'm not sure what you mean by scripting and formulas, but I aim with 2.0 to be at an equivalent level of features to 0.65, and to make changes one step at a time after that. 2.x will go much further. I don't need a roadmap, just ideas to implement :)
The concept is to have a formatter that can read a template of code and then replicate that format style in real code. If the template does not define a style, the formatter will not change the real code.
But, the problem with this is that you may have rules that allow two formats to be allowed. In that case, you may wish to use some type of formula to determine when each format should be used.