Re: Piping code status?

Craig A. Berry wrote: > I haven't found time to really stress test it, just build, install, and build a >couple of extensions against it. Charles B. did say here on 4/18: "Once I've got >stuff sorted out, I'll fold patches into the archive so they'll be in line for future >relea > s." That i

Re: Perl 5.6.0 install errors

Craig A. Berry wrote: > Hmm. Here's the relevant snippet from descrip.mms: > > # install ought not need a source, but it doesn't work if one's not > # there. Go figure... > install : $(MINIPERL_EXE) > @ @perl_setup.com > If F$TrnLnm("Sys") .nes. "" Then Deass SYS > $(MIN

Re: Perl 5.6.0 install errors

> >The install went without errors, but ended with: > >%MMK-I-ACTNOUPD, action did not update target INSTALL > > I saw this too. I have a feeling there is no tangible thing (file > system object) MMS/K can check to see if the INSTALL target is > up-to-date. Thus it's probably just telling y

Re: Perl 5.6.0 install errors

Ed James wrote: > > > > I had to install the patch via edit. Something's wrong with my patch.exe. > > > Unfortunately you'll have to reconfigure and rebuild since the patch > > modifies subconfigure.com. Let us know wheth

Re: Patch for DBD::ODBC 0.28 Makefile.PL

Martin J. Evans wrote: > Thanks for that Craig. I checked on our Tru64 box and it reports "cc" but > I take the point. I have mailed Jeff the change just in case. I've only seen T64 report 'cc' or 'gcc' but I think Craig's suggestion of using a $^O guard was a prudent coding suggestion. Peter

Re: Perl 5.6.0 "Build VMS-Debug version: Y"

Ed James wrote: > Ok, I did the compile, test, and install in the same tree. Won't backup > put all the objects, etc., into the new production tree? I thought the > install would only move the executables, etc., making the production > tree shorter? Not if the build and install trees are the sam

Re: Perl 5.6.0 "Build VMS-Debug version: Y"

Dan Sugalski wrote: > >Exactly our current problem decision. We are installing new bigger > >disks shortly, so I'm going to test with perl_root in my tree, and > >when we get the new drives installed, change descrip.mms and install > >on a production disk. > > If you did an MMS INSTALL into your

Re: Perl 5.6.0 "Build VMS-Debug version: Y"

Ed James wrote: > > that is, is PERL_ROOT defined to be where you want to place perl? > > It will default to BEAST$DRA4:[JAMESE.PERL-5_6_0.] but you may > > want to DEFINE it to point elsewhere. > > Exactly our current problem decision. We are installing new bigger > disks shortly, so I'm going

Re: Configure wants?

Dan Sugalski wrote: > That's so, but I was thinking something a bit more manual than using > build_perl.com. Basically take the Magic Config File from some build (or > roll it yourself) and the appropriate symbols and build a new version of perl. OK That's the idea behond config.com and Policy

Re: Configure wants?

tatus .eq. 1> ought to work OK too - except for the fact that I don't think a failure propagates out of MMK or MMS at this time: [.pragma]warnings...FAILED on test 216 Failed 3/221 tests, 94.57% okay. u=17.18 s=0 cu=0 cs=0 files=212 tests=9419 11-MAY-2000

RE: Perl 5.6.0 "Build VMS-Debug version: Y"

Ed James wrote: > I have been working on getting 5.6.0, using the information on Chuck Lane's > web page at http://www.crinoid.com/perl560.htmlx. I answered configure.com > questions with defaults except: > > Configuration: > > Build VMS-Debug version: Y > Always use default file types

RE: [PATCH] File::Basename and t/pod/...

Charles Lane wrote: > I ran across this problem when I had to use a rooted directory [snip] > Patch follows... > > diff -uBb lib/File/Basename.pm-orig lib/File/Basename.pm > --- lib/File/Basename.pm-orig Wed May 10 09:47:58 2000 > +++ lib/File/Basename.pm Wed May 10 09:55:12 2000 > @@ -1

Re: Configure wants?

Charles Lane wrote: > I'd like to see CONFIGURE.COM build a COM file that contains the > commands needed to build/test/install/tidy/clean Perl. > > You should be able to just "submit" the com file with appropriate > parameters. > > Something like: > > BUILD_PERL.COM: >

