Issue 354, graphdependencies vs. sequencedependencies

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue 354, graphdependencies vs. sequencedependencies

Jesse Wilson
Hey Holger ---

I looked at bug 354 and for the most part I think I've fixed it.
There was a slight bug where we were calling our internal
prepareEvent() method multiple times which was causing
inconsistent behaviour between treedeltas and blockdeltas.
Now we only call prepareEvent() one time for each event.

Note that because of the way your code is structured, this
program will not work with graphdependencies at all. That's okay.

graphdependencies was a proof-of-concept dependency manager,
and we went way too long without a better solution. It handled very
simple dependency problems okay, but it was never smart enough
to do things right.

sequencedependencies replaces graphdependencies and is much
simpler, smarter and it handles all the cases I can come up with.
It's better than graphdependencies in every single way and we'll
be migrating to it as quickly as we can.

I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
sequencedependencies turned on, announcing our new dependency
management hotness. Any feature demands for that release?

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue 354, graphdependencies vs. sequencedependencies

Holger
Jesse,

> Hey Holger ---
>
> I looked at bug 354 and for the most part I think I've fixed it.
> There was a slight bug where we were calling our internal
> prepareEvent() method multiple times which was causing
> inconsistent behaviour between treedeltas and blockdeltas.
> Now we only call prepareEvent() one time for each event.


Thanks for taking the time to look into this issue.
I just tried the testcase again with the latest CVS code.
Now, the testcase fails with graphdependencies
and passes with sequencedependencies, independant of the
use of treedeltas and blockdeltas.
Passing the testcase in 1.6 with graphdependencies + blockdeltas
is actually a buggy behaviour as I understand it now.

> sequencedependencies replaces graphdependencies and is much
> simpler, smarter and it handles all the cases I can come up with.
> It's better than graphdependencies in every single way and we'll
> be migrating to it as quickly as we can.

Ok. I'll try the latest version with our application as soon as possible.
Unfortunately, I've no access to a profiler here at home, so I can't
dig into the performance issues I mentioned in the bug description
until I get back to work in two weeks.

>
> I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
> sequencedependencies turned on, announcing our new dependency
> management hotness. Any feature demands for that release?

This sounds good to me, if you are confident that the new dependency
management is ready for prime time.
There were a bunch of bugfixes and a few new features, for example
James' synchToMap() function and Charlies' contribution.
I think it deserves a 1.7

Perhaps we can add some minor enhancements like issue 330 ...

Thanks,
Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Issue 354, graphdependencies vs. sequencedependencies

James Lemieux
1.7 is probably deserved. As of last night, AutoCompleteSupport now officially works without the requirement that .toString() be implemented in any particular way. Instead, a new version of the AutoCompleteSupport.install(...) method has been added which introduces a new parameter: a java.text.Format object.

The Format object is used to convert objects from the ComboBoxModel into Strings and vice versa.

I was torn between using a Format object and using two separate functions. On one hand, Format has a bunch of methods on it that we would never care about:

 Object clone()
          Creates and returns a copy of this object.
 String format( Object obj)
          Formats an object to produce a string.
abstract  StringBuffer format( Object obj, StringBuffer toAppendTo, FieldPosition pos)
          Formats an object and appends the resulting text to a given string buffer.
 AttributedCharacterIterator formatToCharacterIterator( Object obj)
          Formats an Object producing an AttributedCharacterIterator.
 Object parseObject( String source)
          Parses text from the beginning of the given string to produce an object.
abstract  Object parseObject( String source, ParsePosition pos)
          Parses text from a string to produce an object.

but on the other hand it is a class whose semantics fit the use case fairly well. In the end I decided to use the Format object and document that we only call two methods on it.

Holger, I ended up retooling a lot of AutoCompleteSupport because of this. I've tested it pretty well, and I don't think I've broken anything related to the "old" method of doing things, but just beware that it's possible I introduced bugs with this refactoring.

I'm gonna rerecord the original AutoCompleteSupport screencast plus record another one for the new install(..., Format f) API today.

J

