Personal.X-Istence.com

Bert JW Regeer (畢傑龍)

Ballmer is delusional

This article at The Mac Observer proves it. Also, as for your mouse choices, let me the first to say that my Microsoft Laser Mouse 6000 works perfectly fine with Mac OS X and all my other devices. It is one of the only mice I have found so far that does exactly what I need it to do. After I forgot mine on a plane last year I even ordered a brand new one.

If Ballmer instead had said that Apple's mice suck and that they are uncomfortable to use I would have fully agreed with him. They after all decided that a mouse shaped like a hockey puck would be a good idea. The Mighty Mouse is an interesting concept, but that is all it should ever have been. Sure the little ball in the middle is an excellent idea, and sometimes I miss it, it gets dirty fast and then it stops working. Sometimes it refuses to register right clicks (there is no physical button for right click, it is sensitive as to which finger is where), middle clicks would sometimes become just standard left clicks. Ugh, it was a mess.

Ballmer, your own company created mice work on the Mac, go out get a Mac and experience it for yourself, and stop spouting crap! Come back when you have some experience underneath your belt!

Facepalm

The past few days I have been working on some bits and pieces of code, and I facepalmed myself at 0226 in the morning. I opened up an older part of the project, and I had totally forgotten I had written a config parser. It opens up, and it is scrolled half way down the page, so I don't see my Copyright tag on it at the top.

I look it over a few lines, and suddenly I say to myself:

Wow, that is an interesting way of accomplishing that. I would have never thought of that

Interesting trick

Written with security in mind

Line counting, and even tells the user what error it has encountered!

Wanting to know who wrote this code, figuring it was someone I was working with at the time, I read the copyright:

* Copyright 2006 Bert JW Regeer. All rights  reserved.

Yeah, facepalm. Anyway, luckily I do remember why I was writing it, and I wrote down in the sample config file what the config parser is supposed to parse, so I know that it parses stuff like this:

# <sub-system name> {
#       id: <number>;                           # Any number that is not taken
#       program: bin/something;                 # Full path, or take workingdir/<program>. So /usr/local/bin/something in this example.
#       arguments: -user xistence;              # Pass an arbitrary amount of arguments to the program to be executed
#       env: SPECIALSAUCE=yes,MAYO=no;          # Pass environment variables to the executing program.
# }

The config system is there to allow different programs to be run by the daemon depending on user input. So for example, this would be a valid sub-system:

adduser {
    id: 10
    program: bin/specialadduser
    arguments: --skel=/usr/local/skel
}

Anyway, I was pretty damn impressed with my own code from 2 years ago. Now that I have looked at it again, I remember writing it while I was bored during my summer vacation. That same summer vacation I wrote my own regex library, which sadly I have removed from existence, since it was too complicated to maintain. It was however able to do some of the following:

