Too big

Too big

[mike-h]

"gnatmake -ws -c -u -PC:\Users\Mike\Desktop\Ada\Sudoku_solver\solver.gpr solver-solve.adb
gcc -c -I- -gnatA C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb
cannot generate code for file solver-solve.adb (subunit)
gnatmake: "C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb" compilation error
[2016-03-23 21:55:41] process exited with status 4 (elapsed time: 03.37s)"

What is the most likely reason? For example, the offending subunit contains a large number of "separate" procedures. Would it help to wrap them up in a package?

For information, it's a SUDOKU solver program that attempts to use algorithmic rather than heuristic methods

All sensible suggestions welcom

Mike Hopkins

Re: Too big

[Cotswold Mike]

On Wednesday, 23 March 2016 22:18:51 UTC, Cotswold Mike  wrote:
> "gnatmake -ws -c -u -PC:\Users\Mike\Desktop\Ada\Sudoku_solver\solver.gpr solver-solve.adb
> gcc -c -I- -gnatA C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb
> cannot generate code for file solver-solve.adb (subunit)
> gnatmake: "C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb" compilation error
> [2016-03-23 21:55:41] process exited with status 4 (elapsed time: 03.37s)"
> 
> What is the most likely reason? For example, the offending subunit contains a large number of "separate" procedures. Would it help to wrap them up in a package?
> 
> For information, it's a SUDOKU solver program that attempts to use algorithmic rather than heuristic methods
> 
> All sensible suggestions welcom
> 
> Mike Hopkins

PS A  bit about me - I am a hobby programmer in my ninth decade

Re: Too big

[Anh Vo]

On Wednesday, March 23, 2016 at 3:23:03 PM UTC-7, Cotswold Mike wrote:
> On Wednesday, 23 March 2016 22:18:51 UTC, Cotswold Mike  wrote:
> > "gnatmake -ws -c -u -PC:\Users\Mike\Desktop\Ada\Sudoku_solver\solver.gpr solver-solve.adb
> > gcc -c -I- -gnatA C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb
> > cannot generate code for file solver-solve.adb (subunit)
> > gnatmake: "C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb" compilation error
> > [2016-03-23 21:55:41] process exited with status 4 (elapsed time: 03.37s)"
> > 
> > What is the most likely reason? For example, the offending subunit contains a large number of "separate" procedures. Would it help to wrap them up in a package?
> > 
> > For information, it's a SUDOKU solver program that attempts to use algorithmic rather than heuristic methods
> > 
> > All sensible suggestions welcom
 
This is just a guess. There is at least one grandchild package solver-solve-grandchild*.adb failed to compile correctly.

Anh Vo 

Re: Too big

[Cotswold Mike]

On Wednesday, 23 March 2016 23:04:26 UTC, Anh Vo  wrote:
> On Wednesday, March 23, 2016 at 3:23:03 PM UTC-7, Cotswold Mike wrote:
> > On Wednesday, 23 March 2016 22:18:51 UTC, Cotswold Mike  wrote:
> > > "gnatmake -ws -c -u -PC:\Users\Mike\Desktop\Ada\Sudoku_solver\solver.gpr solver-solve.adb
> > > gcc -c -I- -gnatA C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb
> > > cannot generate code for file solver-solve.adb (subunit)
> > > gnatmake: "C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb" compilation error
> > > [2016-03-23 21:55:41] process exited with status 4 (elapsed time: 03.37s)"
> > > 
> > > What is the most likely reason? For example, the offending subunit contains a large number of "separate" procedures. Would it help to wrap them up in a package?
> > > 
> > > For information, it's a SUDOKU solver program that attempts to use algorithmic rather than heuristic methods
> > > 
> > > All sensible suggestions welcom
>  
> This is just a guess. There is at least one grandchild package solver-solve-grandchild*.adb failed to compile correctly.
> 
> Anh Vo

Many thanks for that suggestion. The trouble started when I began working on a new grandchild procedure (solver-solve-remote_pair_chain). Comment out the call and all goes back to normal. For the moment I'll concentrate on that line of enquiry.

Mike 

Re: Too big

[Robert A Duff]

