Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > pt.comp.programacao > #194 > unrolled thread
| Started by | Patricia Ferreira <pferreira@example.com> |
|---|---|
| First post | 2024-01-26 15:00 -0300 |
| Last post | 2024-01-26 15:00 -0300 |
| Articles | 1 — 1 participant |
Back to article view | Back to pt.comp.programacao
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: sobre fontes e leitura Patricia Ferreira <pferreira@example.com> - 2024-01-26 15:00 -0300
| From | Patricia Ferreira <pferreira@example.com> |
|---|---|
| Date | 2024-01-26 15:00 -0300 |
| Subject | Re: sobre fontes e leitura |
| Message-ID | <87jznwasad.fsf@example.com> |
Patricia Ferreira <pferreira@example.com> writes: [...] > Tem dois tipos de anotações. Existem aquelas que servem só pra nos > lembrar onde estávamos e existem aquelas que concluem alguma coisa. Eis > o que escrevi ondem pra continuar o trabalho hoje. > > ;; Where are we? We have the following bug. When Sylpheed posts, > ;; we're getting line endings \r\r\n. This does not happen in any > ;; other way. We don't know what the problem is. Why is that a > ;; problem? Who is doing this? Is it really Sylpheed? Or is that we > ;; somehow? We care because otherwise we cannot parse it! So we have > ;; a bug in parsing-article procedure for sure. If sylpheed always > ;; sends \r\r\n\r\r\n, we will never find \r\n\r\n between HEADER and > ;; BODY. (We should skip this article in which case.) Eis como continuei hoje. ;; How can we discover who is to blame? Use a different client first. ;; But no others work. Lol! What are we going to do? I've no idea. Reconheci minha inabilidade pra projetar software e desisti, ou seja, comecei a usar um debugger---Wireshark. Descobri. ;; It's us doing it. Someone is substituting 0a into 0d 0a. Since ;; Sylpheed already ends lines with 0d 0a, then we end up with what we ;; see. Onde estava o problema? Não é na entrega ao sistema de arquivos porque estou fazendo isso de forma binária. Não é o recebimento do sistema de arquivos porque estou fazendo isso de forma binária. Então onde poderia ser? Não chega da rede com essa adulteração. Então onde poderia ser? Na leitura da rede. Em suma, não era o Windows fazendo tradução de \n pra \r\n. O protocolo NNTP exige \r\n. Sabe o que era? Meu código lê os dados linha por linha. Common Lisp read-line remove \n. Então as linhas vinham como linha\r Ao juntar todas as linhas, eu fazia (str:join \r\n (list linha1\r linha2\r)) e aí, obviamente, terminava com \r\r\n. Solução: (strip-carriage-return (read-line)). Mas nada disso é interessante o suficiente. Então destruímos a anotação e vida que segue. (*) O que seria interessante? Interessante parece ser o fato de que preciso de um debugger. Não consigo ver a comunicação com clareza. Nem meu software me permite ver a comunicação com clareza e nem o cliente. Isso não é mau design? Parece. Se levarmos essa consideração a sério, aí sim podemos escrever um documento inteiro pra posteridade.
Back to top | Article view | pt.comp.programacao
csiph-web