whatf0xx's questions

Eu estava analisando esta questão em relação à resposta a um problema simples que tenho: quero ter um bloco if/else para decidir se uma iteração deve ter uma barra de progresso tqdm acompanhante :

fn run(n: usize, verbose: bool) {
  let it = if verbose { tqdm(0..n) } else { 0..n };
  for _ in it { _ }
}

O código acima não compila, porque os dois braços do if/else têm tipos diferentes, um é a Rangee o outro é a Tqdm<Range>. No entanto, com base na pergunta vinculada no topo, fiz a seguinte modificação e ele compila bem:

fn run(n: usize, verbose: bool) {
  let it: Box<dyn impl Iterator<Item = usize>> = if verbose { 
    Box::new(tqdm(0..n))
  } else {
    Box::new(0..n)
  };
  for _ in it { _ }
}

Ao especificar o tipo (na verdade, isso é necessário, apenas envolvê-lo Boxnão ajuda), posso fazer o código compilar. No entanto, ingenuamente sinto que isso significa que há uma alocação extra de heap do dyn Iteratorobjeto, enquanto antes tudo (pelo menos como eu entendo) era mais ou menos manipulado dentro do quadro de pilha. Sei que, em geral, o despacho dinâmico (que eu acho que é, mas não tenho certeza absoluta) vem com um impacto no desempenho.

Antes de embrulhar, Boxtentei apenas anotar, dyn Iterator<Item = usize>mas não funcionou. Acho que porque, de alguma forma, a Boxabstração é necessária, mas não entendi bem o porquê.

Existe uma maneira de fazer esse código, ou a ideia por trás dele, compilar sem o Boxe a alocação de heap? Isso é menos importante do que eu penso? Se isso é impossível, por que não posso fazer o simples dyn Iteratorsem o Boxcomo mencionei acima?

Eu tenho um projeto simples que depende do pyo3. Atualmente/anteriormente, ele estava usando a versão 0.20.0, mas recentemente uma nova versão foi lançada, que é a versão 0.21.2. Estou procurando um comando Cargo que atualize a dependência, mesmo que isso signifique que eu tenha que voltar à fonte e corrigir quaisquer alterações importantes que foram introduzidas. No entanto, se eu executar:

> cargo update pyo3 --precise 0.21.2

Ou apenas igualmente:

cargo update pyo3

Então me deparei com o seguinte erro:

error: failed to select a version for the requirement `pyo3 = "^0.20.0"`
candidate versions found which didn't match: 0.21.2
location searched: crates.io index
required by package `eight-ball v0.1.0 (/home/harry/Documents/eight-ball)`
perhaps a crate was updated and forgotten to be re-vendored?

Aqui está o Cargo.tomlarquivo como estava antes da atualização:

[package]
name = "eight-ball"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
[lib]
name = "eight_ball"
crate-type = ["cdylib"]

[dependencies]
itertools = "0.12.1"
pyo3 = "0.20.0"

Se eu acessar o Cargo.tomlarquivo e alterar manualmente a versão para pyo3a versão mais recente e depois compilar, tudo funcionará bem. Não parece que o que estou procurando seja algo maluco, então sinto que estou usando o Cargo de maneira errada.

O que eu queria era apenas poder executar um comando Cargo para me atualizar para a versão 0.21.2, mas a escolha óbvia não funcionou e não consegui ver uma opção --force ou similar. Não sei por que pensei que eu estava tão decidido a permanecer na versão 0.20.0.

Como posso usar o cargo para atualizar as dependências do meu projeto sem precisar modificá-las Cargo.tomldiretamente?

Pelo que entendi, não deveria ser possível ter uma referência mutável a um dado imutável. Dessa forma, se eu quiser criar alguns structque implementem Iteratorcom base na mutação de um estado interno, terei que declarar qualquer instância disso structcomo mutável para poder criar as referências mutáveis ​​​​necessárias.

Para demonstrar, construí um exemplo simples, abaixo:

struct MyIter {
    internal_state: u32
}

impl MyIter {
    fn new() -> MyIter {
        MyIter{ internal_state: 0 }
    }
}

impl Iterator for MyIter {
    type Item = u32;
    fn next(&mut self) -> Option<u32> {
        self.internal_state += 1;
        Some(self.internal_state)
    }
}

#[cfg(test)]
mod tests {
    use super::*;
    use std::iter::zip;

    #[test]
    fn mutable_declaration_no_zip() {
        let mut my_iter = MyIter::new();
        assert_eq!(my_iter.next(), Some(1));
        assert_eq!(my_iter.next(), Some(2));
        assert_eq!(my_iter.next(), Some(3));
    }
}

Isso compila bem e passa, enquanto se eu alterar a função de teste para ter uma declaração imutável for my_iter, como abaixo, ela se recusará a compilar com a mensagem esperada de error[E0596]: cannot borrow 'my_iter' as mutable, as it is not declared as mutable:

#[test]
fn immutable_declartaion_no_zip() {
    let my_iter = MyIter::new();
    assert_eq!(my_iter.next(), Some(1));
    assert_eq!(my_iter.next(), Some(2));
    assert_eq!(my_iter.next(), Some(3));
}

Minha pergunta diz respeito ao caso em que faço basicamente o mesmo que acima, mas uso std::iter::zippara realizar a iteração. O que acontece agora é que mesmo que eu declare my_itercomo imutável, o teste é compilado e aprovado, o que significa que nos bastidores ziphouve uma mutação no estado da variável imutável na qual passei!

#[test]
fn immutable_declaration_zip() {
    let my_iter = MyIter::new();
    let nums: [u32;10] = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
    for (i, num) in zip(my_iter, nums.iter()) {
        assert_eq!(i, *num);
    }
}

Então, alguém poderia explicar por que zipfoi configurado para poder fazer isso? Como posso zipchamar o next()método e, portanto, gerar referências mutáveis ​​para dados que declarei como imutáveis?

Eu sou novo no Docker. Quero colocar em contêiner um ambiente pequeno para poder executar executáveis, mas estou preso porque não consigo nem executar um executável.

Minha estrutura de pastas é assim:

example/
|-Dockerfile
|-hello_world

Meu Dockerfilefica assim:

# Use Alpine Linux as the base image
FROM alpine:latest

# Set the working directory inside the container
WORKDIR /app

# Copy the executable to the container
COPY hello_world /app/

# Set the permissions for the executable
RUN chmod +x /app/hello_world

# Define the command to run your server when the container starts
ENTRYPOINT ["/app/hello_world"]

Então eu corro:

> sudo docker build -t example .

> sudo docker run --name example_container example

O resultado disso é este:

exec /app/hello_world: no such file or directory

Eu tentei tantas variações quanto posso imaginar, tentando usar CMD, RUNe ENTRYPOINTno Dockerfile mas todas tiveram o mesmo resultado da imagem não conseguir encontrar o programa hello_world na pasta app que existe na raiz.

Estou realmente confuso porque tentei isso no meu sistema operacional Ubuntu vanilla, coloquei uma pasta de teste na raiz e depois uma hello_worldlá, e pareceu funcionar bem, pois eu poderia executá-lo de qualquer lugar com esse caminho absoluto.

/app/hello_worldé um executável, é um trecho compilado de código Rust. Quando executo /app/hello_worldo shell na minha máquina Ubuntu, ele funciona bem.

conjunto de ferramentas stable-x86_64-unknown-linux-gnu/rustc 1.71.0

Alguém poderia me dizer o que estou fazendo de errado?