slimac:~ czajnik$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz

Sure, it only gives a CPU model, but well... It's still better than System Information level of details More detailed info can be obtained by printing all sysctl variables with names starting with machdep.cpu. Not as human readable as /proc/cpuinfo, but still very useful:

slimac:~ czajnik$ sysctl -a | grep '^machdep\.cpu'
machdep.cpu.max_basic: 13
machdep.cpu.max_ext: 2147483656
machdep.cpu.vendor: GenuineIntel
machdep.cpu.brand_string: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
machdep.cpu.family: 6
machdep.cpu.model: 58
machdep.cpu.extmodel: 3
machdep.cpu.extfamily: 0
machdep.cpu.stepping: 9
machdep.cpu.feature_bits: 3219913727 2142954431
machdep.cpu.leaf7_feature_bits: 641
machdep.cpu.extfeature_bits: 672139520 1
machdep.cpu.signature: 198313
machdep.cpu.brand: 0
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 xAPIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS SMEP ENFSTRG
machdep.cpu.extfeatures: SYSCALL XD EM64T LAHF RDTSCP TSCI
machdep.cpu.logical_per_package: 16
machdep.cpu.cores_per_package: 8
machdep.cpu.microcode_version: 21
machdep.cpu.processor_flag: 0
machdep.cpu.mwait.linesize_min: 64
machdep.cpu.mwait.linesize_max: 64
machdep.cpu.mwait.extensions: 3
machdep.cpu.mwait.sub_Cstates: 135456
machdep.cpu.thermal.sensor: 1
machdep.cpu.thermal.dynamic_acceleration: 1
machdep.cpu.thermal.invariant_APIC_timer: 1
machdep.cpu.thermal.thresholds: 2
machdep.cpu.thermal.ACNT_MCNT: 1
machdep.cpu.thermal.core_power_limits: 0
machdep.cpu.thermal.fine_grain_clock_mod: 1
machdep.cpu.thermal.package_thermal_intr: 1
machdep.cpu.thermal.hardware_feedback: 0
machdep.cpu.thermal.energy_policy: 0
machdep.cpu.xsave.extended_state: 7 832 832 0
machdep.cpu.arch_perf.version: 3
machdep.cpu.arch_perf.number: 4
machdep.cpu.arch_perf.width: 48
machdep.cpu.arch_perf.events_number: 7
machdep.cpu.arch_perf.events: 0
machdep.cpu.arch_perf.fixed_number: 3
machdep.cpu.arch_perf.fixed_width: 48
machdep.cpu.cache.linesize: 64
machdep.cpu.cache.L2_associativity: 8
machdep.cpu.cache.size: 256
machdep.cpu.tlb.inst.small: 64
machdep.cpu.tlb.data.small: 64
machdep.cpu.tlb.data.large: 32
machdep.cpu.tlb.shared: 512
machdep.cpu.address_bits.physical: 36
machdep.cpu.address_bits.virtual: 48
machdep.cpu.core_count: 2
machdep.cpu.thread_count: 4

One of gevent's important features is monkey patching - ability to patch some standard Python modules to make them cooperative. There's no magic here, thanks to Python's dynamic nature gevent simply replaces the standard APIs with its own cooperative equivalents. Existing blocking code can then be reused without any modifications. Cool, isn't it? Most notably, gevent patches socket (replacing blocking I/O with libevent-based asynchronous one), thread and threading modules (replacing threads with greenlets).

There are some gotchas, however. Due to the way the patching work, it is important to patch all the necessary modules before they are imported by any 3rd party library you want to use. For example, this snippet works fine:

import gevent.monkey; gevent.monkey.patch_thread()
import threading

It is enough, however, to swap the lines:

import threading
import gevent.monkey; gevent.monkey.patch_thread()

Now this simple 2 lines snippet triggers an exception:

Exception KeyError: KeyError(3072570908L,) in <module 'threading' from
 '/usr/lib/python2.7/threading.pyc'> ignored

Why it happens? When threading module is imported it uses main thread ID as a key in some module-level thread dictionary. At exit time it tries to obtain the thread instance from this dictionary (using current thread ID) to perform some clean up, but the ID of the main thread is no longer the same, thanks to patching. If patching is performed before importing the threading module (as in the first example above), all is fine, as the thread ID stored at import time comes from patched threads implementation already. For more details, see my StackOverflow answer.

