Hi All,
Sorry for the long silence, I had a family health problem which had me away from home and with only access to email, no upload or download. Now that I am back I will be able to get on with the build-system updates, once I remember where I was up to ;-). Since I stuffed up copying the source to my laptop nothing has happened in the interim.
As I remember we were trying to come to a conclusion about commands for header files for C and C++ which are currently explicitly prevented from performing any compile or build.
The C++ work I have done in the meantime has re-inforced my desire to be able to at least compile C++ headers by themselves to get out the syntax typos because they tend to cause a lot of "flow on" errors in the .cpp file and C++ generates such enormous error messages (see http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an example). Also I have noticed that Geany 0.15 is very slow when there are lots of errors, maybe the regex parse is a bit slow, anyway that just makes it more important to compile the .hpp file first.
The question seems to be how we handle having different commands for the header files (different to the .cpp files that is) without creating new filetypes for them.
My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(.
Any other suggestions?
Cheers Lex
On Tue, 20 Jan 2009 17:23:42 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey Lex,
Sorry for the long silence, I had a family health problem which had me away from home and with only access to email, no upload or download.
Hope things will get better soon.
The C++ work I have done in the meantime has re-inforced my desire to be able to at least compile C++ headers by themselves to get out the syntax typos because they tend to cause a lot of "flow on" errors in the .cpp file and C++ generates such enormous error messages (see http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an example). Also I have noticed that Geany 0.15 is very slow when there are lots of errors, maybe the regex parse is a bit slow, anyway that
Unless you set custom regexps in filetypes.cpp yourself, Geany won't use them by default (for C/C++), instead it parses the output by cutting the error message string using C/Glib string functions. Anyway, I think the snowiness comes more from adding the error message string to the compiler messages window. Though I don't think this is a big issue, we could maybe execute the build command (g_spawn_async_with_pipes()) in another thread including the parsing, and then write the result into a temporary buffer which is read by the main thread and fills the compiler messages window. This could work in theory thus needs a lot work and code re-organising plus carefully writing the separate thread as there can't be any GTK code. Additionally, single core machines probably won't benefit from this separation. So, if we want to do this, we should do this afterwards.
The question seems to be how we handle having different commands for the header files (different to the .cpp files that is) without creating new filetypes for them.
I still don't know why compiling header files can't be done using with one of the configurable filetype commands you are about to implement. Users who want compile headers simply add a third command for it (or we add it by default, doesn't matter).
My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(.
IIRC we decided to not go this way, but I might be wrong. And currently, I don't have the time to deeply get into this discussion again since there are so many other problems and discussions around here at the moment plus we are heavily going to the next release (mid February maybe).
Regards, Enrico
Hi Enrico,
2009/1/24 Enrico Tröger enrico.troeger@uvena.de
On Tue, 20 Jan 2009 17:23:42 +1100, "Lex Trotman" elextr@gmail.com wrote:
Hey Lex,
Sorry for the long silence, I had a family health problem which had me away from home and with only access to email, no upload or download.
Hope things will get better soon.
They are now thanks.
The C++ work I have done in the meantime has re-inforced my desire to be able to at least compile C++ headers by themselves to get out the syntax typos because they tend to cause a lot of "flow on" errors in the .cpp file and C++ generates such enormous error messages (see http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an example). Also I have noticed that Geany 0.15 is very slow when there are lots of errors, maybe the regex parse is a bit slow, anyway that
Unless you set custom regexps in filetypes.cpp yourself, Geany won't use them by default (for C/C++), instead it parses the output by cutting the error message string using C/Glib string functions. Anyway, I think the snowiness comes more from adding the error message string to the compiler messages window. Though I don't think this is a big issue, we could maybe execute the build command (g_spawn_async_with_pipes()) in another thread including the parsing, and then write the result into a temporary buffer which is read by the main thread and fills the compiler messages window. This could work in theory thus needs a lot work and code re-organising plus carefully writing the separate thread as there can't be any GTK code. Additionally, single core machines probably won't benefit from this separation. So, if we want to do this, we should do this afterwards.
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.
The question seems to be how we handle having different commands for the header files (different to the .cpp files that is) without creating new filetypes for them.
I still don't know why compiling header files can't be done using with one of the configurable filetype commands you are about to implement. Users who want compile headers simply add a third command for it (or we add it by default, doesn't matter).
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.
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.
This would be enough for me, although I am sure I will swear about you every time I use the wrong command ;-)
My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(.
IIRC we decided to not go this way, but I might be wrong.
Last I heard Nick was going to look at the code changes but I have heard nothing since then.
And currently, I don't have the time to deeply get into this discussion again since there are so many other problems and discussions around here at the moment plus we are heavily going to the next release (mid February maybe).
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?
Regards, Enrico
Cheers Lex
On Sat, 24 Jan 2009 09:53:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I think the snowiness comes more from adding the error message string to the compiler messages window.
Hmm, why? It's pretty fast for Find in Files with a lot of results.
I assumed it might be parsing the setting indicators for each build error. Or the build parsing, not sure. If the first, we could stop highlighting errors after the first 50 or so.
Regards, Nick
On Sun, 25 Jan 2009 12:11:58 +1100 Lex Trotman elextr@gmail.com wrote:
My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(.
IIRC we decided to not go this way, but I might be wrong.
Last I heard Nick was going to look at the code changes but I have heard nothing since then.
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Regards, Nick
On Mon, 26 Jan 2009 13:09:48 +0000, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Sat, 24 Jan 2009 09:53:02 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I think the snowiness comes more from adding the error message string to the compiler messages window.
Hmm, why? It's pretty fast for Find in Files with a lot of results.
Just a guess. Given that the bottleneck is parsing the received string using C string functions or adding to the treeview, I think adding to the treeview takes more time, we add a new item to the model, then by adding it the tree view gets notified about the model change and it updates itself and repaints. I just guess this takes a little more time than a little string handling. But again, it's just a guess and maybe the bottleneck is something completely else.
I assumed it might be parsing the setting indicators for each build error. Or the build parsing, not sure. If the first, we could stop highlighting errors after the first 50 or so.
Ah, yeah. That(build error indicators) is more probable to be the cause for the slowness. However, I don't think there is much need to limit this, if users are bothered by this, they can simply disable the highlighting in the prefs dialog.
Regards, Enrico
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I assumed it might be parsing the setting indicators for each build error. Or the build parsing, not sure. If the first, we could stop highlighting errors after the first 50 or so.
Ah, yeah. That(build error indicators) is more probable to be the cause for the slowness. However, I don't think there is much need to limit this, if users are bothered by this, they can simply disable the highlighting in the prefs dialog.
Well, *if* this is the cause, I think it would be best to limit the errors. Error indicators are useful up to a point, but who is really going to look at each error for >50, >100, >200 errors? If there are a lot, they're likely caused by the same problem.
Regards, Nick
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Sun, 25 Jan 2009 12:11:58 +1100 Lex Trotman elextr@gmail.com wrote:
My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(.
IIRC we decided to not go this way, but I might be wrong.
Last I heard Nick was going to look at the code changes but I have heard nothing since then.
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Ok, if no other objections I'll implement an option for compile headers off by default and lets see how it goes.
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I assumed it might be parsing the setting indicators for each build error. Or the build parsing, not sure. If the first, we could stop highlighting errors after the first 50 or so.
Ah, yeah. That(build error indicators) is more probable to be the cause for the slowness. However, I don't think there is much need to limit this, if users are bothered by this, they can simply disable the highlighting in the prefs dialog.
Well, *if* this is the cause, I think it would be best to limit the errors. Error indicators are useful up to a point, but who is really going to look at each error for >50, >100, >200 errors? If there are a lot, they're likely caused by the same problem.
I agree with Nick, I always click on the error to go to the offending source line, but after fixing the first few errors I tend to re-compile to see if I actually fixed them and how many of the rest are consequential errors. So limiting how many are highlighted (or even how many are displayed if the treeview is the problem) may be a solution for slow machines and speeding up the turnaround fits well with my workflow.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I assumed it might be parsing the setting indicators for each build error. Or the build parsing, not sure. If the first, we could stop highlighting errors after the first 50 or so.
Ah, yeah. That(build error indicators) is more probable to be the cause for the slowness. However, I don't think there is much need to limit this, if users are bothered by this, they can simply disable the highlighting in the prefs dialog.
Well, *if* this is the cause, I think it would be best to limit the errors. Error indicators are useful up to a point, but who is really going to look at each error for >50, >100, >200 errors? If there are a lot, they're likely caused by the same problem.
I agree with Nick, I always click on the error to go to the offending source line, but after fixing the first few errors I tend to re-compile to see if I actually fixed them and how many of the rest are consequential errors. So limiting how many are highlighted (or even how many are displayed if the treeview is the problem) may be a solution for slow machines and speeding up the turnaround fits well with my workflow.
Hmm ok, why not. You are both right, that usually fixing the first few errors solves the other 100 errors as well :). And if not, then there is probably a much bigger problem in the used code, haha.
Regards, Enrico
On Tue, 27 Jan 2009 19:50:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, *if* this is the cause, I think it would be best to limit the errors. Error indicators are useful up to a point, but who is really going to look at each error for >50, >100, >200 errors? If there are a lot, they're likely caused by the same problem.
I agree with Nick, I always click on the error to go to the offending source line, but after fixing the first few errors I tend to re-compile to see if I actually fixed them and how many of the rest are consequential errors. So limiting how many are highlighted (or even how many are displayed if the treeview is the problem) may be a solution for slow machines and speeding up the turnaround fits well with my workflow.
Hmm ok, why not. You are both right, that usually fixing the first few errors solves the other 100 errors as well :). And if not, then there is probably a much bigger problem in the used code, haha.
Such an option should be optional with default value 0 for no limit IMHO.
Cheers, Frank
On Wed, 28 Jan 2009 14:15:41 +0100, Frank Lanitz frank@frank.uvena.de wrote:
On Tue, 27 Jan 2009 19:50:03 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 27 Jan 2009 23:03:02 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/27 Nick Treleaven nick.treleaven@btinternet.com
On Mon, 26 Jan 2009 20:52:18 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
Well, *if* this is the cause, I think it would be best to limit the errors. Error indicators are useful up to a point, but who is really going to look at each error for >50, >100, >200 errors? If there are a lot, they're likely caused by the same problem.
I agree with Nick, I always click on the error to go to the offending source line, but after fixing the first few errors I tend to re-compile to see if I actually fixed them and how many of the rest are consequential errors. So limiting how many are highlighted (or even how many are displayed if the treeview is the problem) may be a solution for slow machines and speeding up the turnaround fits well with my workflow.
Hmm ok, why not. You are both right, that usually fixing the first few errors solves the other 100 errors as well :). And if not, then there is probably a much bigger problem in the used code, haha.
Such an option should be optional with default value 0 for no limit IMHO.
Do we really need to add an option for this? In the meantime, I'm convinced it should be ok to just limit the error indicators to 50 or 100.
Regards, Enrico
On Tue, 27 Jan 2009 22:30:20 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Ok, if no other objections I'll implement an option for compile headers off by default and lets see how it goes.
Well, we might want to make changes to the build system, or extend GUI functionality in some way. This would likely be made more complex if we have to also support different sets of build commands.
I think it would be best to keep the alternate build commands feature separate from the main build work.
Regards, Nick
2009/1/30 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 27 Jan 2009 22:30:20 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Ok, if no other objections I'll implement an option for compile headers
off
by default and lets see how it goes.
Well, we might want to make changes to the build system, or extend GUI functionality in some way. This would likely be made more complex if we have to also support different sets of build commands.
I think it would be best to keep the alternate build commands feature separate from the main build work.
Ummm to make sure my last proposal above was understood, what I was proposing was not to have alternate commands for now, just to have an option to make the c/c++ filetype commands available for headers. Currently headers are hard coded to be unable to access any build or compile commands. If headers need a different build command then one of the spare commands will have to be used and the user must choose the correct command for header or body. Since there is some risk in that process, eg choosing the wrong command may have unintended side effects, the option is off by default (giving current behavior). It probably should be a hidden option, not on the GUI.
Cheers Lex
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 31 Jan 2009 00:44:15 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/30 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 27 Jan 2009 22:30:20 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Ok, if no other objections I'll implement an option for compile headers
off
by default and lets see how it goes.
Well, we might want to make changes to the build system, or extend GUI functionality in some way. This would likely be made more complex if we have to also support different sets of build commands.
I think it would be best to keep the alternate build commands feature separate from the main build work.
Ummm to make sure my last proposal above was understood, what I was proposing was not to have alternate commands for now, just to have an option to make the c/c++ filetype commands available for headers. Currently headers are hard coded to be unable to access any build or compile commands. If headers need a different build command then one of the spare commands will have to be used and the user must choose the correct command for header or body. Since there is some risk in that process, eg choosing the wrong command may have unintended side effects, the option is off by default (giving current behavior). It probably should be a hidden option, not on the GUI.
Er, didn't we already decided that the current restriction to not compile header files can/should be removed? I think we don't need an option for this. Just allow compiling header files and leave it in the user's responsibility with which command he/she compiles a header file.
Regards, Enrico
2009/1/31 Enrico Tröger enrico.troeger@uvena.de
On Sat, 31 Jan 2009 00:44:15 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/30 Nick Treleaven nick.treleaven@btinternet.com
On Tue, 27 Jan 2009 22:30:20 +1100 Lex Trotman elextr@gmail.com wrote:
Sorry, I haven't looked at them. Until we have a stable build commands design, I would prefer we don't complicate things. It's not so bad using an existing command to compile headers.
Ok, if no other objections I'll implement an option for compile headers
off
by default and lets see how it goes.
Well, we might want to make changes to the build system, or extend GUI functionality in some way. This would likely be made more complex if we have to also support different sets of build commands.
I think it would be best to keep the alternate build commands feature separate from the main build work.
Ummm to make sure my last proposal above was understood, what I was proposing was not to have alternate commands for now, just to have an option to make the c/c++ filetype commands available for headers. Currently headers are hard coded to be unable to access any build or compile commands. If headers need a different build command then one of the spare commands will have to be used and the user must choose the correct command for header or body. Since there is some risk in that process, eg choosing the wrong command may have unintended side effects, the option is off by default (giving current behavior). It probably should be a hidden option, not on the GUI.
Er, didn't we already decided that the current restriction to not compile header files can/should be removed? I think we don't need an option for this. Just allow compiling header files and leave it in the user's responsibility with which command he/she compiles a header file.
I didn't realise that was decided, happy to do minimal work ;-) will remove.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 31 Jan 2009 00:44:15 +1100 Lex Trotman elextr@gmail.com wrote:
Ummm to make sure my last proposal above was understood, what I was proposing was not to have alternate commands for now, just to have an option to make the c/c++ filetype commands available for headers.
Oh sorry, misunderstood. I agree with Enrico to remove the restriction.
Regards, Nick