Exercise: Write a function that returns the length of a list (without using the scheme length function).
My try:
(define mylengh
(lambda (ilist)
(letrec ((mylengh-rec
(lambda (rlist nr)
(if (eqv? rlist '()) nr
(mylengh-rec (cdr rlist) (+ nr 1))))))
(mylengh-rec ilist 0))))
Solution:
(define (mylength a)
(if (null? a) 0
(+ 1 (mylength (cdr a)))))
Well… It is a start. :)
Como parte da comemoração do turbulento hexa campeonato, decidi postar as duas últimas Pérolas que eu tinha anotado este ano, quem sabe um dia eu revele a identidade do ‘crânio’ que disse todas essas coisas…
“vim é um notepad sem recursos gráficos”
“Portabilidade é a capacidade que o programa tem de rodar em máquinas com poder de processamento diferentes, por exemplo, o mesmo programa que roda em um K6-II roda em um Pentium 4″
As I am going to play with the VMA code and its main data structure (a red-black tree), I have started to collect some data by using systemtap, and got a bit impressed by the number of times find_vma() is called by some processes, as shows the table below.
| PID | exec name | nr calls (5 seconds) | doing… |
| 21984 | cc1 | 1570 | Compiling Linux kernel |
| 11533 | X | 13252 | Switching work spaces |
| 23554 | git-index-pack | 42213 | Resolving deltas |
So, in this specific case gcc has searched its VMA tree 1570 in five seconds while (probably) compiling some C file. Is that a big number? I am not sure but X, for example, is calling find_vma() more than 2600 times in a second if I switch fast between work spaces in Window Maker. I did not expect this.
Git is the winner so far, more than 8000 searches in one second while resolving deltas in a clone operation.
I also wanted to know what are the most called system calls that may search (or change) the VMAs’ tree, and here goes some more numbers:
| system call | nr calls (5 seconds) |
| sys_mmap2 | 11039 |
| sys_munmap | 5102 |
| sys_brk | 3574 |
| sys_execve | 392 |
| sys_clone | 255 |
| sys_vfork | 82 |
This snapshot has been taken while compiling the Linux kernel and while the numbers are of no surprise, there are two interesting functions in that table, brk() and vfork(). I thought that their usage would be very rare these days: users of brk() are now using mmap() and I was wondering whether it makes sense to use vfork() in a modern kernel like Linux, with very fast process creation time and copy on write support.
But a quick look at the code shows that sys_vfork() passes the CLONE_VM flag to do_fork(), this in turn will avoid the creation of a new address space for the child. In other words, they will share the same mm_struct and that makes vfork() faster than regular fork() (threads also share the same mm_struct).
Very cool stuff, I am being good at choosing projects.
While reading the 2.6.27-rc9 announcement email today (looking for fixed bugs, of course) I found this:
PS. I already bugged people on the git lists with this, but since I’m
totally shameless and can’t help but hope that some random kernel person
also does tcl/tk or just wants to help improve my kids-time-tracker, I can
just point tohttp://torvalds-family.blogspot.com/2008/10/tracking-time-kids-spend-online.html
and hope that somebody would like to make that GUI better and/or feel like
they really want to do a “management interface” too ;)
I got a bit confused because the keywords that blinked in my brain were “git”, “tcl/tk”, “kernel”, “kids” and “family”.
Then I discovered that Linus has a blog now and the coolest thing about it is that it is not just another tech- or kernel- blog, he is going to talk about his family too.
That is cool because I am always looking for ways to improve my son’s education and there are not lots of kernel hackers’ blogs about that out there. :)