- Original Message -
From: "Phil Steitz"
To: "Commons Developers List"
Sent: Friday, April 24, 2009 6:02 PM
Subject: Re: [math] Questions on Field
luc.maison...@free.fr wrote:
- "Bill Barker" a écrit :
I've been looking over the Field implementations, and it looks like
it'
On 25/04/2009, Phil Steitz wrote:
> Phil Steitz wrote:
>
> > I would like to propose that we accept Sanselan as a (proper) commons
> component. See [1] for background on Sanselan. We can discuss the
> administrative issues in [1] as we plan and execute the svn moves and
> component setup.
> >
>
Phil Steitz wrote:
I would like to propose that we accept Sanselan as a (proper) commons
component. See [1] for background on Sanselan. We can discuss the
administrative issues in [1] as we plan and execute the svn moves and
component setup.
Votes, please. This vote will close in 72 hours
Phil Steitz wrote:
I would like to propose that we accept Sanselan as a (proper) commons
component. See [1] for background on Sanselan. We can discuss the
administrative issues in [1] as we plan and execute the svn moves and
component setup.
Votes, please. This vote will close in 72 hours
I would like to propose that we accept Sanselan as a (proper) commons
component. See [1] for background on Sanselan. We can discuss the
administrative issues in [1] as we plan and execute the svn moves and
component setup.
Votes, please. This vote will close in 72 hours (1:00AM UTC 28-April
luc.maison...@free.fr wrote:
- "Bill Barker" a écrit :
I've been looking over the Field implementations, and it looks like
it's
mostly done except for FieldPolynomial. I'm not really sure which
SparseFieldMatrix and SparseFieldVector are also missing for now.
package this
Hi Ate,
I'm glad your switch to SLF4J is doing what you need it to do, and I am in no
way trying to persuade you to change course there. I do think, however, that
the problem of classes loading required resources via the wrong ClassLoader
could easily manifest in webapp / portlet components ot
Mark Thomas wrote:
Ate Douma wrote:
Mark Thomas wrote:
I have seen similar issues in Tomcat's internal logging with
java.util.logging, log4j and commons-logging. Why will this be any
different with slf4j?
Because sfl4j does not use the ContextClassLoader to determine the
logger instance but co
Hi John,
While your example proxy solution is nice enough by itself, imo its way too
much over-engineering for the issue at hand.
We're trying to get rid of the ContextClassLoader use for *only* the logging,
not add more overhead to it!
And, in practice this solution wouldn't work for us anyway
On Fri, Apr 24, 2009 at 8:54 AM, Carsten Ziegeler wrote:
> Niall Pemberton wrote:
>>
>> Yes I think saying 3 committers is a bit mis-leading - since Sanselan
>> entered the incubator Carsten has made the 2nd most commits but that
>> is only 16 commits and he hasn't committed for over a year. Also
sebb wrote:
> OK, that makes sense.
>
> However, only objects that are immutable from construction are
> thread-safe without needing some kind of synchronisation.
>
> Passing it to a newly created thread would be OK (Thread.start() is
> synch.), but if it is passed to an existing thread some other
On Fri, Apr 24, 2009 at 11:50 AM, John Bollinger wrote:
> Ted Dunning wrote:
> > My view is that once it is immutable it is immutable. Restoring
> mutability
> > is done by making a new copy [...].
>
> That position is stronger than you make it sound. Changing a supposedly
> immutable object so
Ted Dunning wrote:
> On Fri, Apr 24, 2009 at 11:50 AM, John Bollinger wrote:
>
> > Ted Dunning wrote:
> > > My view is that once it is immutable it is immutable. Restoring
> > mutability
> > > is done by making a new copy [...].
> >
> > That position is stronger than you make it sound. Changing a
Ted Dunning wrote:
> My view is that once it is immutable it is immutable. Restoring mutability
> is done by making a new copy [...].
That position is stronger than you make it sound. Changing a supposedly
immutable object so that it is mutable would itself be a mutation. If it were
possible th
That is a good and subtle point.
On Fri, Apr 24, 2009 at 11:34 AM, sebb wrote:
> OK, that makes sense.
>
> However, only objects that are immutable from construction are
> thread-safe without needing some kind of synchronisation.
>
> Passing it to a newly created thread would be OK (Thread.start
OK, that makes sense.
However, only objects that are immutable from construction are
thread-safe without needing some kind of synchronisation.
Passing it to a newly created thread would be OK (Thread.start() is
synch.), but if it is passed to an existing thread some other means of
synch. would be
My view is that once it is immutable it is immutable. Restoring mutability
is done by making a new copy and in the context of the applications I was
describing is essentially never done.
On Fri, Apr 24, 2009 at 10:39 AM, sebb wrote:
> allow a programmer to make a mutable copy that
> > is manip
On 24/04/2009, Ted Dunning wrote:
> With small objects like this, it is generally a very clear win to have
> immutable objects.
>
> With larger matrix and vector objects, the advantage is not so clear. It is
> often very nice to mutate large matrices in place via views. This usually
> happen
With small objects like this, it is generally a very clear win to have
immutable objects.
With larger matrix and vector objects, the advantage is not so clear. It is
often very nice to mutate large matrices in place via views. This usually
happens in the context of a single class such as a decom
Ceki Gulcu wrote:
> Mark Thomas wrote:
>>
>> Sorry if I wasn't clear. I intended that the slf4j jars and the third
>> party jars were all in WEB-INF/lib
>>
>> My concern in this scenario is more that this j.u.l, as part of the JRE,
>> will be loaded by the System class loader and hence loggers are
Mark Thomas wrote:
Sorry if I wasn't clear. I intended that the slf4j jars and the third
party jars were all in WEB-INF/lib
My concern in this scenario is more that this j.u.l, as part of the JRE,
will be loaded by the System class loader and hence loggers are
registered JVM wide rather than pe
Mark Thomas wrote:
> John Bollinger wrote:
>> See attached sample code for a class that would support this behavior.
>
> Your attachment didn't make it through. Could you post it in-line?
Sure:
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreeme
luc.maison...@free.fr wrote:
> The points above are not theoretical one. Vector3D was mutable and it
> cost us weeks of works at that time to track difficult bugs in a
> complex application. This was not a simple problem of communication: I
> was involved in all teams from commons-math to high leve
John Bollinger wrote:
> See attached sample code for a class that would support this behavior.
Your attachment didn't make it through. Could you post it in-line?
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.o
Ceki Gulcu wrote:
>
>
> Mark Thomas wrote:
>>
>> Two web applications both using slf4j with java.util.logging and both
>> using a third party library that has a logger called "MyLogger".
>>
>> When web app one uses the library, slf4j will return - via a call to
>> j.u.l.getLogger() - a new logger
- "Gilles Sadowski" a écrit :
> Hello.
Hi Gilles,
>
> Would you consider implementing a _mutable_ 3D-vector class?
> A crude benchmark which I just did shows that re-using the same object
> is
> always (if sometimes only slightly) more efficient than re-creating
> it.
3D vectors have bee
Mark Thomas wrote:
> Ate Douma wrote:
> > When Pluto needs to "aggregate" the content of this TestPortlet, it
> > invokes it render(PortletRequest, PortletResponse) method using a
> > "cross-context" call from the Pluto web application to the "test" web
> > application.
> > The TestPortlet.render
Hello.
Would you consider implementing a _mutable_ 3D-vector class?
A crude benchmark which I just did shows that re-using the same object is
always (if sometimes only slightly) more efficient than re-creating it.
[I can help with the editing work.]
Best,
Gilles
Hi Ate,
Ate Douma wrote at Freitag, 24. April 2009 02:09:
> Hi all,
>
> Thanks to Dennis for bringing this to my attention :)
thanks for providing now the appropriate information and for the level of
detail. It is only possible to react if such information is provided.
- Jörg
---
Mark Thomas wrote:
Two web applications both using slf4j with java.util.logging and both
using a third party library that has a logger called "MyLogger".
When web app one uses the library, slf4j will return - via a call to
j.u.l.getLogger() - a new logger called MyLogger. When web app two use
Ate Douma wrote:
> Mark Thomas wrote:
>> I have seen similar issues in Tomcat's internal logging with
>> java.util.logging, log4j and commons-logging. Why will this be any
>> different with slf4j?
> Because sfl4j does not use the ContextClassLoader to determine the
> logger instance but compile-tim
- "Bill Barker" a écrit :
> I've been looking over the Field implementations, and it looks like
> it's
> mostly done except for FieldPolynomial. I'm not really sure which
SparseFieldMatrix and SparseFieldVector are also missing for now.
>
> package this should go in, since o.a.c.m.analy
Mark Thomas wrote:
Ate Douma wrote:
When Pluto needs to "aggregate" the content of this TestPortlet, it
invokes it render(PortletRequest, PortletResponse) method using a
"cross-context" call from the Pluto web application to the "test" web
application.
The TestPortlet.render method receives the
Ate Douma wrote:
> When Pluto needs to "aggregate" the content of this TestPortlet, it
> invokes it render(PortletRequest, PortletResponse) method using a
> "cross-context" call from the Pluto web application to the "test" web
> application.
> The TestPortlet.render method receives the PortletReque
Niall Pemberton wrote:
>
> Yes I think saying 3 committers is a bit mis-leading - since Sanselan
> entered the incubator Carsten has made the 2nd most commits but that
> is only 16 commits and he hasn't committed for over a year. Also the
> last commit on the project was over 3 months ago:
>
> ht
35 matches
Mail list logo
