I removed the underscores to comply with the tests already there!
On Wed, Feb 25, 2009 at 04:37, webpaul <goo...@webpaul.net> wrote:
>
> Excellent, this sounds like what I was after.
>
> /// <summary>
> /// There are several places where we need to iterate over an
> enumerable
> /// several times, but we cannot assume that it is safe to do so.
> /// This class will allow to safely use an enumerable multiple
> times, by caching
> /// the results after the first iteration.
> /// </summary>
>
> I can only assume ayende will flog you repeatedly for taking the
> underscores out of the test names.
>
> On Feb 24, 7:27 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> > Fixed.
> >
> >
> >
> > On Sat, Feb 21, 2009 at 16:48, webpaul <goo...@webpaul.net> wrote:
> >
> > > Yes, that sounds much better than getting no rows on subsequent
> > > iterations
> >
> > > On Feb 21, 9:25 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> > > > Then, I guess that if you want to be able to get the results multiple
> > > times
> > > > without actually enumerating the original enumerable you need to
> cache
> > > the
> > > > enumerations, so that once it's enumerated for the first time,
> subsequent
> > > > enumerations go to the cache. Would this make sense? We already have
> a
> > > > cached enumerator, this would simply mean to swap the
> OneTimeEnumerable
> > > with
> > > > the CachedEnumerator.
> >
> > > > On Sat, Feb 21, 2009 at 16:19, pb648174 <goo...@webpaul.net> wrote:
> >
> > > > > I just looked at the change below:
> >
> > > > > if (alreadyEnumerated)
> > > > > return Enumerable.Empty<T>().GetEnumerator();
> >
> > > > > Which I think will also lead to unexpected results. For example, if
> 3
> > > > > rows, rows.Count() will return 3 the first time and 0 the second
> time.
> > > > > I would expect to be able to iterate the rows each time and get the
> > > > > data but to not suddenly multiple rows in other operations based on
> > > > > how many times the rows were iterated. I think if you want to go
> this
> > > > > route it should either a) throw an exception that the results are
> > > > > being enumerated multiple times so these kinds of problems are
> found
> > > > > faster during development or b) just allow it to be enumerated
> > > > > multiple times without duplicating rows in other operations. I'm
> not
> > > > > sure if b) is possible without losing the benefit of yield return
> > > > > flowing through all the operations, that's why I was curious to see
> > > > > how you solved it.
> >
> > > > > On Feb 21, 8:40 am, Simone Busoli <simone.bus...@gmail.com> wrote:
> > > > > > Sure, any feedback is welcome, I'm not sure that what I choose to
> do
> > > is
> > > > > the
> > > > > > best solution. I simply decorated the enumerable so that it
> cannot be
> > > > > > iterated more than once. But if you try to do so, it simply
> doesn't
> > > > > return
> > > > > > anything.
> >
> > > > > > On Sat, Feb 21, 2009 at 15:21, pb648174 <goo...@webpaul.net>
> wrote:
> >
> > > > > > > Ok, that is interesting then, I'll take a look at the changeset
> and
> > > > > > > see how you did that.
> >
> > > > > > > On Feb 20, 12:41 pm, Simone Busoli <simone.bus...@gmail.com>
> > > wrote:
> > > > > > > > No, the fix didn't change this behavior. The
> > > > > > > SingleThreadedPipelineExecuter
> > > > > > > > is still pulling, while the multi threaded is pushing.
> >
> > > > > > > > On Fri, Feb 20, 2009 at 2:15 PM, pb648174 <
> goo...@webpaul.net>
> > > > > wrote:
> >
> > > > > > > > > The other strange bit of IEnumerable behavior is that if
> you
> > > don't
> > > > > > > > > iterate the rows passed in the Execute method to an
> operation,
> > > the
> > > > > > > > > previous operations won't execute. This makes sense once
> you
> > > think
> > > > > > > > > about how IEnumerable works, but from the context of making
> an
> > > > > > > > > operation that does something not involving rows (as
> perhaps
> > > the
> > > > > last
> > > > > > > > > operation to send an email or something) you can get some
> > > > > unexpected
> > > > > > > > > results. I made a ProcessAndIgnoreAllInput(rows) {
> foreach(var
> > > row
> > > > > in
> > > > > > > > > rows); } to get around this but maybe now I can get rid of
> it.
> >
> > > > > > > > > If you solved this problem by iterating the list no matter
> what
> > > and
> > > > > > > > > making a copy I think you will have also fixed the above
> > > scenario,
> > > > > > > > > just thought I would mention it.
> >
> > > > > > > > > On Feb 18, 7:30 pm, Simone Busoli <simone.bus...@gmail.com
> >
> > > wrote:
> > > > > > > > > > Fixed in revision 2044.
> >
> > > > > > > > > > On Mon, Feb 9, 2009 at 9:27 AM, Ayende Rahien <
> > > aye...@ayende.com
> >
> > > > > > > wrote:
> > > > > > > > > > > +1
> >
> > > > > > > > > > > On Mon, Feb 9, 2009 at 10:22 AM, Simone Busoli <
> > > > > > > > > simone.bus...@gmail.com>wrote:
> >
> > > > > > > > > > >> If everyone's ok with it I can change the single
> threaded
> > > > > executer
> > > > > > > to
> > > > > > > > > > >> avoid iterating the rows twice.
> >
> > > > > > > > > > >> On Thu, Feb 5, 2009 at 9:19 AM, webpaul <
> > > goo...@webpaul.net>
> > > > > > > wrote:
> >
> > > > > > > > > > >>> No, I can't see why anyone would want that behavior,
> it
> > > can
> > > > > lead
> > > > > > > to
> > > > > > > > > > >>> some unexpected results. If anything I would think
> the
> > > single
> > > > > > > > > threaded
> > > > > > > > > > >>> should be made to behave like the multi threaded one.
> I
> > > think
> > > > > if
> > > > > > > > > there
> > > > > > > > > > >>> was some reason for that behavior then an option
> > > defaulted to
> > > > > off
> > > > > > > > > > >>> would be best.
> >
> > > > > > > > > > >>> On Feb 4, 11:21 am, Simone Busoli <
> > > simone.bus...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > >>> > Yes, that sounds reasonable. Do you think it would
> be
> > > > > useful to
> > > > > > > > > enhance
> > > > > > > > > > >>> the
> > > > > > > > > > >>> > threaded pipeline executer to make it iterable
> multiple
> > > > > times?
> >
> > > > > > > > > > >>> > On Wed, Feb 4, 2009 at 3:39 PM, webpaul <
> > > > > goo...@webpaul.net>
> > > > > > > > > wrote:
> > > > > > > > > > >>> > > When I need to do anything like that I just
> > > > > > > > > > >>> > > first convert to a List<Row> rowList = new
> > > > > List<Row>(rows);
> > > > > > > which
> > > > > > > > > > >>> > > safely interates it once and then I don't need to
> > > worry
> > > > > about
> > > > > > > > > it.-
> > > > > > > > > > >>> Hide quoted text -
> >
> > > > > > > > > > >>> > - Show quoted text -- Hide quoted text -
> >
> > > > > > > > > > - Show quoted text -- Hide quoted text -
> >
> > > > > > > > - Show quoted text -- Hide quoted text -
> >
> > > > > > - Show quoted text -- Hide quoted text -
> >
> > > > - Show quoted text -- Hide quoted text -
> >
> > - Show quoted text -
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino Tools Dev" group.
To post to this group, send email to rhino-tools-dev@googlegroups.com
To unsubscribe from this group, send email to
rhino-tools-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rhino-tools-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
