Author Topic: Source Formatter  (Read 42862 times)

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Source Formatter
« on: January 14, 2006, 08:37:24 am »
I have ~good and bad news.

The ~good news: I've started another Source Formatter plugin only for C/C++. So far I have a hardcoded lexer, a console test program and a test plugin. It just tests the lexer, so it takes the whole file and modifies it with a (TOKEN, "lexeme") pair from the first to the last token found.

The bad news: I have barely 1 week of vacations left and most of my projects have never been finished (I read it over and over again and it sounds weird, but deep inside it makes sense). If I come with a working version of this plugin, you'll surely flood my e-mail, thru SF, with bug reports and feature requests, plus some posts, surely, in this thread, instead of giving me support, right? Tell me I'm wrong :P

I've had some ideas about the parser (it's a simpler one 'cause it won't need to build an AST or anything like that). I need to write them on paper and check viability.

I'll commit it to my personal SVN or CVS in a few hours, I hope. If it gets to a working state I'll tell you how to get access or beg a developer to put it in contrib.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #1 on: January 14, 2006, 05:45:02 pm »
The bad news: I have barely 1 week of vacations left and most of my projects have never been finished (I read it over and over again and it sounds weird, but deep inside it makes sense). If I come with a working version of this plugin, you'll surely flood my e-mail, thru SF, with bug reports and feature requests, plus some posts, surely, in this thread, instead of giving me support, right? Tell me I'm wrong :P

Well, may be wrong is too much :), because I have quite always seen in this forum some people available for help. In my case, I could provide some help, but unfortunately not this month (because of my project and some exams :(). In February, I would be more free. So, if you need something, just ask :D.

Concerning the parser, did you take into consideration rickg22's parser, eranif's parser (with SQLite) and "my" small recursive parser?

Best wishes,
Michael

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #2 on: January 14, 2006, 09:32:21 pm »
Quote from: Michael
Concerning the parser, did you take into consideration rickg22's parser, eranif's parser (with SQLite) and "my" small recursive parser?

Hmmm, no? :P

I'll try to get something for the next week. I'll just continue thinking about the implementation and customization issues.

And thank's for offering yourself to help. I'll have you in mind for the next month :)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #3 on: January 14, 2006, 09:43:33 pm »
Quote from: Michael
Concerning the parser, did you take into consideration rickg22's parser, eranif's parser (with SQLite) and "my" small recursive parser?

Hmmm, no? :P

I'll try to get something for the next week. I'll just continue thinking about the implementation and customization issues.

I think that it could be useful to look at them and eventually ask questions. It could be helpful to avoid problems, pitfalls and so on.

And thank's for offering yourself to help. I'll have you in mind for the next month :)

Ok. Just ask and if I can, I will gladly help (and not just asking C::B devs for new features, bug fixes and so on :D).

Michael

takeshimiya

  • Guest
Re: Source Formatter
« Reply #4 on: January 14, 2006, 10:28:19 pm »
I for one, think it will be way more easy to do things using a centralized parser like the one of eranif, or codestore, in the SDK.

Not only source formatting comes to mind, but a lot of other things (refactoring, code test coverage, documentation generated on the fly, class modeling, etc).

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Source Formatter
« Reply #5 on: January 15, 2006, 04:10:00 am »
Ceniza:

Please take a look into my "Copy strings" plugin, it's a very basic state-machine parser, and it recognizes C and C++ comments. The good thing about state machines is their simplicity. No need for long comparisons and particular cases, just a bunch of switches. I was amazed at its effectiveness :)

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #6 on: January 15, 2006, 07:52:28 am »
rickg22: I took a look at it already, remember? You told me to do so :P

A state-machine is indeed very nice, simple and effective, but I just decided to hard code it instead :)

