DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20807.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
**
Note: This e-mail is subject to the disclaimer contained at the bottom
of this message.
**
:
Hi,
We currently use the JxPath 1.1 release and we
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20815.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Tim, Robert et al,
I agree, it would be ideal if we had a commons wide or jakarta wide license.
Everyone seems to be pointing to Robert as the person to talk to about it.
Since Robert's suggested to talk to community or the jakarta pmc I'll head
off in their direction and report back on my
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20813.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
I'd like to request karma for the Jakarta Commons IO project.
My goals:
- Merge/move IO helper functions from FOP into Commons IO.
- I've already submitted an alternative implementation of a
ByteArrayOutputStream that is considerably faster than the original. I
have some additional ideas in
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-18/commons-codec.html
Buildfile: build.xml
init:
[mkdir] Created dir:
+1.
What's left in making this happen? Does Jeremias need a different
'Jakarta' login to get around group-issues at the moment or can the group
thing be done?
Hen
On Wed, 18 Jun 2003, Jeremias Maerki wrote:
I'd like to request karma for the Jakarta Commons IO project.
My goals:
-
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20865.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
mdiggory2003/06/17 20:05:45
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Simplified calculation, removing extra division.
Revision ChangesPath
1.6 +2 -1
Thanks Brent, thats what I was looking for.
Brent Worden wrote:
Here are some recursive formulas for higher central moments
http://www.spss.com/tech/stat/Algorithms/11.5/descriptives.pdf
Brent Worden
http://www.brent.worden.org
-
Al Chou wrote:
--- Brent Worden [EMAIL PROTECTED] wrote:
Looks fine.
Two points for discussion:
1. Will we ever have the need to compute statistics from sub-arrays? i.e
getMean(double[] array, int beginIndex, int endIndex) much like
I think that's a worthwhile feature.
Not a bad idea, in the
mdiggory2003/06/18 05:42:24
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Rolling back to previous version.
Revision ChangesPath
1.7 +86 -86
jakarta-commons-sandbox/math/src/java/org/apache/commons/math/stat/StatUtils.java
Index:
From the (perhaps not quite current?) overview I concluded that
to extend Clazz for Customizing a Family of Reflected Clazzes
I have to create
1) a subclass of Reflected*PropertyInspector
2) some (two) AccessMethodParsers
3) a subclass of (Standard)ReflectedClazz
4) a subclass of
Hi,
if I have the following class
public class Hrglbrmft {
public void addFoo(Bar bar) { ... }
public List getFoos() { ... }
}
should the property returned by Clazz be called foos or foo?
Currently foos is returned.
Victor
--- Weitergeleitete Nachricht / Forwarded Message ---
Date: Wed, 18 Jun 2003 15:24:35 +0200 (MEST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: getFoos and addFoo: property name foos or foo
Hi,
if I have the following class
public class Hrglbrmft {
public void addFoo(Bar
mdiggory2003/06/18 06:47:35
Modified:math/src/java/org/apache/commons/math/stat
UnivariateImpl.java
Log:
Degegates to StatUtils now for window case. Implemented skew and kurt using
recursive moments.
Revision ChangesPath
1.10 +316 -345
mdiggory2003/06/18 06:57:24
Modified:math/src/java/org/apache/commons/math/stat
UnivariateImpl.java
Log:
Last commit got formated with tabs, this is formated with spaces
Revision ChangesPath
1.11 +315 -309
I'll be happy to do a release. There have been no feature changes
whatsoever, just bug fixes, so it should perhaps be a maintenance 1.1.1
release. Let me reformulate that in the form of a question:
Is there a special procedure for making a maintenance release that
would skip all those betas?
-
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
* @param values Is a double[] containing the values
* @return the result, Double.NaN if no values for an empty array
* or 0.0 for a single value set.
@@ -168,10 +175,12 @@
} else if
To add my two cents... I think that it is clearer and more standard for a
class to be named for what it is and does instead of how it is recommended
to be used (delegatory vs. sub-class). I think that any recommendations of
that sort could go in the JavaDoc, but are out of place in the name. I
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Al Chou wrote:
--- [EMAIL PROTECTED] wrote:
mdiggory2003/06/17 20:05:45
Modified:math/src/java/org/apache/commons/math/stat StatUtils.java
Log:
Simplified calculation, removing extra division.
Revision ChangesPath
We need to get test cases committed for StatUtils before adding/modififying
anything else. I am OK with what has been a added; but we need to comply with
our stated guidelines, which require test cases for all committed code.
StatUtils needs its own test cases.
--- [EMAIL PROTECTED] wrote:
Thanks for looking at it, Robert. Is there anything you (anyone?) noticed
that was unnecessarily complex?
I tried (and am open for suggestions) to make it as simple as possible
while still being powerful.
Eric Pabst
|-+--
| |
I could go back and forth on this, but I think that whether the singular
form or plural form is returned, it should be CONSISTENT. I think that it
is easier to implement the singular form since at least one method should
already have it in the singular form. If there are no methods with the
Victor,
1. Are you really trying to add support for a FAMILY of reflected
clazzes? It almost sounds to me that you want to modify accessor
recognition for some specific clazzes. If that's what you are trying to
accomplish. There is a much easier way to do so: you create a custom
Clazz. If it is
Eric,
I got it. This is a valid point and I already said in an earlier post
that I would rename the ~Support classes to Base~. The only place
where I want to keep the ~Support naming is the unit tests. If I call
a class ~Test, Maven will think this is truly a test that needs to run.
I might as
To address this issue, Clazz has this mechanism of aliases. The
plural form is chosen as the basic one and the singular is an alias.
So, if you ask to clazz to iterate its properties, you are going to see
foos there. However, if you specifically ask for the property foo,
it will understand
Cool! That sounds great.
Eric Pabst
|-+---
| | Dmitri Plotnikov|
| | [EMAIL PROTECTED]|
| | com|
| | |
| | 06/18/03 09:24 |
| |
I'm starting to feel replying to commit messages probibly isn't the best
route to posting on the list. I recommend we not do it or at least
rewrite the subject headings to include the [math] string.
Back to the subject, Yes, your quite right, I feel there are two avenues
of testing going on
This has been a problem for about the last 24 hours or so. This may be
breaking the nightly build.
[junit] Running org.apache.commons.math.RealSolverTest
[junit] Tests run: 2, Failures: 0, Errors: 1, Time elapsed: 0.08 sec
[junit] Testsuite:
mdiggory2003/06/18 08:59:55
Added: math/src/test/org/apache/commons/math/stat
StatUtilsTest.java
Log:
Initial Deposit for StatUtils unit testing, this was derived from
StoreUnivariateImplTest.
Revision ChangesPath
1.1
The original contributor is going to supply patches soon. Check out the
Bugzilla patch submission from yesterday.
Tim
On Wed, 18 Jun 2003, Mark R. Diggory wrote:
This has been a problem for about the last 24 hours or so. This may be
breaking the nightly build.
[junit] Running
To commit to a jakarta-* repository one does need to be a member of the
jakarta unix group (except for jakarta-gump, which is open to any
Apache committer). Once you're ready to request it, send a note to
[EMAIL PROTECTED]
Brian
On Wed, 18 Jun 2003, Henri Yandell wrote:
+1.
What's
Mark R. Diggory wrote:
(1) Direct testing: Copy the StoreUnivariateImplTest and rewrite it to
work with StatUtils as StatUtilsTest..
Done
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
I'm starting to feel replying to commit messages probibly isn't the best
route to posting on the list. I recommend we not do it or at least
rewrite the subject headings to include the [math] string.
Back to the subject, Yes, your quite right, I
Phil Steitz wrote:
Each class should include direct test cases and each new commit should be
accompanied by test cases. Unless we want to modify the guidelines, we need to
comply with them. You will notice that we have lots of other classes (e.g.
RandomData, all of the distributions stuff) that
More nitpicking. I don't see that multiplying top and bottom by
values.length
makes things better. In fact, it could reduce precision by inflating the
magnitude of the first term before subtracting from it and dividing it.
hmm, good points. this may be an example of where
luehe 2003/06/18 10:06:02
Modified:el/src/java/org/apache/commons/el ArithmeticOperator.java
MinusOperator.java MultiplyOperator.java
PlusOperator.java
Log:
cut-and-paste error in javadocs
Revision ChangesPath
1.3
[EMAIL PROTECTED] wrote:
- * This product includes software developed by the
+ * This sumLog includes software developed by the
The traps of global sr, I guess... :-)
J.Pietschmann
-
To unsubscribe, e-mail:
Tim O'Brien wrote:
I have commons-math and commons-codec clover licenses which are available
to any commons committer who asks, and are housed on apache
infrastructure.
I think it would be cleaner from a legal standpoint if someone like Robert
asked for a commons-wide license, or better yet
accum += Math.pow(values[i], 2.0);
I think Math.pow should not be used for small integer exponents,
in particular 2,3 and perhaps 5. You could do this in FORTRAN or
other languages with a built-in power operator, because the compiler
will optimize it, but languages without that usually rewrite
tobrien 2003/06/18 10:46:38
Modified:codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java
Log:
Removed characters which were breaking GUMP build. Need to replace character
literals with Unicode codes
Revision ChangesPath
1.2
Phil Steitz wrote:
More nitpicking. I don't see that multiplying top and bottom by
values.length
makes things better. In fact, it could reduce precision by inflating the
magnitude of the first term before subtracting from it and dividing it.
hmm, good points. this may be an
tobrien 2003/06/18 11:43:56
Modified:codecproject.properties project.xml
codec/src/java/org/apache/commons/codec/base64 Base64.java
codec/src/java/org/apache/commons/codec/language
DoubleMetaphone.java
Log:
Checkstyle
hlship 2003/06/18 11:47:01
Modified:hivemind/src/test/hivemind/test/config SetLocation.xml
hivemind/xdocs descriptor.xml configuration.xml intro.xml
hivemind/src/test/hivemind/test/parse
TestDescriptorParser.java TestToString.java
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20652.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20652.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
(1) Does it seem logical that when working with n (or values.length)
to use Math.pow(n, x), as positive integers, the risk is actually
'integer overflow' when the array representing the number of cases gets
very large, for which the log implementation of Math.pow would help
retain greater
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
(1) Does it seem logical that when working with n (or values.length)
to use Math.pow(n, x), as positive integers, the risk is actually
'integer overflow' when the array representing the number of cases gets
very large, for which the log
tobrien 2003/06/18 13:06:48
Modified:math project.xml
Log:
Readded some activity reports to the maven site, now that we have more activity some
of these reports make more sense
Revision ChangesPath
1.19 +4 -4 jakarta-commons-sandbox/math/project.xml
Thanks for entertaining my sometimes naive questioning,
J.Pietschmann wrote:
Mark R. Diggory wrote:
(1) Does it seem logical that when working with n (or
values.length) to use Math.pow(n, x), as positive integers, the risk
is actually 'integer overflow' when the array representing the number
On Wednesday, June 18, 2003, at 03:59 PM, [EMAIL PROTECTED]
wrote:
Thanks for looking at it, Robert. Is there anything you (anyone?) noticed
that was unnecessarily complex?
I tried (and am open for suggestions) to make it as simple as possible
while still being powerful.
it didn't look
--- Mark R. Diggory [EMAIL PROTECTED] wrote:
Thanks for entertaining my sometimes naive questioning,
J.Pietschmann wrote:
Mark R. Diggory wrote:
(1) Does it seem logical that when working with n (or
values.length) to use Math.pow(n, x), as positive integers, the risk
is actually
--- Phil Steitz [EMAIL PROTECTED] wrote:
--- Tim O'Brien [EMAIL PROTECTED] wrote:
On Tue, 17 Jun 2003, Mark R. Diggory wrote:
We all agree that the optimized double[]|- double computations should be
reused. The problem with the above is that you can't dynamically
reorganize
class
Ortwin,
It is an odd problem. Not quite a dead-lock in the traditional sense.
One thread is waiting on the other, and the other is waiting for the
garbage collector. It just so happens that the garbage collector will
never kick in, because the first thread happens to be the AWT Event
Michael Becke wrote:
We allow a 0 timeout indicating an infinite wait. This is in fact the
default.
Makes me think of Queen's song who wants to live forever :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Hello All,
Is there a problem when a comma appears in a cookie value? See 02109POS below. It has
a comma in the value and is split into two cookies. IE at least parses this cookie as
one cookie. Is there a workaround for this?
My understanding is that a cookie value can have any character
Mike,
I think you're roughly agreeing with what I would conclude, but I wasn't
sure and I wanted to get other's feedback.
Michael Becke wrote:
Doing something time-consuming from the event thread is a little
questionable I think. It's an easy way to keep a user from using the
UI but it
Karaoke at Ortwin's house tonight :)
Mike
Ortwin Glück wrote:
Michael Becke wrote:
We allow a 0 timeout indicating an infinite wait. This is in fact the
default.
Makes me think of Queen's song who wants to live forever :-)
Eric,
I think you're roughly agreeing with what I would conclude, but I wasn't
sure and I wanted to get other's feedback.
Yes, I think your analysis was correct.
Unfortunately, I am not directly responsible for the design and
implementation of the product, and we're not focusing resources
Brett,
I didn't download the source, just the jar and the docs. Could I subclass
from a CookieSpec and just replace the parse of Set-Cookie? I would prefer
to not have to modify the source so I can easily replace it with upcoming
versions without having to put my change back in.
Is your fix
Rob,
This is a well known issue. According to the RFC 2109 comma is
considered a spacial character. Cookie values that contain special
characters MUST be in a quoted string. Please refer to the following bug
report for more details:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11240
The
Ron (I apologise for misspelling your name in my previous post),
You can easily subclass any of the CookieSpec classes. The trouble is
there's no way to plug a custom cookie spec into the existing
implementation of HttpClient. At the moment you have to modify
CookiePolicy class and recompile
Hey,
This is a patch which will determine the content type if null based on
file extension. I used the file extension mapping from
$TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif
files. Any thoughts or a kick in the right direction would be helpful.
Thanks and Hope
66 matches
Mail list logo
