Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > pt.comp.programacao > #184 > unrolled thread

sobre common lisp e o sistema de arquivos

Started byPatricia Ferreira <pferreira@example.com>
First post2024-01-22 09:05 -0300
Last post2024-01-27 19:03 +0000
Articles 10 — 2 participants

Back to article view | Back to pt.comp.programacao


Contents

  sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-22 09:05 -0300
    Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-22 16:14 -0300
      Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-23 14:30 -0300
        Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-23 15:42 -0300
          Re: sobre common lisp e o sistema de arquivos Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-24 14:02 +0000
            Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-24 14:52 -0300
      Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-25 01:01 -0300
        Re: sobre common lisp e o sistema de arquivos Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-27 12:05 +0000
          Re: sobre common lisp e o sistema de arquivos Patricia Ferreira <pferreira@example.com> - 2024-01-27 14:21 -0300
            Re: sobre common lisp e o sistema de arquivos Daniel Cerqueira <dan.list@brilhante.top> - 2024-01-27 19:03 +0000

#184 — sobre common lisp e o sistema de arquivos

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-22 09:05 -0300
Subjectsobre common lisp e o sistema de arquivos
Message-ID<87v87la7zs.fsf@example.com>
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: sfwzo74np6w.fsf@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.

[toc] | [next] | [standalone]


#185

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-22 16:14 -0300
Message-ID<878r4h9o4m.fsf@example.com>
In reply to#184
Patricia Ferreira <pferreira@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---

[toc] | [prev] | [next] | [standalone]


#187

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-23 14:30 -0300
Message-ID<87ede8klea.fsf@example.com>
In reply to#185
Patricia Ferreira <pferreira@example.com> writes:

> Patricia Ferreira <pferreira@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.

[toc] | [prev] | [next] | [standalone]


#188

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-23 15:42 -0300
Message-ID<87zfwvki2b.fsf@example.com>
In reply to#187
Patricia Ferreira <pferreira@example.com> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Patricia Ferreira <pferreira@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.

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

[toc] | [prev] | [next] | [standalone]


#191

FromDaniel Cerqueira <dan.list@brilhante.top>
Date2024-01-24 14:02 +0000
Message-ID<87ede6zv6n.fsf@brilhante.top>
In reply to#188
Patricia Ferreira <pferreira@example.com> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Patricia Ferreira <pferreira@example.com> writes:
>>
>>> Patricia Ferreira <pferreira@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.
>
> Lol.  /Shame on me./  Em vez de NIL, basta :type "".

Ainda bem que resolveste.

Eu diria que essa problema é do Ruindows :-P

[toc] | [prev] | [next] | [standalone]


#192

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-24 14:52 -0300
Message-ID<87zfwuhb5b.fsf@example.com>
In reply to#191
Daniel Cerqueira <dan.list@brilhante.top> writes:

> Patricia Ferreira <pferreira@example.com> writes:
>
>> Patricia Ferreira <pferreira@example.com> writes:
>>
>>> Patricia Ferreira <pferreira@example.com> writes:
>>>
>>>> Patricia Ferreira <pferreira@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.
>>
>> Lol.  /Shame on me./  Em vez de NIL, basta :type "".
>
> Ainda bem que resolveste.
>
> Eu diria que essa problema é do Ruindows :-P

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.

[toc] | [prev] | [next] | [standalone]


#193

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-25 01:01 -0300
Message-ID<87wmryf4de.fsf@example.com>
In reply to#185
Patricia Ferreira <pferreira@example.com> writes:

> Patricia Ferreira <pferreira@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.

[toc] | [prev] | [next] | [standalone]


#195

FromDaniel Cerqueira <dan.list@brilhante.top>
Date2024-01-27 12:05 +0000
Message-ID<877cjv0ynw.fsf@brilhante.top>
In reply to#193
Patricia Ferreira <pferreira@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 :-)

[toc] | [prev] | [next] | [standalone]


#196

FromPatricia Ferreira <pferreira@example.com>
Date2024-01-27 14:21 -0300
Message-ID<87fryi1ylb.fsf@example.com>
In reply to#195
Daniel Cerqueira <dan.list@brilhante.top> writes:

> Patricia Ferreira <pferreira@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.

[toc] | [prev] | [next] | [standalone]


#197

FromDaniel Cerqueira <dan.list@brilhante.top>
Date2024-01-27 19:03 +0000
Message-ID<87ttmyzjhf.fsf@brilhante.top>
In reply to#196
Patricia Ferreira <pferreira@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 :-)

[toc] | [prev] | [standalone]


Back to top | Article view | pt.comp.programacao


csiph-web