121 replies to this topic

[Lee]

almiteycow, on Dec 27 2006, 09:05 PM, said:

Lee, it won't build yet, due to the GUI stuff.

I'll see if I can port the LDCPP GUI over real quick for testing.

Ah ok. Well that was for when it's compilable.

[almiteycow]

Missed some files anyway, it seems.

Getting a new compiler error:

Quote

client/FileChunksInfo.cpp: In static member function ‘static Pointer<FileChunksInfo> FileChunksInfo::Get(const TTHValue*)’:
client/FileChunksInfo.cpp:40: error: operands to ?: have different types

Argh.. RevConnect code is driving me nuts...

To Port:
FileChunksInfo.cpp
SharedFileStream.cpp
Text.cpp?
TraceManager.cpp

Then gotta fix random linker errors.

Edited by almiteycow, 28 December 2006 - 12:39 AM.

[Big Muscle]

try to fix this error by type casting NULL to (Pointer<FileChunksInfo>)NULL or something like that.

[almiteycow]

Well, after a nice little break, I've picked the project back up again. Kinda lost track of where I am, but I think I can figure it out.
Looks like I was working on fixing linker errors, like these:

Quote

/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
build/client/DownloadManager.o: In function `DownloadManager::prepareFile(UserConnection*, long long, bool)':
DownloadManager.cpp:(.text+0x2afe): undefined reference to `SharedFileStream::SharedFileStream(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, long long, long long, bool)'
build/client/FavoriteManager.o: In function `FavoriteManager::load(SimpleXML&)':
FavoriteManager.cpp:(.text+0x6ff9): undefined reference to `Util::fileExists(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
build/client/FileChunksInfo.o: In function `FileChunksInfo::doLastVerify(MerkleTree<TigerHash, 1024u> const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':

Here's the latest source folder I'm using. Too lazy to clean it up, everything should be here, minus the dependencies.

http://almiteycow.ho...inuxdcpp.tar.gz

EDIT: Ah, nope, still working on porting those last 4. The scons file has 3 of them commented out.... they need to be put back in, and they throw the usual errors.

EDIT: I found this! It should make life a lot easier for me.

Edited by almiteycow, 23 January 2007 - 06:07 PM.

[Greg]

Toast, on Jan 26 2007, 11:09 AM, said:

LOL seems to be going good now 100$ xD

$130 now.

[Zlobomir]

And update topic title, if really $130...

[almiteycow]

Urgh. Looks like almost all of SharedFileStream.cpp needs to be rewritten for Linux. This is just the tip of the iceberg:

client/SharedFileStream.cpp:42: error: â??FILE_SHARE_READâ?? was not declared in this scope
client/SharedFileStream.cpp:43: error: â??GENERIC_READâ?? was not declared in this scope
client/SharedFileStream.cpp:46: error: â??FILE_SHARE_DELETEâ?? was not declared in this scope
client/SharedFileStream.cpp:46: error: â??FILE_SHARE_WRITEâ?? was not declared in this scope
client/SharedFileStream.cpp:48: error: â??GENERIC_WRITEâ?? was not declared in this scope

Not going to bother posting up with progress at the moment.. if you can't get this far, you probably can't solve this problem, I'd assume.
Main () apparently should be in the GUI somewhere, as well.

EDIT: Maybe those FILE_SHARE Blah and junk relate to this somehow? MO_IRUSR|MO_IWUSR|MO_IRGRP|MO_IROTH

EDIT: Looking at how Valknut/DCGUI do partial file sharing, maybe I'll learn something? I'm definitely going to need help here... anyone?

Edited by almiteycow, 29 January 2007 - 10:51 PM.

[kvach]

Hi all I have a little interest in DC++ working on linux
so I think I can help in part of network code I am not a GUI man

I've got tarball and have a look into ... Is it compiled on Windowz?
about

client/FileChunksInfo.cpp:40: error: operands to ?: have different types

commenting out this line is bad idea it must return pointer to FileChunksInfo::Ptr

almiteycow, on Dec 28 2006, 03:09 AM, said:

Missed some files anyway, it seems.

Getting a new compiler error:
Argh.. RevConnect code is driving me nuts...

To Port:
FileChunksInfo.cpp
SharedFileStream.cpp
Text.cpp?
TraceManager.cpp

Then gotta fix random linker errors.

[kvach]

I can help to port network code
but I need some things

1, access to cvs/svn server where code is
2. a contact with person who knows DC stuff and can answer on my question about DC protocol and other
3. tips how to check that ported code not just compiled but works....

My first question can dc client works without gui? can we check that it's work before gui is ported?

BR

[Zlobomir]

Forgive for commenting on this, but IMHO why not? Like:

/join (connect, whatever) dc.some.test.hub:411
*Connected
/listurs Ana* 3 share
*Ana 80GB
*Anabel 30GB
*Anana 10GB

/getfl Ana
*Done
/openfl Ana

Bla Bla Bla.bs (content)

/getfn Bla Bla Bla.bs C:\Testing
*File saved to C:\Testing

Is this what you want, some way to test basic functionality? If not, well, as GUI so and so will be needed, why not make it now? This may answer to point 3. as well.

[almiteycow]

If you guys can help port the network side, I can do the gui stuff.

As long as there's a way to pass raw DC commands, we can test it. I'll post more tomorrow.

[awx]

I'd really like to have a decent DC++ client on Linux... Porting ApexDC++ to Linux sounds like an ambitious task -- at least there is a working linuxdc++ now as a starting point...

Actually, I might be able to help a bit -- but time is rare... My knowledge of DC++ internals is also very limited...

almiteycow, on Jan 29 2007, 10:30 PM, said:

EDIT: Maybe those FILE_SHARE Blah and junk relate to this somehow? MO_IRUSR|MO_IWUSR|MO_IRGRP|MO_IROTH

GENERIC_READ and GENERIC_WRITE are equivalent to O_RDONLY, O_WRONLY, O_RDRW access modes.
that FILE_SHARE_* junk is used to specify whether the file may be read/written/deleted by other handles. AFAIK sharing is enabled by default on Linux systems.
MO_IRUSR|MO_IWUSR|MO_IRGRP|MO_IROTH <-- these are for specifying permissions when creating files
(correct me if I'm wrong)

hope this helps...

[kvach]

that's right file create/access stuff must be rewritten

Why GTK is planned as GUI framework? Why not use QT?
In case of QT it could be cross platform in future ... with shared codebase.
I do not like having two source tree for one application.

One more comment I do not realy see any reason to use python make (scons) it introduces new dependency
may be it is better migrate to autotools (autoconf/automake).
I this case people who wants install apexDC++ do not need having python/scons installed.

I can autotoolize package

[almiteycow]

If the client and GUI can be separated, people could make multiple front-ends for it. I'm not a pro-coder by any means, so I've gotta work with what I know... GTK.

It uses scons, because that's what the linuxdc++ code that I'm merging with uses. If you'd like to autotool it, go for it.

I'm going to see about sourceforging the files, so we can have a cvs to work off of.

[Crise]

almiteycow, on Feb 13 2007, 08:04 PM, said:

If the client and GUI can be separated, people could make multiple front-ends for it. I'm not a pro-coder by any means, so I've gotta work with what I know... GTK.

It uses scons, because that's what the linuxdc++ code that I'm merging with uses. If you'd like to autotool it, go for it.

I'm going to see about sourceforging the files, so we can have a cvs to work off of.

almitey i can arrange that if needed... just say a word (and tell me your SF nick )

[almiteycow]

Been a bit busy lately, but I'm back.

I have access to the SF CVS now, and was about to upload my progress so far, but I had a second thought. Due to the RevConnect issue, I'm thinking about changing the plan of attack once again.

I've taken notice of this project, MultiDC++, which has the GUI and client separated. It's based on a plain DC++ core (I think LinuxDC++, as the dev worked on that project). I'm thinking it would be a great place to start. It's only in alpha stages as it is, but I'm thinking we may still be able to work with it.

I'd like to check it out, but as you may have noticed, I'm still catching up on how to code in Linux, and can't figure out how to set up the makefile for it, just to check it out and so we can test changes and such. Can anyone give me a hand with this?

On a somewhat related note, it looks like we've managed to get a small group of people willing to help us. Thank you, I'll be figuring out how to organize what we're doing in a more constructive manner. The reward still stands, for those interested. I have a feeling the Partial File Sharing/Segmented Downloads is going to be a show-stopper, so still, whoever can port this over to the MultiDC++ core (or LinuxDC++ core, they should be close enough) gets the prize.

[kvach]

almiteycow, on Feb 21 2007, 03:16 AM, said:

Been a bit busy lately, but I'm back.

I have access to the SF CVS now, and was about to upload my progress so far, but I had a second thought. Due to the RevConnect issue, I'm thinking about changing the plan of attack once again.

I've taken notice of this project, MultiDC++, which has the GUI and client separated. It's based on a plain DC++ core (I think LinuxDC++, as the dev worked on that project). I'm thinking it would be a great place to start. It's only in alpha stages as it is, but I'm thinking we may still be able to work with it.

Hi I have been looked into this code already and the main problem with THIS is ObjectC code with some strong dependencies on macOS X.
I do not know ObjectC at least it can be compiled gcc has support of Object C but still all GUI code is not usable for not mac os users. And
last problem is building. It uses some "project" files like visual C projects so we can not compile and run it to check is it work.

IMHO this is not a good start point .