A simple app ought to do it.
Download iRinger. It used to be a Windows app, but is now available for Mac OSX!
A very intuitive application. Select a song (mp3 for example), it clips it and shows you the ringtone-worthy segment of it, you basically export it as a ".m4r" file.
When done, just open the file and iTunes will automatically open it. Done.
Read MoreThis regexp worked for me.
1 2 3 4 5 6 7 8 9 10 11 12 | SELECT * FROM TABLE WHERE NOT COLUMN ~ ( '^('|| $$[\09\0A\0D\x20-\x7E]|$$|| -- ASCII $$[\xC2-\xDF][\x80-\xBF]|$$|| -- non-overlong 2-byte $$\xE0[\xA0-\xBF][\x80-\xBF]|$$|| -- excluding overlongs $$[\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}|$$|| -- straight 3-byte $$\xED[\x80-\x9F][\x80-\xBF]|$$|| -- excluding surrogates $$\xF0[\x90-\xBF][\x80-\xBF]{2}|$$|| -- planes 1-3 $$[\xF1-\xF3][\x80-\xBF]{3}|$$|| -- planes 4-15 $$\xF4[\x80-\x8F][\x80-\xBF]{2}$$|| -- plane 16 ')*$' ) ; |
Or, if you have iconv on your system, as most UNIX variants do, you can pg_dumpall a database and run the following command on it:
if (@iconv($input, 'UTF-8', 'UTF-8') == $input) echo "Good UTF-8!"; else echo "Nope."
Then take a plain text pg_dump of the database in UTF-8. Let's call it "db.orig.dmp". Strip all problem characters:
iconv -f UTF-8 -t UTF-8 -c <db .orig.dmp >db.stripped.sql </db>
Compare both files:
diff -u db.orig.dmp db.stripped.sql
That output will show all lines containing a problem character. Now the tedious part: Use "db.orig.dmp" to find out which tables they belong to, locate the records in the database by primary key and fix them. Alternatively, you can use iconv's auto-repair if you know which bytes give you a problem.
For example, if you know that the trouble stems only from 0×80 bytes that should be Euro symbols, you could:
iconv -f UTF-8 -t UTF-8 --byte-subst="<0x%x>" < db.orig.sql | sed -e 's/<0x80>/EUR/g' >db.fixed.sql
The resulting "db.fixed.sql" could then be loaded into the new database.
Read MoreIf you use Firefox (and if not, what are you waiting for?) you are familiar with useful extensions such as Video Downloader, which allow you to save local copies of the videos you watch on websites such as Youtube or Vimeo. You can then watch these videos whenever you please.
But this doesn't account for those rare but possible times when you are not on your machine, or don't have access to a browser set up to your tastes. No extensions available.
That's where "KeepVid" comes in. Just enter your URL and it automatically extracts any video(s) found on that website and allows you to download in both FLV and MP4 formats. The MP4 would play on your Nokia, iPhone, or Blackberry too. The FLV file is a flash viewer file, and easily played using common video players – if you don't have VLC, get it pronto.
Here's a straightforward screenshot:
You use PostgreSQL. You find that a column you have in a table is of a smaller length than you now wish. In my case, this was a varchar(20) that I now wished to make varchar(35). Nothing else. I just want to change the size, keeping the data intact.
The ALTER TABLE ...ALTER COLUMN...TYPE... command is useful only if you want to alter the data somehow, or change the data type. Otherwise, it'll be an aeon before this finishes even inside a transaction on a database of any meaningful size.
Until now, I was not familiar with any sensible mechanism to simply change the size in PG. But yesterday, Tom Lane himself suggested something ubercool in the list.
Let's assume for the sake of simplicity that your table is called "TABLE1" and your column is "COL1". You can find the size of your "COL1" column by issuing the following query on the system tables:
SELECT atttypmod FROM pg_attribute WHERE attrelid = 'TABLE1'::regclass AND attname = 'COL1'; atttypmod ----------- 24 (1 ROW)
This means that the size is 20 (4 is added for legacy reasons, we're told). You can now conveniently change this to a varchar(35) size by issuing this command:
UPDATE pg_attribute SET atttypmod = 35+4 WHERE attrelid = 'TABLE1'::regclass AND attname = 'COL1'; UPDATE 1
Note that I manually added the 4 to the desired size of 35..again, for some legacy reasons inside PG. Done. That's it. Should we check?
d TABLE1 TABLE "public.TABLE1" COLUMN | TYPE | Modifiers --------+-----------------------+----------- COL1 | CHARACTER VARYING(35) |
Such a simple yet effective trick. Of course it'd be nicer if this is somehow included in a more proper way in the database, but this does the job.
Read More
RECENT COMMENTS