Gabriel Furstenheim's questions

De acordo com o padrão UUID RFC 4122 , os UUIDs devem ser tratados como unsigned int 128 e a comparação deve ser feita dessa maneira:

Rules for Lexical Equivalence:
      Consider each field of the UUID to be an unsigned integer as shown
      in the table in section Section 4.1.2.  Then, to compare a pair of
      UUIDs, arithmetically compare the corresponding fields from each
      UUID in order of significance and according to their data type.
      Two UUIDs are equal if and only if all the corresponding fields
      are equal.

 UUIDs, as defined in this document, can also be ordered
      lexicographically.  For a pair of UUIDs, the first one follows the
      second if the most significant field in which the UUIDs differ is
      greater for the first UUID.  The second precedes the first if the
      most significant field in which the UUIDs differ is greater for
      the second UUID.

O que significa que println(UUID.fromString("b533260f-6479-4014-a007-818481bd98c6") < UUID.fromString("131f0ada-6b6a-4e75-a6a0-4149958664e3"))deve imprimir falso.

No entanto, é verdade!!

Olhando para a implementação de compareTo (estou usando temurin aqui)

@Override
    public int compareTo(UUID val) {
        // The ordering is intentionally set up so that the UUIDs
        // can simply be numerically compared as two numbers
        int mostSigBits = Long.compare(this.mostSigBits, val.mostSigBits);
        return mostSigBits != 0 ? mostSigBits : Long.compare(this.leastSigBits, val.leastSigBits);
    }

Para este caso particular, os bits mais significativos são

-5389922481480318956
1377831944219938421

respectivamente. O que significa que a comparação está errada porque o longo transborda.

Uma propriedade interessante do json é que leituras parciais são evitadas.

Se um cliente enviar um json como:

[ {"someProperty": 1, "otherProperty": 2}, {"someProperty": 2, "otherProperty": 3}]

E por algum motivo a conexão fecha no meio do caminho e eu só recebo

[ {"someProperty": 1, "otherProperty": 2}

Sei que terei uma exceção de decodificação JSON e nunca processarei essa carga.

Leituras parciais podem ocorrer com protobuf?

Ou seja, tenho uma matriz de bytes, tal que a[0: n]with n != len(a)é válida no mesmo modelo, mas obviamente faltam dados?

Tenho um arquivo no Ubuntu que não está funcionando sourcee não tenho ideia do que está acontecendo.

$ cat .broken_file
export D='222'
$ cat .working_file_1
export D='88'
$ D=5
$ echo $D
5
$ source .working_file_1
$ echo $D
88
$ source .broken_file
$ ## What is happening here? It should be 222
$ echo $D
88

Agora, ambos os arquivos têm as mesmas permissões:

$ ll .working_file_1 .broken_file
-rw-rw-r-- 1 my_user my_user
-rw-rw-r-- 1 my_user my_user 

Além disso, se eu copiar o arquivo quebrado, o novo arquivo simplesmente funcionará:

$ cp .broken_file .broken_file_copy
$ source .broken_file_copy
$ echo $D
222

Portanto, também não é o conteúdo do arquivo.

Posso modificar meu .broken_file (alterando nomes de variáveis ​​e valores) e ele ainda falha.

$ echo $SHELL
/bin/bash
$ echo $BASH_VERSION
5.1.16(1)-release
$ uname -srv
Linux 6.2.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 13 16:27:29 UTC 2

Alguma ideia do que isso pode ser?

Update : typeretorna algumas informações estranhas (não sei como interpretar isso):

$ type .broken_file
.broken_file is DIFFERENT_FOLDER/.broken_file
$ type .broken_file_copy
bash: type: .broken_file_copy: not found