Thanks for the info. Yes, Greg Bildson has kept the project going through lots of changes in people, and making the opensourcers (both hired and volunteer) an important part of the team sure looks like it works. I too like his contributions (i.e his current work with torrents), and I expect that Jens-Uwe Mager and Roger Kapsi will be recognized on the .org page too.

[OT]I don't code, but your remark that the java VM HotSpot compiler uses internal fixed-size static structures reminded me of some Console messages I've been seeing lately on OS X
"stiefs-iBook kernel: resize: max chain len 40, new table size 8192" Any chance this is related?[/OT]

If you're looking at the code, I'd be interested in what you find about 'browse host' and 'ethernet' transfers

The "internal fixed-size structures" in the Java HotSpot compiler is not related to this message. It is related to the way methods calls and method entries are encoded, with strange limitations on the supported method signatures (the count and types of parameters).

These limits on supported method calls are really not intuitive and they way they can be fixed is opposed to the normal OOB programming philosophy of Java:
- sometimes this requires creating temporary work classes to pass these method parameters.
- sometimes some large methods need to be splitted in the source code by the programmer into smaller sub-methods even if the method size is below the threshold of about 4KB of bytecode.
- some small methods fail when HotSpot try to inline them in the compiled native code, or will run much slower if they are not inlined manually directly in the source code.
- the methods profiling performed by HotSpot to determine which methods should be inlined is based on a threshold number of past calls. But this counting does not work for all calls, so some methods may never reach this threshold, even if they are used extremely often. These small methods are nearly never compiled to native code and run slower.
- more generally, the rationale of these limits is not clear, and one needs to profile the application in its critical code parts to see which coding style will work best.

You can diagnose the cases where methods will not be compiled to native code at run-time by HotSpot (and then will run in a much slower interpreted mode) with some undocumented flags on the "java" command-line or set by the JVM instanciation program (such as limewire.exe on Windows): it displays "COMPILATION SKIPPED" messages on the console.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

[removed odd link to picture]

new bug--can anyone else confirm?

-I searched for DSCF0025.jpg in "Any Type", and most of the results incorrectly showed the green "checkmark" icon.

details
-jum 352
-I had two pics of different sizes with the same name already (1 shared, 1 in the unshared download folder) downloaded
-search returned ~200 results, 169 unique files ranging from a few KB up to 4 MB from about 8 different vendors

btw--searching for home collections of digital camera shots is a fun way to either discover the next Anselm Adams, or else to make you feel good about your own abilities

The green checkmark isn't based solely on hash -- if a file exists by the same name, it'll mark it also.

can the checkmark be easily made to reflect the hash? I'm assuming results are grouped based on hash . . .

With the recent changes to support Plastic themes, I experiment now problems when displaying some icons: they are unstable, sometimes the wrong icon is displayed for buttons, and the selected icon changes sporadicly. In a row of graphic buttons (for example tabs at the top, or the row of action buttons for the search results), it happens that all these buttons are showing the same icon, and then they change without user action, or when the mouse cursor passes over it.
However this never happens for the small icons of media selectors, or for file icons.

I think that this is related to the new message I see on the console when starting LimeWire:

OpenGL pipeline enabled for default config on screen 0

(this message appears as the first line of output, before any other debug output generated by LimeWire itself, after that Java VM has been created but still when LimeWire is loading).

Is it possible that the recent Microsoft patch for GDI+ in Windows XP has changed the behavior of Java2D for JPEGs, but possibly too for GIFs and PNGs?
(Note: I see that with the most recent version of the JDK 1.5-beta2)

Is it a bug of Java, or Windows, or of the Plastic Theme integration?
I don't see this message in other Swing apps with the same VM on the same host. I can't see why LimeWire would need OpenGL here, or what can cause Java2D to enable it. Apparently the display bug looks very much like a synchronization issue in the management of the graphic renderer (would it use a pipeline which does not work properly with OpenGL?).

I tried with the Java 1.4.1 JRE, and I have the same display problem (but not the OpenGL message above). Is this bug within the new PlasticTheme library? Does it use OpenGL?

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

Try adding "-Dsun.java2d.opengl=false" to the parameter for starting java. I've noticed at home that openGL is enabled by default on Java5 and basically made LimeWire look like a blob of splattered paint.

Yeah, the checkmark can be made to reflect only the hash -- but it wasn't intended to be a 100% exact match. It's designed to let you know you probably have this file -- hashes are a surefire way, but the filename is also a pretty good way. Perhaps the filename should also include a size check, ensuring that the two are similar sizes? Or maybe a blue instead of green checkmark for the filename matches. Grouping is still done only by hash.

Salut Sam, I was thinking about hash and files and got a little idea. Often you get results of files with the same size and same name but different sha1. An optimisation would be that once you download one file LW gets the tiger tree of the other files with same size same name: if some trees correspond, LW downloads from both files (more sources). The tigers that differ are only downloaded on the the file selected to dl by user. Of course you don't add sources with different sha1 in the download mesh.

I had another idea for uploads but I forgot it today

__________________
Liens d'intérêt /Links of interest:
Gnutellaforums en français /The House's rules you have to respect / First search the forum, then create a thread / Free software alternatives! - Logiciels alternatifs gratuits!/