Skip to content

Instantly share code, notes, and snippets.

View kubo39's full-sized avatar
💭
I may be slow to respond.

Hiroki Noda kubo39

💭
I may be slow to respond.
View GitHub Profile
@elkel53930
elkel53930 / log_with_fram.md
Last active December 7, 2023 16:03
マウス走行中のログをFRAMに保存する話

この記事は「マイクロマウスアドベントカレンダー2023」7日目の記事です。

昨日は笹谷禎伸さんの金沢の魅力とマイクロマウスでした。金沢行きたいです。そしてステッピングモーターでコンパクトなマイクロマウスを作るのすごい。

マウス走行中のログをFRAMに保存する話

この記事ではESP32S3とRustで、マイクロマウスの走行中のログをI2C接続のFRAMに保存する方法について述べようと思います。

ここでいうログとは、センサの値などを時系列で保存したものではなく、メッセージの形で書かれたログのことを言います。 たとえば、探索走行中に左右前の壁の有無と判断した進行方向のログを以下のような形で残すことを考えています。

Looking into the Future

futures-rs is the library which will hopefully become a shared foundation for everything async in Rust. However it's already become renowned for having a steep learning curve, even for experienced Rustaceans.

I think one of the best ways to get comfortable with using a library is to look at how it works internally: often API design can seem bizarre or impenetrable and it's only when you put yourself in the shoes of the library author that you can really understand why it was designed that way.

In this post I'll try to put down on "paper" my understanding of how futures work and I'll aim to do it in a visual way. I'm going to assume you're already somewhat familiar with Rust and why futures are a useful tool to have at one's disposal.

For most of this post I'll be talking about how things work today (as of September 2017). At the end I'll touch on what's being proposed next and also make a case for some of the changes I'd like to see.

If you're interested in learning more ab

@lattner
lattner / TaskConcurrencyManifesto.md
Last active July 18, 2024 08:31
Swift Concurrency Manifesto
@briansmith
briansmith / how-to-generate-and-use-private-keys-with-openssl-tool.md
Last active April 11, 2024 17:02
How to generate & use private keys using the OpenSSL command line tool

How to Generate & Use Private Keys using OpenSSL's Command Line Tool

These commands generate and use private keys in unencrypted binary (not Base64 “PEM”) PKCS#8 format. The PKCS#8 format is used here because it is the most interoperable format when dealing with software that isn't based on OpenSSL.

OpenSSL has a variety of commands that can be used to operate on private key files, some of which are specific to RSA (e.g. openssl rsa and openssl genrsa) or which have other limitations. Here we always use

@sile
sile / 0_succ_bp.md
Last active June 26, 2024 12:38
簡潔データ構造やBalancedParenthesesの紹介資料メモ

発表資料メモ: 簡潔データ構造について

  1. 主題

  • 数千万オーダーの文字列集合(およびマップ)を如何にサイズ効率良く表現するか、の話
    • 諸事情で集合をメモリ上に保持したいことがあるが、サイズは節約したい
    • 実際にはサイズのみを追求するのではなく、諸々のトレードオフを加味しつつバランスを取る
  • 今回はそれを実現するための方法の一つである 簡潔データ構造 について説明する:

MIPSのABIは変だという話をこないだのシステムプログラミング会でしたら、ややザワッとしたので、なにがおかしいのかというのをちょっとまとめてみました。まとめてみて思いましたが、やっぱりMIPSのELFファイルはちょっと変です。

謎のmixed endianフィールド

これが僕は一番ひどいと思ったものです。

ファイルにマルチバイトの数値を保存するときはエンディアンというものが問題になります。たとえば0xBEEFという2バイトの数を保存するときは、1バイト目にBE、2バイト目にEFを書くか、逆順で書くかは、ただの決まり事でどっちでもいいわけですが、書く側と読む側で認識があっていないと困ります。世の中的にはリトルエンディアン(下位バイトから書く)のが主流ですがビッグエンディアンなシステムもあります。

それがですね、MIPSのELFヘッダのr_infoという64ビットのフィールドはリトルエンディアンでもビッグエンディアンでもない謎なエンコーディングになっています。具体的には下位32ビットが最初にリトルエンディアンで書かれていて、ビッグエンディアンでエンコードされた上位32ビットがそれに続くという構成になっています。つまりリトルエンディアンだとABCD EFGH、ビッグエンディアンだとHGFE DCBAとなるところが、MIPSのmixed endianだとEFGH DCBAというふうにファイルに書かれていることになります。

go 1.1 scheduler

where

src/pkg/runtime proc.c asm_*.s

design

@mala
mala / safari-like-cookie-policy-is-too-bad.md
Last active July 11, 2019 05:36
Firefox 22のCookieに関するポリシー変更(予定)についての意見書