Re: [Gcl-devel] lstat

[Matt Kaufmann]

Hi, Camm --

For 1), I'd appreciate your running the following experiment: in your
local copy of books/Makefile, change the line

SHELL := $(shell which bash)

to:

SHELL := $(shell which sh)

or just explicitly define SHELL to be the full pathname of the sh
executable.

If that works, I'll think about how to allow such overrides without
editing that Makefile.  (I don't want to use "?=" in place of ":=",
since otherwise SHELL might be modified by accident.)

For 2), I'll get with the person who kind of maintains that Perl
stuff.

>> Is there a way to certify just using make as in the past, just so I can
>> test the integrity of this image?

I hope so, once we've dealt with 1) and 2).

For state, please try:

  *the-live-state*

Thanks for keeping at this --
-- Matt
   From: Camm Maguire <address@hidden>
   Cc: address@hidden, address@hidden
   Date: Wed, 16 Oct 2013 09:26:38 -0400

   Greetings!  I was not requesting change on your part here, just advice.
   I've decided to hardcode the conventional stripping into stat for
   mingw32, so the issue is now moot.

   Windows environments appear to vary quite a bit.  ACL2 itself can now be
   built straightforwardly (modulo the canonical-unix-pathname issue), but
   the books certification fails due to

   1) books/Makefile gets the shell with `which bash`, and there is only
   /bin/sh here.

   2) The perl installation on mingw cannot load certlib.pl, not finding
   Storable.pm in the include path.

   Is there a way to certify just using make as in the past, just so I can
   test the integrity of this image?

   I'm trying to send you the three forms you requested, but don't know how
   to generate a 'state' variable to pass to pathname-unix-to-os.  I
   trapped one in an error backtrace before, but that error is now
   cleared.  I will have to rebuild from scratch reintroducing the error
   unless there is a way I can get a 'state' normally.

   Take care,

   Matt Kaufmann <address@hidden> writes:

   > Hi, Camm --
   >
   > I'm not sure I follow, but I think you're saying that in some Windows
   > environment, evaluation of (our-user-homedir-pathname) can produce a
   > pathname ending in "//".  Is that right?  Which version of ACL2 is
   > this?  Which version of GCL?  What do you get by evaluating
   > (user-homedir-pathname) instead?
   >
   > I assume that you'd prefer having (our-user-homedir-pathname) produce
   > pathnames that do not end in "//".  Would you also prefer that it not
   > end in "/"?  Please feel free to elaborate; for example, if you happen
   > to know which function is calling (our-user-homedir-pathname) but
   > having trouble with its result, I'd be interested in knowing.
   >
   > Thanks --
   > -- Matt
   >    From: Camm Maguire <address@hidden>
   >    Date: Tue, 15 Oct 2013 16:03:44 -0400
   >
   >    Greetings, and thanks again so much for the use of your windows machine!
   >
   >    We have
   >
   >    lstat("c:/emacs",&ss) -> 1, and ss shows its a directory
   >    lstat("c:/emacs/",&ss) -> 0
   >    lstat("c:/emacs//",&ss) ->0 ;acl2 our-user-homedir-pathname produces 
this
   >
   >    On wine, the trailing slashes are silently eliminated as is customary.
   >    Should I hardcode this behavior in to make up for the non-uniformity?
   >
   >    Take care,
   >    -- 
   >    Camm Maguire                                        address@hidden
   >    
==========================================================================
   >    "The earth is but one country, and mankind its citizens."  --  
Baha'u'llah
   >
   >
   >
   >
   >
   >

   -- 
   Camm Maguire                                     address@hidden
   ==========================================================================
   "The earth is but one country, and mankind its citizens."  --  Baha'u'llah