Hi Enrico,<br><br><br><div class="gmail_quote">2009/1/24 Enrico Tröger <span dir="ltr"><<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 20 Jan 2009 17:23:42 +1100, "Lex Trotman" <<a href="mailto:elextr@gmail.com">elextr@gmail.com</a>><br>
wrote:<br>
<br>
Hey Lex,<br>
<div class="Ih2E3d"><br>
>Sorry for the long silence, I had a family health problem which had me<br>
>away from home and with only access to email, no upload or download.<br>
<br>
</div>Hope things will get better soon.<br>
<div class="Ih2E3d"></div></blockquote><div><br>They are now thanks. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
<br>
>The C++ work I have done in the meantime has re-inforced my desire to<br>
>be able to at least compile C++ headers by themselves to get out the<br>
>syntax typos because they tend to cause a lot of "flow on" errors in<br>
>the .cpp file and C++ generates such enormous error messages (see<br>
><a href="http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17" target="_blank">http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17</a> for an<br>
>example).  Also I have noticed that Geany 0.15 is very slow when there<br>
>are lots of errors, maybe the regex parse is a bit slow, anyway that<br>
<br>
</div>Unless you set custom regexps in filetypes.cpp yourself, Geany won't<br>
use them by default (for C/C++), instead it parses the output by<br>
cutting the error message string using C/Glib string functions. Anyway,<br>
I think the snowiness comes more from adding the error message string<br>
to the compiler messages window.<br>
Though I don't think this is a big issue, we could maybe execute the<br>
build command (g_spawn_async_with_pipes()) in another thread including<br>
the parsing, and then write the result into a temporary buffer which is<br>
read by the main thread and fills the compiler messages window.<br>
This could work in theory thus needs a lot work and code re-organising<br>
plus carefully writing the separate thread as there can't be any GTK<br>
code.<br>
Additionally, single core machines probably won't benefit from this<br>
separation. So, if we want to do this, we should do this afterwards.<br>
<div class="Ih2E3d"></div></blockquote><div><br>I'm not using any custom regexes so I guess it is just the GTK stuff.  I wasn't suggesting that a lot of effort be expended on this, and as you noted single core wouldn't benefit anyway, it is just an observation that it can be an impact on slower machines. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
>The question seems to be how we handle having different commands for<br>
>the header files (different to the .cpp files that is) without<br>
>creating new filetypes for them.<br>
<br>
</div>I still don't know why compiling header files can't be done using with<br>
one of the configurable filetype commands you are about to implement.<br>
Users who want compile headers simply add a third command for it (or we<br>
add it by default, doesn't matter).<br>
<div class="Ih2E3d"></div></blockquote><div><br>It would certainly work having .hpp and .cpp compile commands in the same menu, the only issue was that choosing the wrong command could have unexpected effects, such as g++ overwriting a .o file with a pre-compiled header.  Thats the behaviour of the default .cpp compile command applied to a header so I was looking at how to remove the risk.<br>
<br>Perhaps a simpler option is to make compiling headers a preference item, off by default so it is safe for beginners, and let anyone who enables it be carefull!!  Then they can define any spare filetype compile command for themselves.<br>
<br>This would be enough for me, although I am sure I will swear about you every time I use the wrong command ;-)<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
<br>
>My last proposal was for a "variant" of the filetype which allowed<br>
>different commands.  The variant was identified by a subset of the<br>
>filetypes extensions.  This is a slightly general solution<br>
>configurable in the filetypes or preferences files, or another option<br>
>is something hard coded specifically for header files, not my<br>
>favourite :(.<br>
<br>
</div>IIRC we decided to not go this way, but I might be wrong.</blockquote><div><br>Last I heard Nick was going to look at the code changes but I have heard nothing since then.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 And<br>
currently, I don't have the time to deeply get into this discussion<br>
again since there are so many other problems and discussions around<br>
here at the moment plus we are heavily going to the next release (mid<br>
February maybe). </blockquote><div><br> I wouldn't expect to get the build-system into a mid Feb release, not enough testing time for such a big change. Which brings up a point, I will update the build-system branch to trunk
so merges will be simpler, what is the  best trunk version to use, latest or
a specific one? <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Regards,<br>
Enrico<br>  <font color="#888888"></font></blockquote><div><br>Cheers<br>Lex <br></div></div><br>