ときどきの雑記帖'

最新ページへのリンク
目次ページへのリンク

一つ前へ 2013年8月(上旬)
一つ後へ 2013年8月(下旬)

ホームへ

2013年08月20日

■_

数学セミナー。 ここ最近は会社近くの本屋で買っていたのですが (扱っているところがあった)、 今月は発売日が夏休みにかかってしまい昨日行ったらすでになかった (一冊か二冊しか入ってないからなあ)という。 他に通勤経路にある書店で扱ってるところないんですよねえ。 数学セミナー 2013年 09月号 [雑誌]
数学セミナー 2013年 09月号 [雑誌]

■_

HN経由かなんかで知ったのですが、 Software Design Philosophy - RAMCloud Project - Confluence Added by John Ousterhout, last edited by John Ousterhout on Aug 24, 2012 (view change) あー、一年前の記事かー見ないでもいいかなーとタブをクローズしようとしたときに 編集した人の名前に気がつく。 Tcl のあの人でねーすか。 ということで読む。

Software Design Philosophy - RAMCloud Project - Confluence

This page contains John Ousterhout's recommendations for how to design clean, simple, and obvious software.
As of August, 2012 it is still a work in progress.

    Design classes around information, not algorithms or time order. Each class should encapsulate and own
    particular design decisions or information, so that code outside the class does not need to be aware of
    them. The biggest mistake that people make is to design classes around time: collect all the things that
    happen at one point in time into a single class. Read David Parnas' seminal paper On the Criteria to be
    Used in Decomposing Systems into Modules, which explains why this is a bad idea, and why "information
    hiding" is a better approach. Unfortunately, most people who read Parnas' paper say "d'oh,
    that's totally obvious and I learned that in my introductory programming class!", then go on to write
    code in exactly the way that Parnas argues against.

以下略

お、なんかよさげ。

■_

■_

あー取りあげようと思ったものは幾つもあるのに~

2013年08月19日

■_

おー 「Effective Android」電子書籍化決定! | Tech Booster

昨日のawkの話、awk で実行してたのは v7 UNIX の awk を自前コンパイルしたものだった。

■_ LLまつり

タイムテーブル - Lightweight Language Matsuri うーむ、最初のセッションどの会場も見たいのだがががが。 今年は最後までLT見ていこうかなあ。

■_

One VM to Rule Them All : programmingOne VM to Rule Them All [pdf] | Hacker News で言及されてるスライドが結構面白かった。 Oracleカラーでいっぱいですが。

One VM to Rule Them All [pdf] | Hacker News

This looks interesting, but I am generally worried about something being owned by Oracle. Simple example; I own
an Openpandora. I wrote a live coding environment in Java with a very basic, lispy language at it's core. Using
any free Java implementation it either; did not start (core dump; suspect; not enough memory to get even the VM
up) or ran very (unusable) slow. With the Java 7 closed source ARM version from Oracle; runs fast (just as
smooth as on my Macbook) and uses very little memory.

I have the same experience on x86, but because of the abundance of resources it's less noticable.

I don't insist on everything being open source (completely), but base languages/VMs should be. Unless something
about this changes, I'm not using anything owned by Oracle again.
One VM to Rule Them All : programming

A tweet from Charles Nutter:

Good news: Oracle's Ruby-on-Truffle is 5-6x faster than JRuby. Bad news: it's closed source.
Good news: I can do the same thing for JRuby.

https://twitter.com/headius/status/362641082737115138

Oracle さんの悪役っぷりと来たら

■_

ちょっと前の話題ですが、これに気がついたのは今日なので。はい。 納涼!ほんとにあった怖いコードの話 - shobuno's blog

納涼!ほんとにあった怖いコードの話 - shobuno's blog

開かずのプログラム

これも大手銀行のシステムでのお話。。。

先程書いた様に、私はCOBOLでプログラムを書いていたのですが、

ある日、リーダーに呼ばれて、直々の命令を頂きました。

 

リーダー「あのさ、このコードなんだけど、銀行の利息計算をする

     超重要なプログラムなんだけど、誰も触れないんだよね。」

私「えっ?!」

リーダー「COBOLじゃなくて、FORTRAN(科学演算が得意なプログラム言語)

     なんだよね。」

私「そ、そうなんですか。」

リーダー「これ、COBOLに直してくれないかな?」

私「分かりました。挑戦してみます。」

リーダー「あ、そう? 出来たらで良いから。無理しなくてもいいからね。」

 

貰ったプログラムをプリントアウトしてみて、ビックリ。。。

たったの15行でした。

こんなの楽勝じゃん♪

 

しかし。。。内容の解析に、丸々3日間かかりました。

このプログラム、要するに積分計算のプログラムで、

  \int_a^b f(x)\,dx

こんな感じの式をプログラムで解くもので。。。

要するに、xの値を、a〜bに値を変えて、f(x)の値をどんどん足していく

ものなのですが、0.000001(100万分の一)ぐらいづつxの値を増やして計算していて、

FORTRANの計算誤差と、COBOLの計算誤差が上手く合わなくて、

同じ結果にすることが出来ず。。。結局断念しました。

 

私「す、すみません、これは無理ですね。。。」

リーダー「そうか。ありがとう。 

     じゃあ、このプログラムはまた封印しておこうか。。。」


誰も触る事の出来なかった、あの「開かずのプログラム」。

今でもどこかで、人知れず生き続けている様な気がします。。。(^_^;

刻み幅が 0.000001 ってそりゃあBCD確定のCOBOLと、おそらくは2が基底の浮動小数点数であるだろう (IBMのアレという可能性もある?) FORTRAN とでぴたり一致させるのは大変(面倒)でしょうねえ。 別に怖くも何ともないと思うんですがわたしが鈍感なだけ加茂。

■_

2013年08月18日

■_

艦これやってません。が、 「三隈」を「三隅」と間違っているのをよく見かける(気がする)のが気になる今日この頃 三隈 (重巡洋艦) - Wikipedia 大分県日田市を流れる鵜飼でも有名な河川の名前が、 三隅川(みすみがわ)と三隈川... - Yahoo!知恵袋 あながち無関係でもないのかw

■_ ホームドア

そういやあ丸ノ内線はとっとと付いたのに銀座線が一向に…というのは ホーム幅やらの関係なんですかね。などと 東京メトロ、今年度中に有楽町線全駅でホームドア導入完了へ | マイナビニュース

東京メトロ、今年度中に有楽町線全駅でホームドア導入完了へ | マイナビニュース

東京メトロはこれまでに南北線全19駅、丸ノ内線全28駅、副都心線全11駅と千代田線の2駅でホームドアの設置が完了して
おり、同社全体で84駅へ導入が完了することとなる。全179駅に対しての設置率は約47%。

南北線と副都心線は開業当初からホームドアつきだったけど、なんで丸ノ内線がいちばんに 全駅導入になったんだろか。相互乗り入れしてないから…? それは銀座線も同じだしなあ。

ホームドアの問題 有楽町線にホームドアを設置した後、次は銀座線で、その次は千代田線ですか?その... - Yahoo!知恵袋

■_

スライドが。後で見よ。 Rakudo on JVM や MoarVM の話は miyagawa さんの podcast 最新回でもでてましたね。 YAPC::EU 2013 Slides | 6guts

YAPC::EU 2013 Slides | 6guts

This year I submitted three talks, expecting one or two would be accepted. Instead, all three were! So, I talked about:

    Rakudo on JVM – this session explained the motivation for adding a JVM backend, the compiler architecture
    that enabled it, how it was implemented, the current status, the support so far for Java interoperability
    and the plan from here. Seems to have been well received.

    Concurrency, Parallelism and Asynchrony – this session showed the work I have been doing to build basic
    support for parallel, asynchronous and concurrent programming in Perl 6. This was the best attended and
    also, I believe, the most discussed of my talks this year. There is still much work to do in this area, but
    what’s done so far caught some interest. Once I’m recovered from YAPC, I’ll dig back into it.

    MoarVM – this session talked about the motivation for building a new VM, its overall design, the current
    status and what’s in store. It’s also the first talk I ever gave on MoarVM. The most lightly attended
    and most hastily prepared, but still it seemed to be appreciated by those who attended.

■_ awk と gawk

あれ、なんでこれ動作が違うの

kbk@toybox /cygdrive/c/Users/kbk
$ seq 1 10
1
2
3
4
5
6
7
8
9
10

kbk@toybox /cygdrive/c/Users/kbk
$ seq 1 10|awk '{print $1*2}'
0
0
0
0
0
0
0
0
0
0

kbk@toybox /cygdrive/c/Users/kbk
$ seq 1 10|awk '{print $0*2}'
2
4
6
8
10
12
14
16
18
20

kbk@toybox /cygdrive/c/Users/kbk
$ seq 1 10|awk '{print $1}'
1
2
3
4
5
6
7
8
9
10

kbk@toybox /cygdrive/c/Users/kbk
$ seq 1 10|gawk '{print $1*2}'
2
4
6
8
10
12
14
16
18
20

$1 で数字列が取れてるんだから2をかけて0になるってのは妙だなあ。 実際gawkだと期待通りだし。cygwinだから実体は一緒だよなあ。 ソース見るか。

■_

最近公開した~とあるから新しいのが出たかと思いきや ThoughtworksのTechnology Radarから見る最新技術トレンド Thoughtworks社が最近公開したTechnology Radarの最新記事

Technology Radar May 2013 | ThoughtWorks Prepared by the ThoughtWorks Technology Advisory Board - May 2013 5月のまま。5月の記事を今「最近公開」ってのはなんかへんじゃねーのと思いつつ 元記事見たらそっちも8月頭の記事でした。 Latest Technology Trends on the Radar ThoughtWorks recently released a new installment of their technology radar

■_

2013年08月17日

■_

Software Design (ソフトウェア デザイン) 2013年 09月号 [雑誌]
Software Design (ソフトウェア デザイン) 2013年 09月号 [雑誌]
sed/awk 特集。awk の方の記事で名前出してくれたのはありがたいんだけど呼び捨て… いやまあ名前間違われるより(今でも根に持っているw)はましだし、 論文の類ならそうするんだろうけども。でもなあ。

■_ プログラマーのジレンマ

似たような話は以前にも見た覚えがあるけどどこだっけ

Programmer’s dilemma — I.M.H.O. — Medium

Programmer’s dilemma

Recently I interviewed tens of candidates for a kernel programmer's position. These candidates are from big,
good companies, which are famous for chips or embedded OS/systems. Many of them claimed they have at least 10
years on-job experience on kernel. Their resumes look fairly shiny — all kinds of related projects, buzz words 
and awards…

But most of them cannot answer a really basic question: When we call the standard malloc function, what happens
in kernel?
しかし彼らのほとんどは本当に基本的な質問、「標準関数の malloc を呼び出したときにカーネル内部で起きることは?」
にも答えることができないのです。

Don’t be astonished. When I ask one of the candidate to write a simple LRU cache framework based on glib hash
functions, he firstly claimed he had never used glib — that’s what I expected — I showed the glib hash api
page and explained the APIs to him in detail, then after almost an hour he wrote only a few lines of messy code.

これで驚いてはいけません。
わたしが候補者のひとりに glib のハッシュ関数を使って簡単な LRU キャッシュフレームワークを
書いて欲しいと頼んだところ、彼はまず、glib を使ったことがないと返答してきました。
これは自分も予期していたので、glib のハッシュ APIのページを見せてその詳細を説明しました。
それからおよそ一時間経って彼が書いたものといえば、ほんの数行の messy なコードに過ぎませんでした。


I don’t know if the situation is similar in other countries, but in China, or more specifically, in Beijing,
this is reality. “Senior” programmers who worked for big, famous foreign companies for years cannot justify
themselves in simple, fundamental problems.

他の国ではどうなのかは分かりませんが、中国、さらに言えば北京ではこれが現実なのです。
有名な外資の大企業で何年も働いている「上級」プログラマーたちは、単純で基本的な問題を
justify themseleves できないのです。

Why did this happen?
なぜそれは起きたのか?

The more I think about it, the more I believe it is caused not only by themselves but also by the companies
they worked for. These companies usually provide stable stack of code, which has no significant changes for
years. The technologies around the code wraps up people’s skills, so that they just need to follow the existing
path, rather than to be creative. If you happened to work for such kind of code for a long period and did not
reach to the outer world a lot, one day you will find yourself to be in a pathetic position — they called you
“EXPERT” inside the team or company, yet you cannot find an equally good job in the market unfortunately.

This is so called “Expert Trap”. From day to day, we programmers dreamed of being an expert inside the
team/company; however, when that day really comes we trapped ourselves. The more we dig into existing code,
the deeper we trapped into it. We gradually lose our ability to write complete projects from scratch, because
the existing code is so stable (so big/so profitable). What’s the worse, if our major work is just to maintain
the existing code with little feature development, after a while, no matter how much code we’ve read and
studies, we will find we cannot write code — even if the problem is as simple as a graduate school assignment.
This is the programmer’s dilemma: we make our living by coding, but the big companies who fed us tend to
destroy our ability to make a living.

これは “エキスパートの罠”と呼ばれるものです。

How to get away from this dilemma?
このジレンマを回避するには?

For personal —

First of all, Do your own personal projects. You need to “sharpen your saw” continuously. If the job itself
cannot help you do so, pick up the problems you want to concur and conquer it in your personal time. By doing
so, most likely you will learn new things. If you publish your personal projects, say in github, you may get 
chances to know people who may pull you away from your existing position.

Do not stay in a same team for more than two years. Force yourself to move around, even if in the same
organization, same company, you will face new challenges and new technologies. Try to do job interviews every
18 months. You don’t need to change your job, but you can see what does the market require and how you fit
into it.

For team/company —

Give pressures and challenges to the employees. Rotate the jobs, let the “experts” have chance to broaden
their skills. Start new projects, feed the warriors with battles.

Hold hackathon periodically. This will help to build a culture that embrace innovation and creation. People
will be motivated by their peers — “gee, that bustard can write such a beautiful framework for 24 hours, I
gotta work hard”.

■_ Elixir Design Goals

Elixir の設計上の目標とか

Elixir Design Goals - Elixir

Elixir Design Goals
August 08, 2013 · by José Valim . in internals

During the last year, we have spoken at many conferences spreading the word about Elixir. We usually started
with introducing the Erlang VM, then went on to talk about Elixir goals, saving some time at the end to do a
live demo, showing some goodies like exchanging information between remote nodes and even hot code swapping.

This post is a summary of those talks, focusing on the language goals: compatibility, productivity and
extensibility.

Compatibility

Elixir is meant to be compatible with the Erlang VM and the existing ecosystem. When we talk about Erlang, we
can break it into three parts:

    A functional programming language, called Erlang
    A set of design principles, called OTP
    The Erlang Virtual Machine, referred to as EVM or BEAM

Elixir runs in the same virtual machine and is compatible with OTP. Not only that, all the tools and libraries
available in the Erlang ecosystem are also available in Elixir, simply because there is no conversion cost from
calling Erlang from Elixir and vice-versa.

We frequently say that the Erlang VM is Elixir's strongest asset.

All Elixir code is executed inside light-weight processes (actors), each with its own state, that exchange
messages between each other. The Erlang VM multiplexes those processes onto many cores, making it trivial to
run code concurrently.

In fact if you compile any Elixir code, including the Elixir source, you will see all cores on your machine
being used out of the box. With technologies like Parallella becoming more accessible and affordable, it is
hard to ignore the power you can get out of the Erlang VM.

Finally, the Erlang VM was designed to build systems that run forever, self-heal and scale. Joe Armstrong, one
of Erlang's creators, has recently given an excellent talk about the design decisions behind OTP and the VM.

Nothing that we are describing here is particularly new. Open source projects like CouchDB, Riak, RabbitMQ,
Chef11 and companies like Ericsson, Heroku, Basho, Klarna and Wooga are already enjoying the benefits provided
by the Erlang VM, some of them for quite a long time.

Productivity
以下略
© 2012-2013 Plataformatec. All rights reserved.

なるほどねえ> We frequently say that the Erlang VM is Elixir's strongest asset.

なんかこういう本が予定に Amazon.co.jp: Designing for Scalability with ERLANG/Otp: Implementing Robust, Fault-Tolerant Systems: Francesco Cesarini, Simon Thompson, Robert Virding: 洋書

■_

2013年08月16日

■_

某書店街をうろつきながら気になった本。最近でたものもちょっと前に出たものも。 サリンジャーとかアウグストゥスはボリュームも結構なものだったから、 読むのはきつそうだなあ… 戦闘技術の歴史は会戦の図版目当てな感じが。 サリンジャー ――生涯91年の真実
サリンジャー ――生涯91年の真実 アウグストゥス: ローマ帝国のはじまり
アウグストゥス: ローマ帝国のはじまり 新・ローマ帝国衰亡史 (岩波新書)
新・ローマ帝国衰亡史 (岩波新書) 古代末期: ローマ世界の変容 (文庫クセジュ 981)
古代末期: ローマ世界の変容 (文庫クセジュ 981) 「レアメタル」の太平洋戦争: なぜ日本は金属を戦力化できなかったのか
「レアメタル」の太平洋戦争: なぜ日本は金属を戦力化できなかったのか 戦闘技術の歴史4 ナポレオンの時代編
戦闘技術の歴史4 ナポレオンの時代編 偶然と必然の方程式 仕事に使えるデータサイエンス入門
偶然と必然の方程式 仕事に使えるデータサイエンス入門

明倫館でFORTHの本二冊目撃。一つは(たぶん)持っている本。 もう一つは持ってない本だったけど自重w たぶん原著を持ってたと思うんだよなあ。 あ、あと、岩波の情報科学 の全巻揃いが5000円になってた。 置き場所さえあればなあ…

■_

PDP endian サポートのコードが削られたとかなんとか。

NWCLARK TPF grant May report - nntp.perl.org

Date:
July 26, 2013 14:51
Subject:
NWCLARK TPF grant May report

As per my grant conditions, here is a report for the May period.

This month I simplified part of the implementation of pack and unpack,
removing about 130 lines of code, and reducing the object code size by about
2K. The only casualty was support for mixed-endian systems. Sorry, PDP-11
users.

In the medal stakes for "risk to sanity", the implementation of pack and
unpack are strong contestants, although *only* for bronze. (They're fighting
it out with the implementation of sprintf. Compared with sprintf, they have
the advantage that they've been seen as sufficiently dangerous to nearby
code that they've been quarantined into their own file. The regular
expression engine gets silver, and the reigning champion and gold medal
holder remains the parser itself.)

pack/unpack is one of those pieces of code which has grown organically as
features were added, and so has become too large to easily comprehend the
big picture. In particular, it's hard to look at it at more than one level
at once, and hence see where it could be profitably refactored.

(以下長いので略)

バイトオーダーじゃないけど Ruby のpack/unpack もいろいろ大変そう。

■_

HNで伸びているこれ Google’s “20% time,” which brought you Gmail and AdSense, is now as good as dead | Hacker News

Few people remember it, but the same thing happened at HP. It used to be that HP... | Hacker News

Few people remember it, but the same thing happened at HP. It used to be that HP engineers were expressly given
Friday afternoons and full access to company resources to just play with new ideas. Among other things, this led
to HP owning the printer market.

Then "professional" management came in and killed the proverbial goose. They had to focus more on the
"bottom line". To do what was easy to measure and track, rather than what was necessary for the next
step of the company, and now HP is a mere shadow of its former glory -- directionless and bleeding.

3M and Corning have largely avoided this fate, but it seems that Google won't. This should make a lot of
entrepreneurs happy, as there will continue to be a lot of top-down management-driven products that, if history
shows, will continue to be market failures. Yet somehow, I'm incredibly sad, as it seems that too many companies
go down this road.

そういやあ最近こういう本が 20%ドクトリン サイドプロジェクトで革新的ビジネスを生みだす法
20%ドクトリン  サイドプロジェクトで革新的ビジネスを生みだす法

■_

■_

あーなんかいろいろ読む気がおきねー(特にえーご)

2013年08月15日

■_

夏休みも半分終わっているという… ま、出だしにコミケあったからなあ。

映画に行こうと思い、出かけたはいいが上映時間が今ひとつ都合の良いものでなく、 上映開始まで時間を潰すのが面倒だったので断念。

折りたたみ傘と 傘袋と傘立て

小説フランス革命。やっと最新刊まで追いついた(3巻ほど溜まってた)。 最終刊は来月だっけか。

■_

コンパイルに失敗するまでにとんでもなくメモリを食うというはなし 50 Bytes of Code That Took 4GB to Compile : programming

50 Bytes of Code That Took 4 GB to Compile | Random ASCII

While doing evil things with macros and the inline assembler (trying to run a weird test whose purpose is not
really relevant) I managed to write a program that caused Visual Studio’s C++ compiler to allocate 4 GB of
memory and then die.

Not bad for a program that can easily fit into a single 50 column line.

I might not have noticed except that my machine didn’t have 4 GB free at the time, and the frantic paging-out
of data needed to find 4 GB of memory made my laptop completely unresponsive for a couple of minutes. If you
have a machine with more than 4 GB free then this can be a good test case for doing memory analysis with ETW,
to see if you can duplicate my results.

I’ve simplified the code down to its minimal essence because it amuses me:

    void test()
    {
        __asm { add eax
        __asm { add eax
    }

Here is the compiler output:

    error C2414: illegal number of operands
    error C2414: illegal number of operands
    error C2400: inline assembler syntax error in ‘opcode’; found ‘end of file’
    fatal error C1060: compiler is out of heap space

以下略
50 Bytes of Code That Took 4GB to Compile : programming

Really, it took 4GB to fail to compile :)


Yes, 50 bytes of code that took 4GB to successfully compile would be far more interesting. Could maybe be done
with some template magic.

This just sounds like a rather common type of bug (a loop with an insufficient stop condition), which is not
surprising to find in something as complex as a compiler.


Maybe I didn't read the article properly, but he doesn't seem to explain why this happens? Or is that because
he doesn't know either?


It's an infinite loop in lexer or parser, which allocates some memory on each iteration.


So it is an infinite loop and it just fails at 4 GB because it runs out of heap space? That's less exciting
than the title.

Yes, but more interesting considering the fact it is a well known and used lexer got put into an infinite loop,
not his code.


In 50 characters? I don't think you can do much in that space :-)

■_

2013年08月14日

■_

国会図書館行って、館内でしか閲覧できない電子データ(なんじゃそら)な論文を読みに行くつもりだったのだけど 論文の名前とか忘れてしまったw おっかしいなあどこかに記録してたはずなんだけど

横断歩道を渡っていたら逆走かつ信号無視の自転車に当てられそうになった。

■_ いでぃおむ

while(*d++=*s++); - Yahoo!知恵袋

while(*d++=*s++); - Yahoo!知恵袋


別の質問からの内容で大変恐縮なのですが、
while(*d++=*s++);
について、keicha_hrsさんは酷い例だと回答されていたかと思います。
>http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1211173455...

また、"実用では絶対にするべきではない書き方"ともあります。
この点について、どういう理由からでしょうか?
(それほど気にする内容なのかな?と思い、真意を伺ってみたく、質問させていただきました)

理由として
* null文字が"\0"(=0)であるとは限らない。
* 評価をwhile内側でやらない。(個人的になるべくしないようにしています)
* 優先順位が混在する書き方はしない(わかりづらいので)
などかと考え付きましたが、どれも違う気がしています。

何分、素人ですので誤解や理解不足があるかと思います。
また、いきなりで不躾な質問と思いましたが気になりましたので。。。

大変身勝手な質問ですが、ご回答いただければ幸いです。

回答を見てるとなかなか。 あわせてこちらも。 while(*d++ = *s++);がよくわかりません。 - Yahoo!知恵袋 で、まあ新しく書くコードでは使わない方が良いんでしょうねえ。たぶん。 Zed が執筆中のアレでもそうなってたような。

■_ PEP8

ということで PEP 8 Modernisation | Hacker News のリンク先 peps: fb24c80e9afb で変更点を確認するとなかなか面白かったという話です。いまさら。 一行80桁制限がちょっと緩和されたというのはおいといて

    1.34 -Two good reasons to break a particular rule:
    1.35 +In particular: do not break backwards compatibility just to comply with
    1.36 +this PEP!
    1.37  
    1.38 -1. When applying the rule would make the code less readable, even for
    1.39 -   someone who is used to reading code that follows the rules.
    1.40 +Some other good reasons to ignore a particular guideline:
    1.41 +
    1.42 +1. When applying the guideline would make the code less readable, even
    1.43 +   for someone who is used to reading code that follows this PEP.
    1.44  
    1.45  2. To be consistent with surrounding code that also breaks it (maybe
    1.46     for historic reasons) -- although this is also an opportunity to
    1.47     clean up someone else's mess (in true XP style).
    1.48  
    1.49 +3. Because the code in question predates the introduction of the
    1.50 +   guideline and there is no other reason to be modifying that code.
    1.51 +
    1.52 +4. When the code needs to remain compatible with older versions of
    1.53 +   Python that don't support the feature recommended by the style guide.
    1.54 +
  
   1.261 -- Use class-based exceptions.
   1.262 +- Always use a def statement instead of assigning a lambda expression
   1.263 +  to a name.
   1.264  
   1.265 -  String exceptions in new code are forbidden, and this language
   1.266 -  feature has been removed in Python 2.6.
   1.267 +  Yes::
   1.268  
   1.269 -  Modules or packages should define their own domain-specific base
   1.270 -  exception class, which should be subclassed from the built-in
   1.271 -  Exception class.  Always include a class docstring.  E.g.::
   1.272 +      def f(x): return 2*x
   1.273  
   1.274 -      class MessageError(Exception):
   1.275 -          """Base class for errors in the email package."""
   1.276 +  No::
   1.277 +
   1.278 +      f = lambda x: 2*x
   1.279 +
   1.280 +  The first form means that the name of the resulting function object is
   1.281 +  specifically 'f' instead of the generic ''. This is more
   1.282 +  useful for tracebacks and string representations in general. The use
   1.283 +  of the assignment statement eliminates the sole benefit a lambda
   1.284 +  expression can offer over an explicit def statement (i.e. that it can
   1.285 +  be embedded inside a larger expression)
  

かわいそうな lambda …

■_

2013年08月13日

■_

今日になって気づいたのだけど 8/11 の一日限定半額品。 これは欲しかったなあ(値引きでないと買おうとしないやつ)。 まあまたやってくれるだろう。うん。 Manning: Hello App Inventor!

四日目w
回り忘れてた評論系のいくつかが委託で出ていたので買うなど。

■_

昨日 (8/12)、C と C++ の違いがどうのというツイートが流れてきてたのだけど 背景やらなんも情報がなかったのでなんのこっちゃと思ってたんですが これが発端かな?

■_ TODO

perl-5.18.1 - The Perl 5 language interpreter - metacpan.org をみてて、TODOにどんなもんがあるのか気になった。 意外にたくさんあってびっくり。

気になったのものを幾つか

todo - Perl TO-DO list - metacpan.org
Automate perldelta generation

The perldelta file accompanying each release summaries the major changes. It's mostly manually generated
currently, but some of that could be automated with a bit of perl, specifically the generation of

Configure Windows using PowerShell

Currently, Windows uses hard-coded config files based to build the config.h for compiling Perl. Makefiles are
also hard-coded and need to be hand edited prior to building Perl. While this makes it easy to create a perl.exe
that works across multiple Windows versions, being able to accurately configure a perl.exe for a specific
Windows versions and VS C++ would be a nice enhancement. With PowerShell available on Windows XP and up, this
may now be possible. Step 1 might be to investigate whether this is possible and use this to clean up our
current makefile situation. Step 2 would be to see if there would be a way to use our existing metaconfig units
to configure a Windows Perl or whether we go in a separate direction and make it so. Of course, we all know what
step 3 is.

Use secure CRT functions when building with VC8 on Win32

Visual C++ 2005 (VC++ 8.x) deprecated a number of CRT functions on the basis that they were "unsafe"
and introduced differently named secure versions of them as replacements, e.g. instead of writing

  FILE* f = fopen(__FILE__, "r");

one should now write

  FILE* f;
  errno_t err = fopen_s(&f, __FILE__, "r");

Currently, the warnings about these deprecations have been disabled by adding -D_CRT_SECURE_NO_DEPRECATE to the
CFLAGS. It would be nice to remove that warning suppressant and actually make use of the new secure CRT functions.

There is also a similar issue with POSIX CRT function names like fileno having been deprecated in favour of ISO
C++ conformant names like _fileno. These warnings are also currently suppressed by adding
-D_CRT_NONSTDC_NO_DEPRECATE. It might be nice to do as Microsoft suggest here too, although, unlike the secure
functions issue, there is presumably little or no benefit in this case.

Write an XS cookbook

Create pod/perlxscookbook.pod with short, task-focused 'recipes' in XS that demonstrate common tasks and good
practices. (Some of these might be extracted from perlguts.) The target audience should be XS novices, who need
more examples than perlguts but something less overwhelming than perlapi. Recipes should provide "one pretty
good way to do it" instead of TIMTOWTDI.

Rather than focusing on interfacing Perl to C libraries, such a cookbook should probably focus on how to
optimize Perl routines by re-writing them in XS. This will likely be more motivating to those who mostly work
in Perl but are looking to take the next step into XS.

Deconstructing and explaining some simpler XS modules could be one way to bootstrap a cookbook. (List::Util?
Class::XSAccessor? Tree::Ternary_XS?) Another option could be deconstructing the implementation of some simpler
functions in op.c.

/w regex modifier

That flag would enable to match whole words, and also to interpolate arrays as alternations. With it, /P/w
would be roughly equivalent to:

  do { local $"='|'; /\b(?:P)\b/ }

See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-01/msg00400.html for the discussion.
optimize tail-calls

Tail-calls present an opportunity for broadly applicable optimization; anywhere that return foo(...) is called,
the outer return can be replaced by a goto, and foo will return directly to the outer caller, saving
(conservatively) 25% of perl's call&return cost, which is relatively higher than in C. The scheme language
is known to do this heavily. B::Concise provides good insight into where this optimization is possible, ie
anywhere entersub,leavesub op-sequence occurs.
Add 0odddd

It has been proposed that octal constants be specifiable through the syntax 0oddddd, parallel to the existing
construct to specify hex constants 0xddddd
Add class set operations to regexp engine

Apparently these are quite useful. Anyway, Jeffery Friedl wants them.

PowerShell でごにょごにょというのは面白そう。

■_ パッチ?

定番テキストエディター「Vim」が7.4にバージョンアップ - 1,000箇所にも及ぶパッチと新しい正規表現エンジン | パソコン | マイナビニュース

定番テキストエディター「Vim」が7.4にバージョンアップ - 1,000箇所にも及ぶパッチと新しい正規表現エンジン | パソコン | マイナビニュース

8月10日(現地時間)、Vim.orgはUNIX系OSで定番に数えられるテキストエディター「Vim(ヴィム)」の最新バージョンとなる
「7.4」のリリースを公式サイトや、Googleグループ上の「vim_announce」で発表した。

開発メンバーの一人であるBram Moolenaar氏は「1,000箇所にも及ぶパッチを適用し、新しく速い正規表現エンジンを搭載
した」と述べている。その他の変更点はVim 7.4をインストールし、「:help version-7.4」とコマンドを実行することで確
認可能。公式サイトからはWindows OS用の「gVim」やOS X版となる「MacVim」などのリンクが用意されていた。

マイナーバージョンアップでも新規リリースのときに「パッチを適用」とかいうのかなあと思いつつ vim のサイトを見ると

welcome home : vim online

[2013-08-10] Finally, after more than a thousand patches, there is a new version of Vim. This is mostly a
bug-fix release. Also, many runtime files have been improved, syntax highlighting and indenting works better.
To find out the details, do ":help version7.4" after installing it. Direct link to the MS-Windows
installer. For Linux you probably want to use Mercurial for convenient building. For MacVim look here.
Otherwise see the download page. (Bram Moolenaar) 

「more than a thousand」 だから「1000箇所にも及ぶ」よりは「千個を超える」じゃなかろうか というのはさておき確かに「patches」ってありますね。

テキストエディタ「Vim 7.4」リリース | SourceForge.JP Magazine Vim Gets Faster Regex Engine, 1000+ Fixes And Small Improvements

■_

■_

あ、PEP8ネタまだ書いてなかった。

2013年08月12日

■_

埼京線→りんかい線直通で会場に向かったのですがまさにこんな状態でした。 写真よりもちょっと早い時間帯ですが。 【人多すぎてやばい】 コミケと通勤ラッシュが重なり りんかい線が臨界突破wwww : オレ的ゲーム速報@刃

うーむ前は通ってるはずなのに見た記憶がないのがいくつか UNIXユーザーのためのコミケット84情報ページ

■_

■_

後者は以前にもどこかで耳にした(目にした)覚えがあるな。どこだっけ。

■_

会社が夏休みに入ってて良かった…

2013年08月11日

■_

暑かった…。ということでまとめるキリョクも残っていませんでしたw

本日の最優先目標はこの辺でした。 日本初!?ソフトウェアメトリクスの同人誌を発行します! - TEF東海メトリクス勉強会 私なりの問題提起を3つの同人誌記事として寄稿:森崎修司の「どうやってはかるの?」:ITmedia オルタナティブ・ブログ 手前味噌ですが、コミケで販売される同人誌に3件寄稿しました。誌名50音順で紹介します。3誌は横にならぶそうです。 三つのスペースを順番に。

混雑度がとんでもなかったのと、移動範囲が結構広かった(目当てのサークルがあちらこちらに点在)のとで 回りそびれたのやら忘れてしまったのやら。 苦労して西に移動したはいいが目当ての新刊が「落ちて」て その場でへたり込みそうにw 数日前にtwitter でその旨アナウンスあったんですね確認すると。 パッケージ等でよく見る「あの短い英文」の正体って何なの? 同人誌「プロダクトポエトリー研究」をC84にて無料で配布します – 日本同人誌デザイン協会 棚から一掴み ★コミックマーケット84 新刊のご案内

■_

あ、そうそう。mruby 本を予定していたサークルがあったのですが、 間に合わなかったらしくサンプル本の配布になってたのが残念。 UNIXユーザーのためのコミケット84情報ページ


一つ前へ 2013年8月(上旬)
一つ後へ 2013年8月(下旬)

ホームへ


リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp