FAQ it.comp.lang.c++

Queste sono le FAQ del newsgroup italiano dedicato a C++.Mi sono reso conto che in effetti non è facilissimo trovarle,ache se contengono molte informazioni che risparmierebberodomande banali sul newsgroup.

Per cui, nel caso, le linko.Link.

Illuminated keyboard on PowerBook G4 and Linux.

An image is worth a thousand words.

It was a matter of mod-probing i2c-dev.

It is a custom Linux 2.6.20 Kernel on Debian Unstable. Cool!

Pictures just before the Foundation of "Python Italia"

Execute saved Synaptic markings

It happens quite often that I use synaptic to manage packages on my debian.However, sometime I save the markings in order to perform the installations another time.For example I need to apt-get something quickly without waiting for the whole thing to be downloaded and installed.

The standard procedure would be running synaptic again and then loading the markings.However, in this cases I don't feel like I need to start the whole synaptic thing. I'd prefer a small command line utility that processes the saved markings.

I wrote one. It is very simple. It uses sudo, so every now and then it asks the password.Of course one could do a better job, but I had not time to do something better.

#!/usr/bin/env ruby

args = $*
if args.size == 0
    puts "You should provide a file to process"
    exit 0
end

dict = Hash.new
File.open(args[0]) do |f|
    f.each_line do |line|
        key, action = *line.split
        dict[key] = action
    end
end

# sudo apt-get #{v} #{k}

dict.each do |k, v|
    exec("sudo apt-get -y #{v} #{k}") if fork.nil?
    Process.wait
end

Scripting languages

What is a scripting language?

From Wikipedia we read that:

Scripting languages (commonly called scripting programming languages or script languages) are computer programming languages that are typically interpreted and can be typed directly from a keyboard. Thus, scripts are often distinguished from programs, because programs are converted permanently into binary executable files (i.e., zeros and ones) before they are run. Scripts remain in their original form and are interpreted command-by-command each time they are run. Scripts were created to shorten the traditional edit-compile-link-run process.

Of course any self respecting computer scientist knows that definition is meaningless, because a language is a mathematical constructand is not tied to its implementation. You can write a C interpreter, for example (and there are some). You can also write a compiler for any 'interpreted language' (of course the term 'interpreted language is also meaningless). And there are theoretical constructs (Futamura projections) that given any interpreter are able to build a compiler from it (you could implement them even in practice, though it would be terribly inefficient).

However, any other definition would be misleading as well: if you define a scripting language as a language you can use to "script" (as in "bash script"), then you've got definition that's even more stupid. bash is a scripting language, and so it is Python. However, if someone writes an application that is scripted in C, C becomes a 'scripting language').

Both definitions have an additional problem: scripting languages are considered somewhat inferior to 'non-scripting languages'. Some even use the term 'true programming languages' (and this 'true programming languages' are usually considered to be C and C++, for example).

Lisp, Haskell, OCaml, Prolog

In this dissertation on 'scripting languages', Lisp is quite emblematic. Lisp can be compiled (there are some Lisp compilers around). But Lisp can also be interpreted. This is one of the most widespread Lisp environments (and it is an interpreter). Moreover, in Emacs you can just run some Lisp snippets. And Emacs itself is scripted in Lisp (thus Lisp would be a scripting language according to the second definition). However, no one can assert that it is not a 'true' programming language. Emacs itself is a beautiful (and complex) piece of software, and a lot of 'real' (and extremely difficult) stuff in the AI field has been written in Lisp.

Haskell can be another example. Hugs is an interpreter, ghc is both an interpreter and a compiler. And Haskell is even statically typed (so you see, being dynamic is not necessary ). The very same applies for OCaml or Prolog. And all thislanguages have been used by the most theory-oriented computer scientist toimplement real programs.

I suppose nobody would say that Lisp or Haskell are 'scripting languages' (even if according to the definitions they are -- Haskell is used in many configuration tools by Linspire programmers).

Bash, Perl, Python, Ruby.

All this languages have been labeled as 'scripting languages'. And in fact according to definitions, they are. However, they are very different languages.