mike-h@ada-augusta.demon.co.uk writes:

> All sensible suggestions welcom

In GNAT you don't normally compile subunits separately.  You want to
point gnatmake (or gprbuild) at your main procedure, which cannot be a
subunit.

Perhaps you should make Solver.Solve into a child unit instead of a
subunit.  I haven't seen the code, so I don't know for sure.

- Bob

Re: Too big

[rieachus]

 
> What is the most likely reason? For example, the offending subunit contains a large number of "separate" procedures. Would it help to wrap them up in a package?
ther than heuristic methods
> 
> All sensible suggestions welcom

GNAT tends to insert separate units where they belong during compilation.  In other words, separate may be of use to you in organizing your program code, but the compiler never actually sees the unit as separate.

However, if you reuse separate unit names, when the compiler tries to merge the text, you can end up with an infinitely long source file.  Sounds like what is happening to you.

If you just cut and paste to remove separate units until it works, fine.  However, I suspect that you have a more subtle problem in that you are using separate units where you really should be using generics.  There is a sort of "Aha!" moment when you realize that generic instantiation in theory happens at execution time.  (In other words, the generic is instantiated--the formal generic parameters are replaced by the actual (generic) parameters, then the code is called as usual. Ada always goes through this two-step at execution time.  Most of the time one or the other--elaboration or calling--does most of the work, but they are always both done and in order.) The compiler may make several different code objects (at compile time) for a generic unit, and in some cases the correct unit will be selected during execution.

Sounds complex, but it really isn't.  A short example should help:

generic
  type Element is private;
  type My_Array is array (Integer) of Element;
function Reverse(MA: My_Array) is
  Temp: My_Array := MA;
  for I in 1..MA'length loop -- The array bounds here might be say, 11..19.
    Temp(MA'last-I+1) := MA(I);
  end loop;
  return Temp;
end Reverse;

When you say:  function Reverse_String is new Reverse(Character, String);
you get a regular function.  Junk: String := Reverse(Some_string);  Is then a normal call.

Why all this fancy stuff?  The two stages can be a natural separation of roles, and saves you from creating (sometimes) hundreds of busy little operations which you have to keep straight.  I suspect that this gives you the (source) readability you were trying to get with separate.

I think I got all that right.

Re: Too big

[Niklas Holsti]

On 16-03-24 00:18 , mike-h@ada-augusta.demon.co.uk wrote:
> "gnatmake -ws -c -u -PC:\Users\Mike\Desktop\Ada\Sudoku_solver\solver.gpr solver-solve.adb
> gcc -c -I- -gnatA C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb
> cannot generate code for file solver-solve.adb (subunit)
> gnatmake: "C:\Users\Mike\Desktop\Ada\Sudoku_solver\solver-solve.adb" compilation error
> [2016-03-23 21:55:41] process exited with status 4 (elapsed time: 03.37s)"
>
> What is the most likely reason? For example, the offending subunit
> contains a large number of "separate" procedures. Would it help to
> wrap them up in a package?

GNAT's message suggests to me that solver-solve.adb is itself a subunit 
(of solver). GNAT cannot fully compile subunits separately; it can check 
their syntax and semantics, but cannot generate code. GNAT generates the 
code for subunits when it compiles the parent unit. So for GNAT, "is 
separate" works somewhat as "#include" in C.

For example, if I have, in solver.adb:

procedure Solver
is
    X : Integer;

    procedure Solve (A : in out Integer)
    is separate;

begin
    X := 14;
    Solve (X);
end Solver;

and then in solver-solve.adb:

separate (Solver)
procedure Solve (A : in out Integer)
is begin
   A := A + 1;
end Solve;

and give the command "gnatmake -ws -c -u solver-solve.adb" I get

gcc -c solver-solve.adb
cannot generate code for file solver-solve.adb (subunit)
gnatmake: "solver-solve.adb" compilation error

but the command "gnatmake -ws -c -u solver.adb" succeeds and creates 
solver.o.

A consequence of this GNAT property is that dividing a large unit into 
subunits decrease source-file size, but does not decrease compile-time.

Can your problem be this simple?

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .