Re: LWP::Simple gone with 5.8.6?

At 12:24 PM -0500 12/12/05, Nelson, Randy wrote: > >Perl 5.8.4 seemed to have LWP::Simple built in. When I upgraded to 5.8.6 I >noticed that LWP::Simple has vanished. Is there a technical reason for this? >Will LWP work with 5.8.6? I think Peter has it right. If you got my pre-built 5.8.4 k

Re: patch@26310 - Major step for > 256 char paths on VMS

At 3:23 PM -0600 12/9/05, Craig A. Berry wrote: >At 2:08 PM -0500 12/9/05, John E. Malmberg wrote: >>Somewhat of a shakeup to the code to remove most of the dependencies on >>expecting file specifications to be limited to 256 characters. >> >>Most references to the nam$ or naml$ structures have bee

Re: patch@26310 - Major step for > 256 char paths on VMS

Craig A. Berry wrote: Since applying this patch, Perl builds up to the point where it tries to run the Makefile.PL for the first extension, at which point it rapidly consumes all available stack space (after apparently writing a complete descrip.mms). This is with a thread-enabled build. Obviou

Re: patch@26310 - Major step for > 256 char paths on VMS

At 4:46 PM -0500 12/13/05, John E. Malmberg wrote: >>Obviously we are so far not having the desired effect of reducing >>stack space usage. > >Obviously I have an error somewhere. I do see one example of allocating a long filename on the stack: $ SEARCH/EXACT vms.c "tmp[VMS_MAXRSS" char *dirend

Re: patch@26310 - Major step for > 256 char paths on VMS

Craig A. Berry wrote: At 4:46 PM -0500 12/13/05, John E. Malmberg wrote: Obviously we are so far not having the desired effect of reducing stack space usage. Obviously I have an error somewhere. I do see one example of allocating a long filename on the stack: $ SEARCH/EXACT vms.c "tmp[VMS

bug@26347 embed.fnc/embed.h with unlnk macro

embed.h is ending up with a bad definition of unlnk() when UNLINK_ALL_VERSIONS is defined which is causing a compile error on VMS when a threaded perl is being built. It is not happening when non-threaded perls are being built. -John [EMAIL PROTECTED] Personal Opinion Only

Re: Perforce strangeness (was Re: funny directory names in Pod::Simple)

Nicholas Clark wrote: Change 26340 (from Steve_P) renamed all of the files inside these directories, There still is a problem because of the directories with the same names but different case are now present and merged into one on VMS. The command: $MMK realclean deletes [.lib.pod]*.pod;*

Re: patch@26310 - Major step for > 256 char paths on VMS

At 10:08 PM -0500 12/13/05, John E. Malmberg wrote: >By the way, what options are you passing to the CONFIGURE.COM? > >I enabled threads, but not upcalls. > $ @configure -"Dusedevel" -"Dusevmsdebug" -"Duseithreads" -"des" -- Craig A. Berry mailto:[EMAIL

Re: patch@26310 - Major step for > 256 char paths on VMS

Craig A. Berry wrote: $ @configure -"Dusedevel" -"Dusevmsdebug" -"Duseithreads" -"des" Ok, I will try again. I just completed a build with: $ @configure -"Duselargefiles" "-Dcf_email=SYSTEM" "-Dusevmsdebug" "-Dusethreads" "-de" No problems with the build once I removed the "-Dunlink_all_v

Re: patch@26310 - Major step for > 256 char paths on VMS

John E. Malmberg wrote: I just completed a build with: $ @configure -"Duselargefiles" "-Dcf_email=SYSTEM" "-Dusevmsdebug" "-Dusethreads" "-de" No problems with the build once I removed the "-Dunlink_all_versions" Correction, doing the MMK REALCLEAN is resulting in miniperl generating all

Re: Perforce strangeness (was Re: funny directory names in Pod::Simple)

On 12/14/05, John E. Malmberg <[EMAIL PROTECTED]> wrote: > There still is a problem because of the directories with the same names > but different case are now present and merged into one on VMS. > > The command: > > $MMK realclean > > deletes [.lib.pod]*.pod;* > > This removes [.lib.Pod]Simple.pod