Greetings! OK, this should be in master/Version_2_7_2pre now in case you want to check it out.
Take care, Matt Kaufmann <[email protected]> writes: > Hi Camm, > > That would certainly work for me. I suppose an output file without > a type could generate .h, .data, and .c files as though it had a .o extension > (but it doesn't matter to me, as I'll always be specifying an output > file ending in .o). > > Thanks, > Matt > > On Sun, Nov 23, 2025 at 7:14 AM Camm Maguire <[email protected]> wrote: > > Greetings! > > This seems straightforward enough, with the exception that input > pathnames without a type default to .lsp, traditionally at least. Not > sure if this is in the spec or is still desired. One can, with the > scheme below, supply an :output-file without a type. Thoughts? > > Take care, > > Camm Maguire <[email protected]> writes: > > > Greetings! > > > > Matt, would it work that when supplying :output-file or defaulting to > > the input filename, the c, h and data files would all be formed by > > removing the last ".ext" (if there is one), and then adding ".c" etc.? > > > > Take care, > > > > Matt Kaufmann <[email protected]> writes: > > > >> Hi, > >> > >>> ... I can't see a reason why it > >>> should use just the smallest suffix (the .tar.gz being a counterexample). > >> > >> That's a good point about .tar.gz. So maybe I shouldn't have put this > >> as a request to modify pathname-name. What I actually would find > >> helpful is simply for the auxiliary files created by compilation, in > >> particular the .data file, to have the filename obtained by adding > >> ".data" after stripping off the ".o" suffix. So in the example I > >> gave with > >> :OUTPUT-FILE > <path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.o > >> it would be good if the .data file were > >> <path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.data > >> rather than: > >> <path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.data > >> > >> If there were a way to specify the .data and .c file in a call of > >> compile-file, that would be sufficient for my purposes. > >> > >> -- Matt > >> Matthias Buelow <[email protected]> writes: > >> > >>> Hi, > >>> > >>> I think the main problem here is that Unix-type systems don't really > have a > >>> "file type" in the pathname and therefore the function cannot be > implemented in > >>> a naive way like this. For example, what is a .tar.gz file? A gzip file? > No, > >>> it is really a compressed archive and should be treated as such. File > managers > >>> often have some sort of table that maps filename suffixes to MIME types, > plus > >>> perhaps some other hardcoded logic, but I think that would be outside of > the > >>> scope of this function. > >>> > >>> IMHO there is no proper way to resolve this in a convincing way, I think > the > >>> method gcl has chosen is a legitimate variant and I can't see a reason > why it > >>> should use just the smallest suffix (the .tar.gz being a counterexample). > >>> > >>> Best regards > >>> > >>> Matthias > >>> > >>> > >>> Am Wed, Nov 19, 2025 at 04:16:34PM -0500 schrieb Camm Maguire: > >>>> Greetings, and thanks so much for the feedback. > >>>> > >>>> It does seem one other user requested this as well. I do not think our > >>>> behavior violates the spec, but it does vary from other popular > >>>> implementations. > >>>> > >>>> In short, the first '.' terminates the name in GCL. This was convenient > >>>> in our implementation of pathnames using the regex (e.g. regular > >>>> expression) engine which has been in GCL for ages. As these follow a > >>>> left to right algorithm (longest match if I recall), it makes sense to > >>>> define a terminating character sequence. > >>>> > >>>> If interested you can peruse lsp/gcl_make_pathname.lsp, where you will > find > >>>> > >>>> (defconstant +physical-pathname-defaults+ '(("" "" "" "") > >>>> ("" "" "" "") > >>>> ("" "(/?([^/]+/)*)" "" "" "" > "([^/]+/)" "/" "/") > >>>> ("" "([^/.]*)" "" ".") > >>>> ("." "(\\.[^/]*)?" "" "") > >>>> ("" "" "" ""))) > >>>> > >>>> and an analog for logical pathnames that govern the parsing. I can > >>>> describe the role of each string in the group if interested. > >>>> > >>>> I will try to look at the already implemented regex engine to see if a > >>>> negative look-ahead could be supported. > >>>> > >>>> Take care, > >>>> > >>>> > >>>> Matt Kaufmann <[email protected]> writes: > >>>> > >>>> > Hi Camm, > >>>> > > >>>> > Here's a request: Could you arrange that for any file with a name of > the > >>>> > form "<name>.lisp", then its pathname-name is "<name>" and its > >>>> > pathname-type is "lisp"? This is not always the case, at least in my > >>>> > version of GCL 2.7.1, when "<name>" contains a dot (i.e., character > >>>> > #\.). > >>>> > > >>>> > Below I explain further what I'm seeing and why this is a problem for > >>>> > ACL2. (Probably one can imagine a similar problem for other systems.) > >>>> > > >>>> > Here is behavior I'm seeing in GCL 2.7.1, which causes a problem for > >>>> > ACL2 as explained below. > >>>> > > >>>> >>(pathname-name (pathname "foo.xyz.lisp")) > >>>> > > >>>> > "foo" > >>>> > > >>>> >>(pathname-name "foo.xyz.lisp") > >>>> > > >>>> > "foo" > >>>> > > >>>> >>(pathname-type (pathname "foo.xyz.lisp")) > >>>> > > >>>> > "xyz.lisp" > >>>> > > >>>> >>(pathname-type "foo.xyz.lisp") > >>>> > > >>>> > "xyz.lisp" > >>>> > > >>>> >> > >>>> > > >>>> > I'd prefer to see the behavior shown in the following example, i.e., > >>>> > returning a pathname-type of "lisp". > >>>> > > >>>> >>(pathname-name "foo-xyz.lisp") > >>>> > > >>>> > "foo-xyz" > >>>> > > >>>> >>(pathname-type "foo-xyz.lisp") > >>>> > > >>>> > "lisp" > >>>> > > >>>> >> > >>>> > > >>>> > I'm not sure this behavior is in error, by the way -- just surprising > >>>> > (to me) and, in the case of ACL2, inconvenient. Here's what I found > >>>> > in the CL HyperSPec. > >>>> > > >>>> > https://www.lispworks.com/documentation/HyperSpec/Body/19_bae.htm > >>>> > > >>>> > 19.2.1.5 The Pathname Type Component > >>>> > > >>>> > Corresponds to the ``filetype'' or ``extension'' concept in many > >>>> > host file systems. This says what kind of file this is. This > >>>> > component is always a string, nil, :wild, or :unspecific. > >>>> > > >>>> > To me, it is natural to view "foo.xyz.lisp" as a lisp file, hence with > >>>> > extension "lisp" to say that the "kind of file" is a lisp file. > >>>> > > >>>> > This gets in the way for ACL2 in the case of the following two books. > >>>> > > >>>> > books/projects/aleo/vm/circuits/axe/blake2s1round.old.lisp > >>>> > books/projects/aleo/vm/circuits/axe/blake2s1round.lisp > >>>> > > >>>> > When we do certifications in parallel (i.e., with -j greater than 1), > >>>> > compilation can be attempted in parallel. The two books above can > >>>> > thus lead to the following calls done by two GCL processes in > >>>> > parallel. > >>>> > > >>>> > (COMPILE-FILE > >>>> > > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/[email protected]" > >>>> > :OUTPUT-FILE > >>>> > > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.o") > >>>> > > >>>> > (COMPILE-FILE > >>>> > > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.lsp" > >>>> > :OUTPUT-FILE > >>>> > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.o") > >>>> > > >>>> > Both of these compilations attempt to create the same file, > >>>> > > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.data". > >>>> > I suspect that if pathname-name were changed as described above, then > >>>> > the first compile-file call above would instead create > >>>> > > "<path_to_acl2>/books/projects/aleo/vm/circuits/axe/blake2s1round.old.data". > >>>> > > >>>> > Thanks, > >>>> > Matt > >>>> > > >>>> > >>>> -- > >>>> Camm Maguire > [email protected] > >>>> > ========================================================================== > >>>> "The earth is but one country, and mankind its citizens." -- > Baha'u'llah > >>>> > >> > >> > >> > >> > > -- > Camm Maguire [email protected] > ========================================================================== > "The earth is but one country, and mankind its citizens." -- Baha'u'llah > -- Camm Maguire [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
