How do I change the default solver in AMPL? - ampl

AMPL by default uses MINOS. I have to type option solver "./lpsolve"; every time I want to use lpsolve as my solver. Is there a way to change the default?

Create a text file in the directory where AMPL and lpsolve is with the following line:
option solver './lpsolve';
Before running ampl, you have to set the OPTIONS_IN environment variable and make it point to this newly created text file. I am using bash and I gave the name settings.txt to this text file. Before calling ampl, I issue the following command in the bash shell:
export OPTIONS_IN=./settings.txt
There are others ways to do this, and you may use another shell so I don't want to expand on this.
You may find useful the CPLEX user's guide. Even though it's for CPLEX, there are a few sections on ampl that generally apply.
For example all the above I write is in this user's guide, see Chapter 4 Customizing AMPL, section Persistent Option Settings.

Related

Is there a way to export the predefined macros from a Keil build configuration?

Context:
I'm trying to automate some of the more mundane tasks in embedded development with Keil. The end result I'm aiming for is that clicking build in a Keil project will run a pre-build step that runs all the code through Uncrustify (a source code beautifier) to ensure it conforms to the company style-guide, and a post-build step which then runs the code through pc-lint (a static code analyser) to highlight any potentially unsafe code that it might find. I've written a PC utility that searches through the .uvproj file for the #define macros, the include paths and the file-paths all of which are needed for both tools and then modifies the pre and post-build user commands to call up my batch files which will manage both steps. The uncrustify part is working fine and the lint part is producing some sensible messages, but the signal-to-noise ratio isn't that great.
My problem:
Lint keeps on producing messages that seem to relate to macros that the Keil compiler is aware of, but that Lint isn't. I'm trying to find a way to plug that gap. I found a table of predefined macros documented on the Keil website, which seems like a good start, but rather than manually copying them into a static .lnt file, I'd like to find a way of grabbing the up-to-date values at the time the project gets built. This way, the "__ARMCC_VERSION" macro, for instance, would be updated whenever the developer updates his/her Keil compiler, rather than being stuck at a point in time whenever I manually copied it.
I'd love it if someone can answer my question directly, but I'd be equally pleased if someone has a viable suggestion for a more straightforward alternative approach I could try instead. Many thanks!
I am assuming you're using the Keil ARM Compiler.
From the Compiler User Guide:
To list macros that are defined on the command line, predefined by the compiler, and found in header and source files, use --list_macros with a non-empty source file.
To list only macros predefined by the compiler and specified on the command line, use --list_macros with an empty source file.
EDIT:
It looks like your SDK also adds a few macros.
From the µVision User's Guide:
The following control strings are added, depending on the use of MDK:
__UVISION_VERSION:
Major and minor version of µVision. For example: -D__UVISION_VERSION="520".
RTE:
Set when RTE is in use. For example: -D_RTE_.
__RTX:
Set when RTX Kernel has been selected in Options for Target - Target - Operation System. Not set when using RTE. For example: -D__RTX.
__MICORLIB:
Set when Use MicroLIB has been enabled in Options for Target - Target. For example: -D__MICROLIB.
__EVAL:
µVision runs in evaluation mode. License MDK-Lite. For example: -D__EVAL.
device header name:
Device header name.

Parameters to Script

Is there some way to pass parameters (or command line arguments) to a Yosys script?
I see in this quetion (Can we have variables in a Yosys script?) you can run the Yosys script within a TCL interpreter. Is there some way to pass in an argument?
The reason I am doing this is that I have a script, and I want to be able to call the script with a parameterized path to a Verilog file. Surely this is a common need, and there must be some easy way to do this, but I'm not seeing it.
The only way to do that at the moment is using environment variables and TCL scripts. For example, you can write a TCL script test.tcl:
yosys read_verilog $::env(VLOG_FILE_NAME)
yosys synth -top $::env(TOP_MODULE)
yosys write_verilog output.v
And then call if with VLOG_FILE_NAME and TOP_MODULE set in the environment:
VLOG_FILE_NAME=tests/simple/fiedler-cooley.v TOP_MODULE=up3down5 yosys test.tcl
If you are running Yosys from a shell script you can also simply run something like export VLOG_FILE_NAME=... at the top of your script. Similarly you can use the export Makefile statement when you are running Yosys from a Makefile.
I was facing a similar case. This question showed up while I was working on a solution. I ended up with a different approach though:
I'm creating a wrapper to my top module, written in m4 language. It's very simple, it overrides the parameters value, and then includes my top module definition.
Then in the Makefile, I process the wrapper.m4 file, to create the resulting wrapper.v file, that will be input to yosys.
I have detailled the solution here.

Changing the output language of gpg2.exe

I am automating a process and I use GPG2.exe for it.
Because I need to parse console output - potentially from different systems I need to set the languge to a controlled value.
I am following the Instructions from the manual which states that
LANGUAGE
Apart from its use by GNU, it is used in the W32 version to override the
language selection done through the Registry. If used and set to a valid and
available language name (langid), the file with the translation is loaded from
gpgdir/gnupg.nls/langid.mo. Here gpgdir is the directory out of which the
gpg binary has been loaded. If it can’t be loaded the Registry is tried and as
last resort the native Windows locale system is used.
I found a thread from 2011 that goes into a bit more detail regarding this problem, but this may actaully concern a different version.
I created a batch file for manual testing.
#echo off
REM C is meant to display untranslated messages according to one internet source
set LANGUAGE="C"
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
pause
I ecpext the output to be english but it is still german.
The manual states something about there beegin a "gnupg.nls" folder somewhere.
I was not able to locate this folder, which makes me wonder where german is loaded from.
Is there an error in the man page?
The pdf Version of the man page shows the same content as the man page that came with the installation.
Can someone shed some light on this?
I had the same problem that the output was in Swedish though I wanted it in English. The Windows display language was set to English, and I also tried setting environment variables but what solved it for me was to remove the Swedish translation for gnupg file found here:
C:\Program Files (x86)\gnupg\share\locale
After having removed the "sv" directory all output was in English.
The language directory can be pulled from the registry or I suppose it can also have a fixed path since I can not find the information in my registry.
On my testsysten the path is 'C:\Program Files (x86)\GNU\GnuPG\share\locale'.
This path contains folders for each language - not all of them contain translation files for gpg2 as far as I can tell.
The environment variable for language is not LANGUAGE but LANG. Setting it to C causes gpg2 to default to english.
I successfully tested the following call.
#echo off
set LANG=C
call "C:\Program Files (x86)\GNU\GnuPG\gpg2.exe" --version
User bignose is still correct when he states that I should use the API instead but within my current restrictions I do not see a straight forward way to do so.
This isn't a programming question, as noted in the votes to close.
To answer a different question that could be asked from a programming perspective: Don't parse inherently-changeable console output, when there is a well-defined library API for the same functionality.

no module named modeller

i have started using python for using modeller software for modelling proteins. i have a plot script for plotting graphs it has a module named pylab and its not working with the modeller CMD prompt with windows7 software. and while running the same script by using python shell it showing importerror no module nemed modeller. when i asked to my higher officials he asked me to set PYTHONPATH and LD_LIBRARY_PATH variables. but i dont know how to do it..can u explain me how to set the path in layman format which i can understand easily. but then too i have tried Advanced setting->environmental variables and setting variables but i do not know how to set the path for each variables..please some one guide me with it.
There is some documentation in the python docs for how to deal with this, but it sounds like the confusion is on what to set the variable to.
If you start your command prompt (cmd.exe in the start menu), you can set a variable by using the command
SET PYTHONPATH=%PYTHONPATH%;C:\My_python_lib
The PYTHONPATH variable describes the location of the modules so python knows where to look to find them. It looks like a list of filepaths separated by semicolons.
What this command does is set the variable PYTHONPATH to its current value (the %PYTHONPATH part), adds a semicolon, and puts C:\My_python_lib at the end of the list.
You need to find the path to the pylab module (probably a folder named "pylab" with a file called __init__.py in it) and add it's location to your PYTHONPATH

CDash Custom Dynamic Analysis

I'm trying to integrate custom dynamic analysis tools to CDash. Such as KWStyle, CppCheck and Visual Leak Detector.
I'v figured out that I need to generate a DynamicAnalysis.xml file and submit it to CDash, from CTest scripts.
I think I know how to run the external tool as a part of the ctest script.
Either by using these variables to change how ctest_memcheck() works
CTEST_MEMORYCHECK_COMMAND
CTEST_MEMORYCHECK_SUPPRESSIONS_FILE
CTEST_MEMORYCHECK_COMMAND_OPTIONS
or by running the tool from the execute_process() command.
But I'm a bit uncertain which one to use.
The main problem I think I have is, how can I extract errors from the output of the custom tool and include that information into the DynamicAnalysis.xml to submit?
The extreme solution i see is that i'd need to make a program that generates a valid DynamicAnalysis.xml file.
But the problem is that I don't know the syntax of the DefectList element in the XML file. I have found no answer from google and even the XML Schema for that file is unhelpful.
EDIT:
Looking at this:
http://www.cdash.org/CDash/viewDynamicAnalysis.php?buildid=987149
What draws my attention are the labels, especially the empty ones. I don't see how these would come from the DynamicAnalysis.xml file. Maybe it tracks any labels that have ever appearred? Can i create my own custom labels somehow?
Does CDash create the labels automatically, depending on the tool type? Does this block custom defect types?
I'm just guessing here, so the question is; can i create custom labels for my custom tool, just by generating a DynamicAnalysis.xml - file.
It occurred to me that the amount of different errors from CppCheck (static code analysis) is huge, compared to valgrind for instance. I'm not that certain that I should use the dynamic analysis. Maybe a custom build type (Continuous / Experimental / Nightly) thing would work better. Like this:
http://www.cdash.org/CDash/buildSummary.php?buildid=930174
I have no idea how to do this, i guess it requires meddling around with CDash code?
Which one would work better?
If you are using valgrind, you can simply set CTEST_MEMORYCHECK_COMMAND to the full path to valgrind, and ctest will generate the DynamicAnalysis.xml file for you from the valgrind output when you call ctest_memcheck.
The best way to understand the possible values that can appear in the DynamicAnalysis.xml file is to analyze the source code of CTest.
The file CMake/Source/CTest/cmCTestMemCheckHandler.cxx has the list of defect types in a variable named "cmCTestMemCheckResultLongStrings". Search through that file for references to that variable to see what the possible values are and how they are used to generate "<Defect/>" xml elements.
EDIT (for additional information):
You can also easily see what XML elements CDash is expecting by inspecting its source code. Specifically, the file "CDash/xml_handlers/dynamic_analysis_handler.php".
From what I'v learned so far, is that for a tool that runs on the tests made in the cmake script, the Dynamic Analysis is the thing.
For tools that run on the entire program, a custom Build.xml is the thing you need.
I found out that i can commit those files from the ctest_submit command by using the FILES parameter.
I also found out that you can add custom "build names" to the side of Continuous, Nightly, and others.
And that you can set the builds from certain machines to be automatically transferred under these.
The custom labels under DynamicAnalysis did come from somewhere in CDash, i can't remember where anymore.