I get that same error. I downloaded and compiled the new wine but when I ran it I got this junk.
I also have my windows font dir on my font path.
X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 45 (X_OpenFont) Serial number of failed request: 81 Current serial number in output stream: 82 err:win32:EnterCriticalSection Critical section 0x836fa2c wait timed out, retrying (60 sec) err:win32:EnterCriticalSection Critical section 0x836fa2c wait failed err=102 X Error of failed request: BadFont (invalid Font parameter) Major opcode of failed request: 47 (X_QueryFont) Resource id in failed request: 0x3400015 Serial number of failed request: 82 Current serial number in output stream: 83
Ok, since everyone is talking about all the things that could happen with the SCSL, I thought it might be a good time to tell you all a real problem with the current Java API and how Sun interacts with developers. I have been trying to get Sun to fix the Runtime.exec() API for more than a year. If you are a Java developer, you probally already know what I am talking about. The exec() method does not provide a useful way to set env vars or to exec() a process with a current directory other than the one the JVM was started in.
If you are a JDC member you can read all about it at this URL. (Sorry, if you can not view this URL, but Sun will not let people look at Java bug reports without joining the JDC and agreeing to a license).
I submitted this bug report on July 10, 1998 and it was not "reviewed" until June 28, 1999. It was then shelved for another 3 months when they decided to "fix" the problem. Now comes the tricky part. There is no real information about how they intend to "fix" this bug, and the reviewer mentions that they are not even going to fix "all" of the problems with this API, just the current directory problem. So I still have no real feedback and I will have to wait until the new release of the JDK to see how they decided to "fix" this bug. There is something really wrong here. This kind of crap would never happen on a real Open Source project.
Cheaper would be nice, but what about service? NSI sucks. I have been trying to get them to change the nameserver for my domain for a couple of weeks. My emails have been sent to the "automatic" update system over there, but nothing happens. Is there any other way to get a domain registered?
I kid you not, I read on a MS page that NT 5.0 (aka Win2000) would reduce the need for "administrative reboots". Now that is a great term if I ever head one.
Did anyone else see the Trod's page where he talks about these groundless patent threats? Check it out at http://home8.swipnet.se/~w-82625. In that page Tord says that these legal issues will cost him around 1,000 dollars (I assume he means U.S. dollars). I use bladeenc all the time and I would like to help Tord defend himself on the legal front. I would be willing to put up the first 100 dollars for a "bladeenc legal defense fund". Who here is with me?
Slashdot Mirror
I get that same error. I downloaded and compiled
the new wine but when I ran it I got this junk.
I also have my windows font dir on my font path.
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 45 (X_OpenFont)
Serial number of failed request: 81
Current serial number in output stream: 82
err:win32:EnterCriticalSection Critical section 0x836fa2c wait timed out, retrying (60 sec)
err:win32:EnterCriticalSection Critical section 0x836fa2c wait failed err=102
X Error of failed request: BadFont (invalid Font parameter)
Major opcode of failed request: 47 (X_QueryFont)
Resource id in failed request: 0x3400015
Serial number of failed request: 82
Current serial number in output stream: 83
Ok, since everyone is talking about all the
d e/bugs/4156278.html
things that could happen with the SCSL, I
thought it might be a good time to tell you
all a real problem with the current Java API
and how Sun interacts with developers.
I have been trying to get Sun to fix the
Runtime.exec() API for more than a year.
If you are a Java developer, you probally
already know what I am talking about. The
exec() method does not provide a useful
way to set env vars or to exec() a process
with a current directory other than the one
the JVM was started in.
If you are a JDC member you can read all
about it at this URL. (Sorry, if you
can not view this URL, but Sun will not
let people look at Java bug reports without
joining the JDC and agreeing to a license).
http://developer.java.sun.com/developer/bugPara
I submitted this bug report on July 10, 1998
and it was not "reviewed" until June 28, 1999.
It was then shelved for another 3 months when
they decided to "fix" the problem. Now comes
the tricky part. There is no real information
about how they intend to "fix" this bug, and
the reviewer mentions that they are not even
going to fix "all" of the problems with this
API, just the current directory problem. So
I still have no real feedback and I will have
to wait until the new release of the JDK to
see how they decided to "fix" this bug. There
is something really wrong here. This
kind of crap would never happen on a real
Open Source project.
Mo DeJong
Cheaper would be nice, but what about service? NSI
sucks. I have been trying to get them to change
the nameserver for my domain for a couple of weeks.
My emails have been sent to the "automatic"
update system over there, but nothing happens.
Is there any other way to get a domain registered?
I kid you not, I read on a MS page that NT
5.0 (aka Win2000) would reduce the need for
"administrative reboots". Now that is a great
term if I ever head one.
Mo
Did anyone else see the Trod's page where he talks
about these groundless patent threats? Check it
out at http://home8.swipnet.se/~w-82625. In that
page Tord says that these legal issues will cost
him around 1,000 dollars (I assume he means U.S.
dollars). I use bladeenc all the time and I
would like to help Tord defend himself on the
legal front. I would be willing to put up the
first 100 dollars for a "bladeenc legal defense fund". Who here is with me?
Mo DeJong
dejong@cs.umn.edu