Fromトレイト(@Rust)

https://doc.rust-jp.rs/rust-by-example-ja/conversion/from_into.html

に以下のFromトレイトを使ったユーザ定義型の型変換サンプルコードが出てきますが、お馴染みのString::fromもString型に対して(impl From<&str> for String {~~途中省略~~})とfromを定義しているのでやっていることは同じ、

use std::convert::From;

#[derive(Debug)]
struct Number {
    value: i32,
}

impl From for Number {
    fn from(item: i32) -> Self {
        Number { value: item }
    }
}

fn main() {
    let num = Number::from(30);
    println!("My number is {:?}", num);
}

std::convert::Fromトレイトは、

pub trait From: Sized {
    // Required method
    fn from(value: T) -> Self;
}

のようになっているので、from()にこの例のように個別の実装(impl From for Number)をしてやれば、自作の型でも型変換ができるようになります。

 

admin

 

 

refパターン(@Rust)

https://doc.rust-jp.rs/rust-by-example-ja/custom_types/enum/testcase_linked_list.html

のコードでrefと&で何が違うのと思ったのですが、

Rust by exampleの以下のページに出てくるrefパターン

https://doc.rust-jp.rs/rust-by-example-ja/scope/borrow/ref.html

の解説は、

—————————-

 // 左辺に`ref`をつけることによる借用と、右辺に`&`をつけることによる借用は等価

    let ref ref_c1 = c;

    let ref_c2 = &c;


ということなので、どちらも借用ですが似てるようで意味は全く異なります。

該当部分のコード全体をいかに再掲(長ったらしいので日本語は削除)しますが、タプル全体の文字列と長さの取得処理は再帰処理を使っています。

https://doc.rust-jp.rs/rust-by-example-ja/custom_types/enum/testcase_linked_list.html

use crate::List::*; // equivalent to following two lines, it's a short form of the enum List 
//use crate::List::Cons;
//use crate::List::Nil;

#[derive(Debug)]
enum List {
    // Cons: Tuple struct that wraps an element and a pointer to the next node
    Cons(u32, Box 	 	 	),
    // Nil: A node that signifies the end of the linked list
    Nil,
}

// Methods can be attached to an enum
impl List {
    // Create an empty list
    fn new() -> List {
        // `Nil` has type `List`
        Nil
    }

    // Consume a list, and return the same list with a new element at its front
    fn prepend(self, elem: u32) -> List {
        // `Cons` also has type List
        Cons(elem, Box::new(self))
    }

    // Return the length of the list(using recursive call)
    fn len(&self) -> u32 {
        // `self` has to be matched, because the behavior of this method
        // depends on the variant of `self`
        // `self` has type `&List`, and `*self` has type `List`, matching on a
        // concrete type `T` is preferred over a match on a reference `&T`
        // after Rust 2018 you can use self here and tail (with no ref) below as well,
        // rust will infer &s and ref tail. 
        // See https://doc.rust-lang.org/edition-guide/rust-2018/ownership-and-lifetimes/default-match-bindings.html
        match *self {
            // Can't take ownership of the tail, because `self` is borrowed;
            // instead take a reference to the tail
            Cons(_, ref tail) => 1 + tail.len(),
            // Base Case: An empty list has zero length
            Nil => 0
        }
    }

    // Return representation of the list as a (heap allocated) string(using recursive call)
    fn stringify(&self) -> String {
        match *self {
            Cons(head, ref tail) => {
                // `format!` is similar to `print!`, but returns a heap
                // allocated string instead of printing to the console
                //println!("st: {}, {}", head, tail.stringify());
                let ret: String = format!("{}, {}", head, tail.stringify());
                println!("{:?}", ret);
                ret
            },
            Nil => {
                format!("Nil")
            },
        }
    }
}

fn main() {
    // Create an empty linked list
    let mut list = List::new();

    // Prepend some elements
    list = list.prepend(1);
    list = list.prepend(2);
    list = list.prepend(3);

    // Show the final state of the list
    println!("linked list has length: {}", list.len());
    println!("{}", list.stringify());
}

コメントにあるように2018年版のRustからは*selfとref tailの*とrefは不要になった(&とrefを推論する)そうで、確かにそう変えてもコンパイルは通ります。となると、fn stringify(&self)も同じように書き換え可能なので、このソースでrefを使う必要はなくなりますが。

        match self {
            // Can't take ownership of the tail, because `self` is borrowed;
            // instead take a reference to the tail
            Cons(_, tail) => 1 + tail.len(),
            // Base Case: An empty list has zero length

 

admin

モジュール化(@Rust)

コードの記述が一個のファイルに収まるケースというのは現実にはほぼないので、モジュール構成が必要になりますが、以下は割と単純なケースになります。

最初は印字する関数print()だけのファイルmod_sample.rsがmain.rsと同じディレクトリに存在しています。

<mod_sample.rs>

pub fn print(arg: &str) {
    println!("{}", arg);
}

呼び出される関数はpublic(pub)でないとコンパイルエラーになります。

呼び出し側は、

<main.rs>

mod mod_sample;

fn main() {
    use crate::mod_sample::print;
    let msg = "hello";
    print(&msg);
}

Rustの場合にはmain.rs(バイナリクレートが複数あればそれぞれに)にmod文で呼び出すクレート名(mod_sample)を指定しておきます。use文はクレートの短縮形を指定しているだけで、本質ではありません。

一番シンプルにはこれだけですが、実際には呼び出される側が階層構造になっているケースが多いだろうと思われます。例えば以下のようなディレクトリ構成で、

ここで新たに現れるファイルがmod.rsで、これはこの名前でないとモジュールの検索ができません。

mod.rsの中身は他のクレートを定義しているだけですが、mod.rs経由でここで大義されたクレートを呼び出すわけです。呼び出されるmod_sample.rsには変更は不要です。

<mod.rs>

pub mod mod_sample;

クレートファイルが複数存在する場合にはそれらを列挙、最後にmain.rsにも変更が入ります。階層構造のルートディレクトリ名を指定するようにします。

<main.rs>

mod libra;

fn main() {
    use crate::libra::mod_sample::print;
    let msg = "hello";
    print(&msg);
}

 

admin

 

デストラクト(@Rust)

デストラクト(destructuring)は紛らわしいのですが、Rustの変数がスコープを外れた時に廃棄されるデストラクター(destructor)とは別物です。

ではデストラクトとは何かというと、

https://exercism.org/tracks/rust/concepts/destructuring

に記載あるように、タプルや構造体の要素の初期化です。

About Destructuring

Destructuring is the process of breaking down items into their component parts, binding each to smaller variables.

例えばタプルの初期化ならば、

Destructuring Tuples

Destructuring tuples is simple: just assign new variable names to each field of the tuple:

let (first, second) = (1, 2);

というふうに、機能的にはJavaScriptの分割代入 (Destructuring assignment) 構文と同じに見えます。

Rust by exampleでは、

https://doc.rust-lang.org/stable/rust-by-example/flow_control/match/destructuring.html

が公式ドキュメントです。

 

admin

構造体リテラル更新記法におけるString型(@Rust)

構造体のインスタンス作成時に、すでに作成済みのインスタンを使用するということですが、以下の例でdivの型をString型とするとコンパイルが通りません。

何故なら、divをString型にするとemp2で..emp1でdivを使用した瞬間に所有権がemp1からemp2に移動してしまうためです。数値はプリミティブ型なのでそのようなことは起きないのですが。

#[derive(Debug)]
struct Employee<'lt> {
    name: String,
    age: u8,
    grade: u8,
    div: &'lt str,
}

fn main() {
    let div: &str = "sales";
    let emp1 = Employee{name: String::from("John"), age: 30, grade: 3, div: div};
    let emp2: Employee = Employee{name: String::from("Bill"), age: 25, ..emp1};
    println!("{:?}, {:?}", emp1, emp2);
}

つまり構造体でフィールドとして参照を持つ場合、参照フィールドには必ずライフタイムが必要ということです。

以下のようにstatic宣言にしてプログラム実行中のライフサイクルにしても良いですが、永続的なライフタイムを持つすなわちメモリをずっと占有してしまいます。

struct Employee {
    name: String,
    age: u8,
    grade: u8,
    div: &'static str,
}

Rustでは所有権にまつわる規則がどこかで必ず現れてきます。

 

admin

 

 

電源オンオフスケジュール用のGUIがある時点から無くなってる(MacBook)

昔の設定がMacOSのアップデートで設定が引き継がれていただけですが、以前はGUIでリブート設定していたものが、今はコマンドラインで設定するように変わっていた。ずっと変えてなかったから気づいていなかったけど。

pmsetコマンドで現在の設定を見てみると、

@MacBook-Pro ~ % pmset -g sched
Repeating power events:
restart at 5:00AM every day

こんな感じになっているから、最後の行のパラメータをpmsetコマンドで打ち込めばいいんだろう。使い方は、

% man pmset

で見れます。

 

admin

 

 

 

マイクラEEでmaze

maze(迷路)の作成アルゴリズムには色々ありますが、一番単純なアルゴリズムが棒倒し法です。棒倒し法のアルゴリズムは他で参照していただくとして、それをマイクラEE(教育エディション)で実装してみます。bedrock版でもプラグイン使うとMakecodeと連携できるようですが、マイクラEEではデフォルトでcode builder(中身はMakecodeと同じに見えます)が使えますからエージェントに迷路を作成させてみます。

いきなりですが、作成した画像は、

こんな感じです。

動画版は、

code builderのソースは以下のリンクから、

https://minecraft.makecode.com/88632-58071-51947-80905

① 初期化処理(『最初だけ』)で周りの囲いと一つおきに棒(以下ブロック)の配置をするための配列(リスト)を作成、リストを二つ作るのはブロックの重複置きチェックのために倒したブロックの配置を記憶しておくためです

② チャットコマンド”maze”を入力したときに、最初に枠と棒倒しの基準になるブロックを置き、次に迷路作成のための”make_wall”を呼び出しています

③ make_wall中では最初のブロックと二番目以下のブロックでは倒せる方向の可能性が違うので、引数で処理を分けて実際の棒倒し処理(“random_block”)を呼び出します。

④ random_block中では乱数で倒す方向を決めて、もし倒す方向に既にブロックが存在していれば、他の倒し先を乱数で決定して倒しますが、この処理も最初のブロック列と二番目以下のブロック列では処理が異なるのでロジックを分けて記述必要です

簡単に書くとこのような処理を行なっていますが、code builderのブロック言語でそこそこ長いコードを記述すると、コードの見通しが良くないので、実際のロジックの検証はPythonあるいはJavaScriptに展開されてコードで行うのが現実的。あとデバッグ機能のようなものも存在しないのでそこが不便なのと、変数のスコープがいまいちすっきりしないので、関数へはsize(正方形のサイズ)以外は引数渡しにしてローカル変数のごとく使っています。

これ以上に複雑なmazeロジックの記述はおそらく大変、

 

admin

 

ホバークラフト(浮上力向上させた)

発泡丼では空気室の面積が不足で、浮上力が思ったように出ないから、電池電圧が低下すると浮き上がらない。

対策は設置面積を増やすことですが、あまり大きすぎると重量制約も出てくるだろうから、ホームセンターで発泡板を上質紙で挟んだ軽量のボードを買ってきて組み込み。

組み上げるとこんな感じ、

スカート用の素材に使えそうなもの(テープ付き養生シート)があったので、それを貼り付けます。ただしスカートが開かないように左右を紐で抑えるため両面テープで貼り付け。x/y方向でそれぞれ3本づつ使いました。

動かしてみているところ、

マイムービー – SD 480p

 

回転モーメントが発生しているようで、自然にUFOのごとく自転しています。おそらくモーターの回転数がアンバランスではないかと思われますが。

ようやくスタートポイントといったところですね、

P.S. 2024/2/2

回転の原因はモーターの回転数変えてみて、回転数が支配的ではなくて、傾いて取り付けられていることによる横方向の力がおそらく原因。したがって取り付け角度のコントロールが必要ですが、構造作り替え必要です。横方向の力が働くので、回転すると同時に移動も発生していると思われます。

 

admin

Volumio2でSpotifyのプラグインを使う

SpotifyをPremiumプランにしたので、Bluesound Node(Spotify connectが実装されている)だけでなく、Volumio2(raspberry pi zero)でSpotifyのプラグインを使って音出ししてみた。

Spotifyを再生するだけならAirPlayでもいいですが、当然ですが音質は落ちます。

Spotify connectを使うと音楽ファイルをWi-Fiで飛ばすことなくVolumioから直接Spotifyの音源を取り込むので音質的にはベストです。

インストールは簡単で、プラグインメニューでVolumio Spotify Connectをインストールしてアクティブにすると、

Spotifyのアプリ画面からVolumio2(そういう名前にしてます)が追加されるので、

Volumio2に切り替えれば、あとはブラウザから演奏中の曲情報が見えます。

 

CD qualityで再生されています。一点気になるのはゲインが固定ではなくて可変できてしまうことでしょうか。–> プラグイン入れる前からそうなってただけ

BluOSからアクセス(プレイ)するとSpotify connectがNodeに切り替わるので当然コントロールは排他的です。

改めてVolumioは優秀なソフトです。I2S DACは、

https://www.allo.com/sparky/miniboss-rpi-zero.html

を使ってます。

P.S. 気づき(2024/1/24)

① アルバムの途中で中断して、再度のSpotify connect後に新たなアルバムをプレイすると、ブラウザ上には旧いアルバムの表示がされて、次の曲が始まった時点で新たなアルバムに切り替わり

② Volumioの再生を二十分(仕様は10分?)ぐらい停止するとSpotify connectは切断されます

 

admin

ホバークラフト(レビュー)

ちょっと触ってみた感触ですが、

① 電池電圧が満充電状態ではおよそ4.1V程度あってモーターの風量も多いけれども、3.9Vぐらいになると明らかに浮力が落ちる

② 本体の重量測ると207g程度で電池が二個で35g、合計でおよそ240gだから、Telloのほぼ3倍の重量だから結構重い

③ ファンの空気の抜けがイマイチの感

ファンとモーターの取り付けのV2設計図ですが、ドローンも概ねこんな感じだから作り替えが必要と思う。

④ 9軸センサーなしではやはり姿勢制御は辛い、micro:bitで使えそうなのは回転をコントロールできる方角センサーだけだろうから

 

垂直方向がないだけで、実質はほぼドローンと類似の制御が必要ということだろうから、V2の設計を始めてみるか。

 

admin