Hi, Christian! I've been working with Jeroen, and we seem to have fixed the major problem that prevented the program from working. It was crashing on a regular basis, caused by the reception of some message that was not handled properly. Jeroen was able to make some changes that allowed him to duplicate the problem, and then fix it. I've got a test version running now, and it's looking good so far.
>Unless you contribute a (unified) diff of your changes, those problems won't disappear anytime soon. I've found that everyone wants diffs created in their own format that they find the most familiar. If you send me the switches you use, and what you mean by a 'unified' diff, I'd be glad to send you the diffs. I just send Jeroen a set of diffs that contained the changes I made for the SUN environment. >Is it possible, that you talk about C99 features and not GNU C specifics? As I don't know which code you're talking about, I've no idea what the actual problem is. Yes - I've only just downloaded the ISO/IEC 9899:1999 spec, so that I can tell which is which. My original comment about GNU came from a comment I found in the file, which said something about 'Don't worry - this is a GNU extension'. And right now I can't even find the place where I saw this. I was pretty tired after about 12 hours of concentrated debugging at the time so I was a littel grumbly - please forgive me if it came over as strongly as it appears to. Gtk-gnutella had required that I also port, test, and build 10 additional support libs, and I couldn't even start work on the port until those were done. It was a bad day. >I've installed them in parallel (which isn't really a problem) and if you want to develop portable code and has to be compilable by GCC as well. In my case, I can't do that. Instead, we use separate machines for the GNU work, and it's actually on a different platform. With Sun hardware, every single one of our users runs Solaris. No one runs Linux or SunOS 4.x on them. So we don't have a GNU install on Solars. >There's no Linux-dogma. It's just that mostly Linux users want to use and develop Gtk-Gnutella. Maybe HP-UX, AIX, RiscOS users etc. are too lazy or give up too soon? ;-) No, problable most of them are not allowed to use P2P on corporate hardware. The machines are too expensive for the casual user to buy for use at home, and corporate policy prevents the use of P2P in most companies, unless you sneak it in. At least that's what I think might be the case. Solaris X86 is on the edge, sort of between these two groups. We've found that the most common Solaris X86 user is a professional engineer who uses it at work on SUN hardware, and wants the same OS at home. It's because the cost of the OS used to be about $1000 per CPU. Two years ago, we had a huge fight with SUN's management, and got them to give it away for the cost of the media, or a small fee if you want media and install docs. It's now cheaper than any comparable Windows platform. As to porting it, I don't know - On Linux, if you want it, you build it, or find a prebuilt RPM. On Solaris, almost everything comes with the OS. But not things like P2P - instead, they give you IPSEC/IKE, and so on. There are people who do build packages like gnutella for the users, and put them up on web sites, but they don't want to make the effort to do the porting. They just install the prebuilt gcc/g++ from the 'companion software' disk, which is filled with GNU software. So yes, at least on Solaris, the general user is either too intimidated, or too lazy to bother with a port. I may be the exception, because I only use the SUN compilers. I've asked SUN to send me an update, because they do have a new version of the compiler that is supposed to be C-1999-compliant. I don't know how long it will take to get here, but it's certainly time that I updated my tools. And that may make a lot of the porting issues go away - at least I hope so. My current tools are only C-89 compliant, although they are much newer than 1989. I think the C/C++ compilers are from 2001. But at that time, SUN was trying to drop the X86 platform entirely. We took out 1/2-page ads in the San Jose papers, hammering at the decision, and finally met with SUN's management, to convince them that this was a very bad decision. We eventually got them to understand, and since then, they have even stated publicly that it was a terrible decision, and they have even embraced the platform to the point of offering two 'edge servers', rackmount mutli-processor systems based on the Intel motherboards. It's just that Sun and Intel do not get along at all - both of them think that each has screwed the other big-time, so SUN didn't want to help Intel sell anything. I think they were also worried about the X86 chips taking away market from the Sparc lines, which were beginning to lose market share at that time. This was also when the tech stocks hit the floor, and Sun was looking for ways to save money. We showed them instead how they could make money with the X86 product, and they finally listened. It's a great OS, and a cost-effective platform. I pointed out to them that my dual-P-III 1GHZ machine running Solaris outperformed my dual-SPARC system on my desk at work by about 100%, using standard benchmarks and with their compilers. My X86 box cost $1500, while the Sparc box cost $35,000! And while the Sparc hardware might be much more reliable in the long term (i doubt it), the X86 hardware is fine for a rack-server. You could build a server-farm of X86 boxes for the cost of one large SUN, and get a lot of redundancy too, and it would still cost less by far. Anyway, Sun appears to be behind the product finally, as they paid whoever makes their compiler to update it to the current ANSI standards. And I think they had something like 700,000 downloads of the free software (back when they didn't even charge the $20 download/license fee). They finally got it that this was a great platform, and their users wanted it. It didn't hurt that we had over 20,000 signatures on a petition when we went to speak to their management, either. Back to business: >This is either a recent problem or has to be rejected. 0.92.1c compiled flawless with SUN's Workshop Pro compiler 8.0 and was useable - although not heavily tested. The Workshop 8 version is the one that is supposed to be completely C-1999 compliant, so that does indicate that most of the issues are related to the new language features. Some things were new, I guess, like the void function that was returning a value. My compiler thinks that is fatal! But it's certainly a simple fix. It's interesting that GNU doesn't choke on it, but it probably does whats right, and just discards the value, since the calling function doesn't look for it anyway. >There were no reports, requests and maybe no requirement at all. Nobody can fix problems he isn't aware of. Yes, and I'm sorry that's probably the case. Again, I think corporate policy is the problem here. ITS doesn't want people using their expensive servers for sharing MP3 files at work. Nor do they want the possible legal issues that sharing touches. But I'm a little surprised that someone didn't pick up a cheap AIX system on EBAY, and bring it home. That type of user would probably want it. But if they also have a Windows PC, they probably just run Kazaa instead. Kazaa-lite has gotten really good, as far as performance, and it's painless to install on Windows. Files that turn up 8 or 10 sources on gnutella, turn up over 200 sources on Kazaa (Inu Yasha Anime videos, for instance), and the download speeds with that many users will usually fill your bandwidth pipe completely. I often get 160K/sec downloads in Kazaa, which is the max my cable-modem will allow. So far, no P2P program that I have on UNIX has exceeded even 50K/sec, yet it's on the same pipe. The best has been epic4, an IRC program. >English is surely not the perfect language but it's rather easy to learn and if everyone were forced to use it, there would be less problems. Yeah - I agree, especially from the standpoint of porting. I had to port IBM's ICU libraries to 5 UNIX platforms, including RedHat, and I'd hate to have to do it again. We broke just about every compiler trying to get that working. We ended up having to disable optimization for specific files on most platforms, because of the way it's coded. It's multi-threaded, and that just makes things harder, because all the platforms have slightly different thread packages in the OS. Sun and RedHat were the easiest! (HPUX the worst...) I finally disabled the NLS in the Configure, although at first I just used the defaults. But I don't need the functions, and if I had known more about how gnutella uses these features at the time, I would have left them out from the beginning. The problem is that at the start of a port, I usually know nothing about the software, and have not even seen the program work on any platform. >That might be true and I could list dozens of popular programs which won't compile with anything but gcc or even worse: [snipped] Absolutely! This is frustrating to me, because I really don't want to install gcc on my system. I find the SUN compiler does everything I need, and it's a good tool, so why install another one? It takes disk space up, and I think it still modifies the include files from a standard system. It used to, anyway, and I didn't want anything to mess up the includes, as it might break the SUN tools. But there are many programs which were created on systems that only have gcc/g++ available, and without those systems, we might never have gotten the software in the first place. Even Linux bootstrapped on top of gcc, and that's a valuable OS that I'd hate to lose. It's also brought thousands of people into the computer world that would not have come if Linux or one of the variants weren't available. Anyway, my approach is that if I really want the program, then I make the effort to do the port. We've also had people do things like write soundcard drivers, and make them available to the public, because they wanted to use that card in their system. But not every one can do that, and I consider myself lucky that I can. I've been a UNIX engineer since 1987, when I started working on a port of some legal software to a DEC microvax from a PC platform. I've never really gone back to the Windows environment as a developer. These days, I'm a porting and systems engineer for a large company. I take their Windows development code and port it to the 5 or so UNIX platforms that we support. And right now I'm home on sick leave. I had some surgery, and they damaged my spine during the operation, so I have chronic pain. I'm trying to get disability, because it will never get better, only worse. Spinal nerves don't heal, ever. >However, all libraries you mention are required but almost any GTK program and also used by many other stuff. I don't think there are many up-to-date desktop system which miss these. Well, actually the commercial UNIX systems do, because they are all built on X11/Motif. Sun uses DisplayPoscript, but that's going away and will be replaced by Gnome2 as the desktop. But I don't think any of them shipped much GNU or FSF software of any kind, as part of the OS. Sun's companion CD does contain many packages like these, but it's because they are all requested by the users, who also helped in the porting. Sun actually gives out the GNU gcc/g++ compilers now, on the companion CD, so if you don't have a commercial compiler, you just install the package - painless! But really, I don't recall AIX, HPUX, or Solaris having any of these libs. Of course, I knew about all of them, except for pango, which I had never heard of. But I never had any need for them, because I had the graphic tools I needed on Windows. I use the Solaris system more for development and as a database server. I run Oracle on it. >You should at least mention which code exactly causes problems with your compiler and also report all compiler warnings as they might indicate serious bugs. I did this, but after I send the mail you responded to. I hadn't hooked up with Jeroen yet, so I had no idea where to send the details to. It looks like the code he sent me today is working quite well, after I made the few changes I needed to to work around the compiler problems. I'm still worried about the way I hacked the ZERO_LENGHT macro in gnutella.h, and will have to read the code more to make sure I didn't break anything. But the program is running without any crashes so far, and both uploads and downloads are working. So are searches. I'm really pleased to find that you didn't restrict the search function. I looked at the LimeWire beta recently, and for me it's useless, because it does not do a very deep search. They seem to be depending on the propagation of the ultrapeers to handle the scares source files, but it clearly doesn't. The same search term in their program turned up 27 files, none with more than 2 sources. In two hours, gnutella has found 1400 files, many with as much as 8 sources, for the exact same search. In their program, many files just don't get returned at all. And while it's not quite like Kazaa, this is a different network, and is not as heavily populated as the Windows world. Or at least it seems that way. Kazaa often finds 200 sources or more for these same files, within about 2 hours. But as long as it finds it, that's what's important. So I've thrown Limewire away, and am very pleased that Jeroen and I were able to find and fix the problems. Because it sure looks like gnutella will do the trick for me. If I get time, I may ask to join you folks in development, or maybe write some docs for you. I'm a reasonable technical writer. But we'll deal with that when I am sure I will have time to contribute. Again, let me apologize for the way this mail came across, as I was in pain, tired from all the work getting the libs ported, and grumpy too. There is no reason why I should take that out on your team, and I'm sorry if it came across that way. The problem with hitting bugs in a port is that it's not clear where the problem lies. I was really worried that it would be traced to one of the libs, because they also were ported. It was just another place where things could go wrong. Or that it was pilot error in the porting. But it turned out that it was a real group of errors in the code, which just weren't caught by gcc (another reason why I like the Sun tools - they are strict, but they catch almost every error.) Jeroen has the details, and has already put the changes into the CVS system at gtk-gnutella.asselman.com, since that's where I got the current code I am running. I've sent him the diffs from my changes to that code, and he will decide what goes into the CVS files, I guess. But it's working, and that's a good thing. I'm going to do more testing, and also do a non-debug build, since that could have a big effect on the thruput, and I'll send more mail if I find any problems that you should know about. If you need anything from me, let me know. Regards, --Carl ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Gtk-gnutella-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
