David Cantrell wrote:
The practice of bundling third-party modules with yours is IMO very
wrong indeed. If I bundle (eg) Test::Frobnitz, and a hundred other
people bundle Test::Frobnitz, then this leads to two problems:
Agreed. See the earlier advice about the inc/ directory so you can
bundle,
Adam Turoff wrote:
>
> On Wed, Sep 13, 2000 at 09:59:09PM -0400, Barrie Slaymaker wrote:
> > Adam Turoff wrote:
> > > > Feedback welcome.
> > >
> > > I noticed that CVS reports this as part of the version logs:
> > >
> > > date: 200
Adam Turoff wrote:
>
> > Feedback welcome.
>
> I noticed that CVS reports this as part of the version logs:
>
> date: 2000/09/13 05:49:30; author: cvs; state: Exp; lines: +19 -19
Yup: not sure how to orchestrate logging in to the server as different usernames,
or su'ing to be different user
I wrote:
>
> Nick Ing-Simmons wrote:
> >
> >
> > I see no reason why the perforce changes cannot be 'checked in' to CVS
> > one-by-one so that CVS builds its own representation of the change history.
>
> I've got this working now in a program called 'vcp', I need to test
> p4->cvs updates using
Nick Ing-Simmons wrote:
>
>
> I see no reason why the perforce changes cannot be 'checked in' to CVS
> one-by-one so that CVS builds its own representation of the change history.
I've got this working now in a program called 'vcp', I need to test
p4->cvs updates using the perl5 repository next
[perl6-annonce list snipped from Cc:, didn't even notice it the first time]
"Brust, Corwin" wrote:
>
> Let me see If I have it...
>
> try {...} is synonmous with eval {...} which is syntatic sugar for { ... }
Hmmm, I think I'd put it this way: if there's a catch or cleanup statement
(however t
[EMAIL PROTECTED] wrote:
>
> It basically allows the programmer to "try" a certain action and see what the
> effects are going to be (i.e. handle the exception) so that some action can
> then be taken based on the results of the exception.
Seems like any BLOCK could be an implicit eval {...} or
