Help with Glade (Annex E) on Windows

Help with Glade (Annex E) on Windows

[Gene]

Is there someone who can help with Glade setup on Windows?  Have tried 
both Academic and free GPL versions.  Gnatdist builds clean with MSYS 
(current version .10).  The bank example works fine.  Two of the prime 
number finding examples work fine.  Two hang after partial output.  
Recursive calls seem to cause this.  The Adacore folks are looking at 
it.

This is for a student who's trying to parallelize a genetic 
algorithm.  Should be a nice project if we can get off the ground.

The trivial RCI code (below) works fine with all partitions on one 
host.  When we put a partition on a separate host, no output.  Clearly 
I'm missing something.

To eliminate the Starter, I have tried starting the partitions 
manually with the following commands:

On host 10.1.0.30:
c:\bin\partition_0 --boot_location tcp://10.1.0.30:1234

On host 10.254.254.10:
c:\bin\partition_1 --boot_location tcp://10.1.0.30:1234

Result is same... Just hung partition processes.

Thanks in advance.
Gene

-- static.cfg
configuration Static is
  pragma Starter(Ada);
  for Partition'Directory use "/bin";
  Partition_0 : Partition := ();
  for Partition_0'host use "10.1.0.30";
  procedure Main is in Partition_0;
  Partition_1 : Partition := (Report_1);
  for Partition_1'host use "10.254.254.10";
end Static;

-- report_1.ads
package Report_1 is
  pragma Remote_Call_Interface;
  function Identity(X : in Integer) return Integer;
  procedure Echo(Rtn : out Integer; X : in Integer);
end Report_1;

-- report_1.adb
with Report;
package body Report_1 is
  function Identity(X : in Integer) return Integer
    renames Report.Identity;
  procedure Echo(Rtn : out Integer; X : in Integer)
    renames Report.Echo;
end Report_1;

-- report.ads
package Report is
  function Identity(X : in Integer) return Integer;
  procedure Echo(Rtn : out Integer; X : in Integer);
end Report;

-- report.adb
package body Report is
  function Identity(X : in Integer) return Integer is
  begin
    return X;
  end Identity;
  procedure Echo(Rtn : out Integer; X : in Integer) is
  begin
    Rtn := X;
  end Echo;
end Report;

-- main.adb
with Ada.Text_IO; use Ada.Text_IO;
with Report_1;
procedure Main is
  I : Integer := 0;
begin
  Put_Line("Start:");
  Report_1.Echo(I, Report_1.Identity(I+1));
  Put_Line(Integer'Image(I));
-end Main;

Re: Help with Glade (Annex E) on Windows

[Dr. Adrian Wrigley]

On Sun, 28 Jan 2007 17:00:19 -0800, Gene wrote:

> Is there someone who can help with Glade setup on Windows?  Have tried 
> both Academic and free GPL versions.  Gnatdist builds clean with MSYS 
> (current version .10).  The bank example works fine.  Two of the prime 
> number finding examples work fine.  Two hang after partial output.  
> Recursive calls seem to cause this.  The Adacore folks are looking at 
> it.

Which version?  I had the serious problems below with GPL 2005, GPL 2006
on x86 Linux.  GNAT 3.15p + glade was more usable.

My view only.  Not officially endorsed!

GNAL GPL 2006 + glade appears to have a number of serious faults.
If you are using glade for professional purposes, you are strongly advised
to use a commercially supported Annex E implementation for your compiler.
Contact AdaCore at sales@adacore.com (or visit http://www.adacore.com/).

The problems with this version are believed to be:

1) Deadlock when making RCI call from within RCI call
   Examples such as Eratho/Spiral will hang during execution.

   You should architect your software to avoid chains of
   remote calls to avoid this bug.

2) Intermittent deadlock when making simultaneous RCI calls on a partition
   using dynamic subprogram binding though Remote Access to
   Class Wide types (RACW).  This occurs with multiple
   tasks or partitions making dynamic remote calls at the same time.
   It is believed this also occurs with remote subprogram access types.
   The problem does not seem to occur when the target of the remote call is
   in the same partition as the boot server and program "main" procedure.

   If possible avoid dynamic binding to remote calls.  If not possible,
   put all the dynamically bound units into the main partition
   ("procedure MainProc is in partition MainPartition" in .cfg file)

3) Failure of MultiPro test case to build in the examples directory.

4) Problem with dependencies - gnatdist sometimes fails to rebuild when necessar
y.
   Certain partition configurations can result in out of date builds
   after source code modifications.

   This bug can be avoided by deleting the old executables before
   invoking gnatdist.

