Hello.
> > [...]
> >
> > The idea is to have "interleaved" calls to the candidate
> > implementations, so
> > that (hopefully) they will be penalized (or benefit) in the same way
> > by what
> > the JVM is doing (GC or JIT compilation or ...) while the benchmark
> > is
> > running.
> >
> > Does
On Mon, Jul 25, 2011 at 9:56 AM, Stefan Bodewig wrote:
> On 2011-07-25, wrote:
>
>> If the URL do include the version, then it would be better to keep old
>> version online, to avoid dangling links from external web pages, mail
>> archives or documentation.
>
> Good point, thanks Luc. The Javado
On Sun, Jul 24, 2011 at 07:27:50PM -0700, Phil Steitz wrote:
> On 7/24/11 2:43 PM, er...@apache.org wrote:
> > Author: erans
> > Date: Sun Jul 24 21:43:08 2011
> > New Revision: 1150496
> >
> > URL: http://svn.apache.org/viewvc?rev=1150496&view=rev
> > Log:
> > MATH-632
> > Added tests referred to
Dinner? It is only 9am in Hawaii. I haven't even had breakfast yet.
Ralph
On Jul 25, 2011, at 11:30 AM, Christian Grobmeier wrote:
> uh yes :-)
>
> Sorry for the spam - time to have dinner and grab a beer!
>
> On Mon, Jul 25, 2011 at 8:29 PM, Matt Benson wrote:
>> Wrong list? ;)
>>
>> Matt
uh yes :-)
Sorry for the spam - time to have dinner and grab a beer!
On Mon, Jul 25, 2011 at 8:29 PM, Matt Benson wrote:
> Wrong list? ;)
>
> Matt
>
> On Mon, Jul 25, 2011 at 1:18 PM, Christian Grobmeier
> wrote:
>> Hey all,
>>
>> OpenSymphony has closed. Not sure if OSCache has survived.
>> T
Wrong list? ;)
Matt
On Mon, Jul 25, 2011 at 1:18 PM, Christian Grobmeier
wrote:
> Hey all,
>
> OpenSymphony has closed. Not sure if OSCache has survived.
> This page recommends OSCache:
> http://cayenne.apache.org/doc/query-result-caching.html
>
> It looks like this project is the follow up:
>
Hey all,
OpenSymphony has closed. Not sure if OSCache has survived.
This page recommends OSCache:
http://cayenne.apache.org/doc/query-result-caching.html
It looks like this project is the follow up:
java.net/projects/oscache
But it seems also to be rather dead (last commit > 4 yrs)
Is it time t
On 25 July 2011 16:23, Gary Gregory wrote:
> On Mon, Jul 25, 2011 at 4:41 AM, Stefan Bodewig wrote:
>> Hi all,
>>
>> given that most discussion has only been started late last week, it has
>> been a bit unorganized and some things have moved during the weekend
>> I'll give it a bit more time to s
On Mon, Jul 25, 2011 at 10:27 AM, Torsten Curdt wrote:
>>> Maybe I am working too much in other languages to appreciate the "less
>>> is more" way of coding.
>>> Self descriptive code is less a myth but more a state of mind when
>>> writing that code and documentation.
>>
>> The problem with that
On 7/25/11 8:27 AM, Torsten Curdt wrote:
>>> Maybe I am working too much in other languages to appreciate the "less
>>> is more" way of coding.
>>> Self descriptive code is less a myth but more a state of mind when
>>> writing that code and documentation.
>> The problem with that "state of mind" is
>> Maybe I am working too much in other languages to appreciate the "less
>> is more" way of coding.
>> Self descriptive code is less a myth but more a state of mind when
>> writing that code and documentation.
>
> The problem with that "state of mind" is that unless and until you
> clearly specify
On 7/25/11 6:31 AM, Matt Benson wrote:
> On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt wrote:
Good code needs little javadocs.
>>> I disagree strongly.
>>>
>>> The Javadoc should present the public API (and should ideally be
>>> written before the code - i.e. the code implements the docs).
>
On Mon, Jul 25, 2011 at 4:41 AM, Stefan Bodewig wrote:
> Hi all,
>
> given that most discussion has only been started late last week, it has
> been a bit unorganized and some things have moved during the weekend
> I'll give it a bit more time to settle.
>
> IMHO svn trunk is ready to be released a
On 7/25/11 6:55 AM, Torsten Curdt wrote:
> I am not saying don't use javadocs. It's all about using javadocs effectively.
>
> Forcing javadocs on all methods leads to bloat and noise. Better
> present stellar javadocs on public APIs and document how the library
> works. Having great examples helps
On Mon, Jul 25, 2011 at 9:59 AM, Phil Steitz wrote:
> On 7/25/11 1:36 AM, luc.maison...@free.fr wrote:
>> Hi Jörg,
>>
>> - Mail original -
>> De: "Jörg Schaible"
>> À: dev@commons.apache.org
>> Envoyé: Lundi 25 Juillet 2011 09:19:36
>> Objet: Re: [math] Inherits doc and @Override
>>
>>> H
On 7/25/11 1:36 AM, luc.maison...@free.fr wrote:
> Hi Jörg,
>
> - Mail original -
> De: "Jörg Schaible"
> À: dev@commons.apache.org
> Envoyé: Lundi 25 Juillet 2011 09:19:36
> Objet: Re: [math] Inherits doc and @Override
>
>> Hi Phil,
>> Phil Steitz wrote:
>>> On 7/24/11 10:52 PM, Jörg Scha
On 7/25/11 1:13 AM, Torsten Curdt wrote:
>> Here's the problem as I see it. Code with no javadoc is bad, bad,
>> bad.
> Good code needs little javadocs.
>
> http://vafer.org/blog/20050323095453/
>
> Good docs and good code over noise - any time.
Ummno.
Without method javadoc, library code
2011/7/22 Arne Ploese :
> Hi,
>
> I saw in the sources serveral /** {@inheritDoc} */ on methods with
> @Override annotation. Javadoc knows to inherit the javadoc of the
> overwritten methos, so there is no need for @inheritDoc.
> If all agree, one could drop this if the code is modified?
For refer
I am not saying don't use javadocs. It's all about using javadocs effectively.
Forcing javadocs on all methods leads to bloat and noise. Better
present stellar javadocs on public APIs and document how the library
works. Having great examples helps a great deal ...but don't (please
don't!) use Ecli
On Mon, Jul 25, 2011 at 5:07 AM, Torsten Curdt wrote:
>>> Good code needs little javadocs.
>>
>> I disagree strongly.
>>
>> The Javadoc should present the public API (and should ideally be
>> written before the code - i.e. the code implements the docs).
>>
>> If the only documentation is the code,
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
On 2011-07-21, sebb wrote:
> However just doing that without adding @Override and minimal generics
> will result in compilation warnings; it seems wromg to release source
> that does not compile cleanly.
The zip64 branch now requires Java5 but I'm having a hard time seeing
any compiler warnings.
>> Good code needs little javadocs.
>
> I disagree strongly.
>
> The Javadoc should present the public API (and should ideally be
> written before the code - i.e. the code implements the docs).
>
> If the only documentation is the code, it is much harder for users to
> determine how to use the API.
On 25 July 2011 09:13, Torsten Curdt wrote:
>> Here's the problem as I see it. Code with no javadoc is bad, bad,
>> bad.
+1
> Good code needs little javadocs.
I disagree strongly.
The Javadoc should present the public API (and should ideally be
written before the code - i.e. the code implemen
On 23.07.11 08:17, Henri Yandell wrote:
> If you want to get the code committed, it makes life fractionally
> easier for you rather than figuring out how to svn switch over. I'm
> happy to wait on your nod before doing the svn move.
It's ok as it is now.
How is the policy here concerning larger c
On 2011-07-25, wrote:
> If the URL do include the version, then it would be better to keep old
> version online, to avoid dangling links from external web pages, mail
> archives or documentation.
Good point, thanks Luc. The Javadoc URLs for Compress currently don't
contain a version number so t
- Mail original -
> Hello.
Hi Gilles,
>
> Finding myself repeatedly writing the same few lines when trying to
> figure
> out which of several implementations of some functionality was
> running
> faster, I wonder wether it would be interesting to add a little
> utility in
> the "test"
Hi Stefan,
- Mail original -
> Hi all,
>
> some components keep the Javadocs for older versions online in
> addition
> to the ones of the current release. In our case the Javadocs for 1.2
> won't be too different from the ones of 1.1, so I don't think it is
> worthwhile, but still I'd li
Hi all,
given that most discussion has only been started late last week, it has
been a bit unorganized and some things have moved during the weekend
I'll give it a bit more time to settle.
IMHO svn trunk is ready to be released and likely won't change except
for release notes, version numbers and
Hi Stefan!!!
I think that keeping old javadocs would have more sense when we
release major releases, for cases such as compress 1.1 -> 1.2, tags
like @since, @deprecated, ... are more than enough.
just my 2 cents, have a nice day!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.o
Hi Jörg,
- Mail original -
De: "Jörg Schaible"
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 09:19:36
Objet: Re: [math] Inherits doc and @Override
>Hi Phil,
>Phil Steitz wrote:
>> On 7/24/11 10:52 PM, Jörg Schaible wrote:
>>> Hi Phil,
>>>
>>> Phil Steitz wrote:
>>>
On 7/
Hi all,
some components keep the Javadocs for older versions online in addition
to the ones of the current release. In our case the Javadocs for 1.2
won't be too different from the ones of 1.1, so I don't think it is
worthwhile, but still I'd like to double check.
Does anybody want the Javadocs
> Here's the problem as I see it. Code with no javadoc is bad, bad,
> bad.
Good code needs little javadocs.
http://vafer.org/blog/20050323095453/
Good docs and good code over noise - any time.
cheers,
Torsten
-
To unsubscrib
- Mail original -
De: "Gilles Sadowski"
À: dev@commons.apache.org
Envoyé: Lundi 25 Juillet 2011 00:18:56
Objet: Re: [jira] [Resolved] (MATH-599) Re-implementation of Secant-based root
finding algorithms
>
> Luc Maisonobe resolved MATH-599.
>
>
> Res
Hi Phil,
Phil Steitz wrote:
> On 7/24/11 10:52 PM, Jörg Schaible wrote:
>> Hi Phil,
>>
>> Phil Steitz wrote:
>>
>>> On 7/24/11 3:13 PM, Gilles Sadowski wrote:
Hello.
> I saw in the sources serveral /** {@inheritDoc} */ on methods with
> @Override annotation. Javadoc knows to inh
35 matches
Mail list logo
