Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Module Fortran 90


IThe compiler rejects the module global.

MODULE global
 implicit none
 save
 integer N,k
 integer,dimension(:), pointer :: A
END MODULE global

I thought that the declarations in mobile would apply in the main
program or any subroutine, which included the command "use global."

John

John <j@lehigh.edu> wrote:
> IThe compiler rejects the module global.

> MODULE global
>  implicit none
>  save
>  integer N,k
>  integer,dimension(:), pointer :: A
> END MODULE global

There is nothing wrong with that module. The g95 compiler I tried had no
trouble with it, and I'd be a bit surprised if any compiler did, as it
is pretty simple.

Perhaps you need to be more specific about exactly what you did and
exactly what the compiler message was.

The possibilities that occur to me are

1. That you are compiling the module incorrectly. One possibility there
is that you might be telling the compiler to build an executable from it
alone. Since you don't say what you are doing to compiler it, there is
no way to diagnose that.

2. That you are seeing an error in something that uses the module
instead of in the module itself. Since you don't show any such using
code, there is no way to diagnose that.

3. Other, more obscure issues having nothing to do with the code shown.
There are infinite possibilities that can't be diagnosed with the data
given.

> I thought that the declarations in mobile would apply in the main
> program or any subroutine, which included the command "use global."

That's not a very accurate description. Sort of close, but inaccurate
enough to make possibility 2 above seem more likely. In particular, it
is not declarations that are accessed from a module. What is accessed is
is the entities that are declared. Yes, there are multiple major
differences. But I won't go on about that, as I don't know that it has
anything to do with your problem.

I suggest describing your environment (notably operating system and
compiler), showing exactly what you did, and exactly what the resulting
mesage was.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 2, 1:37 pm, nos@see.signature (Richard Maine) wrote:

...

One variation of (most nearly item 1) that strikes me is perhaps OP is
unaware that the module must be compile before the code that uses it,
not just have the source available...that would kinda' correlate w/
the description as well...

But, of course, the real answer is to follow your request and provide
enough context to be able to tell what was done and how and what the
result was (precisely)...

--

On Jun 2, 5:59 pm, dpb <bozart@gmail.com> wrote:

I was thinking the same thing. But now that you bring it up, why do
modules have that restriction? Is it to avoid self reference in some
roundabout way?

Gabe <DrWeymo@gmail.com> wrote:
> On Jun 2, 5:59 pm, dpb <bozart@gmail.com> wrote:
> > ...perhaps OP is
> > unaware that the module must be compile before the code that uses it,
> > not just have the source available...

> I was thinking the same thing. But now that you bring it up, why do
> modules have that restriction? Is it to avoid self reference in some
> roundabout way?

No. First be aware that this is not a restriction specified in the
standard. The standard doesn't talk about compilation at all, much less
compilation order. The standard says something about the public parts of
the module being available, or some such words, but the precise meaning
of that is left to the compiler vendor. Typically, yes, it means that
the module must have been compiled and the resulting .mod file must be
in the module search path. I have used at least one compiler (no longer
around, and was a piece of junk anyway) where there were no .mod files
or equivalent; a USE statement scanned the module source code.

Anyway, ignoring all that, compilation to a .mod file or something
simillar is the most common implementation. For such implementations,
the reason that you need to compile the module first is nothing
complicated or esoteric at all. The whole point of a USE statement is to
access the information from the module. The information in question is
in the .mod file that is produced by compiling the module. So you have
to have compiled the module to make that file.

Implementations could, in theory, look directly at the module source
code instead of at a .mod file. I mentioned that I've seen one
implementation that did that. But that has a whole host of problems; it
just doesn't work out well. Another possibility is that implementations
could automatically trigger compilation of the module when needed. But
that also has complications; it gets into the whole thing of compilation
dependencies, more typically handled by utilities like Make than by
compilers. (Not that I'm at all a fan of Make's design, but I'll not
wander off into that subject).

Given the basic implementation idea that compiling a module produces a
.mod file and that a USE statement reads the .mod file, it trivially
follows that you have to compile the module first. That's realy all
there is to it.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 2, 2:12 pm, John <j@lehigh.edu> wrote:

> IThe compiler rejects the module global.

> MODULE global
>  implicit none
>  save
>  integer N,k
>  integer,dimension(:), pointer :: A
> END MODULE global

> I thought that the declarations in mobile would apply in the main
> program or any subroutine, which included the command "use global."

> John

Followup to my message, at 2:12 pm, on June 2.

Operating System: SUSE LINUX ENTERPRISE, System 9, ServicePack 3,
kernel 2.6.5

Compiler: INTEL 8.1.020

Errors: error in creating the Library module file [GLOBAL] & error in
opening the Library module file & numerous errors complaining that
variables N, k and A had no types

John

You got the OS and compiler parts. But you still did *NOT* show exactly
what you are doing. I can only repeat my prior suggestion that you show
*EXACTLY* what you did. Please note the emphasis on the word "exactly".
You haven't even described it in general terms, much less exactly.
Showing us exactly would include at least the exact command used to do
the compilation. It would also include the exact text of the error
messages. Some of what you cite is obviously not exact error message
text; certtainly "numerous errors complaining" isn't. The more
interesting one is the first one; I can't tell whether it is the exact
(and complete) message text or not.

I have no idea why you got an error creating the module file. You
haven't given enough data to make a diagnosis. It could be any number of
things, some of them trivial, others not so trivial. A trivial one would
be attempting compilation in a directory where you had no security
permission to write anything. I suppose that would be my best current
guess. But I'm afraid my confidence in the guess is low. If I don't have
good data, I can't make a good diagnosis.

Although you never mentioned it, I deduce that your errors about opening
the file and about the undeclared variables are from attempts to compile
other code that tries to use the module. You haven't given anywhere near
enough data to allow diagnosis of the details. However, if the
compilation of the module failed, as it sounds like, then it is a waste
of time to try to compile other code that needs the module to be
compiled first.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 4, 4:37 pm, nos@see.signature (Richard Maine) wrote:

PROGRAM rsample
 use global
 implicit none
 integer, dimension(20) :: B
 real sum
 external rnset
 call system('clear')
 print 1
 print*,'please enter 'N, k, and seed'
 read*,N,k,seed
 allocate(A{k))
 call rnset(seed)
 do i=1,20
  B(i)=0
 enddo
 do i=1,1000
  call ini
  call cbs
  call mbl(p)
  call ala(p)
  call rns
 do j=1,10
   B(A(j))=B(A(j))+1
 enddo
 enddo
 print*,B
 sum=0.
 do i=1,20
  sum=sum+)B(i)-500)**2
 endo
  print*,sum/500.
1 format(/)
 END PROGRAM rsample
 MODULE global
  implicit none
  save
  integer N,k
  integer,dimension(:), pointer :: A
 END MODULE global

Complilation errors began on the line "use global"
All other errors were complaints that N, k and A had no type

John

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you have program and module in one file I suggest putting the module first, then all
parts dependent on that module - in this case only the program.
Most compilers cannot automatically resolve the module dependencies.

Best Regards

> Complilation errors began on the line "use global"
> All other errors were complaints that N, k and A had no type

> John

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFGZYeHFVLhKuD7VgsRAo9/AKDZX+9X4vDJ7IfC/kMctezm9fh99ACgqhiQ
OoJu4FTZ3S+zoqbtZRkvDpY=
=LyvT
-----END PGP SIGNATURE-----

John wrote:
> Complilation errors began on the line "use global"
> All other errors were complaints that N, k and A had no type

Try putting the 'global' module before the main program?

Richard

> On Jun 4, 4:37 pm, nos@see.signature (Richard Maine) wrote:
> > Showing us exactly would include at least the exact command used to do
> > the compilation. It would also include the exact text of the error
> > messages.
John <j@lehigh.edu> wrote:
> PROGRAM rsample
>  use global
...
>  MODULE global
...
> Complilation errors began on the line "use global"
> All other errors were complaints that N, k and A had no type

Sigh. We appear to be having communication troubles. I still have yet to
see even a hint as to the command line used, and the most important
error message here is only a hint. I think I'm about to give up here, as
repeating the same suggestion fruitlessly isn't achieving much. In the
meantime...

I do see one problem here, although it doesn't match well with some of
the previously described error messages. But then, given the precision
of the descriptions involved, it is hard to tell.

If you have a module and something that uses the module in the same
file, many compilers require that the module be before whatever uses it.
This is a compiler-dependent issue; not all compilers require that, but
it is pretty common. Moving your module to before the main program would
address that. Another approach is to put the module in a separate source
file and compile that before compiling the main program. Using separate
files is the most common approach, but either will work.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

On Jun 5, 12:09 pm, nos@see.signature (Richard Maine) wrote:

Command to compile: $F90 $FFLAGS rsample.f90 $LINK_FNL

John

On Jun 5, 1:10 pm, John <j@lehigh.edu> wrote:

...

Why if you're coming for help is getting information like pulling
hen's teeth? :(

> Command to compile: $F90 $FFLAGS rsample.f90 $LINK_FNL

_Exact_ error message was???

Have you tried recompiling after rearrange the source as suggested?
What was the result?

--

On Jun 5, 3:45 pm, dpb <bozart@gmail.com> wrote:

Moving the module to the top didn't help.

Compilation errors:

Main program
 use global: error in opening the Library module [GLOBAL]
 read*,N,k,seed: N does not have a type
 read*, N,k,seed: k does not have a type
 allocate(A(k)): A does not have a type

Type errors occur over and over, always involving N, k and A

The module is unusable for some reason. Thank you for your patience.

John

Try a different module name.  From the message, the compiler
thinks that it's a "Library module" (whatever that is) and
you just want a plain old module.  "global" might be some sort
of magic word for your compiler/linker/os.

Without seeing the actual code, it's hard to know for sure.
But, is N, k, and seed come from the module, then if there's a
problem opening the module, it's likely that they will be undefined
in the program.

As I recall, your program is reasonably short.  It's better to include
the actual code when you ask questions.

Dick Hendrickson

On Jun 6, 11:26 am, John <j@lehigh.edu> wrote:

I presume there are no errors or warnings until this one (that is the
module code was (apparently) compile cleanly?

If so, Dick's hypothesis seems plausible that there is somehow
something "magic" about "global" as a module name or other compiler-
specific behavior.

If that doesn't resolve the problem, I'd suggest creating the shortest
possible program that illustrates the problem and posting the whole
thing with the error messages.

It also would probably help to provide the actual compiler and version
and the actual command line used rather than the makefile line you
previously posted which includes the macro definition but not the
expanded values.  W/O them, no one can tell if there's something
peculiar there.

It's such sufficient detail that for some reason you seem reluctant to
provide or don't understand the need for that are the only way anybody
else is going to have a chance of diagnosing a problem.  Remember that
all the information we have is what you provide -- efficiency (and the
probability of keeping somebody interested long enough to get to the
bottom of the problem) are directly related to having that kind of
information...

--

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc