lifthrasiir

There are some intertwined concepts in Rust module system:

• Visibility
• Physical file path
• Logical module path

One should note that these three concepts are completely independent to others. While rustc automatically infers the physical file path from the logical module path, it is just for the convenience and you can always override this behavior with #[path] attribute.

lifthrasiir

What the hell is this

Read is intended to be a counterpart to the standard std::fmt library: it parses values out of the string instead of formatting the string out of values. It (mostly) shares the same formatting syntax as std::fmt.

Warning: This is a library design and yet to be implemented.

Read trait

lifthrasiir

#!/bin/bash
# A script for downloading and extracting the official Rust nightly
# Written by Kang Seonghoon, put in the public domain. No warranty.
#
# LOCALRUST should be set to a directory to hold all Rust-related files
# including  `bin`, `lib` etc. Since the script tries to erase all files
# and extract new files, LOCALRUST should be dedicated to this purpose only
# (i.e. do not set it to `/usr/local` or similar, you've been warned).
#
# The script will create `update-rust.last` file to track the most recent update.

lifthrasiir

running 33 tests
test codec::japanese::eucjp_tests::bench_decode_short_text                     ... bench:      5431 ns/iter (+/- 59) = 111 MB/s
test codec::japanese::eucjp_tests::bench_encode_short_text                     ... bench:      7007 ns/iter (+/- 18) = 128 MB/s
test codec::japanese::iso2022jp_tests::bench_decode_short_text                 ... bench:      7380 ns/iter (+/- 41) = 86 MB/s
test codec::japanese::iso2022jp_tests::bench_encode_short_text                 ... bench:      9415 ns/iter (+/- 24) = 95 MB/s
test codec::japanese::windows31j_tests::bench_decode_short_text                ... bench:      6588 ns/iter (+/- 14) = 91 MB/s
test codec::japanese::windows31j_tests::bench_encode_short_text                ... bench:      8354 ns/iter (+/- 26) = 107 MB/s
test codec::korean::windows949_tests::bench_decode_short_text                  ... bench:      6482 ns/iter (+/- 82) = 98 MB/s
test codec::korean::windows949_tests::bench_encode_short_text                  ... bench:      8592 ns/iter (+/- 13

lifthrasiir

• E = Emerald
• Some redundant dummy entries have been omitted

Building Blocks

• 32 Cobblestone (1/2 stack) → 1E
• 1E → 8 End Stone
• 1E → 12 Hardened Clay
  • As opposed to: 48 Clay + fuel → 12 Hardened Clay
• 1E → 8 Packed Ice

lifthrasiir

Sonorous 스킨 시스템

어떻게 작동하는가

Sonorous에서 변경 가능한 내용은 미리 지정된 훅(hook)을 통해 그려진다. 훅은 크게 블록 훅(block hook)과 스칼라 훅(scalar hook)으로 나뉜다. 블록 훅은 특정한 요소를 미리 지정된 조건에 따라 0번 이상 그리는데, 이를테면 특정 조건이 만족될 때만 요소가 보이거나(예: BGA가 있으면 BGA를 보여 준다), 조건에 따라 다른 요소를 보여 주거나(예: 제목이 있으면 제목을 보여 주고 없으면 "제목 없음"이라고 표시한다), 임의 길이의 목록을 보여 주거나(예: 곡 목록) 하는 용도로 쓰인다. 스칼라 훅은 문자열(예: 곡 제목)이나 숫자(예: 곡 레벨), 텍스쳐(예: 배너 이미지) 등을 반환한다. 일반적으로 블록 훅 안에서는 안에서만 의미가 있는 다른 블록 훅이나 스칼라 훅을 쓸 수 있게 된다.

Sonorous 스킨 시스템은 화면에 무언가를 그릴 때마다 클리핑 사각형(clipping rectangle)이라는 걸 관리한다. 이건 두 가지 용도로 쓰이는데 일단 상대 위치를 절대 위치로 바꾸는데 사용한다. 어느 요소가 사각형으로 구성되어 있는데 그 안에 다른 요소가 있으면 둘 다 절대 위치로 쓸 수도 있지만 바깥 요소에 해당하는 클리핑 사각형을 설정해서 다른 요소를 그 사각형을 기준으로 좌표를 지정하면 편리할 수도 있다. 또한 만약 클리핑 사각형이 충분히 작아져서 아무리 그리려고 해도 아무 것도 그릴 수 없게 된다면 더 그릴 게 남아 있어도 계속 진행할 이유가 없으므로 거기서 멈추는 역할도 한다. 둘을 종합하면 목록 같은 걸 유연하게 표시하는 용도로 쓰일 수 있다.

이제 이런 화면을 만들고 싶다고 하자:

lifthrasiir

target
doc

lifthrasiir

// This file is part of rgtk.
//
// rgtk is free software: you can redistribute it and/or modify
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// rgtk is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the

lifthrasiir

09:25:37 < duncan> i know i am just doing something stupid, but I am getting a confusing error message trying to implement the Iterator trait: http://is.gd/48ZeJk
09:26:12 < duncan> on the same line, I get 2 opposing errors: "error: wrong number of lifetime parameters: expected 0, found 1" "error: wrong number of type arguments: expected 1, found 0"
09:26:24 < duncan> same line, same column
09:26:42 < Yurume> duncan: Iterator accepts a type parameter, not a lifetime parameter.
09:26:55 < Yurume> maybe you want `impl Iterator<uint> for ...`

13:54:50 < derek_c> I want to iterate through a Vec and remove the first element that satisfies a certain condition.  how may I do so?
13:56:16 < Yurume> derek_c: vec.remove(vec.as_slice().iter().position(|&e| ...).unwrap())

14:23:54 < bananasaur> if i don't need custom syntax is there any benefit to a macro over just inlining a function?

lifthrasiir

The terms safe and unsafe are used for many related but slightly differing meanings in Rust.

1. The provable memory safety: The compiler can prove that the code does not (or, cannot) violate the memory safety. Here the memory safety refers to the absence of access to the non-allocated or invalid pointers and the absence of dangling (allocated-then-never-deallocated) pointers.
2. The memory safety: The code does not violate the memory safety. The compiler may or may not be able to prove that.
3. The behaviorial safety: The code does not violate the user's expectation. The exact definition may vary, but this includes the memory safety, no unexpected integer overflows, no unexpected out-of-bounds condition, and so on.

Rust provides the provable memory safety, and allows users to mark the code with non-provable memory safety as unsafe. Rust in general does not provide a strict mechanism to eliminate the behaviorial unsafety, but both the standard library and 3rd-party library writers are *recomm