The above example was trivial, things get more nasty in real life scenarios. I came across this problem again recently when trying to use sniffer for testing. It's enough to patch threading in the test file to trigger the problem. Let's start with the following test file, test.py:

import gevent.monkey; gevent.monkey.patch_thread()
import unittest

class TestTesting(unittest.TestCase):

    def test_nose(self):
        self.assertTrue(True)

Sniffer works fine when started, nothing indicates the problems to come:

Did not find 'scent.py', running nose:
.
----------------------------------------------------------------------
Ran 1 test in 0.009s

OK
In good standing

But it's enough to touch the test file to make it explode (there are more exceptions, but I copy the first one only for brevity):

Traceback (most recent call last):
  File "/home/czajnik/env/local/lib/python2.7/site-packages/sniffer/runner.py", line 95, in _run
    if self.run():
  File "/home/czajnik/env/local/lib/python2.7/site-packages/sniffer/runner.py", line 177, in run
    return super(ScentSniffer, self).run()
  File "/home/czajnik/env/local/lib/python2.7/site-packages/sniffer/runner.py", line 115, in run
    import nose
  File "/home/czajnik/env/local/lib/python2.7/site-packages/nose/__init__.py", line 1, in 
    from nose.core import collector, main, run, run_exit, runmodule
  File "/home/czajnik/env/local/lib/python2.7/site-packages/nose/core.py", line 11, in 
    from nose.config import Config, all_config_files
  File "/home/czajnik/env/local/lib/python2.7/site-packages/nose/config.py", line 8, in 
    from nose.util import absdir, tolist
  File "/home/czajnik/env/local/lib/python2.7/site-packages/nose/util.py", line 19, in 
    log = logging.getLogger('nose')
  File "/usr/lib/python2.7/logging/__init__.py", line 1555, in getLogger
    return Logger.manager.getLogger(name)
  File "/usr/lib/python2.7/logging/__init__.py", line 1022, in getLogger
    _acquireLock()
  File "/usr/lib/python2.7/logging/__init__.py", line 217, in _acquireLock
    _lock.acquire()
  File "/usr/lib/python2.7/threading.py", line 122, in acquire
    me = _get_ident()
  File "/home/czajnik/env/local/lib/python2.7/site-packages/gevent/thread.py", line 28, in get_ident
    return id(getcurrent())
TypeError: 'NoneType' object is not callable

Clearly, logging module uses threads (fair enough - it tries to make logging API thread-safe). Unfortunately, not much can be done here, all the imports are performed before our module even gets loaded. As a workaround I've hacked nose/core.py, adding this line just before logging import:

  import gevent.monkey; gevent.monkey.patch_thread()

Now sniffer works fine, yet it's a hack, obviously. For my project it's enough, as I use separate virtual environment and thus I can hack around without consequences. But this problem
definitely asks for some clean solution.

Needless to say, it's tempting to look closer at the .pyc files, or even try to decompile them. Here comes the surprise - the files seem encrypted. Typically, .pyc contains a lot of human-readable strings (at least the file name and variable/function names), but it's not the case with files from unzipped Dropbox.exe:

czajnik@czajnik:~/work/dropbox/exe$ strings distutils/__init__.pyc  
Oc {
z4E7ls
]yD~
:z<n

Also, every .pyc file starts with a 4-byte magic number - in case of extracted .pyc files, the magic number equals 0xb7f20d0a - no public Python release ever used this value.

It seems that Dropbox team decided to patch the Python interpreter with some decryption routines, in order to protect the application from reverse engineering. Note, that the Python interpreter (Python25.dll) itself is embedded inside Dropbox.exe as a resource, it can be easily extracted with any resource editor. I guess it's time to start IDA Pro and look deeper

Edit: For the curious - I've spent some time digging deeper. It turned out there are 2 protection levels - one is a decryption routine plugged into code demarshalling part of static PyObject *r_object(RFILE *p) function (see marshall.c). It's fairly easy to work it around, even without fully disassembling it - nothing stops one from building a small .exe which calls original code in the DLL to decrypt the file. However, there is another protection - the Python virtual machine opcodes are mixed. This required a bit of manual reverse engineering of PyObject *PyEval_EvalFrameEx(PyFrameObject *f, int throwflag) (see ceval.c), but also turned out to be fairly easy. Now I'm able to uncompyle nearly all the files.

This is typically dealt with by configuring the SCRIPT_NAME CGI parameter, and letting this name be removed from the beginning of the PATH_INFO parameter by the WSGI environment, before the path is passed down to the application. This way the WSGI application routing remains the same, no matter where in the URL tree it is deployed. The application needs to be aware of SCRIPT_NAME parameter only to generate proper URLs to self.

It turned out that Nginx configuration need to contain magical uwsgi_parameter1 30; setting, e.g.:

server {
    // ...
    location /admin/ {
        uwsgi_pass unix:/path/to/uwsgi.socket;
        include uwsgi_params;
        uwsgi_param SCRIPT_NAME /admin;
        uwsgi_modifier1 30;
    }
}

The uwsgi_modifier1 parameter is listed in the Nginx's uWSGI module documentation, but it doesn't really explain what modifier1 is? Why it needs to be 30? The answer can be found in the uWSGI protocol documentation. The modifier1 is simply used to denote the uWSGI protocol's packet type. According to the table, value 30 means:

Standard WSGI request followed by the HTTP request body. The PATH_INFO is automatically modified, removing the SCRIPT_NAME from it.

Packets of type 0 (default) and 30 differ only in how SCRIPT_INFO is handled. I really wish there was a better documentation for this kind of feature. The parameter names used don't help googling, either...

In JavaScript, each statement can be terminated with a semicolon. If it is not, the semicolon is inserted automatically by the language implementation (the exact rules are irrelevant here, you can easily find it). Sounds innocent at first, but it is actually quite dangerous. Let's say we want to return an array from a function:

function a()
{
    return [ 'a' ]
}
print (a());

The result matches our expectations:

czajnik@lapcio:~$ rhino a.js
a

Now let's insert a new line after the return statement:

function b() 
{
    return
    [ 'b' ]
}
print (b());

This snippet produces the following output:

czajnik@lapcio:~$ rhino b.js
undefined

That's because a semicolon was inserted automatically after return, and the array alone on the next line is acceptable syntax (in JavaScript an expression alone is a valid statement). This is weird, pathetic and scary...

There are dozens of books about Android application development published already, adding little value to what can be found in the official Android developer's guide. On the other hand, no single book has been published until now (as far as I know) about porting and customizing the platform itself, making AOSP site and mailing lists the only sources of information. This situation is going to change with Embedded Android: Porting, Extending, and Customizing by Karim Yaghmour coming from O'Reilly in June.

The first four chapters of the book are already available directly from O'Reilly (digital Early Release). What's available now is already worth looking at, let me describe the contents briefly.

The first chapter, Introduction, gives a brief Android platform introduction (with some good background about how Android platform emerged) - it's fun to read, but nothing new to those interested in Android development.

The second chapter, titled Internals Primer, is where the book starts to shine. It gives a great overview of the whole platform, starting with a basic outline from the application developer perspective, then describing the platform architecture in more details - the motivation behind the Android's proprietary kernel modifications (wakelocks, binder, ashmem, etc.), general approach to hardware support (e.g. how the code is split between kernel space and C/Java user space code), filesystem layout, list of system daemons and services, etc. It's a kind of Android's missing architecture manual.

The third chapter, titled AOSP Jumpstart, is the first "hands-on" chapter of the book, giving all the information needed to download the AOSP source tree, prepare the build environment and eventually perform a basic build. Nothing very revelatory though, anyone who has ever tried to build a custom Android build should know it all already.

The fourth chapter, titled The Build System, is a great one, giving more detailed description of the Android's build system. It contains all the information necessary to add a new device, application, native library or daemon. Again, I'd expect such information to be available from AOSP site, but this book fills the gap perfectly.

The following chapters are going to describe the individual subsystems in more details. Even with only four chapters released so far I'd really recommend this book, as I believe the next ones will be as great, and I just can't wait for the final release!

I hope that the boards assigned to Qt on Raspberry Pi program will be available soon!

First of all, DTL and TTL logic families were the most popular when RS232 was developed. In both DTL and TTL input current is significantly lower in the high state (a TTL input is equivalent to NPN transistor's emitter), so it makes perfect sense to use high state when idle to minimize the power consumption in the logic part.

The second part of the story is more funny. Why is high state represented by negative voltage on the line? This is because copper wires exposed to moisture are less likely to corrode if the voltage is negative. Indeed, it's the anode (positive electrode in electrolytic cell) where the oxidation happens. Beautiful explanation, isn't it?