UFO:Alien Invasion
Development => Coding => Topic started by: criusmac on December 11, 2009, 09:25:48 am
-
I posted this somewhere before, but now I have some proof.
The problem is CodeBlocks sometimes deletes files on me, removing all of my changes. Attached is a file that causes a compile error in CodeBlocks.
The errors I get are:
.objs\game\src\game\g_actor.o||In function `G_ActorDamage':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:213: undefined reference to `LIST_AddPointer'|
.objs\game\src\game\g_actor.o||In function `G_ActorTreat':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:404: undefined reference to `LIST_GetByIdx'|
:C:\cprogs\UFOAI-2.3-dev-medikits\src\game\g_actor.c|419|undefined reference to `LIST_Remove|
These errors are expected since I lost my linked list file additions to the workspace upon updating my project with the repository's.
Now, when I click on these errors, nothing happens until I click on the last one, which opens an empty file, with nothing in it, which has the same name and location as the file with the error.
I probably clicked save all or something without noticing this originally. Upon saving this file, which I successfully did in my test just a couple minutes ago, I lost the entire contents of the file. Luckily, I made a backup of the file before trying to save it, so I was able to replace the file.
-
Hmm. Was there also some svn update involved ?
I never used 'Save all'. Instead I let 'build' do that for me. But I assume the same code is used there.
-
Yes, I did a full svn update since I was preparing to start coding the medikits project again.
Ok, I tested with build, without using save all, and build wiped out the file too. The file became empty, and I got a *ton* more new errors.
Sadly, I forgot I removed the file from my backup location after I restored it, and all my changes to this file were lost. Thank goodness I uploaded it here, or I'd have lost it.
-
I asked for svn update because if a file you edited is also updated via svn, C::B comes up with a box with three buttons. One can easily click the wrong one. But that might kill your changes, not the entire file.
Are you on Win or *nix ?
The file in question is g_actor.c ?
-
I never update via svn while the project or any files are open in CodeBlocks, so I probably skirt around that issue.
I'm on
OS Name Microsoft Windows XP Home Edition
Version 5.1.2600 Service Pack 3 Build 2600
The file in question in this case is g_actor.c, though I've lost g_combat.c several times too, and, oddly, I don't recall losing any files that didn't start with g_ before... It's always g_ files I lose...
-
I've been running CB on XP and Vista for more than a year now, but I never experienced loss of data (except by misclicking maybe). And no other user afaik complained about such.
Are you sure your HW is ok ? Especially HD and mem ? Did you experience other things that might be associated with a HW defect ?
-
So, I take it the error could not be reproduced on your system with that file.
Did you download the file and try to compile it, and then double click on the last error to see what happens?
I can't guarantee my HD and mem are ok, but my POST has never indicated a problem.
The error is 100% reproducible for me, and very easy to do, every time I try, exiting CodeBlocks and restarting it doesn't make a difference.. This suggests memory isn't my problem since memory errors tend to be a bit more random.
The file can be opened up properly and contains all the information if I open it up via the project interface. It is only blank if I open it up by double clicking on the error message itself. This suggests it's not a HD problem since the file can be opened up properly through other methods. Also, there is no error of any kind when double clicking the compile/linking errors. This suggests it's not a HD problem.
Since I can reproduce this problem through very easy to follow steps, and it is 100% reproducible, this suggests it is a bug. The location is the bug is most likely CodeBlocks, but it could also be the operating system, or something else.
I am not seeing any symptoms of any hardware defects or problems.
When I first downloaded CodeBlocks as requested on these forums, I downloaded the package from the CodeBlocks web page, and I manually downloaded all the dependencies and installed them myself. I probably also got some plugins for CodeBlocks, but I don't know which ones or where they are. So, it is possible one of the plugins I grabbed originally is doing this.
In any case, what I am seeing suggests a software glitch since there are no errors reported at any stage, and it is 100% reproducible. Since I have overwritten my original install with the CodeBlocks package supplied by UFO: AI several times now, there may be some problem that came to surface in this way as well. -- The only way to be certain is to see if the problem can be reproduced on someone else's computer, hence this post. Since there has been no mention that this problem could not be reproduced yet, I can't eliminate my setup as a problem yet.
-
These are my plugins:
12/11/2009 10:32 PM 264,834 astyle-1.2.cbplugin
12/11/2009 10:32 PM 67,488 autosave-0.1.cbplugin
12/11/2009 10:32 PM 114,533 AutoVersioning-1.2.cbplugin
12/11/2009 10:32 PM 99,822 BrowseTracker-1.2.74_2008_03_15.cbplugin
12/11/2009 10:32 PM 75,600 byogames-1.0.cbplugin
12/11/2009 10:32 PM 51,694 cb_koders-0.1.cbplugin
12/11/2009 10:32 PM 69,509 classwizard-0.3.cbplugin
12/11/2009 10:32 PM 237,852 codecompletion-0.7.cbplugin
12/11/2009 10:32 PM 548,851 codesnippets-1_3.92_2008_08_23.cbplugin
12/11/2009 10:32 PM 54,120 codestat-0.5.cbplugin
12/11/2009 10:32 PM 512,609 compiler-0.99.cbplugin
12/11/2009 10:32 PM 47,717 copystrings-1.00.cbplugin
12/11/2009 10:32 PM 251,126 debugger-0.3.cbplugin
12/11/2009 10:32 PM 54,765 defaultmimehandler-1.0.cbplugin
12/11/2009 10:32 PM 96,402 devpakupdater-0.2.cbplugin
12/11/2009 10:32 PM 85,530 DragScroll-1.3.23_2008_08_26.cbplugin
12/11/2009 10:32 PM 76,993 envvars-0.97.cbplugin
12/11/2009 10:32 PM 401,642 Exporter-1.0.cbplugin
12/11/2009 10:32 PM 272,632 headerfixup-0.80.cbplugin
12/11/2009 10:32 PM 342,273 help_plugin-1.1.cbplugin
12/11/2009 10:32 PM 324,077 HexEditor-0.5.cbplugin
12/11/2009 10:32 PM 74,383 IncrementalSearch-0.5.cbplugin
12/11/2009 10:32 PM 91,673 keybinder-1.0.46_2008_02_12.cbplugin
12/11/2009 10:32 PM 190,423 lib_finder-2.0.cbplugin
12/11/2009 10:32 PM 41,179 openfileslist-1.0.cbplugin
12/11/2009 10:32 PM 83,715 Profiler-1.0RC2.cbplugin
12/11/2009 10:32 PM 84,180 projectsimporter-1.0.cbplugin
12/11/2009 10:32 PM 44,715 RegExTestbed-0.2.cbplugin
12/11/2009 10:32 PM 127,419 scriptedwizard-0.9.cbplugin
12/11/2009 10:32 PM 61,883 SymTab-1.0.cbplugin
12/11/2009 10:32 PM 116,285 ThreadSearch-1.11.cbplugin
12/11/2009 10:32 PM 114,482 todo-0.2.cbplugin
12/11/2009 10:32 PM 63,579 wxsmith-1.0.cbplugin
12/11/2009 10:32 PM 116,264 wxSmithContribItems-0.1.cbplugin
12/11/2009 10:32 PM 37,114 xpmanifest-1.0.cbplugin
-
So, I take it the error could not be reproduced on your system with that file.
Did you download the file and try to compile it, and then double click on the last error to see what happens?
Actually I had not tried with your file because I can't believe that it's the content of the file.
But now I tried and got a lot of compiler errors along the lines of WOUND_* undeclared. So I didn't get to the linker errors you are experiening.
-
Ah, hmm, I was worried that might be the case.
http://ufoai.ninex.info/forum/index.php?topic=2216.msg32609#new contains my medikits.diff file which is all of the differences I'm working with. As long as you don't modify the project files (adding the g_linkedlist.c), the exact errors I'm seeing should appear.
-
Uhm...just to be sure: you're talking about the medikit.diff in the SF patch tracker ID: 2891685 ?
-
https://sourceforge.net/tracker/?func=detail&aid=2891685&group_id=157793&atid=805244
-
I applied that patch. Got some conflicts but could resolve them. Sooner or later you should create a patch based on a recent rev.
I still got compile errors:
C:\UFO\src\game\g_round.c: In function 'G_ActorsBleed':
C:\UFO\src\game\g_round.c:159: warning: unused variable 'regen'
C:\UFO\src\game\g_round.c: In function 'G_ClientEndRound':
C:\UFO\src\game\g_round.c:211: warning: implicit declaration of function 'G_GetNextActiveTeam'
C:\UFO\src\game\g_round.c:213: error: 'lastTeam' undeclared (first use in this function)
C:\UFO\src\game\g_round.c:213: error: (Each undeclared identifier is reported only once
C:\UFO\src\game\g_round.c:213: error: for each function it appears in.)
C:\UFO\src\game\g_round.c:219: warning: unused variable 'nextTeam'
C:\UFO\src\game\g_round.c:253: error: expected declaration or statement at end of input
-
i've attached an updated version to the tracker item
-
I had no errors when I applied the patch to the most recent revision that I got from svn 3 days ago, save for the one when I threw out the project and workspace file modification (since they conflicted).
It's starting to look like chasing this down will be a waste of time. I can work around this as long as I never double click an error, or if I do, I don't save all or build afterwards. Since I can avoid the error, it's probably not worth the time to continue confirming there is an error.
I'll label it up as "I finally figured out why my files are getting deleted", and I will just backup everything before I start testing again. That's life. Very sorry to have caused so many problems with this.
-
btw. it would be nice if you would read the coding guidelines again ;)
-
You're right to some extent. Even if we could prove it's a C::B bug, we couldn't do much about. I just wanted to help you find out whether it's 'just you'.
If you can easily apply the patch to current trunk, you can as easily create a fresh patch based on trunk ;)
You may also want to find out whether there is a difference between compiler and linker errors being clicked on.
-
I applied the diff files to the current trunk, and threw out my versions of:
ufo.workspace
game.cbp
then I compiled.
That's it, that's all. As soon as I placed my g_linkedlist.c file back into the game.cbp, the errors all went away, and everything worked fine.
This problem, I suspect, happens everytime a new game.cbp is created since I always throw out my version, and use the trunk, and so I likely always create the same link problem every time the game.cbp file is updated.
I have no idea why the diff file worked so easily for me, when it won't for you.
If you are still interested in pursuing this, attached is the patch based on the trunk as of, uh, about 5 minutes before I hit post on this message.
As stated before, this is a work in progress, and so it will not follow the coding guidelines. To make it easier to use, I also removed the game.cbp file from the diff.
-
it would be really cool if you could at least use the updated version that i've appended to the tracker item.
-
g_linkedlist.c is not included in the patch, isn't it?
i also don't see which codeparts from the patch at sf.net should need this. as it compiles clean with current trunk (except one compile error that was introduced for you to look at the position)
-
I also noticed that your game.cbp contains backslashes in the paths. C::B doesn't need that even on Window$. That might even be the source of your error.
What happens if you use the standard cbp from trunk ?
-
game.cbp is the trunk version, gotten via svn, and then I used CodeBlocks to add g_linkedlist.c into the game sources.
So, if CodeBlocks wrote the file incorrectly, then, uh... Well, I don't modify game.cbp by hand, so I really don't know why it would be wrong.
I can try to use the code you appended to the tracker, sure. I was just continuing my coding from where I left off.
I removed g_linkedlist.c purposely from the diff file I uploaded into this conversation to introduce the compile/link errors and make it easy for you to get the exact errors I was seeing. I have *no* idea how you avoided the errors and got a clean compile when I very specifically made sure you would not get a clean build.
Since I updated my source code via svn just minutes before I created this diff file...
And the codeparts from the patch that need this file are displayed in the first message of this conversation:
The errors I get are:
.objs\game\src\game\g_actor.o||In function `G_ActorDamage':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:213: undefined reference to `LIST_AddPointer'|
.objs\game\src\game\g_actor.o||In function `G_ActorTreat':C:/cprogs/UFOAI-2.3-dev-medikits/src/game/g_actor.c:404: undefined reference to `LIST_GetByIdx'|
:C:\cprogs\UFOAI-2.3-dev-medikits\src\game\g_actor.c|419|undefined reference to `LIST_Remove|
So, it is g_actor.c that needs g_linkedlist.c.
I have no idea where to go from here. To get a clean compile, your CodeBlocks settings must somehow be different from mine, or something, and I've never been informed of any of the CodeBlocks settings for this project. I did not change any CodeBlocks settings from when I first installed CodeBlocks, so maybe they really are wrong.
Honestly, if you don't include g_linkedlist.c in the game project, but you are including my changed g_actor.c, there should be no way to get a clean compile.
-
Upon closer reading of your statements, I have come to the conclusion that you may not realize I am trying to change the UFO: AI code to add the new form of Medikits.
From what I can gather, you are stating the UFO:AI original code project compiles fine without g_linkedlist.c - my newly added file. This probably means that you are not using my new g_actor.c changes, which requires g_linkedlist.c.
Please download the trunk, and then apply my diff file without modifying anything, and try to compile/link it. You will get errors - this was done on purpose. Double clicking on the last error (for me) causes CodeBlocks to open up an empty file with the same pathname of a proper existing file. With this strangely empty file, if you save all or build, you can overwrite the real file with the empty file, thus losing the real, full file completely.
If CodeBlocks Windows version is adding backslashes into the project file, and it can't use these blackslashes properly, which causes it to completely erase files, that sounds like a CodeBlocks bug, and a very serious one.
-
Ok, I
- svn updated to r27510
- applied your diff (5 posts above) without conflicts :)
- got the three LIST_* linker errors
- clicked the last one (it's singleClick btw) and C::B nicely opened g_actor and found the correct line :)
-
Great! Thank you.
It's obviously something wrong with my CodeBlocks then. I'll update to the latest version (I was using svn build rev 5456 (2009-02-14 11:03:04) gcc 4.2.1 Windows/unicode), and see if the problem goes away. If not, well, hmm. I haven't a clue what else to do.
-
I just downloaded svn build rev 5731 (2009-08-15 03:48:58) gcc 4.2.1 Windows/unicode from mattn's CodeBlocks.zip, and it worked perfectly. So, I guess I happened to find a bug in the previous version.
Thanks. It's solved.
-
:)
It's always a good idea to hunt them bugs down to their very end...
-
sed.exe from gnu is not useable under mingw32
I've replaced the GNU sed.exe with a sed.exe from an older C::B build (attached)
GNU sed errors
sed.exe: -e expression #2, char 1: unknown command: `V'
MinGW build VS MSYS build
Some programs when used under the MSYS shell can be tricky. One such example is sed.
$ ls *.txt -1 | sed -e s/.exe/\&\!/g
Normally, sed will append "!" to the end of every .txt file, but if sed was compiled and link using MinGW, MSYS will treat it as a native application and will try to change "/" to "\" to compensate for the difference between UNIX path and WIN32, resulting in unpredictability when used under the MSYS shell.
-
where to get that sed version? we need an updated version for the c::b script.
-
is part off msysCORE
no need for
codeblocks.sh
// download_archive http://downloads.sourceforge.net/gnuwin32/ sed-4.2-bin.zip sed.zip
-
thanks, i've removed it
-
same problem with gawk
remove
download_archive http://downloads.sourceforge.net/gnuwin32/ gawk-3.1.6-1-bin.zip gawk.zip
add
download_archive http://downloads.sourceforge.net/mingw/ gawk-3.1.7-1-msys-1.0.11-bin.tar.lzma
-
i will replace that one, too - thanks
-
I just created a new C::B package with the updated script, it compiles the game fine, but not radiant without errors.
I'm currently uploading the package for others to try if they want to.
(Logs attached).
Edit: Link:
http://www.destructavator.com/92dl/codeblocks_new.zip
-
should be fixed with the most recent script version, too
-
should be fixed with the most recent script version, too
OK thanks, I'll try it again now.
-
Success! Everything works now. :D
Here is the new and updated, working package:
http://www.destructavator.com/92dl/codeblocks_6088.zip
-
I've done "some" work on the codeblocks.sh script
Tested:
able to codeblocks.sh on the newly created codeblocks.7z
and a working UfoAI build from scratch
.) download archives updated
.) new function to extract archives extract()
.) changed function download_archive()
.) more verbose output
.) some cleanup
The script:
will now use 7za only for extraction
add everything needed to build UfoAI incl. NSIS and keep things separated; codeblock is codeblock, mingw is mingw
added my script make_UfoAI_win32 too
changed the way the script calls functions; I download and extract package by package
made a lot of error checking
-
thanks - commited to trunk
-
there is a bug regarding include dir
fixed it and attached!
working with last codeblocks_6088.zip and codeblocks.zip from official download (mattn)
-
https://sourceforge.net/tracker/index.php?func=detail&aid=2954987&group_id=157793&atid=805244
-
Hmm, i start to think we should call it by name, UfoAI_win32_build_environment_${version}
Newbies get easily confused codeblocks package <=> codeblocks IDE
what codeblock they currently using
where to get the newest
and is it up2date
I've changed the name from codeblocks.sh to make_win32_build_environment.sh
codeblocks.sh is calling make_win32_build_environment.sh (in some month we should trash it)
make_win32_build_environment.sh adds
a versionNumber too, a changelog at the bottom of the script
and most important a text file Mingw/bin/WINenvVER containing the environment-version that is currently used
We are than able to check every time C::B is used to compile the project if the environment is up2date
C::B call cb_check.cmd which will open WINenvVER and make_win32_build_environment.sh apply a version check and
exit 0 or assist the user to build a update
attached 2 patches
projects.patch for build\projects
scripts.patch for contrib\scripts
incl. for contrib\scripts
cb_check.cmd
make_win32_build_environment.sh
I hope i've done the svn diff accurate
<Add before="..\..\contrib\scripts\cb_check.cmd "$(TARGET_COMPILER_DIR)"" />
@echo off
cd /d %~dps0
@echo %~1
@echo %~dps1
set env_build_script=make_win32_build_environment.sh
set codeblocks_toolchain_path=%~dps1
if NOT Exist %codeblocks_toolchain_path%bin\WINenvVER (
call :error "unable to find %codeblocks_toolchain_path%bin\WINenvVER"
)
for /f "tokens=*" %%a in ('type %codeblocks_toolchain_path%bin\WINenvVER') do (
set ver=%%a
)
if NOT Exist %env_build_script% (
call :error "unable to find %~dps0%env_build_script%"
)
for /f "tokens=2 delims== " %%a in ('type %env_build_script% ^| findstr /I "^environment_ver"') do (
set CB=%%a
)
if %ver%==%CB% (
@echo Win32 build environment is up2date
exit 0
)
if %ver% GEQ %CB% (
@echo Win32 build environment is a testbuild
exit 0
)
call :error "Win32 build environment is outdated"
:error
@echo %~1
@echo update your build environment
echo %~dps0 | findstr /I "%codeblocks_toolchain_path%\" 2>&1>NULL && (
rem @echo %codeblocks_toolchain_path%
rem @echo %~dps0
set this=%~dps0
call set this=%%this:%codeblocks_toolchain_path%=%%
call set this=%%this:\=/%%
start %codeblocks_toolchain_path%msys.bat
)
echo %~dps0 | findstr /I "%codeblocks_toolchain_path%\" 2>&1>NULL || (
@echo %codeblocks_toolchain_path%
@echo %~dps0
@echo As the Wiki state, ufoai source must be somwhere below Mingw
@echo move your ufoai source folder at %codeblocks_toolchain_path%
start explorer %~dps0..\..\
start explorer %codeblocks_toolchain_path%
)
if NOT "%this%"=="" (
@echo .
@echo enter this line into mingw32
@echo /%this%%env_build_script% create
@echo .
@echo you will find the new environment at %codeblocks_toolchain_path%home\%USERDOMAIN%
start explorer %codeblocks_toolchain_path%home\%USERDOMAIN%
)
exit 1
goto :EOF
-
it would be cool if you could base your work on the scripts in our svn
see also https://sourceforge.net/tracker/?func=detail&aid=2954987&group_id=157793&atid=805244
-
I hope it's now as it should be
svn add /ufoai/contrib/scripts/make_win32_build_environment.sh
svn add /ufoai/contrib/scripts/cb_check.cmd
svn diff /ufoai/contrib/scripts >>scripts.patch
svn diff /ufoai/build/projects >>projects.patch
-
applied to trunk with a little modifications - deprecated files should not exists - use svn move filename newfilename to keep the version history. please watch a little bit the coding guidelines of our project. even if this is all about scripts, they are true for scripts, too ;)