Prev: Announce: Matreshka 0.0.3
Next: ANN: Units of measurement for Ada v3.0
From: Jerry on 13 Apr 2010 15:38
On Apr 12, 6:59 am, John McCormick <mccorm...(a)cs.uni.edu> wrote:
> On Apr 12, 5:36 am, Jerry <lancebo...(a)qwest.net> wrote:
>
> > Thanks, Georg and Manuel, for testing. I'm on OS X 10.5.8 and:
>
> > MBPro:/ me$ gnat
> > GNAT 4.4.0 20080314 (experimental) [trunk revision 133226]
> > Copyright 1996-2007, Free Software Foundation, Inc.
>
> > I've tried the program on three different terminal programs with the
> > same result: it prints out 0 and waits for RETURN, then prints out 1,
> > etc. If I hit q then RETURN the loop is exited. But the loop never
> > "free-runs."
>
> > Jerry
>
> Perhaps the Asynchronous Transfer of Control mechanism would be
> appropriate.  Here is some GNAT code that runs under Windows XP in
> which the input loop is interrutpted by Ctrl-c.  The interrupt handler
> must be at the library level so I put it in its own package.
>
>    select
>       Ctrl_C_Interrupt.Wait;
>       Put_Line ("Handled Ctrl C");
>    then abort
>       loop
>          Put_Line ("Enter an integer (Ctrl C to exit)");
>          Get (Value);
>          Put (Value);
>          New_Line;
>       end loop;
>    end select;
>
> -----------------------------------------------------------
> with Ada.Interrupts.Names;
> package Ctrl_C is
>
>    protected Ctrl_C_Interrupt is
>       entry Wait;
>       procedure Handler;
>       pragma Attach_Handler (Handler, Ada.Interrupts.Names.SIGINT);
>       pragma Interrupt_Priority;
>    private
>       Received : Boolean := False;
>    end Ctrl_C_Interrupt;
> end Ctrl_C;
>
> -----------------------------------------------------------
> package body Ctrl_C is
>
>    protected body Ctrl_C_Interrupt is
>       procedure Handler is
>       begin
>          Received := True;
>       end Handler;
>
>       entry Wait when Received is
>       begin
>          Received := False;
>       end Wait;
>    end Ctrl_C_Interrupt;
>
> end Ctrl_C;
>
> John

Thanks, John.

