Good morning everyone,
just to let you know that I've committed the code in rev1170462, for
everyone to patch.
The process was actually in two stages, because I think I
misunderstood how svn should be configured in order to handle
automatically eol. So I had to change manually the SVN property, and
Sébastien,
Yes, this is what I had in mind. Others on the list might disagree, but I
think paying a bit in performance for some modicum of thread safety in
listener/event handling code will make your life simpler.
-Greg
2011/9/11 Sébastien Brisard
> Hello all,
> @Greg: I've modified the constr
Hello all,
@Greg: I've modified the constructor according to your message on JIRA
this.listeners = new CopyOnWriteArrayList();
Is that what you were concerned about? I'm sorry to say I know nothing
on thread issues, and I could use your help! I'm almost certain I will
be facing a potential thread-s
I sent the original to the wrong thread, my apologies!
Sebastian,
The only observation I made is in the JIRA notes. Use thread safe
collections for the listener lists. There is a bit of overhead, but if you
have long running optimizations you might want to connect, get the state of
the optimizati
On 9/10/11 12:45 AM, Sébastien Brisard wrote:
> Thanks to you both for your review.
>
>> 0) maybe incrementIterationCount in the manager should be called
>> startIteration
>>
> OK
>> 1) I guess TooManyEvaluations is the only thing left to throw, but
>> MaxIterationsExceeded or even something new li
Hi.
> Thanks to you both for your review.
Unfortunately, I didn't have the time to thoroughly read the code.
>
> >
> > 0) maybe incrementIterationCount in the manager should be called
> > startIteration
> >
> OK
> >
> > 1) I guess TooManyEvaluations is the only thing left to throw, but
> > MaxI
Thanks to you both for your review.
>
> 0) maybe incrementIterationCount in the manager should be called
> startIteration
>
OK
>
> 1) I guess TooManyEvaluations is the only thing left to throw, but
> MaxIterationsExceeded or even something new like IllegalIteration
> might make sense here (bad nam
On Fri, Sep 09, 2011 at 01:03:22PM -0700, Phil Steitz wrote:
> On 9/9/11 12:13 PM, Sébastien Brisard wrote:
> > Hi,
> > I was wondering if anyone of you had the chance to look at the new
> > piece of code submitted (JIRA MATH-655).
> > Thanks for your comments!
>
> Sorry to be slow on this. I wou
On 9/9/11 12:13 PM, Sébastien Brisard wrote:
> Hi,
> I was wondering if anyone of you had the chance to look at the new
> piece of code submitted (JIRA MATH-655).
> Thanks for your comments!
Sorry to be slow on this. I would say go ahead and commit the last
patch and we can talk about patching fr
Hi,
I was wondering if anyone of you had the chance to look at the new
piece of code submitted (JIRA MATH-655).
Thanks for your comments!
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional comman
I forgot a very important question: would this classes be applicable
to ODEs (see Luc's explanations below). If not, I can probably forget
about them, since, I think this package makes the most extensive use
of events at the moment in CM...
Sébastien
>
> So here are the needs for ODE:
> - callback
Hi,
I'm reviving this thread to let you know that I took the liberty to
create a new JIRA ticket on this issue (see JIRA MATH-655). A few
classes are attached to this ticket for you to review. These classes
provide support for managing the iteration count as well as event
occuring before, during an
Le 11/08/2011 06:14, Phil Steitz a écrit :
On 8/10/11 8:19 PM, Sébastien Brisard wrote:
Hello,
going back to the initial conversation. It seems to me that
formalizing Iterative Algorithms in a general way is very interesting,
but not a realistic target for 3.0 (or probably even 3.1). However, I
>
> Sounds reasonable to me; though I would personally be fine with
> adding some small classes along the lines of what I outlined above
> to support events. They could even be package-scoped if we want to
> keep them out of the public API and replace later with more general
> constructs used else
On 8/10/11 8:19 PM, Sébastien Brisard wrote:
> Hello,
> going back to the initial conversation. It seems to me that
> formalizing Iterative Algorithms in a general way is very interesting,
> but not a realistic target for 3.0 (or probably even 3.1). However, I
> would very much like to have a satis
Hello,
going back to the initial conversation. It seems to me that
formalizing Iterative Algorithms in a general way is very interesting,
but not a realistic target for 3.0 (or probably even 3.1). However, I
would very much like to have a satisfactory working version of linear
iterative solvers. I'
Luc,
I think we misunderstood each other, in the snippet below, my intention was
to agree with him. Everything Gilles was agreeable and hard to argue
against.
-Greg
>
> Luc
>
>
> Not sure what you mean.
>>
>>
>> In my opinion, discussions should serve to solve real problems of a
>>> software
>
This is very much what I had in mind. The downside is that the committer is
saddled with a recurring task. -Greg
On Wed, Aug 10, 2011 at 1:39 PM, Ted Dunning wrote:
> I have been able to manage some long-lived branches in Zookeeper and Mahout
> using git.
>
> The key was to rebase the branch fre
I have been able to manage some long-lived branches in Zookeeper and Mahout
using git.
The key was to rebase the branch frequently. That allowed me to spread the
complexity of the ultimate merge out into a lot of small decisions, each of
which was pretty simple and could be tracked back to a smal
Le 10/08/2011 16:30, Greg Sterijevski a écrit :
Gilles,
I think we do agree on most points:
For very-limited functionality, this could be an option. The big drawback
is that, if it takes time to implement, the merge with the "official"
branch
may not be trivial. [IIUC, Ted suggested that "git"
Hi.
> I think we do agree on most points:
>
> For very-limited functionality, this could be an option. The big drawback
> > is that, if it takes time to implement, the merge with the "official"
> > branch
> > may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
> > in making
Gilles,
I think we do agree on most points:
For very-limited functionality, this could be an option. The big drawback
> is that, if it takes time to implement, the merge with the "official"
> branch
> may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn"
> in making this less
Hello.
> I think you hit the nail on the head with the comment:
>
> "... but also the time to
> experiment. Only the latter will be able to tell if the design is good.
> And this must take time so that all the potential pitfalls can be ..."
>
> Maybe this is chumming the water with more flotsam
I was not aware that someone has codified this. The "Rules for
Revolutionaries" is very very good. There is an elegant order out of
disorder theme that permeates it. Thank you. -Greg
On Tue, Aug 9, 2011 at 1:04 PM, Mark Thomas wrote:
> On 09/08/2011 18:50, Greg Sterijevski wrote:
> > I think y
In that case, I'm quite happy to test one of the options which have
been suggested within the framework of linear solvers.
I could for example try and implement the Obervable/Observer option,
and see how it goes.
Sébastien
2011/8/9 Mark Thomas :
> On 09/08/2011 18:50, Greg Sterijevski wrote:
>> I
On 09/08/2011 18:50, Greg Sterijevski wrote:
> I think you hit the nail on the head with the comment:
>
> "... but also the time to
> experiment. Only the latter will be able to tell if the design is good.
> And this must take time so that all the potential pitfalls can be ..."
>
> Maybe this is
This is a great idea.
And it is something you can just do on github.
On Tue, Aug 9, 2011 at 10:50 AM, Greg Sterijevski wrote:
> Would it be possible to fork the trunk of the source tree to an
> "experimental branch"? Whether its monitoring the progress of ODE solvers,
> other solvers or any othe
I think you hit the nail on the head with the comment:
"... but also the time to
experiment. Only the latter will be able to tell if the design is good.
And this must take time so that all the potential pitfalls can be ..."
Maybe this is chumming the water with more flotsam and jetsam, but a lot
On Tue, Aug 09, 2011 at 05:46:47PM +0200, Luc Maisonobe wrote:
> Le 09/08/2011 09:28, Phil Steitz a écrit :
> >On 8/8/11 10:46 PM, Sébastien Brisard wrote:
> >>2011/8/8 Phil Steitz:
> >>>+1 to the idea of using the Observer pattern; but -0 for
> >>>Observable. I would favor defining Events and Lis
Le 09/08/2011 09:28, Phil Steitz a écrit :
On 8/8/11 10:46 PM, Sébastien Brisard wrote:
2011/8/8 Phil Steitz:
+1 to the idea of using the Observer pattern; but -0 for
Observable. I would favor defining Events and Listeners because a)
Observable is concrete, so effectively forces you to create
One approach that will minimize the burden on commons math developers is to
point users to an AspectJ approach as is discussed here:
http://www.ibm.com/developerworks/java/library/j-aopwork6/index.html
The article starts out with a discussion of how to implement the observer
design pattern the
> >> +1 to the idea of using the Observer pattern; but -0 for
> >> Observable. I would favor defining Events and Listeners because a)
> >> Observable is concrete, so effectively forces you to create an
> >> Observable delegate
> >>
> > I'm not sure I understand. Components in java.awt also need to
On 8/8/11 10:46 PM, Sébastien Brisard wrote:
> 2011/8/8 Phil Steitz :
>> +1 to the idea of using the Observer pattern; but -0 for
>> Observable. I would favor defining Events and Listeners because a)
>> Observable is concrete, so effectively forces you to create an
>> Observable delegate
>>
> I'm
2011/8/8 Phil Steitz :
>
> +1 to the idea of using the Observer pattern; but -0 for
> Observable. I would favor defining Events and Listeners because a)
> Observable is concrete, so effectively forces you to create an
> Observable delegate
>
I'm not sure I understand. Components in java.awt also n
> > a useful feature for *any* iterative algorithm would be the
> > possibility to call a "monitor" at the end of each iteration. What
> > would this monitor do would pretty much depend on the user's mood:
> > periodically backup the state of the algorithm (in order to restart it
> > in case of a c
+1 on JMX framework.
On Mon, Aug 8, 2011 at 3:41 PM, Phil Steitz wrote:
> On 8/8/11 11:52 AM, Sébastien Brisard wrote:
> > Hi,
> > a useful feature for *any* iterative algorithm would be the
> > possibility to call a "monitor" at the end of each iteration. What
> > would this monitor do would pr
On 8/8/11 11:52 AM, Sébastien Brisard wrote:
> Hi,
> a useful feature for *any* iterative algorithm would be the
> possibility to call a "monitor" at the end of each iteration. What
> would this monitor do would pretty much depend on the user's mood:
> periodically backup the state of the algorithm
How about just serializing the object? -Greg
2011/8/8 Sébastien Brisard
> Hi,
> a useful feature for *any* iterative algorithm would be the
> possibility to call a "monitor" at the end of each iteration. What
> would this monitor do would pretty much depend on the user's mood:
> periodically bac
Hi,
a useful feature for *any* iterative algorithm would be the
possibility to call a "monitor" at the end of each iteration. What
would this monitor do would pretty much depend on the user's mood:
periodically backup the state of the algorithm (in order to restart it
in case of a crash), log a set
39 matches
Mail list logo
