[freenet-support] JVM Launcher Error
You've missed the point completely. The error message was Could not find the main class. A java programmer knows this to be not an error with the virtual machine, but more of a classpath issue (the VM cannot find the class; it never actually *ran* anything). Recommending that the user upgrade their VM is bad advice since that clearly isn't the issue. It's not too much to ask those who wish to contribute by answering support questions that they actually understand the nuances of Java. Recommending that the user upgrade their VM is bad advice since that clearly isn't the issue. is a prime example of spicious reasoning: it does not follow, because it's not the main issue, that it is bad advice. At most, if the advice was not wrong on itself and if no other recommandations were made, it would constitute inadequate advice. I didn't miss the point, but you mix two things: the recommandation that he uses another JVM, and the recommandation that he should just auto-install the stuff, and not put it manually in a folder. That installing a new JVM is probably not a main issue under XP was made clear enough by my words: 'besides', 'mostly for linux', 'preferably', etc. The fact that it couldn't find the path IS probably due to him installing stuff manually in a folder. Under windows, with the webupdate and all, you can auto-install JVM as well as freenet 'out of the box', without any manual moving around afterwards, as I've said. In fact, your comment about him installing it manually and that he will discover his error, hints at this as well. But since I think it's more difficult to find the right file(s) and move it to the right folder, or adapt the path; the most easy thing to do is auto-installing a new JVM. I have done exactly the same more then once, also under windows, and I've never encountered classpath problems, so IMHO, the recommandation was not 'bad'. Using another JVM like the 1.5.x build is an extra recommandation, for the reasons I already said in earlier posts (and to which you do not agree, I know). Maybe your interaction with users is vastly more elaborate then mine, but *I* didn't see much bugreports with as cause the 1.5.x build, certainly not compared to the 1.4.2 build. And, as you indicated, Toad himself has recommended it already too. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
Re: [freenet-support] JVM Launcher Error
As far as I remember, the winstaller actually checks that the 1.4.x JVM is installed. If you have the 1.5.x JVM, I believe the winstaller will still point fred to use the 1.4.x JVM (I could be mistaken of course because I've not even looked at any of the installer code for over a year) You've missed the point completely. The error message was Could not find the main class. A java programmer knows this to be not an error with the virtual machine, but more of a classpath issue (the VM cannot find the class; it never actually *ran* anything). Recommending that the user upgrade their VM is bad advice since that clearly isn't the issue. It's not too much to ask those who wish to contribute by answering support questions that they actually understand the nuances of Java. Recommending that the user upgrade their VM is bad advice since that clearly isn't the issue. is a prime example of spicious reasoning: it does not follow, because it's not the main issue, that it is bad advice. At most, if the advice was not wrong on itself and if no other recommandations were made, it would constitute inadequate advice. I didn't miss the point, but you mix two things: the recommandation that he uses another JVM, and the recommandation that he should just auto-install the stuff, and not put it manually in a folder. That installing a new JVM is probably not a main issue under XP was made clear enough by my words: 'besides', 'mostly for linux', 'preferably', etc. The fact that it couldn't find the path IS probably due to him installing stuff manually in a folder. Under windows, with the webupdate and all, you can auto-install JVM as well as freenet 'out of the box', without any manual moving around afterwards, as I've said. In fact, your comment about him installing it manually and that he will discover his error, hints at this as well. But since I think it's more difficult to find the right file(s) and move it to the right folder, or adapt the path; the most easy thing to do is auto-installing a new JVM. I have done exactly the same more then once, also under windows, and I've never encountered classpath problems, so IMHO, the recommandation was not 'bad'. Using another JVM like the 1.5.x build is an extra recommandation, for the reasons I already said in earlier posts (and to which you do not agree, I know). Maybe your interaction with users is vastly more elaborate then mine, but *I* didn't see much bugreports with as cause the 1.5.x build, certainly not compared to the 1.4.2 build. And, as you indicated, Toad himself has recommended it already too. ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED] ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
[freenet-support] Stable build 5096
Freenet stable build 5096 is now available. The snapshots have been updated. Please upgrade to 5096, test it, and report any bugs that you find. You can do this by using the update utility on windows (on the start menu), or by running update.sh in linux, or by downloading the new jar from http://freenetproject.org/snapshots/freenet-latest.jar. Either way, it's probably a good idea to shut down the node before doing so (and turn it back on afterwards!). There are many changes in this build, here are some of them: - 5095 is now mandatory. Queueing wasn't really working adequately until 5095. However the overwhelming majority of nodes at least in my RT are 5095, so there is hopefully no problem here... - Lots of work on timeouts, in response to recent problems with inserts. It is likely that the recent insert problems have been caused by insert timeouts being wrong, partly by not taking queueing into account. - A major routing bugfix in the estimator smoothing code. This is used mostly when a node is relatively young. - New, optional, but enabled by default, super-fast routing estimators. These are slightly lower precision than the original estimators, and were developed as part of the recent simulation efforts. These are based on double precision arithmetic (64 bits, 53 of which are mantissa i.e. actual value, we can use), which is accelerated in hardware by most modern CPUs, instead of 160-bit BigIntegers. We believe that doubles provide sufficient precision; the simulations suggest there are no serious bugs in the changeover of this particular code. 53 bits should be enough even for a very large network... In any case the new code is 3-4x faster (in terms of CPU usage, not routing effectiveness or how fast it learns). This is a big part of freenet's overall CPU usage, so expect improvements, especially on low end machines. Turn this off by setting useFastEstimators=false in freenet.conf/freenet.ini. - Also you can use doEstimatorSmoothing to enable or disable estimator smoothing; the results from the simulations on estimator smoothing are unclear at present. - Transfer failures are handled better by Fproxy, there is now a proper error message instead of the unfriendly exception messages we have been seeing reported on devl and support recently. - Much improved Current Downloads page thanks to Iakin (Niklas Bergh). And related bugfixes. - Partial fixes and workarounds for the Too high probability bug. I don't think we have finally fixed the cause of this bug, but at least it will be recovered from virtually instantly. We may have fixed it completely however. - We now have a histogram of the versions of only connected nodes, as well as the histogram of versions of all nodes in the routing table. - Added some missing images for the simple theme (UITemplateSet=simple). - Lots of routing refactoring by Thelema (Edgar Friendly). - Workaround for an infinite loop bug in queueing that I haven't been able to reproduce and fix yet. Will log an error if it happens. - Workaround for a bug in some Sun JVMs, that causes BigInteger.toString(16) to cause an NPE. We now use our own code to dump BigIntegers. - Fix a rare NPE in MuxConnectionHandler - Extra checks for invalid MRIs - Added a method to AutoRequestor to calculate the CHK we would get if inserting a file, given a specific content type, by Vesa Salento. I think this may make freenet.client.cli.Main computechk work correctly, but I haven't tested this. - Paranoia to ensure we never send an HTL over our limit. I don't think current builds do this; I know some older ones did. - start-freenet.sh was still not setting LD_ASSUME_KERNEL for some systems. Fixed it. - Many other minor fixes. -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. signature.asc Description: Digital signature ___ Support mailing list [EMAIL PROTECTED] http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:[EMAIL PROTECTED]