5) Returning SUCCESS return code from gnatdist when compiles fail.
   This cause problems in compilation scripts, since a build may
   complete when errors remain undetected.

   You will need to be careful to watch for errors during build.

6) Failure of "abort" after task calls RCI unit - including timed abort
   with a select statement, as well as simple task abort statements.

   You should avoid using any abort statements to stop a task
   which has executed any remote calls.

7) gnatdist does not pass -m options (such as -m32 for 32-bit build
   on amd64 system) to the compiler, even after -cargs option.

   If building 32-bit and 64-bit code, you are recommended to install
   two versions of the compiler, or use dchroot with a 32-bit environment.

8) Package variables of controlled types are not finalized until
   after the partition communication system is shut down when
   a partition is terminating.  This prevents the finalization routines
   from making any remote accesses to clean up as a package terminates.
   It is unclear whether this is an error.

   You should avoid making remote calls in finalization code which
   may be invoked during partition shutdown.

9) Killing a distributed program and restarting it immediately may
   not work as expected, but produce an error (return code 137).
   Invoking the program a second time will work. Seems to be something
   to do with the IP port not clearing in time.

   Error is:
   raised SYSTEM.GARLIC.COMMUNICATION_ERROR : Do_Listen: tcp bind error

   Solution is to check for this error in a script and retry once.
   Alternatively, waiting ten seconds after killing a program usually works.

10) Shared Passive units crash if values declared are of types with initial valu
es.

11) Shared Passive units crash if protected types are used in them.

    Protected access to Shared Passive data may be achieved by placing
    the protected type in a Remote Call Interface unit instead.

12) Shared Passive units do not seem to detect version mismatches
    between the persistent data and the executing code.

    Users should manually delete the Shared Passive unit data files
    before running new versions with incompatible data representation.

13) Shared Passive units may crash if the data stored is too large(?)
    Test cases have failed with 20kB of SP data.  Cause is unclear.

14) Shared Passive units do not initialise data. This can lead to
    program failure, even when the uninitialised data are not used.
    This problem may be caused by attempts to transmit invalid data.

    Take care to initialise *all* data as early as possible in execution.

These problems are also thought to affect GNAT GPL 2006 glade.
The version of glade supplied with GNAT 3.15p avoids problems (1), (6).

It *is* possible to build reliable code with this release of glade,
provided that the program is designed to avoid the above problems.
Depending on your requirements, this may involve significant
changes to the application architecture.

It may also be possible to avoid some of these problems by
rebuilding your GNAT system with the "setjmp/longjmp" exception
model (use --RTS=sjlj options), in place of the default option
of zero cost exceptions.

Notes by Adrian Wrigley (amtw at linuxchip.demon.co.uk)
23 October 2006.
--
Adrian

Re: Help with Glade (Annex E) on Windows

[Gene]

