Re: A chart/graph Library suite
Senthil S wrote: Expecting a chart/graph making library from Apache that is similar to jfreechart and has enhanced features to create live and interactive graphs. The question is: why do you think there should be another charting/graphing library? Do you have problems with the JFreeChart license (LGPL)? You could go shopping around for other libraries, there are at least 50 open source libs for Java and C# on sourceforge, some using BSD or MIT license. For an ASL licensed library, checv out krysalis wings http://www.krysalis.org/wings/, although the project seems to be dead too. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Verifying Downloads
Henri Yandell wrote: which contains nice links to Windows programs. CygWin (http://www.cygwin.com) contains ports of all important Unix command line programs, including gpg and multiple ways to compute md5 (md5, md5sum, openssl md5, perl etc.). A must have. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java@apache
Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. We would want some nice means for aggregating and dynamically managing the data, but fortunately we have a ready standard for dealing with the content: LDAP. The nice thing about standards is that there are so many to choose from. There are also RDF/RSS/DC and a variety of other XML based metadata languages (Topic Maps would fit almost as well as LDAP). J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A free Java data analysis tool?
Jordi Salvat i Alabart wrote: I was actually looking for something readily available we could "partner" with -- rather than develop it ourselves. Hm, could you give a more detailed list of features you expect? E.g.: - input data structure and format (is it a file?) - what statistics? fitting curves? clustering? calculating medians, standard derivations, quantiles, rankings? test for abnormal data? - what nice graphs? lines, bars, different markers, candles, 3D? - just plot or do user interaction: zoom in etc? J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A free Java data analysis tool?
Jordi Salvat i Alabart wrote: Hi. JMeter could make good symbiosis with a free Java data analysis tool. I've been searching a little, but not been able to find anything good. Most relevant requirements are being able to read a set of numeric timed data sets and generate nice graphs and simple statistics from them. Any pointers? Hm. Statistics: jakarta-commons-math. Nice graphs: jFreeGraph or whatever else you can grab from sourceforge (there are at least 3 mature projects). Get the plumbing and UI is still work though. :-/ J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Stephen Colebourne wrote: Once you start getting into a list like this you must consider the IBM ICU project, which tackles these kind of issues. (note, I haven't used ICU). ICU tackles a lot of important functionality, mainly related to extended Unicode support (compared to the Java RT). Most notably it provides character normalization, as well as localized collation, generalized number parsing and formatting, script dependent glyph shaping and some other character/script/text related stuff. It also has all kind of calendars, localized date and time parsing and formatting, extensions for dealing with holidays (very useful), and a somewhat extended support for currencies (also compared to Java RT). Some of the functionality, in particular BIDI support, was adopted by Java 1.4. A look at the ICU4J jar size should make clear that proper i18n is no small undertaking. There's still more to i18n, especially for interactive programs which get significant text input from the user. This requires internationalized input methods, something which is rather nontrivial to get right. There's also hyphenation, word inflection, spell check, punctuation and a few other text/script specific stuff. Other, hardly explored i18n features are writing modes and dialog component arrangement (imagine a drop down box in a lr-tb writing mode), cultural dependent use of colors, patterns and pictograms, and the gadzillion of small differences in national standards and customs for expressing measurements, city names, legalese, lies+threats, formulas and whatnot. Regards J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [i18n] Internationalization subproject sponsor?
Tetsuya Kitahata wrote: many hardships which people in multi-byte area *must* undergo. *bg* http://www.pms.informatik.uni-muenchen.de/lehre/seminar/ internationalisation/02ss/reports-slides/topicK/all.htm (URL broken across line) gives an impression. Besides the more obvious: * Unicode Support * Collation * Number Formatting * Currency * Date and Time * BIDI and general writing mode support * Input Method Engines They even have * Measurement Scales * Paper Sizes * Color: Red + U.S. Meaning: Danger + Asian Countries: Happiness & Good Luck Who'd think about that? Happy lobbying! J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Jakarta should protect community email addresses
asudell wrote: Might it perhaps make sense to scrub or obsucure email addresses from the author tags? There was an article on slashdot mentioning a study about how spammers get the addresses. Basically scraping web pages mailto links and strings looking like email addresses seems to be the most used technology. They stated that even simple obfuscations like using HTML entities or character references will cut spam sent to these addresses drastically, while they are still fully functional as mailto links. Apparently they scan web pages as text, not HTML. Other ideas include strange looking account names containing odd but nevertheless valid characters which throw the scanners off. Unfortunately, Yahoo et al. usually wont accept them either. More advanced JavaScript based techniques or, if the address is for information rather than a mailto link, using "j3322ptm at yahoo dot com" will be successful in cuttting down spam for some time to come, until word gets around and the spammers run out of easy prey and start using HTML parsers, JavaScript engines and advanced pattern matching. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
