This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3


On 25 Mar 2003, Robert Collins wrote:

> On Tue, 2003-03-25 at 11:00, Igor Pechtchanski wrote:
>
> > > 3) reused in RunFindVisitor.
> >
> > No.  In fact, the code currently in RunFindVisitor is broken and will not
> > work if there are subdirectories under /etc/postinstall.  What I would
> > like to do (in a separate patch) is change FindVisitor so that basePath is
> > the POSIX path, rather than the Windows one.  We can then simply
> > concatenate the filename to it and use that.
>
> Ok. There aren't allowed to directories under /etc/postinstall BTW.

IMO it's much neater to just be able to use the basePath.  I don't think
basePath is even used now.  This would make the Find/FindVisitor more
generic.

> > > run_package_scripts cries our for a helper class IMO.
> > >
> > > i.e. ScriptRunner with
> > > a) constructor
> > > b) destructor
> > > c) run(std::vector<Script> const &) method.
> > > d) operator () (Script const &aScript) method.
> >
> > I don't see the benefit of run(); it'll be subsumed by operator(), IMO.
> > Otherwise, I'll give it a shot.
>
> well, you'll have one instance of ScriptRunner for both the dependency
> order package scripts, and the found-by-filename scripts. If you have
> pre-running-a-vector or post-running-a-vector code, then that belongs in
> run(). If that code goes into the constructor, then sure, eliminate
> run().

Yep, I think the pre-post vector code could go into the
constructor/destructor.

> > > this:
> > > for (std::vector<Script>::iterator script = scripts.begin();
> > > +       script != scripts.end();
> > > +       ++script)
> > >
> > > then becomes
> > > *this = for_each (scripts.begin(), scripts.end(), *this);
> >
> > We could probably just lose the return value...
>
> Check the template, IIRC it takes a copy of the object, calls the copy's
> operator (), then returns a copy of the copy.
> i.e. if we want failure stats, script run counts etc, we need the return
> value.
> Rob

Yes, but we don't keep failure stats.  If we ever decide to, we can easily
capture the return value later.  I'm pretty sure we can ignore it for now.

Thanks for the feedback.  I'll send the next iteration soon.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha at cs dot nyu dot edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor at watson dot ibm dot com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk!
  -- /usr/games/fortune


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]