From: itinerants <iti...@ho...> - 2007-11-03 20:22:36
|
A coupla weeks ago I decided to port dc++ onto OSX, that is, to put a native interface onto the "client" section of the code. It went well - had it up and running in about 8 hours, another 4 to put some semblance of "nice" interface on it, and I've been using it, crashless (well, a few due to my own errors) since then. I did, however, find the following, which I think are NOT my bugs, but I stand to be corrected... 1. I see there is some "if macintosh" type code, so I needed to turn off SO_NOSIGPIPE... BufferedSocket::accept BufferedSocket::connect Both needed sock->setSocketOpt(SO_NOSIGPIPE, 1); With the other socket options. I suspect this is a mac only fix, but I know nothing about pcs, so I can't be sure. 2. DirectoryListing::loadFile need to be specified as throwing FileException, SimpleXMLException - corrupt file lists, as well as the routine itself, throw more than just "Exception". I'm not a c++ expert, but my understanding of the "throw" thing in the function prototype is that if you throw something other than what's listed, you get a runtime exception and the prog exits if it isn't handled - can't see that it is being handled. This certainly killed my version until I added the new specifiers. 3. in .702... In "StringDefs.cpp", A) in ResourceManager::strings between "Tag", and " Target filename too long", There should be "Target removed" B) in ResourceManager::names between "Tag", and "TargetFilenameTooLong", There should be "TargetRemoved" 4. The AutoSearch thing... It saves a list of the 30 last "searched for" strings. This means that, if you have, say, 29 items in your list, once they've all been searched for, no more autosearching is performed, yet if you have 31, it'll keep cycling around. I fixed this by clearing the list if nothing to search for is found, then, next time around, we're back searching again. 5. The autosearch interval needs to be user-specifiable. It's either 120000, or 300000, but some hubs have 10 minute minimum search intervals! On those hubs, autosearch never finds anything after the first one, since the hub bounces every subsequent search as being within the minimm search interval. 6. Unless I've missed something, which is quite possible, users in the wait list who aren't online are shown only with their CIDs? I've created a "Downloaders" database/window that shows how much has been down/up loaded from each user you've down/up loaded from/to. I had this on an earlier Valknut port and now wouldn't/couldn't live without it. It tells you who might be a good target for future downloads (it also shows max/average speed for each). To do this it hooks into the DownloadManagerListener, UploadManagerListener, BufferedSocketListener, ClientManagerListener, and QueueManagerListener (to collect nicks for people before you've downloaded from them). The other advantage is that my wait list uses THIS database to provide real nicks. Guess that's more a suggestion than a bug, sorry. There are a bunch of other things of lesser import, but I'll stop for now. Hope some of this is useful, if not, just send a nuke my way! Regards and keep up the good work. "SomeQuestions" |
From: James R. <si...@wa...> - 2007-11-03 21:05:27
|
-------------------------------------------------- From: "itinerants" <iti...@ho...> Sent: Saturday, November 03, 2007 8:22 PM To: <dcp...@li...> Subject: [dcplusplus-devel] Source level bug (probably) report > 3. in .702... > In "StringDefs.cpp", > > A) in ResourceManager::strings > between > "Tag", and " Target filename too long", > There should be "Target removed" > > B) in ResourceManager::names > between > "Tag", and "TargetFilenameTooLong", > There should be "TargetRemoved" For what it's worth, this was caused by a typo in StringDefs.h (which StringDefs.cpp is generated from), and has since been fixed in SVN (r873, 29 October 2007). -- James Ross |
From: Fredrik U. <ul...@gm...> - 2007-11-04 14:10:15
|
On Nov 3, 2007 9:22 PM, itinerants <iti...@ho...> wrote: > 4. The AutoSearch thing... > It saves a list of the 30 last "searched for" strings. > This means that, if you have, say, 29 items in your list, once they've all > been searched for, no more autosearching is performed, yet if you have 31, > it'll keep cycling around. > I fixed this by clearing the list if nothing to search for is found, then, > next time around, we're back searching again. > > 5. The autosearch interval needs to be user-specifiable. It's either 120000, > or 300000, but some hubs have 10 minute minimum search intervals! On those > hubs, autosearch never finds anything after the first one, since the hub > bounces every subsequent search as being within the minimm search interval. > If there's less than 30 items, DC++ should start over again with the queue. (It didn't at some point, and a patch was provided to fix it. This was quite a long time ago.) However, there's still bugs in that code; The code only checks for the total size of the queue, and not the size of the files that are eligable for autosearch. That is, if there's a file that's set to paused or is running etc, and there's less than 30 items, the autosearch mechanism will (then) break. I'm not sure if a user defined search interval would be useful. First off, most people would probably keep the interval at its minimum. The setting seem to be only useful in those instances where the hub has a completely silly minimum interval, and it feels bad to endorse that kind of behaviour where massive user count is the goal (and the hub's reasoning of setting a silly minimum interval to preserve bandwidth). -- Fredrik Ullner |
From: Jacek S. <arn...@gm...> - 2007-11-04 17:55:45
|
itinerants wrote: > 1. I see there is some "if macintosh" type code, so I needed to turn off > SO_NOSIGPIPE... > BufferedSocket::accept > BufferedSocket::connect > Both needed > sock->setSocketOpt(SO_NOSIGPIPE, 1); > With the other socket options. > I suspect this is a mac only fix, but I know nothing about pcs, so I can't > be sure. linux has a similar issue/trick...win32 doesn't... > 2. DirectoryListing::loadFile need to be specified as throwing > FileException, SimpleXMLException - corrupt file lists, as well as the > routine itself, throw more than just "Exception". I'm not a c++ expert, but > my understanding of the "throw" thing in the function prototype is that if > you throw something other than what's listed, you get a runtime exception > and the prog exits if it isn't handled - can't see that it is being handled. > This certainly killed my version until I added the new specifiers. *Exception inherit from Exception so it should be safe...although I'm sure there are lots of places in the code with bad specifiers (msvc didn't enforce this so I never cared really much about it)...currently I use a gcc switch to disable the runtime exception =) > 6. Unless I've missed something, which is quite possible, users in the wait > list who aren't online are shown only with their CIDs? yeah, at some point some sort of caching of nicks (and other info) should be added... an open mac port would be welcome, to this end I've been striving to make the non-gui part more library like to maybe break it off in some distant future... /J |