Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
SVNInside : development of another SVN plugin for CodeBlocks
MortenMacFly:
--- Quote from: orel on December 02, 2007, 09:05:26 pm ---though i don't think it would resolve those warning you got!
--- End quote ---
Don't worry, we can settle this easily then. The reason is most liekely a wrong parameter in the build setup... no prob. ;-)
MortenMacFly:
...minor bug that causes a crash on exit on Windows Vista:
int void wxSVNTreeCtrl::OnProjectClosed(CodeBlocksEvent& event)
The line:
this->Delete(pLoadedPrj->GetId());
should better be inside the if (pLoadedPrj) (...) switch yard. Otherwise you are accessing a null pointer there possibly... ;-)
With regards, Morten.
orel:
Thank you Morten for reporting me this bug, but the current code of SVNInside is nearly not at all the same as the one i commit to svn on assembla a long ago (some weeks). I am not commiting my current work until i come with a more stable version and with the minimum features one need. i am sure i will have some bugs but my api is now better designed.
Why i am taking longer than i thought is because i really had some big problems with ::wxExecute in asynchronous mode, and i decided for the moment to totally removes the asynchronous code, so all function calls are sequential and CB can be freezed when calling some svn commands taking a long time to return.
The problems i had with ::wxExecute called asynchronously had really no sense, sometimes everything worked like a charm, then next time i sent wxExecute a longer command line and it won't return, leaving my plugin anc CB hanging and freezing. I hope they will improve that or i will be obliged to do everything synchrously or maybe use another API for executing commands which is more stable, any ideas?
I am also looking ()at using subversion in a static or dynamic library to deal directly with the svn API : no command line, no pipes, more speed, more informations, more control. But sv is really a nightmare to compile and build on mingw, so it's not for tomorrow.
MortenMacFly:
--- Quote from: orel on December 23, 2007, 12:56:45 am ---any ideas?
--- End quote ---
The issue you have described could be the "well-known" wxExecute bug that limits the command line to a (???) 255 characters. If you provide a longer command line you are corrupting memory without notification / exception. Thomas once discovered that issue but so far we were just lucky when creating compiler command lines. Thomas also worked on a cbExecute due to that that removes this (stupid) limitation. But AFAIK it is not yet finished.
With regards, Morten.
eranif:
--- Quote from: MortenMacFly on December 23, 2007, 06:42:06 am ---The issue you have described could be the "well-known" wxExecute bug that limits the command line to a (???) 255 characters. If you provide a longer command line you are corrupting memory without notification / exception. Thomas once discovered that issue but so far we were just lucky when creating compiler command lines. Thomas also worked on a cbExecute due to that that removes this (stupid) limitation. But AFAIK it is not yet finished.
With regards, Morten.
--- End quote ---
You got me curios there, so I went and read wxExecute source code (MSW), I cant seem to see the limitation you mentioned of 255 characters.
The command for wxExecute is of type of wxString, and it passed to ::CreateProcess() method like this command.c_str() - so no limitation here.
Maybe you are talking of Linux?
On Linux, for executing a synchronous commands, I dont use wxExecute, but this (it works very well on Linux & Mac):
--- Code: ---void ExecuteCommand(const wxString &command, wxArrayString &output, long flags)
{
#ifdef __WXMSW__
wxExecute(command, output, flags);
#else
FILE *fp;
char line[1024];
memset(line, 0, sizeof(line));
fp = popen(_C(command), "r");
while ( fgets( line, sizeof line, fp)) {
output.Add(_U(line));
memset(line, 0, sizeof(line));
}
pclose(fp);
#endif
}
--- End code ---
EDIT: Forgot to mentioned, that my wx version is 2.8.4 on windows, 2.8.6 on Linux
Eran
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version