RE: Should I expect crypt to produce usable results?

Martin Vorlaender wrote: > Dan Sugalski <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] wrote: > > > What would be involved in providing a Unix-compatible crypt() > > > function? > > > > Snagging the source for crypt and making it available to perl. > > You could do it entirely in perl, I'm sur

RE: Configure wants?

Dan Sugalski wrote: > We probably ought to put a check in immediately after we've chosen the > compiler to make sure it works. That'll pick up all manner of > install/config issues. I too was thinking along those lines. > Yeah, but the help text only went in as of 5.6.0. (Just checked my 5.00

RE: Configure wants?

Dan Sugalski wrote: > That works. I'm uncertain whether we should go and skip compiler tests too, > if the C compiler and OS versions are the same. Probably not, since a > different C RTL version will change things. I would say not to skip compiler checks. In fact one recent bug I found was o

RE: Configure wants?

Dan Sugalski wrote: > I'm going to be messing about in perl's guts again next week. The big VMS > things I'm planning on are getting the non-compiling things compiling on > VMS (perl's malloc, Ithreads, a MULTIPLICITY build) and making > configure.com take and save defaults, with symbol overri

[PATCH 5.6.0]yet another little tweak to subconfigure.com

Enclosed please find a small addition to vms/subconfigure.com that turns this: $ perl "-V:make" make='UNKNOWN'; into this: $ perl "-V:make" make='MMS'; The make utility on vms may be known by two different names, neither of which is make. (In the old days we supported GNU make as well bu

Re: Perl 5.6.0 and DBI/DBD module problems

Martin J. Evans wrote: > I hope people on this list do not think this discussion is inappropriate for > the vmsperl list. If so, please let me know. I had thought of using one of the > DBI lists but there seems to be fewer VMS people subscribed to those lists - > possibly because the traffic is s

RE: [PATCH] Perl w/ VMS debugger enhancements

Charles Lane wrote: > Cosmic; but the but the event times are taken from an atomic clock slaved to > an external GPS receiver. The only problem is that the atomic clock > says "9 May 1900" since it's i/o hardware only has 2 BCD digits for the > year :) Now _that_ is funny :-) > > Watch out for

RE: MakeMaker 'all' target (was Re: Perl 5.6.0 and DBI/DBD module problems)

Craig A. Berry wrote: > I believe what is causing this problem (and it's always been this way for > DBI) is that Unix make utilities search for the 'all' target and build that > first if no target is explicitly specified, whereas MMK and MMS build > whatever target they encounter first in desc

RE: [PATCH] Perl w/ VMS debugger enhancements

Charles Lane wrote: > Peter Prymmer wrote: > > Charles Lane wrote: > >> BTW, I'm seeing failures of the vmsish test #17 that might be due to being > >> east of greenwich. This'll be a good opportunity to debug 'em. > > > I am curious: Are you at CERN or DESY now? What is your > > SYS$TIMEZONE_

Re: Perl 5.6.0 and DBI/DBD module problems

Martin J. Evans wrote: > Craig, > > Thanks for replying. I have managed to get a little further now. I think DBI is > installed but I am trying to install DBD::ODBC with my driver to check it out > and am having even more problems. For DBI I found: > > [1] For some strange reason the generated

RE: [PATCH] Perl w/ VMS debugger enhancements

Charles Lane wrote: > BTW, I'm seeing failures of the vmsish test #17 that might be due to being > east of greenwich. This'll be a good opportunity to debug 'em. I am curious: Are you at CERN or DESY now? What is your SYS$TIMEZONE_DIFFERENTIAL? Peter Prymmer

[DOC PATCH: 5.6.0]VMS specific additions to perlrun.pod

--official perlrun.pod > /tmp/pvh p/man/man1/perlrun.tmp ln /tmp/pvhp/man/man1/perlrun.tmp /tmp/pvhp/man/man1/perlrun.1 unlink /tmp/pvhp/man/man1/perlrun.tmp (although isn't pod2man now using the non-complaining Pod::Parser?) at any rate, here is the addition to perlrun.pod:

[PATCH: 5.6.0]work around broken chdir() in VMS C rtl - by Charles Lane

In message <[EMAIL PROTECTED]> in the vmsperl web archive at: http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2000-04/msg00127.html Charles Lane wrote: > I'm using DECC 5.5-003 on an Alpha and also have the "trailing > slash" problem. So rather than version/architecture testing, I suggest

RE: perl and flock

Dan Sugalski wrote: > I just got the neatest surprise. > > As of perl 5.005 with some versions of the Dec C RTL (certainly the one I'm > running on my 7.2 clusters) the perl flock() call works. > > Time to mark off one more "doesn't work on VMS" function... Cool. BTW Dan I was poking around

Re: Should I expect crypt to produce usable results?

David Morriss wrote: > That makes sense. I assume that the intention was to provide an interface > similar to $HASH_PASSWORD from Perl? If I were writing code just to > interact with OpenVMS passwords I'd appreciate the decision :) Yes the intention was to provide access to sys$hash_password - a

Re: Should I expect crypt to produce usable results?

Richard Levitte - VMS Whacker wrote: >Try: > > http://www.openssh.org/ > >for further information. > > Uhmmm? Funny, I had the impression I was hacking on OpenSSL, but then > again, I've been mistaken before... > > Sorry, I couldn't resist it :-) Err - oops. Peter Prymmer

Re: Should I expect crypt to produce usable results?

I wrote: > For network verification things such as kerberos are a bit more robust. > Kerberos services for VMS are available as part of the Multinet TCP/IP > product e.g. And I completely neglected to mention Richard Levitte's fine work on OpenSSH! Try: http://www.openssh.org/ for further

RE: Should I expect crypt to produce usable results?

[EMAIL PROTECTED] wrote: > Hi, > > I'm trying to develop a tool for synchronising a remote OpenLDAP directory, > using Net::LDAP, from data held on an OpenVMS system, using Perl. Along the > way, as I create a new LDAP object I want to add a default Unix-style > password to the "userPassword" at

RE: Any interest in porting emacs 20.x to OpenVMS v7.x

Jordan Henderson wrote: > Anyway, my research has given me the following options: > > Emacs (and support an effort to get it more current on OpenVMS). > > VILE To add a couple of alternatives into your mix: Boston Business Computing has a VMS editor emulator that ru

RE: Any interest in porting emacs 20.x to OpenVMS v7.x

Richard Levitte wrote: > Anyhow, life went on, and I simply didn't get the time to take up > autoconf and concentrate on it, the rest followed by implication. > > So, why am I writing this? Well, I recently got reasons to start mucking > around seriously with emacs again, perhaps with a slightl

RE: Has anyone used Net::Telnet on VMS?

Mark Temple wrote: > I have Multinet, and a need to communicate with other local hosts. Has > anyone used Net::Telnet in the VMS context? Perl version 5.005_03. Does > 'perl Makefile.PL' work on VMS for installs? I've done installs in Linux, > but not in VMS. Thanks in advance for any help.

RE: Compilation tweaks for 5.6.0

Dan Sugalski wrote: > Dunno how many folks have machines with the newer toys in them, but I just > ran perlbench against 5.6.0. It turns out that if you specify an > /ARCH=HOST, and compile on an EV6 system, perl gets an overall boost of > about 5% over a plain build. Some of the tests show a

Chris's new web site (slashperl?)

Hi, Chris Nandor (who now works for Andover.net I think) has a new slashdot style perl web discussion forum at: http://use.perl.org/ Go forth and have fun there. Peter Prymmer

Re: install problems with 5.6.0

Charles Lane wrote: > > I'm using DECC 5.5-003 on an Alpha and also have the "trailing > slash" problem. So rather than version/architecture testing, I suggest > we just strip 'em all and not worry about it further. > > Patch follows: > > > --- iperlsys.h-orig Fri Apr 21 07:39:46 2000 > ++

RE: 5.6.0 install problems part 2

> From: SMTP%"[EMAIL PROTECTED]" 20-APR-2000 17:48:19.51 > To: PVHP > CC: > Subj: RE: 5.6.0 install problems part 2 > > Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Precedence: bulk > list-help: <mailto:[EMAIL PROTECTED]> > list-unsubscr

RE: 5.6.0 install problems part 2

Craig A. Berry wrote: > I've discovered three problems with installperl as it ships with > 5.6.0. I don't have a patch yet because I don't have the whole > shebang working yet. > > 1). The Config variable 'version' is documented in Config.pm but it > does not exist in my build. This was fro

RE: Trouble compiling 5.6.0 on axp vms

William Atkinson wrote: > Yes, it is definitely a conflict in header files. I talked with the vms guy > here and it turns out that we are comitted to keeping them so that we can > generate product versions that look like they came from older vms releases. > > I followed Craig Berry's suggestion

RE: install problems with 5.6.0

Jordan Henderson wrote: > Grrr. I'll try that again (Wordmail is fscking evil!) > > I agree with Charles Lane that we should make > work-arounds for these kinds of things in VMS.C (or elsewhere) > to support all reasonable DECC versions (for reasonable values > of reasonable), but perhaps a

Re: install problems with 5.6.0

Charles Lane wrote: > Peter Prymmer ([EMAIL PROTECTED]) writes: > > BTW I just recently noted that with: > > > DEC C V5.3-006 on OpenVMS VAX V6.2 > > > that perl's chdir("/unix/style/spec/") will not work but that > > chdir("vms:[style.spec]") will. Hence File::Find is fubarred. > > (Though th

Re: install problems with 5.6.0

[EMAIL PROTECTED] wrote: > "Craig A. Berry" <[EMAIL PROTECTED]> writes: > > I just tried to do an "mmk install" with 5.6.0 plus Charles Lane's patches > > and mine. The first thing I noticed is that README.VMS is no longer correct > > in saying that you can define PERL_ROOT and then do an instal

RE: VMS::Filespec on Win NT?

Tracy Hughes wrote: > Hi, > I tried to add VMS::Filespec to the installed Win32 perl at my > company (I read a rumour somewhere that this was straightforward...) I posted a patch to the Win32 Makefiles that allowed for installation of File::Spec::VMS.pm on Win32 but that is a module different f

RE: Question about VMS Perl

Greg Wright wrote: > Hi, > > I just downloaded VMSPERL 5.6. The compile went OK but the test revealed > the following errors: > > [.lib]glob-basicFAILED on test 3 > > $ perl glob-basic.t > 1..9 > ok 1 > ok 2 > not ok 3 > # [] > not ok 4 > ok 5 > ok 6 # skipped > ok 7 > not ok 8 > ok 9

RE: MakeMaker problem

Martin Vorlaender wrote: > Thanks, Peter, for the hint. > > As I already wanted to have a look at Perl 5.6, I installed the > CPAN version yesterday. It went fine exceptfor six tests - I'll look > into these over the weekend. Environment is DEC C 5.7-004 and MMK > on VMS/VAX 6.2, configuring the

RE: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > The error-throwing suggested was only in response to a system() or > piped i/o request that couldn't be satisfied because of lacking PERL_ROOT. Ah OK that is a bit different. In general I am wary of the urge to toss more warnings into perl. E.g. I think the C> warning in

RE: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > If you look for VMSPIPE and can't find it at all, what do you do? > You can't run system(), you can't do piped i/o. I'd say that a -F- > is an appropriate response to that kind of failure, maybe a *bit* > on the harsh side. There are plenty of things I can do with perl wit

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > I'm not sure why we're trying to avoid PERL_ROOT during testing; it's > a cause of a lot of the grief we're having now. Perhaps it's some > unix thing, since those poor guys don't have logicals to help them out. > Sort of like programming without pointers, doncha know :) A

RE: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > > When you get right down to it, perl's hosed if it's library's > > dysfunctional, so if folks *do* mess things up we can just tell 'em "Don't > > *do* that!" > >%PERL-F-DOPESLAP, logical PERL_ROOT not found, don't *DO* that! > > I do wonder what kind of weird situatio

RE: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > Look at the problem in general: how do you find a file you need? > > Either (a) relative to logical (PERL_ROOT or some "special" logical) > (b) relative to default directory (-I../lib etc.) > (c) relative to executable ($^X) > > I don't think there are an

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Charles Lane wrote: > Charles Bailey [EMAIL PROTECTED] wrote: > > What would you think of this alternative? > > > 1. Search @INC for file. > > 2. On failure, try dirname($^X). > > 3. Perhaps as last resort, try Perl_Root:[00], though I'm > >not sure this'll add much. > >

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Chuck Lane wrote: > Well, as far as I can tell the *only* place having VMSPIPE.COM in > PERL_ROOT:[00] could *maybe* be an issue is during the Perl > build/test/install. > > But that all occurs in what (should be) a rather well controlled > environment. As has been mentioned, MMK and MMS do

Re: RFC: a small addition to perlrun.pod

Charles Bailey wrote: > > What do folks here think of an addition to perlrun.pod such as this?: > > Looks like a good idea. Would it fit better into perlvms.pod? Thanks. The wording was intended to fit in with the wording of perlrun.pod, in particular the (Win32 port only) type env. var. lis

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Chuck Lane wrote: > I don't think so; checking the DESCRIP.MMS: > > install : $(MINIPERL_EXE) > @ @perl_setup.com > If F$TrnLnm("Sys") .nes. "" Then Deass SYS > $(MINIPERL) installperl > > So even if you play around with definitions of PERL_ROOT earlier, the > execut

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Craig A. Berry wrote: > At 10:23 PM -0500 3/31/00, Charles Lane wrote: > > > >Avoiding dependance on having the logicals set up properly *before* > >invoking "MMK test", sure... but MMK should be able to set up some > >logicals that the build and test code depend on. > > Isn't the problem that i

RE: Re[2]: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

John Peacock wrote: > Peter - > > I cannot say why I had problems with perlshr defined, but as soon as I > deassign'd it, most of the errors went away. The errors (which I helpfully did > not save) referred to problems activating the shared image PERLSHR.EXE. That is a bit unfortunate. I ran

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

Chuck Lane wrote: > A patch for the glob-basic test was posted here on 17 Mar. Apparently it was missed when assembling 5.6.0 unfortunately. > The piping changes depend on PERL_ROOT being defined so that the > DCL wrapper file can be found when spawning subprocesses; in > discussion with Char

RFC: a small addition to perlrun.pod

What do folks here think of an addition to perlrun.pod such as this?: $ gdiff -u [.pod]perlrun.pod;1 [.pod]perlrun.pod --- [.pod]perlrun.pod;1 Mon Mar 13 21:25:37 2000 +++ [.pod]perlrun.pod Thu Mar 30 17:36:57 2000 @@ -809,6 +809,17 @@ this controls the behavior of global destruction of objec

Re: [ID 20000330.044] Not OK: perl v5.6.0 on VMS_AXP V7.1

In <[EMAIL PROTECTED]> John Peacock wrote Thu, 30 Mar 2000: > Overall a clean build under VMS (WOW!!!). If perlshr is already > defined (i.e. an existing installation), there are failures in > [.t.lib]vmsish.t and [.t.pragma]warnings.t (Configure.com should > check for this and suggest that per

Re: Y2K readiness

Tom Christiansen wrote to Dan Sugalski: > >Pity we've seen such a slowdown in recent perls. I'm hoping efficiency > >hacks are high on the list for 5.7/5.8 > > I think the bloat is due to Unicode. I think the speeddowns are > because of Larry not really being so into the release process. He >

Re: Y2K readiness

Tom Christiansen wrote: > >I have perl 1..4 on some CD's somewhere (from www.cdrom.com) I'd be > >willing to recompile them for a price. > > I keep them on my system. That's how I sent those perl1..5 benchmarks > yesterday. It's velly nice to have. Which were velly interesting results. In ma

RE: Extremely non-portable hack required

Ivor Williams wrote: > Hi, > > Any of you know of a way of getting to the raw DCL command line in perl, > before it has been globbed, argv chunked and otherwise mangled? > > I am looking at something which will fake a particular DCL command without > the users or scripts knowing the difference

Re: Y2K readiness

Dan Sugalski wrote: > At 11:23 PM 3/29/00 -0700, [EMAIL PROTECTED] wrote: > >I don't see a message about this in my archive of messages to this list. > > > >Is VMS Perl in some sense Y2K-compliant? If so, was there a particular > >version > >at which that compliance was achieved or which was th

RE: [PATCH] Perl 5.6.0: VMS piping mods

Dan Sugalski wrote to Jordan Henderson: > I kinda want to do that anyway, so as to be able to give memory back to the > system. It'd be cool to be able to do: > >$#foo = 100; >$#foo=3; > > and see memory usage peak then drop again. We could give the Unix folks a > big "Nyah!" :)

RE: [PATCH Perl 5.6.0] zero-length string fixes, MM_VMS.PM fix/enhancements

Charles Lane wrote: > I've been pretty quiet the past week or so...it's mostly been a matter > of giving the piping code a good workout and getting CPAN.pm working > on VMS. > > Here's a patch of some *other* fixes that were generated in the process: > > VMS.C > checks for zero-

RE: MakeMaker problem

Martin Vorlaender wrote: > Hi VMSperlers, > > while trying to install XML::Parser (OpenVMS/VAX 6.2, Perl 5.005_03) > I stumbled over the following bit: > > The Makefile.PL for XML::Parser::Expat specifies > > @expat_files = qw(expat/xmltok/xmltok.c expat/xmltok/xmlrole.c > ex

RE: default file types, DECC 6.0, volume names and all that...

Carl Friedberg wrote: > It may be sufficient (I pray) to use > > $ mount/system xxx user usr My intent was to modify the mount command to $ mount/system dkb100 usr usr and retain the define/system USER rooted logical name. I am fairly confident that noone is using DISK$USER, those that

Re: default file types, DECC 6.0, volume names and all that...

Craig A. Berry wrote: > I don't think it will because in that case he'll never hit the code where >Perl_find_script calls Perl_cando which calls lib$fid_to_name, thus avoiding -- but >not solving -- the problem. Right, Peter? Yes that is correct. Like I mentioned in my earlier reply to Dan I

Re: default file types, DECC 6.0, volume names and all that...

Dan Sugalski wrote: > Well, that's something. But RC3 bombs if you answer N too, doesn't it? Yes it does bomb with a "N" (actually with a "-des" configuration). I intend to remount the disk as volnam USR as soon as an opportunity crops up (folks are too dependent on the USER logical name unfo

RE: Perl_cando(), rooted logicals, and volume labels

Craig A. Berry wrote: > At 4:39 PM -0800 3/21/00, [EMAIL PROTECTED] wrote: > > > >Why wouldn't that stat() returned physical device be OK for SYSCOMMON? > >What problem do you foresee? > > Well, the dev name would be fine, but with this example again: > > $ r fidvoltest > Enter a complete path

default file types, DECC 6.0, volume names and all that...

In a message sent earlier today Dan Sugalski had asked about not accepting the defaults during a configure.com run. Here was an attempt to build with RC3: -- During the configure I specify to accept the default types --

RE: Perl_cando(), rooted logicals, and volume labels

Craig A. Berry wrote: > But what if the redefinition of the volume logical was to another disk, not > to another directory? Or what if the logical has been deassigned entirely > and doesn't exist? Perhaps we can avoid the whole mess by just using the > physical device name returned by stat()

RE: Perl_cando(), rooted logicals, and volume labels

Craig A. Berry wrote: > At 10:22 AM 3/21/00 -0800, [EMAIL PROTECTED] wrote: > >Correction: the DISK$volnam logical was not redefined. > > Agreed, as I pointed out in my last post. A very nice well worded post that I hadn't seen before I sent my reply to Hoff BTW. > >"volnam" was used > >to

RE: Perl_cando(), rooted logicals, and volume labels

Stephen Hoffman wrote: > In addition to the (expected but) bizzare behaviour seen here when > the DISK$ logical names are redefined, PCSI will also get very confused > by this particular redefinition -- if there are any kits installed on > this target disk... > > File Identifiers (FI

RE: shareable image names

Dan Sugalski wrote: >Okay, I just got bit in a *big* way by LIB$FIND_IMAGE_SYMBOL's annoying >tendency to believe logicals over filenames and assumptions that two >shareable images with the same base name are the same bloody image, and I'm >going to fix it once and for all. (Though not for 5.6

Re: Setting Name Space For REQUIRE?

Ed James wrote: > > Now after running `nmake install` I see: > > > > D:\perl-5.6.0-RC2\win32>d:\perl_rc2\5.6.0\bin\mswin32-x86\perl -Mvmsish -e > "print 'hello'" > > This isn't VMS at -e line 0 > > Compilation failed in require. > > BEGIN failed--compilation aborted. > > > > So it didn't w

Re: Setting Name Space For REQUIRE?

Ed James wrote: > Can the lexical scope be changed, say to package or other scope? Yes it can. Here is an example that explicitly sets package scopes: $ type pp.p package foo; $foo = "foo foo"; $bar = "foo bar"; package main; $foo = "main foo"; $bar = "main bar"; print "\$foo is $fo

Re: [PATCH 5.6.0 RC2]VMS patches

Craig A. Berry wrote: > At 03:49 AM 3/15/00 -0500, Dan Sugalski wrote: > >Without these patches. RC2 won't build properly, install, or build modules. > > I have a feeling that the configure.com patch for default file types will > fix Peter's issue with Perl_cando and lib$fid_to_name, although i

Re: Setting Name Space For REQUIRE?

Ed James, wrote: > My question was about non-begin block name spaces, where the "require ..." > evidently uses a separate name space: > > $ type vmsish_test.pl > my $EXIT_SUCCESS; > my $EXIT_BADPARAM; > # BEGIN { > if( $^O eq 'VMS') { > require vmsis

RE: Setting Name Space For REQUIRE?

Ed James, TCS Inc, 410-295-1919, wrote: > Hello, > > I am working on multi-platform Perl scripts for VMS & NT. > > The NT Perl does not have some files, such as vmsish.pl. I have figured out > that I can create a BEGIN block that checks $^O for VMS and does a > "require vmsish.pm; vmsish::impor

RE: RMS$_DNF in cando_by_name()

Carl Friedberg wrote: > Hi Peter > > I have a feeling that USER is one of those logical names that get's us in > trouble. Well there is nothing magic about the choice of the name other than it coincides with a volume label. > We've had a system level concealed logical name of USER since day on

RE: RMS$_DNF in cando_by_name()

Craig A. Berry wrote in repsonse to me: > At 7:19 PM -0800 3/14/2000, [EMAIL PROTECTED] wrote: > > > >Thus lib$fid_to_name() apparently feels compelled to change a perfectly OK > >device name doing s/\Q_SNFRN$DKB100\E/USER/ for some odd reason. The bug is > >Compaq's and I now have to hunt up a

RE: RMS$_DNF in cando_by_name()

Just a quick update: I think that I've found the smoking gun here. Note that with a vms.c that is equipped with the following .+printf()s This is not a patch $ gdiff -u vms.c;1 vms.c --- vms.c;1 Tue Mar 14 15:56:14 2000 +++ vms.c Tue Mar 14 19:02:03 2000 @@ -4549,6 +4549,7 @@ bool Pe

RE: progress report on piping on VMS

Charles Bailey wrote: > | Rhetorical question: If I am on a Mac and want to convert a > | C:\Windows\File\Spec.txt to a C:[VMS.FILE]SPEC.TXT how do I do that with > | File::Spec? Is it even possible? > > It should be possible, though there isn't a nicely packaged way to do > the conversion (t

Re: [PATCH RC1]a bunch of config clean up items (still not prime time)

Dan Sugalski wrote: > Yep. The plan was to make it work like the other platforms--unknown $i_* > and $d_* variables get turned to undef under the assumption that they're > not in use. While your in the process of porting bash to VMS/DCL you might be interested in a place where you could pick

RE: RMS$_DNF in cando_by_name()

;(((Stat_t *)statbufp)->st_ino), &namdsc,&namdsc.dsc$w_length,0,0); in VMS.C Perl_cando(). The problem that I am seeing is that fname turns into "USER:[VMSPERL.VMS]WRITEMAIN.PL;1" which is wrong. This is odd because on this machine my sys$

Re: [PATCH RC1]a bunch of config clean up items (still not prime time)

Dan Sugalski wrote: > >Yes without a doubt there are examples of those already. The algorithm > >that I currently use to uncover suchlike is: > > > > $ search config.h "$" > > > >Although I think that the automatization that Dan has hinted at may do > >something considerably more perlian :-).

Re: vms 6.2-1h3; decc 6.2; configure died

Charles Bailey wrote: > > I always run my perl builds in batch so I can easily trap any errors that > > occur with the text, etc., etc., and I never ran into those "Warning: Executing > > in batch mode... " messages before. I think they are bogus, as there has never > > been a file locking probl

Re: vms 6.2-1h3; decc 6.2; configure died

Charles Bailey wrote: > > In looking over the Bourne shell version of Configure I'd say replace > > them with "5_005" or simply apply the patch that I sent to the list a > > bit earlier. It does not appear that you want ''version' in xs_apiversion > > or pm_apiversion (although there is enough f

Re: [PATCH RC1]a bunch of config clean up items (still not prime time)

Dan Sugalski wrote: > We can, and probably should, combine some of the tests--no reason we can't > probe for sizes of things in one go, rather than one per thingie. Ah Yup. ;-) Peter Prymmer

RE: progress report on piping on VMS

Charles Bailey wrote: > This remains a problem, I agree. It's actually a bit frustrating because we've > gone out of our way to include portable ways to do things in the Perl > distribution, and many of the problems arise because someone didn't take the > time to use them. As we find better way

Re: [PATCH RC1]a bunch of config clean up items (still not prime time)

Charles Bailey wrote: > > 'define' on VMS and they ought not even incur the expense of any symbol d_foo > > or perl_d_foo. Hence there are at least three classes of conf variables: those > > that are completely ignorable on VMS and do not even need to be in our > > config.sh, those that take c

RE: RMS$_DNF in cando_by_name()

Craig A. Berry wrote: > At 02:18 PM 3/13/00 -0800, Peter Prymmer replied to me off-list: > > > BTW, did you ever solve the dir not found error in Perl 5.6's vms.c? > > > >No. I punted on the issue and sent a patch to vmsperl this morning. > >It is a wacky large value that I see on the return fr

Re: vms 6.2-1h3; decc 6.2; configure died

Dan Sugalski wrote: !>Hi Charles, hmmm, this was built on vms6.2-1h3, decc 6.2, alpha. multinet !>4.2a. !> !>configure "-des" dies, I think because I ran this in batch mode? ! !Nope. Search through subconfigure for localperlver and replace it with !version and you should be OK. (New bug in subc

RE: New test kit

Charles Bailey wrote: > OK, I finally got a chance to catch up on the last several days' patches, > and I've got a new test kit based on RC1 up for ftp here as > ftp://perl.newman.upenn.edu/perl5/vmsperl_rc1_1.tgz After applying the enclosed patch I obtained: [.lib]filespec..FAILED

Re: [PATCH RC1]a bunch of config clean up items (still not prime time)

Dan Sugalski wrote: > There aren't that many symbols in configure.com, though it has grown since > the original. Subconfigure.com, on the other hand, has scads of them--one > for each variable in config.sh. That's way too many, but it seemed like a > good idea at the time. You'll notice that a

RE: [PATCH RC1]a bunch of config clean up items (still not prime time)

I wrote: > OK enough babbling here's the patch, Dan provided you don't disagree with > any of it I'd appreciate it if you could fold this into your working copy > before doing your diff. Please note that I've not sent this to p5p, Jarkko, > or Sarathy and they won't see any of it unless one of

[PATCH RC1]a bunch of config clean up items (still not prime time)

Here is a patch that trims configure.com + subconfigure.com down by 1300 + bytes by removing redundancies between the two and trimming down some of the C<$ IF var .eqs. "Yes"> stuff in the latter. There is a _lot_ more room for improvement as we move toward stuffing redundant code (like compil

RE: progress report on piping on VMS

Charles Lane wrote: >So what do we do? Some options: >1. use vmsish 'messages' off by default -> no VMS messages >2. use ???'?quietude?' off by default -> VMS messages >3. use vmsish 'messages' ON by default (violating Dan's rule) > >I don't think the ??? s

  1   2   >