On 7/30/06, Holger Brands <[hidden email]> wrote:
Jesse,

> Hey Holger ---
>
> I looked at bug 354 and for the most part I think I've fixed it.
> There was a slight bug where we were calling our internal
> prepareEvent() method multiple times which was causing
> inconsistent behaviour between treedeltas and blockdeltas.
> Now we only call prepareEvent() one time for each event.


Thanks for taking the time to look into this issue.
I just tried the testcase again with the latest CVS code.
Now, the testcase fails with graphdependencies
and passes with sequencedependencies, independant of the
use of treedeltas and blockdeltas.
Passing the testcase in 1.6 with graphdependencies + blockdeltas
is actually a buggy behaviour as I understand it now.

> sequencedependencies replaces graphdependencies and is much
> simpler, smarter and it handles all the cases I can come up with.
> It's better than graphdependencies in every single way and we'll
> be migrating to it as quickly as we can.

Ok. I'll try the latest version with our application as soon as possible.
Unfortunately, I've no access to a profiler here at home, so I can't
dig into the performance issues I mentioned in the bug description
until I get back to work in two weeks.

>
> I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
> sequencedependencies turned on, announcing our new dependency
> management hotness. Any feature demands for that release?

This sounds good to me, if you are confident that the new dependency
management is ready for prime time.
There were a bunch of bugfixes and a few new features, for example
James' synchToMap() function and Charlies' contribution.
I think it deserves a 1.7

Perhaps we can add some minor enhancements like issue 330 ...

Thanks,
Holger

______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Issue 354, graphdependencies vs. sequencedependencies

Jesse Wilson
Hey dude ---

I'd recommend not overloading the install()
method any further. Rather, consider adding
a setFormat() method.

Overloading constructors is gross because
of the combinatorial explosion it introduces:
  -- default Filterator, default Format
  -- custom Filterator, default Format
  -- defalut Filterator, custom Format
  -- custom Filterator, custom Format

Since most people won't be using the Format,
I think it's better as a support setter method.

Cheers,
Jesse

On 7/30/06, James Lemieux <[hidden email]> wrote:

> 1.7 is probably deserved. As of last night, AutoCompleteSupport now
> officially works without the requirement that .toString() be implemented in
> any particular way. Instead, a new version of the
> AutoCompleteSupport.install(...) method has been added which introduces a
> new parameter: a java.text.Format object.
>
> The Format object is used to convert objects from the ComboBoxModel into
> Strings and vice versa.
>
> I was torn between using a Format object and using two separate functions.
> On one hand, Format has a bunch of methods on it that we would never care
> about:
>
>   Objectclone()
>            Creates and returns a copy of this object.
>   Stringformat( Object obj)
>            Formats an object to produce a string.
>  abstract  StringBufferformat( Object obj, StringBuffer toAppendTo,
> FieldPosition pos)
>            Formats an object and appends the resulting text to a given
> string buffer.
>   AttributedCharacterIteratorformatToCharacterIterator( Object obj)
>            Formats an Object producing an AttributedCharacterIterator.
>   ObjectparseObject( String source)
>            Parses text from the beginning of the given string to produce an
> object.
>  abstract  ObjectparseObject( String source, ParsePosition pos)
>            Parses text from a string to produce an object.
> but on the other hand it is a class whose semantics fit the use case fairly
> well. In the end I decided to use the Format object and document that we
> only call two methods on it.
>
> Holger, I ended up retooling a lot of AutoCompleteSupport because of this.
> I've tested it pretty well, and I don't think I've broken anything related
> to the "old" method of doing things, but just beware that it's possible I
> introduced bugs with this refactoring.
>
> I'm gonna rerecord the original AutoCompleteSupport screencast plus record
> another one for the new install(..., Format f) API today.
>
> J
>
>
> On 7/30/06, Holger Brands <[hidden email]> wrote:
> > Jesse,
> >
> > > Hey Holger ---
> > >
> > > I looked at bug 354 and for the most part I think I've fixed it.
> > > There was a slight bug where we were calling our internal
> > > prepareEvent() method multiple times which was causing
> > > inconsistent behaviour between treedeltas and blockdeltas.
> > > Now we only call prepareEvent() one time for each event.
> >
> >
> > Thanks for taking the time to look into this issue.
> > I just tried the testcase again with the latest CVS code.
> > Now, the testcase fails with graphdependencies
> > and passes with sequencedependencies, independant of the
> > use of treedeltas and blockdeltas.
> > Passing the testcase in 1.6 with graphdependencies + blockdeltas
> > is actually a buggy behaviour as I understand it now.
> >
> > > sequencedependencies replaces graphdependencies and is much
> > > simpler, smarter and it handles all the cases I can come up with.
> > > It's better than graphdependencies in every single way and we'll
> > > be migrating to it as quickly as we can.
> >
> > Ok. I'll try the latest version with our application as soon as possible.
> > Unfortunately, I've no access to a profiler here at home, so I can't
> > dig into the performance issues I mentioned in the bug description
> > until I get back to work in two weeks.
> >
> > >
> > > I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
> > > sequencedependencies turned on, announcing our new dependency
> > > management hotness. Any feature demands for that release?
> >
> > This sounds good to me, if you are confident that the new dependency
> > management is ready for prime time.
> > There were a bunch of bugfixes and a few new features, for example
> > James' synchToMap() function and Charlies' contribution.
> > I think it deserves a 1.7
> >
> > Perhaps we can add some minor enhancements like issue 330 ...
> >
> > Thanks,
> > Holger
> >
> >
> ______________________________________________________________
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Re: Issue 354, graphdependencies vs. sequencedependencies

James Lemieux
Jesse,

I'm not offering a combinatorial explosion. They can pass GlazedLists.toStringTextFilterator() as the text filterator arg if they don't really need anything too custom there. We could even accept null and infer that they actually mean "use the toString text filterator."

I like using a setter less because it implies that people change it, possibly multiple times, which would be unexpected. Plus, the logic during the switch from an old Format to a new one could get hairy. Do we try to keep the current selection (as we do with all other setters on AutoCompletionSupport)? What if it is filtered away under the new Format?

James

On 7/30/06, Jesse Wilson <[hidden email]> wrote:
Hey dude ---

I'd recommend not overloading the install()
method any further. Rather, consider adding
a setFormat() method.

Overloading constructors is gross because
of the combinatorial explosion it introduces:
  -- default Filterator, default Format
  -- custom Filterator, default Format
  -- defalut Filterator, custom Format
  -- custom Filterator, custom Format

Since most people won't be using the Format,
I think it's better as a support setter method.

Cheers,
Jesse

On 7/30/06, James Lemieux <[hidden email]> wrote:

> 1.7 is probably deserved. As of last night, AutoCompleteSupport now
> officially works without the requirement that .toString() be implemented in
> any particular way. Instead, a new version of the
> AutoCompleteSupport.install(...) method has been added which introduces a
> new parameter: a java.text.Format object.
>
> The Format object is used to convert objects from the ComboBoxModel into
> Strings and vice versa.
>
> I was torn between using a Format object and using two separate functions.
> On one hand, Format has a bunch of methods on it that we would never care
> about:
>
>   Objectclone()
>            Creates and returns a copy of this object.
>   Stringformat( Object obj)
>            Formats an object to produce a string.
>  abstract  StringBufferformat( Object obj, StringBuffer toAppendTo,
> FieldPosition pos)
>            Formats an object and appends the resulting text to a given
> string buffer.
>   AttributedCharacterIteratorformatToCharacterIterator( Object obj)
>            Formats an Object producing an AttributedCharacterIterator.
>   ObjectparseObject( String source)
>            Parses text from the beginning of the given string to produce an
> object.
>  abstract  ObjectparseObject( String source, ParsePosition pos)
>            Parses text from a string to produce an object.
> but on the other hand it is a class whose semantics fit the use case fairly
> well. In the end I decided to use the Format object and document that we
> only call two methods on it.
>
> Holger, I ended up retooling a lot of AutoCompleteSupport because of this.
> I've tested it pretty well, and I don't think I've broken anything related
> to the "old" method of doing things, but just beware that it's possible I
> introduced bugs with this refactoring.
>
> I'm gonna rerecord the original AutoCompleteSupport screencast plus record
> another one for the new install(..., Format f) API today.
>
> J
>
>
> On 7/30/06, Holger Brands < [hidden email]> wrote:
> > Jesse,
> >
> > > Hey Holger ---
> > >
> > > I looked at bug 354 and for the most part I think I've fixed it.
> > > There was a slight bug where we were calling our internal
> > > prepareEvent() method multiple times which was causing
> > > inconsistent behaviour between treedeltas and blockdeltas.
> > > Now we only call prepareEvent() one time for each event.
> >
> >
> > Thanks for taking the time to look into this issue.
> > I just tried the testcase again with the latest CVS code.
> > Now, the testcase fails with graphdependencies
> > and passes with sequencedependencies, independant of the
> > use of treedeltas and blockdeltas.
> > Passing the testcase in 1.6 with graphdependencies + blockdeltas
> > is actually a buggy behaviour as I understand it now.
> >
> > > sequencedependencies replaces graphdependencies and is much
> > > simpler, smarter and it handles all the cases I can come up with.
> > > It's better than graphdependencies in every single way and we'll
> > > be migrating to it as quickly as we can.
> >
> > Ok. I'll try the latest version with our application as soon as possible.
> > Unfortunately, I've no access to a profiler here at home, so I can't
> > dig into the performance issues I mentioned in the bug description
> > until I get back to work in two weeks.
> >
> > >
> > > I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
> > > sequencedependencies turned on, announcing our new dependency
> > > management hotness. Any feature demands for that release?
> >
> > This sounds good to me, if you are confident that the new dependency
> > management is ready for prime time.
> > There were a bunch of bugfixes and a few new features, for example
> > James' synchToMap() function and Charlies' contribution.
> > I think it deserves a 1.7
> >
> > Perhaps we can add some minor enhancements like issue 330 ...
> >
> > Thanks,
> > Holger
> >
> >
> ______________________________________________________________
> > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: Issue 354, graphdependencies vs. sequencedependencies