On Jan 29, 6:29 am, "Dr. Adrian Wrigley" 
<a...@linuxchip.demon.co.uk.uk.uk> wrote:
> On Sun, 28 Jan 2007 17:00:19 -0800, Gene wrote:
> > Is there someone who can help with Glade setup on Windows?  Have tried
> > both Academic and free GPL versions.  Gnatdist builds clean with MSYS
> > (current version .10).  The bank example works fine.  Two of the prime
> > number finding examples work fine.  Two hang after partial output.  
> > Recursive calls seem to cause this.  The Adacore folks are looking at
> > it.
>
> Which version?  I had the serious problems below with GPL 2005, GPL 2006
> on x86 Linux.  GNAT 3.15p + glade was more usable.
>
> My view only.  Not officially endorsed!
>
> GNAL GPL 2006 + glade appears to have a number of serious faults.
> If you are using glade for professional purposes, you are strongly advised
> to use a commercially supported Annex E implementation for your compiler.
> Contact AdaCore at s...@adacore.com (or visithttp://www.adacore.com/).
>
> The problems with this version are believed to be:
>
> 1) Deadlock when making RCI call from within RCI call
>    Examples such as Eratho/Spiral will hang during execution.
>
>    You should architect your software to avoid chains of
>    remote calls to avoid this bug.
>
> 2) Intermittent deadlock when making simultaneous RCI calls on a partition
>    using dynamic subprogram binding though Remote Access to
>    Class Wide types (RACW).  This occurs with multiple
>    tasks or partitions making dynamic remote calls at the same time.
>    It is believed this also occurs with remote subprogram access types.
>    The problem does not seem to occur when the target of the remote call is
>    in the same partition as the boot server and program "main" procedure.
>
>    If possible avoid dynamic binding to remote calls.  If not possible,
>    put all the dynamically bound units into the main partition
>    ("procedure MainProc is in partition MainPartition" in .cfg file)
>
> 3) Failure of MultiPro test case to build in the examples directory.
>
> 4) Problem with dependencies - gnatdist sometimes fails to rebuild when necessar
> y.
>    Certain partition configurations can result in out of date builds
>    after source code modifications.
>
>    This bug can be avoided by deleting the old executables before
>    invoking gnatdist.
>
> 5) Returning SUCCESS return code from gnatdist when compiles fail.
>    This cause problems in compilation scripts, since a build may
>    complete when errors remain undetected.
>
>    You will need to be careful to watch for errors during build.
>
> 6) Failure of "abort" after task calls RCI unit - including timed abort
>    with a select statement, as well as simple task abort statements.
>
>    You should avoid using any abort statements to stop a task
>    which has executed any remote calls.
>
> 7) gnatdist does not pass -m options (such as -m32 for 32-bit build
>    on amd64 system) to the compiler, even after -cargs option.
>
>    If building 32-bit and 64-bit code, you are recommended to install
>    two versions of the compiler, or use dchroot with a 32-bit environment.
>
> 8) Package variables of controlled types are not finalized until
>    after the partition communication system is shut down when
>    a partition is terminating.  This prevents the finalization routines
>    from making any remote accesses to clean up as a package terminates.
>    It is unclear whether this is an error.
>
>    You should avoid making remote calls in finalization code which
>    may be invoked during partition shutdown.
>
> 9) Killing a distributed program and restarting it immediately may
>    not work as expected, but produce an error (return code 137).
>    Invoking the program a second time will work. Seems to be something
>    to do with the IP port not clearing in time.
>
>    Error is:
>    raised SYSTEM.GARLIC.COMMUNICATION_ERROR : Do_Listen: tcp bind error
>
>    Solution is to check for this error in a script and retry once.
>    Alternatively, waiting ten seconds after killing a program usually works.
>
> 10) Shared Passive units crash if values declared are of types with initial valu
> es.
>
> 11) Shared Passive units crash if protected types are used in them.
>
>     Protected access to Shared Passive data may be achieved by placing
>     the protected type in a Remote Call Interface unit instead.
>
> 12) Shared Passive units do not seem to detect version mismatches
>     between the persistent data and the executing code.
>
>     Users should manually delete the Shared Passive unit data files
>     before running new versions with incompatible data representation.
>
> 13) Shared Passive units may crash if the data stored is too large(?)
>     Test cases have failed with 20kB of SP data.  Cause is unclear.
>
> 14) Shared Passive units do not initialise data. This can lead to
>     program failure, even when the uninitialised data are not used.
>     This problem may be caused by attempts to transmit invalid data.
>
>     Take care to initialise *all* data as early as possible in execution.
>
> These problems are also thought to affect GNAT GPL 2006 glade.
> The version of glade supplied with GNAT 3.15p avoids problems (1), (6).
>
> It *is* possible to build reliable code with this release of glade,
> provided that the program is designed to avoid the above problems.
> Depending on your requirements, this may involve significant
> changes to the application architecture.
>
> It may also be possible to avoid some of these problems by
> rebuilding your GNAT system with the "setjmp/longjmp" exception
> model (use --RTS=sjlj options), in place of the default option
> of zero cost exceptions.
>
> Notes by Adrian Wrigley (amtw at linuxchip.demon.co.uk)
> 23 October 2006.
> --
> Adrian

Thanks very much.  Extremely helpful.  I was trying GPL 2006, both 
free and academic versions.

Today I rolled back to 3.15p, and everything started working 
immediately, at least with the synchrnous RCI part of the Annex we 
need.  GPL 2006 seems to be totally unusable on Windows.

If anyone needs help with the Win32 3.15p configuration, write me.

Re: Help with Glade (Annex E) on Windows

[Simon Wright]

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:

> 	Can this really be considered a problem with the GNAT runtime? It
> seems to be common behavior on a number of OS socket stacks, regardless
> of the language used, to have a forced time-out before a port can be
> reused... unless it's been opened with the REUSEADDR option.
>
> 	(Okay, maybe it's a bug that this option is /not/ being used... but
> it is not a commonly used option either>

We use it all the time! can't see any real reason not to ... and IME
it can be a lot longer than 'a few seconds'.