(a*) to look for a followed by any characters, and store it.
a+ to look for 1 or more occurrences of a.
(.*) { (.*) } would also work, it would store whatever it found before a "
{" in an array as position 0, and then whatever was in the curly braces in
array position 1. It is probably for the best that the code is gone, but it
was an interesting exercise none the less.

Maybe later I will post more information. I am heading back to my other code, it is nowhere near finished!

PHP 5.2.6 on FreeBSD with extensions

There seems to be an issue in PHP 5.2.6 with extensions where the extensions have to be loaded in a certain order or the PHP interpreter has a tendency to crash and fail miserably. It is weird, as depending on the system configuration the order of the extensions has to be entirely different.

Certain extensions have a dependency on other extensions and their functionality so it is understandable that they are required to be loaded before the other modules can be loaded, however this has never been an issue before. I am not entirely sure how PHP does it, but I am betting it loads all the modules and then runs an init function of sort, and since all the modules are loaded at the same time, there are no issues.

However, in this case it seems that multiple functions are clashing, or something along those lines.

Running PHP in a gdb session showed the following:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x29803544 in __do_global_dtors_aux () from /usr/local/lib/php/20060613/simplexml.so
#2  0x29807c04 in _fini () from /usr/local/lib/php/20060613/simplexml.so
#3  0x2824f558 in tls_dtv_generation () from /libexec/ld-elf.so.1
#4  0x28251558 in ?? () from /libexec/ld-elf.so.1
#5  0xbfbfe9c8 in ?? ()
#6  0x282327b6 in elf_hash () from /libexec/ld-elf.so.1
#7  0x282350a0 in dlclose () from /libexec/ld-elf.so.1
#8  0x081374e4 in zend_hash_apply_deleter ()
#9  0x0813757f in zend_hash_graceful_reverse_destroy ()
#10 0x0812da7c in zend_shutdown ()
#11 0x080f4f67 in php_module_shutdown ()
#12 0x081aa892 in main ()

So it seems that simplexml is the culprit here, lets remove it. Once removed from extensions.ini we re-run gdb and give it the same information we gave it before, this time however we see this:

Cannot load module 'SPL' because required module 'simplexml' is not loaded in Unknown on line 0

My gut instinct is to now move simplexml ABOVE the line that says extension=spl.so. After we do this, PHP is able to run without any issues. Now, for the fun:

extension=spl.so
extension=xml.so
extension=ctype.so
extension=zlib.so
extension=session.so
extension=mbstring.so
extension=pdo.so
extension=pdo_sqlite.so
extension=ftp.so
extension=posix.so
extension=pcre.so
extension=json.so
extension=zip.so
extension=suhosin.so
extension=pdo_mysql.so
extension=bz2.so
extension=openssl.so
extension=gd.so
extension=pdf.so
extension=hash.so
extension=mhash.so
extension=curl.so
extension=mcrypt.so
extension=xmlwriter.so
extension=tokenizer.so
extension=filter.so
extension=simplexml.so
extension=iconv.so
extension=sqlite.so
extension=dom.so
extension=xmlreader.so
extension=gettext.so
extension=tidy.so
extension=mysqli.so
extension=mysql.so
extension=sockets.so
extension=pspell.so
extension=imap.so
extension=ncurses.so
extension=xsl.so

Is the extension list on one of the servers I administrate. Notice that spl.so is at the top of the file, and simplexml.so is somewhere in the middle. And this works perfectly, however the same file on a second server causes it to bomb spectacularly. However, I had kept a backup of the original extensions.ini on the second server, put it back, and then experimented with it, and this is what came out:

extension=simplexml.so
extension=spl.so
extension=suhosin.so
extension=json.so
extension=zip.so
extension=filter.so
extension=hash.so
extension=session.so
extension=sysvmsg.so
extension=gd.so
extension=pdf.so
extension=tidy.so
extension=magickwand.so
extension=odbc.so
extension=calendar.so
extension=sysvshm.so
extension=soap.so
extension=tokenizer.so
extension=mcrypt.so
extension=iconv.so
extension=readline.so
extension=sysvsem.so
extension=bz2.so
extension=zlib.so
extension=ftp.so
extension=pcntl.so
extension=ncurses.so
extension=posix.so
extension=gettext.so
extension=mhash.so
extension=pcre.so
extension=mbstring.so
extension=xmlwriter.so
extension=xml.so
extension=xmlrpc.so
extension=sqlite.so
extension=openssl.so
extension=ctype.so
extension=ming.so
extension=dom.so
extension=xmlreader.so
extension=curl.so
extension=mysqli.so
extension=mysql.so
extension=sockets.so
extension=imap.so
extension=xsl.so

Now when I tried this on the first system where that first configuration file comes from, it bombs spectacularly leaving a core-dump. I have NO IDEA what is going on. I just know that log messages like the following:

pid 54662 (php-cgi), uid 80: exited on signal 11 (core dumped)
pid 54655 (php-cgi), uid 80: exited on signal 11 (core dumped)
pid 54658 (php-cgi), uid 80: exited on signal 11 (core dumped)
pid 54661 (php-cgi), uid 80: exited on signal 11 (core dumped)
pid 54660 (php-cgi), uid 80: exited on signal 11 (core dumped)

are a thing of the past, until next time when I upgrade or re-compile PHP and the order is played with again.

If you have any hints, insights or knowledge of what is going on, and what magic order I have to place the extensions in, please let me know by sending me an email at xistence@gmail. This is going to be a mystery, for now, as I definitely don't have the time to figure out what is going on and why.

Happenings and assembly

School has started again, I am taking six classes. I am now really gearing up to finally leave UAT and go out into the work force. I have this semester, and two more to go and then comes the decision; graduate school or work? Not entirely sure yet which I want to do, but that is what life is all about, trying to figure out what the best would be, and possibly finding out it was a mistake and growing and learning.

There are others things that have been going on lately, I have been spending much time behind a computer screen programming. The intellectual challenges it provides me with are very enjoyable and great way to stay mentally fit. Also as a perfectionist by nature, it makes it really hard to start working on something and then put it down to go to sleep, it has to be perfect. That is probably also the reason why I now have a 300 line patch set instead of 500 lines. Yay for removing redundant code, and re-thinking the problem/solution.

Other things that I have been working on is a challenge that my room mate Victor (Pancho) gave me. It requires a recursion to complete the problem. In itself this does not generally present a problem, as the max recursion level is going to be limited to a fairly reasonable number, however in C/C++ there is still a massive amount of overhead when doing a function call. This includes things like setting up the stack, creating local variables, and then saving certain states. Extra garbage that you want to eliminate especially in tight loops. The problem however cannot be solved using for/while loops, or at least there is no way that I can figure out (if you want to know what it is that I am working on, contact me. Victor is going to make the challenge public later so I don't want to spoil it for everyone). So I have been writing some self-modifying code that unrolls loops on the fly. I will post code sometime in the near future when I have it partially working, not entirely sure yet how I want to proceed right now. More on that later!

Here is a bit of Intel assembly written in AT&T syntax for GCC to grok for Mac OS X/FreeBSD machines that use a stack based syscall infrastructure:

__asm__("pushl  $21;\n"
    "pushl  %0;\n"
    "pushl  $0x1;\n"
    "movl   $4, %%eax;\n"
    "pushl  %%eax;\n"
    "int    $0x80;\n"
    "addl   $16, %%esp;\n"
    :
    : "r" (answer)
    : "%eax");

Note that the length of the string is 21 characters (20 characters, and a newline which I appended before printing), and that answer is the char *. See my previous Intel post to see what the code does, and why. It is exactly the same printing routine, only difference is the assembly syntax. It really is too bad that GCC for Darwin does not grok the .intel_style inline assembly, it would have made things much easier.

You should be able to modify it to accept an integer to push onto the stack, however I have been unable to figure out why the following is not working:

__asm__("pushl  %0;\n"
    "pushl  %1;\n"
    "pushl  $0x1;\n"
    "movl   $4, %%eax;\n"
    "pushl  %%eax;\n"
    "int    $0x80;\n"
    "addl   $16, %%esp;\n"
    :
    : "r" (length), "r" (answer)
    : "%eax");</pre>

Assuming length is an integer and answer is a character pointer. It is kind of frustrating, because there are not many good resources out there on the web that explain inline assembly for GCC. The few that I have been found have been rather vague and have not explained very much. Maybe I am just using the wrong words, and or my Google-Fu is not strong enough.

Speaking of inline assembly, I have heard from some friends that are running on 64-bit systems that if you compile 64-bit binaries for Windows in Visual-C++ 2008 you are not allowed to use inline assembly, they have removed support for it. Does that seem wrong to anyone else? That seems like it would frustrate many developers of tight code that runs many times faster in assembly than using compiled code. Sure compilers have been getting better for ages, however at the same time in assembly the programmer has a lot more control over the CPU and where time is going to be spent than any other way.

Oh, Erlang is my new shiny programming language to learn.