October 16, 2013

Justification. Is it really so hard?

Have you ever thought about how do right-aligned texts look like? Don't you find them gnawed by an army of little hungry text-string eaters? Next time you type something, recall justification feature. Just think about it.

October 09, 2013

Strange thing about hashables in Python 2

I was digging through Python's docs about sets and dictionaries and have found a strange thing about them in Python 2. As set and dict docs say:

"A set object is an unordered collection of distinct hashable objects."
"A mapping object maps hashable values to arbitrary objects."

Old documentation tells that the set classes are implemented using dictionaries, so they are rather similar things.

From the definition of hashable it comes that an object is considered to be hashable if it has both __hash__() and (__eq__() or __cmp__()) methods. Python 3 says that the object is hashable if and only if it has both __hash__() and __eq__() methods. So, let's check that in Python 3 and Python 2.

>>> import platform
>>> platform.python_version()
'3.3.1'
>>> platform.python_implementation()
'CPython'

Let's define a couple of classes and try to use their instances as set's members and dict's keys.

>>> class A(object):
...     pass
... 
>>> class B:
...     pass
...
>>> a = A()
>>> b = B()
>>>
>>> '__hash__' in dir(a)
True
>>> '__eq__' in dir(a)
True
>>> '__hash__' in dir(b)
True
>>> '__eq__' in dir(b)
True

Well, class A is defined in new-class style and class B is defined in old-class style. In Python 3 all classes are new-styled indeed, so everything is OK and instances of both classes have __hash__() and __eq__() methods and we can create a set and a dictionary:

>>> {A(), B(), }
{<__main__.B object at 0xb717cb4c>, <__main__.A object at 0xb717cb6c>}
>>> {A(): 'foo', B(): 'bar', }
{<__main__.A object at 0xb70c66ac>: 'foo', <__main__.B object at 0xb69edf6c>: 'bar'}

So, everything is fine with Python 3. Let's switch to Python 2:

>>> import platform
>>> platform.python_version()
'2.7.4'
>>> platform.python_implementation()
'CPython'

and define the same classes and their instances:

>>> class A(object):
...     pass
... 
>>> class B:
...     pass
... 
>>> a = A()
>>> b = B()

and make some checks:

>>> '__hash__' in dir(a)
True
>>> '__eq__' in dir(a)
False
>>> '__cmp__' in dir(a)
False

Oops! New-style classes in Python 2 do not have neither __eq__() nor __cmp__() methods, so by definition they are not hashable. Let's make the galaxy collide!

>>> set([a, ])
set([<__main__.A object at 0xb74deacc>])
>>> 
>>> d = {a: 'foo', }
>>> d
{<__main__.A object at 0xb74deacc>: 'foo'}
>>> d = {a: 'bar', }
>>> d
{<__main__.A object at 0xb74deacc>: 'bar'}
>>> d.update({A(): 'baz', })
>>> d
{<__main__.A object at 0xb74deacc>: 'bar', <__main__.A object at 0xb74debec>: 'baz'}

Emm, stop. Everything is good, wright? No. But, well, yes, we've got a set and a valid dictionary. But how? I don't get it. Let's move on:

>>> '__hash__' in dir(b)
False
>>> '__eq__' in dir(b)
False
>>> '__cmp__' in dir(b)
False
>>> dir(b)
['__doc__', '__module__']

T-sss! We are going to act like a real badass developers and use this really non-hashable (by definition) object in our experiments:

>>> s = set([b ,])
>>> s
set([<__main__.B instance at 0xb74deb0c>])
>>> s.update(set([B(), b, ]))
>>> s
set([<__main__.B instance at 0xb74deb0c>, <__main__.B instance at 0xb74ded0c>])
>>>
>>> d = {b: 'foo', }
>>> d
{<__main__.B instance at 0xb74deb0c>: 'foo'}
>>> d.update({b: 'bar', B(): 'baz', })
>>> s
set([<__main__.B instance at 0xb74deb0c>, <__main__.B instance at 0xb74ded0c>])

"Oops, I did it again!" Can you hear that? The time hasn't stopped and the clock is going on. How do you like that? Non-hashables are treated as valid hashables! I'm quite happy that nothing had crashed and it is not an 8th wonder of the world. But isn't it strange when some things act in the way they really should not?

June 25, 2013

Extending oh-my-zsh with hg_prompt

If you are using oh-my-zsh framework for your zsh (if not, just look at this) then you may noticed that there is a nice out-of-box prompt for git repositories:

If you would like to do something similar with your mercurial prompt, then you will need:

1
Install hg prompt
2
Add 'mercurial' plugin to the list of your zsh plugins (~/.zshrc):
plugins=(git, mercurial)

3
Add the following after "source $ZSH/oh-my-zsh.sh":
source $ZSH/oh-my-zsh.sh

# Things to add:

function hg_prompt_info {
    hg prompt --angle-brackets "\
<%{$fg_bold[blue]%}hg:(%{$fg_bold[red]%}<branch>><:<tags|, >%{$fg_bold[blue]%})>\
%{$fg[yellow]%}<status|modified|unknown><update>\
<patches: <patches|join( → )>>%{$reset_color%}" 2>/dev/null
}

PROMPT='${ret_status}%{$fg_bold[green]%}%p %{$fg[cyan]%}%c %{$fg_bold[blue]%}$(git_prompt_info)$(hg_prompt_info)%{$fg_bold[blue]%} % %{$reset_color%}'


3
Have a nice mercurial prompt!

June 11, 2013

VirtualBox modules for Arch Linux

To prevent some butthurt during work with VirtualBox on Arch Linux you need to next modules:

# modprobe -a vboxdrv vboxnetadp vboxnetflt

To load them on system's boot create some .conf file in /etc/modules-load.d and add the modules list to it:

# /etc/modules-load.d/vbox.conf

vboxdrv
vboxnetadp
vboxnetflt

April 23, 2013

Env variables available in KDE

To make some environmental variable available in KDE you should export it during KDE initialization. To do this you can:

1
Create an initialization script, for example:
#!/bin/sh
# my_var_init.sh

export MY_VAR=my_value
2
Put this script to one of the next directories:
~/.kde/env/
# or
~/.kde4/env/
# or something similar

If you absolutely do not know, where to put you script, then go to
"System settings -> Startup and Shutdown -> Autostart" and add path to it.

3
Restart your session.

January 09, 2013

Tapestry plugin for Netbeans

By the ask of my mates I'm placing here link to the Tapestry plugins for Netbeans. They where compiled manually from sources. Do not ask, where I took them from. I just don't remember. In other case here would be the link to them. Have a nice Tapestring!