Posted by stechert on April 12, 2015 at 02:33 PM in Decode | Permalink | Comments (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
If you use NewsFire to export OPML, you may run into some trouble because there are a few things wrong with the export. In particular, even though the XML header indicates that the character encoding is ISO-8859-1:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- Generated by NewsFire 67 --> <!-- http://www.NewsFireRSS.com/ --> <opml version="1.1"> ...
the file is, in fact, encoded as UTF-16 (or some other two byte encoding). You can see this in the output of od -a
on the OPML file:
0000000 ff fe < nul ? nul x nul m nul l nul sp nul v nul 0000020 e nul r nul s nul i nul o nul n nul = nul " nul 0000040 1 nul . nul 0 nul " nul sp nul e nul n nul c nul
The two characters "ff fe" are referred to as the BOM, or byte order mark, of the file. That's the first clue that this is a two byte encoding. Next, you'll see that every other character is a NUL. That's because UTF-16 keeps a NUL in the high byte for ASCII characters. Anyway, all of this doesn't mean much other than that this file is not, as previously indicated, ISO-8859-1, which is a one byte encoding. To fix it, make use of the lovely utility "iconv", which comes standard on most Unixes (and the Mac). "-f" means "from this encoding" and "-t" means "to this encoding".
stechert@kirin:~/Desktop [1040] $ iconv -f UTF-16 -t UTF-8 My\ NewsFire\ Feeds.opml > My\ NewsFire\ Feeds2.opml stechert@kirin:~/Desktop [1041] $ od -a My\ NewsFire\ Feeds2.opml 0000000 < ? x m l sp v e r s i o n = " 1 0000020 . 0 " sp e n c o d i n g = " I S 0000040 O - 8 8 5 9 - 1 " ? > nl < ! - -
Changing the indicated encoding to UTF-8 by replacing the string "ISO-8859-1" in the header with "UTF-8" gets us a properly encoded XML file.
Now the only remaining problem is that OPML requires a head element within the OPML tag, so go add that. The head of your file should now look like this:
<?xml version="1.0" encoding="UTF-8"?> <!-- Generated by NewsFire 67 --> <!-- http://www.NewsFireRSS.com/ --> <opml version="1.1"> <head/> <body> ...
Having come this far, your OPML file should now validate and you could, e.g., use it to upload a news filter to TailRank, if you wanted to give it a try (instead of getting error messages about how brokenly formatted your OPML is). It's annoying that David Watanabe gets this wrong. And it was a missed opportunity-to-impress that the burtonator's code didn't handle this kind of stuff automatically. But then again, neither does Google Reader or Bloglines.
Posted by stechert on August 12, 2006 at 01:54 AM in Decode | Permalink | Comments (1) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
When programming in Visual Studio, if you happen to run across this error while trying to compile C code, one thing to check on is whether or not you're declaring your local variables inline. For whatever reason, Visual Studio hates this and issues a syntax error for the next line of code. One that's of no use whatsoever in helping to figure out what to do.
So, for example, if you have a function like:
int foo(int x)
{
assert(x != 0);
int y = 4/x;
return y;
}
You would need to rewrite your code like this:
int foo(int x)
{
int y;
assert(x != 0);
y = x/4;
return y;
}
Strange but true. I suspect there's an option somewhere to turn off the strictness of the compiler, but I haven't found it.
Posted by stechert on January 16, 2006 at 11:47 PM in Decode | Permalink | Comments (5) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
If you're running Mac OS X 10.4 and you're seeing the processes mds
and LAServer
taking all of your CPU, it's probably because you're putting a lot of new data onto your disk somehow. Spotlight is indexing -- LAServer is the language analysis server, mds is, I think, the "metadata server". More grokkage if you man mdcheckschema, mdfind, mdutil, or mdimport.
If you don't want the new files indexed, go to System Preferences, Spotlight, and add the folder(s) that you don't want indexed in the Privacy tab. The UI there is a little sketchy in that it adds the file asynchronously -- good from a UI responsiveness perspective, but the final implementation leaves you wondering whether or not the folder actually got added.
Posted by stechert on January 09, 2006 at 08:35 PM in Decode | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
(Prelude: If you're getting this error message, some program other than the Mac OS X firewall control panel has created firewall rules using ipfw. You can check whether or not this is occurring by issuing the command
sudo ipfw list
in the terminal. If you're sure that you don't want the firewall rules shown, then
sudo ipfw flush
and delete /Library/Preferences/com.apple.sharing.firewall.plist. This should reset your firewall settings.)
Finally had time today to run down some really irritating behavior that had shown up in Mac OS X lately - whenever the Powerbook went to sleep, it would forget and then never reacquire the DHCP configuration it got from the network. Reboot and the problem would be solved, but who wants to reboot every time you wake up your laptop?!
Hunted around and found that the most common cause for this is a firewall getting in the way of the DHCP interaction. Trouble is, I've never installed firewall software beyond Apple's built in stuff. Head over to System Preferences, sharing, firewall to check it out and got the dialog "Other Firewall Software is Running on your Computer". What the heck is this? "sudo ipfw list" shows that TCP ports 990, 999, 5678, and 5679 all have special rules associated with them. Huh, I didn't do that. Turns out those ports are for ActiveSync.
Then I remembered PocketMac. I bought a great new cellphone (Audiovox SMT 5600) a little while ago which rocks except that, because it's based on Mobile Windows, it needs software that can synchronize with the Mac's contacts, calendaring, etc. So I bought PocketMac, fiddled with it to get Bluetooth syncing working and never looked back. Only problem is that the software installs firewall rules for you that f*** up DHCP. Went to system settings, accounts, login items and deleted PocketMacStatus.app from the list of startup items. Reboot, sleep, wakeup, no worries. *sigh*.
Posted by stechert on December 28, 2005 at 01:02 AM in Decode | Permalink | Comments (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
The Scenario: You're porting your multithreaded software that works great on all kernel versions of Linux, FreeBSD, etc., but when you try to run on Solaris, at a repeatable point in the program, the process just exits with the error message "aborted". Even when you step through the code in gdb, the program exits unexpectedly. You might see something about a SIGALARM.
What's going on: Solaris, unfortunately, uses SIGALARM for both (a) coordinating among multiple threads in a multithreaded application and (b) the usleep() function in libc. So, if you ever call usleep() in a multithreaded app on Solaris (on 2.8 at least), then when the call returns, your program will abend as described above. Since it's going to be a lot harder getting rid of the multithreaded-ness of your application, I'd recommend that you just don't use usleep(). Or maybe conditionally define it away on Solaris.
Posted by stechert on August 19, 2005 at 11:28 PM in Decode | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
The Quick Answer
In your prototype file (i.e., the thing created by pkgproto), look for a repeated filename, probably pkginfo.
More Detail
Yet another error message without a good answer out there so I'm adding it to my decode list.
If you get this error message, you might have, like me, been using the instructions at http://www.sunfreeware.com/pkgadd.html.
If so, the first time you ran through the instructions, everything probably worked great, but the second time, the recipe failed.
What happened? In the instructions, you create a file called prototype with this command:
find . | pkgproto > prototype
The first time you ran it, everything was fine and then you added the line:
i pkginfo=./pkginfo
to the top of the prototype file. The second time, however, because the pkginfo file existed when you ran the find, it ended up in the prototype file even before you edited it. Then, when you added the i pkginfo=./pkginfo line, you created a second entry for pkginfo in the prototype file.
Get rid of the entry that was added by the find command.
Technorati Tags: Solaris
Posted by stechert on August 05, 2005 at 06:46 PM in Decode | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
Another decode entry because the search engines had no results. If you are building some libraries that use boost, and the resulting library has some unresolved symbols (leading to segmentation fault or abort), and those unresolved symbols are these:
Then what's happened is that your build is referencing different versions of the boost when (a) including header files and (b) linking libraries. These symbols mean, in particular, that this is happening for the boost regex library. This is often caused by including something like "-I/usr/local/include" in your CPPFLAGS but forgetting the boost-specific include path "-I/usr/local/include/boost-1_32" or whereever your boost happens to be installed.
Technorati Tags: Boost
Posted by stechert on August 04, 2005 at 02:26 AM in Decode | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
Bumped into this error message while building custom glibcs. Google results were mostly folks expressing confusion, so I thought I'd post as a decode.
What's going on here is that ldd, which is a bash script, is invoking the glibc dynamic loader for you with its --verify option. The ld-linux.so.2 thing? That's the dynamic loader. Yes, you can invoke it directly. Try it. And read the ldd bash script while you're at it. Anyway 139 = 128 + 11. When a command within a shell script gets signaled, its return value is 128 + the signal number. Signal number 11? SIGSEGV.
Probably what you want to do at this point is ulimit -c, invoke ld-linux.so.2 manually, and then use gdb to see what's causing it to fail. Good luck!
Posted by stechert on June 27, 2005 at 06:13 AM in Decode | Permalink | Comments (0) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |
I've created a new category called "decode" that's going to be the home of compiler (and other) detritus such as the python error:
TypeError: Error when calling the metaclass bases
For this one, the answer is that you probably named a python class the same thing as the module (i.e., the file) that it's in. You then imported the module and attempted to use it like a class. You did this because you, like me, were probably a Java programmer not that long ago :-). The way to fix it is to import the module.class instead of just the module. Or, for sanity's sake, change the name of the class or the module so that it's more obvious what's being imported.
I think we're all doing the world a favor by helping out the Oracle with a few hints when we run across these things and there isn't a good answer already documented.
Posted by stechert on March 30, 2005 at 05:01 AM in Decode | Permalink | Comments (6) | TrackBack (0)
Reblog
(0)
| | Digg This
| Save to del.icio.us
|
| |