I am using JUnit4.9.zip. I downloaded it from https://github.com/KentBeck/junit/downloads. I am also using IntelliJ 10.5 as my text editor. I am having a problem getting the assertThat method to work with the greaterThan function. Basically I just want to make sure that the int result that I am getting from a method is not negative.
Here is the problem: IntelliJ can't seem to locate the greaterThan function that is used by JUnit. What am I missing/doing wrong? What do I need to get this to work.
Check what JUnit libraries you have in the module dependencies, most likely there is also an old version that appears first in the classpath.
Related
A little configuration information to start:
Xcode 13
Qt 5.15.5
iOS 14.7.1 (18G82) (I'm running on a device, not a
simulator)
Host MacOS Big Sur 11.6
I'm debugging a large Qt app, all written in C++, except for the necessary few files to make it work in iOS (so it's really an Objective-C++ app with an enormous amount of native C++ linked to it, everything of Qt it needs). I have a break point within the LoadApplication method - Qt has been built from source for development (that is, in debug configuration with symbols). There are a number of native Qt QUrl objects whose values I'd like to inspect. I have successfully installed lldbbridge.py, but I think the problem may be unrelated to that, because I saw it when I was using other tricks to see the data without the bridge. There is a method called toString on the QUrl class that produces a text representation of the URL (and another called toDisplayString that may be more human readable). These methods produce (of course) QString objects. So here are the failure modes:
First the bridge should be helping me to inspect the QUrl and all I see are the raw object descriptions that hide all the private interfaces. It isn't.
before I installed the lldbbridge.py script, I was able to view some of these objects (local variables, but not parameters), using code like expr url.toString().toStdString().c_str(). It still might work on local variables, but I would really like to be able to inspect parameters as well.
the error feedback I get is
error: <lldb wrapper prefix>:21198:9: module 'std' not found
#import std;
~~~~~~~^~~
this is a pretty legit error, because I have scoured my system and the internet for evidence of this std.framework whose existence is implied, and cannot find it, though its name suggests that it would be an assist to Objective-C or Swift to deal with std::string and the like. Possibly it was a thing in Xcode 12 that has been dropped in Xcode 13, but if so, it has no footprint on the web that I can find. Still, presumably Qt 5.15.5's lldbbridge.py was compiled and run and against it at some point in the recent past.
this isn't the only trick that doesn't work when inspecting a QString, with or without the bridge. I also tried expr (const wchar_t*)url.toString().toUtf16() and expr (const char*)url.toString().toUtf8() and so forth. The same error feedback results, complaining about the mysterious "std" framework or module.
and don't get too hung up on QUrl objects, because I get the same result with other QStrings.
one more symptom: if I do an expr #import std; in the lldb command line, it appears to work. That is, it gives no error feedback and appears to complete. This just makes the world weirder, because if exists, it must be hiding somewhere inside Xcode's contents, but I've done file searches in there, and see no evidence of such a thing. And if it does exist, why is the lldb wrapper prefix giving me grief? Could the wrapper be underspecified in terms of framework search paths, but the lldb command line not?
So as if it's not too obvious, here are my questions (besides WTF???):
Am I the first to see this? I've seen some forum talk about string inspection no longer working for others in Xcode 13 lldb, but the specific failure mode is different. Anyone else see this?
Does anyone have any idea about this mysterious "std" framework or module? Could its functionality have been sucked up into some other module or framework for Xcode 13?
Any ideas about work-arounds that I haven't thought of? I'm not a complete lldb novice, but I'm not an expert either.
I'd like to turn up the log levels look at those for clues, but I've never used that feature before, and I don't really even know where to FIND the logs.
I notice that the feedback suggests that there are at least 21198 lines in this "wrapper" BEFORE we get to the failing import statement. Seems a little excessive to wrap a request to view the contents of a string. Perhaps the whole wrapper is corrupted in some way. Any thoughts on how to test that hypothesis? How about a way to inspect the contents of the wrapper prefix itself?
Could the #import std; be a red herring and just co-lateral damage in some other unrelated failure mode? It's tempting to imagine it's some kind of std library support thing, but I don't want to assume too much at this point.
one more things about "std", whatever it is - lldb is super dynamic. It's always compiling inline code on-the-fly to support its functionality. That's the whole llvm magic. Is it possible it exists only as some inline text within lldb's source? And again, if so, why is it only selectively available?
Well, that's my nightmare. Unless my setup is horribly corrupted in some way and it's my unique curse, I'm sure this problem will show up for others, so cogent answers will make you a hero. Any pointers are appreciated. Thanks.
I try to run a cppcheck analysis over my code, which has the following file structure:
/code/module_1/src/a.cpp
/code/module_1/src/b.cpp
/code/module_1/test/c.cpp
/code/module_2/src/d.cpp
/code/module_2/src/e.cpp
/code/module_3/test/f.cpp
I'd like to run an analysis excluding all test code. Is this possible with a command like "cppcheck -itest"? It doesn't work for me, although I think it should, according to the docs:
...Directory name is matched to all parts of the path.
I'm using version 1.69. I know I could mention all test directories separately (which does work, I checked), but the number of modules is too high to do this for many analyses reasonably.
Is this possible?
I installed Cppcheck to do some tests and it seems the -i implementation is a bit bonkers. However, I managed to achieve what you want.
Solution: use -itest\ instead of -itest (this was in Windows; maybe Linux needs -itest/)
Rationale: in my tests, -itest worked only if there was a .\test\ directory, in which case even .\a\test\a.cpp was excluded. With -itest\, however, such exclusion took place regardless of the presence of .\test\ directory.
This seems like a bug which the developers ought to weed out, but, in the meantime, you can succeed using the above workaround.
This is a late response to an old question, but perhaps this will help other latecomers like myself.
Disclaimer: This answer is for Windows.
It seems as if v1.79 has remedied the OP's issue. The following command line syntax has worked for me:
cppcheck -itest code
In this example, "-itest" weeds out any occurrence of the "test" directory, as originally (and correctly) assumed by the OP. In addition, the code folder is found next to the cppcheck.exe. This will be the root of the recursive source-code scan.
I'd use something like:
cppcheck /code/module_1/src /code/module_2/src /code/module_3/src
I would like to embed NodeJS in my application. The reason i would like to use NodeJS and not just the V8 directly, is because of the extensions that exist for NodeJS.
To do that i understand that i need to compile NodeJS with GYP. Got it. But how do i work with it? is there a static lib to link to? how to start it up? say i want to provide it with a V8 context, how do i pass it?
a bit at a loss here. hope for help.
Note - i want to activate nodejs from my C++ code, not the other way around. i understand extensions, this is not what i want.
Regards,
Gal.
As I got from this question the problem of immediate linking with node.js is still unsolved. Actually the workaround may be running it in a separated process like an ordinary command line application. You may save your script to file, pass it as cmdline argument, then obtain std output from the node.js executable.
im trying out raphael js examples from http://www.irunmywebsite.com/raphael/additionalhelp.php#pagetop.
i took the example of animateAlong and tried, but im getting an error of animateAlong function is not defined.
Also made sure that my code is inside window.onload. My Raphaël version 2.0.1
Thanks
It's been removed from Raphael2. See this link for a possible solution. (Haven't checked it out myself, so your mileage may vary...)
I have a Sitecore 6.2.0 (rev. 091012) installed and working perfectly, except one thing - every xsl rendering i have is failing to run, and the xsl error i get is "System.Exception: Could not resolve type name: Demo.Samples.XslHelper, MyDemo.....". I have no idead what this is and how to fix this - any suggestions?
My user controls are working without a glitch.
Try searching your web.config for "Demo.Samples.XslHelper", then you will properly find a xslExtension that Sitecore cant find, remove it.
It is probably declaring a namespace in the top, which in turn is registered to a demo DLL that you don't have.
Paste the XSL file here, if none of this makes any sense to you, and the source of the error should be straight forward to identify.