'elp, my text disappeared
I've been trying to work with Dia, but noticing that the text it creates
is so small as to be unreadable, no matter what size the font is set at.
While Googling reveals that a change in the Pango library is at fault,
no answer is to be found... until now, hopefully. Switching over to the
Groups side of Google reveals that Dia 0.92.2 has taken
Pango's changes into account. I grabbed the SuSE-friendly rpm here.
Although it complains of a slight libxml version mismatch, the text is
indeed fixed.
[/code]
Syslog is weird
...or maybe it's Sys::Syslog, or VMware, or maybe it's me... Just made it through one of those situations where code works on one server but not the other, even though the two servers are, to the best of my abilities to verify, identical. In my development environment, the code I'm working on was able to write its log messages to syslog using perl's standard Sys::Syslog module. On the test server, the messages disappeared. I checked all the things I could think of - same perl versions, same syslogd versions, same syslog.conf file, same /etc/sysconfig/syslog file (this is SuSE). Just for fun I tried the code on the production server it will eventually live on - again, configured exactly the same as the other two - and it worked! So, definitely something about the test server, though that something remains elusive.
Stranger yet, if I run my code using a newer perl binary (5.8, as opposed to 5.6, which is being used in production), it works on the test server. So not only is there a hidden environment difference between the servers, but that difference is handled appropriately by newer perls, but not by the version I needed to test. A quick diff of Sys::Syslog between 5.6 and 5.8 shows that there were some changes made in the connection methods, but my belief that the syslog settings were the same in the test and dev environments prevented me from acting on that until my coworker pointed out that the connection to syslogd (be it via unix socket or TCP) seemed like the most likely place for a problem. So, out of other ideas, I added -r to the test machine's syslog config script. And it worked. Now, of course, the environment is definitely out of sync with the development and production environments...
Although I've been thinking that the environments must be the same since the relevant config files, code, and libraries are all the same, there is one difference: the test server is actually a VMware instance. While this shouldn't make a difference, there are also other things about being a VMware instance that shouldn't make differences, but do, so it doesn't seem totally impossible.
[/code]
Mon, 17 May 2004
...or maybe it's Sys::Syslog, or VMware, or maybe it's me... Just made it through one of those situations where code works on one server but not the other, even though the two servers are, to the best of my abilities to verify, identical. In my development environment, the code I'm working on was able to write its log messages to syslog using perl's standard Sys::Syslog module. On the test server, the messages disappeared. I checked all the things I could think of - same perl versions, same syslogd versions, same syslog.conf file, same /etc/sysconfig/syslog file (this is SuSE). Just for fun I tried the code on the production server it will eventually live on - again, configured exactly the same as the other two - and it worked! So, definitely something about the test server, though that something remains elusive.
Stranger yet, if I run my code using a newer perl binary (5.8, as opposed to 5.6, which is being used in production), it works on the test server. So not only is there a hidden environment difference between the servers, but that difference is handled appropriately by newer perls, but not by the version I needed to test. A quick diff of Sys::Syslog between 5.6 and 5.8 shows that there were some changes made in the connection methods, but my belief that the syslog settings were the same in the test and dev environments prevented me from acting on that until my coworker pointed out that the connection to syslogd (be it via unix socket or TCP) seemed like the most likely place for a problem. So, out of other ideas, I added -r to the test machine's syslog config script. And it worked. Now, of course, the environment is definitely out of sync with the development and production environments...
Although I've been thinking that the environments must be the same since the relevant config files, code, and libraries are all the same, there is one difference: the test server is actually a VMware instance. While this shouldn't make a difference, there are also other things about being a VMware instance that shouldn't make differences, but do, so it doesn't seem totally impossible.
[/code]
Happy Gay Marriage Day!
I hear from NPR that Massachusetts has just joined the Netherlands, Belgium, and two unspecified Canadian provinces as one of the only places on earth where gays can legally marry. Seems like good company, especially when you consider the human rights records of states who, on the other hand, are particularly bearish on gay rights - China and Egypt come to mind, though there obviously dozens of others.
While there are days when it seems like the Bay State is run by an uneasy alliance between the Catholics and Mormons, today is clearly not one of them.
[/general]
I hear from NPR that Massachusetts has just joined the Netherlands, Belgium, and two unspecified Canadian provinces as one of the only places on earth where gays can legally marry. Seems like good company, especially when you consider the human rights records of states who, on the other hand, are particularly bearish on gay rights - China and Egypt come to mind, though there obviously dozens of others.
While there are days when it seems like the Bay State is run by an uneasy alliance between the Catholics and Mormons, today is clearly not one of them.
[/general]
slag code: