At 9:25 PM +0000 3/17/03, Doc.Cypher wrote: > ><[EMAIL PROTECTED]>: >>This mailinglist does not accept postings crossposted to newsgroups - >>Contact [EMAIL PROTECTED] for help > >I just checked for new mail and received the above after sending a response >which was again posted to c.o.v and VMS Perl.
I was under the impression that all the Perl newsgroups were read-only and the mailing lists required a subscription to post. I've never given it much thought, though. >My apologies, I was unaware of this restriction. Would it be possible to >permit crossposts to VMS Perl and comp.os.vms? Most VMS people will check >the newsgroup archive first when seeking information. Well, we could write to the list owner and ask him, but I can't think of when this has ever come up before in five years of following both groups. I've got a fix in progress and I'll be sure to post it to c.o.v as well. I need to apply the C RTL patch to my hobbyist system first, so stand by. >Anyway, for those who don't follow comp.os.vms, here is what I posted there >(and will have been rejected by the mailing list)... > > >On Mon, 17 Mar 2003, Charlie McCutcheon <[EMAIL PROTECTED]> >wrote: > >>As other posters noted, there is a new function poll() in the C Run-Time. >> >>From the release notes, which we suggest all customers read: >> >> o The new socket routine poll() is provided with this kit. Hmm. This statement did not make it into the release notes for the 7.3-1 version of the kit, which I'm guessing will also provide the function. I'll have to give that a try. > ><snip> > >>All changes on the kit were asked for by active users requiring them >>before a next OpenVMS release. > >I don't have a problem with that, my users can still perform basic Perl >stuff. As a Hobbyist system that I give out accounts on people should >expect to see some bleeding edge issues. > >On Mon, 17 Mar 2003, Craig A Berry wrote (on the VMS Perl mailing list): > >>Perl needs to be made to work with as many C RTL versions as >>possible, so it's looking like we'll need to add a test for poll(). >>Thanks, Doc. This is precisely the reason that I wanted more >>widespread testing. The weird thing is that I didn't think we had a >>poll() override, but there must be one in there somewhere that's >>causing the conflict. > >I hit the same problem with 5.8.0 following this ECO application. It >probably impacts the 5.6.0 and 5.6.1 build too. Yes, the poll() replacement has been there for ages in the IO extension, so I expect it will collide with the new system-supplied one on any version of Perl. >Patches is actually something I had a problem with for Perl 5.8.0. I found >two patches via the VMS Perl mailing list archive, but had problems >applying them that led me to believe I was missing other patches. Your best bet is to post specific problems when you encounter them. In some cases it's quite kosher to apply later patches but not earlier ones, but it's also possible to get in trouble when various things have diverged, things that may or may not be relevant to the particular problem you are trying to solve by applying the patch. There is no formal dependency tracking and there is definitely nothing like an installation rating. >This leads on to a few questions I've not found a clear answer on... > >Where precisely can I obtain patches for Perl and now do I identify those >I should apply (VMS specific, or generally required)? There are a variety of ways to stay up to date, the most authoritative being to use rsync, which unfortunately, as far as I know, is not available for VMS. This is covered in the perlhack documentation at <http://www.perldoc.com/perl5.8.0/pod/perlhack.html#Keeping-in-sync> (or via "perldoc perlhack" on a system with Perl installed). There are a number of ways to track what's going on via the Perl Repository Browser at <http://public.activestate.com/cgi-bin/perlbrowse>. There is no general answer to your question that covers both the development stream and the maintenance stream of Perl development. A "patch" could equally well be an experimental warp field generator that will probably blow up your system or what we VMSers would call an ECO. Patches usually get applied to the development stream first and then, if they don't seem to introduce new problems and are considered to be bug fixes rather than new features, they get rolled back to one or more previous maintenance streams. > >What is the syntax to use with GNU patch on VMS Generally the same as it is on any other OS. >assuming I have the >following setup on DISK$PERL > >[5_8_0] Build directory created from tarball downloaded off > CPAN. > >[5_8_0_ROOT] The [000000] directory for PERL_ROOT. > >[5_8_0_PATCHES] Where I download patches to. $ set default disk$perl:[5_8_0] $ gpatch --dry-run -p0 -i [5_8_0_patches]foo.patch If all goes well, remove the --dry-run flag and repeat. The -p0 may or may not be right for any given patch; it's the number of "prefix" levels to remove from the directory specifications. If the directories in the patch look like "+++ [EMAIL PROTECTED]/ext/Foo/foo.t" then you'd need -p1 to remove the "[EMAIL PROTECTED]" prefix if you are applying the patch from the top-level build directory. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
