I'd like to use the debugger in Juno. I have multiple files, say file1, file2 and file3, all stored in one directory, say directory1. However, when I try to run the debugger, it claims
ERROR: could not open file /directory2/file3.jl
How come it does not find my files? It runs just fine, without the debugger. Do I need to change some PATH variable (REPL?) or something to tell it where to look for files?
Are you're includeing those files? If so, that's a bug in Juno's debugger.
Until this is fixed, you can either
use absolute paths in your include statements, e.g. include("/foo/bar/baz.jl") instead of include("baz.jl")
or directly enter the function call (with e.g. Juno.#enter start() or the "Run Block" command).
I think my error came from the fact that I just opened the debugger panel, without entering the correct command in the Juno command line :
Juno.#enter start()
where start() is the function that starts my program. Now everything compiles and runs at least.
Related
I was using Pycharm as my editor to run the scripts since i need to add a task scheduler i had to test the code on the command prompt. Firstly this is the structure of my project.
When i try to run the following line
C:\Users\My_name\AppData\Local\Programs\Python\Python36-32\python.exe "C:\Users\My_name\PycharmProjects\FYP_CB006302\generateSummary.py"
I get this error,
From the knowledge i have i think it is because it doesn't recognize the path.
But when i change the directory to my project folder then give the path to python.exe and type generateSummary.py it works which was done as shown here.
However i highly doubt that this method can be used to task a schedule in Windows. Therefore, any ideas that would to run as shown in the beginning will be helpful.
The problem here is that when you use that line to run a particular script the folder which is causing the error is out of scope.
C:\Users\My_name\AppData\Local\Programs\Python\Python36-32\python.exe "C:\Users\My_name\PycharmProjects\FYP_CB006302\generateSummary.py"
In this case pickle_saves folder is out of scope. You can avoid this by giving a absolute path to that file in line 173. Where the absolute path is something like C:\user\documents\projects\pickle_saves\all_words
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
I've read this discussion but despite different attempts, I get an error (it varies depending on my approach).
The compilation itself works fine. Double-clicking on the "publish.bat" files executes it just fine too. It's the combo in VS10 that breaks.
This is what I've tested.
$(OutDir)\publish.bat
"$(OutDir)\publish.bat"
$(OutDir)publish.bat
"$(OutDir)publish.bat"
call $(OutDir)\publish.bat
call "$(OutDir)\publish.bat"
call $(OutDir)publish.bat
call "$(OutDir)publish.bat"
What am I missing?
I had a similar problem that I was just able to fix. For me the simple call "$(SolutionDir)\Setup\CreateInstaller.bat" worked, but I kept getting a The command "call {solution directory}\Setup\CreateInstaller.bat" exited with code {code}. Turns out my batch file was expecting to be run from the directory in which it lived. So, check that all the commands in the batch file are not using relative directories or commands as these may break.
Also, are you sure the $(OutDir) macro is what you want? In VS2010 at least, that is just equal to bin\Debug or bin\Release depending on which version you're building in. It seems unlikely that you really want that directory. I expect what you want is $(SolutionDir) or perhaps even $(TargetDir).
This is probably batch scripting 101, but I can't find any clear explanation/documentation on why this is happening or if my workaround is actually the solution. So basically any terminology or links to good sources is really appreciated.
So I have a program I want to execute via batch script (along with several other programs). It's the only one where the exe is not in a Program Files folder. I can get it to start like this:
C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
But I get an error along the lines of:
Run-time Error '3024':
Could not find file
C:\Users\MyUserName\Desktop\ModuleSettings.mdb
So it seems that the program is looking for its settings files from the same location that the batch script starts up. Given that I finally got everything to work by doing the following:
cd C:\WeirdProgram\WeirdProgramModule\
weirdmodule.exe
That works fine, and it's not the end of the world to have to go this route (just one extra line), but I've convinced myself that I'm doing something wrong based on lack of basic understanding.
Anybody know or can point me to why it works this way?
Oh, and doing the following:
start "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"
doesn't do anything at all.
Thanks,
you are doing it perfectly :-)
the executable is probably looking for this file in the "current working directory", which is being set, when you "cd" to it before.
you can set your working directory manually by creating a shortcut to your batch file; right click; properties.
edit:
you can also set your current working directory using the start command:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe"
edit:
If you like to pass params, just add them to the executable filename as you would in a regular shortcut:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe" "param1 param2"
or
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe param1 param2"
For reference, the syntax is described here: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true.
What's happening is that weirdmodule.exe is looking in the "current directory" for the .mdb file. You might be able to tell it where to find the .mdb file through a command line parameter or some other configuration method (registry or .ini file maybe). How you'd specify the location is entirely up to the weirdmodule.exe program, though.
Other than that, your current workaround is probably what you're stuck with.
As far as your problem with using start.exe... the start.exe program has the very, very odd behavior (bizarre behavior in my opinion) of treating the first parameter as the 'title' to put in the window if (and only if) the first parameter is in quotes. So you have a couple of options:
Don't use quotes to specify the program. This works for you because you don't need quotes (there aren't any spaces or other special characters in the path that would require quoting it):
start C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
Give an empty (or some other string) title as the first parameter. This is something you'd have to do if your path required quotes:
start "" "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?