I'm traying to execute this command:
/home/sumo-0.25.0/sumo/bin/netconvert --node-files=hello.nod.xml
--edge-files=hello.edg.xml --output-file=hello.net.xml
But I get this error:
Warning: Environment variable SUMO_HOME is not set, using built in type maps.
Error: Could not open nodes-file 'hello.nod.xml'.
Quitting (on error).
The first one is a warning only. If you want to get rid of it, do something like
export SUMO_HOME=/home/sumo-0.25.0/sumo/
in your shell. The second one is the real error. It indicates that the file in question is not accessible. Is the file hello.nod.xml in your current working directory and readable?
Related
I have a solution full of SSIS projects, and I'm trying to build a single one via command line. I know I need to use the devenv.com executable, and if I use devenv.com solution.sln /Rebuild it will process the whole set of projects. However, I cannot seem to get the additional parameters correct. When I try devenv.com solution.sln /Rebuild "Development" /Project "projname", I get an enigmatic The operation could not be completed. The parameter is incorrect. Which parameter? What should it be? I've tried replicating this answer's syntax, but I get the same error. How do I find out what parameter is incorrect? So far the closest I can get is to rename the .sln file so it can't be found and just specify the .dtproj file.
I'm trying to open a simple file open dialog in Tcl/Tk but whenever I run tk_getOpenFile I get the following error:
invalid command name "::tk::dialog::file::"
while executing
"::tk::dialog::file:: open {*}$args"
(procedure "tk_getOpenFile" line 5)
invoked from within
"tk_getOpenFile"
(procedure "open" line 2)
invoked from within
...
I'm running the latest version of Tcl/Tk, 8.6.9, from the Arch Linux repositories. What could be causing this?
It looks like a broken installation somehow. The procedure tk_getOpenFile in …/tk.tcl (where … is where Tk's library files are installed) delegates to the procedure ::tk::dialog::file:: in …/tkfbox.tcl (yes, an unusual procedure name), but that doesn't seem to be working in your case. Either the file is missing, or the tclIndex file in the same directory is broken. (That's using an old mechanism for auto-loading of code that doesn't really make sense for new code to use in… well, in this millennium. It's kept for backward compatibility.)
I have a C extension to Tcl where command mytest is defined. The extension is compiled correctly (I am on Linux, extension is *.so). For example, I can start tclsh and use it like this:
$ tclsh
% load /path/extension.so
% mytest abc
...
But, if I create a file myscript.tcl with the following content:
load /path/extension.so
mytest abc
then I get error:
$ tclsh myscript.tcl
invalid command name "mytest"
while executing
"mytest abc"
(file "myscript.tcl" line 2)
I am using bash on Ubuntu 14.04. Tcl 8.6.
EDIT 1: My question/problem is that I want to use tclsh with a script as an argument - this script should properly load extensions in such a way that mytest and other implemented functions are working without error.
EDIT 2: Uhh, If I use command "source myscript.tcl" inside tcl shell the result is the same. If I use absolute path for myscript.tcl the error is still the same --- "load" executes without warning but I am not sure about it because I get invalid command name "mytest". Maybe the problem is with scope, but it is working correctly when tclsh is used interactively.
If you are using the full path of the extension library in both cases, that part should work identically. It probably is doing though; if it couldn't load it, it would generate an error (which might or might not be helpful, as some of the ways that things fail give very little information; Tcl reports what it has got, but that's sometimes not enough, as it is dependent on the OS to tell it some things). Instead, the problem is probably elsewhere.
The main difference between interactive use and scripted use is that in interactive use, the unknown command will expand unknown command names to Tcl commands that the thing you typed is an unambiguous prefix of. This is convenient, but when converting to a script, you should always use the full command name. OK, not the full full command name — you mostly don't want or need the :: namespace on the front — but without abbreviation, so don't use lappe for lappend. (In interactive use, Tcl will also exec things as external programs without requiring you to type the exec explicitly; again, that's turned off in scripts as it is rather fragile.)
Could it be that this is what is going on? You can check by setting the global variable tcl_interactive to 0 before typing in your code (I recommend using cut-n-paste for that typing, so that you know exactly what is going in). If that fails, it's the interactive-mode helpfulness that is tripping you up. Check what commands you might have as an expansion for a prefix with info commands (after the load, of course):
info commands mytest*
If that just reports mytest, my theory is wrong. (Well, if it does that and the length of that string is 6; there could theoretically be extra invisible characters have been put on the command name, which would be legal Tcl but very nasty and DON'T DO THAT!)
I'm using IDL 8.3 on Mac 10.9.3
I am running a script that calls in a procedure. The procedure I am calling in is contained in a directory that I included in IDL's path (I did this by going under IDL->preferences->IDL->paths and adding the directory). However, when I attempt to run the script, I get the error message: "% Attempt to call undefined procedure/function: 'procedure.pro'. % Execution halted at: $MAIN$". The weird thing is is that it still lists all the syntax errors in the procedure that is supposedly 'undefined'. Also, when I type the procedure.pro name into the IDL prompt, it lights up teal/blue color (meaning it recognizes the procedure).
I tried making a very simple simple.pro, put it into the same directory I mentioned before, typed it into the IDL prompt (it turned teal/blue), and it ran perfectly with no errors.
I am unsure why the procedure.pro file is 'undefined' since it is contained it its path, and I proved with simple.pro that .pro files in this path will run correctly.
A couple of things to check:
Is the routine called as a procedure and defined as a procedure (or called/defined as a function)?
Does the name of the file match the name of the routine?
well, the procedure I was attempting to call in contained other procedures/functions that weren't included in IDL's original library. I just had to download these separate procedures/functions, and the syntax errors went away, along with the 'unidentified procedure' error message.
I'm not entirely sure how to define an Erlang function within an Erlang module. I'm getting the following error:
11> invoke_record:invoke().
** exception error: undefined function erlang:rr/1
From this simple code trying to invoke the rr(?MODULE). from within the beam executable in order to "initialize" records so that it doesn't need to be called from the shell every time.
-module(invoke_record).
-export([invoke/0]).
-record(process, {pid,
reference="",
lifetime=0
}).
invoke() ->
erlang:rr(?MODULE).
The command rr("file.hrl"). is meant to be be used only in shell for debugging purposes.
As other users highlighted in their answers, the correct way to import a record (or a function) contained in a .hrl file within your erlang code consists in using the command -include("file.hrl').
Once you have included the .hrl file in your code (and usually in a module based on OTP behaviours this is done after the -export(...) part) you can refer to the Erlang record (or function) without any problem.
rr is a shell command. You cannot use it it compiled code.
http://www.erlang.org/doc/man/shell.html
If your intent is to read many record definitions in the shell, in order to facilitate the debug, you can write a file containing all needed include statements and simply invoke rr once in the shell.
in rec.hrl:
-include("include/bank.hrl").
-include("include/reply.hrl").
and in the in the shell
1> rr("rec.hrl").
[account,reply]
2>
I didn't find any way to execute this automatically, when starting the VM.
When working on a project, you can gather all necessary includes and other command line arguments that you want to use for that particular project in a plain text file. After having made the plain text file, you can start your shell:
erl -args_file FileName
where FileName is the name of the plain text file. Note that all command line arguments accepted by erl are allowed. See also erl Flags in the ERTS Reference Manual