Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[stsp]

Hi.

I am very new to aMule. I tried to compile it several
months ago, and it failed. I tried now, and it failed the
same way. So I thought I'd better fix it myself. The patch
is attached. Apparently aMule uses some things that
are no longer supported by wx (I am updating my wx
from CVS, which is probably why I can't compile aMule).

What the patch does:
1. wxNode* --> compatibility_iterator is an easy one.
2. Removal of wxString::GetWriteBuf() and wxString::UngetWriteBuf()
is a bit fishy: the wx docs do not say these methods are
no longer supported, but apparently they are not available
if you build the wx with the STL support. But in any case
these were unused by aMule, so I just removed them.
3. Apart from the compilation problems, I also had to fix
one runtime bug, which was that the wxString object
returned by thePrefs::GetLanguageID() was not checked
for being an empty string, and so GetChar(0) asserts.

With this patch the aMule compiles and starts up successfully.
There are also some other disturbing problems I have,
which is that I was not able to find the following things:
1. aMule CVS server (so had to download the full  snapshots
every time, which is silly)
2. aMule patch tracker (so had to use this forum, sorry).
Can you please give me a hint as to where to find those?
I visited the SF page, but even there there are no such things!
Btw, if the Joy-User can't find such an important things,
then I guess the web page is in need of some update to
get those things more apparent. Or am I just blind?

[Xaignar]

The problem seems to be you're the first to use the STL enabled version of wxWidgets.

Your patch seems fine to me, though I'm as you not sure about wxString::*WriteBuf functions. However, this should be possible to do without using the writebuffer.

I'll walk through it and fix the issues. Many thanks for the patch.

Oh, and the questions:
1) The CVS server is private. If you plan on following the changes, then I'd suggest that you install ccache.
2) http://bugs.amule.org

[deltaHF]

Originally posted by stsp

1. aMule CVS server (so had to download the full  snapshots
every time, which is silly)
2. aMule patch tracker (so had to use this forum, sorry).

hi,

for some reasons we can provide only the daily tarballs, sorry.. and there is no such thing like "patch tracker"..

the only way to get something earlier than the daily tarballs is to become an amule dev

cheers

[stsp]

Originally posted by Xaignar
1) The CVS server is private. If you plan on following the changes, then I'd suggest that you install ccache.

I think I understand your suggestion, although it doesn't
really help. You propose the way to shorten the compilation
time, while I aim for saving my internet traffic which costs
money.

2) http://bugs.amule.org

OK, SF affected my mind so that I always expect to see
the patch tracker separately from the bug tracker. Well,
can use the bug-tracker too, thanks for the pointer.

[stsp]

Originally posted by deltaHF
for some reasons we can provide only the daily tarballs, sorry..

Unless a secret, what are those reasons?

and there is no such thing like "patch tracker"..

OK, I just got used to such a thing being a SourceForge
user. Can live with a bug-tracker too.

the only way to get something earlier than the daily tarballs is to become an amule dev

My concerns are not as much about the early updates,
but rather about the waste of the traffic. One will surely
*not* update aMule code every day if it requires to D/L
the full 2Mb tarball, while with CVS this is not a problem
at all (few KBs, few seconds to update, few minutes to
recompile). And thinking about the dial-up modem users -
2Mb is a real, real pain for them. So if there is a reason
against the read-only anonymous CVS access, I hope
it is strong enough:)

[Xaignar]

Originally posted by stsp

Originally posted by deltaHF
for some reasons we can provide only the daily tarballs, sorry..

Unless a secret, what are those reasons?

I could tell you, but then I'd have to kill you. *boom, tschh!*

[GonoszTopi]

stsp, if you want to post patches, use the Development board (http://forum.amule.org/board.php?boardid=47)

[Xaignar]

stsp, I'm afraid that wxWidgets using STL wont be officially supported as of now. While most of the issues can be fixed quite simply, the functions in the kad subfolder are needed while we import kad and can't safely be replaced until that import is completed. So until that point, we wont be supporting STL enabled wxWidgets.

[GonoszTopi]

Xaignar, I see no point why we can't support STL enabled wxWigdets in 2.0.0, as we don't have KAD right now. When we start importing kademlia, then we can say that we don't support wxWidgets with STL, until we find a proper replacement for those functions.

Considering the above, I commit these fixes.

stsp: I had to change 2 things in your patch:
1) An empty langID is not an error, but it is the 'System Default' language
2) Instead of removing the offending functions, I placed them inside a #if/#endif pair.

Anyway, thanks for the patch.

[Xaignar]

Well, for one thing, the fix just broke support for wx2.4.2 ...