Hey All,
I have created a JIRA entry for adding a Builder interface to the
builder package. The JIRA entry is 601
(http://issues.apache.org/jira/browse/LANG-601). The basic suggestion
is to add an interface Builder that provides a "T build()" method
to indicate that a class is capable of building
Hey All,
I added patches for IO-229, my suggestion to convert AndFileFilter and
OrFileFilter to use varargs constructors instead of two arguments ones
(https://issues.apache.org/jira/browse/IO-229), and IO-239, which was
converting IOCase to a proper enumeration
(https://issues.apache.org/jira/bro
Here is one. The goal is to provide an over-dispersed exponential
distribution which is defined as an exponential distribution with a prior
distribution on the lambda parameter.
/**
* Sample from an exponential distribution whose parameter is distributed
according
* to a Gamma distribution.
*/
The trunk pom.xml refers to 1.5-SNAPSHOT, but it seems to me that the
next release should be 2.0 rather 1.5, as IO now requires Java 1.5,
that requires a major version change.
Does that make sense?
If so, then the maven id can also be fixed (see IO-125).
--
> > Can you imagine a not contrived example? I.e. why would one inherit from a
> > class while throwing away the implementation?
>
> It's precisely to keep the implementation that the parent needs to use
> the getter.
>
> If the parent does not use the getter, then the sub-class will have to
> r
Hi.
> Well, the exponential, chi^2 and Maxwell-Boltzman distributions are all
> specializations of the gamma distribution.
>
> If you working on a Monte-carlo estimate where the parameters of your chi^2
> distribution vary according to a hyper-distribution, then it would be nice
> to implement th
Well, the exponential, chi^2 and Maxwell-Boltzman distributions are all
specializations of the gamma distribution.
If you working on a Monte-carlo estimate where the parameters of your chi^2
distribution vary according to a hyper-distribution, then it would be nice
to implement the chi^2 distribut
On 05/03/2010, Gilles Sadowski wrote:
> Hi.
>
>
> > > > I don't see any changes proposed.
> > >
> > >
> > > I propose to use the instance variable in place of the accessor.
> > >
> > >
> > > > I see a couple of statements that getters are used (usually considered
> > > > good), and a qu
Hi.
> > > I don't see any changes proposed.
> >
> >
> > I propose to use the instance variable in place of the accessor.
> >
> >
> > > I see a couple of statements that getters are used (usually considered
> > > good), and a question about over-riding.
> >
> >
> > Getters are for accessing to e
On 05/03/2010, Gilles Sadowski wrote:
> Hello.
>
>
> > I don't see any changes proposed.
>
>
> I propose to use the instance variable in place of the accessor.
>
>
> > I see a couple of statements that getters are used (usually considered
> > good), and a question about over-riding.
>
>
> Gette
Paul Benedict wrote:
> On Fri, Mar 5, 2010 at 6:17 AM, Niall Pemberton
> wrote:
>> Hmmm - I expected/assumed it would return the same type.
>
> Type T means exactly that: one type. It wouldn't be type-safe if the
> types were changed between input and output.
?? There is no generic type anymor
Hello.
> I don't see any changes proposed.
I propose to use the instance variable in place of the accessor.
> I see a couple of statements that getters are used (usually considered
> good), and a question about over-riding.
Getters are for accessing to encapsulated data. Within the class itself
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=294597&projectId=2634
Build statistics:
State: Ok
Previous State: Failed
Started at: Fri 5 Mar 2010 10:32:31 -0800
Finished at: Fri 5 Mar 2010 10:33:38 -0800
Total time: 1m 7s
Build Trigger: Schedule
Buil
On Fri, Mar 5, 2010 at 6:17 AM, Niall Pemberton
wrote:
> Hmmm - I expected/assumed it would return the same type.
Type T means exactly that: one type. It wouldn't be type-safe if the
types were changed between input and output.
One thing we might want to consider for 3.0 (and it would only be
appropriate in this release or 4.0), is to review exceptions thrown
for illegal null inputs. I bet most throw IAE; should we consider
throwing NPE for them? We did such work with the Validate class. It
would be nice to have a modern
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=294567&projectId=2634
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 5 Mar 2010 09:38:44 -0800
Finished at: Fri 5 Mar 2010 09:40:00 -0800
Total time: 1m 15s
Build Trigger: Schedule
Bui
I don't see any changes proposed.
I see a couple of statements that getters are used (usually considered
good), and a question about over-riding.
What are you proposing?
On Fri, Mar 5, 2010 at 4:34 AM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> Hello.
>
> I'm ready to make the cha
On 2010-03-05, sebb wrote:
> On 05/03/2010, Stefan Bodewig wrote:
>> On 2010-03-04, sebb wrote:
>>> On 04/03/2010, Stefan Bodewig wrote:
The more I think about this, the more I believe we should make
JarArchiveInputStream use the java.util.jar package rather than extend
Zi
- "Gilles Sadowski" a écrit :
> Hello.
>
> I'm ready to make the changes proposed in
> https://issues.apache.org/jira/browse/MATH-348
Hi Gilles,
Sorry, I forgot to comment on the issue. I agree with you, go ahead with the
changes.
Luc
>
> Any objection?
>
> Best,
> Gilles
>
>
Hello.
I'm ready to make the changes proposed in
https://issues.apache.org/jira/browse/MATH-348
Any objection?
Best,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h..
On Fri, Mar 5, 2010 at 11:12 AM, Jörg Schaible wrote:
> Henri Yandell wrote at Freitag, 5. März 2010 10:32:
>
>> Thinking further on moving StringUtils to CharSequence, I'd like to
>> take the String left(String, int) method as an example. It depends on
>> substring(int, int), so is entirely possi
On 05/03/2010, Stefan Bodewig wrote:
> On 2010-03-04, sebb wrote:
>
> > On 04/03/2010, Stefan Bodewig wrote:
>
>
> >> The more I think about this, the more I believe we should make
> >> JarArchiveInputStream use the java.util.jar package rather than extend
> >> ZipArchiveInputStream - this
Henri Yandell wrote at Freitag, 5. März 2010 10:32:
> Thinking further on moving StringUtils to CharSequence, I'd like to
> take the String left(String, int) method as an example. It depends on
> substring(int, int), so is entirely possibly to move over to
> subSequence(int, int).
>
> Hypothetica
On Fri, Mar 5, 2010 at 9:32 AM, Henri Yandell wrote:
> Thinking further on moving StringUtils to CharSequence, I'd like to
> take the String left(String, int) method as an example. It depends on
> substring(int, int), so is entirely possibly to move over to
> subSequence(int, int).
>
> Hypothetica
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=294229&projectId=2634
Build statistics:
State: Ok
Previous State: Building
Started at: Fri 5 Mar 2010 01:32:11 -0800
Finished at: Fri 5 Mar 2010 01:33:05 -0800
Total time: 54s
Build Trigger: Schedule
Buil
Thinking further on moving StringUtils to CharSequence, I'd like to
take the String left(String, int) method as an example. It depends on
substring(int, int), so is entirely possibly to move over to
subSequence(int, int).
Hypothetical new method:
CharSequence left(CharSequence, int)
The down
Very close to 3.0. The major items remaining are:
* LANG-396 Investigate for vararg usages
Lots left on this one - we've not really vararg'd the API yet.
* LANG-456 HashCodeBuilder throws StackOverflowError
First step would be to make a unit test that is very simple and clear,
then
+1
Niall
On Thu, Mar 4, 2010 at 7:04 PM, sebb wrote:
> As was done recently for DPCP, POOL and CODEC, I'd like to get rid of
> all the main() and suite() methods in test cases, and drop the TestAll
> or PackageTest classes.
>
> SureFire allows individual tests to be run, and this can easily be
>
On 2010-03-04, sebb wrote:
> On 04/03/2010, Stefan Bodewig wrote:
>> The more I think about this, the more I believe we should make
>> JarArchiveInputStream use the java.util.jar package rather than extend
>> ZipArchiveInputStream - this would also mean we'd break the API of 1.0,
>> though.
29 matches
Mail list logo
