I've created an MFC activeX control named M.
and created another ATL project named N.
M references N, meaning M uses some classes in N.
M -> N
Then I compile all of then to .ocx files and run AxImp.exe against M.ocx like this:
AxImp M.ocx /out:AxM.dll
it only generates AxM.dll and M.dll, while I think it should also generates N.dll
What did I wrong?
thanks.
Related
Whenever I purposefully put H atoms inside a structure (with Fe and O in the structure as host atoms) as interstitials, I expect that it will be defined as an isolated atom with no bonds between it and the surrounding host atoms. However, depending on the location of the H interstitial, pyiron sometimes defines a bond between the additional H and the original O for lammps calculation.
This can be useful for the automatic detection of bonds. However, how can one control this feature whenever not needed?
I also believe there is a bug with the .define_bonds() function.
The inputs for the functions are:
species="O"
element_list=["H"]
cutoff_list=[2.0]
max_bond_list=1
bond_type_list=1
While I believe the max_bond_list and bond_type_list are supposed to be lists, it only works error-free if both are defined as integers instead because of the way they are defined. However, defining them as integers then messes up running the jobs because they should be iterables.
I wish to make use of a subroutine in a DLL for my research. The dll is provided to me as a blackbox and can be used in a leading FE software.
I executed the following code for the dll
dumpbin /EXPORTS UDSM_HPS.dll > UDSM_HPS.exports
and ended up with the following subroutine
2 0 00020D50 _getmodelcount#4
4 1 00020D60 _getmodelname#12
6 2 00020E50 _getparamcount#8
8 3 00020E80 _getparamname#16
10 4 00021AE0 _getparamunit#16
12 5 00001010 _user_mod#124
1 6 00020D50 getmodelcount
3 7 00020D60 getmodelname
5 8 00020E50 getparamcount
7 9 00020E80 getparamname
9 A 00021AE0 getparamunit
11 B 00001010 user_mod
My interest lies in the 'user_mod' subroutine. I created a .lib file from the .def file, by adding 'EXPORTS' in the beginning of the file and isolating the subroutine names, using the following code
lib /def:UDSM_HPS.def /out:UDSM_HPS.lib
and attached the .lib file to the 'Resourse Files' to my Visual Studio 2013, while placing a copy of my .dll to my 'Debug' folder.
No surprises here, the 'user_mod' subroutine is not seen by the compiler.
Now My question, am I missing something, or is there a differnt way of utilising the subroutine from the dll?
The dll is written in FORTRAN too, and I have written a simple piece of FE code in FORTRAN to run this subroutine.
Long story short: Any assistance is figuring out how to utilise a FORTRAN dll in FORTRAN program is much appreciated.
Edit 1:
I am using the Intel Fortran compiler - Intel(R) Visual Fortran Compiler XE 15.0.6.285 [IA-32]. I had tried compiling the same piece of code in Intel(R) Fortran Compiler 10.1.021 [IA-32], but in vain.
The subroutine I intend to call is
call user_mod(IDTask, iMod, IsUndr, iStep, iTer,&
iEl, Int, X, Y, Z, Time0, dTime, Props, Sig0, Swp0, StVar0,&
dEps, D, BulkW, Sig, Swp, StVar, ipl, nStat, NonSym, iStrsDep,&
iTimeDep, iTang, iAbort)
To clarify my rather vague sentence of 'not seen by the compiler', I meant this error
Error 1 error LNK2019: unresolved external symbol USER_MOD referenced in function PLAXIS_DLL_INTF interface_files.obj
Edit 2:
Thanks for the all the help.
Adding
!DEC$ ATTRIBUTES STDCALL,REFERENCE :: USER_MOD
was all that was needed to get my code going. Code is behaving like how it should now.
Thanks for providing the error message - that is the key. It isn't the compiler that can't see user_mod, it's the linker. Note that the error message refers to USER_MOD, but your dump of the symbols says user_mod. Case matters!
It is also important that the routine you're calling has the STDCALL calling mechanism. This is not the Intel Fortran default, and getting this wrong leads to stack corruption.
The solution is to add the line:
!DEC$ ATTRIBUTES STDCALL,REFERENCE :: USER_MOD
to the routine calling USER_MOD - in with the declarations. This tells Intel Fortran that USERMOD is a STDCALL routine, and downcases the routine name. Also make sure that you are passing the correct number and type of arguments when you call USER_MOD. If you get this wrong, you'll get link errors. Last, I am guessing about the use of REFERENCE here, but I will assume it is correct since I don't know how USER_MOD was built. At least this will get you past the link error.
I have a read/write operation going on in the Fortran code snippet as follows
OPEN(5,FILE='WKDAT.dat', STATUS='OLD')
OPEN(6,FILE='WKLST.dat', STATUS='UNKNOWN')
I know that by default the unit number 5 is used for input from the keyboard and unit number 6 is used to display on the screen. Also I can use *.
But in the above-mentioned Fortran code unit number is 5 and a file name "WKDAT.dat" is given. So this means that the data is being read from "WKDAT.dat" file. Also there is code unit number 6 and a file name "WKLST.dat" is given. So this means that the data is being written to "WKLST.dat" file.
Is my understanding correct?
As per my basic knowledge:
Unit number 5 is only used to take input from keyboard & unit number 6 is only used to print to console so no files should be involved. But in the code snippet it has both unit number 5, 6 as well as file name.
So both are contradicting :(
In this link http://www.oc.nps.edu/~bird/oc3030_online/fortran/io/io.html they have mentioned the following "When I/O is to a file you must ASSOCIATE a UNIT number (which you choose) with the FILENAME. Use any unit number other than 5 and 6. On some computers, some unit numbers are reserved for use by the computer operating system."
Fortran has no magic unit numbers. The Fortran standard says nothing about 5, 6 or any other valid unit number being used for a special purpose. As such you are free to use the open statement to associate any valid unit number with a file. However traditionally for reasons that pre-date me 5 and 6 have been pre-associated with the keyboard and screen, as you say. Now still you can change the association by use of the open statement and that is fine save for the confusion it can cause, so most people I know recommend avoiding this and using unit numbers of 10 and upwards. Also because 5 and 6 are not guaranteed to be associated with the default input and output devices I would recommend against their use, preferring * or, in more modern code, the named constants input_unit, output_unit and error_unit from the iso_fortran_env intrinsic module.
So in summary you've got the right idea, and I'm not surprised you're confused.
Nothing in the standard says units 5 and 6 have any special meaning although in practice standard input and standard output are often pre-connected to 5 and 6.
Module iso_fortran_env from Fortran 2008 contains constants
INPUT_UNIT
OUTPUT_UNIT
ERROR_UNIT
with the unit numbers where standard input, standard output and standard error are connected. These are allowed to be different than 5 and 6.
Opening a file in unit that is in use causes the unit to be associated with the new file.
For example the Cray Fortran manual says:
Unit numbers 100, 101, and 102 are permanently associated with the
standard input, standard output, and standard error files,
respectively.
That means if you open some other file as unit 5 or 6 standard input and standard output still have some other unit where they are pre-connected and they will not be closed.
I want to store a list of variable names in a new local variable, such that I do not have to type a long list of variable names for each regression. I am using Stata 14.
E.g., I have the following 5 independent variables: a b c d e and one dependent variable: f
I don't want:
regress f a b c d e
But I want something like:
regress f allvar
How can I generate allvar?
Unfortunately, this does not work
local allvar a b c d e
The following works fine.
clear
set more off
sysuse auto
// first regressions
regress price mpg rep78 weight
// second regression
local allvars mpg rep78 weight
regress price `allvars'
Unless you show us something reproducible and/or more explicit, it's difficult to see what the problem is. A report only mentioning "does not work" is usually useless.
See also the keyword _all in help varlist.
You are using a local macro. If you are running the code by parts, then don't. You need to run the whole code, all at once. Read [P] macro, for details. An excerpt:
Local macros exist solely within the program or do-file in which they
are defined. If that program or do-file calls another program or
do-file, the local macros previously defined temporarily cease to
exist, and their existence is reestablished when the calling program
regains control. When a program or do-file ends, its local macros are
permanently deleted.
A common reason why your command sometimes "does not work" is that you ran your do-file line by line, rather than all in one go. A local macro is local to a session (hence the name). So if you ran the line local allvar a b c d e, then that will create that local macro and let it disapear as soon as Stata finished running that section of your .do file. There are two solutions:
You can get into the habit of running the definition of local macros and their use in one go. It is actually good practice to make many small .do files and make each .do file self-contained (see for example this excellent book), so you can easily just run the entire .do file each time you want to check or change something.
Alternatively, you can use global macros. These continue to exist after a session. As someone that programs in Stata, using global macros hurts my eyes, but I guess that if you use Stata only to analyse data it does little harm.
As an asside, allvar does not seem like a right name for that local macro: it does not contain all variables as it excludes the variable f. This sounds pedantic (and it is), but it is good practice to use names that accurately describe its content. In a real project we tend to come back to it after some time. A common scenarion is that you submitted a paper to a journal, it took half a year or more for the reviews to come in, and now you need to "read" your own .do-file to understand what you did half a year ago. At that point you are very happy that you were pedantic when writing the .do file...
As a further asside, assuming that a b c d e f are indeed all the variables in your dataset you can also create your local using:
ds f, not
local rhs `r(varlist)' // rhs short for right-hand side
My folder contains several files, which are compiled in this order: global.ml, zone.ml, abs.ml, main.ml
global.ml contains some reference variables (e.g. let g1 = ref 0) for all the files.
In zone.ml there is a declaration let f = !g1.
In abs.ml, there is g1 := 5, which will be run by main in the beginning of run-time, I consider it as an initialization of g1 given the real run-time context.
Later main will call Zone.f. Curiously, what I realize is that it takes f = 0 instead of f = 5.
Do you think this behavior is normal? If so, what should I change, to make it take the current value of !g1 into account?
PS: Maybe one solution is to make a function let f v = v in zone.ml then let main call Zone.f !g1. But I have several global reference variables as g1 in global.ml, I hope they could be valid over all the files and functions, and I don't want to get them involved in the signature of a function.
You are basically concerned with the order of evaluation of the top-level values in your modules. The order in which this happens isn't related to the order that you compile the files, but rather the order that they appear when you link the files.
If you ignore the module boundaries, if you link the files in the order you give, what you have is like this:
let g1 = ref 0
let f = !g1
let () = g1 := 5
It shouldn't be surprising that f has the value 0.
Note that your main is not necessarily the first thing that happens at runtime. Top-level values are evaluated in the order the files appear when you link them. Very commonly, main is the last top-level thing to happen (because its file is usually the last one).
(Also note that having a main at all is just a convention, presumably adopted by former C programmers like me. There's no requirement to have a function named main. OCaml just evaluates the top-level values in order.)
Edit:
It's difficult to say how to restructure your code without knowing more about it. The essence of your problem appears to be that you define f as a top-level immutable value in zone.ml but you want its value to follow g1, which is a mutable value.
The simplest suggestion would be to remove the definition of f from zone.ml and replace it everywhere in the file with !g1.
If you want to retain the name f at the top level in zone.ml, you have to redefine it as something other than an immutable value. A function is the most obvious choice:
let f () = !g1
Then you would replace uses of f in zone.ml by f () instead.