I've been learning Swift for a little bit now, and I really want to use it. However, compiling Swift on Windows is quite a chore. I can do it from Visual Studio 2015 easily, but VS2015 support is very poor, and incredibly hard to work with; I would prefer to use Atom and the command line. I use RemObject's Silver to compile to .NET, but I can never get the command line to work.
When I use the Elements.exe at C:\Program Files (x86)\RemObjects Software\Elements\Bin, passing the filename as a parameter, it tells me that print is undefined.
Does anyone know how to use Silver's command line to compiler Swift?
Have you tried referencing the online documentation?
calling elements needs some libraries to import:
elements --mode=ECHOES --reference=Swift myfile.swift
I recommend using MSBuild, rather than Elements.exe, to build Elements projects from the command line. It's more complete and supports more advanced build tasks needed for some project types.
That said, --mode and --reference should definitely work. Can you post a complete command line and output?
You will need --reference=Swift in order for print() & co to be known, and --reference System.Core to use LINQ.
Related
Simple question here, just can't seem to pass it google in a way it can understand.
Say I wanted to execute a line of actual programming code (c++ or java or python... etc) like SetCursorPos or printf from the command prompt command line. I vaguely imagine I would have to invoke the compiler and pass the command to it like a parameter, where from it would then be converted into machine language and passed to... where exactly?
Okay so that was kind of two questions.
How to run actual code from the command line and
what exactly is happening when a fully compiled program, or converted line of code (presuming these are essentially binary containers at that point), is executed?
Question one takes priority obviously. Unfortunately, I can not find any documentation on it, just a bunch of stuff vaguely related to it.
How to run actual code from the command line
Without delving into the vast amounts of blurriness between them, there are two major categories of language implementations: interpreters and compilers.
With many interpreters (or implementations with implicit compilation, such as V8 JavaScript's jit compiler, or pretty much anything with a repl), running a single line from the command line should be fairly trivial. CPython (the standard implementation of Python) has the -c command option:
$ python -c 'print("Hello, world!")'
Hello, world!
Language implementations with explicit compilation steps will tend to be decidedly less simple. In particular, the compiler would need to either accept source either from directly out of the argument list, or from standard input (via piping or redirection). On the output side, your compiler would have to support immediately executing that program, or outputting it to standard out, so that an operating system feature (if it exists) can execute it from a pipe.
To my knowledge, most explicit compilers are not designed with such usage in mind. In such cases, your best bet is to see if there is a REPL available for the language in question, preferably one as compatible with your compiler as possible, or to create (or find) a wrapper that makes it look like your language has a REPL. The wrapper would:
Accept input along the lines of CPython above.
Create a temporary source file behind the scenes with the code to be run and any necessary boilerplate.
Pass that file to the compiler.
Automatically run the resulting executable.
Delete the source file and executable. These may be cleaned up by the operating system later instead, if they're in a temp directory.
From the point of view of the user, this should look pretty similar to the CPython example, as they wouldn't have to interact with or see the compiler or temporary files.
I am new to Coverity,I am using it from the command prompt with it's .exe files.So I want to pass specific macros in coverity cov-build.exe so that those macros will be implemented when cov-emit.exe(when it is called by cov-build.exe) is parsing the .c files.Till now I have tried the below stated configurations.
code-build.exe Intermediate_folder --delete-stale-tus --preprocessor-first --return-emit-failure "My_bat_file" -- -D My_macro_name=my_macro_body
So any help will be much be appreciated.I am stuck on this.
Thanks and regards,
Newbie_in
cov-build wraps your existing build command, monitors it and spawns parallel compiler invocations in order to understand your code. These parallel compiler invocations will see the same command line being passed to your own compiler.
So if you want this define to take effect for your compiler as well as Coverity's then you should simply just add it to your build the way you would normally and Coverity will see it.
If you want to add a define that only Coverity's compiler can see, this is best done with within the config for your compiler.
You can either edit the config directly (add
<append_arg>-Dmy_macro_name=my_macro_body</append_arg>
after the <begin_command_line_config> line), or re-configure using --xml-option.
For example, if you're using the shortcut gcc config this would look like this:
$ cov-configure --gcc --xml-option=append_arg>-Dmy_macro_name=my_macro_body.
I noticed you're using --preprocess-first on the cov-build command line - I recommend against this, as it destroys XREFs making it much more difficult to browse defect information, as well as makes the analysis unable to find some defects (i.e. ones that are due to macros). --preprocess-next behaves like --preprocess-first and will only fire if the initial compilation attempt fails, so if you're using --preprocess-first to work around compilation issues, I strongly recommend using --preprocess-next instead.
If you do have compilation issues, it's always good to report them (along with a reproducer) to Coverity support so that they can be fixed in future releases.
I usually have an environment setting for MAKE_MODE (Windows XP, using GNU make, both under Cygwin and native)
set MAKE_MODE=UNIX
I now found differences between my build server (which has no MAKE_MODE defined) and a local build. This may be something completely different, but it got me wondering what other values I could specify for MAKE_MODE.
I think I know that MAKE_MODE=UNIX is suppose to tell GNU make to use /bin/sh - if it finds it - , but I quickly checked the GNU make manual and couldn't find a description. A google search only told me what I already know, but doesn't give a valid alternative.
Is the only alternative to not define the variable? Does it have influence at all when using CMD.exe and a native version of GNU make?
EDIT: So far I have found references for the values 'unix', 'win32', 'null' and undefined, but no explanations, and no specifications. But a look at the source code for GNU make 3.82 shows not a single occurrence of the string "MAKE_MODE", so GNUmake itself apparently doesn't change its behavior when this environment variable is set or not.
EDIT2: I checked the source code for GNU make for MinGW, and again found nothing. Maybe it's CygWin specific?
EDIT3: I found a reference that it might be property of an old version of GNU make, so I checked version 3.75. No luck, the string MAKE_MODE does not appear in the source code at all. The next step really must be the Cygwin version of GNU make. I know from 10 years ago that the Cygwin port in those days was not integrated in the regular source tree.
I found an ancient mailing list entry on the Cygwin site, explaining the basic operational effect of MAKE_MODE. This definitely indicates that the variable has to do with the Cygwin implementation of GNU make.
I'll dig around in the source code, and add to this answer when I find more details.
UPDATE: In a more recent post by maintainer Christopher Faylor I found the following update for GNU make version 3.81:
Note that the --win32 command line option and "MAKE_MODE" environment
variable are no longer supported in Cygwin's make. If you need to use a
Makefile which contains MS-DOS path names, then please use a MinGW
version of make.
I've not really found the values allowed for MAKE_MODE, but it's not any more necessary or supported in most recent versions of GNU make for Cygwin, and it was used for supporting DOS filenames in Cygwin's make.
And if you really want to know the set of allowed values, look in the source for Cygwin's make version before 3.81-1. I guess the only useful value was unix, all others will have meant the same.
Case closed? There's still not many views here...
This was asked before, but the solution doesn't seem to work on MacOS. Wolfram Library has a package for 7 year old Matlab version. Is there a solution that works on MacOS 10.6 and Matlab 7.9?
I want to call CVX from Mathematica
You could use RunThrough["command",expr], this runs the external command command, and feeds expr (a Mathematica expression) as input to command
An example of a suitable command would be "matlab -r \"matlab expr\"", you could place your CVX specific code in the "matlab expr" string.
Update: Right now, probably MATLink is the best way to do this. It works on Windows/Linux/Mac.
Disclosure: I'm one of MATLink's authors.
Have you tried using the newer mEngine instead? I can only try it on Windows, but after looking at the sources, I believe it might work on other platforms too.
Hopefully you only need to modify main.c, actually just copy and paste the main function from one of the MathLink examples (e.g. addtwo), as mEngine's main.c has the non-Windows-specific part removed. Then compile the package as a MathLink program.
Take an undocumented executable of unknown origin. Trying /?, -h, --help from the command line yields nothing. Is it possible to discover if the executable supports any command line options by looking inside the executable? Possibly reverse engineering? What would be the best way of doing this?
I'm talking about a Windows executable, but would be interested to hear what different approaches would be needed with another OS.
In linux, step one would be run strings your_file which dumps all the strings of printable characters in the file. Any constants chars will thus be shown, including any "usage" instructions.
Next step could be to run ltrace on the file. This shows all function calls the program does. If it includes getopt (or familiar), then it is a sure sign that it is processing input parameters. In fact, you should be able to see exactly what argument the program is expecting since that is the third parameter to the getopt function.
For Windows, you can see this question about decompiling Windows executables. It should be relatively easy to at least discover the options (what they actually do is a different story).
If it's a .NET executable try using Reflector. This will convert the MSIL code into the equivalent C# code which may make it easier to understand. Unfortunately private and local variable names will be lost, as these are not stored in the MSIL but it should still be possible to follow what's going on.