Me. On hacking and searching for solutions.
Last.fm scrobbling troubling on Slackware64 13.1 | Hacking inlook 1.0.0-pre1.pl | Hacking viewtxt.pl | Hacking birthdays.pl | /dev/dsp error | Hacking inlook 0.8.14 | Hacking inlook 0.8.12.pl | Hacking inlook-0.8.8.pl | xzgv 0.8 issue | Hacking Songs v0.3
2010/05/26IMPORTANT NOTICE: The information below doesn't work out as it should. It caused system locks and reboots. I switched to qmmp, which compiled fine from source. I just wanted everyone to know.
Slackware 13.1 was released recently, and today I installed it on my workstation. It all seemed pretty nice, until... What the... No scrobbling with Last.fm in Audacious? It took me a long time to realize the problem. The Audacious development team had excluded the plugin for the 2.3-version which ships with Slackware 13.1. Well, ok. I guess you could do the same thing with version 2.2, but I went back to 1.5.1 which is used in 13.0. I downloaded the packages from my local mirroring site, and executed the following commands:
$ su(You need to be root.)
$ pkgtoolAnd removed the Audacious-package (including the plugins).
Then:
$ installpkg audacious-plugins-1.5.1-x86_64-4.txz
$ installpkg audacious-1.5.1-x86_64-3.txz.I'm happy. Once again.
2010/03/12Today I released inlook 1.0.0-pre1.
A problem I've been working on for a long time was solved with this code.
It works fine, but I guess I have to "polish" the code a bit. Anyhow I felt that the time was right to release pre1. I am actually using inlook as my main e-mail client right now. :)
2010/01/28Up late - again. Hacking. Perl. Searching for solutions.
I'm not quite sure on how important this was, but anyhow I think i solved a security-leak with the following line:
if ((!$full=~/doc/)) {Time will show how important this was. But hopefully this will prevent cracking and other stupid nonsence on my domain.
You may as well check out the full source for further details.
20090513I'll never learn. Up late. Hacking. Perl. Again.
I've hacked a lite tool for remembering birthdays. See the source for details and instructions.
20090408Well. What can I say. Up late again. Not hacking, just searching for solutions. As stated before, I did a small hack with Songs v0.3. After installing Slamd64, and compiling Linux kernel 2.6.28 - /dev/dsp couldn't be found on my system, and I had no idea on what to do. Songs wouldn't play my wav-files, and unfortuntaly it doesn't support ALSA, but OSS only.
It's quite embarrassing, actualy. All I had to do was
modprobe snd-pcm-oss.So.
My
/etc/rc.d/rc.localnow containts these lines (among others, of course:)
echo "Now loading module: snd-pcm-oss" modprobe snd-pcm-ossMe. Happy. Now.
20090401Up late and hacking - again. The code below says it all I guess.
It's quite messy, but it does the job. Now I am soon going to sleep.
20080610I've been late up coding, again. The whole night. Bless the caffeinated drinks.
Anyway, I've done some improvements on inlook. Now I have a spambox and sent-mail folder, which is used inside of inlook. Earlier you had to quit inlook and use 'cd' to reach the actual e-mail(s). Here's how the spambox works:
It's VERY satisfying when the code works flawlessly.
20071023Well, where should I start. Inlook, my e-mail sending and receiving program needed an update. This time, I wanted to make a better configuration-system. The old solution looked like this:
open(CONFIGUREFILE, "<$config_file") || print "$0: can't open $config_file: $!\n"; @configure_lines=<CONFIGUREFILE>; chomp($mail_real_name=substr($configure_lines[0], 10));This is of course not good. It makes the configuration-file (~/.inlook/inlookrc) less flexible and hard to modify. Although I have an automatic setup for configuring inlook when running it for the first time, I felt that I needed to perform a little and very simple hack.The new solution is quite simple, and now looks like this (in this example, we want to find the real name from the configuration-file):
open(CONFIGUREFILE, "<$config_file") || print "$0: can't open $config_file: $!\n"; @configure_lines=<CONFIGUREFILE>; for ($i=0; $i<20; $i++) { if ($configure_lines[$i]=~/real_name/) { chomp($mail_real_name=substr($configure_lines[$i], 10)); $check=1; } } if (!($check)) { print "$0: configuration error: please check $config_file\n"; &main(); }It does the job quite nice, and works perfectly. Now I have to change this for the whole code, which is going to take some time...
20070727Running an x86_64 isn't that easy, after all - some programs just don't seem handle it. An example: I like xzgv (and yes - I'm aware that it's outdated), and used it all the time on my x86-laptop. Now, with x86_64 I got the following error messages while running
make:stian@xasthur:~/programmer/xzgv-0.8$ make cd src && make xzgv make[1]: Entering directory `/home/stian/programmer/xzgv-0.8/src' gcc -O2 -Wall -DINTERP_MMX -DBACKEND_IMLIB1 `gtk-config --cflags` -c -o main.o main.c main.c: In function `do_logo_invert': main.c:4590: warning: operation on `ptr' may be undefined /tmp/cc9apfZc.s: Assembler messages: /tmp/cc9apfZc.s:13445: Error: suffix or operands invalid for `pop' /tmp/cc9apfZc.s:13448: Error: suffix or operands invalid for `push' /tmp/cc9apfZc.s:13451: Error: suffix or operands invalid for `pop' make[1]: *** [main.o] Error 1 make[1]: Leaving directory `/home/stian/programmer/xzgv-0.8/src' make: *** [xzgv] Error 2It took some time, but eventually I realised both the cause and solution. Inxzgv-0.8/config.mkwe can see the following compiling options:CFLAGS=-O2 -WallAfter some thinking I found out the that I had to editconfig.mklike this:CFLAGS=-O2 -Wall -march=x86-64 -mtune=x86-64I also had to uncomment a line inconfig.mkin order to make this work (like I've done on the line below):# CFLAGS+=-DINTERP_MMXNow, I've also created an x86_64 Slackware package which is available here.Happy hacking!
20070719Songs is a nifty program written by an enthusiastic individual which have written many hacks and programs. I use it with my noise-project and I really like it. It worked like a charm on my x86-laptop, but as I moved to x86_64 the program compiled fine, but exited with an error message. It would be sad if I couldn't use the program on my x86_64.
The error message I got was the following:
stian@xasthur:~/programmer/songs-0.3$ ./songs Sorry, on your machine sizeof(int) < sizeof(void *) the program can't handle it.Now, I e-mailed the author, and he explained to me that I could try to uncomment some lines inmain.cand see if that worked. That's exacly what I did, and as expected it worked fine.The lines that causes the problem is the following:
if (sizeof(int) < sizeof(void *)) { fprintf(stderr, "Sorry, on your machine sizeof(int) < sizeof(void *)\n"); fprintf(stderr, "the program can't handle it.\n"); return 1; }I decided to solve the problem with some sort of style, so I ran the following commands to create a patch.stian@xasthur:~/programmer/songs-0.3$ cat main.c > new-main.c(Note that innew-main.cI have modified the five lines above.)stian@xasthur:~/programmer/songs-0.3$ diff -u main.c new-main.c > songs-0.3.x86_64.patchYou can download the patch from here, and copy it to the songs-0.3/-directory.Use the following command to patch the program:
stian@xasthur:~/programmer/songs-0.3$ patch -p0 < songs-0.3.x86_64.patch stian@xasthur:~/programmer/songs-0.3$ makeThat's it. The program _can_ handle it! :-)20070727 Update: I have now created a Slackware package with Songs, it's available here.
This page was last modified Thursday, 03-Jun-2010 21:04:38 CEST
Copyright (C) 2007, 2008, 2009, 2010 Stian Skjæveland.
Verbatim copying and redistribution of this entire page are permitted provided
this notice is preserved.