From: Philip Newton Date: 11:16 on 26 May 2005 Subject: Don't install a different version than you promised! I wanted to install dbish, the DBI shell, on a Windows machine. One `ppm install DBI-Shell` later and I had a dbish. Yay! It also downloaded and installed some prerequisites, such as Test::Simple and Text::Reform v1.11. Or so I thought. The next time I started ppm, ten minutes later, it bombed with: "break_at" is not exported by the Text::Reform module Can't continue after import errors at C:/Programme/ActivePerl/site/lib/Text/Reform.pm line 43 BEGIN failed--compilation aborted at C:/Programme/ActivePerl/site/lib/Text/Autoformat.pm line 9. Compilation failed in require at C:\Programme\ActivePerl\bin\ppm3-bin line = 12. BEGIN failed--compilation aborted at C:\Programme\ActivePerl\bin\ppm3-bin line 12. Looking in Text/Reform.pm, it appears that this is version 1.10 -- not 1.11! Even though ppm thinks it's version 1.11. And downloading Reform.pm v1.11 shows that it's a week older than the v1.10 that was installed by ppm. WTF? Hateful. --=20 Philip Newton <philip.newton@xxxxx.xxx>
From: peter (Peter da Silva) Date: 14:03 on 26 May 2005 Subject: Re: Don't install a different version than you promised! Dependencies must be identified, and where possible eliminated. -- Motto of Microsoft's Excel developers, the only group in the company to routinely meet deadlines.
From: Simon Wistow Date: 14:40 on 26 May 2005 Subject: Re: Don't install a different version than you promised! On Thu, May 26, 2005 at 08:03:07AM -0500, Peter da Silva said: > Dependencies must be identified, and where possible eliminated. These were the people who also wrote their own compiler. "In defense of not invented here" http://www.joelonsoftware.com/articles/fog0000000007.html Which is interesting especially since Mr Spolsky seems to have completely reversed his opinions on "Microsoft can do no wrong, they're just misunderstood ... by the way I wrote macros for Excel". As an aside - releatively recently I've heard more than a few people (both here and in other forums) complain that dependencies (and hence shared libraries) are a bad idea, especially if they don't control them. I'm always intrigued to hear whether they advocate static libraries, or just not-invented-here or whether they have a new, entirely shiny and different way of doing things.
From: peter (Peter da Silva) Date: 15:16 on 26 May 2005 Subject: Re: Don't install a different version than you promised! > As an aside - releatively recently Decades. > I've heard more than a few people > (both here and in other forums) complain that dependencies (and hence > shared libraries) Shared libraries are implementation, not design. Back in 1979 I was working with some other guys at Berkeley trying to run some software that came out of the Tufts software distribution. We couldn't get it working without a bunch of work because they included some of it as object files that you had to link in, and THOSE files depended on some custom system calls they'd put into PDP-11 UNIX. Not a "shared library" in sight. > are a bad idea, Well, not "are", but "can easily become". Especially if they're not identified. I've spent six week shaking down and integrating the dependencies in one package on Red Hat, and even when I decided to just duplicate the existing system it took two more weeks to put together an install script that actually worked on a virgin Red Hat system. > especially if they don't control them. If you control them, you're not dependent on them. The Excel compiler was not a dependency for the Excel team, even if it was a dependency for the Excel code. > I'm always intrigued to hear whether they advocate static libraries, or > just not-invented-here or whether they have a new, entirely shiny and > different way of doing things. I advocate IDENTIFYING dependencies and, WHERE POSSIBLE, eliminating them. That doesn't mean "don't use anything anyone else wrote", it means "write robustly portable code". One way of looking at portability is that portability is all about identifying dependencies and eliminating them. You isolate non-portable code behind wrappers, you #ifdef or otherwise selectiveley reference code or other objects you _may_not_be_able_to_depend_on_ being there, you provide hooks for extensions but you don't break if they're not used, you provide stubs or workarounds for missing functionality, and when you get new tools you leave the old mechanism as a fallback... at least until you _can_depend_on_ being able to use the new one everywhere.
From: Michael G Schwern Date: 21:27 on 26 May 2005 Subject: Re: Don't install a different version than you promised! On Thu, May 26, 2005 at 12:16:03PM +0200, Philip Newton wrote: > The next time I started ppm, ten minutes later, it bombed with: > > "break_at" is not exported by the Text::Reform module > Can't continue after import errors at > C:/Programme/ActivePerl/site/lib/Text/Reform.pm line 43 > BEGIN failed--compilation aborted at > C:/Programme/ActivePerl/site/lib/Text/Autoformat.pm line 9. > Compilation failed in require at C:\Programme\ActivePerl\bin\ppm3-bin line 12. > BEGIN failed--compilation aborted at > C:\Programme\ActivePerl\bin\ppm3-bin line 12. > > Looking in Text/Reform.pm, it appears that this is version 1.10 -- not > 1.11! Even though ppm thinks it's version 1.11. > > And downloading Reform.pm v1.11 shows that it's a week older than the > v1.10 that was installed by ppm. WTF? I'm going to suspect that you are the victim of "shadowing". At some point you installed Text::Reform 1.10 from CPAN and it went into the "site" library directory. The PPM (rightfully) installed into the "vendor" library directory. Perl almost always looks at "site" before "vendor" when trying to load modules, and rightly so because whatever you install locally should take priority over the vendor's stuff... the assumption being that you've decided to take over maintenance of Perl from your vendor. Do a find and you'll probably find a second Text\Reform.pm. The hate here is that you have to do this sort of thing rather often, replacing one bit of normally packaged software, and things like this happen. Perl doesn't do a very good job of it. Debian does ok.
From: Philip Newton Date: 07:44 on 27 May 2005 Subject: Re: Don't install a different version than you promised! On 5/26/05, Michael G Schwern <schwern@xxxxx.xxx> wrote: > I'm going to suspect that you are the victim of "shadowing". At some poi= nt > you installed Text::Reform 1.10 from CPAN and it went into the "site" > library directory. The PPM (rightfully) installed into the "vendor" > library directory. I thought the output of ppm had said it was installing in ...\site\lib. Hm. *looks* Nope, only one file named 'Reform.pm' under my ActivePerl directory, in the ...\site\lib\Text directory. And I don't seem to have a 'vendor' directory tree at all. --=20 Philip Newton <philip.newton@xxxxx.xxx>
From: Michael G Schwern Date: 20:29 on 27 May 2005 Subject: Re: Don't install a different version than you promised! On Fri, May 27, 2005 at 08:44:13AM +0200, Philip Newton wrote: > Nope, only one file named 'Reform.pm' under my ActivePerl directory, > in the ...\site\lib\Text directory. > > And I don't seem to have a 'vendor' directory tree at all. Ok, ActiveState is doing it completely wrong then. My mistake, continue hating.
Generated at 17:45 on 21 Sep 2006 by mariachi