sobre common lisp e o sistema de arquivos

[Patricia Ferreira]

Tenho lido vários pedaços de documentação Common Lisp por aí, livros
incluindo. Antes de falar com o sistema de arquivos, vale a pena ler o
capítulo 14 de Peter Seibel ``Practical Common Lisp''.

--8<---------------cut here---------------start------------->8---
Files and File I/O
https://gigamonkeys.com/book/files-and-file-io.html

``When pathnames were designed, the set of file systems in general use
was quite a bit more variegated than those in common use today.
Consequently, some nooks and crannies of the pathname abstraction make
little sense if all you're concerned about is representing Unix or
Windows filenames.''
--8<---------------cut here---------------end--------------->8---

Uma das coisas legais de Common Lisp é essa. É uma linguagem realmente
antiga que levava em consideração uma série de sistemas que não se vê
mais. É uma oportunidade pra entender melhor a evolução da coisa.

--8<---------------cut here---------------start------------->8---
The historical diversity of file systems in existence during the 70s
and 80s can be easy to forget. Kent Pitman, one of the principal
technical editors of the Common Lisp standard, described the situation
once in comp.lang.lisp (Message-ID: sfwzo74...@world.std.com)
thusly:

The dominant file systems at the time the design [of Common Lisp]
was done were TOPS-10, TENEX, TOPS-20, VAX VMS, AT&T Unix, MIT
Multics, MIT ITS, not to mention a bunch of mainframe [OSs]. Some
were uppercase only, some mixed, some were case-sensitive but case-
translating (like CL). Some had dirs as files, some not. Some had
quote chars for funny file chars, some not. Some had wildcards, some
didn't. Some had :up in relative pathnames, some didn't. Some had
namable root dirs, some didn't. There were file systems with no
directories, file systems with non-hierarchical directories, file
systems with no file types, file systems with no versions, file
systems with no devices, and so on.
--8<---------------cut here---------------end--------------->8---

Duvido que alguém consiga localizar a mensagem original de Kent Pitman.

[Patricia Ferreira]

Patricia Ferreira <pfer...@example.com> writes:

> Tenho lido vários pedaços de documentação Common Lisp por aí, livros
> incluindo. Antes de falar com o sistema de arquivos, vale a pena ler o
> capítulo 14 de Peter Seibel ``Practical Common Lisp''.
>

> Files and File I/O
> https://gigamonkeys.com/book/files-and-file-io.html
>
> ``When pathnames were designed, the set of file systems in general use
> was quite a bit more variegated than those in common use today.
> Consequently, some nooks and crannies of the pathname abstraction make
> little sense if all you're concerned about is representing Unix or
> Windows filenames.''

Eis o tipo de armadilha contras as quais estamos.

--8<---------------cut here---------------start------------->8---
NNTPD> (rename-file (make-pathname :name "1" :type "tmp") (make-pathname :name "2" :type "txt"))
Failed to find the TRUENAME of "c:\\[...]\\quicklisp\\local-projects\\nntp\\groups\\1.tmp":
--8<---------------cut here---------------end--------------->8---

Lol. Não consigo nem renomear um arquivo.

--8<---------------cut here---------------start------------->8---
NNTPD> *default-pathname-defaults*
#P"c:/[...]/quicklisp/local-projects/nntp/groups/local.test"

NNTPD> (sb-posix:getcwd)
"c:\\[...]\\quicklisp\\local-projects\\nntp\\groups\\local.test"
--8<---------------cut here---------------end--------------->8---

Em outras palavras---rename-file deveria operar nesse diretório aí e não
em groups/. O que poderia estar errado? Veja que sei o que estou
fazendo---sei renomear um arquivo e tenho curso *superior* e tal.

--8<---------------cut here---------------start------------->8---
* *default-pathname-defaults*
#P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/groups/local.test/"
* (rename-file "1.tmp" "1.txt")
#P"c:/[...]/quicklisp/local-projects/nntp/groups/local.test/1.txt"
#P"c:/[...]/quicklisp/local-projects/nntp/groups/local.test/1.tmp"
#P"c:/[...]/quicklisp/local-projects/nntp/groups/local.test/1.txt"
--8<---------------cut here---------------end--------------->8---

Isso prova.

Onde está o problema? O problema está no fato de que aí na segunda
tentativa, o diretório termina com uma barra. No primeiro caso, onde a
falha ocorre, não há uma barra. Common Lisp assume que aquilo então é
um arquivo e não um diretório. ``Ele'' então pega o diretório daquele
arquivo, que é groups/.

Peter Seibel me avisou disso, mas iniciantes são assim. Como disse a
USENET uma vez---even if you dip a user in an ocean of clues, it will
comes out clueless. Lol.

--8<---------------cut here---------------start------------->8---
When dealing with pathnames that name directories, you need to be
aware of one wrinkle. Pathnames separate the directory and name
components, but Unix and Windows consider directories just another
kind of file. Thus, on those systems, every directory has two
different pathname representations.

One representation, which I'll call file form, treats a directory
like any other file and puts the last element of the namestring into
the name and type components. The other representation, directory
form, places all the elements of the name in the directory
component, leaving the name and type components NIL.

When you create pathnames with MAKE-PATHNAME, you can control which
form you get, but you need to be careful when dealing with
namestrings. All current implementations create file form pathnames
unless the namestring ends with a path separator. But you can't rely
on user-supplied namestrings necessarily being in one form or
another. For instance, suppose you've prompted the user for a
directory to save a file in and they entered "/home/peter". If you
pass that value as the :defaults argument of MAKE-PATHNAME like
this:

(make-pathname :name "foo" :type "txt" :defaults user-supplied-name)

you'll end up saving the file in /home/foo.txt rather than the
intended /home/peter/foo.txt because the "peter" in the namestring
will be placed in the name component when user-supplied-name is
converted to a pathname. -- Peter Seibel, capítulo 14.
--8<---------------cut here---------------end--------------->8---

[Patricia Ferreira]

Patricia Ferreira <pfer...@example.com> writes:

> Patricia Ferreira <pfer...@example.com> writes:
>
>> Tenho lido vários pedaços de documentação Common Lisp por aí, livros
>> incluindo. Antes de falar com o sistema de arquivos, vale a pena ler o
>> capítulo 14 de Peter Seibel ``Practical Common Lisp''.
>>
>> Files and File I/O
>> https://gigamonkeys.com/book/files-and-file-io.html
>>
>> ``When pathnames were designed, the set of file systems in general use
>> was quite a bit more variegated than those in common use today.
>> Consequently, some nooks and crannies of the pathname abstraction make
>> little sense if all you're concerned about is representing Unix or
>> Windows filenames.''
>
> Eis o tipo de armadilha contras as quais estamos.
>

> NNTPD> (rename-file (make-pathname :name "1" :type "tmp") (make-pathname :name "2" :type "txt"))
> Failed to find the TRUENAME of "c:\\[...]\\quicklisp\\local-projects\\nntp\\groups\\1.tmp":
>

> Lol. Não consigo nem renomear um arquivo.

Eis a próxima.

NNTPD> (rename-file "3.txt" "3")
#P"c:/[...]/nntp/groups/local.test/3.txt"
#P"c:/[...]/nntp/groups/local.test/3.txt"
#P"c:/[...]/nntp/groups/local.test/3.txt"

Não é fácil renomear um arquivo sem uma ``extensão'', que Common Lisp
adequadamente chama de ``type''. Tentei também um experimento aleatório
como

(make-pathname :name "3" :type nil)

com mesmo comportamento. Desisti de não usar extensões.

Por que você escolheria uma linguagem de programação que não te
apresenta esses obstáculos históricos?

If you know your history
You know where you're coming from
-- Robert Marley, 1978.

[Patricia Ferreira]

Lol. /Shame on me./ Em vez de NIL, basta :type "".

[Daniel Cerqueira]

Ainda bem que resolveste.

Eu diria que essa problema é do Ruindows :-P

[Patricia Ferreira]

Não é, não---Windows não de fato suporta essas extensões. Você pode
nomear seus arquivos essencialmente como se faz em UNIX exceto por uma
escolha mais restrita de caracteres. As extensões são essencialmente
uma coisa dependente da aplicação, como o explorador de arquivos.

[Patricia Ferreira]

Patricia Ferreira <pfer...@example.com> writes:

> Patricia Ferreira <pfer...@example.com> writes:
>
>> Tenho lido vários pedaços de documentação Common Lisp por aí, livros
>> incluindo. Antes de falar com o sistema de arquivos, vale a pena ler o
>> capítulo 14 de Peter Seibel ``Practical Common Lisp''.
>>
>> Files and File I/O
>> https://gigamonkeys.com/book/files-and-file-io.html
>>
>> ``When pathnames were designed, the set of file systems in general use
>> was quite a bit more variegated than those in common use today.
>> Consequently, some nooks and crannies of the pathname abstraction make
>> little sense if all you're concerned about is representing Unix or
>> Windows filenames.''
>
> Eis o tipo de armadilha contras as quais estamos.

Eis outra.

NNTPD> (sb-posix:getcwd)
"c:\\sys\\emacs\\usr\\quicklisp\\local-projects\\nntp\\groups\\local.test"

NNTPD> (uiop:getcwd)
#P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/groups/local.test/"

Está bem claro em que diretório SBCL está. Agora, observe:

%pwd
c:/sys/emacs/usr/quicklisp/local-projects/nntp/groups/local.test

%ls
2 3 4

Se eu pedir pra abrir 2, 3 ou 4, conseguirei com certeza:

NNTPD> (open "2")
The file #P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/2" does not exist:
The system cannot find the file specified.

Lol---open olha outro diretório.

A conclusão parece simples. Procedimentos e macros como open,
with-open-file et cetera usam a variável *default-pathname-defaults* e
ignoram o current-working-directory do processo. A variável relevant é

NNTPD> *default-pathname-defaults*
#P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/"

É preciso conhecer essa vida pré-UNIX.

[Daniel Cerqueira]

Patricia Ferreira <pfer...@example.com> writes:

> A conclusão parece simples. Procedimentos e macros como open,
> with-open-file et cetera usam a variável *default-pathname-defaults* e
> ignoram o current-working-directory do processo. A variável relevant é
>
> NNTPD> *default-pathname-defaults*
> #P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/"
>
> É preciso conhecer essa vida pré-UNIX.

Tens muita razão. Tenho-te a agradecer :-) Isto que disseste acabou de
me dar jeito. Alterar o *default-pathname-defaults* com SETF e PATHNAME
foi o que foi preciso para eu por as coisas a funcionar :-)

Estou a ver isto do lisp-koans (https://github.com/google/lisp-koans).

Acho engraçado isto de koans :-P Talvez deixe para um pouco mais tarde,
mas já consegui correr o programa pela primeira vez :-)

[Patricia Ferreira]

Daniel Cerqueira <dan....@brilhante.top> writes:

> Patricia Ferreira <pfer...@example.com> writes:
>
>> A conclusão parece simples. Procedimentos e macros como open,
>> with-open-file et cetera usam a variável *default-pathname-defaults* e
>> ignoram o current-working-directory do processo. A variável relevant é
>>
>> NNTPD> *default-pathname-defaults*
>> #P"c:/sys/emacs/usr/quicklisp/local-projects/nntp/"
>>
>> É preciso conhecer essa vida pré-UNIX.
>
> Tens muita razão. Tenho-te a agradecer :-) Isto que disseste acabou de
> me dar jeito. Alterar o *default-pathname-defaults* com SETF e PATHNAME
> foi o que foi preciso para eu por as coisas a funcionar :-)
>
> Estou a ver isto do lisp-koans (https://github.com/google/lisp-koans).

Legal! Deve ser útil.

> Acho engraçado isto de koans :-P Talvez deixe para um pouco mais tarde,
> mas já consegui correr o programa pela primeira vez :-)

É engraçado.

--8<---------------cut here---------------start------------->8---
A kōan is a story, dialogue, question, or statement from the Chinese
Chan-lore, supplemented with commentaries, that is used in Zen practice
to provoke the "great doubt" and initial insight of
Zen-students. Prolonged koan-study shatters small-minded pride of, and
identification with, this initial insight, and spurs further development
of insight and compassion, and integration thereof in daily life and
character.
--8<---------------cut here---------------end--------------->8---

Insight e sabedoria por via de métodos. Como se... Lol.

[Daniel Cerqueira]

Patricia Ferreira <pfer...@example.com> writes:

> --8<---------------cut here---------------start------------->8---
> A kōan is a story, dialogue, question, or statement from the Chinese
> Chan-lore, supplemented with commentaries, that is used in Zen practice
> to provoke the "great doubt" and initial insight of
> Zen-students. Prolonged koan-study shatters small-minded pride of, and
> identification with, this initial insight, and spurs further development
> of insight and compassion, and integration thereof in daily life and
> character.
> --8<---------------cut here---------------end--------------->8---
>
> Insight e sabedoria por via de métodos. Como se... Lol.

Boa :-)