Difference between Rust compile modes [closed] - intellij-idea

Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I'm new to Rust.
As I used to code a lot in Jetbrains IDEs (of course with Ideavim), I decide to pick up a Jetbrains IDE for Rust too, be more specificly CLion(as I also have to write C++ sometimes). Here you can treat CLion like Intellij or Pycharm/Rubymine/Android-studio if you are not fammiliar with it, because afterall what really does the work is the Rust plugin powered by LLDB.
Today I encountered a very strange thing:
I have wrote a library in C, which works fine in a C++ project. In my new Rust project, I want to keep using it, as a dynamic library. It compiles well, but it behaves strange, like, sometimes the logging to std does not work, the file operation does not work, and something more.
After some more investigation, I found out my test cases will:
Fail if I run through CLion/Intellij Run selected configuration
Fail if I run through CLI cargo test -- --nocapture
Pass if I run through CLI cargo test --release -- --nocapture
Pass if I run through CLion/Intellij Debug selected configuration
Here Intellij Debug behaves like cargo --release, Run behaves like cargo(without --release), have no idea why.
You may suspect that that's because I wrote some build-type-depending codes, but at least it's not true in the Rust part. As to the C library, it already been compiled, I do not think different rust compile types will change something inside it.
I checked the Rust configuration in CLion, found no items concerns to build mode.
OK, that's the context, and here comes my questions:
What's the difference between Intellij Run selected configuration/Debug selected configuration for Rust by default
Why Intellij Debug/Run behaves opposing to cargo --release/cargo
What may cause the different behaving between compile mode while I have no mode-depending codes in Rust.(no third party crates here)

For those who encountered similar problems, well not only in Rust, but also other programming langues, I found the reason for the different behaivors:
Dynamic library mess
I name it like this, not sure if it is correct, but to describe that multiple versions of the same dynamic library lay in your computers different paths may cause strange problems like I've encountered.
If you are in a situation like this, use ldd to check the library dependancies.
And also, remember to cleanup all the caches.

Related

How do you get Haskell to check SQL at compile time?

I know it can be done, but I'm having trouble getting it working. I'm still finding my feet with Haskell.
I tried using postgresql-typed, but it wouldn't compile. They don't enable the QuasiQuotes extension, so I don't understand how their code would ever compile. It also fails with an error on the useTPGDatabase statement. I cloned the library's source code from Github, but their tests failed to compile using stack with exactly the same errors.
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket.". I considered switching to nix but that seems like even more effort.
Does somebody have a reliable recipe for getting an environment working that type-checks SQL at compile time in Haskell?
I considered using hasql-th, but it's not on stackage.org, which immediately puts it in the "too hard basket."
All you need to do is add the latest version of hasql-th to the extra-deps section of your stack.yaml file and all other deps that Stack will suggest to you when you build.
In the end your stack.yaml file should look something like this:
resolver: lts-17.9
extra-deps:
- hasql-th-0.4.0.8
- headed-megaparsec-0.1.0.4
- postgresql-syntax-0.3.0.3
Anticipating a question in the spirit of "Why is it not listed on Stackage?" It's just that nobody has gotten to list these packages yet.

Generate Lint targets using cmake (Flexelint/Linux)

I am working on a C/C++ product that only builds in the Linux environment. It is a massive code base and generating lint targets manually is going to be incredibly painful. I know that you can link Lint into cmake so cmake generates these targets for you while it builds the code. Cmake has a macro called add_pc_lint (https://cmake.org/Wiki/PC-Lint) which does this for you. I wanted to know if there is something similar that could be used for Flexelint?
I currently have a PC-Lint license and wanted to ask this question before spending $998 on a Flexelint license. Thanks!
FlexeLint and PC-lint share the same manual so I'm pretty sure they are fully compatible on the command line. You should be able to use the same make files for both, or with minor changes. Otherwise they do offer a 30-day money-back guarantee.
Another option might be to run PC-lint under Wine. I tried this once and I got it working, but then I never used it much so I'm not sure how well it worked.
So I did get a FlexeLint license yesterday and now I am trying to integrate it into my CMakeLists. I am looking at the source code of cmake's add_pc_lint function and trying to modify it to work for FlexeLint. If anyone has played around with it before, please comment. The FlexeLint manual is not at all helpful.

In the playground, how to turn off debug mode?

I wanted to disable debug mode in Xcode 6 playground, but can't find how to do it. Is it possible at all?
Well, I wasn't able to find any official sources for what I'm writing now; but how should playground be able to work without debugging?
Playground doesn't simply execute your application and then shows your results nor does it execute your application step by step.
Xcode uses JIT compiling (just-in-time; Swift needs to be compiled) for your code (and every change you do) and then executes your binary and shows some information about your code which it considers useful.
So what it does is debugging your code but without the necessity for you to set breakpoints and check the state of your vars or return values on your own.
So you could consider it as some kind of real-time-debugging.
At least this is how I understood how things are going.

grunt lesslint how to prevent output from being written to console

We are trying to use grunt-lesslint in our project, as our UI developer is comfortable fix errors in less file. grunt-recess seems more powerful but not sure if it can point errors in less file itself. I am unable to comprehend enough from lesslint page, and there do not seem to be many examples. Does anyone know the following:
How to prevent lesslint from displaying on the console. I use formatters and the report file is generated, but it also prints on console, which I do not want to.
How to make lesslint fail only in the case of errors (not warnings). Also csslint seems to report errors also, while lesslint mostly gives warnings only, why is that so? Does lesslint throw errors as well? How to make it fail only in case of errors?
I tried using 'checkstyle-xml' formatter, but it does not seem to use it (I have used in jshint and it gives a properly formatted xml, which it does not give for lesslint).
Is it possible to compile less (many files or directories) in conjunction with lesslint? Any example?
Thanks,
Paddy
I'd say it's more of a common practice to display stdout for this kind of thing; the JSHint plugin does it, as does any other linting plugin that I've used. If you get in another developer that uses Grunt they'll probably expect stdout too. If you really want to override this, use grunt-verbosity: https://npmjs.org/package/grunt-verbosity
Again, this is a convention in Grunt; if a task has any warnings then it fails. The reason being if you lint a file and the linter flags something up it should be dealt with straight away, rather than delay it; six months time you have 500 errors that you haven't fixed and you're less likely to fix them then. Most linting plugins allow you to specify custom options (I've used CSS Lint and that is very customisable), so if you don't like a rule you can always disable it.
This should work. If there's a bug with this feature you should report it on the issue tracker, where it will be noticed by the developers of the plugin. https://github.com/kevinsawicki/grunt-lesslint/issues
Yes. You can set up a custom task that runs both your linter and compile in one step: something like grunt.registerTask('buildless', 'Lint and compile LESS files.', ['lesslint', 'less']); note that you'll have to install https://github.com/gruntjs/grunt-contrib-less to get that to work. Also note that, failing linting will not compile your LESS files; mandate that your code always passes the lint check; you'll help everyone involved in the project.

Workaround for enoent error from Erlang's Common Test on Windows?

When using Common Test with Erlang on Windows, I run into a lot of bugs with Common Test and Erlang. For one, if there are any spaces in the project's path, Common Test often fails outright. To workaround this, I moved the project to a path with no spaces (but I really wish the devs would fix the libraries so they work better on Windows). Now, I got Common Test to mostly run, except it won't print out the HTML report at the end. This is the error I get after the tests run:
Testing myapp.ebin: EXIT, reason {
{badmatch,{error,enoent}},
[{test_server_ctrl,start_minor_log_file1,4,
[{file,"test_server_ctrl.erl"},{line,1959}]},
{test_server_ctrl,run_test_case1,11,
[{file,"test_server_ctrl.erl"},{line,3761}]},
{test_server_ctrl,run_test_cases_loop,5,
[{file,"test_server_ctrl.erl"},{line,3032}]},
{test_server_ctrl,run_test_cases,3,
[{file,"test_server_ctrl.erl"},{line,2294}]},
{test_server_ctrl,ts_tc,3,
[{file,"test_server_ctrl.erl"},{line,1434}]},
{test_server_ctrl,init_tester,9,
[{file,"test_server_ctrl.erl"},
{line,1401}]}]}
This happened in sometimes in Erlang R15 and older if the test function names were either too long or had too many underscores in the name (which I suspect is also a bug) or when too many tests failed (which means Common Test is useless to me for TDD). But now it happens on every ct:run from Common Test in R15B01. Does anyone know how I can workaround this? Has anyone had any success with TDD and Common Test on Windows?
Given the last comment you might want to disable the buildin_hooks. You can do this by passing the following to ct:run/1 or ct_run
{enable_builtin_hooks,false}
That should disable the cth_log_redirect hook and maybe solve your problem during overload.