Anyway, the lexer is almost done (6 more tokens come to my mind, which can be added in just a few minutes (5 of those are keywords which are really simple to add) :D). Haven't had the time to do so though, maybe tomorrow I'll add those (yes, haven't had those few minutes yet).

What Takeshi Miya says is true. How many C/C++ parsers/lexers will be using Code::Blocks (even though some come from external libraries)?: CodeCompletion, Scintilla, AStyle, ¿AngelScript?, my Source Formatter, maybe a Refactoring one, ...

Anyway, those will be there; if anyone needs them, use them. At least my lexer is built as a library that relies only in C++.

One again, I'll tell you when I put the files in SVN or CVS (right, I'ven't done it yet).

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #7 on: January 15, 2006, 09:18:26 am »
[edit]
I finally got to enable anonymous access to SVN, so here it is (removed the CVS info here):

Server: cenizasoft.cjb.net
Repository: /svnroot/SourceFormatter

Command line example:
svn co svn://cenizasoft.cjb.net/svnroot/SourceFormatter

Of course you can also use TortoiseSVN.

Right now the plugin just tests the lexer.
[/edit]
« Last Edit: January 15, 2006, 09:42:35 am by Ceniza »

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #8 on: January 15, 2006, 05:53:17 pm »
A state-machine is indeed very nice, simple and effective, but I just decided to hard code it instead :)

Sorry, but why you want to hard code it :?? IMHO, it is not a very good idea, because of e.g., extensibility, scalability.

Michael

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #9 on: January 15, 2006, 06:07:44 pm »
Sorry, but why you want to hard code it :?? IMHO, it is not a very good idea, because of e.g., extensibility, scalability.
Hey, hardcoding is great :)
(For me, that is, since I only use C++)

I'd love to see a better source code formatter for C++. And since hardcoding the lexer saves Ceniza precious time, this means he'll be done with it sooner (and I'll be happy sooner :))
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #10 on: January 15, 2006, 06:28:18 pm »
Sorry, but why you want to hard code it :?? IMHO, it is not a very good idea, because of e.g., extensibility, scalability.
Hey, hardcoding is great :)
(For me, that is, since I only use C++)

Hard coding is useful, I agree :), but not when the code would change oft and/or for extensibility/scalability. In such a case, it is better to avoid hard coding even if the implementation would take some more time. But later, you will save time when modifiying/updating the code.

I'd love to see a better source code formatter for C++. And since hardcoding the lexer saves Ceniza precious time, this means he'll be done with it sooner (and I'll be happy sooner :))

Well, I cannot really disagree with you :D. May be, later it would be possible to re-write the hard-coded part.

Michael

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Source Formatter
« Reply #11 on: January 16, 2006, 07:20:23 pm »
My state machine in the copystrings plugin is hardcoded, my point was the design without special cases   (in a state machine, all cases are special cases - they're handled equally).

If what Ceniza meant by "hardcoding" was to use a series of if's and design of the lexer/parser "by hand", then that's a no-no.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #12 on: January 16, 2006, 07:30:49 pm »
Quote from: thomas
I'd love to see a better source code formatter for C++. And since hardcoding the lexer saves Ceniza precious time, this means he'll be done with it sooner (and I'll be happy sooner :))

Oh, my precious... time.... I would like to get it done soon too :)

There's something I prefer to ask you guys, and girls if any: how to customize it? I mean, how detailed would you like it to be? Any interface idea?

So far I've thought of a series of dialogs, each one to customize specific things (but I also think it would be overkill, even to configure), like the way a "if (expr) stmts", "if (expr) { stmts }", the ones with "else" and "else if" should be formatted. You could then "say", for each thing: the if goes in a new line with current indentation, space + LPAREN, expr, RPAREN, LBRACE in new line with current indentation, stmts in new line with extra indentation, RBRACE in new line un-indenting, ...

That way it would always look like this:

Code
if (expr)
{
  stmts
}

Or just use simple options similar to those in AStyle?

Ideas? I still need to add a few more things to the lexer and have a global idea of the parser, including "customization details", before I can start coding it.

rickg22: I think it's a no-no then, sorry :P

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #13 on: January 16, 2006, 08:03:43 pm »
Or just use simple options similar to those in AStyle?

I do not know what the other devs/users think about, but for my AStyle was quite good :D. I just set the template I wanted to use (ANSI :lol:) and voilà...

The custom option of AStyle is a good idea. So, users could use their own style.

What it would be also good, would be the possibility to define and register new styles. In this was users could define more than one custom style.

IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.

Michael

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #14 on: January 16, 2006, 08:26:23 pm »
The AStyle way is not so bad actually, it is simple and it works. But there are just a few things which AStyled does not do the way I like it (for example, it compresses white space in comments and around '=', and always puts {} in a new line, so if you spend a lot of time laying out things properly, the code formatter destroys it later). Also you can only configure everything from hand, or nothing, which is annoying (for example, I like the way ANSI style looks, but I don't like spaces for indentation).

Why don't you make a simple "choose one out of n" interface (list box, for example). The actual configuration is read in from a config file, and you just provide 3-4 such configs. If somebody wants something different from ANSI, Gnu, or K&R, then he can write his own config and is not limited to a stiff GUI. Most people will use one of the default sets, so they have a 1-click configuration.
You could use tinyXML for the parsing, so you save an awful lot of time on designing a GUI (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #15 on: January 16, 2006, 08:40:28 pm »
Quote from: Michael
What it would be also good, would be the possibility to define and register new styles. In this was users could define more than one custom style.

That could even be considered a Feature Request for the current plugin, but if any of you do that it'd mean pending work for me (right, I'm the maintainer of the plugin, but some bug reports and requests are for AStyle itself, not the plugin) :P. I'll have it in mind :)

Quote from: Michael
IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.

IYHO, you still insist (I agree, but it'd be even more work) :)

If this plugin goes somewhere (instead of just converting the current file in a (token, lexeme) pair as it does now), it could have the same luck of the CodeCompletion plugin (redisign) :P. I wonder if Rick would like to suffer with this one too... :twisted:

Quote from: thomas
The AStyle way is not so bad actually, it is simple and it works. But there are just a few things which AStyled does not do the way I like it (for example, it compresses white space in comments and around '=', and always puts {} in a new line, so if you spend a lot of time laying out things properly, the code formatter destroys it later). Also you can only configure everything from hand, or nothing, which is annoying (for example, I like the way ANSI style looks, but I don't like spaces for indentation).

I've had it in mind since you sent me that PM, so don't worry. If it gets somewhere I'll try to get that working... eventually :)

Quote from: thomas
Why don't you make a simple "choose one out of n" interface (list box, for example). The actual configuration is read in from a config file, and you just provide 3-4 such configs. If somebody wants something different from ANSI, Gnu, or K&R, then he can write his own config and is not limited to a stiff GUI. Most people will use one of the default sets, so they have a 1-click configuration.

So, have a simple "choose one of..." interface and save the stiff GUI for customization so everybody will stick with the 3-4 configs. Understood :P

(Oh, and thanks, you just suggested the name for the customization button: "Stiff GUI" :))

Quote from: thomas
... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:

It's now time to focus on the Stiff GUI...

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #16 on: January 16, 2006, 09:08:14 pm »
Quote from: thomas
... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:
I guess you could call it a free interpretation of the good old 90/10 rule, or of the hot spot concept which derives from it :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #17 on: January 16, 2006, 09:08:38 pm »
Quote from: Michael
IMHO, the code should also thought extensible and scalable to allow integration of e.g., another parser.

IYHO, you still insist (I agree, but it'd be even more work) :)

If this plugin goes somewhere (instead of just converting the current file in a (token, lexeme) pair as it does now), it could have the same luck of the CodeCompletion plugin (redisign) :P. I wonder if Rick would like to suffer with this one too... :twisted:

Sorry :oops:. I do not want to make you crazy about my extensibility and scalability bla bla :D.

In a previous project, I have had several problems in hard-coding things and do not thinking about extensibility/scalability. I still remember the nights where I was re-working my classes...... :roll:

May be you can make your hard code parts easier to be successively re-coded. Of course, if this does not mean too much additional work for you :D.

Michael

Offline yop

  • Regular
  • ***
  • Posts: 387
Re: Source Formatter
« Reply #18 on: January 16, 2006, 09:09:48 pm »
Quote from: thomas
... (designing a GUI takes 90% of your time, but only 10% of the people use it 1% of their time...).

I love that sentence, but I bet it'sn't yours :wink:
I guess you could call it a free interpretation of the good old 90/10 rule, or of the hot spot concept which derives from it :)
Funny I've only read the Meyer's 80-20 law
Life would be so much easier if we could just look at the source code.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #19 on: January 16, 2006, 09:22:35 pm »
Funny I've only read the Meyer's 80-20 law
I guess Meyers was not even a child when they made the 90/10 rule. It is a really, really old rule, dating way back before computers were invented :)

On an interesting side note, the X Window system's design philosophy follows a  kind of 90/10 rule, too, which is addmittedly quite clever. It says something like "if you can get 90% of your features implemented with 10% of the trouble, then leave it at that".
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #20 on: January 17, 2006, 08:54:13 am »
I was working a bit more in the lexer. I'm kinda tired so it wouldn't be strange if I introduced a few bugs.

I just wanted to add that I got WebSVN working :)

http://svn.cenizasoft.cjb.net/websvn/

P.S.: Still waiting for ideas regarding the Stiff GUI. Screenies welcomed :)

[edit]
The WebSVN link has changed to http://svn.cenizasoft.cjb.net/
[/edit]
« Last Edit: January 23, 2006, 02:22:43 am by Ceniza »

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Source Formatter
« Reply #21 on: January 17, 2006, 02:48:18 pm »
I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this: :(

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

I also wanted to make an option to word wrap a comment block without having to redo whatever delimiter you put at the beginning of a comment line.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #22 on: January 17, 2006, 02:58:46 pm »
I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this: :(

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

It was interesting :). You should not give up. May be such a real-time functionality could be implemented in what Ceniza is doing.

Michael
 

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Source Formatter
« Reply #23 on: January 17, 2006, 03:24:18 pm »
I started writing a plugin that would format just what you were working on as you type, but gave up when no one answered this: :(

http://forums.codeblocks.org/index.php?topic=1927.0

All it was going to do is format the current statement or block after you hit ; or } but I thought it would be interesting.

It was interesting :). You should not give up. May be such a real-time functionality could be implemented in what Ceniza is doing.

Michael
 

Maybe. :) I've been really busy working on another part.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

