This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
- From: Igor Pechtchanski <pechtcha at cs dot nyu dot edu>
- To: Robert Collins <rbcollins at cygwin dot com>
- Cc: cygwin-apps at cygwin dot com
- Date: Mon, 24 Mar 2003 19:28:52 -0500 (EST)
- Subject: Re: [PATCH] Run postinstall scripts in a thread with progress bars - take 3
- Reply-to: cygwin-apps at cygwin dot com
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
> > > 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
Yep, I think the pre-post vector code could go into the
> > > 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
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.
|\ _,,,---,,_ 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!