I use the FORTRAN_WINPRINT.F90 to print from my applications, but the print window (the one that allows you to select your printer) opens almost always behind my applications window. Not every time, but more probably more than 70% of the time. So users think the program has stopped when it is actually waiting for input. How do I get this Print window to always come up in front of my applications window?
My builds previously worked, but after updating with the latest Intel Fortran tools, I no longer have a libmmt.lib and my build has a fatal error:
Error 9 fatal error LNK1104: cannot open file 'libmmt.lib' LINK
My update database shows that libmmt.lib DID previously exist in e.g. Program Files (x86)/Intel/Composer XE 2015/Compiler/lib/intel64
but it is gone after the update. Other tools (Intel Software Manager) seem to be gone, too.
Is this change expected and what can I do about it?
This is mostly an FYI on a follow up to the locked post: https://software.intel.com/en-us/forums/topic/515943
I had the same x64 debugging problem (watch variables show up with undefined addresses), so I updated to the latest ver of Fortran composer (Intel(R) Visual Fortran Compiler XE 188.8.131.52), which is update 5, but this did not fix the problem (the problem only occurs with VS2013, but not VS2010).
in my company we have some IF Studio 2013 and some IF Composer 2013 installed.
I've updated the Composers XE 2013 to SP1.5.239
Now I'm searching for SP1 Update 5 for the Studio-versions, but in the Intel-download-area I can only find SP1 update 3.
I assume the the Studio-Update is just a bundling of the updates of the tools it consists of.
Question: is it save to update a Studio-installation with the Composer-Update?
I've been looking for documentation of what has changed with this vector reduction. The one note I find in ifort release notes is about the somewhat curious addition of these reduction clauses to the legacy !dir$ simd directive in 15.0.1.
In the basic case, the reductions, using f77 code and directive, are equivalent to f90 maxval and minval, so the latter seem preferable, and I almost wonder why so much fuss has been made about directives which 15.0.3 seems to show aren't needed for the single thread case.
If I know the record length (recl) and number of record(n) i want to read in a file is safe to:
open the file with a record length of recl*n
read the file in block
in other work can I always assume that the data will be sequential and not record delimiter will make this operation unsafe.
I cant post a comment to the Documentation -
It wasn't terribly important, but the WORD verfication fails -
It mentioned something about "you may be blocked."
However, when I used the AUDIO version of that, it worked.
any reason why they are not consistent?
Would I be blocked? If so, why?
I have a large 3-dimensional array and I'm trying to do an element-by-element maximum on the first 2 dimensions using the MAXVAL function. When I do, I get a stack overflow error. Is there a size limit to the MAXVAL intrinsic function? The code is abbreviated below with constants in the array declarations and allocations instead of variables just to show the size:
real, allocatable :: arr2(:,:), arr3(:,:,:)
allocate( arr3( 0:1000, 1:440, 1:6 ), source = 0.0 )
allocate( arr2( 0:1000, 1:440 ), source = 0.0 )
...! assign values to arr3
I'm trying to use parameterized derived types and have run into a problem which I have distilled into the following code:
module t_mod implicit none type T(k) integer, kind :: k = 4 integer(kind=k) :: d contains procedure, public, pass(x) :: check_v end type T contains logical function check_v(k, x) integer :: k class(T) :: x check_v = (k == x%d) end function check_v end module t_mod
I get the following compilation error:
I am trying to use OpenGL functions that are not directly supported by Windows, which only supports GL functions up to OpenGL 1.1. Supposedly the the wglGetProcAddress function allows access to functions supported by the graphics hardware from following versions of OpenGL.
Here's what I'm trying to do....