ipython in emacs with dark background

I use a black bg color theme in emacs,while ipython outputs like this by default:

 

well,some part of the output is black,it sucks

after a travel in the source code of ipython.el and python-mode.el,I found that ipython.el add a "-color lightbg" to command args when start ipython by default,as following:


(unless (member "-colors" py-python-command-args)
(setq py-python-command-args
(nconc py-python-command-args
(list "-colors"
(cond
((eq frame-background-mode 'dark)
"Linux")
((eq frame-background-mode 'light)
"LightBG")
(t ; default (backg-mode isn't always set by XEmacs)
"LightBG"))))))

so I can either modify the py-python-command-args variable or frame-background-mode variable to stop it sucking.

I choose the latter one.

 

BTW:both ways the variable must be set before ipython.el is loaded,for the code above is runned while loading rather than in a function which runned later.

ULK note (1):Segment in linux

According to ULK,linux uses segmentation in a very limit way,namely,linux uses 4 segments,two for user mode and two for kernel mode.Linux also defines macros as segment selectors of these 4 segments:__USER_CS,__USER_DS,__KERNEL_CS,__KERNEL_DS.

I lookup the definition in include/asm-i386/segment.h(crash here for details),let's take a look at __USER_CS and __KERNEL_CS:

#define GDT_ENTRY_DEFAULT_USER_CS 14
#define __USER_CS (GDT_ENTRY_DEFAULT_USER_CS * 8 + 3)

#define GDT_ENTRY_KERNEL_BASE 12
#define GDT_ENTRY_KERNEL_CS (GDT_ENTYY_KERNEL_BASE + 0)
#define __KERNEL_CS (GDT_ENTRY_KERNEL_CS * 8)

well,14(GDT_ENTRY_DEFAULT_USER_CS) is the user data segment descriptor's offset in GDT.

8 is the length of segment descriptor,easy to understand,huh(it's my first thought)?But what is the "+ 3"?

In fact,8 is (1000) in binary,so multiplying 8 left shift GDT_ENTRY_DEFAULT_USER_CS by 3 bits.aha!It's the TI and RPL fields in segment selector!so what the red "+ 3" turns out:it means this segment is in GDT(TI cleared) and it's in user mode(RPL=11).

Similar to __USER_CS,RPL of __KERNEL_CS is set to 00 to indicate that the segment is in kernel mode,so nothing needs to be added.

a note about sbcl and slime

recently I switch to stumpwm,getting it work with sbcl,I enjoyed hacking.
but then I found that when slime read or print Chinese characters,the connection to sbcl will be broken.
Actually,I did set slime-net-coding-system to utf-8-unix,which dosen't help at all.
At last the problem turned out to be due to the coding system of swank side.
as we know,slime connects to a server that was provided by a package named swank.
if I type M-x slime in emacs,everything works well cause emacs runs an sbcl process and set coding system at both side for me,but when sbcl started seperatly by xdm from slime,I forgot to set coding system of swank.
so after I start swank like this:

(swank:create-server :dont-close t :coding-system "uft-8-unix")

I can input Chinese and get correct output at REPL.

ssh to remote server without password

1. install openssh in both local and remote machine;
2. run ssh-keygen in the local machine,you'll get id_rsa and id_rsa.pub;
3. well,the file id_rsa stors your private key,you must keep it secret;
4. while id_rsa.pub is the public key,just keep it from writing by others.
5. deliver id_rsa.pub to the remote server you want to login without password by whatever ways,e.g. scp .ssh/id_rsa.pub user@server:.ssh/ of course you will be prompted for password this time,make sure there is a .ssh directory in the remote server and it's mode is 700
6. cat .ssh/id_rsa.pub >> .ssh/authorized_keys (run in remote server)
7. chmod 644 .ssh/id_rsa.pub .ssh/authorized_keys (also in remote server)
8. now have a try.

note:when you run ssh server without a username,ssh asumes you want to login to remote server with the same user as the local one.
note2:if you put your non-root user's public key to /root/.ssh of the remote server,then you can login to remote server as root directory,so either avoid this situation or protect the password of your local account.

a note about autoconf and automake

after several hours,I got autoconf and automake to work on my program,known as following(with autoconf-2.61 and automake-1.10):

1.run autoscan in the source directory,and we can get a file named configure.scan

2.modify the configure.scan so that it makes sense to our project,

• first of all is AC_INIT macro,i.e. our project name,version,and contact address;
• then add a macro AM_INIT_AUTOMAKE (be careful of the red M),fill it with the project name and version,if it does not exist,then aclocal will not work properly;
• and do not touch AC_CONFIG_HEADER ,it's for people who want make their project portable with a "config.h",so do not feed your project's header files to it;at last comes AC_OUTPUT,set it with "Makefile";
• other macros are project specified,so we skip them here;
• rename configure.scan to configure.ac or configure.in

3.run aclocal to generate aclocal.m4(if no aclocal.m4 generated,there must be something wrong)

4.run autoconf to generate configure

5.create a file Makefile.am,

• set macro bin_PROGRAMS=names(it's the executable file's name,like emacs,mplayer,etc)
• name_SOURCES=files(it's the sources files whitch the binary relies on)
• name_LDFLAGS=flags(e.g. if we use expat, add -lexpat here)

many other macros can be useful,too,but omitted here.

6.run automake -a,touch files which it complains can not find.

7.all right,run ./configure now, we can get Makefile automatically,wonderful,isn't it?