Re: GNV BASH hacks on 5.8.4-RCI issues.
At 2:58 PM -0400 4/25/04, John E. Malmberg wrote:
With the patches that I have attached now, Perl is only failing one test.
lib/ExtUtils/t/basic.FAILED at test 28
I do not have hard links enabled on the ODS-5 volume. I do not know if that is
affecting the test results.
I doubt it.
I also do not know how to trouble shoot this failed test to find out what is wrong,
and how to make the test pass.
As part of its standard test suite, Perl builds, tests, and installs
a dummy extension in order to validate the extension building
process. There are a couple of VMS-specific hacks in
[.lib.ExtUtils]Manifest.pm that case-level filenames read from an
extension's manifest. These case-leveled names are then compared to
case-specific names returned from the filesystem, or at least they are
case-specific when DECC$EFS_CASE_PRESERVE is enabled. Without
running the test with your modified version, I can't say for sure
this is where the problem is, but on the other hand I can't see how
Manifest.pm could work in a case-preserved environment (at least
without modifications that are planned but not yet implemented).
With only one test failing though, it looks a lot better.
Indeed. So Perl is able to build itself and all the core extensions
with your modifications?
Now how do get a more verbose output of the failing test?
Read the instructions in README.vms :-). . where it will tell you
$ @[.vms]test .exe -v [-.lib.extutils.t]basic.t
though the second argument should be ndbg instead of empty if
you've got a VMS debug build.
I hope I do not need to build a debug version of perl, I have not got that to work
yet on VAX.
I do it pretty regularly on Alpha and the relevant qualifiers should
be the same. From your subsequent message it looks like you may have
it working, but let us know if not.
--- dist_root:[00]configure.com_oldSun Apr 11 21:58:27 2004
+++ dist_root:[00]configure.comSat Apr 24 22:31:30 2004
Forgive the ongoing nitpicking of your patch style, but unless these
filespecs are in unix syntax, folks who have check-in authority are
not going to be able to apply it. I know you may not intend the
patch to be ready for that yet, but it's getting darn close.
Lots of stuff that looks ok snipped.
@@ -4384,8 +4422,10 @@
* the argv items and lowercase all of these names.
*/
for (c = string; *c; ++c)
+ if (!decc_efs_case_preserve) {
if (isupper(*c))
*c = tolower(*c);
+ }
if (isunix) trim_unixpath(string,item,1);
add_item(head, tail, string, count);
++expcount;
I would think we'd want to check decc_efs_case_preserve outside the loop.
more good stuff snipped.
+#ifndef __VAX
+#if __CRTL_VER = 7030
+s = decc$feature_get_index(DECC$EFS_CASE_PRESERVE);
+decc_efs_case_preserve = decc$feature_get_value(s, 1);
+
I'm with you on this one.
+s = decc$feature_get_index(DECC$FILENAME_UNIX_REPORT);
+decc_filename_unix_report = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_REPORT, FALSE);
+
+s = decc$feature_get_index(DECC$FILENAME_UNIX_ONLY);
+decc_filename_unix_only = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_ONLY, FALSE);
But I'm confused on these two. It looks to me like we check for
whether the features are enabled and save the setting we inherited
from the environment, but then we also explicitly disable the
features. If we honor the values we inherit, it seems we would not
want to disable them. If we disable them, it seems we would not want
to save the values we inherit. What am I missing?
+#else
+status = sys_trnlnm(DECC$EFS_CASE_PRESERVE, val_str, sizeof(val_str));
+if (status) {
+ _toupper(str[0])
+ if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) {
+ decc_efs_case_preserve = 1;
+ }
+}
+status = sys_trnlnm(DECC$FILENAME_UNIX_REPORT, val_str, sizeof(val_str));
+if (status) {
+ _toupper(str[0])
+ if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) {
+ decc_filename_unix_report = 1;
+ status = sys_crelnm(DECC$FILENAME_UNIX_REPORT, DISABLE);
+ }
+}
+status = sys_trnlnm(DECC$FILENAME_UNIX_ONLY, val_str, sizeof(val_str));
+if (status) {
+ _toupper(str[0])
+ if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) {
+ decc_filename_unix_only = 1;
+ status = sys_crelnm(DECC$FILENAME_UNIX_ONLY, ENABLE);
+ }
+}
Hmm. On this last one we are checking to see if it's already enabled and then
re-enabling it?
+#endif
+#endif
+
+
+/* CRTL can be initialized past this point, but not before. */
+/*DECC$CRTL_INIT(); */
+
+return SS$_NORMAL;
+}
+
+#ifdef __DECC
+/* DECC dependent attributes */
+#if __DECC_VER 60560002
+#define relative
+#define not_executable
+#else
+#define relative ,rel
+#define not_executable ,noexe
+#endif
+#pragma nostandard
+#pragma
Re: Current Status and location of VMS::Logical?
Dr. Martin P.J. Zinser [EMAIL PROTECTED] wrote on 04/28/2004 06:56:10 PM: subject says it all:-) I am looking for a place to find the VMS::Logicals module (vmsbox.cjb.net does not work for me), as well as for information on its current status. You bring up an important topic. The original author, Forrest Cahoon, does have a CPAN account as can be seen at e.g.: http://search.cpan.org/~forrest/ From which you'll see that he has a semi active blog and now appears to like writing perl code on Linux. He has a GPG key at: http://www.abstractfactory.org/forrest/gpg_key.html I think that I tried back in February 2004 to get a hold of Forrest, but I do not recall having succeeded with plain email (neither gpg nor pgp signed) to any of his old addresses that he had used to post to vmsperl. I suggested a patch way back in: http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2002-06/msg00011.html I think the module needs to be on CPAN. If Forrest can't do it (perhaps he moved and does not have access to VMS anymore?) then someone else should. Are there any volunteers out there? Peter Prymmer
Re: Current Status and location of VMS::Logical?
Hello Craig, hello Peter, as for VMS::Logical on the Freeware: I think I should know that ;-) Seriously, VMS::Logical was on my wishlist for the freeware V6 and is currently on my ToDo list for the next freeware kit. This is one of the reasons I am looking for it right now ;-) As for the Patch/CPAN: I do still have the mail with the Patch in my mailfolder on disk:-), I just need the original to apply the patch against. Anybody has one by chance? I might be able to polish the module up so it could be submitted, but would prefer if somebody who already has an account could do the final submission. Greetings, Martin From: IN%[EMAIL PROTECTED] 29-APR-2004 18:04:20.25 Subj: RE: Current Status and location of VMS::Logical? Dr. Martin P.J. Zinser [EMAIL PROTECTED] wrote on 04/28/2004 06:56:10 PM: subject says it all:-) I am looking for a place to find the VMS::Logicals module (vmsbox.cjb.net does not work for me), as well as for information on its current status. You bring up an important topic. The original author, Forrest Cahoon, does have a CPAN account as can be seen at e.g.: http://search.cpan.org/~forrest/ From which you'll see that he has a semi active blog and now appears to like writing perl code on Linux. He has a GPG key at: http://www.abstractfactory.org/forrest/gpg_key.html I think that I tried back in February 2004 to get a hold of Forrest, but I do not recall having succeeded with plain email (neither gpg nor pgp signed) to any of his old addresses that he had used to post to vmsperl. I suggested a patch way back in: http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2002-06/msg00011.html I think the module needs to be on CPAN. If Forrest can't do it (perhaps he moved and does not have access to VMS anymore?) then someone else should. Are there any volunteers out there? Peter Prymmer Dr. Martin P.J. Zinser [EMAIL PROTECTED] Deutsche Boerse Systems Inc. 233 South Wacker Drive Tel: +1-312-544-1027 Suite 2455 FAX: +1-312-544-1301 Chicago, IL, 60606 USA Private: [EMAIL PROTECTED]
RE: Current Status and location of VMS::Logical?
I've volunteered before, but I have not produced what I promised (e.g., our website has not been touched, and I'm feeling guilty about that). Nonetheless, if no one else can do it, I will try to step in here. I hope some one else can do it, however... Carl Friedberg [EMAIL PROTECTED] +1.212.233.5470 www.comets.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Dr. Martin P.J. Zinser [EMAIL PROTECTED] wrote on 04/28/2004 06:56:10 PM: subject says it all:-) I am looking for a place to find the VMS::Logicals You bring up an important topic. The original author, Forrest Cahoon, does have a CPAN account as can be seen at e.g.: http://search.cpan.org/~forrest/ From which you'll see that he has a semi active blog and now appears to like writing perl code on Linux. He has a GPG key at: http://www.abstractfactory.org/forrest/gpg_key.html I think that I tried back in February 2004 to get a hold of Forrest, but I do not recall having succeeded with plain email (neither gpg nor pgp signed) to any of his old addresses that he had used to post to vmsperl. I suggested a patch way back in: http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2002-06/msg00011.html I think the module needs to be on CPAN. If Forrest can't do it (perhaps he moved and does not have access to VMS anymore?) then someone else should. Are there any volunteers out there? Peter Prymmer
Re: GNV BASH hacks on 5.8.4-RCI issues.
Craig A. Berry wrote:
At 2:58 PM -0400 4/25/04, John E. Malmberg wrote:
Indeed. So Perl is able to build itself and all the core extensions
with your modifications?
It seems so. The intent was that unless the C features were enabled,
that they would not be visible.
I do not have any feature logicals set for the build. They might affect
things, and then the build procedure would have to disable them to
protect it self.
--- dist_root:[00]configure.com_old Sun Apr 11 21:58:27 2004
+++ dist_root:[00]configure.com Sat Apr 24 22:31:30 2004
Forgive the ongoing nitpicking of your patch style, but unless these
filespecs are in unix syntax, folks who have check-in authority are
not going to be able to apply it. I know you may not intend the
patch to be ready for that yet, but it's getting darn close.
I will have to use the bash shell to change the syntax. The samba/rsync
folks seem to be able to accept them. Having never run a patch
procedure, I do not know if it cares about what is in the filename, but
just uses it as a comment. After all, those lines do not contain
anything that the patch program needs to apply the patch.
Lots of stuff that looks ok snipped.
@@ -4384,8 +4422,10 @@
* the argv items and lowercase all of these names.
*/
for (c = string; *c; ++c)
+ if (!decc_efs_case_preserve) {
if (isupper(*c))
*c = tolower(*c);
+ }
if (isunix) trim_unixpath(string,item,1);
add_item(head, tail, string, count);
++expcount;
I would think we'd want to check decc_efs_case_preserve outside the loop.
So do I. I am surprised that I did not see that before. My suspicion
is that I put the line in the wrong place. I will change that even
though the compiler should know to do the right thing.
more good stuff snipped.
+s = decc$feature_get_index(DECC$FILENAME_UNIX_REPORT);
+decc_filename_unix_report = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_REPORT, FALSE);
+
+s = decc$feature_get_index(DECC$FILENAME_UNIX_ONLY);
+decc_filename_unix_only = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_ONLY, FALSE);
But I'm confused on these two. It looks to me like we check for
whether the features are enabled and save the setting we inherited
from the environment, but then we also explicitly disable the
features. If we honor the values we inherit, it seems we would not
want to disable them. If we disable them, it seems we would not want
to save the values we inherit. What am I missing?
If you leave these features set, it may cause problems when filenames
are passed from C routines to RMS or system services.
It may also have other side effects for filenames that are externally
displayed, which is probably desired.
To leave these features enabled would require more study of the code to
make sure that there are not any problems, and probably some more tests.
But the settings are remembered so that perl will treat . as UNIX
./, instead of SYS$DISK:[].;
+}
+status = sys_trnlnm(DECC$FILENAME_UNIX_ONLY, val_str, sizeof(val_str));
+if (status) {
+ _toupper(str[0])
+ if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) {
+ decc_filename_unix_only = 1;
+ status = sys_crelnm(DECC$FILENAME_UNIX_ONLY, ENABLE);
+ }
+}
Hmm. On this last one we are checking to see if it's already enabled and then re-enabling it?
That is a bug, Since this is a newer version than the #ifdef, it should
not be affecting what I built.
This code was copied from what I did on Python where it was desired to
have all internal filenames in UNIX format.
+
+/* CRTL can be initialized past this point, but not before. */
+/*DECC$CRTL_INIT(); */
A side note here.
Putting a DECC$CRTL_INIT() in a lib$initialize psect may have undesired
effects if put in a shared image. They get chained, and if a C program
is linked with a shared image that has such a call, it will prevent the
features from being detected. This was discovered with Python, and the
RDB module had to be converted to being dynamically loaded to fix.
So there are two psects, LIB$INITIALIZ and LIB$INITIALIZE ?
Yes. I suspect that the LIB$INITIALIZ psect name is not critical, since
the documentation is a bit sparse on that, I would have to either
rummage around in the internals, or track down who ever is currently
maintaining that code.
Well, now I will see if I can find out why that one test is failing, and
then I will look at the two .pm scripts that I am told need a change to
build GTK+.
When I actually try to build GTK+, I may find more issues.
-John
