I am following the Rust docs hello world program section, and I have it made and saved. Now it asks me to compile it by using the command line. However, it doesn't say where to start the command line from, or how to enable rustc command. I am hoping someone actually can answer this question, as I did not find much on the topic.
I fixed the issue. For anyone who is wondering, if you are on Windows you just have to add the Rust bin file to the path. You can go to:
Control Panels > System and Security > System > Advanced System Settings > Environment Variables. Then, scroll down to Path, and click edit. Add the path to the Rust/bin folder. I actually did this one time before I asked this question, but it was removed for some reason. Adding it backed worked for me.
Related
I have followed the instructions for updating my GDB for use with Eigen3. However, the CLion IDE is unable to load the contents of eigen matrices in the debug panel.
What should be a quick validation and debug process of results is turning into a time consuming manual print process (or worse: running gdb in interactive mode in cygwin's terminal).
There must be a way to enable eigen to be used with clion's debugger?
There is quite a simple way #Chris and anyone else looking for a solution using GDB, CLion, I tested it on ubuntu but it should work on any system.
Part of the solution is already in the eigen repository, just needs a bit of tweaking.
Eigen printers
What I changed is the python module import logic:
Save printers.py to a newly created printers directory under any directory of your choosing, lets say /any_full_path/printers
make sure you create and empty __init__.py
Create a ~/.gdbinit in your home directory
Copy paste the slightly changed(from the original repo) script below
python
import sys
sys.path.insert(0, '/any_full_path/printers')
from printers import register_eigen_printers
register_eigen_printers(None)
end
Feel free to ask for more screenshots or other clarification, caus that should work simply like a charm.
I've managed to make lldb work in CLion using this project on windows: https://github.com/fantaosha/LLDB-Eigen-Pretty-Printer
You need to create .lldbinit in your home directory and add similar line:
command script import "C:\Users\user.lldb-eigen-data-formatter\LLDB_Eigen_Pretty_Printer.py" (ofc this folder and file needs to be cloned as per the readme on github)
Now Clion will import this script bit you will get some errors, you need to remove the question mark in the regular expressions as described here:
https://github.com/fantaosha/LLDB-Eigen-Pretty-Printer/issues/4#issuecomment-747329527
Now CLion will be able to show you the matrix, vector etc. values (but without newline - at least on windows).
For gdb specifically it should be what uta answered but I haven't tried it because I'm using lldb. Maybe you can try changing the debugger to lldb if you don't use anything specific related to that.
Hope this helps in some way!
I am writing an app using applescriptobjc in xcode, and while making the archive I see the source code is still inside the package, is there a way to hide it or transform it completely to binary code?
Thanks
I may be a year late to the discussion but I asked the same question around the same time as you did last year and hope that the answer I got will satisfy your own question. Here is an extract answer from
my own question:
When you save the AppleScript file you have the option of checking "Run Only" - in that case the script is compiled into a new form that can be run exactly as the original script, but it is not meant for further editing/development.
It doesn't mean that the run-only file is complete protected or non-readable, but parts of your code, comments, etc. are not included or not easily readable.
If you want to do more you'll need a code obfuscator if you still want to use AppleScript - however I'm not sure if one exists on the market, or you need to develop your own.
As you can see, a simple way to do this is:
Open your final AppDelegate.applescript file in Script Editor on the mac.
Select: File > Export...
2.1. Don't change the file name but override the archive file
2.2. BEFORE SAVING: Choose Run-only checkbox from the save options but leave the File Format as Script
Now your file cannot be opened in plain text as it is set to Run-only. Please remember that it is not a 100% read-proof solution, but works great for small projects (provided you are not rushing the final export and don't forget to perform the above mentioned steps before handing it over to the customer).
I hope you can make the most of this answer and still deem it useful. Let me know how you get on or whether you have any more questions. Perhaps you have since found a far better solution (or just an alternative), if so, I am still looking for the next best thing in source code protection.
In Xcode 9.2. (and maybe earlier versions) you can find under Build Settings the item OSACompile and can choose to compile to an executable only directly from Xcode.
C:\Users\redacted\Documents\redacted>gfortran hibrac.f -o hibrac.exe
'gfortran' is not recognized as an internal or external command,
operable program or batch file.
https://gcc.gnu.org/wiki/GFortranBinariesWindows seems similar to my problem: gfortran.exe is in C:\Windows\MinGW\bin -- except the solution appears not to apply to Windows 8.1 Pro:
Right click on My Computer, Properties, Advanced Tab, Environment Variables.
Instead I tried: Right click on 'This PC' within File Explorer, Properties, Advanced system settings, Advanced Tab -- and I cannot find an equivalent-looking section that allows me to proceed with the advised solution.
As background information:
I had installed MinGW Installation Manager which installed mingw32-gcc-fortran (together with mingw32-base, -gcc-g++, and -gcc-objc) in the recommended C:\Windows\MinGW folder, without any apparent error message.
Isn't it acceptable -- standard practice -- to have one's code in a folder separate from this MinGW folder? i.e. a subdirectory of my Users\account rather than a subdirectory of MinGW. This isn't the problem, is it? What do I need to do to get it to recognize the gfortran.exe, or call it correctly?
Please tell me what to do to get it working. If it's relevant, I have a Japanese computer with an English language pack installed (it seems to have some gaps, such as some text in the Settings charm or startup/shutdown text being in Japanese).
This looks very much like you have neglected to add C:\MinGW\bin to the effective PATH for the command window, in which you are attempting to run the gfortran command.
Your question isn't entirely specific on this point, (i.e. you could improve the question), but you hint that you were unable to add the appropriate PATH entry to the global environment variables, because you couldn't find the appropriate control panel applet? I know that this is often recommended as part of a MinGW setup, but the installer will not do it for you, because I, as the maintainer of mingw-get, don't consider that to be best practice; much better, IMO, to add it for each specific command window in which you need it to take effect, by running (once, at the start of each command prompt session) the command:
path %PATH%;C:\MinGW\bin
If you prefer, you may create a batch file to do this for you, along with any other initializations you wish to perform, (or better still, use MSYS as the working shell environment, in which case the PATH initialization is taken care of by the shell's own initialization scripts).
background info:
I know this question has been asked countless times, but I'm not understanding the answers.
Today is the first time I've ever done anything with python, so I'm a total noob.
I'm using windows 7.
python 3.3.5 lives here: C:\Python33\python.exe
I have a .py file I want to run saved here: C:\Users\Scydmarc\Documents\cs188\python_basics\myfile.py
If I simply double click on myfile.py, it opens, runs, and closes super fast. By doing a perfectly timed printscreen, I can see that it works. It is my understanding that I need to run the file from within python.exe to get the window to stay open and allow me to mess with variables etc after it runs. So I open python.exe. What exactly do I need to type to run myfile.py? I've found lots of people trying to do this, but I guess I'm not understanding the answers. When I try to follow along, I get tangled up with errors. Do you still need to put python before the file name while in the python.exe window? Do I somehow need to specify a full path to the file? Some are actually running from the windows command prompt and not the python command prompt. When trying to change PYTHONPATH, are you supposed to do that from inside python, or the windows command prompt? Some examples use '/', while some use '\'. So, I think a complete example (what to actually type, in what window, line by line, with real filepaths) would clarify a lot for me and be super helpful. I'm thinking if I can actually see it done once, I can figure out how to make it do what I want in the future. Thanks for any help you can give.
in your python dir type python.exe pathtofile.py or set python.exe to your classpath
edit: https://www.youtube.com/watch?v=IokKz-LZsEo
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).