I can see from various documentations that XCloseDisplay returns an integer, which I suspect to be an error code.
What should I do with this value? Is it an error code? If so how do I handle the error?
I looked in the source code (lib/X11/ClDisplay.c)
It says:
return 0;
So there's nothing you can really do with the return value.
Related
Given this code:
expect(exit_code).to eq(0), result
I understand what expect(exit_code).to eq(0) is supposed to do, but I don't understand what the comma or result variable are doing. Could someone shed some light on that for me?
It's not so common, but to method can accept an additional argument, which is a message displayed, when the example is failed. Have a look at the source code.
Thus, a custom message can be provided with extra information, how to handle the failed spec:
expect(exit_code).to(eq(0), "spec failed, because exit_code is 0, please handle it")
The second argument, can be also a proc:
expect(exit_code).to(eq(0), -> { "expected zero, got: #{exit_code}" })
Following #Stefan's comment, here's the documentation about customizing failure messages.
In the Hack language type system, is there a "top" type, also known as an "any" type, or a universal "Object" type? That is, a type which all types are subclasses of?
The manual mentions "mixed" types, which might be similar, but are not really explained. There is also the possibility of simply omitting the type declaration in some places. However, this cannot be done everywhere, e.g. if I want to declare something to be a function from string to the top type, it's not clear how I do this. function (string): mixed?
I'm an engineer working on Hack at Facebook. This is a really insightful and interesting question. Depending on what exactly you're getting at, Hack has a couple different variations of this.
First, let's talk about mixed. It's the supertype of everything. For example, this typechecks:
<?hh // strict
function f(): mixed {
return 42;
}
But since it's the supertype of everything, you can't do much with a mixed value until you case analyze on what it actually is, via is_int, instanceof, etc. Here's an example of how you'd have to use the result of f():
<?hh // strict
function g(): int {
$x = f();
if (is_int($x)) {
return $x;
} else {
return 0;
}
}
The "missing annotation" type ("any") is somewhat different than this. Whereas mixed is the supertype of everything, "any" unifies with everything -- it's both the supertype and subtype of everything. This means that if you leave off an annotation, we'll assume you know what you're doing and just let it pass. For example, the following code typechecks as written:
<?hh
// No "strict" since we are omitting annotations
function f2() {
return 42;
}
function g2(): string {
return f2();
}
This clearly isn't sound -- we just broke the type system and will cause a runtime type error if we execute the above code -- but it's admitted in partial mode in order to ease conversion. Strict requires that you annotate everything, and so you can't get a value of type "any" in order to break the type system in this way if all of your code is in strict. Consider how you'd have to annotate the code above in strict mode: either f2 would have to return int and that would be a straight-up type error ("string is not compatible with int"), or f2 would have to return mixed and that would be a type error as written ("string is not compatible with mixed") until you did a case analysis with is_int etc as I did in my earlier example.
Hope this clears things up -- if you want clarification let me know in the comments and I'll edit. And if you have other questions that aren't strict clarifications of this, continue tagging them "hacklang" and we'll make sure they get responded to!
Finally: if you wouldn't mind, could you press the "file a documentation bug" on the docs pages that were confusing or unclear, or could in any way be improved? We ideally want docs.hhvm.com to be a one-stop place for stuff like this, but there are definitely holes in the docs that we're hoping smart, enthusiastic folks like yourself will help point out. (i.e., I thought this stuff was explained well in the docs, but since you are confused that is clearly not the case, and we'd really appreciate a bug report detailing where you got lost.)
This one is making me a little crazy and I hope someone can help.
I added a wait(45) line to my QTP script and when it runs I get a type mismatch error.
I know this will occur if a function can't be called or I misspell something to be called or etc.
But, this is a simple WAIT statement. Nothing else on the line.
Line: 152
Char: 6
Error: Type mismatch: 'Wait'
Code 800A000D
Any ideas? Did I miss something? How can there be a type mismatch on Wait?
There definitely is no Wait() sub or function in VBScript; as this question indicates, this holds for QTP too.
As to the error: a missing sub/function throws a type mismatch:
>> nosuchsub
>>
Error Number: 13
Error Description: Type mismatch
(If this consoles you, I don't like it neither.)
Actual error is not in Wait function. QTP shows type mismatch error due to compilation error in previous lines. Check all your library files are properly added. Best method to find the root cause of problems like this is to divide your code into smaller functions / procedures and test each function.
Could some explain it.
This didn't helped me:
http://www.khronos.org/opengles/documentation/opengles1_0/html/glEnable.html
As long as no valid GL enum has an actual value of 0 (which I really doubt), this will result in a GL_INVALID_ENUM error and otherwise do nothing.
I encounter an error in the code below.
recursive_mutex m_RecurMutex;
condition_variable cond;
unique_lock<recursive_mutex> lock(m_RecurMutex);
cond.wait(lock); // Error Here.
What is the reason causing this error?
You should use condition_variable_any instead, the semantics of this version is the same, but it allows all kinds of lock types. The regular condition_variable is however said to be potentially faster.
I assume the error is
mutex.cc: In function ‘int main()’:
mutex.cc:9: error: no matching function for call to ‘boost::condition_variable::wait(boost::unique_lock<boost::recursive_mutex>&)’
/opt/local/include/boost/thread/pthread/condition_variable.hpp:17: note: candidates are: void boost::condition_variable::wait(boost::unique_lock<boost::mutex>&)
i
if not, please correct me. The documentation shows boost::condition_variable::lock takes a boost::unique_lock<boost::mutex> as an argument, not a boost::unique_lock<boost::recursive_mutex> as in your example.