Release process for 0.2.8_beta2
I think I got the reconnection "crash" (It's more of a fatal error, the least I'll be able to do is turn it into a nonfatal one) recorded myself. I'd still need one for the other problem, the server browser not updating.
The triggering event appears to be the that when you reconnect fast, you'll catch one of the "connection terminated" messages from the last connection. It seems unrelated to Nemo's bug after all.
Edit: I have local changes that
a) turn the fatal error into a recoverable error (terminating the connection nontheless)
b) avoid the error by opening a new socket for the new connection (from a new port, not receiving leftover messages from the server).
I'll commit them later when I see they're not dangerous to the server.
The triggering event appears to be the that when you reconnect fast, you'll catch one of the "connection terminated" messages from the last connection. It seems unrelated to Nemo's bug after all.
Edit: I have local changes that
a) turn the fatal error into a recoverable error (terminating the connection nontheless)
b) avoid the error by opening a new socket for the new connection (from a new port, not receiving leftover messages from the server).
I'll commit them later when I see they're not dangerous to the server.
I think I fixed the odd angled walls bug; what I fixed looked like it, and was caused by wrong updates to the temporary wall the client keeps around. It only happened when intermediate syncs got lost or were never sent due to bandwidth constraints. The screenshot shows how it looked for 4 axes, for more axes, the extra wall would not appear to grow in front of the cycle, but can stick out at any angle. And it also can begin at an arbitrary point.
You do not have the required permissions to view the files attached to this post.
I'm not quiet sure how to attach the recording but here my best try:
Let me explain it first. It loads up a couple servers (in this one 4) and leaves the rest as polling forever...i waited a min and when it didnt change i pressed r (refresh) and it loaded all the other servers.
Let me explain it first. It loads up a couple servers (in this one 4) and leaves the rest as polling forever...i waited a min and when it didnt change i pressed r (refresh) and it loaded all the other servers.
You do not have the required permissions to view the files attached to this post.
Damn, it sure has been a while!
I don't know what Zip program you're using; they all have slightly different interfaces. The zip file you attached seems to be empty.TiTnAsS wrote:i made zip file and just moved it over to it, yet once its in the zip file it dsont open. What am i doing wrong...
On my PC, when I want to zip something, I right click on it and select a menu entry "Create Zip" or similar; the rest goes automatically. I never heard of a drag'n'drop interface to zip files, but I guess it would make sense.
The runtime error is important, I guess.
About autopackage: I could easily statically link to libxml2 by setting APBUILD_STATIC="xml2" in the
BuildPrepare phase; I can statically link to the C libraries with APBUILD_STATIC_LIBGCC=1; but, just as with my previous experience, I could not statically link with libstdc++. APBUILD_STATIC="xml2 stdc++" did not work.
However, doing the right kind of googling turned up this:
http://www.trilithium.com/johan/2005/06/static-libstdc/
The solution seems to be to tell GCC to look for libstdc++ in a directory where only the static library will be found. I'll try that next.
Lucifer: Is it OK if I take over the complete autopackage thing? It needs slightly better integration into the build module, right now it overwrites everything
BTW, I like it how autopackage supports inremental builds for testing. Something I really missed with RPM.
BuildPrepare phase; I can statically link to the C libraries with APBUILD_STATIC_LIBGCC=1; but, just as with my previous experience, I could not statically link with libstdc++. APBUILD_STATIC="xml2 stdc++" did not work.
However, doing the right kind of googling turned up this:
http://www.trilithium.com/johan/2005/06/static-libstdc/
The solution seems to be to tell GCC to look for libstdc++ in a directory where only the static library will be found. I'll try that next.
Lucifer: Is it OK if I take over the complete autopackage thing? It needs slightly better integration into the build module, right now it overwrites everything

BTW, I like it how autopackage supports inremental builds for testing. Something I really missed with RPM.
That runtime error seems to correspond to the problem I was having where if I went to a different window, armagetron would crash at some point. Since the armagetron window was no longer updating, I don't know at what point it was crashing.
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Cool.z-man wrote:<snip static linking>

That reminds me. The autopackage thing hasn't been integrated into the build module, so it tends to overwrite things.Lucifer: Is it OK if I take over the complete autopackage thing? It needs slightly better integration into the build module, right now it overwrites everything

I really like that about autopackage. I don't like how it uses the source tree to do its stuff, though. There's a certain style about how RPM just uses a source tarball, but that style gets real irritating when you have to build the whole package 10 times tweaking the spec file as you go. I figured that proper integration with the build module would fix it for autopackage.BTW, I like it how autopackage supports inremental builds for testing. Something I really missed with RPM.

Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
I have not tried SDL yet; APBUILD_STATIC should work there, too.Lucifer wrote:Cool.z-man wrote:<snip static linking>Did you manage to get SDL staticly linked? I asked on the autopackage forums about it and one of the guys said "There's no autopackage for SDL, and you can't rely on SDL being there in any particular configuration". So we need to staticly link it if at all possible. (luckily since it's a C library we don't have to deal with ABI formats, so if SDL ever does get predictable in an installation, we can stop worrying about it)
But I don't think we should do that. While SDL is not installed everywhere, it certainly is included in all non-minimal distributions. And it likely is installed if the user installed a single non-kde game from the distribution.
See, static linking is not free of problems. Our main program gets built with the autopackage tools (apgcc, for example) that work around some of the binary compatibility problems. By statically linking with a library from the system, we break that (it was build with normal gcc). Statically linking for improved compatibility makes full sense only if we build the dependencies with apgcc, too. And I don't know yet how that could be even possible for libstdc++; it gets compiled during the gcc build in the bootstrap process. We can't plug in apgcc there.
ARMAGETRONAD_FAKERELEASE=true is your friend when testing build scripts/spec files. It skips the compilation and installs a stub batch file instead. This won't let you test issues with the binary, like the automatic dependency detection, but you won't be missing any files.Lucifer wrote:I really like that about autopackage. I don't like how it uses the source tree to do its stuff, though. There's a certain style about how RPM just uses a source tarball, but that style gets real irritating when you have to build the whole package 10 times tweaking the spec file as you go. I figured that proper integration with the build module would fix it for autopackage.BTW, I like it how autopackage supports incremental builds for testing. Something I really missed with RPM.
And yes, the real autopackage builds will be done from the official tarball, like RPM does. I'll keep a testing target around that uses the source directly.
- Tank Program
- Forum & Project Admin, PhD
- Posts: 6712
- Joined: Thu Dec 18, 2003 7:03 pm
Cusco reported this in IRC with version 0.2.7.1-8.Lucifer wrote:That runtime error seems to correspond to the problem I was having where if I went to a different window, armagetron would crash at some point. Since the armagetron window was no longer updating, I don't know at what point it was crashing.

The autopackage guys also suggested we could build SDL ourselves and bundle it in the package, or we could build an autopackage of SDL that could be resolved at install time whenever the autopackage of armagetron resolves dependencies.z-man wrote: See, static linking is not free of problems. Our main program gets built with the autopackage tools (apgcc, for example) that work around some of the binary compatibility problems. By statically linking with a library from the system, we break that (it was build with normal gcc). Statically linking for improved compatibility makes full sense only if we build the dependencies with apgcc, too. And I don't know yet how that could be even possible for libstdc++; it gets compiled during the gcc build in the bootstrap process. We can't plug in apgcc there.
I don't think that's going to happen for this release, but it is worth considering what will be needed to support autopackage long-term.

Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Lucifer: Yes, supplying autopackages for our dependencies ourselves sounds like the way to go; the build itself should be unproblematic. I'm not yet ready to write the skeleton files needed for dependency resolution, though.
The sources are tagged now; the tag is "v0_2_8_beta2". I tagged all modules again so we don't forget one later. We're likely to make some changes to the build modules over the weekend (autopackage, mdk, VisualC), we can move the tag afterwards.
I'm going to bed now; the RPMs are building overnight. I'll upload them to SF and/or aabeta tomorrow when I have time, next will be the Windows builds, then autopackage.
About the runtime error: sounds like the thing I was trying to avoid by disabling rendering when the app loses focus; have you set "Keep Window Active" in the screeen settings? Are there any conditions where it happens more often?
The sources are tagged now; the tag is "v0_2_8_beta2". I tagged all modules again so we don't forget one later. We're likely to make some changes to the build modules over the weekend (autopackage, mdk, VisualC), we can move the tag afterwards.
I'm going to bed now; the RPMs are building overnight. I'll upload them to SF and/or aabeta tomorrow when I have time, next will be the Windows builds, then autopackage.
About the runtime error: sounds like the thing I was trying to avoid by disabling rendering when the app loses focus; have you set "Keep Window Active" in the screeen settings? Are there any conditions where it happens more often?
You do not have the required permissions to view the files attached to this post.
Heh, neither am I.z-man wrote:Lucifer: Yes, supplying autopackages for our dependencies ourselves sounds like the way to go; the build itself should be unproblematic. I'm not yet ready to write the skeleton files needed for dependency resolution, though.

Not that I know of, but I'll check. I may have set it at some point and forgotten about it.About the runtime error: sounds like the thing I was trying to avoid by disabling rendering when the app loses focus; have you set "Keep Window Active" in the screeen settings? Are there any conditions where it happens more often?
Check out my YouTube channel: https://youtube.com/@davefancella?si=H--oCK3k_dQ1laDN
Be the devil's own, Lucifer's my name.
- Iron Maiden
Be the devil's own, Lucifer's my name.
- Iron Maiden
Uhg when i right click and press send to comrpess zip file i can;t find it afterwords?z-man wrote:I don't know what Zip program you're using; they all have slightly different interfaces. The zip file you attached seems to be empty.TiTnAsS wrote:i made zip file and just moved it over to it, yet once its in the zip file it dsont open. What am i doing wrong...
On my PC, when I want to zip something, I right click on it and select a menu entry "Create Zip" or similar; the rest goes automatically. I never heard of a drag'n'drop interface to zip files, but I guess it would make sense.
Mabye its cuz i'm using the recording program thing, is there something eles i should be using?
Edit: I noticed that beta 2 download..is there one for windows yet?
Damn, it sure has been a while!