ときどきの雑記帖 2012


一つ前へ 2012年4月(下旬)
一つ後へ 2012年5月(中旬)





■_ C!

階層構造を持ったモジュール云々という話に関しては、 オブジェクト(と実行ファイル)にも踏み込まないとダメじゃないかなあ とは常々思ってます。 詳しくは書かないけどw

C! - system oriented programming - LSE Blog
    C! - system oriented programming

    Written by Marwan Burelle
    May 09, 2012 at 14:52

        This is a first article, intended to be an introduction to to C!, more articles
        presenting syntax and inner parts of the compiler will follow.

    C! is one of our projects here at LSE (System Lab of EPITA.) It is a programming 
    language oriented toward lower-level system programming (kernel or driver for example.)

    C! は(カーネルやドライバーのような)低水準のシステムプログラミングを指向したプログラミング言語です

    We were looking for a modern programming language for kernel programming and after 
    trying some (D, C++, OCaml … ) it appears that most of them were too oriented toward 
    userland to be used in kernel programming context.

    わたしたちはカーネルプログラミングのための modern なプログラミング言語を探していて

    So we decide to modify and extend C to fit our need and quickly aim toward a new 
    programming language: C!

    新しい言語を作り出すことを目指すことにしたのです。それが C!

    Modern languages and kernel programming
    modern な言語とカーネルプログラミング

    Most parts of kernel code are rather classical: data structures, algorithms and a lot
    of glue. But, some crucial aspects require lower-level programming: direct management
    of memory, talking to specific CPU part (interruption management, MMU … ), complete
    control over data layout, bit-by-bit data manipulation …

    カーネルのコードの大部分はとても classical なものです。
    データ構造があり、アルゴリズムがあり、そしてたくさんの glue (糊)。
    しかし、一部の重要なものは低水準 (low-level) のプログラミングを要求しているのです。
    それはメモリーの直接的な管理であったり、CPU の特定の部分(割り込みの管理、MMU、など)

    Thus, to write some kernel code (or a complete kernel) we need a native language with
    direct access to this kind of low-level operations. This implies the ability to include
    ASM code somehow, to manage function calls from ASM and to build standard functions
    (so you can have function pointers for various interruption mechanisms.)

    今挙げたような低水準操作に対する直接的なアクセスができる native な言語が

    And, since you're not in user-land, you can't use user-land facilities (standard system
    libs for example). For most languages this means that you must rewrite memory
    allocators and tools that come shipped with them (especially for managed memory 
    languages using garbage collection).

    さらに、ユーザーランドにいないのでユーザーランドの facilities (たとえば標準システムライブラリ)
    (特に、ガーベジコレクションを使っている managed memory な言語の場合)。

    Another issue is the binary format: when writing user-land programs, your compiler 
    builds a file suited for the kernel binary loader. On most current Unix systems, your 
    file will respect the ELF format. Of course, you can write an ELF loader in your 
    bootloader (or any part of your booting process for that matters) but since you are 
    managing memory and memory mapping, you can't rely on the way a program is loaded on 
    your system and thus the organization of your ELF must reflect these constraints.

    期待できないのです。したがって、ELF であってもこういった制約を反映した

    Of course, this issue is not language dependent, even with a pure ASM or C kernel, you
    will have to control the way your linker builds the final binary. But, in C (and
    obviously in ASM) there are no major issues there, the structure of your program will
    be sufficiently simple so that the only important question is: where will I be in 

    pure なアセンブラや C のカーネルに対してさえ

    So, what's wrong with modern languages?
    では、modern な言語で間違っていることとはなにか?

    For the most evolved ones such as languages with transparent memory management and 
    garbage collection, one of the most important problem is to provide a replacement for 
    all aspects of the standard libraries of the system: memory allocator, threads and 
    locks management, etc. And in that case some aspects just can't be rewritten the same 
    way it is in user-land.

    The C++ situation is somehow better and worse: in theory there is less runtime needs
    than most modern languages. The good part is that you can bypass the most problematic
    elements of C++ (such as RTTI or exceptions) so you don't have to fight against them.
    Once you've deactivated problematic features and found what can't be used without them,
    you have to provide runtime elements needed by your code: start-up code, pure virtual
    fallback, dynamic stack allocation code, dynamic memory allocation for new and delete
    operators (for objects and array) …

    Roaming here and there, you'll find documentation on how you can write your C++ 
    kernel, but let's face it: is the required work really worth the pain?

    What's wrong with C (Cで間違っているところ)

    So, if you're still reading me, this means that you're partially convinced that using
    C++ (or D, or OCaml, or … ) is not a good idea for your kernel. But, why not go on with
    the good old C programming language?

    Since it was designed for that job, it is probably the best (or one of the best) fit
    for it. But, we want more.

    Here is a quick list of what we may find wrong or missing in C:
    C に欠けていたりCが間違っていること

        The C syntax contains a lot of ambiguous traps
        C の構文にはたくさんの ambiguous なわながある

        While the type system of C is basically size based, a lot of types have an ambiguous size (int for example)
        C の型システムは大きさに基づいたものであるにもかかわらず型の多くはその大きさが曖昧である

        Controlling size and signedness of integers is often painful
        整数の大きさや符号を操作することは大抵 painful である

        There is no clean way to provide some form of genericity or polymorphism
        genericity や polymophism (多態) といったものを提供するための clean な方法がない

        There's no typed macros

        The type system and most static verification mechanisms are too basic compared to what could be done now
        型システムや静的な検査機構の大部分が今の時代には basic なものすぎる

        C miss a namespace (or module) mechanism

        While you can do object oriented programming, it is tedious and error prone

    In fact, the above list can divided in two categories:

        syntax and base language issues

        missing modern features
        欠けている modern な機能

    Genese of C!

    Once we stated what was wrong with C, I came up with the idea that we could write a
    simple syntactic front-end to C or a kind of preprocessor, where we would fix most 
    syntax issues. Since we were playing with syntax, we could add some syntactic sugar as 

    We then decided to take a look at object oriented C: smart usage of function pointers
    and structures let you build some basic objects. You can even have fully object oriented
    code. But while it is dead simple to use code with object oriented design, the code
    itself is complex, tedious, error prone and most of the time unreadable. So, all the
    gain of the OOP on the outer side, is lost on the inner side.

    So why not encapsulated object oriented code in our syntax extension ?

    But, OOP means typing (Ok, I wanted static typing for OOP.) And thus, we need to write
    our own type system and type checker.

    Finally, from a simple syntax preprocessor, we ended up with a language of its own.


    Designing and implementing a programing language implies a lot of work: parsing, static
    analysis (mostly type checking), managing syntactic sugar, and a lot of code
    transformations in order to produce machine code.

    While syntactic parts and typing are unavoidable, code productions can be shortened
    somehow: you write a frontend for an existing compiler or use a generic backend such as
    LLVM. But you still need to produce some kind of abstract ASM, a kind of generic machine
    code that will be transformed into target specific machine code.

    The fact is that a normal compiler will already have done a lot of optimization and
    smart code transformation before the backend stage. In our case, this means that we
    should do an important part of the job of a complete C compiler while we are working
    with code that is mainly C (with a different concrete syntax.)

    The last solution (the one we chose) is to produce code for another compiler: in that
    case all the magic is in the target compiler and we can concentrate our effort on
    syntax, typing and extensions that can be expressed in the target language.

    Based on our previous discussion, you can deduce that we chose to produce C code. 
    Presenting all aspects of using C as a target language will be discussed further in a 
    future article.

    Syntactic Sugar

    An interesting aspect of building a high-level language is that we can add new shiny
    syntax extensions quite simply. We decided to focus on syntax extensions that offer
    comfort without introducing hidden complexity.

    Integers as bit-arrays

    In lower-level code, you often manipulate integers a bit at a time, so we decided to
    add a syntax to do that without manipulating masks and bitwise logical operands.

    Thus, any integer value (even signed, but this may change, or trigger a warning) can
    be used as array in left and right position (you can test and assign bit per bit your

    A small example (wait for the next article for full syntax description):

    x : int<+32> = 0b001011; // yes, binary value!
    t : int<+1>;
    t = x[0];
    x[0] = x[5];
    x[5] = t;

    Assembly blocks

    When writing kernel code, you need assembly code blocks. The syntax provided by gcc is
    annoying, you have to correctly manage the string yourself (adding newline and so on.)

    gcc が提供するアセンブリコードブロックのための構文は annoying で、

    On the other hand, I don't want to add a full assembly parser (as in D compiler for
    example.) Despite the fact that it is boring and tedious, it implies that the language
    is stuck to some architectures and we have to rewrite the parser for each new
    architecture we need …


    In the end, I found a way to integrate asm blocks without the noise of gcc but keeping
    it close enough to be able to translate it directly. Of course, this means that you
    still have to write clobber lists and stuff.

    A little example (using a typed macro function):

    #cas(val: volatile void**, cmp: volatile void*, exch: volatile void*) : void*
      old: volatile void*;
      asm ("=a" (old); "r" (val), "a" (cmp), "r" (exch);)
                cmpxchg %3, (%1)
      return old;

    Macro stuff

    Actually, C! has no dedicated preprocessing tools but we included some syntax to provide
    code that will be macro rather than functions or variables.

    First, you can transform any variable or function declaration into a kind of typed macro
    by simply adding a sharp in front of the name (see previous example). The generated code
    will be a traditional C macro with all the "dirty" code needed to manage return,
    call by value and so on.

    The other nice syntax extension is macro classes: a macro class provides methods (in fact
    macro functions) on non object types. The idea is to define simple and recurring
    operations on a value without boxing it (next article will provide examples).


    Another missing feature of C is a proper module mechanism. We provide a simple module
    infrastructure sharing a lot (but far simpler) with C++ namespaces. Basically, every C!
    file is a module and referring to symbols from that module requires the module name,
    like namespaces. Of course you can also open the module, that is making directly
    available (without namespace) every symbol of the module.

    わたしたちは C++ の名前空間と多くを共有する(しかし格段にシンプルな)
    モジュール infurasturacture を提供します。
    基本的にはすべてのC! ファイルはひとつのモジュールであり
    and referring to symbols from that module requires the module name, like namespaces.
    そのモジュールにあるすべての(namespace 抜きの)シンボルを直接扱えます。

    Namespaces provide a simple way to avoid name specialization: inside the module you can
    refer to it directly and outside you use the module name and thus no inter-module
    conflict could happen.

    名前空間は name specialization を除去するためのシンプルな方法を提供します。

    What's next

    In the next article of this series I will present you with C! syntax, the very basis of
    the object system and macro stuff.

    The compiler is still in a prototype state: all features described here are working,
    but some details are still a bit fuzzy and may need you to do some adjustments in the
    generated code.

    As of now, you can clone C! on its LSE git repository, take a look at the examples in
    the tests directory and begin writing your own code. Unfortunately, we don't have an
    automated build procedure yet, so you will have to do it step by step.

© LSE 2012 — Main website — RSS Feed

■_ C!


C! - new system oriented programming language : programming

This name will be so easy to google for!

I love C!

Oh, the modern irony!

Remember to name it after C, but with a special character at the end.

C++,C--,C#,Cω,C♫, C₀ and C! are already taken, might I recommend "C-:"? It looks something like a smiley face.

Cಠ_ಠ maybe?


How about C+- (C more or less).

You mean C±.

C∓ is a much better language

■_ safety-critical software


Ada の名前があがりますねー

Which languages are used for safety-critical software? - Stack Overflow

I'm researching the development of safety-critical software, and in particular what effects the choice of programming language has on such development.

Please explain, in detail, which languages are commonly used, and why.

Ada and SPARK (which is an Ada dialect with some hooks for static verification) are 
used in aerospace circles for building high reliability software such as avionics 
systems. There is something of an ecosystem of code verification tooling for these 
languages, although this technology also exists for more mainstream languages as well.

Erlang was designed from the ground up for writing high-reliability telecommunications 
code. It is designed to facilitate separation of concerns for error recovery (i.e. the 
subsystem generating the error is different from the subsystem that handles the error). 
It can also be subjected to formal proofs although this capability hasn't really moved 
far out of research circles.

Functional languages such as Haskell can be subjected to formal proofs by automated 
systems due to the declarative nature of the language. This allows code with side 
effects to be contained in monadic functions. For a formal correctness proof the rest 
of the code can be assumed to do nothing but what is specified.

However, these languages are garbage collected and the garbage collection is 
transparent to the code, so it cannot be reasoned about in this manner. Garbage 
collected languages are not normally predictable enough for hard realtime applications, 
although there is a body of ongoing research in time bounded incremental garbage 

Eiffel and its descendants have built-in support for a technique called Design By 
Contract which provides a robust runtime mechanism for incorporating pre- and post- 
checks for invariants. While Eiffel never really caught on, developing 
high-reliability software tends to consist of writing checks and handlers for failure 
modes up-front before actually writing the functionality.

Although C and C++ were not specifically designed for this type of application, they 
are widely used for embedded and safety-critical software for several reasons. The 
main properties of note are control over memory management (which allows you to avoid 
having to garbage collect, for example), simple, well debugged core run-time libraries 
and mature tool support. A lot of the embedded development tool chains in use today 
were first developed in the 1980s and 1990s when this was current technology and come 
from the Unix culture that was prevalent at that time, so these tools remain popular 
for this sort of work.

While manual memory management code must be carefully checked to avoid errors, it 
allows a degree of control over application response times that is not available with 
languages that depend on garbage collection. The core run time libraries of C and C++ 
languages are relatively simple, mature and well understood, so they are amongst the 
most stable platforms available. Most if not all of the static analysis tools used for 
Ada also support C and C++, and there are many other such tools available for C. There 
are also several widely used C/C++ based tool chains; most tool chains used for Ada 
also come in versions that support C and/or C++.

Formal Methods such as Axiomatic Semantics (PDF), Z Notation or Communicating 
Sequential Processes allow program logic to be mathematically verified, and are often 
used in the design of safety critical software where the application is simple enough 
to apply them (typically embedded control systems). For example, one of my former 
lecturers did a formal correctness proof of a signaling system for the German railway 

The main shortcoming of formal methods is their tendency to grow exponentially in 
complexity with respect to the underlying system being proved. This means that there 
is significant risk of errors in the proof, so they are practically limited to fairly 
simple applications. Formal methods are quite widely used for verifying hardware 
correctness as hardware bugs are very expensive to fix, particularly on mass-market 
products. Since the Pentium FDIV bug, formal methods have gained quite a lot of 
attention, and have been used to verify the correctness of the FPU on all Intel 
processors since the Pentium Pro.

Many other languages have been used to develop highly reliable software. A lot of 
research has been done on the subject. One can reasonably argue that methodology is 
more important than the platform although there are principles like simplicity and 
selection and control of dependencies that might preclude the use of certain platforms.

As various of the others have noted, certain O/S platforms have features to promote 
reliability and predictable behaviour, such as watchdog timers and guaranteed 
interrupt response times. Simplicity is also a strong driver of reliability, and many 
RT systems are deliberately kept very simple and compact. QNX (the only such O/S that 
I am familiar with, having once worked with a concrete batching system based on it) is 
very small, and will fit on a single floppy. For similar reasons, the people who make 
OpenBSD - which is known for its robust security and thorough code auditing - also go 
out of their way keep the system simple.

EDIT: This posting has some links to good articles about safety critical software, in 
particular Here and Here. Props to S.Lott and Adam Davis for the source. The story of 
the THERAC-25 is a bit of a classic work in this field.
For C++, the Joint Strike Fighter (F-35) C++ Coding Standard is a good read:




reddit 編

What's The Best Language For Safety Critical Software? : programming

I work in this field (specifically aerospace) and nearly always use the 'C' language 
(NOT C++) but we always use a restricted subset, MISRA Guidelines are often applied 
which should largly remove undefined behaviours and when done properly the tool 
qualification will involve understanding any erratas or weaknesses in your tools and 
further restrictions can be added to the coding standards. For instance if there is a 
problem using a shift operator with the specific compiler used then shift will be 
banned in the coding standards.

I have only seen C and Ada used, I have heard of C++ being used and assembler is 
always used for some aspects. You can in theory use any language but with safety 
critical you will need someone to agree and sign off on your choice. In aerospace the 
cert authorities will most likely be reluctant to let you choose something interesting. 
Everyone likes things that have been done before, so C and Ada dominate.

practically right now, probably still ada.

When I was in aerospace (20 years of it) I worked on safety-critical systems. On the 
systems I worked on, we used C and (in some cases) a very highly restricted subset of 
C++. Ada, at that time, was another option but there were several reasons to avoid it: 
back then, the tool chain was buggy and inefficient, and its cross-platform support 
was uneven-- though I hear that it's much improved now. And, as one of the commenters 
in the linked article pointed out, the methodology matters more than the tools. I 
might add that, for any nontrivial application, proving correctness is impossible too. 
The complexity of your proof will always be massively greater than the complexity of 
your code. At best you can have "islands" of provable correctness of some 
components (e.g, the code but not the OS or the full suite of hardware).

There are also engineering compromises. Some safety-critical code also has to have 
deterministic (hard) realtime performance. I worked on systems that required that 
certain pieces of processing never took longer than N milliseconds to complete. So 
this limits the opportunity to run garbage collection, and it also means that 
recursion has to be avoided, and lazy evaluation has to be looked at very hard as well.

Generally speaking, sophisticated language features are unhelpful in this world unless 
a normal human being can still understand exactly what the compiler has done with any 
given segment of code. Hence the continuing use of C.

Edit: I'm out of that game now, but I agree that some FP concepts are well-suited to 
safety-critical systems. But with the caveats I listed above. Some considerations are 
quite implementation-specific.




形式手法入門―ロジックによるソフトウェア設計― 組み込みソフトへの数理的アプローチ: 形式手法によるソフトウェアの仕様記述と検証 (COMPUTER TECHNOLOGYシリーズ) Interface (インターフェース) 増刊 組み込みシステム開発に役立つ理論と手法 2012年 05月号 [雑誌]






Ruby/Ruby on Rails 開発者に求められるスキルとは

What skills are required to become a Ruby/Ruby on Rails developer? : ruby

Ruby and Rails being the obvious choices, what other things do I need to know to begin 
developing with Ruby?

    You already know you'll need to learn Ruby.

    After you learn Ruby, learn Rails. They aren't the same thing.

    You also need to understand HTML and CSS through-and-through, because even if you only do
    back-end work you'll be speaking HTML and CSS in your views along with your designers.

    Learn the version control system of the shop you plan to work for. If you don't know which
    they use or if you're going on your own, learn git.

    Get comfortable with the Unix command line (Terminal on Mac/Linux or Cygwin on Windows).

    Learning JavaScript is a good idea as well, because you should understand what the 
    front-end developers on your team are doing--or if you're on your own, you'll need to 
    do client-side programming.

    Find a good text editor (or IDE) and get used to it. Really used to it. Learn its keyboard
    shortcuts, its plugins, its quirks. You'll be spending a lot of time in it. I suggest vim,
    emacs, Sublime Text 2, or Aptana Studio.


    You'll need to understand basic programming concepts. Object-orientation (in Ruby: methods,
    objects, classes, modules), controlling the flow of a program, debugging, running test units,
    and such.

    You'll need to understand Model-View-Controller architecture, because that's the way Rails works.

    You should understand the ins and outs of your version control system, including how to
    efficiently use branches and ideally how to use an online repository site (github, Google
    Code, etc.)

    You should understand the way regular people interact with computers. Have a basic idea of
    UX (user experience) design.

    You should know how to deploy an application ("to the cloud" if you will). Whether
    you deploy to a rails-specific host like Heroku or Engine Yard, or you deploy to your own
    Virtual Private Server, know how to get it up and keep it running.

    You should know the basics of how HTTP works so that you can optimize loading times. Speed
    means a lot to your users even if they don't consciously realize it.

    There's probably more I didn't list here as well.

Sarcastic Stuff ;-)

    Always know your PHP put-downs.

    Be ready to complain every time a new version of Ruby or Rails is released. I mean 
    sky-is-falling level complaining.

    Be sure to tell everybody that you use Ruby on Rails. Don't just tell people that ask about
    you being a programmer, tell everybody. Tell your mother. Tell your pastor. Tell your neighbor's

IAMA lead engineer at a ruby/rails company. We would look for these skills, roughly in order of importance, from a junior engineer:

    Some ruby/rails/java/other programming experience
    Able to write ruby code using blocks + general familiarity with ruby syntax
    Able to model the back end of a web app on a whiteboard (e.g. understanding ActiveRecord associations)
    Able to write a method that takes a block as an argument in ruby.
    Rails app code sample
    javascript/jQuery/Prototype experience
    SQL experience

If you had absolutely no coding experience, then you should have everything but the javascript and SQL. Those are bonuses (but big bonuses).


■_ C!


C! - system oriented programming - LSE Blog
 C! - system oriented programming 
 Written by Marwan Burelle 
 May 09, 2012 at 14:52 

This is a first article, intended to be an introduction to to C!, more articles presenting
syntax and inner parts of the compiler will follow. 

C! is one of our projects here at LSE (System Lab of EPITA.) It is a programming language
oriented toward lower-level system programming (kernel or driver for example.) 

We were looking for a modern programming language for kernel programming and after trying some
(D, C++, OCaml … ) it appears that most of them were too oriented toward userland to be used
in kernel programming context. 
So we decide to modify and extend C to fit our need and quickly aim toward a new programming
language: C! 


© LSE 2012 — Main website — RSS Feed 




イブニング しばちゅーさん レッド

■_ PL/M

とあることから Wikipedia(日本語版)の PL/I のところを見てたんですが、 PL/M のあたりの記述が

PL/I - Wikipedia



言語仕様が~CP/Mを作った。の文、何が言いたいのかよくわからん。 ひょっとして英語版を訳してこうなったのかと思って英語版を見ると (ってまあ日付までチェックしてないんですけどね)

PL/I - Wikipedia, the free encyclopedia

PL/I compilers for personal computers and Unix

    In 1972 Gary Kildall implemented a subset "PL/M" for Intel. PL/M was used to
    write the CP/M operating system proper - and much application software running on CP/M
    and MP/M. Digital Research sold a PL/I compiler[42] for the Personal Computer written
    in PL/M. PL/M was used to write much other software at Intel for the 8080, 8085, and
    Z-80 processors during the 1970s.

    PL/M-86 was a version of the PL/M language for the 8086 and 8088 microprocessor. It was
    heavily used by Daisy Systems for electronic design automation software on the "Logician"
    family of special-purpose workstations.

キルドールは PL/I のサブセットである PL/M を作った。 PL/M は CP/M (の一部)を書くのに使われた。 PL/M は Intel の 8080、8085、(ザイログの) Z-80 向けソフトウェアを記述するのに使われた。 ってなとこですよね。

■_ InfoQ


InfoQ: Microsoft to C99 Developers: Use ISO C++

Microsoft to C99 Developers: Use ISO C++

Posted by Jeff Martin on May 07, 2012

Microsoft has spent significant time and resources to promote developer interest in 
C++. The company's "Going Native" program has emphasized C++ development but 
what continues to be missing from this initiative is support for modern C as defined 
by the C99 standard. While compiler support for C99 varies across the industry, Visual 
Studio stands out by providing limited to non-existent compliance.

Microsoft は C++ に注力してますよ。と。
そのあおり?で、C については規格をしっかりと追いかけてはいない。

This failure to support C99 has frustrated developers requesting Visual Studio 
compatibility with the long time standard. If VS supported C99 natively, it would be 
easier for users to develop and port existing cross-platform applications. Google 
developer Josh Haberman recently listed several popular projects written in C in his 
recent plea for Microsoft to adopt C99.  (Note that Haberman's website may be down, 
Google copy is available.)

C99 をきちんとサポートしていないことについては以前から不満の声が上がっていた。





更新が毎日じゃないのは twitter にどっぷりはまってるからじゃないですよ?

歴史群像 2012年 06月号 [雑誌]
歴史群像 2012年 06月号 [雑誌]


■_ How not to ask questions at a conference


How not to ask questions at a conference | Kevin Burke
How not to ask questions at a conference
Posted on May 5, 2012

I went to Pycon last month (my first conference ever!) The conference was totally 
awesome and I met a lot of cool people. But I was also pretty appalled at the question 
asking at the end of each talk. Here's some stuff you should keep in mind before you 
ask a question at a conference.

    Ask questions that you believe would be relevant to at least a third of the people in
    the room. Otherwise, avoid the temptation to show off your specialized knowledge to the
    room and just ask the speaker afterwards. Most of them are approachable on Twitter,
    email, or just in the hallways.


    Ask only one question. If you have more than one question, pick the best and ask the
    other one in private later. Or ask your first question and then go to the back of the
    line. Other people have questions to ask as well and may not get to ask one.


    Avoid buzzword bingo. It feels like lots of people walk up to the microphone just so
    the room can hear them mention some buzzword that indicates they know something about
    the topic. If I am running a Scrum team should I use Soak testing? How does Node.js
    influence the development of the PyPy project? If you wouldn't ask the question without
    a room full of people present, then don't ask.

    buzzword を使わない。

    Ask a question, don't make a comment. Talk time is for the speaker to be the expert, not
    you. Write up your comment as a blog post and post it for everyone to read later.

    コメントはチラシの裏自分の blog に書く

    Be brief. After a talk, time is precious and many people may have questions for the
    speaker, so don't ramble about how nice it is to finally see the speaker in person, or
    how enlightening the talk is, even if those things are true. It's a matter of courtesy
    to everyone else in the room.


There is an easy solution to bad questions that no one has bothered to implement yet. 
Have people submit questions anonymously and have the speaker or a moderator choose 
which ones to answer, or have the room vote using a tool like Google Moderator. This 
will solve the problem of the question asker-bragger asking a trivial question.

The other solution is to charge money to ask a question, which could go to whatever 
cause you want. If enough people in the room have the same question they can 
contribute to the fee to ask the question and have it asked.

Update: There's some good discussion on Hacker News. "If the question you're 
asking makes you look smart, there's a good chance you're being a douchebag."

Also my friend Alan Shreve wants to know if it's appropriate to push back if the 
speaker dodges your question.



Why is the first position in a string zero and not one? : programming

Why is the first position in a string zero and not one? (en.wikipedia.org)

Because strings (historically, from null-terminated C strings) are simply arrays of
characters, and arrays are zero-indexed.

For why arrays are zero-indexed, I defer the answer to our good friend Dijkstra.

    So let us let our ordinals start at zero: an element's ordinal (subscript) equals the
    number of elements preceding it in the sequence.

I guess this makes sense; thanks for the link. I found a wiki page on the topic, and it seems
that this is not a trivial issue.

Also interesting:

    The 0-based/1-based debate is not limited to just programming languages. For example,
    the elevator button for the ground-floor of a building is labeled "0" in France
    and many other countries, but "1" in the USA.

In some languages, the first character is at the index 1. It's the difference between the
relative position of a character with respect to an offset (0-based) vs. the absolute
position of a character (1-based).

because of hardware. A binary 2 is 10, a binary four is 100. However, in order to use all
possible bits of entropy, you have include the null case

ex: you're on a computer with two-bit bytes (for some reason). Thus, the different available
bytes are 00,01,10, and 11. To get the most out of your bytes, you use the 0 as the first in
a sequence, and can now specify four separate locations (powers of two are very useful in
binary computers). Same thing goes for 8 bits/byte, or any other schema.

because it makes us programmers seem more mysterious to the uninitiated




GW 終了~

検索してみたらリデル・ハートの著書のいくつかが図書館にあることがわかったので (家の近くの、ではなく同じ区の別の図書館所蔵ではあるのだけど)、 借りる手配をするなど。


昨日分で紹介した VC++ では C99 の機能をフルサポートしないよ という話を受けて。

Herb Sutter: No C99 support is planned. Use C++ instead. : programming

This is a sad situation with results like this:

Summary: CPython is C90 because VC won't support C99. No, you can't compile large C 
codebase as C++ and expect it to work, "very few cases" rhetoric 

It really is time to ask all projects like this whether it is worth their time to keep 
supporting a compiler that has been abandoned, when there are several other 
alternatives for building on Windows which have great support for C99 and are free, to 

Why keep holding your code back, making it less readable and maintainable, just to 
support an obsolete compiler? Tell your users how to use a real compiler to build your 
code, and be free of ridiculous limitations.

It is bitter to say this, but there is a reason to hold your code back, make it less 
readable and maintainable, just to support an obsolete compiler, if a compiler in 
question is the preferred choice by developers of the platform in question. Say, maybe 
it has a great debugger that developers love to use.

Python can be embedded, and some of heavy Python users include Windows game developers. 
Good luck convincing them to use anything other than VC...

Well, that is the whole point: It is to make those people complain to Microsoft that 
the current situation is not acceptable.

In the meanwhile, set up a way to build Python as a DLL in mingw and then link it into 
the VC project. This is a pain for them, but not so much they can't deal with it in 
the meanwhile.

Windows game A uses library B. Library B stops supporting VC. Then Windows game A 
developers complain to Microsoft?

More likely Windows game A switches to library C which still supports VC, even if it 
is slightly inferior to library B.

This is actually entirely analogous to IE6 situation. If you stop supporting IE6, 
users don't complain to Microsoft. Users switch to your competitor still supporting 
IE6. IE6 got obsoleted by people upgrading to IE7, IE8, IE9, IE10, not by sites 
dropping support.

what's worse? so many people relying on Windows and C or so many people relying on C on Windows?

So many people relying on Windows.

The goal is to force people to use other less convenient tools if they want cross-platform
compatibility, a typical Gates/microsoft tactic. To be honest I would have hoped with Gates
new Holy self he could put some pressure on microsoft to be more socially responsible.

Are there really that many cross-platform applications and libraries written in C that 
wants to use C99?

Pretty much every single one would benefit from C99 to some extent.



[Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?

[Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?
trunk はまだ変数を好きな場所で宣言できないコンパイラーをサポートし続けるのか?

Wed May 2 10:43:32 CEST 2012

Right now the CPython trunk religiously declares all variables at the 
tops of scopes, before any code, because this is all C89 permits.  Back 
in the 90s all the C compilers took a page out of the C++ playbook and 
independently, but nearly without exception, extended the language to 
allow you declaring new variables after code statements.  This became an 
official part of the language with C99 back in 1999.

現状の CPython trunk では決まってスコープの先頭、すべてのコードよりも前
ですべての変数を宣言しています。なぜなら C89 ではそれしか許されていないからです。
90年代、すべてのCコンパイラーは C++ playbook にあったアイデアを取り込みましたが
#and independently が
これは 1999年に C99 の一部として取り込まれました。

It's now 2012.  As I step out of my flying car onto the moving walkway 
that will glide me noiselessly into my platform sky dome... I can't help 
but think that we're a bit hidebound, slavishly devoting ourselves to 
C89.  CPython 3.3 drops support for VMS, OS/2, and even Windows 2000.

今は 2012年です。

わたしたちはいさかか守旧的で C89 に対するこだわりが強すぎるとわたしは考えます。
CPython 3.3 では VMS や OS/2、Windows 2000 のサポートも drop します。

I realize we can't jump to C99 because of A Certain Compiler.  (Its name 
rhymes with Bike Row Soft Frizz You All See Muss Muss.)  But even that 
compiler added this extension in the early 90s.

一部のコンパイラーのために C99 へ移行することができないとわたしは認識しています

Do we officially support any C compilers that *don't* permit 
"intermingled variable declarations and code"?  Do we *unofficially* 
support any?  And if we do, what do we gain?

"intermingled variable declarations and code"
を *許さない* すべてのCコンパイラーを公式にサポートすべきなのでしょうか?

Just itching to pull some local macro hijinx, is all,

■_ お題

回答にあるように awk でやるにはちと厳しい点もあるんだけど (gawk だと asort があるからなんとかなるけど)、 もうちょっとどうにかならんかなあと考えてみたり。

awkで項目番号ごとに行を列に並べる | OKWave


a  10   1
b  10   2
c  10   3
d  10   4
a  20   5
b  20   6
c  20   7
d  20   8
a  30   9
b  30   0
c  30   1
d  30   2

No.  a  b  c  d
10  1  2  3  4
20  5  6  7  8
30  9  0  1  2






■_ 新言語

またひとつ Elm: a new language for Functional-Reactive web programming. Learn the basics with in-browser interactive examples. : programming


The Elm Programming Language

The Elm programming language aims to make web development more pleasant. Elm is a type-safe,
functional reactive language that compiles to HTML, CSS, and JavaScript. You can start coding
in Elm without any install or setup with Elm's interactive editor, so start learning Elm by

プログラミング言語 Elm は web 開発をより pleassant にすることを目指したものです。
Elm は type-safe で HTMLやCSS、JavaScript へコンパイルする functional reactive 言語です。
Elm でのコーディングはなにもインストールしないでも始められますし、
Elm の対話型エディターをセットアップすることもできます。

Elm's major distinguishing features are support for reactive programming and its focus on
Graphical User Interfaces. Elm is also call-by-value and strongly / statically typed with type
inference, so those of you already familiar with Haskell or ML should be quite comfortable.

Elm の特筆すべき機能はリアクティブプログラミングのサポートと
Elm はまた call-by-value で、type interfacce を使って強く静的に型付けをします。

The language features mentioned above help catch errors in your code at compile time, but there
are some errors that are external to your code, such as browser incompatabilities. By using
HTML, CSS, and JavaScript as an assembly language, Elm can avoid some of these problems.





■_ なんでもリスト


Why not just use lists for everything? : lisp

Why not just use lists for everything? (self.lisp)

I'm reading through Practical Common Lisp, and while reading about vectors and hash tables,
I have to wonder, why bother with them when you have lists which can represent heterogeneous,
nested structures? Or rather, when would you use a list, and when would you use a
vector/hash table/etc.?

Computational complexity.

---------           -------------------   -----------   -------   ----------
Singly Linked List  O(n) average          O(n) average  O(n)      O(1)
Hash Table          O(1)                  costly        costly    O(1)
Extensible Vector   O(1)                  O(n) average  O(n)      O(1) amortized

Lists are great when you want to add something to the front or traverse it linearly, 
but for anything else the performance hit becomes severe.

Using a list as a hash will give you O(n) lookup time whereas hash tables should have 
constant time lookup.

Lists, alists, plists are great for prototyping and lisp has lots of built in 
functions for searching and manipulating them. They print nicely in the repl for 
debugging. And often the prototype using lists is good enough and does not need 
optimizing. And if you program smartly and abstract away the list structure, you can 
replace the list structure for whatever is more efficient.

You'd use a vector or hash table for speed and efficiency, mostly.

Vectors offer fast, random access to elements. Accessing an element in a vector by 
index is O(1), whereas the same in a list is O(n), as the underlying code in the 
latter is chasing the cdr's until it gets to the right place. For big data sets and/or 
repeated searches, the difference in performance can be stunning.

For hash tables, it's actually cheaper to use an alist for fewer than about a dozen or 
so elements: the linear search time is usually less expensive than computation of the 
hash code and the subsequent bucket lookup. Once you pass that threshold a hash table 
allows for faster value access.

One thing to bear in mind is that hash tables in Common Lisp are distinctly 
non-functional, in that you're modifying an existing table by applying a non-pure 
function (in contrast to Clojure's assoc or Erlang's dict:store). This may or may not 
be a concern.





■_ 「自由」とは

Twitter / @k3c: 「RuviEdit のライセンスは基本的にMITライ ... Twitter / @vivisuke: MIT/bsd系ではGPL系が使えないのだから、もし ... Twitter / @vivisuke: 自由自由詐欺のGPL系のソースはMITやbsdなど真 ...


Reader Q&A: What about VC++ and C99? « Sutter's Mill

Reader Q&A: What about VC++ and C99?

2012-05-03 by Herb Sutter

I occasionally get asked about whether, or how well, Visual C++ supports C99.

わたしはときおり、Visual C++のC99サポートについて尋ねられることがあります

    This week, I just posted two replies to this questions on UserVoice (merged below).
    Last fall, I also answered it in an interview with Dr. Dobb's (recommended for some rationale discussion).

The short answer is that Visual C++'s focus is to support ISO C code that is supported 
by ISO C90 or ISO C++ (98 or 11). For the longer answer, I'm combining my UserVoice 
answers below, plus an additional comment about restrict in particular.

その質問に対する短い回答は、Visual C++ の focus は ISO C90または ISO C++ (98または11) が
サポートする範囲での ISO C コードをサポートする。というものです。

Our focus in Visual C++ is on making a world-class C++ compiler, and we're heads-down on
C++11 conformance. For C programmers, the good news is twofold:

1. Our primary goal is to support "most of C99/C11 that is a subset of ISO C++98/C++11."
   わたしたちの primary な目標は 「ISO C++98/C++11 のサブセットの C99/C11 の大部分」をサポートすることである。

    VC++ 2010 already fully supports the C subset of C++98, including things like <stdint.h>
    and declarations in the middle of a block.[*] The C subset of C++98 is approximately C95
    (with very few incompatibilities with C95; i.e., there are very few cases where legal C95
    code has a different meaning or is invalid in C++98) plus a few C99 features like declaring
    variables in the middle of blocks).

    VC++ 2010 はすでにC++ 98 のサブセットとしての C を完全にサポートしていて、
    C++ 98の サブセットしての C はおおむね C95 にいくつかの C99 の機能を追加したものになっています

    VC++11 now in beta already adds partial support for the C11 subset of C++11 (e.g., it
    supports the new C11 atomic_int types for concurrency and parallelism).

    VC++11 は現在 βの状態にあり、C++11 のサブセットとしての C11 の
    (たとえば C11 の 並行/並列処理用の atomic_int types をサポートしています)。

    Soon after VC++11 ships we have announced we will do out-of-band releases for additional
    C++11 conformance which will naturally also include more C11 features that are in the C
    subset of C++11. We intend to implement all of the C++11 standard, which includes much of
    C99 — roughly, it includes the C99 preprocessor and library extensions but not the
    language extensions like restrict.

So we already support large subsets of C99 and some-and-soon-more of C11. Our immediate and
long-term goal is to fully support the C subsets of ISO C++.

So we already support large subsets of C99 and some-and-soon-more of C11.
ですからわたしたちはすでに C99 の large subset をサポートしているし、
C11 の some-and-soon-more をサポートしているのです。
わたしたちの直近の、そして long-term での目標は
ISO C++ のサブセットとしてのCを完全にサポートすることです。

2. We also for historical reasons ship a C90 compiler which accepts (only) C90 and not C++.

For the (hopefully rare) cases where legal C90 code has a different meaning in C++98 
and this matters to C developers, for backward compatibility with older C90 code we 
also continue to ship a C compiler that implements Standard C90 exactly (using /TC or 
naming files as something.c).

Granted, however, there is also bad news for C programmers:

3. We do not plan to support ISO C features that are not part of either C90 or ISO C++.
   C90 にも ISO C++ にも含まれない部分の ISO C の機能をサポートする計画はない

I understand C programmers may be disappointed or angry with this answer and I'm sorry to
have to say no here. It's true, and very quotable, that "focus means saying no,"
but that doesn't make it easy to say — it is hard to say no to you, and I'm sorry to say
it. But we have to choose a focus, and our focus is to implement (the standard) and innovate
(with extensions like everyone but which we also contribute for potential standardization)
in C++.

この回答に C プログラマーたちががっかりしたり怒りを覚えたりするであろうことをわたしは理解しています。


We recommend that C developers use the C++ compiler to compile C code (using /TP if 
the file is named something.c). This is the best choice for using Visual C++ to 
compile C code.

わたしたちは、C のコードをコンパイルするのに C++ コンパイラーを使うことを C developer たち
にはお勧めします。これは Visual C++ でCコードをコンパイルする最善の選択です。

Alternatively, we recommend that C developers use the C90 compiler (using /TC or 
naming files as something.c) if you need to write C90 conforming code that exercises 
some of the rarer cases that in C++98 are illegal or have changed meaning. This is a 
fallback primarily intended to support historical C code.

あるいは、C++98 では不法となってしまったり意味が変わってしまうような
C90 準拠のコードを書かなければならないのであれば
C90 コンパイラーを使うことをお勧めします。

If you really need either of the following:

    features in C95/C99/C11 that are not part of ISO C++; or
    ISO C++ には含まれない C95/C99/C11 の機能
    features in C that are in the C++ subset but without also enabling the writing of C++ code;
    C++ に含まれる C の機能ではあるけれども

then we recommend that you consider using a different compiler such as Intel or gcc 
(short-term) and/or pressure your standards committee representatives to have ISO C++ 
include more of the C standard (longer-term).

(短期的には) Intel コンパイラーや gcc のような別のコンパイラーの使用を検討することをお勧めします。
そして、(長期的には) ISO C++ がより多くの C standard を取り込むように
standards comittee に圧力を掛けることをお勧めします。

[*] Visual C++ also partly supports some C99 language features under a slightly different
syntax and possibly with slightly different semantics. Notably, we support __restrict – we
did (and could again) consider allowing the standard C99 spelling restrict here for this
feature, but please understand that this is not as simple as it looks. Not only the VC++
team, but also the ISO C++ standards committee, considered adding restrict to VC++ and ISO
C++, respectively. Although it was specifically suggested for ISO C++11, it was rejected,
in part because it's not always obvious how it extends to C++ code because C++ is a larger
language with more options and we would want to make sure the feature works correctly
across the entire language.


    on 2012-05-03 at 11:10 am sven

    Hi Herb,

    there is many so called C99 code out there, but that code is full of GCC extensions.
    At the moment everybody can declare all the code which don't compile with the VC compiler
    simply C99 code.

    So in my opinion we need a strong C99/C11 counterpart without the GCC extensions to get
    again more portable C Code.

    A few years ago programming C was the right decision to create portable code. (write once
    – compile everywhere in opposite of compile once – run somewhere) But now we get C99 code
    for linux/gcc which doesn't proper integrate into the windows platform.

    With your denial of C99 you contribute to the fragmentation of the C Language.

    on 2012-05-03 at 11:17 am Chris

    I think this is a very reasonable explanation. C++11 support is clearly more demanded than
    a pure C99/C11 compiler. As a C++ programmer I'm happy with the C subset of C++, it's
    important to keep the VC++ team's resources where they should be – implementing C++11.

    Also, as mentioned before, some official positive statements on the Windows XP issue are very welcome.
    on 2012-05-03 at 3:36 pm Doug Cook

    I think this is a rather silly approach. The Microsoft C compiler (the /TC version) is
    NOT C90. It accepts numerous Microsoft-only and C99-only extensions. There is a lot of
    low-hanging fruit that could easily be added to the C compiler that would make a lot of
    people happy with very little in the way of hurting backwards compatibility. I
    understand that the compiler front-end team is trying to keep its focus, but I think it
    is currently too focused on C++. C is important and deserves at least a little bit of

    There is a LOT of existing code out there that is valid C but is not valid C++. That code
    is not likely to be rewritten to make it work with Microsoft C. Instead, it will either
    be built using MinGW (which is a less-than-optimal experience) or the users will just
    switch to another operating system that has decent support for C (which is one of the most
    important programming languages in the world). I think the lack of Microsoft support for C
    really is costing Microsoft customers.

    Compiler front-end support could easily be added to support some of the simpler additions
    to C11. Even if the support isn't exactly 100% compliant, you could get 98% compliance for
    several C11 features with very little work. If necessary for backwards-compatibility, these
    changes could be conditionally provided via a /Zc flag. I know that no change is free, but
    I think a little love would go a long way here. At least a token effort, please?

    Should be easy to fix:

    - Anonymous structures should not be considered “nonstandard extension”.
    - C++ comments should not be considered “nonstandard extension”.
    - Flexible array members should not be considered “nonstandard extension”.
    - Keyword “inline” should be recognized and treated the same as existing keyword “__inline”.
    - Keyword “restrict” should be recognized and treated the same as existing keyword “__restrict”.
    - Keyword “_Alignof” should be recognized and treated the same as existing keyword “__alignof”.
    - Keyword “_Pragma” should be recognized and treated the same as existing keyword “__pragma”.
    - Keyword “_Noreturn” should be recognized and treated the same as existing attribute “__declspec(noreturn)”.
    - Keyword “_Thread_local” should be recognized and treated the same as existing attribute “__declspec(thread)”.
    - Keyword “_Static_assert” should be recognized and treated the same as C++ keyword “static_assert”. As a temporary easier fix, it could be treated the same as existing keyword “__static_assert”. __static_assert is not 100% the same as _Static_assert (__static_assert can be used in scopes where _Static_assert is illegal), but it's probably close enough to satisfy most people.
    - Preprocessor token “__func__” should be recognized and treated the same as existing token “__FUNCTION__”.
    - A supported (guaranteed to continue working in the next version) way to express INFINITY and NAN as a compile-time constant. Currently, INFINITY=(DBL_MAX+DBL_MAX) and NAN=(INFINITY-INFINITY) work, but these are not entirely satisfactory until the compiler team agrees to maintain them as valid test cases.
    - Define the appropriate macros for the features not supported, i.e. __STDC_NO_ATOMICS__, __STDC_NO_COMPLEX__, __STDC_NO_THREADS__, __STDC_NO_VLA__.

    Might take a weekend to implement and a week to test:

    - Support for declarations in the middle of the block. This exists in the C++ FE, so this may or may not be easy to port to C.
    - Keyword “_Bool” should be recognized and behave like C++ bool. It should be a 1-byte unsigned type, boolVar in an expression should act like “(_Bool)(boolVar ? 1 : 0)”, and assignments “boolVar = x” should evaluate as “boolVar = (x != 0)”. Not sure how easy, but it would be really helpful to have a Boolean type in C.
    - Keyword “_Alignas” should be recognized and work as specified. (This also needs to be done in C++.)
    - Mixing string literals should be legal, e.g. { L”a” “b” } should be the same as { L”a” L”b” }. (This also needs to be done in C++.)
    - Hexadecimal floating-point constants: 0×1.7ffp0L
    - Keyword _Generic(type, selectors) is really cool and useful. It enables a lot of very useful situations in C but avoids name mangling linkage issues related to other implementations of “overloading”.

    Better library conformance would also be nice, but library issues usually have 
    reasonable workarounds.

    Speaking of which, lack of XP and C99 support in VC11 is making me want to resume work on
    my “minwincrt” project. It was a very basic CRT implementation (STDC headers and lib)
    that worked with the VC10 compiler, tried to be C99-conforming, and linked as a static
    library to your app (so a simple “hello world” exe ends up being about 4k and depends
    only on kernel32.dll). Maybe I should go back to working on that. I don't think there is
    any reason why it wouldn't be able to work with VC11 and create XP-compatible apps. (Note
    that I don't mean to say that I disagree with Microsoft making VC11 target Vista or later,
    since that helps keep the CRT size down and improve CRT performance. It would just be nice
    to have a fallback option.)



Memory efficient way to store strings in hash maps using boost::array | Jovislab dev blog


First of all, let's take a look what does make the overhead when using std::string class
(GNU ISO C++, G++ 4.6.2 -O2 optimizations, 32 bit binary, Linux Fedora 16 x86)::

まず初めに、std::string クラスを使ったときのオーバーヘッドを見てみましょう

    pointer to the text data (4 bytes),
    length of the data (4 bytes),
    length of the allocated data (4 bytes),
    reference counter (4 bytes)

Additional data: 16 bytes. If created on the heap, additional 4 bytes will be occupied 
to store size of allocated memory. In total – 24 bytes. Also, memory alignment may be 
applied. In my case, allocated memory size is rounded to 8 bytes, but it is at least 
16 bytes. Take into account that it is OS and compiler specific, though.

この数字は OS やコンパイラーに依存するものです。

How about size of the actual text data? Let's consider the smallest non-empty string, 
eq. “a”. It will consume 1 byte + null terminating character. Take a look that it is 
always allocated on the heap, therefore extra size data will have to be stored, as 
well as alignment applied. In total, in my environment it is 16 bytes.

空文字列ではない最も小さな文字列 "a" で考えてみましょう。
これは 1 バイトに null 終端キャラクターを加えた分だけ消費します。
extra size data を格納する必要があり、
トータルで(わたしの環境の場合) 16バイトとなります。

Let's sum up. The “j” string stored as std::string object, when allocated using new 
operator will consume 40 bytes. It is 40 times more than our one-byte “j” character. 
It is 3900 MB of overhead per 100 MB of actual data. Pretty much of overhead, isn't it?

合計しましょう。"j" という内容の std::string オブジェクトは
new 演算子を使って割り当てられたときに40バイトを消費します。
これは、"j" という一バイトのcharacterの40倍の大きさです。
実データが 100 メガバイトであれば 3900メガバイトのオーバーヘッドがあります。

So, how to do it better?

We have to limit amount of additional data. Let's go through the list of additional 
data above and consider what can we remove, and what will be the consequences.

    Pointer to the text data (4 bytes).
        If removed, then size of the data will have to be a member of the class. Therefore
        it's size will have to be known in compile-time. It is a very strict assumption.

    Length of the data (4 bytes).
        Can be removed, but we getting length of the array will be O(n) instead of O(1) in
        term of complexity.

    Length of the allocated data (4 bytes).
        If we don't want to perform string manipulation, then we can remove this member.

    reference counter (4 bytes)
        This is just used for a speed optimization. If we do not want to manipulate the
         string very often, then this member is unnecessary.






テルマエ戦記 テルマエ戦記
読んだ。 基本的にblogの内容をまとめたものらしいけどそっちは知らなかったので 楽しく読めた。

ソーシャルゲームのすごい仕組み (アスキー新書)
を読んだんですが例によって重箱の隅が気になるw とりあえず二箇所。

p52 今30代、40代の読者であれば学校が、 終わればファミコンのある友人宅に集まり、 ゲームを順番にプレイしたことを懐かしく思い出せる人も多いはずだ。 余談だが、 カセットテープからプログラムを読み込ませる必要のあったMSX全盛のころは、 1つのゲームを読み込ませるのに30分近くかかることも珍しくなかった。 (略) カセット方式でこの待ち時間から解放されたときには、 筆者も子どもながら感慨を覚えたものだ。

p96 初代ドラクエでは64キロバイト、つまり80枚分(本書のちょうどこのあたりまでの文字数だ) の容量しかないカセットROMに、

MSX でもカセットテープを使ったのは少数派じゃないかなあ。 MSX 全盛の時期ではカセットテープを使ったパソコンがたくさん使われていた という話なら書き方がおかしい気がする。

後者はなんの80枚分なのかが不明。 とりあえず400字詰め原稿用紙かなあと考えてみると 400×80→32000。2バイト一文字としてまあそんな勘定か。

All sizes | fp-influences | Flickr - Photo Sharing!

■_ with

きちんと訳したいところなのだけど 時間的に色々厳しいので見出しをピックアップ

So, you you want to write software?: Life Without Objects

Monday, 30 April 2012
Life Without Objects

Over the last few years I have been learning and experimenting with a wider range of 
programming languages. In particular I have started using Scala as my primary 
development language, adopting a more and more functional style. I have also become 
very interested in Haskell (a pure functional language) and Clojure (a modern lisp 

I have therefore been moving away from the object-oriented development principles that 
have made up the bulk of my 17 year career to date. More and more I am beginning to 
feel that objects have been a diversion away from building concise, well structured 
and reusable software.

As I pondered on this topic, I realised that this isn't a sudden switch in my thinking. 
The benefits of objects have been gradually declining over a long period of time. The 
way I use objects today is very different to how I used them when they were new and 
shiny. In this post I explore this change in my thinking about object-oriented 

The Promise of Objects

Back in the 1990s, objects were new and exciting. The promise of being able to create 
reusable classes built around common design patterns was seductive. The ability to 
then combine these classes into reusable and configurable business components seemed 
like the Mecca of software development. New languages like C++ and then, slightly 
later, Java held the promise of a new way of building great software.

再利用可能で configurable な business components とする 能力は
the Mecca of software development のようでした。
C++ や、かなり遅れて現れた Java のような新しい言語は
great software を構築する新しい手法を保証していました。

© 2010 Chris Turner. Ethereal template. Powered by Blogger.

Business Components Aren't Reusable

Patterns Don't Build Well Structured Software
パターンは well structured なソフトウェアを作らない

Frameworks for Class and Component Reuse Give Few Benefits

Inheritance Creates Brittle Software
継承は brittle (脆い、不安定な) なソフトウェアを産み出す

Violation of Encapsulation
封じ込め (encapsulation) に対する違反

Mutable State Causes Pain
mutable な状態は痛みを起こす

Behavioural Interfaces Cause Code Complexity and Bloat
behavioural なインターフェースはコードを複雑にし膨れあがらせる

Life Without Objects

So, is it possible to go back on 17 years of experience and contemplate a life without 
objects? I'm not sure that I'm 100% there just yet, but using a multi-paradigm language
like Scala is allowing me to overcome many of the limitations of the object-oriented

100% の確信はありませんが、Scala のようなマルチパラダイム言語を使うことで

For example, Scala's support for mixin traits makes it almost unnecessary to ever use 
implementation inheritance. It's rich collections framework plus the ability to use case
classes to create data structure like concepts obviates working around encapsulation issues.
A recommendation to use immutable data and collections makes code easier to debug and reason
about. The ability to use functions as general abstractions and type classes to extend
behaviour while maintaining single responsibilities makes it much easier to build well
structured, reusable software.

たとえば Scala の mixin traits のサポートは実装継承の使用をほぼ不要なものにしました。

rich なコレクションフレームワークに
封じ込め問題 (encapsulation issues) に関するワークアラウンドを不要にするコンセプト
のようなデータ構造を生成する case classes を使う能力を付加したもの

immutable なデータとコレクションの使用を推奨することは
well structured で reusable なソフトウェアの構築を格段に容易なものにします。
#while maitaining single resposibilities をどうしたものか

In fact, what I find I am doing more and more is using simple objects in the form of case
classes to represent data structures, with a few behavioural methods to simplify working
with this data. Then I'm just using mixin traits as a modular approach for grouping related
functions together. Then I'm combining these together to form components in which I compose
together various functions that transform data from one for into another.

Perhaps I'm further away from the pure object-oriented approach than I'd thought. I'm 
certainly building smaller, cleaner and better structured software than I ever was 

encapsulation は「カプセル化」とするのが定番でしょうが思うところがあってこうしました

■_ without


Life With Objects | Awelon Blue

Life With Objects
Posted on 20120501

This is a wordy response to Chris Turner's Life Without Objects.

Many object models compose poorly. There are no generic methods to combine two objects 
into a meaningful third. Rather than composition, we get a Cartesian product of 
specializations (e.g. BufferedInputStream, ByteArrayOutputStream). Functional programming,
by comparison, focuses very heavily on composition. We model programs with composable
abstractions – lenses, functors, categories, arrows, stream processors, iteratees, pipes,
monad transformers.

多くのオブジェクトモデルでは poorly にしか compose しません。
二つのオブジェクトを結びつけて meaningful な三つめのオブジェクトに仕立てるような
generic なメソッドがないのです。
composition というよりはむしろ、specialization の Cartesian product を手にしています
(たとえば BufferedInputStream, ByteArrayOutputStream)。
関数プログラミングでは対照的に composition に非常に強く focus していて、
composable な抽象を使ってプログラムをモデリングします。
lenses, functors, categories, arrows, stream processors, iteratees, pipes, monad transformers.

Functional programmers often reason in terms of compositional properties – i.e. properties
that are inductive across compositional operators (e.g. “if A doesn't deadlock, and B
doesn't deadlock, then A*B doesn't deadlock”). Purity includes a nice set of compositional
properties, and is most publicly associated with functional programming. But there is much
interesting ground between `pure functions` and `imperative IO`. Functional programmers
often seek and learn new compositional abstractions to achieve desired compositional
properties and expressiveness.

関数プログラマーはしばしば compostional な属性でもって考えます。
属性は compotional な演算子をまたいで indcutive です
(たとえば 「Aがデッドロックせず、かつ、Bがデッドロックしないのなら A*B はデッドロックしない」)。
Purity (純粋さ) は compositional な属性の集合を含み、また、
関数プログラマーは、望む compositional な属性や expressiveness を得るために
しばしば新しい compositional abstraction を求め、学習しています。

It's often difficult to achieve both expressiveness and rich composition, but invention is
the art of avoiding tradeoffs!

expresiveness と rich な compostion の両方を得ることは難しいことがほとんどなのですが、
invention (発明?) とはトレードオフを解消する技なのです!

While the functional programming community typically achieves composition by providing 
uniformly-structured entries and exits for every action, this isn't strictly necessary.

The OO community pursues another viable path to expressive composition: mixins, dependency
injection, and auto-wiring mechanisms in general. Ambient oriented and concept oriented
programming both provide alternative approaches to resource discovery and wiring objects
together. Sean McDirmid has pursued a few interesting possibilities for composition of
first class objects. I've also been idly pursuing such mechanisms, though without the OO
angle – e.g. constraint-based linkers and configuration and dependency injection for
functional values.

オブジェクト指向コミュニティでは別のやりかで expressive composition を追求しています。
一般的には mixin や dependency injection、auto-wiring 機構といったものです。


My Future with Objects

It would take a broad, fuzzy definition of OO to call RDP an OO paradigm. But RDP does 
support object capability model patterns. And I do pursue some of the auto-wiring
mechanisms suitable for object composition (in addition to rich, arrow-based functional
composition). RDP realizes most of my vision of what OO programming will eventually become
– a clean, declarative, open, composable, internally stateless fusion of object capabilities
and reactive programming. RDP's continuous time semantics require some interesting models
for external state, but state is still an essential part of many applications and the RDP

My RDP is embed with objects. ^_^




今日はわりともくもくしました。 ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目
ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目 の続きを読んでもくもくしたかったのですが、 天気も悪い中あの大きくて厚くて重い本を持ち出す気にはならなかったのでこっちなんかを。
ソフトウェアの世界でキャリアを築く Making it Big in Software

それと隣の区の図書館の貸し出しカードを作ったり。 パタンランゲージを所蔵している図書館があるんですよねこっちの区だと。 図書館同士のやり取りで自分の住んでいる区の図書館で借りることもできるのですが それだと貸出期限延長ができないので :) とはいえ別の人の予約が入ると延長できませんけどね。
一度は(大まかにでも)読んでみたいとは思っていたものの、 買うには高かった○| ̄|_ みんなビンボが悪いんだ