takeshimiya

  • Guest
Re: Source Formatter
« Reply #24 on: January 17, 2006, 05:40:15 pm »
Still waiting for ideas regarding the Stiff GUI. Screenies welcomed :)

Here they are:

These are current drawbacks of the AStyle GUI, which you can take in account:

Code::Blocks AStyle Plugin

Actual behaviour:
Not a big problem, but the sample TextCtrl doesn't reflects the editor settings (font, colors, etc)
Expected behaviour:
The sample TextCtrl should be a cbEditor in the case it's not that difficult.
Maybe also letting the user can change the text example in real time wouldn't be bad.

Actual behaviour:
The window and TextCtrl is rather small, the text itself also, thus reviewing styles becomes hard.
Expected behaviour:
The text example should include more cases like classes, etc.

Actual behaviour:
The Custom style doesn't show any text at all.
Expected behaviour:
It should show the text and run AStyle over it in each change made to the custom settings.
At the time we'll have this working, the Sample TextCtrl should be shared across the 3 tabs.

Hope that helps a little :)

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #25 on: January 18, 2006, 06:02:17 am »
Time to ask before writing a complex parser when it's maybe unnecessary...

Customizing AStyle plugin provides:

Indentation:
  • Indentation size (in spaces)
  • Force using TABs
  • Convert TABs to spaces
  • Fill empty lines with the whitespace of their previous lines
  • Indent classes
  • Indent switches
  • Indent case: statement in switches
  • Indent brackets
  • Indent blocks
  • Indent namespaces
  • Indent labels
  • Indent multi-line preprocessor definitions

Formatting
  • Brackets
  • Pad empty lines around header blocks
  • Break 'else if()' header combinations into separate lines
  • Insert space padding around operators
  • Insert space padding around parenthesis
  • Don't break complex statements and multiple statements residing in a single line
  • Don't break one-line blocks

Good, now: what to keep, what to add, what to remove or just a full redisign that allows even further customizations (this one was my idea, but it'd take longer to implement)?

Takeshi Miya: that could be implemented in the current plugin, with some time :)

[edit]
Takeshi Miya: I just added a Preview button and removed the READONLY flag for the wxTextCtrl in AStyle's plugin. I still need to redesign it to share the wxTextCtrl across the 3 trabs.

Patch to change the wxTextCtrl for a cbEditor that reflects the editor settings is welcomed :)

Another text sample that includes more cases is also welcomed :)
[/edit]
« Last Edit: January 18, 2006, 07:59:10 am by Ceniza »

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Source Formatter
« Reply #26 on: January 18, 2006, 08:49:39 am »
the only thing which really bugs me using Astyle is, that
wxWidgets-typical macro constructs like

Code
BEGIN_EVENT_TABLE(MainFrame, wxFrame)
    EVT_ERASE_BACKGROUND(MainFrame::OnEraseBackground)
    EVT_SIZE(MainFrame::OnSize)
    EVT_UPDATE_UI(idViewStatusbar, MainFrame::OnViewMenuUpdateUI)
    EVT_MENU_RANGE(wxID_FILE1, wxID_FILE9, MainFrame::OnFileReopen)
    EVT_PROJECT_ACTIVATE(MainFrame::OnProjectActivated)
    EVT_SHOW_DOCK_WINDOW(MainFrame::OnRequestShowDockWindow)
END_EVENT_TABLE()

lose their format. this maybe owns potential for enhancements ...
« Last Edit: January 18, 2006, 08:53:04 am by tiwag »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #27 on: January 18, 2006, 09:07:12 am »
tiwag: that'd need some kind of hack. That's what you get when playing with macros :)

Since it could also contribute with SourceFormatter's dialog, here's an example of AStyle's dialog with the Sample wxTextCtrl out of the wxNoteBook.



Evil for resolutions under 1024x768, and not that pretty IMHO, and couldn't find what else to add where the wxStaticTextSizer with title "Info" is now (maybe some random picture of a naked girl would make people launch that dialog more often, changing that 90/10/1 rule :P).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #28 on: January 18, 2006, 09:13:17 am »
Quote
Good, now: what to keep, what to add, what to remove or just a full redisign that allows even further customizations (this one was my idea, but it'd take longer to implement)?

I am not sure if a redesign really takes that much longer. Adapting something existing (especially if you did not write it in the first place) is often tedious.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #29 on: January 18, 2006, 09:22:35 am »
tiwag: that'd need some kind of hack. That's what you get when playing with macros :)
Hey! Why not an "indent between <regex> and <regex>" option? That might be good for other things, too (not just event tables).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #30 on: January 18, 2006, 09:29:52 am »
thomas: by "full redisign" I meant doing it totally different. It could be, for example, an interface with all productions and some widget to choose what to do with every token there (put it in the next line, add space before/after, next line and indent, keep original style, ...). That'd be the Stiff GUI.

Heh, and I wouldn't feel like trying to fix bugs in, or adapt, a 5000+ lines project that wasn't written by me and where all that bunch of lines is in just a few files. Code::Blocks is huge, but at least it's well divided in many modules :)

Quote from: thomas
Hey! Why not an "indent between <regex> and <regex>" option? That might be good for other things, too (not just event tables).

See? That'd be a hack! The regex would apply to tokens! :?  :(  :cry:

What about a special IDs thingy? You could add BEGIN_EVENT_TABLE with something like "next line + indent" and END_EVENT_TABLE with "unindent".

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Source Formatter
« Reply #31 on: January 18, 2006, 09:35:55 am »
What about a special IDs thingy? You could add BEGIN_EVENT_TABLE with something like "next line + indent" and END_EVENT_TABLE with "unindent".
Sounds good. :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Raindog

  • Multiple posting newcomer
  • *
  • Posts: 17
Re: Source Formatter
« Reply #32 on: January 19, 2006, 03:58:03 am »
Might I suggest looking at the features that ReSharper or IntelliJ IDEA offer for source code formatting?

www.jetbrains.com

IMO they offer a real complete solution to formatting source code, and instead of using a large screen space to display the formatted source, they use a scrollable text view.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #33 on: January 19, 2006, 07:13:51 pm »
News: I'ven't coded any kind of parser :)

Anyway, I just wanted to comment you about a little source formatter I found and its configuration concept. I'm talking about NiceC, where the idea is to make it learn from existing formatted code. Then I came with the idea of a "learning session".

Here's a scenario (images are for illustrative purposes):

You have Code::Blocks opened, the plugin installed, and a source file loaded. You go to Plugins and select SourceFormatter.

It'll display a dialog showing you the current styles (predefined + user defined), a button to create a new empty style, a button to create a new style from an existing one, a button to apply the style and another button to learn.



You decide to create a new style, select it and click Learn.

Now tokens are found and a dialog pops-up. It'll allow you to configure some behavior based in the current scenario. Say it found a '{' that belongs to an if. Here you can select a set of actions based on some rules like: we're currently in an IF, previous token is, next token is, previous actions, next actions, ...



That one needs more "tuning". An option to add custom states could also be added.

States are pushed in a stack. The IF one would be pushed when a LPAREN token is found and the previous token is IF. Who removes it? :)

The configuration dialog should allow you to see, remove, modify and add actions (dialog not defined yet).

Anyway, what you'd get with that action would be (comments for clarification; dots mean space; indentation is 4 spaces):

Original code:
Code: cpp
if.(1.+.1.==.5).{

Formatted code:
Code: cpp
if.(1.+.1.==.5)// pre-action: Go to next line
{// post-action: Go to next line
....// post-action: Indent

Now it's your turn to say how much this idea sucks :D

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #34 on: January 19, 2006, 07:22:14 pm »
Look really cool :D. But before a final judgement I would like to see it in action... :D

Michael

[EDIT] @Ceniza: I cannot SVN update the SourceFormatter, because it seems that your server refuses the connection. Should I try later?
 
« Last Edit: January 19, 2006, 07:26:51 pm by Michael »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #35 on: January 19, 2006, 07:48:02 pm »
Quote from: tiwag
98/1/1

Yep, that'd be a huge problem.

Quote from: Michael
Look really cool :D. But before a final judgement I would like to see it in action... :D

See it in action? I just came up with the idea! Those dialogs were made with wxSmith (I got wxSmith to crash many times creating the second one :P) with 0 functionality.

Quote from: Michael
@Ceniza: I cannot SVN update the SourceFormatter, because it seems that your server refuses the connection. Should I try later?

I rebooted the machine where that's stored two times today (I needed its CD-ROM drive :P) and it seems svnserve wasn't started.

Ok, found the problem: I decided to add the command to start svnserve at the end of /etc/init.d/bootmisc.sh, but /etc/rcS.d/S55bootmisc.sh is a file and not a symlink so it was useless. Now I added it to the one in rcS.d :)

I just started it manually so it should work now.

Sorry for the Linux talking :P

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #36 on: January 19, 2006, 07:57:35 pm »
Quote from: Michael
Look really cool :D. But before a final judgement I would like to see it in action... :D

See it in action? I just came up with the idea! Those dialogs were made with wxSmith (I got wxSmith to crash many times creating the second one :P) with 0 functionality.

Ok. Anyway, your idea is very good :D. The Learn button gives an air of AI... :D

Concerning the wxSmith crashes (Windows, right?), you should may be post them.

Quote from: Michael
@Ceniza: I cannot SVN update the SourceFormatter, because it seems that your server refuses the connection. Should I try later?

I rebooted the machine where that's stored two times today (I needed its CD-ROM drive :P) and it seems svnserve wasn't started.

Ok, found the problem: I decided to add the command to start svnserve at the end of /etc/init.d/bootmisc.sh, but /etc/rcS.d/S55bootmisc.sh is a file and not a symlink so it was useless. Now I added it to the one in rcS.d :)

I just started it manually so it should work now.

Sorry for the Linux talking :P

No problem for the Linux talking :). The server works fine now. Thanks :).

Michael

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2813
Re: Source Formatter
« Reply #37 on: January 19, 2006, 08:08:02 pm »
I like the linux talking, how else are we gonna learn that greek??  :lol:

pecan

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #38 on: January 20, 2006, 09:12:20 pm »
Yesterday I committed the changes I made to the lexer a few days ago, and the first sketch of a formatter (nothing really).

So far the idea of the "rules" system sounds good. I'd need to define the default rules too.

It's a shame I didn't save those dialogs. More work to do again :(

There's a huge problem though: today is friday, 15:00+ here right now. My GF will surely want to come here saturday and sunday (and she won't help me with this plugin). Classes begin on monday.

Code: cpp
limit(free_time, busy_time, all_time) | free_time = all_time - busy_time

Quote from: Texas Instruments TI-89
0

:(

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #39 on: January 21, 2006, 09:12:19 am »
Naming things... how time consuming can this task be?

Anyway, here is a preliminar version of the basic structures for the rules:

Code: cpp
struct Condition
{
  TokenType cur_token;
  TokenType pre_token;
  TokenType next_token;
  State cur_state;
};

struct Actions
{
  std::vector<SingleAction> pre_actions;
  std::vector<SingleAction> post_actions;
};

struct Rule // version 1
{
  Condition cond;
  Actions acts;
};

struct Rule : Condition, Actions // version 2 (I prefer this one)
{
  // What else?
};

So far the function name could be something like matches. Overloading operator == wouldn't be that a good idea.

The function could look something like this:

Code: cpp
// kids: don't code like this :P
inline int Condition::matches(const Condition &other)
{
  return cur_token == other.cur_token ? 1 + (pre_token == other.pre_token) + (next_token == other.next_token) + (cur_state == other.cur_state) : 0;
}

Quite simple: if the current token is the same, count it and all others that match, else 0.

What if two rules return the same value (there wouldn't be duplicates, just same number of matches)?

If many return values != 0 but the one with biggest return value is unique, that one would be chosen.

Even though, there sould be another evaluation like this one (var == other.var || var == NOTHING || other.var == NOTHING). So, matches must return two values: exact matches and matches with "empty" variables. A struct, vector or pair<> would do that.

Now, the way to decide which one to apply would be (order is quite important when coding this, not here :P):
* The one with biggest return value for exact matches.
* If there's more than one with the same value, then the one of those with biggest total matches (those counting "empty" cases).
* If even that way there's more than one with both number of matches the same, what to do?
* If all returned 0 for exact matches, return the one with biggest total matches.
* If there's more than one with the same value, what to do?
* If both exact and total matches are 0, it's just a "NO MATCH". Apply default rule (easy to say, but what's the default rule?).

Feedback anyone? :)

Emmanuel Delahaye

  • Guest
Re: Source Formatter
« Reply #40 on: January 21, 2006, 09:36:27 am »
The ~good news: I've started another Source Formatter plugin only for C/C++..
Good Idea. I don't like the A-style formatter. I suggest GNU-Indent 1.91 that is free and has nice features (the more recent versions don't have them).