Your solution does work (after I added pragma
Unreserve_All_Interrupts;) and I think I can adapt it to my specific
problem but it takes 100% of CPU time so I'm not sure how that would
affect my number-crunching loop. (A similar solution was suggested by
Chris on the GNAT-OSX list but I haven't tried it yet.)

Jerry
From: Jerry on 13 Apr 2010 15:51
On Apr 12, 1:04 pm, Simon Wright <si...(a)pushface.org> wrote:
> Tero Koskinen <tero.koski...(a)iki.fi> writes:
> > On Mon, 12 Apr 2010 03:36:42 -0700 (PDT) Jerry wrote:
>
> >> Thanks, Georg and Manuel, for testing. I'm on OS X 10.5.8 and:
>
> > Most likely Get_Immediate is not implemented for OS X and
> > the code is defaulting to blocking behaviour.
>
> > Look at getc_immediate_common in sysdep.c.
>
> > I have there (gcc 4.3.4) following #ifdef jungle:
> > ...
> > {
> > #if defined (linux) || defined (sun) || defined (sgi) || defined (__EMX__) \
> >     || (defined (__osf__) && ! defined (__alpha_vxworks)) \
> >     || defined (__CYGWIN32__) || defined (__MACHTEN__) || defined (__hpux__) \
> >     || defined (_AIX) || (defined (__svr4__) && defined (i386)) \
> >     || defined (__Lynx__) || defined (__FreeBSD__) || defined (__OpenBSD__)
> > ...
>
> > __MACHTEN__ might be related to OS X, but I don't have a Mac around, so
> > I am just guessing.
>
> The current source (r156233) says
>
> {
> #if defined (linux) || defined (sun) || defined (sgi) || defined (__EMX__) \
>     || (defined (__osf__) && ! defined (__alpha_vxworks)) \
>     || defined (__CYGWIN32__) || defined (__MACHTEN__) || defined (__hpux__) \
>     || defined (_AIX) || (defined (__svr4__) && defined (i386)) \
>     || defined (__Lynx__) || defined (__FreeBSD__) || defined (__OpenBSD__) \
>     || defined (__GLIBC__) || defined (__APPLE__)
>
> and it's the __APPLE__ that does the trick. This was fixed 2009-04-15
> (r146098) and is OK in GNAT GPL 2009 and, of course, in GCC 4.5.0 (still
> only 'experimental').

Thanks, Simon. The GPL versions from both your build at sourceforge
and from AdaCore indeed have this problem fixed.

However, both of these builds still contain the old bug which arises
when using
Ada.Numerics.Long_Real_Arrays;
in which the linker can't find the non-existent (on OS X) library
lgnalasup (linear algebra support) requested by i-forbla.adb. I
thought this was fixed a long time ago and if I'm reading the history
correctly it was fixed on Apr 22 07:14:31 2008. I suppose I should
raise this on another thread, however.

Jerry
From: Simon Wright on 13 Apr 2010 17:22
Jerry <lanceboyle(a)qwest.net> writes:

> However, both of these builds still contain the old bug which arises
> when using
> Ada.Numerics.Long_Real_Arrays;
> in which the linker can't find the non-existent (on OS X) library
> lgnalasup (linear algebra support) requested by i-forbla.adb. I
> thought this was fixed a long time ago and if I'm reading the history
> correctly it was fixed on Apr 22 07:14:31 2008. I suppose I should
> raise this on another thread, however.

Same here.

$ gnatmake jerry
gcc -c jerry.adb
gnatbind -x jerry.ali
gnatlink jerry.ali
ld: library not found for -lgnalasup
collect2: ld returned 1 exit status
gnatlink: error when calling /opt/gnat-gpl-2009-x86_64/bin/gcc
gnatmake: *** link failed.

(sorry to take your name in vain, it helps me to keep my ~/tmp
code in order)

4.5.0 has a Darwin-specific i-forbla.adb containing

OX--------------------------------------------
-- Version for Mac OS X

package body Interfaces.Fortran.BLAS is
pragma Linker_Options ("-Wl,-framework,vecLib");
end Interfaces.Fortran.BLAS;
OX--------------------------------------------

and I just managed to link (just a 'with', no execution) with GNAT GPL
2009 by compiling against this file -- I put it in a subdir called math
and said

$ gnatmake jerry -a -Imath
gcc -gnatpg -c -Imath i-forbla.adb
gnatbind -Imath -x jerry.ali
gnatlink jerry.ali
From: Jerry on 14 Apr 2010 23:39
On Apr 13, 2:22 pm, Simon Wright <si...(a)pushface.org> wrote:
> Jerry <lancebo...(a)qwest.net> writes:
> > However, both of these builds still contain the old bug which arises
> > when using
> >     Ada.Numerics.Long_Real_Arrays;
> > in which the linker can't find the non-existent (on OS X) library
> > lgnalasup (linear algebra support) requested by i-forbla.adb. I
> > thought this was fixed a long time ago and if I'm reading the history
> > correctly it was fixed on Apr 22 07:14:31 2008. I suppose I should
> > raise this on another thread, however.
>
> Same here.
>
> $ gnatmake jerry
> gcc -c jerry.adb
> gnatbind -x jerry.ali
> gnatlink jerry.ali
> ld: library not found for -lgnalasup
> collect2: ld returned 1 exit status
> gnatlink: error when calling /opt/gnat-gpl-2009-x86_64/bin/gcc
> gnatmake: *** link failed.
>
> (sorry to take your name in vain, it helps me to keep my ~/tmp
> code in order)
>
> 4.5.0 has a Darwin-specific i-forbla.adb containing
>
> OX--------------------------------------------
> --  Version for Mac OS X
>
> package body Interfaces.Fortran.BLAS is
>    pragma Linker_Options ("-Wl,-framework,vecLib");
> end Interfaces.Fortran.BLAS;
> OX--------------------------------------------
>
> and I just managed to link (just a 'with', no execution) with GNAT GPL
> 2009 by compiling against this file -- I put it in a subdir called math
> and said
>
> $ gnatmake jerry -a -Imath
> gcc -gnatpg -c -Imath i-forbla.adb
> gnatbind -Imath -x jerry.ali
> gnatlink jerry.ali

Awesome. In the past I discovered that if I delete the inappropriate
linker pragma in i-forbla.adb and link with -largs to the BLAS and
LAPACK libraries in the OS X frameworks that I could work around this
problem. But this is better. Following your lead, I moved the newly-
made i-forbla.o and i-forbla.ali into

/opt/gnat-gpl-2009/lib/gcc/i386-apple-darwin9.7.0/4.3.4/adalib

I then moved /opt/gnat-gpl-2009 to /usr/local/ada-4.3 which is where
the Xcode Ada plug-in expects to find a compiler. I also moved your /
opt/gnu/ to /usr/local/gnu.

I can now compile a small program that uses Real_Vector etc. and has a
non-blocking Get_Immediate without any compiler switches using Xcode
with the (ever-brittle) Ada plug-in. 8o)

Trying to use the GUI debugger within Xcode,
(Apple version gdb-768) (Tue Oct 2 04:07:49 UTC 2007)
is mostly successful but it bombs with SIGBUS when trying to single-
step past a Put_Line.

I have also applied the fix to AdaCore's GPL 2009.

Unfortunately, with the new set-up, building PLplot (to which I wrote
Ada bindings) now results in the linker complaining of some dylibs,
"file is not of required architecture."

Jerry
From: John B. Matthews on 15 Apr 2010 00:08
In article
<cde1ed80-fcd9-430d-bb96-07556e58665d(a)30g2000yqi.googlegroups.com>,
Jerry <lanceboyle(a)qwest.net> wrote:

> Awesome. In the past I discovered that if I delete the inappropriate
> linker pragma in i-forbla.adb and link with -largs to the BLAS and
> LAPACK libraries in the OS X frameworks that I could work around this
> problem. But this is better. Following your lead, I moved the newly-
> made i-forbla.o and i-forbla.ali into
>
> /opt/gnat-gpl-2009/lib/gcc/i386-apple-darwin9.7.0/4.3.4/adalib

For convenience, I wrote a little makefile to build and install a
modified i-forbla.adb, et al.

<http://home.roadrunner.com/~jbmatthews/misc/groots.html>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Announce: Matreshka 0.0.3
Next: ANN: Units of measurement for Ada v3.0