Jesse Wilson
Sounds good to me

Be sure to document that we allow 'null' as a standin for 'default'.

Cheers,
Jesse

On 7/31/06, James Lemieux <[hidden email]> wrote:

> Jesse,
>
> I'm not offering a combinatorial explosion. They can pass
> GlazedLists.toStringTextFilterator() as the text filterator
> arg if they don't really need anything too custom there. We could even
> accept null and infer that they actually mean "use the toString text
> filterator."
>
> I like using a setter less because it implies that people change it,
> possibly multiple times, which would be unexpected. Plus, the logic during
> the switch from an old Format to a new one could get hairy. Do we try to
> keep the current selection (as we do with all other setters on
> AutoCompletionSupport)? What if it is filtered away under the new Format?
>
> James
>
>
> On 7/30/06, Jesse Wilson <[hidden email]> wrote:
> > Hey dude ---
> >
> > I'd recommend not overloading the install()
> > method any further. Rather, consider adding
> > a setFormat() method.
> >
> > Overloading constructors is gross because
> > of the combinatorial explosion it introduces:
> >   -- default Filterator, default Format
> >   -- custom Filterator, default Format
> >   -- defalut Filterator, custom Format
> >   -- custom Filterator, custom Format
> >
> > Since most people won't be using the Format,
> > I think it's better as a support setter method.
> >
> > Cheers,
> > Jesse
> >
> > On 7/30/06, James Lemieux <[hidden email]> wrote:
> > > 1.7 is probably deserved. As of last night, AutoCompleteSupport now
> > > officially works without the requirement that .toString() be implemented
> in
> > > any particular way. Instead, a new version of the
> > > AutoCompleteSupport.install(...) method has been added which introduces
> a
> > > new parameter: a java.text.Format object.
> > >
> > > The Format object is used to convert objects from the ComboBoxModel into
> > > Strings and vice versa.
> > >
> > > I was torn between using a Format object and using two separate
> functions.
> > > On one hand, Format has a bunch of methods on it that we would never
> care
> > > about:
> > >
> > >   Objectclone()
> > >            Creates and returns a copy of this object.
> > >   Stringformat( Object obj)
> > >            Formats an object to produce a string.
> > >  abstract  StringBufferformat( Object obj, StringBuffer
> toAppendTo,
> > > FieldPosition pos)
> > >            Formats an object and appends the resulting text to a given
> > > string buffer.
> > >   AttributedCharacterIteratorformatToCharacterIterator(
> Object obj)
> > >            Formats an Object producing an AttributedCharacterIterator.
> > >   ObjectparseObject( String source)
> > >            Parses text from the beginning of the given string to produce
> an
> > > object.
> > >  abstract  ObjectparseObject( String source, ParsePosition pos)
> > >            Parses text from a string to produce an object.
> > > but on the other hand it is a class whose semantics fit the use case
> fairly
> > > well. In the end I decided to use the Format object and document that we
> > > only call two methods on it.
> > >
> > > Holger, I ended up retooling a lot of AutoCompleteSupport because of
> this.
> > > I've tested it pretty well, and I don't think I've broken anything
> related
> > > to the "old" method of doing things, but just beware that it's possible
> I
> > > introduced bugs with this refactoring.
> > >
> > > I'm gonna rerecord the original AutoCompleteSupport screencast plus
> record
> > > another one for the new install(..., Format f) API today.
> > >
> > > J
> > >
> > >
> > > On 7/30/06, Holger Brands < [hidden email]> wrote:
> > > > Jesse,
> > > >
> > > > > Hey Holger ---
> > > > >
> > > > > I looked at bug 354 and for the most part I think I've fixed it.
> > > > > There was a slight bug where we were calling our internal
> > > > > prepareEvent() method multiple times which was causing
> > > > > inconsistent behaviour between treedeltas and blockdeltas.
> > > > > Now we only call prepareEvent() one time for each event.
> > > >
> > > >
> > > > Thanks for taking the time to look into this issue.
> > > > I just tried the testcase again with the latest CVS code.
> > > > Now, the testcase fails with graphdependencies
> > > > and passes with sequencedependencies, independant of the
> > > > use of treedeltas and blockdeltas.
> > > > Passing the testcase in 1.6 with graphdependencies + blockdeltas
> > > > is actually a buggy behaviour as I understand it now.
> > > >
> > > > > sequencedependencies replaces graphdependencies and is much
> > > > > simpler, smarter and it handles all the cases I can come up with.
> > > > > It's better than graphdependencies in every single way and we'll
> > > > > be migrating to it as quickly as we can.
> > > >
> > > > Ok. I'll try the latest version with our application as soon as
> possible.
> > > > Unfortunately, I've no access to a profiler here at home, so I can't
> > > > dig into the performance issues I mentioned in the bug description
> > > > until I get back to work in two weeks.
> > > >
> > > > >
> > > > > I think we'll push out a 1.6.2 or perhaps even a 1.7 release with
> > > > > sequencedependencies turned on, announcing our new dependency
> > > > > management hotness. Any feature demands for that release?
> > > >
> > > > This sounds good to me, if you are confident that the new dependency
> > > > management is ready for prime time.
> > > > There were a bunch of bugfixes and a few new features, for example
> > > > James' synchToMap() function and Charlies' contribution.
> > > > I think it deserves a 1.7
> > > >
> > > > Perhaps we can add some minor enhancements like issue 330 ...
> > > >
> > > > Thanks,
> > > > Holger
> > > >
> > > >
> > >
> ______________________________________________________________
> > > > Verschicken Sie romantische, coole und witzige Bilder per SMS!
> > > > Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > [hidden email]
> > > > For additional commands, e-mail:
> > > [hidden email]
> > > >
> > > >
> > >
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [hidden email]
> > For additional commands, e-mail:
> [hidden email]
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]