■_ Python Iteration


Ned Batchelder: Python Iteration
Created 24 April 2012

This is a presentation I gave at Boston Python in April of 2012.

There's a video of me talking, but you can't read the slides in it, so you might want to
follow along here. Also, clicking the slide images on this page will jump into the full
presentation at that point.

Python Iteration

This is a short talk for a Boston Python night called "Fundamental Topics." It's
intended to help beginners understand Python at a deeper level, and also to give intermediate
learners some new tidbits also.

Python has a nice model of abstract iteration which can be used to increase the expressiveness
of your programs. I think Python's iteration tools are one of the most underused features of
the language, especially by programmers coming from other "similar" languages.

My goal here was to show Python iteration in a light that would encourage programmers to
explore more of its possibililities.


Let's say you have a list of eight numbers, and you want to print each of them. One way to
do it is shown in the second code sample: start a counter at zero, and as long as the counter
is less than the length of the list, access that element of the list, and print it. Then
increment the counter, and the while loop runs over the whole list.


Note we used "less than the length of the list" because list indexes run from zero to len-1.
リストの添字は0から始まりlen-1 までなので「リストの長さより短い」としていたことに

This works, and is the least common denominator: this way of thinking about the loop 
can be written in almost any language.

In Python, if you want to have a loop that ranges from zero to N-1, you can use the 
idiom "for i in range(N)", as we see next. Here i again takes on values 
starting with zero and going up to the last index of my_list. This is the Python 
version of C's classic loop structure.

Python では0からN-1間での範囲のループを使いたい場合に
"for i in range(N)" というイディオムが使えます。
ここでも、i はゼロから my_list の最後の添字までの値をとります。
このやり方は C の伝統的なループ構造のPythonバージョンです

But Python gives us a much more natural way to loop over the values in my_list. Rather 
than iterating over indexes, and using the index i to get the value we really want 
from the list, we can simply loop over the values.

しかしPython は my_list 中の値を loop over するのにもっと自然な方法を提供しています。
添字を iterating over するのではなくて、index i を実際に必要な値を得るために使うと
いうもので、単に値の集まりに対して loop over できるのです。

The last code sample shows the right way to write this loop. "for v in my_list"
gives us each value in my_list in the variable v, with no need to fiddle around with i,
the index, at all. What started as a five-line while loop with two variables is now a
two-line loop with only one.

 "for v in my_list" は v という変数に my_list の値のそれぞれを
わたしたちに提供します。添字のために i について fiddle する必要はありません。


To summarize: iteration is a fundamental tool in all programming. Python has a simple yet
powerful model for iteration that is used throughout the language and standard library.
Using the tool that iterables provide, you can re-think your iterations to make them
clearer, more concise, and more powerful.

繰り返し (iteration) はすべてのプログラミングにおける基本的なツールです。
Python は繰り返しのために単純でありながら強力なモデルを持っています。
iterables を提供するツールを使うことによって、

© Copyright 2012, Ned Batchelder


UTF-8 Everywhere

UTF-8 Everywhere


Purpose of this document

This document contains special characters. Without proper rendering support, you may see
question marks, boxes, or other symbols.

To promote usage and support of the UTF-8 encoding, to convince that this should be the
default choice of encoding for storing text strings in memory or on disk, for
communication and all other uses. We believe that all other encodings of Unicode (or text,
in general) belong to rare edge-cases of optimization and should be avoided by mainstream

In particular, we believe the very popular UTF-16 encoding (mistakenly used as synonym to
‘widechar' and ‘Unicode' in Windows world) has no place in library APIs (except 
specialized libraries dealing with text).

This document recommends choosing UTF-8 as string storage in Windows applications, where
this standard is less popular due to historical reasons and lack of the native UTF-8 support
by the API. Yet, we believe that even on this platform the following arguments outweigh the
lack of native support. Also, we recommend forgetting forever what are ‘ANSI codepages' and
what were they used for. It is in the customer's bill of rights to mix any number of
languages in any text string.



    Indexing the nth character is O(n) in UTF-8. Not so for UTF-16/UTF-32.
    UTF-8 で n番目のキャラクターを indexing するのは O(n) である。
    Not so for UTF-16/UTF-32.

    So is in UTF-16 which is a variable length encoding. It's ϴ(n) operation even in UTF-32.
    Characters aren't code points. For example both
    可変長のエンコーディングである UTF-16 は当然として、UTF-32 であっても同様である。
    文字 (character) とはコードポイントではない。

    naïve (U+006E, U+0061, U+00EF, U+0076, U+0065)


    naı̈ve (U+006E, U+0061, U+0131, U+0308, U+0076, U+0065)

    are 5 character words, while the former consists of five code points and the later of six.

    Code points are meaningful only in the context of Unicode algorithms, which by their nature
    always scan the string sequentially. Looking up the nth character is, on the other hand,
    has little meaning in Unicode (see below).
    コードポイントは Unicode の、常に文字列をシーケンシャルにスキャンするというアルゴリズム
    一方、n番目の文字を探すということは Unicode において瑣末なことでしかない(後述)。

    Finding the length of a string is O(n) in UTF-8. Not so for UTF-16/UTF-32.
    UTF-8 において文字列の長さを求めるのは O(n) である。

    The word ‘length' is ambiguous, the comparison as stated is meaningless.

        Length in code units: is always the size of the memory occupied by the string divided
        by the size of one code unit. This is the most frequently used operation when you work
        with strings.

        Length in code points: it's ϴ(n) in both UTF-8 and UTF-16, and it's indeed constant-time
        in UTF-32. It's needed only when you convert to UTF-32, probably inside some Unicode
        UTF-8とUTF-16 では O(n) で、UTF-32 では定数時間でもとめられる。
        これはおそらくなにか Unicode アルゴリズムの内部で
        UTF-32 へ変換するときにのみ必要となる。
        Length in characters: it's ϴ(n) in any encoding since one character may be encoded with
        multiple code points and some code points may not correspond to characters.
        どのエンコーディングでも O(n) となる。

    What you usually do care about is…
        The size of the string as it appears on the screen: you'll need to communicate with the
        rendering engine for this, which has to scan the whole string no matter what encoding is





今日はあまりもくもくできなかったんですが、それでも何十ページか読んだ。 (ざっとだけど)。

んで、いくつか気になることがあってそのうちのひとつ。 本文中である人の著書を紹介するようなときに 文献タイトル [著者名] みたいなスタイルで書かれています、 そして詳しい文献情報が巻末の参考文献リスト著者名を手がかりに簡単に探せるようになっています。 そのこと自体はすばらしいのですが、 本文中の文献タイトルが中途半端に訳されてしまっています。 どういうことかというと、 日本語版が出ているのであればその日本語版のタイトルを書くべきだと思うのですが なぜか翻訳者が原著タイトルを訳したものになっているのです。 実際にいくつかの本について実際に出ている翻訳本のタイトルではないものが 書名として本文に書かれてしまっています。

確かに巻末のリストを見れば正しい翻訳本のタイトルはわかります。 でもなんだって独自に訳さなきゃならんのでしょう? 原著タイトルそのままで良いと思うのですけど。 せめて正しい?書名で書くべきではないでしょうか。


■_ split

groovy はよくわからんのですが、これ ,*を囲む () は不要じゃないでしょうか というかつけると意味が変わるような。





def lines = result.split(,).findAll{it != ''}


def lines = result.split(/(,*)/)



ruby で。

irb(main):001:0> "a,b,c,,e".split(/,/)
=> ["a", "b", "c", "", "e"]
irb(main):002:0> "a,b,c,,e".split(/,*/)
=> ["a", "b", "c", "e"]
irb(main):003:0> "a,b,c,,efg".split(/,*/)
=> ["a", "b", "c", "e", "f", "g"]
irb(main):004:0> "a,b,c,,efg".split(/(,*)/)
=> ["a", ",", "b", ",", "c", ",,", "e", "", "f", "", "g"]

python でも。 で気がついたのですが、なにかでこの仕様の違い("efg" がどう分割されるか) が話題になってような記憶がかすかに

>>> import re
>>> re.compile(',').split("a,b,c,,e")
['a', 'b', 'c', '', 'e']
>>> re.compile(',*').split("a,b,c,,e")
['a', 'b', 'c', 'e']
>>> re.compile('(,*)').split("a,b,c,,e")
['a', ',', 'b', ',', 'c', ',,', 'e']
>>> re.compile('(,*)').split("a,b,c,,efg")
['a', ',', 'b', ',', 'c', ',,', 'efg']

あら perl も python と同じか

>perl -E "say split(/,/, 'a,b,c,,efg')"

>perl -E "say split(/,*/, 'a,b,c,,efg')"

>perl -E "say split(/(,*)/, 'a,b,c,,efg')"

■_ C カンファレンス


The C Conference

Attend! C Conf is in San Diego, CA August 28th, 2012

tl;dr C Conf is real; Register Now!

    Who: You and a 150 other compiler wranglers and bit fiddlers
    What: A conference about using the C programming language
    When: August 28th, 2012
    Where: San Diego, CA; co-located with LinuxCon/CloudOpen/LPC
    Why: Because C is used by everyone
    How: Register Now; submit ideas via the Reverse CFP

A month ago I spent a morning putting down some rough ideas about a C Conference after joking
about the idea with some friends over the previous few weeks. It hit Hacker News front page
later that morning so I had to make it real: it is now.


Posted on: Apr 26 2012 


reddit での反応。 Hakcer news の方は伸びてなかった。

C Conference - a conference about C (planned by me) : programming

400 dollars seems insanely high for a conference. Defcon in Las Vegas is more than one 
day and far cheaper.

    C Conf is revenue neutral with a portion of proceeds held to bootstrap future C Conf
    events and the rest being donated to the OSUOSL (why?)

    I owe the Oregon State University Open Source Lab (OSUOSL) a debt for the boost they gave
    to my career and I want to pay-it-forward and help other students succeed. So, I will be
    donating a portion of the procceeds generated from the C Conference to help someone else
    succeed. The rest of the proceeds will be held for future C Conf events.

So if one was to go, they are going to pay their conference, and the next few conferences that
they may, or may not attend. Why not set the fee lower to cover the cost of this conference?

And if one is to go, their ticket price is raised to technically force them to donate to some
open source project. How about maybe give a little talk on the project, and let the people
decide for themselves if they want to spend the extra money to donate?

Just two suggestions to lower the price to get the conference off the ground. Personally, 400
dollars is a lot I think, that's like 26 steak dinners. Twenty-six.

I'm not the O.P., but I would note that a lot of the costs of running a conference like this
are fixed costs rather than per-person costs, so you have to set the per-person costs high
enough to be reasonably certain of covering things even if you don't have as many attendees as
you hope -- and then, if you get more attendees, you have a surplus.

With that said, science fiction conventions also run as revenue-neutral, and the smaller ones
rarely cost more than $150 for an all-weekend event, and under $100 is typical. (Admittedly,
they usually don't have A/V-system-rental costs.) If you're having to charge $400/person to
cover costs of a one-day conference, you're almost certainly doing something wrong, like
booking things in a way-too-expensive hotel, or getting catered food for all three meals.

You can get a steak dinner for $15.38, really?

I can get a steak from Scores for $4.99 on a Friday.

Especially with only vague plans about talks and speakers. At first glance I thought it was
$40. By the time I typed my e-mail in I realized I was an order of magnitude off and closed
the page.

I was ready to commit $40 bucks and the price of a hotel and gas to geek out with a bunch of
random C fans. At $400, I need to be wowed by high profile attendees well planned content.

acm confs are well above that

What level of skill is assumed of all who wish to attend?

I love C and have loads of fun talking about it (especially to my C# and PHP loving 
colleagues who seem to think it's old school) but $400? Really? I would love to see 
something like this streamed over the internet, maybe a large networked video 
conference. I was considering driving down from the Bay Area until I saw the price. 
Not to be a Debbie downer...


■_ Commercial and Open Source support for Ruby by Daniel Berger

Windows 向けRubyを云々。

WinRuby - Commercial and Open Source support for Ruby by Daniel Berger — Kickstarter

Ruby on Windows needs to be better!
Windows 上での Ruby はもっと良いものにする必要がある!

Microsoft Windows has always been a secondary platform both for the Ruby core developers and
for most OSS Ruby programmers. Many Windows developers have difficulty when dealing with Ruby
on Windows because of this, as many open source libraries simply weren't developed with Windows
support in mind.

Microsoft Windows は Ruby のコア開発者たちと大部分の OSS Ruby プログラマーたちの両方にとって
常に secodary platform でした。そのため、多くの Windowss 開発者たちは Windows 上で Ruby を扱
うときに困難が伴います。それは多くのオープンソースのライブラリが Windows のサポートを考えずに

If you're like me then you understand that, love it or hate it, Microsoft Windows is here to
stay and it's a viable and popular commercial platform.  For Ruby to succeed it must succeed on

好むと好まざるとに関わらず Microsoft Windows は現に存在している
viable かつ popular な commercial platform であることが理解できるでしょう。
Ruby が成功するためには Windows で成功することが必須なのです。

Making Ruby itself cross platform is difficult because Windows has its own set of functions for
doing most things, and the result is a lot of macro checks in the source code, as well as
separate source files. The result is a lot of code that simply isn't optimized for Windows, or
doesn't work quite right.

Ruby それ自身を cross platform のものにするのは困難です。
なぜなら Windows は大部分のことについてそれを行うための独自の関数群を持っていて、
# as well as ~をどうしよ
その結果、Windows 向けに最適化されていないか、さもなければ Windows では

Making individual Ruby libraries cross platform is difficult because many people don't use or
don't have access to Windows and are unfamiliar with its API, let alone its nuances.

個々の Ruby ライブラリを cross platform にすることは困難です。
なぜなら、多くの人は Widows を使っていなかったり
Windows を使う手段を持っていないので Windows APIに不案内であり、
その(Windows 独特の)ニュアンス (nuances) は放置されてしまうからです。

Let's make Ruby development on Windows great!
Winodows 上での Ruby 開発をきちんとしたものにしよう!

We need to make a version of Ruby that is explicitly written and optimized for Windows. And we
need better all-around support for Ruby libraries on Windows. In addition, we need to make Ruby
libraries better by providing a way for developers to easily test their Ruby libraries on
Windows, and a way for companies to get support for Windows development with Ruby when they
need it.

わたしたちにはきちんと Windows 向けに書かれ最適化された Ruby を作る必要があります。
さらに、Windows 上の Ruby ライブラリのためのより良い all-around なサポートが必要です。
加えて、開発者が簡単に自分のライブラリを Windows でテストできる手段や
企業が必要とするときに Ruby を使った Windows 向け開発のためのサポートを得る手段
を提供することで Ruby ライブラリをよりよくする必要があります。

Help me create both commercial and free support for Ruby on Windows!
Ruby on Windows の commercial support と free support 両方を作るのを助けてください!

I realize that there are companies out there that develop with Ruby on Windows and sometimes
they need support, both in terms of general expertise and suggestions as well as code. I also
realize that individual gem authors could use help too, both in terms of development and

Windows 上の Ruby で開発している企業があり

個人の gem author たちも

My goal is to create a business that supports businesses commercially in terms of service and
consultancy, as well as provide help for individual gem authors.

ビジネスを service と consultancy の面で
commercially にサポートする
個人の gem author たちを手助けする

My Credentials

I have a long history of Windows Development with Ruby. I've headed up the Win32Utils project
for over 8 years now. The Win32Utils team has published several open source libraries
explicitly designed for Windows, i.e. many of the win32* gems, with some even correcting
mistakes in core Ruby. I have also published dozens of open source libraries where I make extra
effort specifically for cross platform support, especially the sys* libraries that I've

わたしには Ruby を使った Windows 向け開発の長い経験があります。
現在まで8年以上にわたり Win32Uitls プロジェクトを指揮してきています。
Win32Utils チームはきちんと Windows 向けに設計された オープンソースのライブラリを
そしてそこで  Ruby のコアにあるミスの修正すらもいくつか行っています。

In addition I've made contributions both to Ruby core, and have contributed (for Windows or
otherwise) to many other open source libraries, including Rake and Rubygems, often dealing with
Windows support issues specifically.

I have both the track record and the skills to Ruby for Windows better.

You can see my all of my gem contributions at: https://rubygems.org/profiles/1140


There are several deliverables:

    A refactored Ruby built with MSVC++ with optimizations for Windows. Any bugs found will be
    sent back to the Ruby core developers.

Ruby のコア開発者たちに
sent back しています

    A Continuous Integration service for Windows. This would eventually include the option to
    select from multiple versions of Windows to test against (2000, XP Pro, Windows 7, etc), as
    well as different builds (MSVC++ vs mingw).
Windows 向けの continuous な integration サービス

    Support for individual gems. I'll help individual gem authors who contribute get their code
    working on Windows and/or provide them with continuous integration (once setup) for one gem
    of their choice.  Those who pay for support will be able to have multiple gems and even full
    application stacks setup and tested.

    個人の gem 向けのサポート。
individual gem author たちを

    Service contracts for companies using Ruby on Windows. I can help you develop a library for
    Windows, or help you get your existing code working on Windows.
    Windows 向け Ruby を使っている会社に対するサービス契約。

    Continued development of existing open source Windows libraries. This mainly includes the
    Win32Utils libraries. Many of them could use improvements, and need to be ported to FFI so
    that they will also work with JRuby.

    オープンソースの 既存 Windows ライブラリの continued decelopment(継続した開発?)。
    これは主に Win32Utils ライブラリ群を含みます。

JRuby でも使えるように FFI へ移植する必要があります。

    Development of commercial Windows Services (i.e. daemons) with Ruby. Both licensing of
    existing services, and new services that customers would like written.

    Rubyを使った商用 Windows サービス (デーモン) の開発。
既存ライブラリの licensing と


reddit での反応 Commercial support for Ruby on Windows : ruby


一つ前へ 2012年4月(下旬)
一つ後へ 2012年5月(中旬)



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