Re: gfortran planning meeting

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

On Tue, Oct 31, 2006 at 08:34:12PM +0100, Tobias Burnus wrote:
> Hi,
> 
> Paul Thomas wrote:
> > Jerry,
> >> Oops, I got carried away.  Are we going to have that meeting on IRC.
> > I suggest that we agree a time, a date and an "agenda" of some sort -
> > we also should forewarn the other #gcc-ers.
> One could also join on a #gfortran channel, or start on #gcc and move on
> to a #gfortran channel.
> On the other hand, maybe one gets some nice input from non-fortraners at
> #gcc.
> Maybe one could even be regularly at #gfortran (simply "/join #gfortran").
> 
> 
> In terms of time, gfortraners seem to spread from the American west
> coast to Europe, if I saw it correctly. [No one from Asia or Australia,
> am I right?]
> That is (cf. http://www.worldtimezone.com/):
> PST = UTC-8, EST = UTC-5, CET = UTC+1
> And thus:
> PST EST CET
> 00   03  09
> 05   08  14
> 10   13  19
> 15   18  00
> 20   23  05
> 
> For me, ca. 1100 to 0100 CET = 0500 to 1900 EST = 0200 to 1600 PST would
> be fine.
> Erik wrote that he will be there also at European evening times (EET =
> UTC+2). The later European evening (late afternoon at the East coast,
> early afternoon at the West coast) seems to be a good time.
> Maybe something like 14 PST, 17 EST, 23 CET would be ok?
> 

Tobias,

Looking at your table above, 2 PM PST works for me on Saturday
(kids soccer games occupy the AM).  I'll be on IRC at that time.

Agenda Items:

1) Smashing bugs.
2) Integration of ISO C BINDING when available.  FX tells me that
   it is a huge patch, so many eyes will be needed.
3) Updating the manual (I know that this needs works even with
   Brooks and Daniel's recent efforts).
4) Others?

I personally hope to write the needed mpfr to gmp and gmp to mpfr
bitwise copy patch that pault has asked me to look into.  This
should help fix the last TRANSFER bug.  I also plan to audit 
all mpfr/gmp uses.  Finally, I will take a shot at implementing
the remaining F2003 intrinsic procedure behavior.  REAL(z'f')
is fascinating.

-- 
Steve