Bash is a very simple language designed to do simple things. Unix system administrators used it intensively (along with awk and sed and other utilities) to automate many repetitive tasks. Although this is surely 'programming', in some sense it's different from programming an application from scratch. Some even consider it a 'lower level' kind of programming (and surely we must recognize that skills involved in writing a boot script are different from skills used to write a compiler)

Perl was born in this environment: its goal was textual manipulations and interactions between processes in a system. It is a nicer alternative to bash + awk in many situations. Later it has been added a fully fledged object model, but in the while it has been used to write very complex applications that go outside the 'lower level programming domain' that is usually associated with 'scripting'. Even though I don't like Perl anymore, it is a general purpose language, with the same dignity of C or C++.

The 'scripting language' monicker is not fitting anymore. And it is even less fitting for Python. Python has been an object oriented programming language from the beginning. Good software engineering practices have always been employed. However, many consider it just another scripting language. And of course Python makes a great scripting language.

The domains in which Python excels are the same in which Java is used, for example. However, Python can be used for scripting, too. That is to say... some (and I'd be tempted to say 'most' ) 'scripting languages' can be used both as general purpose languages and automation/scripting.

The reason why they can be used for automation/scripting and that they are easier to use and we can write programs faster. The development cycle is faster, too. And to me, they all seem good properties.

I think that the very same features that make Python (or Ruby) great for scripting, make it even greater for general purpose programming. That is to say we should consider a 'scripting language' not a poorer language, but a better one (yeah, of course this is exaggerated, since there are languages suited for scripting that are not suited for general purpose programming -- AppleScript and bash, for example).

Emacs and emacsclient (Ruby script to call them both)

I usually call one single emacs server (I've got (server-start) at the very beginning of my .emacs), then connect to it with some emacsclient.

Unfortunately enough emacsclient just quits if there is no active emacs server.

I need a process that tries to run emacsclient: if there is no active server, it runs emacs.Moreover, emacsclient has a -n switch that makes it return ASAP, so the terminal is available for more commands.emacs has not such a switch, but that behaviour is the one I want.

So I decided to write a small ruby script that does just this:

1. Tries to run emacsclient with the -n option.
2. If it succeeds, we are done. Otherwise we run Emacs doing some standard posix process manipulation in order to return to the shell as soon as possible.

This is the script:

#!/usr/bin/env ruby

fork do
    exec('emacsclient', '-n', *$*)
end

Process.wait
    if $?.exitstatus != 0
        fork do
        Process.setsid
        Signal.trap('HUP', 'SIG_IGN')
        exec('emacs', *$*) if fork.nil?
        exit!(0)
    end
    
    Process.wait
end

Welcome Home, Debian! (Ubuntu PPC discontinued?)

Ubuntu discontinued?

Recently there are rumors that Ubuntu PPC will be discontinued.

In fact there is an IRC log about it:

Something asked a few times: Will PPC support be discontinued soon?

We will make a final decision on PPC for Feisty by the end of next week

if there is sufficient community contribution on this, then the community port can be just as good as a Canonical-supported one

we would keep the builds in place, but not block the release if things failed to build

so if people step up to unblock issues when they occur, then PPC would be on the same footing as it currently is

sabdfl, will "but ps3 is ppc" be a valid argument? (asked a few times as well)

the extra architecture costs us a lot in terms of testing bandwidth at release time, and figuring out issues like how to deal with the live CD are compicated

if SONY fund Ubuntu-on-PS3 then I guarantee it will happen :-)

I have to say I've not been pleased about it. Of course Canonical should make its own interests: that is to say, if they feel that supporting PPC is not worth it, they are doing the right thing. However, it's quite sad: there are a loto of perfectly functioning G3, G4 and G5 machines out there. Dropping support like this, seems to be the way commercial companies act.

The point is that we must realize that Canonical is a commercial company. You just can't do anything about it and accept it.

Since at the moment I run Linux mostly on a PPC machine (my notebook), PPC support becomes a key factor in chosing the right distribution. My choice was obvious: I had been using Debian for ages before Ubuntu, why not going back to Debian? Welcome home, Debian!

Debian PPC

I downloaded the DVD iso for testing. Since I'm running on PPC, the new graphical installer is still experimental. Moreover, I quite feel at home with good old Debian textual installer.

Installation was really smooth. Debian recognised all my hardware with no need for manual intervention. Of course the airport card did not work without bcm43xx-fwcutter. Unfortunately enough, I left my working ethernet cable at the university, in the office I share with some fellow students. This was just a small delay.

Quite interesting Debian recognised my display better than Ubuntu (I still don't know why, but I had to set the resolution manually or Ubuntu would not start X11). However, Debian did not preload pbbuttons (that are used for the notebook multimedia keys, volume, lcd backlight, etc).

In fact I think a noob prefers to find a system with no multimedia buttons and working graphics than vice-versa. It seems that the guys at Debian did a pretty good work. Nonetheless, I'm quite sad for the exclusion of pbbuttons: I did chose a macro-package (when installing) called 'laptop' or something like that. I think that pbbuttons should be included in the first DVD. In fact most PPC machine out there should be laptops (well, maybe not 'most', but surely a great number).

Everything else worked smoothly. I recompiled the kernel (I would like to have that backlit keyboard working, it should work even with the 2.6.18 default kernel, but maybe something useful was not compiled into it). The backlit keyboard still does not work, which is a pity, but is something I can live without. Beryl does not work too (but it didn't work with Ubuntu, either). And it should work. But that is another thing I can happily live without.

Ruby Cookbook: review

I recently bought the Ruby Cookbook. I bought the italian version (whose title is 'Ruby Cookbook con elementi di Rails' which roughly translates to 'Ruby Cookbook with elements of Rails'). However, the book itself is not different.

Although I prefer to read technical books in English, I often buy books in Italian in order to show the publisher interest on that particular technology. In fact, in a country where most people avoid buying book in English because they feel they are 'too' difficult (like in Italy), good technologies do not spread if there are no good books in the local language.

The first impression with the book has been terribly negative. Actually if instead of buying the book online, I found it in a shop and leafed through it, I suppose I would have put it down.

Strings in Ruby are much like strings in other dynamic languages like Perl, Python

and PHP. They’re not too much different from strings in Java and C. Ruby strings are dynamic, mutable, and flexible.

In this paragraph you learn that "Ruby strings are dynamic, mutable, and flexible." And that is true. However, you get another impression: the authors do not know what they are talking about.

They say that Ruby strings are 'much like' the strings in Perl. This is almost true (well, Perl unicode support is much better than Ruby, and Perl deals natively with unicode strings. However, saying that Ruby strings are like Python strings is plainly wrong: Python strings are immutable and are somewhat more akin to Ruby symbols (in fact if you call intern on a Python string you get something semantically very similar to a Ruby symbol). Moreover, Python deals with unicode natively.

Again, the comparison with Java strings is plainly wrong: in Java strings are immutable. The comparison with C is terrible: in C, strings are not even a primitive data type.

As I said before, at this point I was tempted to put the book on a shelf and never open it again. Luckily enough I went on and soon enough I found out I bought one of the best books on Ruby available.

The impression that the authors are not competent (or at least they speak of something they do not know) is plainly wrong. A few chapters later, there are some chapters that quite accurately confront Ruby pragmatic with Python one. They are poignant and precise: definitely the authors know both languages quite well. I suppose the 'bad' paragraph at the beginning was a tentative to be didactical.

The book in fact is quite didactical. You can read it with almost no previous knowledge of Ruby. The reader is guided through Ruby syntactical conventions (for example when dealing with strings, you learn that parentheses are optional, which is known to everybody who coded a bit in Ruby).

In the later chapters (most notably the ones on modules and objects), the reader learns the nature of Ruby power, and how to reason and develop in order to unleash that power. This book is a cookbook, but every single receipt does more than teaching a way to achieve its goal: it teaches something about the way Ruby programmers should think and code *in general*. In fact you can consider this cookbook a 'beginner' book that teaches by examples (and that is a very effective way in a language such as Ruby). Of course, there is also plenty of intermediate and advanced stuff, or subjects not covered elsewhere (for example the ones about image manipulation).

This is a precious book and the ideal companion for everyone who's seriously motivated in learning Ruby. But it is also a book that a Ruby programmer may want to keep on her desk to find out how to do things without reinventing the wheel.

Duck hyping and Ruby

Introduction

Ruby is the new boy in town. Until a couple of years ago, nobody reallyspoke about Ruby. It was really popular in Japan, but outside it was justone of the many 'scripting' languages that the open source world has developed over the years.

The big names were using Python or Perl. Well, most of them were using PHP,but in fact this does not matter: while Perl, Python and Ruby are excellent languages (even if it is almost impossible someone really likes both Perland Python, nonetheless Perl has its merits), PHP plainly sucks. And then of coursethere was that Java everybody was talking about and C# (but the open sourceguys usually said positive things about it only if in the same sentence the word 'mono' occurred).

In the last few years Rails changed things. Now a lot of people are talkingabout Ruby and dynamic languages. A lot of Java developers discovered thepower of dynamic languages and dynamic typing, after years spent sayingthat the only saviour was static typing. In fact it seems to me that thereis kind of a revolution in the IT world.

Python and Ruby and Lisp and ...

Rails is a pretty good framework. The documentation is acceptable even forthose who grew up with Sun's bloated documentation (I still prefer to readthe code if the language itself is readable enough).

Ruby is a really nice language. In fact you can see it as a (Perl--)++.It kept almost all nice features from Perl, and dropped some of the worse.Of course a Perl Monger would disagree, but I'm a pythonist after all.

One of the most interesting things, in my opinion, is that Ruby and Pythonare quite similar (even if they start from different points of view). I feelquite comfortable with both languages, and even their pragmatic is notreally different. Moreover differences tend to depend on different syntax, rather than on different semantics.

For example in Ruby is quite frequent to 'open' classes and add methods.This is something you can do in Python, even if there isn't a specialsyntax.

>> class A(object): pass
>> a = A()
>> a.foo()
Traceback (most recent call last)
...
<type 'exceptions.AttributeError'>: 'A' object has no attribute 'foo'

>> def ext_foo(self): print 'foo'
>> A.foo = ext_foo
>> a.foo()
foo

Of course this is far less elegant, and that's way it's something less frequently done in Python.

Ruby has another 'advantage' over Python. It's syntax is less rigid, and in fact the most typical thing that is in Ruby pragmatic is to write a DSL in the language itself and program in that DSL.

There are a lot of examples of this strategy in Rails itself. However, thisapproach is not new at all. Lisp programmers have been using it since thebeginning, that is to say it's almost forty years they code DLS in Lisp anduse them to write the application.

Duck typing vs. duck hyping.

Unfortunately I hear people saying quite often that 'Ruby invented duck typing'. People that just discovered Ruby, seem quite certain about it. Some of them even told me thatin Python you 'were not really duck typing' and that it was something peculiar to Ruby. But let's look at the definition (from Wikipedia):

Duck typing is a form of dynamic typing in which a variable's value itself implicitly determines what the variable can do. This implies that an object is interchangeable with any other object that implements the same interface, regardless of whether the objects have a related inheritance hierarchy. Duck typing is a feature of programming languages such as Smalltalk, Python, Ruby, and ColdFusion.

Of course this is something that you can do in Python. And you can also do it in Objective C, by the way. And in Python it is something plainly obvious, too. Everybody does it, everybody likes it. But nobody thought about using a fancy name when describing the practice in books and blogs.

Amazingly, the term 'duck typing' (that some think it's a Ruby peculiar feature) was probably used for the first time by Alex Martelli when speaking about Python typing system. It was Jul 26 2000, and the english language Ruby newsgroup had been active since the first days of may. There was a mailing list of course, but nonetheless Ruby was relatively unknown outside Japan.

In other words, don't check whether it IS-a duck: check whether it QUACKS-like-a duck, WALKS-like-a duck, etc, etc, depending on exactly what subset of duck-like behaviour you need to play your language-games with. If the argument fails this specific-ducklyhood-subset-test, then you can shrug, ask "why a duck?" (at least, you can if you're a Marx Brothers fan and have memorized "Cocoanuts"' script; Monty Python one-true-wayists will have to find their own simile here), and move on to the next set of tests (why-a-no- chicken immediately comes to mind, but then one would have to ask why it crosses the road, so I think we'd better snip it).

Alex's original post

That is the reason why I say that Ruby supports 'duck hyping'. Ruby is a very good language. I suppose that if I learnt Ruby before Python, I'd probably like Ruby more than Python (because the languages are quite equivalent, it's my head that now works in a somewhat more pythonic way). However, there are a lot of people that are really *good* at selling Ruby. An excellent publisher based his early success on Ruby books, the creator of Rails has lots of marketing skills, and so on.

However, I was wondering: why Ruby and not Python? I don't believe in fortune. To discover the answer (that in this particular case I guarantee it' s not 42) we must analyze in which ways syntactical features of Ruby (since semantically they are quite interchangeable) influence the language pragmatic, and in which ways the pragmatic contributed to build Ruby success.

And when we are into pragmatic, we are not in the world of the compiler: we are in the world of the programmers. That is to say: we must understand why Ruby has appeal even where Python has not. We must understand in which way the language influenced the way of thinking of so many people, and why Python did not.

Python Metaclass on Steroids

In Python Metaclasses are considered an advanced and difficult to use technique. This is certainly true. Developers of 'production code' are often discouraged to use metaclasses, since code that makes use of metaclasses is often overly complex (especially for people who are not used to metaclasses).

A further reason to avoid metaclasses is that they truly can be avoided. They do not add much power to Python. However, there are cases when they make 'client' code more readable.

Consider this situation: we have a finite set of strings that are used as dictionary keys in several parts of our application. Of course, we don't want to use explicit strings in every point where they are needed. This is too error prone and bugs are more difficult to track.

A good solution is to put all the strings in a module. We will have code such as

FOO1 = 'foo1'
FOO2 = 'foo2'

Good. However, we may want to loop over the constants. One of the more pythonic solutions is this one:

targets = {
    'SEARCH': 'search', 'INFO': 'info', 'VARIANTS': 'variants',
    'DEPS': 'deps', 'DEPENDENTS': 'dependents', 
    'INSTALL': 'install','UNINSTALL': 'uninstall',
    'ACTIVATE': 'activate', 'DEACTIVATE': 'deactivate', 
    'INSTALLED':'installed', 'LOCATION': 'location',
    'CONTENTS':'contents', 'PROVIDES': 'provides',
    'SYNC': 'sync', 'OUTDATED': 'outdated',
    'UPGRADE': 'upgrade', 'CLEAN':'clean', 'ECHO': 'echo',
    'LIST': 'list', 'VERSION': 'version', 
    'SELFUPDATE': 'selfupdate', 'HELP': 'help'
}
locals().update(targets)

In this way we can do whatever we want. However, we could use a class instead of a module. We simply define the constants as class variables. Then we can easily use the locals built-in to create the array of constants. But with a little metaclass trick, we can write more interesting client code.
We could for example write things like:

for k in PackageKey:
    # do something

or

if key in PackageKey:
    returnself.foo(key)

We can use metaclasses to define a class object that behaves in the way above.

class_ConstantNamespace(type):
    def__iter__(cls):
        for v incls.keys:
            yield v
    
class PackageKey(object):
    __metaclass__= _ConstantNamespace

NAME                   ='name'
VERSION                ='version'
REVISION               ='revision'
DIRECTORY              ='directory'
VARIANTS               ='variants'
HOMEPAGE               ='homepage'
DESCRIPTION            ='description'
BUILD_DEPENDENCIES     ='build_dependencies'
LIBRARY_DEPENDENCIES   ='library_dependencies'
RUNTIME_DEPENDENCIES   ='runtime_dependencies'
PLATFORMS              ='platforms'
MAINTAINERS            ='maintainers'
keys = [locals()[key] 
        for key inlocals().keys() if (key.upper()== key and 
            (key.isalpha()orkey.endswith('_DEPENDENCIES'))]