一つ前へ
2013年12月(中旬)
一つ後へ
2014年1月(上旬)
大晦日。アレ。 8時過ぎに国際展示場前駅に到着。 駅でトイレ寄ろうと思ったら行けず。 夏もそうだったのだけど夏は待機場所までの仮設トイレで用を足せたのだけど 今回は仮設トイレもえらい行列で断念。 で、会場に入って真っ先に行ったのはトイレだったりw
この開場待ちの行列を見ていると、いっつもサンデル先生の白熱教室を連想してしまうのでした。 数日前にも放送がありましたし NHK 白熱教室。で、 評論やらコンピュータ関係が集まってたのは西だったのでそちらから行って、 後で東へ移動したのですがこれが大混雑。 よくtwitterでザボーガーバイクの写真がでてくる ＧＲＵＭＭＡＮＡ＆ＡＭＰの詳細 | Comike Web Catalog こことか行けなかった。 そしてトドメ。 Colorful Pieces of Game::どひゃー完売しちゃいましたが… Colorful Pieces of Game::すまん・・・マジで完売した('A`) 二日めいっとくんだった○|￣|＿
どうしてこうなった
会場で一枚。
グラム量り売り&円周率詠唱一桁一円割引実施中の暗黒通信団にて、円周率詠唱600桁を達成して本の代金580円から差引代金GETしてる方がいたww 周囲からは拍手がww #c85
— 体温乃風 (@E_X_ILE) 2013, 12月 31見たかった。
【再々掲】量子コンピュータについて解説した本を出します。エ−26b「猫耳官邸」さんに委託です。4つの力ヴィジュアルデータブックも一緒について300円です。よろしくお願いします。 #c85 http://t.co/0vnCkmTC4N http://t.co/PRvuaXuetf
— 蟷螂 3日目エ−26b(委託参加) (@kamakiri_ys) 2013, 12月 30場所が場所だったので行けず○|￣|＿
「いやぁ、こんな時代が来るとはね」
「さっき、赤城さんだっけ？それのコスプレした女の子が本買いに来たよ」
「一年前じゃ空母の話女の子に振ったらドン引きですよね」
「いい時代になったよ」
太平洋戦争戦史系サークルにて
#C85 #艦これ
— 牛乃介@歯抜けジジイ (@gyuunosuke) 2013, 12月 31↑この会話、生で聴いてた :)
2014年予測というか興味があるもの。
・Elixir
なんかいつの間にか三冊も出版予定があるし(すでに Early Release で(部分的に)読めたりしますが)、
Dave Thomas も
The Pragmatic Bookshelf | Read Our Magazines
で記事を書いていたりしたので見ておいて損はないのかなあと漠然と思ってたりします。
Programming Elixir: Functional - Concurrent - Pragmatic - Fun
Introducing Elixir － O'Reilly Media
Manning: Elixir in Action
・Rust
Go がちょっと抜け出してる感はあるんですが、競争相手はいても良かろうと
(D とか C++ はよくわかりません)
Rust is surprisingly expressive | Hacker News
Rust is surprisingly expressive
HNSearch - Hacker News Search
・Oberon
これはプログラミング言語だけでなくそれを含むシステム全体の話なんですが
Wirth 先生ですからして
Project Oberon - The Design of an Operating System, a Compiler, and a Computer (New Edition 2013) : programming
↑また言語ばかりだなw
・Green Array
Programming a 144-computer Chip to Minimize Power
の話に出てきたやつです。
・unreliable chip
How to program unreliable chips - MIT News Office
一言で説明するのは面倒なんですが面白そうだなあと。
つらつらと幾つか挙げましたが Elixir を除けば2014年中に大きな動きはあるとは あまり思えませんし、「大穴」狙いってところですね。
特に変わったこともせず2013年分〆。
まとめません。
コンビニにあったコピー機の「プレビュー画面」について。 片面二枚を両面一枚にまとめるコピーをしようとしたんですね。 で、こいつ「プレビュー」機能を持ってたんですよ。 スキャンした結果が小さい画面にだけど出してくれるという。 んで、まず一枚目を 向かって左側がA4縦の天が左に来るようにセットしてスキャンさせたのですが プレビュー画面には右に天が来ているように表示されている… あれ、天地逆にセットしちゃったかなと思い二枚目を天が右に来るようにして スキャンさせると、プレビュー画面では左側に天が! 紙を伏せて置いたのと、印刷方向やスキャン方向を考えると こういう表示になるのが自然になのかもしれないけどびっくりしたわw
まあADFつきならこんな心配しないでいいんですけどねー 「ADF」とは：パソコン関連用語の意味・解説
なんでこの時間になっても巡回先が増えるのよー○|￣|＿
最近Cのポインターに関する本が出たり記事を見かけたりが多いような Pointers and Memory
Pointers and Memory Pointers and Memory Stanford CS Education Library: a 31 page introduction to programming with pointers and memory in C, C++ and other languages. Explains how pointers and memory work and how to use them -- from the basic concepts through all the major programming techniques. Can be used as an introduction to pointers for someone with basic programming experience or as a quick review. Many advanced programming and debugging problems only make sense with a solid understanding of pointers and memory -- this document tries to provide that understanding.
ということであとで読む
巡回の最終チェックがーーーー
すでに2014年のノート(モレスキン)に予定を幾つか書いてたりしているわけで。
MOLESKINE モレスキン 2014年 限定版 スターウォーズ スケジュール+ノート / ハードカバー / ラージ
ソフトウェア品質の経済的側面
書店で見かけたのでぱらぱらと眺めたんだけどなかなか面白そう。
とはいえ先立つものがー
↓もあるしー
現物を見た。
確かに大きい、厚い、重い。
なんだけど欲しいっちゃ欲しい。
つーても電書向きの読み方しかしないだろうしなあ…
アルゴリズムイントロダクション 第3版 総合版 (世界標準MIT教科書)
そして謎の巡回リストを作成中。
だいぶまえの記事ですが An Overview of Memory Management in Rust - pcwalton
An Overview of Memory Management in Rust
One of the key features of Rust that sets it apart from other new languages is that its memory management is
manual—the programmer has explicit control over where and how memory is allocated and deallocated. In this
regard, Rust is much more like C++ than like Java, Python, or Go, to name a few. This is an important design
decision that makes Rust able to function in performance-critical domains that safe languages previously
haven’t been able to—top-of-the line games and Web browsers, for example—but it adds a nontrivial learning
curve to the language.
他の新言語と Rust とを区別する key features のひとつは、Rust のメモリー管理が手動であるという点です。
プログラマーはメモリー割り当てや解法を行う場所とその方法を explicit に control します。
この点に関して、Rust は Java や Python、Go といったものよりは C++ のようなプログラミング言語により近いものです。
これは、Rust をたとえばゲームや Webブラウザーといった safe Languages が機能できないような performance-critical
な domain で機能できるようにするための重要な設計上の意志決定 design decision です。
しかしそれは nontrivial な学習曲線 learning curve をこの言語に与えたのです。
For programmers familiar with modern C++, this learning curve is much shallower, but for those who are used to
other languages, Rust’s smart pointers can seem confusing and complex. In keeping with the systems-oriented
nature of Rust, this post is designed to explain how Rust’s memory management works and how to effectively
use it.
modern C++ に馴染んだプログラマーにとっては、この学習曲線は much shallower ですが、
他の言語を使っているプログラマーにとっては、Rust の smart pointers は複雑で混乱するものかもしれません。
本記事は Rust がsystems-oriented な性質を保つ上で、Rust の memory management がどのように動作していて、
それがどのくらい effectively なのかの説明を試みるものです。
Smart pointers 賢いポインター
In many languages with manual memory management, like C, you directly allocate and free memory with calls to
special functions. For example:
C のような manual memory management を行っている多くの言語では、特別な関数を呼び出してメモリー割り付けや解放を
行います。例を挙げましょう
void f() {
int *x = malloc(sizeof(int)); //ヒープ上に int 一つ分のスペースを割り付ける
*x = 1024; //値を初期化する
printf("%d\n", *x); //スクリーンに出力
free(x); //メモリーを解放してヒープに戻す
}
C gives you a great deal of control over where memory is allocated and deallocated. Memory is allocated with a
special function malloc, and it is freed with a special function free. After the call to free, it is an error
to attempt to use x, as it is a dangling pointer. A dangling pointer points to invalid memory, but the C
compiler makes no attempt to prevent you from using it; it’s your responsibility to avoid touching it after
freeing the memory it points to.
C はメモリーの割り付けと解放に関してあなたに great deal of control を与えています。メモリーは malloc という特殊な
関数により割り付けられ、そして free という特殊な関数を使って解放されます。free を呼び出した後で dangling
pointer となっている x を使おうとすると、エラーになります。dangling pointer は invalid memory を point してい
ますが、C コンパイラーはそれを使ってしまうことを防ごうとはしません。メモリーを解放した後でその場所へアクセスし
てしまうのを避ける avoid のはあなたの責任 your responsibility です。
Rust gives you the same level of control over memory, but it works somewhat differently. Let’s see how the
same piece of code looks in Rust:
Rust はそれと同レベルの control over memory をあなたに与えます。
しかし、C とは異なった動作をします。
Let's see how the same piese of code looks in Rust:
fn f() {
let x:~int=~1024;
println(fmt!("%d", *x));
} // <-- the memory that x pointed at is automatically freed here
x が指しているメモリーはここで自動的に解放される
There are three main differences to notice here:
ここで、注意すべき main differences が三つあります。
1．In C, you allocate memory first (with the call to malloc), and then you initialize it (in the example
above, with the *x = 1024 assignment). Rust fuses the two operations together into the ~ allocation
operator, so that you don’t accidentally forget to initialize memory before you use it.
C では最初に (mallocを呼び出して) メモリーを割り付け、それから初期化を行います (先ほどの例で言うと *x=1024
の代入です)。Rust はこれら二つの operations をひとつの ~ という allocation operator に fuses しました。
そのため、使用前のメモリーの初期化をうっかり忘れてしまうようなことはありません。
2. In C, the call to malloc returns a plain pointer, int *. In Rust, the ~ operator, which allocates memory,
returns a special smart pointer to an int. Because this type of smart pointer is so common, its name is
just a single character, ~—thus the type of this smart pointer is written as ~int.
C では呼び出された malloc は plain pointer である int* を返します。一方 Rust の ~ operator は int に対す
る特別な smart pointer を返します。smart pointer はとても一般的なので、名前が一文字の ~ になっています。
したがって、この smart pointer の型は ~int のように記述します。
3．You don't call free manually in Rust. Rather, the compiler automatically frees the memory for you when a
smart pointer goes out of scope.
Rust では manually に free を呼び出すことはありません。それどころか Rust コンパイラーは smart pointer が
スコープから外れたときにあなたに代わってメモリーを自動的に free してくれるのです。
As it turns out, points (2) and (3) are very intertwined, and together they form the cornerstone of Rust’s
memory management system. Here’s the idea: Unlike C, allocation functions in Rust don’t return a raw pointer
to the space they allocate. Instead, they return a smart pointer to the space. A smart pointer is a special
kind of value that controls when the object is freed. Like a raw pointer in C, you can access the data that a
smart pointer refers to with *. But unlike a raw pointer, when the smart pointer to an allocation goes out of
scope, that allocation is automatically freed. In this way, smart pointers are “smart” because they not only
track where an object is but also track how to clean it up.
As it turns out, (2) と (3) は非常に関連が強いもので、共に Rust の memory management system の corner stone
を形成しています。考え方はこうです: C とは異なり、Rust における割り当て関数は自身が割り当てたスペースを指す
raw pointer を返しません。返すのはそのスペースを指す smart pointer です。smart pointer はオブジェクトがいつ
freeされるかを制御している special kind of values です。C の raw pointer 同様、smart pointer も * を使ってデ
ータにアクセスできます。しかし raw pointer と異なるのは、smart pointer が割り当ての行われたスコープから外れた
ときに、その割り当てが自動的に解放されるという点です。In this way, smart pointers は “smart”です。
なぜなら、それらのpointers はオブジェクトの位置だけでなくどのようにしてclean up するのかも track しているから
です。
Unlike C, in Rust you never call free directly. Instead, you rely on smart pointers to free all allocations.
The most basic reason for this is that smart pointers make it harder to forget to free memory. In C, if you
forget to call free, you have a memory leak, which means that the memory will not be cleaned up until the
program exits. However, in Rust, the compiler will automatically insert the code necessary to free the memory
for you when the smart pointer pointing to your data goes out of scope.
C とは異なり、Rust では free を直接呼び出すことは決してありません。
その代わりに、すべての allocation をいつ free するかを smart pointers に任せられるのです。
The most basic reason for this は、smart pointers が memory のfree を忘れてしまわないようにするからです。
Cの場合、free を呼び出すのを忘れてしまうとメモリーリークが生じ、
プログラムが存在している間そのメモリーは clean up されないということになります。
しかしながら Rust では、smart pointer がスコープを外れるときに
それが point しているデータを free するのに
必要なコードをコンパイラーが automatically に insert します。
Rust has multiple types of smart pointers, corresponding to the different strategies that programs use to
reclaim memory. Some smart pointers, namely ~ and @ (which we will cover shortly), have special names known to
the compiler, because they’re so common. (Having to type long names like unique_ptr all the time would be a
burden.) Other smart pointers, such as ARC (which allows you to share read-only data between threads), are in
the standard library and are not built into the compiler.
Rust には、プログラムがメモリーを得るために使用する個別の戦略に対応している
複数の型のsmart pointer があります。
一部の smart pointer はそれがとても一般的 so common だという理由で、
コンパイラーに知らせる ~ や @ のような (短く書ける) special names を持っています
(型指定のために毎回 unique_ptr のような長い名前を書かなければならないのは苦痛です)。
その他の smart pointer、たとえば (複数のスレッド間でread-onlyなデータを共有できるようにする)
ARC のようなものは標準ライブラリの中にあり、コンパイラーに組み込まれてはいません。
The pointer covered above is known as the unique smart pointer ~. We call it “unique” because there is always
only one smart pointer pointing to each allocation. The other type of smart pointer built into the language is
the managed smart pointer, which allows multiple smart pointers to point to the same allocation and uses garbage
collection to determine when to free it. Here’s an example of a managed smart pointer in use:
前述の pointer は unique smart pointer ~ として知られているものです。
わたしたちがそれを「unique」と呼ぶのは、allocation ごとにそれを point している
smart pointer が常にただひとつだけ存在しているからです。
言語に組み込まれているこれとは別の型の smart pointer が managed smart pointer です。
これは same allocation を point しつつ、
free するタイミングをガーベジコレクションに任せるような
multiple smart pointers を可能にします。
managed smart pointer の例を出しましょう:
fn foo() {
lex x:@int=@1024; //ヒープ上にintの領域をallocateしてさらに初期化する
bar(x); //それを'bar'に渡す
println(fmt!("%d", *x)); //スクリーンに出力する
} // ← メモリーをここでfreeできる
fn foo(x:@int){
let y:@int=x; // make a new smart pointer to `x`
} // ← despite `y` going out of scope, the memory is *not* freed here
The key difference between ~ and @ is that @ allows multiple smart pointers to point to the same data, and the
data is cleaned up only after the last such smart pointer disappears. Notice that, in this example, the memory
pointed at by y (which is the same as the memory pointed at by x) is not freed at the end of the function bar,
because x is still in use and also points to the same data. The fact that @ allows multiple smart pointers to
the same data, as well as the fact that the allocation is freed only when all of those pointers go out of
scope, make managed smart pointers very useful. However, they can be less efficient than unique smart pointers,
as they require garbage collection at runtime.
~ と @ の key difference は、@ では same data をpoint する multiple smart pointer を許していて、
最後の smart pointer が disappear したときにのみデータの clean up を行うという点です。
この例ではyによってpoint されている memory (x によって point されている memory と同じもの)は
関数barの終端に来てもfreeされないことに注意してください。
なぜなら y と同じデータを pointしている x がまだ使われているからです。
@が multiple smart pointers to the same data を allow するということは
それらのpointers がすべてスコープを外れたときにのみ
allocation が free されるということと同じく
managed smart pointer をとても便利なものにしています。
しかしながら managed smart pointer は実行時ガーベジコレクションを要求するので
unique smart pointer よりも効率が劣ります。
References
Recall that a smart pointer is a pointer that automatically frees the memory that it points to when it goes out
of scope. Perhaps surprisingly, it often turns out that it’s useful to have a kind of pointer that doesn’t
free the memory that it points to. Consider this code:
smart pointer とは、それがスコープを外れる際に point しているメモリーを automatically に free する pointer で
あったことを思い出してください。おそらく驚かれることでしょうが、point しているメモリーを free しない種類の
pointer があることが便利なことはしばしばあるのです。次のコードで考えてみましょう
struct Dog {
name:~str // a unique smart pointer to a string
}
fn dogshow() {
let dogs:[~dog * 3] = [
~Dog { name : ~"Spot" }, // create an array of Dog objects
~Dog { name : ~"Fido" }, // use unique smart pointers to allocate
~Dog { name : ~"Snoopy" },
];
for dogs.each |dog| {
println
}
} // ← all dogs destroyed here
Suppose that we wanted to single Fido out as the winner of the dog show. We might try this code:
ここで、Fido を dog show の優勝犬として出力したいとしましょう。次のようなコードで試してみるかもしれません
fn dogshow() {
let dogs: [~Dog * 3] = [
~Dog { name: ~"Spot" },
~Dog { name: ~"Fido" },
~Dog { name: ~"Snoopy" },
];
let winner: ~Dog = dogs[1];
for dogs.each |dog| {
println(fmt!("Say hello to %s", dog.name));
}
println(fmt!("And the winner is: %s!", winner.name));
} // ← all dogs, and `winner`, destroyed here fn dogshow() {
But this code won’t compile. The reason is that, if it did, Fido would be destroyed twice. Remember that
unique smart pointers free the allocations they point to when they go out of scope. The code attempts to make
a second smart pointer to Fido at the time it executes the line let winner: ~Dog = dogs[1]; If the compiler
allowed this to proceed, then at the end of the block, the program would attempt to free Fido twice—once when
it frees the original smart pointer embedded within the dogs array, and once when it frees winner.
しかしこのコードはコンパイルされません。
その理由は、もしこれがコンパイルできた (そしてそれを実行できた) とすると、
Fido は二度 destroy されてしまうからです。
unique smart pointer は allocations を free してしまうことを思い出してください。
このコードでは実行時に Fido のために二個目の smart pointer を
let winnner: ~Dog = dogs[1] の行で作ろうとしています。
もしコンパイラーがこの proceed を許したとすると、
ブロックの最後でプログラムは Fido を二度 free してしまうでしょう。
一度は dogs array の中に埋め込まれた original smart pointer を free
するときに。そしてもう一度は winner を free するときに。
What we really want is for winner to be a pointer that doesn’t free the allocation that it points to. In fact,
what we want isn’t a smart pointer at all; we want a reference. Here’s the code rewritten to use one:
わたしたちが本当に望んでいるのは、winner をそれが point している allocation を free しないようにすることで
す。事実わたしたちが望んでいるものは結局のところ smart pointer ではなく、reference なのです。
そして reference を使って書き直したコードが以下のものです;
fn dogshow() {
let dogs: [~Dog * 3] = [
~Dog { name: ~"Spot" },
~Dog { name: ~"Fido" },
~Dog { name: ~"Snoopy" },
];
let winner: &Dog = dogs[1]; // note use of `&` to form a reference
for dogs.each |dog| {
println(fmt!("Say hello to %s", dog.name));
}
println(fmt!("And the winner is: %s!", winner.name));
} // <-- all dogs destroyed here
This code will now compile. Here, we convert winner into a reference, notated in Rust with &.
You can take a reference to any smart pointer type in Rust by simply assigning it to a value with a
reference type, as the let winner: &Dog = dogs[1] line does.
これでこのコードはコンパイルされるようになりました。
ここで、& を使って Rust に note して winner を reference にconvert しました。
Rust では任意の smart pointer type の reference を take することが、
let winner:&Dog = dogs[1] のように
ある値を reference type に代入するだけで可能なのです。
References (also known as borrowed pointers) don’t cause the compiler to free the data they refer to. However,
they don’t prevent the compiler from freeing anything either. They have no effect on what smart pointers will
do; regardless of how many references you have, a unique smart pointer will always free the data that it points
to when it goes out of scope, and a managed smart pointer will always free its data when all managed smart
pointers to the same allocation go out of scope.
(borrowed pointersとしても知られている) references は、それが参照しているデータの free を
コンパイラーにさせることはありません。
しかし、コンパイラーが anything either を free するのを妨げることもしません。
references は smart pointer が持っているような効果を持っていません。
unique smart pointer は、how many references you have に関係なく
それがスコープを外れるときには常に point しているデータを free してしまいます。
一方 managed smart pointer は、
same allocation に対するすべての managed smart pointer が
スコープを外れるときにfreeします。
This is important to keep in mind. Code like this will not compile:
これは心にとどめておくべき重要なことです。
次のようなコードはコンパイルされません。
fn foo() {
let y: ∫
{
let x: ~int = ~2048;
y = x;
} // ← x freed here
println(fmt!("Your lucky number is: %d", *y)); // ERROR: accesses freed data!
}
In languages like C++, code like this could cause faults from attempting to access invalid memory. As it
turns out, however, this piece of code won’t compile—the Rust compiler can and does prevent you from writing
code like this at compile time. Essentially, the Rust compiler tracks where each reference came from and
reports an error if a reference persists longer than the allocation it points into. This means that, generally
speaking, you can use references all you like and have the confidence that they won’t result in
hard-to-diagnose errors at runtime.
C++ のような言語では、こういったコードは invalid memoryにアクセスしようとしたときに faults を引き起こします。
しかしすでに説明したようにこのコードは (Rust では) コンパイルされません。
Rust のコンパイラーはこのようなコードを書いてしまうことをコンパイル時に防止しているのです。
Rust コンパイラーは
reference がそれぞれどこから来たのかを track します。
そして、ある reference が allocation it points into よりも persists longer のときに
エラーを報告します。これはつまり、一般論としては references を
自分が使いたいところならどこでも使うことができるし、
また、references は result in hard-to-diagnose errors at runtime しないような
confidence を有しているということです。
Conclusion 結論
These ideas—smart pointers and references—form the basis of memory management in Rust. If you’re a C++
programmer, most of this will (hopefully!) simply have been an exercise in learning different syntax. For other
programmers, these concepts are likely more foreign. But using these tools, you can write code with
fine-grained control over memory, with improved safety over languages like C.
以上のアイデア、smart pointer とreferences は Rust におけるメモリー管理の基礎をなしているものですが、
あなたが C++ プログラマーであるのなら、その大半はただ単に構文が違っているだけのすでに学んだこと
(できればそうあって欲しいもの) なのです。そうでないプログラマーにとっては、
こういった concepts はさらに外国語に似たものでしょう。しかしこれらの tools を使うことによって、
free-grained control over memory を持ったコードを記述できるし、
また、safety over language C を improve できるのです。
蔵書の苦しみ。という以前買っていた新書が不意に出てきたので読んだ。
蔵書の苦しみ (光文社新書)
これ、kindle版もあったのか。
この種の新書は電書の方がいいかなあ。
とある発表スライドを見ていたら「Bug Hunting」という言い回しが何度も出てきたのでぐぐると
bug hunting - Google 検索
そういやあこういう本ありましたわね。
Bugハンター日記
原著 kindle版も。
Regular Expression(正規表現) Part12 143 デフォルトの名無しさん [sage] 2013/12/28(土) 13:39:07.55 ID: Be: /imsxadlup の /d /l /u の使い方教えて。英語読めないの。 http://perldoc.jp/docs/perl/5.14.1/perlre.pod#47l 146 デフォルトの名無しさん [sage] 2013/12/28(土) 14:19:31.38 ID: Be: >>143 /d この修飾子は、パターンマッチングの際にプラットフォーム固有のロケール（ASCIIなど）を使用するように指示する。 ただし、Unicodeを使うべき理由がある場合はこの設定はそちらが優先される。 この修飾子が具体的にパターンマッチングにどのような変化をもたらすかを以下のサンプルで示した。 /l この修飾子は、パターンマッチングの際に現在のロケール設定を使用するように指示する。 このロケール設定はコンパイル時のロケールと同じであるとは限らず、 setlocale()を用いて任意のロケール設定を用いることができる。 /u この修飾子は、パターンマッチングの際にUnicodeのルールを使用するように指示する。 148 143 [sage] 2013/12/28(土) 15:17:11.45 ID: Be: >>146 おお、ありがとうございます。マジで助かりました。 おかげ様でperl 5.14.1の正規表現ルールを全部覚えられました、感謝～。 149 デフォルトの名無しさん [] 2013/12/28(土) 15:18:54.48 ID: Be: >>148 どういたしまして。
やたらとでてくる (TBT)ってなんだろうと思ったけど、 これ perldoc.jp のページだから翻訳される(予定がある)ってことで、 To Be Translate 辺りってことね。
にしたって、5.14って結構前だよねえ。 Jesse Vincent / perl-5.14.1 - search.cpan.org 2011年6月かな? 手が足らないのかしらん。
perlre - Perl 正規表現 - perldoc.jp Character set modifiers /d, /u, /a, and /l, available starting in 5.14, are called the character set modifiers; they affect the character set semantics used for the regular expression. (TBT) 5.14 から使えるようになった /d /u /a /l は character set modifier と呼ばれるもので、 正規表現で使用する character set semantics に影響を及ぼします。 At any given time, exactly one of these modifiers is in effect. Once compiled, the behavior doesn't change regardless of what rules are in effect when the regular expression is executed. And if a regular expression is interpolated into a larger one, the original's rules continue to apply to it, and only it. (TBT) At any given time, これらの modifier のただ一つだけが有効になります。一旦コンパイルされてしまうと、正規表現が 実行されたときに有効な rule がなんであれその振る舞いが変わることはありません。また、 ある正規表現がより大きな正規表現で interpolate された場合、 original's rules が適用され続けますし, and only it. Note that the modifiers affect only pattern matching, and do not extend to any replacement done. For example, (TBT) これらの modifier はパターンマッチングに対してのみ影響し、replacement には一切拡張されないことに注意してください。 たとえば s/foo/\Ubar/l will uppercase "bar", but the /l does not affect how the \U operates. If use locale is in effect, the \U will use locale rules; if use feature 'unicode_strings' is in effect, it will use Unicode rules, etc. (TBT) これは "bar" を大文字にしますが、/l は \U がどのように operate するかには影響しません。 use locale している場合には ￥U は locale rules を使用します。 use feature 'unicode_strings している場合には Unicode rules を使用します。 /l means to use the current locale's rules (see perllocale) when pattern matching. For example, \w will match the "word" characters of that locale, and "/i" case-insensitive matching will match according to the locale's case folding rules. The locale used will be the one in effect at the time of execution of the pattern match. This may not be the same as the compilation-time locale, and can differ from one match to another if there is an intervening call of the setlocale() function. (TBT) この modifier は current locale の rules (perllocale 参照) を使うよう指示します。たとえば \w はその locale での "word" characters にマッチし、"/i" case-insensitive matching ではその locale の case folding rules に従ってマッチします。実行時の locale はコンパイル時の locale とは異なる可能性があって、intervening call of the setlocale() function が行われた場合には別のキャラクターにマッチしてしまうことがあるかもしれません。 Perl only supports single-byte locales. This means that code points above 255 are treated as Unicode no matter what locale is in effect. Under Unicode rules, there are a few case-insensitive matches that cross the 255/256 boundary. These are disallowed under /l. For example, 0xFF does not caselessly match the character at 0x178, LATIN CAPITAL LETTER Y WITH DIAERESIS, because 0xFF may not be LATIN SMALL LETTER Y WITH DIAERESIS in the current locale, and Perl has no way of knowing if that character even exists in the locale, much less what code point it is. (TBT) Perl は single-byte locale のみをサポートしています。これはつまり、255 を越えたコードポイントは in effect な locale に関係なく Unicode として扱われるということです。Unicode rules の下では、255/256 boundary を跨ぐような case-insensitive なマッチが幾つか存在していますが、それらは /l によって禁止されます。たとえば 0xFF は 0x178 に ある character とは caselessly match しません。なぜなら 0xFF はその current locale において LATIN SMALL LETTER Y WITH DIAERESIS は使えないからです。Perl は current locale においてそういった character が 存在しているかどうかすら知る手段を持っていません。 This modifier may be specified to be the default by use locale, but see "Which character set modifier is in effect?". (TBT) この modifier は use locale したときのデフォルトとなります。 詳細は "Which character set modifier is in effect?" を参照してください。 /u means to use Unicode rules when pattern matching. On ASCII platforms, this means that the code points between 128 and 255 take on their Latin-1 (ISO-8859-1) meanings (which are the same as Unicode's), whereas in strict ASCII their meanings are undefined. Thus the platform effectively becomes a Unicode platform, hence, for example, \w will match any of the more than 100_000 word characters in Unicode. (TBT) この modifier はパターンマッチングの際に Unicode rules を使用させます。つまり、ASCII platfotm においては strict ASCII では meanigs が undined になっている 128 から 255 の間にある code point は Latin-1 (ISO-8859-1) meanings として扱われます (これは Unicode のそれと同じです)。 Thus the platform effectively becomes a Unicode platform, hence, for example, \w will match any of the more than 100_000 word characters in Unicode. Unlike most locales, which are specific to a language and country pair, Unicode classifies all the characters that are letters somewhere as \w. For example, your locale might not think that LATIN SMALL LETTER ETH is a letter (unless you happen to speak Icelandic), but Unicode does. Similarly, all the characters that are decimal digits somewhere in the world will match \d; this is hundreds, not 10, possible matches. And some of those digits look like some of the 10 ASCII digits, but mean a different number, so a human could easily think a number is a different quantity than it really is. For example, BENGALI DIGIT FOUR (U+09EA) looks very much like an ASCII DIGIT EIGHT (U+0038). And, \d+, may match strings of digits that are a mixture from different writing systems, creating a security issue. "num()" in Unicode::UCD can be used to sort this out. (TBT) 大部分の locale とは違い Unicode ではすべての character を \w のような letter と classify しています。たとえば あなたの使っている locale では LATIN SMALL LETTER ETH を letter とはみなしていないかもしれませんが Unicode では letter とみなします。同様に、世界中にある decimal digit すべてが \d にマッチします。つまり、マッチする可能性の あるものが十個ではなく数百個あります。そしてそれらの中には十個の ASCII digit のどれかに見た目が似ているけれども 意味が異なっているので人が見たときに実際の数とは違った数と容易に思い込んでしまうようなものが存在しています。 一例を挙げると、BENGALI DIGIT FOUR (U+09EA) は ASCII DIGIT EIGHT (U+0038) に見た目が非常に似ています。 そして \d は a mixture from different writing systems な strings of digits にマッチしてしまうために sceurity issue を作ってしまいます。 Unicode::UCD にある "num()" はソートするのに使えます。 Also, case-insensitive matching works on the full set of Unicode characters. The KELVIN SIGN, for example matches the letters "k" and "K"; and LATIN SMALL LIGATURE FF matches the sequence "ff", which, if you're not prepared, might make it look like a hexadecimal constant, presenting another potential security issue. See http://unicode.org/reports/tr36 for a detailed discussion of Unicode security issues. (TBT) また、case-insensitive マッチングは Unicode における character 全体に作用します。たとえば KELVIN SIGN は "k" や "K" という letter にマッチし、LATIN SMALL LIGATURE FF は "ff" という並びに マッチします。 which, if you're not prepared, might make it look like a hexadecimal constant, presenting another potential security issue. See http://unicode.org/reports/tr36 for a detailed discussion of Unicode security issues. (TBT) On the EBCDIC platforms that Perl handles, the native character set is equivalent to Latin-1. Thus this modifier changes behavior only when the "/i" modifier is also specified, and it turns out it affects only two characters, giving them full Unicode semantics: the MICRO SIGN will match the Greek capital and small letters MU, otherwise not; and the LATIN CAPITAL LETTER SHARP S will match any of SS, Ss, sS, and ss, otherwise not. (TBT) This modifier may be specified to be the default by use feature 'unicode_strings, but see "Which character set modifier is in effect?". (TBT) /a is the same as /u, except that \d, \s, \w, and the Posix character classes are restricted to matching in the ASCII range only. That is, with this modifier, \d always means precisely the digits "0" to "9"; \s means the five characters [ \f\n\r\t]; \w means the 63 characters [A-Za-z0-9_]; and likewise, all the Posix classes such as [[:print:]] match only the appropriate ASCII-range characters. (TBT) /u とほぼ同じですが、\d、\s、\w および POSIX character class のマッチ対象は ASCII の範囲に制限されます。 つまり、この modifier をつけることによって \d は常に "0" から "9" までの digit を意味するようになり、 \s は [ \f\n\r\t] の五つの character を、\w は [A-Za-z0-9_]; の63個の character を意味するようになります。 また、[[:print:]] のような POSIX class についてもすべて ASCII-range characters だけがマッチの対象になります。 This modifier is useful for people who only incidentally use Unicode. With it, one can write \d with confidence that it will only match ASCII characters, and should the need arise to match beyond ASCII, you can use \p{Digit}, or \p{Word} for \w. There are similar \p{...} constructs that can match white space and Posix classes beyond ASCII. See "POSIX Character Classes" in perlrecharclass. (TBT) この modifier は incidentally にのみ Unicode を使う人にとって有用です。 With it, one can write \d with confidence that it will only match ASCII characters, and should the need arise to match beyond ASCII, you can use \p{Digit}, or \p{Word} for \w. There are similar \p{...} constructs that can match white space and Posix classes beyond ASCII. perlrecharclass にある "POSIX Character Classes" を参照してください。 As you would expect, this modifier causes, for example, \D to mean the same thing as [^0-9]; in fact, all non-ASCII characters match \D, \S, and \W. \b still means to match at the boundary between \w and \W, using the /a definitions of them (similarly for \B). (TBT) おそらく期待しているように、この modifier はたとえば \D を [^0-9]; と等価な意味にします。 つまり、すべての non-ASCII character が \D、\S、\W にマッチします。 \b still means to match at the boundary between \w and \W, using the /a definitions of them (similarly for \B). Otherwise, /a behaves like the /u modifier, in that case-insensitive matching uses Unicode semantics; for example, "k" will match the Unicode \N{KELVIN SIGN} under /i matching, and code points in the Latin1 range, above ASCII will have Unicode rules when it comes to case-insensitive matching. (TBT) それ以外については /a は /u と同じように、Unicode semantics を用いた case-insentive マッチングを行います。 たとえば "k" は /i マッチングの場合には Unicode \N{KELVIN SIGN} にマッチしますし、Latin1 の範囲にあって above ASCII な コードポイントは case-insentive マッチングが必要になった場合には Unicode rule が使われます。 To forbid ASCII/non-ASCII matches (like "k" with \N{KELVIN SIGN}), specify the "a" twice, for example /aai or /aia (TBT) ("k" with \N{KELVIN SIGN} のような) ASCII/non-ASCII マッチを禁じるには /aai や /aia のように "a" を二回指定します To reiterate, this modifier provides protection for applications that don't wish to be exposed to all of Unicode. Specifying it twice gives added protection. (TBT) This modifier may be specified to be the default by use re '/a' or use re '/aa', but see "Which character set modifier is in effect?". (TBT) /d This modifier means to use the "Default" native rules of the platform except when there is cause to use Unicode rules instead, as follows: (TBT) この modifier はその platform の "Default" native rules を使うよう指示しますが、 以下のような Unicode rules を使う理由のある場合は例外です。 ターゲット文字列が UTF-8 でエンコードされている; または パターンが UTF-8 でエンコードされている; または パターンが、(\x{100} のような形で)255 を超える符号位置に明示的に言及している; または パターンが Unicode 名 (\N{...}) を使っている; または パターンが Unicode 特性 (\p{...}) を使っている Another mnemonic for this modifier is "Depends", as the rules actually used depend on various things, and as a result you can get unexpected results. See "The "Unicode Bug"" in perlunicode. (TBT) もう一つの mnemonic for this modifier は、実際に使用している rules に様々な状況で依存しているので 期待したのとは異なる結果が得られてしまう可能性があるということです。 On ASCII platforms, the native rules are ASCII, and on EBCDIC platforms (at least the ones that Perl handles), they are Latin-1. (TBT) Here are some examples of how that works on an ASCII platform: (TBT) $str = "\xDF"; # $str is not in UTF-8 format. $str =~ /^\w/; # No match, as $str isn't in UTF-8 format. $str .= "\x{0e0b}"; # Now $str is in UTF-8 format. $str =~ /^\w/; # Match! $str is now in UTF-8 format. chop $str; $str =~ /^\w/; # Still a match! $str remains in UTF-8 format.
「やっつけ訳」なので参考程度に。
んで、この先も見てて気になったのがあって
perlre - Perl 正規表現 - perldoc.jp 文字クラス及び他の特殊なエスケープ さらに、Perl は以下のものを定義します: Sequence Note Description (略) \g1 [5] 指定したまたは前のグループへの後方参照 \g{-1} [5] 数値は相対的に前のグループを示す負の値にもできます、また 任意で安全にパースするために波かっこで括ることもできます \g{name} [5] 名前指定の後方参照 \k<name> [5] 名前指定の後方参照
\g1 の説明がよくわからん。どゆこと? で、こういうときは原文に当たれ。と。
perlre - perldoc.perl.org \g1 [5] Backreference to a specific or previous group, \g{-1} [5] The number may be negative indicating a relative previous group and may optionally be wrapped in curly brackets for safer parsing.
あー、\g1 の直後の記述って , で終わってるから、 これを . 扱いしてここで説明文が終わってるとみなすとおかしくなるっぽい? [5] の参照先も併せて考えると
perlre - perldoc.perl.org Capture groups The bracketing construct ( ... ) creates capture groups (also referred to as capture buffers). To refer to the current contents of a group later on, within the same pattern, use \g1 (or \g{1} ) for the first, \g2 (or \g{2}) for the second, and so on. This is called a backreference. There is no limit to the number of captured substrings that you may use. Groups are numbered with the leftmost open parenthesis being number 1, etc. If a group did not match, the associated backreference won't match either. (This can happen if the group is optional, or in a different branch of an alternation.) You can omit the "g" , and write "\1" , etc, but there are some issues with this form, described below. You can also refer to capture groups relatively, by using a negative number, so that \g-1 and \g{-1} both refer to the immediately preceding capture group, and \g-2 and \g{-2} both refer to the group before it. For example:
ん、 \g1 \g2 のようなのが Backreference to a specific group で、 \g-1 \g-2 のようなのが Backreference to a previous group ということか(で、数字部分を {} でくくっても良し。と)。
awkの、コマンドライン上での変数代入について
@node Other Arguments
@section Other Command-Line Arguments
@cindex command line, arguments
@cindex arguments, command-line
Any additional arguments on the command line are normally treated as
input files to be processed in the order specified. However, an
argument that has the form @code{@var{var}=@var{value}}, assigns
the value @var{value} to the variable @var{var}---it does not specify a
file at all.
(See
@ref{Assignment Options}.)
@cindex @command{gawk}, @code{ARGIND} variable in
@cindex @code{ARGIND} variable, command-line arguments
@cindex @code{ARGC}/@code{ARGV} variables, command-line arguments
All these arguments are made available to your @command{awk} program in the
@code{ARGV} array (@pxref{Built-in Variables}). Command-line options
and the program text (if present) are omitted from @code{ARGV}.
All other arguments, including variable assignments, are
included. As each element of @code{ARGV} is processed, @command{gawk}
sets the variable @code{ARGIND} to the index in @code{ARGV} of the
current element.
@cindex input files, variable assignments and
The distinction between @value{FN} arguments and variable-assignment
arguments is made when @command{awk} is about to open the next input file.
At that point in execution, it checks the @value{FN} to see whether
it is really a variable assignment; if so, @command{awk} sets the variable
instead of reading a file.
Therefore, the variables actually receive the given values after all
previously specified files have been read. In particular, the values of
variables assigned in this fashion are @emph{not} available inside a
@code{BEGIN} rule
(@pxref{BEGIN/END}),
because such rules are run before @command{awk} begins scanning the argument list.
@cindex dark corner, escape sequences
The variable values given on the command line are processed for escape
sequences (@pxref{Escape Sequences}).
@value{DARKCORNER}
In some earlier implementations of @command{awk}, when a variable assignment
occurred before any @value{FN}s, the assignment would happen @emph{before}
the @code{BEGIN} rule was executed. @command{awk}'s behavior was thus
inconsistent; some command-line assignments were available inside the
@code{BEGIN} rule, while others were not. Unfortunately,
some applications came to depend
upon this ``feature.'' When @command{awk} was changed to be more consistent,
the @option{-v} option was added to accommodate applications that depended
upon the old behavior.
The variable assignment feature is most useful for assigning to variables
such as @code{RS}, @code{OFS}, and @code{ORS}, which control input and
output formats before scanning the @value{DF}s. It is also useful for
controlling state if multiple passes are needed over a @value{DF}. For
example:
@cindex files, multiple passes over
@example
awk 'pass == 1 @{ @var{pass 1 stuff} @}
pass == 2 @{ @var{pass 2 stuff} @}' pass=1 mydata pass=2 mydata
@end example
Given the variable assignment feature, the @option{-F} option for setting
the value of @code{FS} is not
strictly necessary. It remains for historical compatibility.
一昨年からやってた TAPL の翻訳がついに終わり、「型システム入門」という題名で本が発売されました。これも報酬に見合わない労力がつぎ込まれた傑作なので、まだ買ってない人は是非買ってください。
12月26日 VS2013コンパイラの内部エラー
12月27日 Re:VS2013コンパイラの内部エラー
一日目も興味あるサークルがあるにはあるんだけど見送りかなあ (二日目も微妙…)
この辺の誤訳を指摘されたような気がする
Apocalypse 5: Pattern Matching Poor integration with rich languages Let's face it, in the culture of computing, regex languages are mostly considered second-class citizens, or worse. "Real" languages like C and C++ will exploit regexes, but only through a strict policy of apartheid. Regular expressions are our servants or slaves; we tell them what to do, they go and do it, and then they come back to say whether they succeeded or not. At the other extreme, we have languages like Prolog or Snobol where the pattern matching is built into the very control structure of the language. These languages don't succeed in the long run because thinking about that kind of control structure is rather difficult in actual fact, and one gets tired of doing it constantly. The path to freedom is not to make everyone a slave. However, I would like to think that there is some happy medium between those two extremes. Coming from a C background, Perl has historically treated regexes as servants. True, Perl has treated them as trusted servants, letting them move about in Perl society better than any other C-like language to date. Nevertheless, if we emancipate regexes to serve as co-equal control structures, and if we can rid ourselves of the regexist attitudes that many of us secretly harbor, we'll have a much more productive society than we currently do. We need to empower regexes with a sense of control (structure). It needs to be just as easy for a regex to call Perl code as it is for Perl code to call a regex.
ふむ。どうしよ。
twitter のTLを眺めるに、今日が仕事納めの人も結構いたようで。 わたしゃあ明日までだけどな!w
Kotlinのソースコード読みたいと思ってGitHubからCloneしたけど、何処にArrayがあったりCollectionがあったりするのか全然分からなくて泣けたので誰か読み方教えてください＞＜
twitter の一部で正規表現の話が盛り上がっていて、そこから派生して C++のライブラリの話が。で、これをちょっと見てたのですが regex_proposal
regex_proposal ECMAScript ECMAScript[4] is based on the perl regular expression syntax[2], which in turn is loosely based on the POSIX extended syntax[1]. ECMAScript is also known as JavaScript or JScript. Unlike the POSIX regular expression syntaxes, ECMAScript does not use the "leftmost longest" rule to determine the best possible match, instead the regular expression is treated as a directed graph, and a depth first search is performed, with the first match found being returned. The following examples illustrate the main differences between the two:
depth first seacrh って言い回し、他で見たことあったかな?
年末のアレのチェックをしてるんですが、 夏に出てた(しかし完成していなかった) mruby本のさーくると xv6本のサークルさんがいないっぽい。
オライリーの本にあわせたようなタイミングで別のポインター本が。 ってこのタイトル以前にも見たことあるような? Amazon.co.jp： 詳説 Cポインタ: Richard Reese, 菊池 彰: 本 Amazon.co.jp： C言語のポインタのツボとコツがゼッタイにわかる本―最初からそう教えてくれればいいのに!: 石黒 尚久: 本
Read less HN johnmurray.io
COBOL向けのframework…? COBOL on Wheelchair
COBOL on Wheelchair Who says you can't teach a 54-year-old dog some new tricks? ;) COBOL on Wheelchair is a minimal webframework\^H\^H\^H\^H\^H\^H just a proof of concept. However, it partially works, and it can handle: routing; PATH variables (GET and POST on the way...); basic templating. In order to run COBOL on Wheelchair you will need: some http server; GNU COBOL [sudo apt-get install open-cobol]; ability to run cgi-bin.
元記事にはサンプルもあるんですがなんと言うかこう…
今夏のことでしたが、このことを知っていた、あるいは覚えているという方はどのくらいいるでしょうか
１６歳マララ・ユスフザイのスピーチが感動的！｜ほぼ毎日 英語学習日記 ～ 英語holic ～
秋くらいにこの人が書いた本が(もちろん英語版)出る(た?)というのを聞いて
日本語訳出るかなあと思ってたら意外に早かった
(さすがにスティーブ・ジョブズのアレには及びませんが)。
というわけで一気に。とは行きませんでしたが読了。
わたしはマララ: 教育のために立ち上がり、タリバンに撃たれた少女
お父さんも立派な人だなあというのが第一印象。 で、感想やらはさてどう書いたものか。
Alan Turing, Enigma Code-Breaker and Computer Pioneer, Wins Royal Pardon - NYTimes.com
Enigma codebreaker Alan Turing receives royal pardon | Science | The Guardian
英国政府、アラン・チューリングに没後59年目の恩赦。計算機科学の父 - Engadget Japanese
前にこういう話なかったっけ?
と思い調べてみると前回のそれは「謝罪」だったようで。
ということで年末年始にこれらの本などいかがでしょうか? :)
チューリング
チューリングを読む コンピュータサイエンスの金字塔を楽しもう
チューリングの大聖堂: コンピュータの創造とデジタル世界の到来
Book Review and Author Q&A - Explore It! by Elisabeth Hendrickson これ、途中まで読んで放置状態なんだけど、日本語訳でたりするんだろうか?
O'Reilly のtwitter アカウントからの投稿
A Great Old-Timey Game-Programming Hack
http://t.co/HGIYtGbJ08
— O'Reilly Media (@OReillyMedia)
2013, 12月 23
ちょっと前に reddit でも話題になってまして A Great Old-Timey Game-Programming Hack : programming Another Great Old-Timey Game-Programming Hack (this one for the Apple IIGS) : programming
面白いっちゃあ面白いんだけど6809だし、イマドキの若い衆向きではないかもしれない (老害発言) A Great Old-Timey Game-Programming Hack - Tom Moertel’s Blog Super Merryo Trolls
形式手法に始まり、思いやり、品質、モックアップ、テスト、simple とeasy、そして Ruby! と非常に話題は多岐に渡りました。 そこには、今回のテーマである"formal and casual"が散りばめられており、とちぎで今しか味わえない極上の Ruby 会議であったと思います。
今回は風ちゃんの超強気に乗ってしまって200部と相成りました。
毎回売り切れになってしまって申し訳なかったので今回は余らせる勢いで200部刷ってあります。 前回の「きつねさんとおぼえる！Clang」も50部刷りますので買い逃した方はぜひ両方ともご購入下さい。
先日Javaで書かれたロジックをRubyに移植しようとしてハマった内容です。
How much of this is true? C vs. C++ by Linus Torvald : programming 妙に伸びてると思ったらまたもあの話題でしたとさ Re: RFC Convert builin mailinfo.c to use The Better String Library.
ピープルウェア第三版。
前のとの違いがよくわからない(一応解説はあったけど)
ピープルウエア 第3版
最近翻訳が少ない? 最新技術を追い求めるデベロッパのための情報コミュニティ
ついったで見かけたので Glocalization 2013 #3 テキストのハードコーディングは痛い (精神/肉体/経済的に)
Programming and Stuff - Michael Scharhag's Java development blog: Six things I learned for software localization Saturday, November 16, 2013 Six things I learned for software localization ソフトウェアのローカライズからわたしが学んだ六つのこと This blog post is a personal compilation of six technology independent things I learned in the past months about software localization. A few weeks ago we finally went live with our application supporting 22 different languages. As a German development team working for a German customer we used German as our base language within the application. Our customer was responsible for translating the German application messages into the other 21 languages and providing other localized material (images, downloadable documents, etc.). 1. Use a tool (ツールを使おう) (略) 2. Teach Translators (翻訳者に教えよう) You should make sure that translators fully understand the syntax of messages. For a developer it might be obvious how placeholders, escaping and date formats work. From a translator's view (who might not have any experience with software development at all) things aren't always that obvious. If your application crashes with date format exceptions in certain languages because the date format DD.mm.YYYY got translated to jour/mois/an (day/month/year in French) you know you have to improve on this point. 翻訳者が完璧にメッセージの構文が理解できるようにすべきです。開発者にとってはプレースホルダーやエスケープ、 日付の書式指定といったものがどのように動作するかは明白なことかもしれません。しかし(ソフトウェア開発の 経験が全くないかもしれない)翻訳者の視点では、それらが明白なものだとは常に言えることではないのです。 DD.mm.YYYY という日付の書式指定が jour/mois/an (フランス語表記での day/month/year) に翻訳されてしまっために アプリケーションが特定の言語において date format exception を伴ってクラッシュしたならば、 あなたはこの点を改善しなければならないことを理解するでしょう。 Make sure to tell them how placeholders work and which special characters need to be escaped. Give them examples of common date/time patterns including the output those produce. Use comments in message files to provide common formatting options or to explain the placeholders that can be used within messages. 翻訳者には、プレースホルダーがどのように作用するのか、またどのキャラクターをエスケープする必要があるのかを きちんと伝えましょう。また、一般的な日付や時刻のパターンの例をその生成結果も含めて与えましょう。 メッセージファイルでは一般的なフォーマット用オプションやメッセージ中でプレースホルダーを使ったときの 説明をするのにコメントを使いましょう。 3. Give translators context (翻訳者に文脈を伝えよう) Just translating messages from one language into another often isn't enough. Translators need to know the context in which the message is displayed in order to provide an appropriate translation. The first step here is to give them access to a test system where they can see the application with a recent version of their translations. ある言語から別の言語へメッセージを翻訳しただけでは充分ではありません。 翻訳者は適切な翻訳を行うためにメッセージが表示される文脈を理解しておく必要があります。 その最初のステップは、翻訳者に対して彼らが自分たちの行った翻訳の結果を確かめられるように テストシステムへアクセスできるようにすることです。 In regular intervals we received emails from translators with questions like this: Within the application I see message X at position Y. What is the message key for X? わたしたちが翻訳者から受け取った質問のメールは大抵こう言ったものでした 「アプリケーションでYの位置にメッセージXを見つけました。Xのキーはなんですか?」 Depending on the message X a simple search for X in the message files doesn't always help (think of placeholders, additional markup or too many messages that contain X). Our solution to this was to extend the way messages were rendered for the UI. After that, it was posible to display the message keys in the test environment by adding an additional url parameter to our application urls. Whenever this url parameter was appended we added a simple <span> tag with a title attribute around rendered messages. So instead of [message] we rendered <span title="[key]">[message]</span>. This made it possible to just hover the displayed message with the mouse to see a small tool tip which shows the message key. This approach isn't 100% bulletproof because in some situations the additional <span> will break the layout. However, 95% of the time it works fine and it reduced the questions we received from translators a lot. メッセージファイルの中でメッセージ X の X を検索するのに頼るのはいつでも有効だとは限りません (プレースホルダーや付加的なマークアップがありますし、X を含むメッセージがたくさんあるかもしれません)。 それに対してわたしたちのとった解決策は、UI 向けに render されるメッセージを拡張するといったものでした。 (略) 4. Keep in mind word widths can vary (単語の長さが変わる可能性に注意しよう) Depending on your base language you should be aware that the average character count per word can be much higher or lower in other languages. I haven't found any real statistics of average word lengths, but I can show you some numbers from our message files: Average characters per word: Language Characters Factor English 5.3 1 Portuguese 5.5 1.04 French 5.7 1.07 German 6.4 1.21 Russian 6.7 1.25 (略) 5. Test it (テストしよう) Extensively test the localized application: Validate translations, use non western characters as user input and check the functionality for all languages. To underline the importance of testing I just want to give a few examples of locale specific problems we ran into: ローカライズされたアプリケーションを extensively にテストしましょう。 翻訳を validate し、ユーザー入力に non western characters を使い、すべての言語に対してその fubctionality をチェックしましょう。 To underline the importance of testing I just want to give a few examples of locale specific problems we ran into: Users of a particular language didn't receive a certain email. It turned out that the email contained a date formatted by a locale dependent pattern. The pattern contained an invalid character, the date formatter failed and the email wasn't sent to the user. ある特定の言語のユーザーは一部のメールを受け取れませんでした。これは、受信できなかったメールには locale depended なパターンでフォーマットされた日付があったためでした。そのパターンには invalid character が あり、date formatter が失敗したのでメールがユーザーに送信されなかったのです。 In certain situations placeholders weren't replaced by actual content in French. The problem was caused by messages that contained unescaped single quotes. In Java's MessageFormat placeholders aren't replaced if they are located between two unescaped single quotes. We only noticed this problem in French because French messages contain much more single quotes than the messages from other languages we support. フランス語環境で、プレースホルダーが actual content に置き換わらなかったシチュエーションがいくつかありました。 この問題はエスケープされていないシングルクォートを含むメッセージによって発生しました。 Java の MessageFormat のプレースホルダーはエスケープされていないシングルクォートに挟まれたものの 置き換えは行いません。わたしたちがフランス語環境でのみこの問題に気がついたのは、わたしたちがサポート していた言語の中でフランス語のメッセージが飛び抜けて多くのシングルクォートを含んでいたからでした。 UI elements broke because translated messages where too long and didn't fit into the reserved space. 翻訳されたメッセージが長すぎて確保していたスペースに収まらなかったために UI 要素が壊れた It turned out that an external payment provider we are using doesn't support the full UTF-8 character set. So cyrillic characters couldn't be printed on invoices. 6. It takes time (時間がかかる) The whole process of localization can take a lot of time. Especially if many people from different countries are involved. So make sure to plan it properly. Remember that every text message you add to the application needs to be translated. Once we added a small feature which took around a day of development effort. After the development was done it took around three weeks until we could push the feature to the live system. Some translators were on vacation and for some countries legal questions had to be clarified. Additionally we had some dependencies between translators. As mentioned above we used German as base language, but not every translator understood German. So in some cases the German messages had to be translated into English first before they could be translated into other languages. From a developers point of view this doesn't have to be bad. It is actually a very good excuse if the customer or project manager asks you one day before production release if you could add feature X and Y until tomorrow. Sure you could add it, but there is no chance that it gets localized until tomorrow, so it's better to plan it properly and move it to the next release ;-)
あー自分も経験したようなことが…w (Java じゃなかったけど)
冬至。銭湯へゆず湯に。 脱衣場でスマートフォン使おうとして番台(にいた店主)から注意された御仁を目撃。
新聞の書評のページに使われていた写真に背表紙が載っていて、
気になって調べた本
マザーマシンの夢 « 名古屋大学出版会
価格 8,000円
○|￣|＿
例の「フェミニスト向けプログラミング言語」のリポジトリ、bitbucket のも消えたっぽい。
なぜ(ほとんどのプログラミング言語で)戻り値はひとつ(の値)なのか? Why do most programming languages only return a single value from a function? | Hacker News
Why do most programming languages only return a single value from a function? | Hacker News A proof by contradiction: Assume a language where functions do not only return one value. Now, consider each function in this language. It either returns the same number of values each time, where each has a specific meaning, and they are distinguished either by order or by name. Or it returns an arbitrary number of values, where the semantics of each are the same. But that means the return values are equivalent to a tuple, a dictionary, or an array, which are single values. Therefore we have a contradiction and such a language does not exist. (Yes, I know about values in Lisp and this can be a bit nice. Mostly joking.) More seriously, ask the question: what relationship between multiple values is useful for returning from functions but not useful enough to be a data structure that can be used in other parts of code?The same argument applies to functions with multiple parameters, and yet most languages support multiple arguments rather than requiring one to use tuples.Common Lisp has multiple return values and it's quite useful: (let x (f 12) ...) ; bind x to the first value returned by (f 12) and silently drop the others (let (x y) (f 12) ...) ; bind x to the first value and y to the second. That way, I can return more information without breaking existing code. That point is really important: in Python I can gracefully add an extra argument, from def foo(x): ... to def foo(x, y=None): ... but I can't return an extra value without changing (and uglifying!) all calling code to handle the tuple. The answer to the OP is probably that all computer languages derive from Fortran, and Fortran derived from maths, so it chose f(x, y) as the notation for function application. With that notation, there's no elegant way of handling more return values, and language designers might feel that the extra complexity/ugliness isn't worth it. That, and intellectual inertia.
話題の記事はこちら Why do most programming languages only return a single value from a function? | Ars Technica
数学云々よりはコンピューターのアーキテクチャーに引っ張られた結果のような気がするんだけど よくわからん。
Erlang 本のお話。 Erlang: The Written History | Josetteorama
Erlang: The Written History | Josetteorama Erlang: The Written History 2013 December 21 by Joe Armstrong Erlang is now over 25 year old. I’ve been involved with Erlang from the very start, and seen it grow from an idea into a fully-fledged programming language with a large number of users. I wrote the first Erlang compiler, taught the first Erlang course, and with my colleagues wrote the first Erlang book. I started one of the first successful Erlang companies and have been involved with all stages of the development of the language and its applications. (略) Here’s the time line since 2007 * 2007 – Programming Erlang – Armstrong – (Pragmatic Bookshelf) * 2009 – ERLANG Programming – Cesarini and Thompson – (O’Reilly) * 2010 – Erlang and OTP in Action - Logan, Merritt and Carlsson – (Manning) * 2013 – Learn You Some Erlang for Great Good - Hebert – (No Starch Press) * 2013 – Introducing Erlang: Getting Started in Functional Programming – St. Laurent (O’Reilly) * 2013 – Programming Erlang - 2nd edition- Armstrong – (Pragmatic Bookshelf)
2013年だけで3冊出てたのね。 んで Programming Erlang の 2nd edition について
Erlang: The Written History | Josetteorama The biggest difference in the 2nd edition was redefining the target audience. Remember I said that the first edition was intended for advanced and beginning users? Well, now there were four competing books on the market. Fred Hebert’s book was doing a great job for the first-time users, with beautifully hand-drawn cartoons to boot. Francesco and Simon’s book was doing a great job with OTP, so now I could refocus the book and concentrate on a particular band of users. But who? In writing the 2nd edition we spent a lot of time focusing on our target audience. When the first seven chapters were ready we sent the chapters to 14 reviewers. There were 3 super advanced users – the guys who know everything about Erlang. What they don’t know about Erlang could be engraved on the back of a tea-leaf. We also took four total beginners – guys who know how to program in Java but knew no Erlang – and the rest were middling guys: they’d been hacking Erlang for a year or so but were still learning. We threw the book at these guys to see what would happen.
この後の部分が一番面白かったりする :)
追記(2013-12-21): 「Scalaを使い始めてから半年だけど印象をまとめてみる」へのコメント - Togetterまとめ で言及をいただきましたので、いくつか追記しておきます。
ということで 第1回 PowerShell勉強会 : ATND に行って参りました。 東京メトロの六本木駅から地上に出ないで会場のある森ビルに行けたんだけど前からこのルートあったっけ? まあ年単位で行ってないところだし、以前は気づいてなかっただけなのかもしれないけど。 それと、なんというか世界が違うんだなあと、会場を提供してくれた会社を見て(ほんの一部だけどね)思った。
一応発表内容メモりながら聴いてたのだけど(内職もしつつ)、 最近はどうもきちんと書き起こす気になれないのよねえ。 こういうのあるし 第1回 PowerShell勉強会 #jpposh ツイートまとめ - Togetterまとめ
そういやあどの発表でも質疑応答の時間を全く取らなかったけど そういうもんなんだろうか。 いやまあ時間とってもどれくらい出たものかは分からないし、 今日は全体的に押してたからなあ (休憩時間短めにしたくらい)。
My Hardest Bug | Hacker News 自分が経験した中での難しかった(面倒くさかった)バグの話は書いたことあったっけか? 懇親会やらで話したことはあると思うんだけど
reddit にもあったのを忘れていたので追加 My Hardest Bug : programming
【R言語】統計解析フリーソフトＲ 第５章【GNU R】 69 １３２人目の素数さん [sage] 2013/12/11(水) 01:32:30.36 ID: Be: データ・サイエンスのプログラミング言語はRからPythonに置き換わる http://readwrite.jp/archives/2534 70 １３２人目の素数さん [sage] 2013/12/11(水) 07:27:37.57 ID: Be: そんな主張への反論だそうだ。こちらは訳されないだろうが。 http://blogs.computerworld.com/big-data/23204/python-really-supplanting-r-data-work http://blog.revolutionanalytics.com/2013/12/r-and-python.html
On the growth of R and Python for data science これか－、それほど長くはないけども…
On the growth of R and Python for data science As an general-purpose data processing tool, it's no surprise that Python has more activity than the domain-specific analytics language R. But it's clear that both are growing explosively (Wickham describes the growth as "very close to being exponential"). Looking closer though, we see that the proportion of R questions, as a fraction of Python questions, is also growing rapidly:
この辺が反論の肝かしらん
もう一つの方 Is Python really supplanting R for data work? | Computerworld Blogs
Is Python really supplanting R for data work? | Computerworld Blogs So yes, I'll agree that many people think R is hard. (Many people also think data science is hard, but that doesn't seem to be slowing the field.) I'll also agree that Python is an elegant and popular language useful for data work. I've got nothing against Python; if I had the time, I'd be interested in learning it myself. But it's still a big leap from "R is hard and I like Python" to "Python is displacing R." And as any good data scientist knows, the burden is on the researcher who makes a claim to prove it, not on his or her readers to conduct research in order to find it false.
あ、明日は(アップロードする時点で日付変わってるけど)冬至か
一つ前へ
2013年12月(中旬)
一つ後へ
2014年1月(上旬)
リンクはご自由にどうぞ
メールの宛先はこちら