Python Automaticaly-Generated Properties

In my work on ScrollBack I came up with the following class. (Well, technically, its a metaclass.) I know that Python 2.6 has a way of dealing with the problem that this class is supposed to solve, but I believe it is in some ways better than Python 2.6's solution. (Also, what if you're not using Python 2.5 or earlier?)


AutoPropertyM (WARNING: Be sure to get those first two lines at the top, the ones that are outside the class, or else it won't work!)


I'll let the class description do the explaining.

I think this class is better than Python 2.6's `property.getter`, `property.setter`, and `property.deleter` methods because it allows for properties' individual behaviors to be inherited automatically, yet separately, and this includes docstrings as well. It also makes it easy for a property to call functions of its "super property" as ordinary methods in a way that works well with multiple inheritance. (In fact, I had multiple inheritance in mind when I wrote this.) Finally, this system does not require explicitly referring to inherited properties or the classes thereof, as does the use of the `property.Xer` methods. This makes it easier to change the bases of classes.

I have not tested it extensively, but the tests I did try worked well. Theoretically, it should just collapse a getter, a setter, a deleter, and a docstring into a single property (which is what properties are for anyway), but relies on inherited methods and the MRO (method resolution order), so it should work fine for most cases of MI.

EDIT: Now that I think about it, there is one possible flaw: It will inherit methods from parent class properties even if the methods are actually None. This may not be a problem, however.

Internet on Palm Treo 650 using Bluetooth and Ubuntu Jaunty

This is a log of how I managed to get my Palm Treo 650 to connect to the internet by using a
Blueooth-to-WiFi bridge on Ubuntu Linux 9.04 i386. (It will probably work with x64 as well.)

It seems there is a change between Ubuntu 9.04 (Jaunty) and earlier versions that prevents the old methods of getting Bluetooth-powered Internet on a Treo. This is a journal I kept while I was trying to discover the secret for Jaunty.

I realize this isn't the easiest thing to understand, especially if you are new to Ubuntu or
Linux, but if you have some experience, it should get you somewhere. Maybe in the future I will
post a more concrete tutorial to summarize what this journal says.

--

1.) Used tray icon to get the Treo on the trusted devices list as "Brad's Treo".
(Palm sees laptop as "speedyg-0".)
Palm accepted pairing here, but could not connect from the palm (i.e. could
not send any files; get "unable to send to: ..." error on Palm screen.

2.) Found forum post at http://ubuntuforums.org/showthread.php?t=1140766. The
following instructions are by "ihutch" in 3rd reply to the original poster of the thread:

1. Do not edit anything in /etc/default/bluetooth
2. Do edit the /etc/ppp/peers/treo file to include your information about addresses etc, per prior instructions.
3. Everything on the Palm is the same as before.
4.Obtain the bluez-compat package: apt-get install bluez-compat
5. When bluetoothd is already going (check e.g. with ps ax) #> dund --listen -p --msdun call treo
[here treo is the name of the file you editted or created in 2. You must be root (sudo)]
6. Test to show that this works.
7. Hack some script (e.g. /etc/init.d/bluetooth) to execute dund after bluetootd is started, and to kill it
(killall dund || true) just before bluetoothd is stopped. [This is the part that's most annoying.]

3.) The following commands are what I did in accordance with the instructions above:

1.) Installing bluez-compat
$ sudo apt-get install bluez-compat

2.) Checking if bluetoothd is running:
$ ps ax | grep bluetooth
(Outputs "/usr/sbin/bluetoothd" and others)

3.) Created /etc/ppp/peers/treo with the following data:

115200
192.168.3.1:192.168.3.2
local
ms-dns 192.168.1.1
noauth
debug

4.) On treo, created "SpeegyG" bluetooth connection:

Name: SpeedyG
Connect to: PC
Via: Bluetooth
Device: speedyg-0
Details...
Speed: 115,200
Flow ctl: Automatic

5.) On treo, created network service "SpeedyGNet":

Service: SpeedyG
User name:
Password:
Details...
Fallback: -None-
Idle timeout: 3 Minutes
Advanced...
IP Address: Automatic
Query DNS: Yes

6.) $ dund --listen -p -mddun call treo
(no output, no noticeable delay)