Actually, the easy way should be to allow to install an external tool with auto-reload (I do that with UltraEdit and Dev-C++).
« Last Edit: January 21, 2006, 09:39:56 am by Emmanuel Delahaye »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #41 on: January 21, 2006, 10:38:15 am »
There's a big problem with GNU-Indent though: it's for C only.

Quote from: Emmanuel Delahaye
Actually, the easy way should be to allow to install an external tool with auto-reload (I do that with UltraEdit and Dev-C++).

Just like using Code::Blocks' Tool menu...

I still wonder if this SourceFormatter based on those basic rules will get somewhere...

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Source Formatter
« Reply #42 on: January 21, 2006, 09:00:45 pm »
I still wonder if this SourceFormatter based on those basic rules will get somewhere...

I think yes :D. May be you can provide a small example that shows some basic functionalities. That would help both you and users. And you will get valuable feedback (IMHO :D).

Michael

takeshimiya

  • Guest
Re: Source Formatter
« Reply #43 on: January 21, 2006, 10:38:19 pm »
Good Idea. I don't like the A-style formatter. I suggest GNU-Indent 1.91 that is free and has nice features (the more recent versions don't have them).

Yeah, just clone GNU-indent, it is a lot more configurable than AStyle, but it's designed only for C, not C++.
Anyways, AStyle is great for common cases. I don't think there is an urgent need for another source formatter.

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Source Formatter
« Reply #44 on: January 22, 2006, 12:07:43 am »
Ok, found the problem: I decided to add the command to start svnserve at the end of /etc/init.d/bootmisc.sh, but /etc/rcS.d/S55bootmisc.sh is a file and not a symlink so it was useless. Now I added it to the one in rcS.d :)

I just started it manually so it should work now.

Sorry for the Linux talking :P

If you are looking for a cleaner way to do that you can use the place the attached script in the /etc/init.d and then make the proper sym links in /etc/rc3.d.  It is a full working init script with start, stop, reload, and force-reload.  You will need to edit the settings for to init svnserve with at the top.

[attachment deleted by admin]

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #45 on: January 22, 2006, 01:26:54 am »
Quote from: Game_Ender
If you are looking for a cleaner way to do that you can use the place the attached script in the /etc/init.d and then make the proper sym links in /etc/rc3.d.  It is a full working init script with start, stop, reload, and force-reload.  You will need to edit the settings for to init svnserve with at the top.

I checked if such script was generated but it wasn't, so I just decided to add that single line to initialize it in bootmisc.sh.

But thanks for the script :)

And BTW, in my Linux box it's /etc/rc5.d :)

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Source Formatter
« Reply #46 on: January 22, 2006, 03:13:01 am »
Well rc3.d and rc5.d stand for run level 3 and 5 respectively. Runlevel 3 is what text only servers boot into, and Runlevel 5 is what machines with a GUI boot into, there is no 4.  In order to get runlevel 5 you have to pass through 1,2, and 3 also.  Now if you were to ever boot your machine into text only mode, like if you made it your server, and you only decided to put svnserve in rc5.d you would be suprised when it doesn't start.

EDIT- I think I am wrong about the OS ascending through run levels, I will investigate more.
EDIT2- Yes I am wrong, but if you run Ubuntu you are always safe if you put the init symlinks in rcS.d because that is run before the default runleve, which is 2 on Ubuntu.
« Last Edit: January 22, 2006, 03:30:43 am by Game_Ender »

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #47 on: January 22, 2006, 06:36:49 am »
We're getting a bit away from the plugin discussion...

Anyway, that's a Knoppix machine with runlevel 5 as default in inittab. The thing is: it works 'cause it's in the bootmisc of rcS.d and I don't really have any plans to move it :)

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Source Formatter
« Reply #48 on: January 23, 2006, 02:22:53 am »
Ok, back on-topic.

I just added the sketch for the rules system and it's already committed.

One more thing, the WebSVN link has changed to http://svn.cenizasoft.cjb.net/

I'll edit the previous post too...