7.) Didn't seem to do anything. Tried the above with sudo.
Again, no noticeable delay or output, but the laptop's bluetooth
light blinked a couple times. (Could be a coincidence.)

8.) Tried to connect treo network "SpeedyGNet". It said "Signing on..." for
a while, then failed with some error like "no GPRS service available."

9.) Tried connecting again. This time it just said "bad connection or
faulty modem" immediately after attempting to connect.

10.) Tried step 3.7 above again. (No output, to delay, etc.)

11.) Tried to connect SpeedyGNet again. This time it connected after a short
delay.

4.) Tried pinging laptop IP (192.168.3.1) from palm using Mergic Ping. Success.

5.) Tried pinging home router IP. (192.168.1.1) from palm. Failure (timeout).

6.) Tried pinging laptop again. Success.

7.) Tried to ping treo IP (192.168.3.2) from laptop. Just stalled, never gave
output. Finally gave up. (Ping said 113 packets sent, 100% were lost.)

8.) Tried some stuff from https://help.ubuntu.com/community/PalmBluetoothHowto

1.) $ sudo nano /proc/sys/net/ipv4/ip_forward
Replaced 0 with 1. (Note: gedit has problems with this file, it has to
be nano for the editor.) Actually, the file was empty; I just put a 1
in there.

2.) $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(This was actually a mistake; the eth0 should have been wlan0)

3.) sudo iptables -A FORWARD -i ppp0 -j ACCEPT

4.) $ sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
(Fixed version of step 8.2 above.)

5.) Kill the dund process from earlier.
$ sudo killall dund
(No process killed...odd.)

6.) $ dund --nodetach --listen --persist --msdun call treo
(Starts a new dund process for port forwarding to the treo and gives
output as stuff happens.)

7.) Disconnected Bluetooth from palm, then reconnected. Dund says:

dund[20550]: Bluetooth DUN daemon version 4.32
dund[20575]: New connection from 00:07:E0:25:4C:CB
dund[20577]: Error while executing /usr/sbin/pppd

...then the palm gives the GPRS error from earlier.

8.) Tried connecting again. Same result.

9.) Executed the following lines based on the OP's script at
http://ubuntuforums.org/showthread.php?t=1140766 :

$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$ sudo iptables -A FORWARD -i ppp0 -j ACCEPT
$ sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$ sudo dund --listen --persist --msdun call treo

10.) Tried connecting the treo again. Success.

11.) Tried pinging 192.168.3.1 (laptop), 192.168.1.1 (router), and google.com.
All succeeded!

12.) Wrote the following script based on the OP's script:

#!/bin/bash

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

iptables -A FORWARD -i ppp0 -j ACCEPT

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

killall -v dund

sleep 1

dund --listen --persist --msdun call treo

Script saved to /etc/init.d/treo_bluetooth_internet.sh

13.) # sudo chmod +x /etc/init.d/treo_bluetooth_internet.sh
(Makes the script executable.)

14.) $ sudo ln -sv /etc/init.d/start_bluetooth.sh /etc/rc2.d/S98treo_bluetooth_internet
(Creates a symlink to the script for runlevel 2, the default runlevel.)

15.) After this, the treo should be able to connect to the laptop anytime its
on, but after restarting the laptop the treo gives a "faulty modem" error.

16.) Manually running `sudo /etc/init.d/treo_bluetooth_internet.sh` allows the
treo to connect to the internet after laptop has restarted. (Should not
need manual running...)

17.) To fix this problem, I hack the script `/etc/init.d/bluetooth` so that
`treo_bluetooth_internet.sh` is run when the Bluetooth service is started or
restarted. For me, this means locating the block that starts with `case "$1" in`
and ends with `;;` and on the line just before the semicolons add the line:

/etc/init.d/treo_bluetooth_internet.sh

into the script. (This may vary depending on the machine...there are probably
other places in the script that the line work, but I believe this is the best one.)

18.) The treo can now connect to the internet any time after Ubuntu has booted and connected
to the internet itself, assuming the Bluetooth radio is turned on and the Treo is in
range of the laptop.

Jaunty and Power Management - Part 1

Among some of the oddities that I encountered after upgrading to Ubuntu Jaunty was the fact that its power management skills, compared to Hardy, seem...a bit confused.

In Hardy, I was able to get my laptop's dual CPUs to stay cool and the fan at a low temp by using the CPU Frequency Scaling Monitor tool, a panel app for Gnome. (Of course, I needed to reconfigure a package or two to make it work, but it worked.) What I always thought was odd, though, was the fact that it always seemed to control both CPUs as a single unit. In other words, changing the frequency (or power profile) of one CPU would change the other CPU to match. At the time I figured this was a limitation of the hardware, so I didn't think much of it, and decided just to use 1 cpu monitor app instead of two since I knew that having a monitor for each separate CPU would be pointless.

After upgrading to Jaunty, however, I noticed an odd thing happening after a while: The fan would speed up and the system would get hotter when running a high-power application even though the CPU was set to 'powersave' mode (in other words, 'always-stay-at-minimum-power' mode.). For a long time I thought this was a glitch in Jaunty; Ubuntu THOUGHT it was scaling the CPU down when really it wasn't. But as I recently found out, it was user error...

Apparently, the fact that both processor speeds would change when attempting to change the speed of just one was a problem with Hardy and not the CPU hardware. But I didn't know that, so I had a CPU monitor telling me only half of the truth; one of the CPUs really was running in powersave mode, but the other was still running in ondemand.

Fixing the problem was as simple and obvious as can be: Just add a second CPU monitor for the other processor to the panel.

Sansa Clip Has Special Needs for Media Info

The Sansa Clip is a nice little MP3 player. It's very small and lightweight, and has all the standard features, like playing, stopping, pausing, fast forward, rewind, shuffle, loop, and the ability to locate groups of songs based on artist, album or genre. It also has a built-in FM radio and the ability to record from the radio or from a microphone.

Like many modern MP3 players, it can connect to a computer using a couple of different protocols: MTP and MSC. If you're on Windows and using Windows Media Player to upload and download songs to and from your Sansa Clip, the MTP protocol works just fine. However, if you're on Linux or you want to use software that does not support MTP, then you need to use MSC.

When you tell your Sansa Clip to use the MSC protocal for USB mode, it makes the device act like an ordinary USB flash drive when you plug it in to your computer. This makes uploading songs a simple matter of copying files from your hard drive (or wherever) into the MUSIC folder on your Sansa Clip.

The Clip will play MP3s uploaded via MSC just the same as files uploaded as MTP without any issues. However, unlike the MTP protocol, the MSC protocol does not allow for song meta data (such as song artist, album title, album release year, etc.) to be sent to the Clip. This means that the Clip has to determine such information by reading the ID3 tags of MP3 files uploaded to it. This is where problems come in.

Many modern compressed audio formats, most notably MP3, contain information about the audio they contain (called "meta data") in the form of "ID3 tags." These tags are small pieces of text that are tacked on to the beginning or end of an MP3 file and give the name of the artist who wrote the song, the album that the song was release in, the year the album was released, and possibly a few other things.

There are several different versions of ID3 tags now. But for some reason, the Sansa Clip only supports version 2.3 with a latin1 encoding, or at least that's the only version I've got working with the Clip. Unfortunately, this format is fairly old and many CD ripping tools won't use it, favoring the newer 2.4 or 3.x versions instead. This means that MP3s ripped from CDs using such ripping tools will not sort correctly in the Clip's internal media browser, only appearing in the "Unknown" category for either Artist or Album. This makes locating songs rather bothersome.

To fix this problem, you need to convert the tags of ripped MP3s to version 2.3 with latin1 encoding. There many ways to do this, but the way I have had the most luck with is to use a Linux tool called "eyeD3". On Ubuntu, this can be installed using the following command:

sudo apt-get install eyed3

One you have it installed, you can cd to the directory that contains the MP3s whose ID3 tags you want to convert, then issue

eyeD3 -v some_song.mp3

where "some_song.mp3" is replaced with the file name of any MP3 in the directory. This will output a bunch of information, among which you should be able to see which version of ID3 the MP3 is using.

To change the ID3 tags of all the MP3s in the directory to version 2.3 with latin1 encoding, do this:

eyeD3 --to-v2.3 --set-encoding=latin1 --force-update *.mp3

NOTE: This will actually modify the MP3 files, though the audio itself will remain unchanged.

After changing the tags, you should be able to see the artist, album, year, etc. from the Clip just like songs uploaded via MTP.

Another piece of software you might want to try out is "easytag." It is a sophisticated GUI-based tool for changing the ID3 tags of many MP3s at once and supports ID3v2.3, 2.4, and 3.x.

A Quick, Semi-Fix for a Broken "R" button on the Game Boy Advance SP

A while back the R button on my Game Boy Advance SP stopped responding. I called Nintendo and they said it would be cheaper to buy new one than it would be to have them fix or replace the one I had because it was waaay past warranty. So, I decided to try fixing it myself.

The first thing I did was buy a special Y-shaped (tri-wing) screwdriver. This was actually pretty easy to find using eBay, and it was really cheap: less than $5.00 USD including shipping costs and insurance. It got here within a week of purchase.

The problem with the L and R buttons on the SP is that the plastic gets worn over time and the external "shoulder pads" no longer completely press the real, internal buttons that extend out from the motherboard.

To fix this issue, my plan was to affix some electrical tape to the inside of the shoulder pads so that there would be a bit more pressure between them and the internal button. But let me warn you right now: This method may work with a lot of tweaking, but I never got it to work.

Nonetheless, here's what to do to get to the L and R buttons. NOTE: This will void your warranty, meaning you will not be able to return your SP to the store or get it fixed/replaced by Nintendo! Make sure to read these instructions ALL THE WAY THROUGH before beginning, or you could really mess something up!

1.) If there is a cartridge, take it out. This will reveal a small Y-shaped screw near the cart slot.

2.) Take the battery cover off with a miniature Phillips-head screwdriver. (I had one leftover from an extended battery pack kit that I bought a while back.) Remove the battery to reveal a another Y-shaped screw.

3.) There is no step three. :)

4.) At each corner of the bottom of the SP there should be a Y-shaped screw. Combined with the two above, there is a total of 6 screws that need to be removed (not counting the one on the battery cover). Simply remove all the screws with the Y-shaped screwdriver and set them aside. (Careful, they're really small and easy to lose!). The back of the SP will now be loose, so be careful not to let it fall off.

5.) With the bottom of the SP facing down, carefully pull the top, including the screen, controls, and motherboard, off of the bottom. It should all come off in one piece, but the L and R shoulders may stick to the top and the joint pins may fall out, so be ready to catch them. This will expose the backside of the SP's motherboard, including the CPU, so be very careful not to damage anything!

6.) The L and R outer buttons are wedged between the top and bottom halves of the SP's casing and each is spring-loaded using a mechanism involving a short, thick metal pin and a thin, wiry spring through which is "wrapped" around the pin. Once the back of the casing is removed, there's very little to hold all the pieces of this mechanism in place, so if you turn the back upside down it will likely fall apart. It's not too hard to get them back together again, but chances are, this will make BOTH the shoulder buttons stop working for good!!! You have been warned.

Under each shoulder button is a small, round internal button about the size of a point from a Sharpie marker. You can press these in to hear them click. These are the "true" L and R buttons, and you need only press these to make the SP react. However, they seem to require a certain amount and angle of pressure that the outer shoulder buttons fail to provide after a while of use. You can try fixing this by wedging things between the outer and inner buttons, but I didn't have much success that way. Instead, I merely removed the outer buttons completely so that I could press the internal buttons directly. I didn't spot any electrical contacts near the internal buttons, but I can't be positive, so I can't guarantee that this is completely safe either for you or your SP...but hey, it basically works.

7.) When reassembling the SP, make sure that the power switch did not fall out. If it did, putting it back in is a fairly simple matter; just stick it back into the bottom half of the casing and slide it back and forth to make sure it clicks between the "on" and "off" positions.

8.) Put the casing back on the bottom of the SP, making sure all the stuff fits into the right grooves. Lay the SP upside down and screw the Y screws back in, but make sure not to confuse the corner screws with the smaller screws that come from behind the battery and game cart slot.

Now you have an SP with its internal L and R buttons exposed. You have to stick your fingers inside the holes at the corners to get to them and its a bit uncomfortable after a while, but they work.

Curing Jaunty's Fear of Touchpads.

Actually, I had one issue with upgrading to Ubuntu Jaunty, and it's an issue that has been reported by a number of people: A number of laptop touchpads no longer work out-of-the-box.

Apparently, this is some kind of bug with the X server's input drivers that needs to be fixed. It affects people whose touchpad is reported by the output of the command "xinput list" as "ETPS/2 Elantech Touchpad" or "SynPS/2 Synaptics TouchPad".

There are a couple of ways to get around this issue.

1.) Use an external mouse (because external mice don't seem to be affected by the bug), or
2.) Change the mouse driver options. There is a script for this given below.

Before I give you the script, however, please note the following:

a.) Run the script from a TTY terminal, and NOT from a X terminal emulator like xterm or gnome-terminal. If you don't, there is a chance that the X server will freeze, forcing you to restart.
b.) Run the script with ROOT PRIVELAGES by adding `sudo` to the beginning of each line, or else putting the lines into a file and executing that file with root privelages.
c.) As a side effect, this script will disable some options from the Gnome mouse configuration menu. If after running the script you find that some options were disabled that you needed to use, you can undo the changes by running the second script below.

Here is the script to enable the alternate mouse driver settings:


#!/bin/bash

modprobe -r psmouse
modprobe psmouse proto=imps
echo "options psmouse proto=imps" > /etc/modprobe.d/touchpadfix.conf


Here is the script to undo the changes made by the script above:


#!/bin/bash

modprobe -r psmouse
modprobe psmouse
rm /etc/modprobe.d/touchpadfix.conf


Again, make sure to run those with root privileges from the TTY command line and not from an X terminal.

As far as I can tell, what this basically does is unload the mouse drivers from memory and then load them back again using a different set of options that make it detect the mouse hardware differently. Then, it adds an option to the system configuration that makes sure that the mouse driver is always loaded with the new options whenever the system boots, making the changes permanent. The other script does the opposite.

I adapted these scripts from a solution given by a bug report by Ricardo Faria which was linked to by Matataki on the Ubuntu forums. Thanks, guys!

Sources:
* Touchpad not working (Jaunty)

* [Jaunty] synaptics driver needs to be updated [...]

EDIT: A line of the first script didn't seem to be working correctly anymore, but it's been fixed now.

Upgrading to Ubuntu 9.04 (Jaunty Jackalope) with a Fresh Install

Well, I haven't had much to say in a while, which is unfortunately something I'm well known for. But for this blog at least, I'm going to try to change that.

For the last few days my install of Ubuntu 8.04 Studio Edition has been acting completely wonky for no obvious reason--sound systems not working, random freezes, abnormally sluggish behavior, freezing after waking up--all signs of a corrupted OS. I don't know what I did, but I must have broken something.

At this time I realized three important things:

1.) My computer was fudged.
2.) I really need this fixed.
3.) It's the weekend.

This got me to thinking: Hey, this would be a great time to give Intrepid another go! So I did.

I don't know if I mentioned this before, but I recently upgraded my laptop's HDD to a 250GB SATA, a huge improvement over the original 80GB SATA. This made it possible for me to create a separate partition for the OS and still have lots of room left over for my personal data (i.e. put /home on its own partition). With this setup, upgrading is a lot more safe because I can easily remove the OS without fear of damaging years worth of precious personal data.

I decided to do a fresh install to Intrepid rather than an upgrading through the usual tools because experience has told me that upgrading from one version of an OS to another almost never works the way its supposed to, and tends to create a lot of unwanted work. This is true not only for Ubuntu, but for any OS, as I have heard.

Installing Intrepid this time around with a simple matter of popping the CD in and telling the installer to reformat /dev/sda2 for the OS but keep /dev/sda3 for data. There was a slight hiccup with getting connected to the wifi network, but after getting the latest system updates for 8.10 that basically went away.

Then I realized that Jaunty has been out for about a month now. Well, dang!

I figured I might as well install Jaunty, even though I just spent an hour or so installing Intrepid--better now then later when I've made all my customizations. I downloaded the CD (quickly, too; I must have gotten to the server at a good time of day), burned it, and kept it in the tray while I rebooted.

The CD wouldn't boot. I just got a message saying "syslinux loading..." (or something to that effect) and it just froze there. Not sure why this happened, because the CD booted fine on the family desktop. In any case, I didn't feel like checking the CD for defects, so I decided to try a different route: Network installation.

Net installing wasn't actually as hard as I thought, and it didn't require a single disc (or disk). However, it did require another computer on the network; in this case, the family desktop running Windows XP.

The procedure is as follows:

1.) Download TFTPD32. This is a free TFTP server for Windows that will serve out the files needed to boot the Ubuntu net installer. If you plan on using this and then forgetting about it (like I did) then just download and extract the .zip version into a folder you have access to.

2.) Use Windows Explorer or an FTP client to download the installation files from the Ubuntu FTP archive. This will be a folder called "netboot" containing files of various types. I'm not sure exactly what the installed needs from this, so its best to download the whole folder. For the i386 version of Jaunty, the folder is located here at this URL:

ftp://archive.ubuntu.com/ubuntu/dists/jaunty/main/installer-i386/current/images/ .

(For other versions, you may need to navigate up to a higher level and locate the necessary files. The archive is organized pretty well, so it shouldn't be to hard to find what you need.)

3.) From the local copy of netboot\, locate the folder called ubuntu-installer\ and copy the entire thing into the same directory as the TFTPD32 executable (.exe) file. (Note: Do not copy the CONTENTS of the folder, copy the folder itself!

4.) In the same way as above, copy the folder pxelinux.cfg\ and the file pxelinux.0 into the TFTP folder.

5.) Start the TFTPD32 executable with admin rights. Make sure that your firewall is either disabled or else configured to let TFTPD32 connect to whatever it wants.

6.) Find the DHCP tab in the TFTP window and configure it for your network. This is going to vary from computer to computer. My network has a central 4-port switch/wifi router that functions as the main gateway to the Internet and probably also functions as the WINS server (whatever that is) and its IP address is 192.168.1.1 on my LAN, so I used the following settings:

IP Pool starting address: 192.168.1.100
Size of pool: 50
Boot file: pxelinux.0
WINS/DNS server: 192.168.1.1
Default router: 192.168.1.1
Mask: 255.255.255.0
Domain name: (this was left blank)
Additional option: 0 (second field left blank)

Then I clicked "S a v e".

(The address 192.168.1.1 above should be replaced with the IP of your network's main gateway, though 192.168.1.1 is usually the default.)

7.) Optionally, click the second "log" tab so you can see what your target computer is about to do.

8.) Boot up the computer you are going to install Jaunty onto and configure the BIOS to boot from LAN/use PXE bios. This will vary wildly from computer to computer, so you're on your own for this part.

9.) Plug the computer into the same network that the TFTPD-running computer is serving from and restart it. (I mean restart the one you're trying to install Jaunty to, not the one running TFTPD.) If the BIOS was configured correctly, and if TFTPD is running and is not being blocked by any firewall, the Jaunty-to-be computer should load the PXE files and you will see the familiar Ubuntu logo.

10.) Press "enter" to enter the interactive, text-mode installer.

11.) At this point you can probably close TFTPD. On my system I had to because, the idiot that I am, I had my DHCP settings conflicting with the settings of my router, making it difficult to connect to the Internet.

At this point my particular set of choices were different from what most people's would be. I first told the installer to use /dev/sda1 for swap, /dev/sda2 for the root filesystem (/), and /dev/sda3 for personal data (/home/). I decided to give the new ext4 filesystem a try for my root, but obviously I left the /home/ partition alone (i.e. opted to NOT format it).

Next, I selected the software packages I wanted, and began installing. However, for whatever reason, installation failed unless I only picked the default Ubuntu Desktop collection (and, of course, the core Linux files). But that wasn't a problem; I merely installed the other packages later after the net install was over.

From there, everything worked like a charm, and I have to say, Jaunty is NICE! And guess what? They finally fixed whatever it was that kept causing my system to freeze after resuming from suspend-to-ram while using Compiz! Excellent! Now I can finally go fully-Compiz!

EDIT: Actually, I did have one minor issue upon upgrading. However, a solution to the issue was found the next morning. See the following entry: Curing Jaunty's Fear of Touchpads.