From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Subject: Re: another way to shoot yourself in the foot?
Date: Wed, 9 Jul 2008 20:39:08 +0100
Date: 2008-07-09T20:39:08+01:00 [thread overview]
Message-ID: <Pine.WNT.4.64.0807091356230.6656@teor2> (raw)
In-Reply-To: <_wPbk.7600$L_.4566@flpi150.ffdc.sbc.com>
I crosspost from news:comp.lang.ada to news:comp.lang.fortran .
Gary Scott posted in news:_wPbk.7600$L_.4566@flpi150.ffdc.sbc.com
on July 5th, 2008:
|-------------------------------------------------------------------------------------|
|"Colin Paul Gloster wrote: |
|> Gary Scott <garylscott@sbcglobal.net> wrote in message |
|> news:NPKbk.14568$N87.10457@nlpi068.nbdc.sbc.com ... |
|> |-------------------------------------------------------------------| |
|> |"Colin Paul Gloster wrote: | |
|> |[..] | |
|> |> and we have FORTRAN and C++ codebases which I should improve. How| |
|> |> better to start than by porting to Ada!? | |
|> | | |
|> |Or Fortran 95 or Fortran 2003 (ok, 2003 is nearly available) | |
|> |<snip> | |
|> |> Regards, | |
|> |> Colin Paul Gloster | |
|> |> | |
|> |> | |
|> | | |
|> | | |
|> |-- | |
|> | | |
|> |Gary Scott" | |
|> |-------------------------------------------------------------------| |
|<snip> |
|> || |
|> || |
|> ||I can understand one choosing Fortran over Ada, simply due to the inertia |
|> || |
|> ||that Fortran has in this domain, and the huge amount of existing Fortran |
|> || |
|> ||code out there." |
| |
|Better reason is that it is vastly improved in recent standards and |
|continues to rapidly evolve." |
|-------------------------------------------------------------------------------------|
Could you please elaborate?
|-------------------------------------------------------------------------------------|
|"[..] |
| |
|My company has extensive Ada experience and has found it quite error |
|prone, inefficient, and difficult to debug and maintain," |
|-------------------------------------------------------------------------------------|
Could you please give examples?
|-------------------------------------------------------------------------------------|
|" and has |
|switched almost entirely to C++." |
|-------------------------------------------------------------------------------------|
Why does Gary Scott's company use almost entirely C++ if Gary Scott recommended Fortran?
Does Gary Scott disagree with the following quotation from Matthew B. Kennel
in news:slrnb19l3m.66u.mbkennelSPAMBEGONE@lyapunov.ucsd.edu
timestamped Fri, 3 Jan 2003 00:08:22 +0000 (UTC)?...
**************************************************************************
*"[..] *
* *
*And why is it "Fortran looking more like C++?" If anything, it is much*
*more like Ada95 (certainly saner and cleaner than C++). *
* *
*[..]" *
**************************************************************************
Gary Scott posted on July 5th, 2008:
|-------------------------------------------------------------------------------------|
|"> Let us not forget that the standardization body took different |
|> directions in two of the latest attempts at an object-oriented Fortran |
|> (though something similar could be said for Ada). |
| |
|Yes, they thoughtfully surveyed dozens of other languages and cherry |
|picked the best features. They picked some from Ada, some from |
|Modula...none from C/C++, but of course they added necessary |
|interoperability." |
|-------------------------------------------------------------------------------------|
Gary Scott edited out all citations to newsgroup posts from circa 2007
which do not promote Fortran. Perhaps posters to
news:comp.lang.fortran would care to inform me as to whether or not
they are valid...
Dan Nagle posted with timestamp Fri, 29 Jun 2007 01:32:54 GMT:
$------------------------------------------------------------------$
$"[..] $
$ $
$The annex in the draft 08 standard detailing undefined behavior $
$was added as a result of the activities of the OWG-V committee. $
$The annex gets substantial additions with every meeting, $
$it's harder than it appears to be to write. The annex includes $
$some entries that say "paragraph such-and-such lists a whole bunch$
$of stuff we don't try to describe" in addition to entries $
$listing specific items." $
$------------------------------------------------------------------$
Phillip Helbig posted with timestamp Tue, 10 Jul 2007 10:55:16 +0000 (UTC):
+----------------------------------------------------------------------------+
+"In article <469242ED.8FFA4...@earthlink.net>, Walter Spector +
+ +
+ +
+<w6ws_xthiso...@earthlink.net> writes: +
+> Phillip Helbig wrote: +
+> > I think I will put this function in a separate module and USE that in +
+> > the main module (or only in the routine which needs it). The name will +
+> > be hard-wired. If desired, the user can edit this new module and +
+> > recompile. +
+ +
+> You might consider simply placing an INTERFACE block in your +
+> main module - which describes the function. Then a user can easily +
+> link in his own version. In this case, his function does not need to +
+> be in a module. So you will not have a compilation dependency problem. +
+ +
+ +
+ +
+True, but then there is no automatic check if the INTERFACE actually +
+corresponds to the code. With the routine in a module, the interface is +
+automatically explicit and automatically correct." +
+----------------------------------------------------------------------------+
B. L. Massingill posted on 7 Jul 2007 07:22:33 GMT:
;---------------------------------------------------------------------------------;
;"In article <2007070314244816807-gsande@worldnetattnet>, ;
;Gordon Sande <g.sa...@worldnet.att.net> wrote: ;
; ;
; ;
;> On 2007-07-03 14:02:02 -0300, "Wade Ward" <inva...@invalid.nyet> said: ;
; ;
;> > I'd love to see authentic fortran source for this. One thing I don't get is ;
;> > what bounds-checking is unltimately going to do for you. Without ;
;> > bounds-checking, when you assign to array(-1) or array(11) in a ;
;> > ten-dimensional array, you get a runtime error. ;
; ;
; ;
;> No! No! You typically get a program that continues on but is not doing what ;
;> you intended. It may continue silently to produce nonsense. It may get into ;
;> some other form of trouble elsewhere. It may even produce the result hoped ;
;> for as the error turns out to be benign. But which will happen is a matter ;
;> of luck, or ... ;
; ;
; ;
;> > With bounds-checking in the same situation you get ...? ;
; ;
; ;
;> You get told that your program is not behaving as intended and that some ;
;> attention to some or other issue is called for. And the issue will have been ;
;> raised early and in a relatively sensible form. ;
; ;
; ;
;> The plaintive query of "My program is crashing and when I put in a single ;
;> write statement it crashes somewhere else. Can anyone help?" is raised ;
;> here with a amazing regularity. Main cause is bad subscripting. Followed ;
;> by argument mismatch. ;
; ;
; ;
;> So could you explain again why ignoring the possible results of subscript ;
;> checking is a good thing. ;
; ;
; ;
; ;
;Because it makes for such interesting bugs? Sort of a :-). ;
; ;
;(I speak as someone who spent several formative years tracking down ;
;bugs in other people's Fortran 66 code, an amazing number of which ;
;turned out to be caused by out-of-bounds array accesses that could ;
;have been avoided by more-careful programming. Everything you ;
;and Richard Main are saying in this thread brings back memories. ;
;And the experience left its mark -- it's beyond my understanding ;
;why "buffer overflow" is as common an explanation as it is for ;
;security holes. <shrug>, maybe.) " ;
;---------------------------------------------------------------------------------;
Ken Fairfield posted on Tue, 03 Jul 2007 13:08:20 -0700:
~---------------------------------------------------------------------------~
~"[..] ~
~ ~
~> I'm thinking he's thinking the typical resulting "ACCVIO" is necessarily ~
~> the initial addressing error??? :) ~
~ ~
~ ~
~ ~
~May be, may not be, depending on a bunch of things... ~
~ ~
~On VMS, I think you typically get an error that reads something ~
~like "bounds error" (it's been so long since I've done one of ~
~these, I don't know off the top of my head), although an ACCVIO is ~
~certainly one possiblity. An ACCVIO usually comes from passing the ~
~wrong number of arguments to a function or subroutine, or an ~
~otherwise "bad" address that "points off into space" as it were. ;-) " ~
~---------------------------------------------------------------------------~
Henrik Holst posted on Fri, 13 Jul 2007 12:15:46 -0700:
^-----------------------------------------------------------------------------^
^"Hi fellow Fortran users (old and new)! ^
^ ^
^I am new to Fortran but not to programming in general. I started to ^
^program more seriously Fortran just a couple of months ago and now I ^
^have come up to a cross section where I need some help to understand ^
^the design of Fortran 90. ^
^ ^
^ ^
^I have seen some serious issues (yes, strong word) with Fortran 90 ^
^modules. The binary compatibility between different compilers - even ^
^on the same architecture - is zero. Also they create a terrible mess ^
^in the Make scripts. I just cannot understand why Fortran 90 thought ^
^there was a need to reinvent the wheel - and make a terrible work ^
^while doing so? ^
^ ^
^ ^
^Let's look at the test module testmod.f90: ^
^MODULE TESTMOD ^
^ INTEGER :: X ^
^CONTAINS ^
^ SUBROUTINE COMPUTE ^
^ END SUBROUTINE ^
^END MODULE TESTMOD ^
^ ^
^ ^
^Between the three different compilers I have available I see the ^
^following difference in the object files: ^
^ ^
^ ^
^gfortran 4.2 ^
^00000000 T __testmod__compute ^
^00000000 B __testmod__x ^
^ ^
^ ^
^Intel Fortran 9.1 ^
^00000000 T testmod._ ^
^00000002 T testmod_mp_compute_ ^
^00000004 C testmod_mp_x_ ^
^ ^
^ ^
^Sun studio 12 ^
^00000000 T testmod.compute_ ^
^00000000 B testmod.x_ ^
^00000000 D testmod_ ^
^ ^
^ ^
^Also the .mod file is different. <sarcasm>The new Fortran 2003 ^
^standard talks about C integration. How about to start with Fortran <- ^
^ ^
^ ^
^ ^
^> Fortran integration? </sarcasm> ^
^ ^
^ ^
^This means that you cannot compile a library with say gfortran and use ^
^it in any other compiler. ^
^ ^
^If you avoid using Fortran modules you can get something that is ^
^binary compatible and usable between the three compilers I have ^
^available and have also tested with. I have [1] a small example of how ^
^to write "module code" without using modules. It boils down to using ^
^INCLUDE instead. There are some negativisms with not using MODULES as ^
^well but not as many. ^
^ ^
^ ^
^Leading researchers is using Fortran 95 [2] with modules I guess I ^
^just have to bend over and recognize that this is broken but nobody ^
^but me seems to care about it. Also, if you look at the BLAS95 ^
^proposal routines, you see lot's of dangerous code. You see unsafe ^
^EXTERN keywords. I would though out modules and replace it with type ^
^checking any day of the week (Do not confuse modules with ^
^interfaces.). ^
^ ^
^ ^
^I think Fortran 90 has lot's of nice features which I think is ^
^essential to a modern programming language. I know I don't have to ^
^follow everyone else and use MODULES. I don't even have to use Fortran ^
^90. But since so many are choosing to use modules and seems fine with ^
^that - where did you dispose of the bodies of those who questioned it? ^
^ ^
^ ^
^Thanks for your comments. I would very very much like to hear what you ^
^have to say about these things. ^
^ ^
^ ^
^[1] http://na37.nada.kth.se/mediawiki/index.php/Fortran_90_goes_back_to_t... ^
^[2] http://www.cs.umd.edu/~stewart/matran/Matran.html ^
^ ^
^ ^
^Cheers, ^
^-- ^
^Henrik Holst, Sweden ^
^http://www.csc.kth.se/~holst/contact.shtml " ^
^-----------------------------------------------------------------------------^
Of course, linking issues between different compilers in Ada are not
always completely easy.
Craig Powers posted on Fri, 06 Jul 2007 17:03:59 -0400:
?----------------------------------------------------------------------------?
?"Gary Scott wrote: ?
?> Beliavsky wrote: ?
? ?
?>> On Jun 28, 8:43 pm, Gary Scott <garylsc...@sbcglobal.net> wrote: ?
? ?
? ?
?>>> I probably don't have the syntax correct, but I read recently that you ?
?>>> can force bounds checking on an array by expressing an access something ?
?>>> like: ?
? ?
? ?
?>>> array.at[i] ?
? ?
? ?
?>>> whereas: ?
? ?
? ?
?>>> array[i] ?
? ?
? ?
?>>> would not cause bounds checking ?
? ?
? ?
?>> I wonder if you are thinking of the vector container in the C++ ?
?>> standard library, which can be substituted for the array of C/C++ in ?
?>> some cases. ?
? ?
? ?
?>>> Would something like that be useful in Fortran? Seems sort of kludgy ?
?>>> and partially redundant to me. ?
? ?
? ?
?>> Good compilers have done checked for some time, and assumed shape ?
?>> arrays "know their own size", so one can determine the dimensions of ?
?>> array arguments of procedures. The C++ vector, unlike the C/C++ array, ?
?>> has a similar feature. ?
? ?
? ?
?> The stated reason for the difference in the article I read was so that ?
?> programmers could directly control in code whether automatic checking ?
?> occurred or not. ?
? ?
? ?
? ?
?Seems to me that only becomes an issue if you have a time-intensive ?
?application where a bounds error happens a long way into the run, and ?
?you can localize to a subset of your arrays. Then, exercising per-array ?
?control over what is and is not bounds-checked could be helpful. ?
? ?
?The other benefit of the .at method is that it gives you tight control ?
?over the results of a bounds error -- you'll get a well-defined ?
?exception thrown, which will allow you to do your own error processing ?
?if you desire instead of tying you to whatever the compiler happens to ?
?do. This is obviously not applicable to Fortran until and unless ?
?Fortran gets an exception mechanism." ?
?----------------------------------------------------------------------------?
James Giles posted with timestamp Thu, 28 Jun 2007 01:03:12 GMT:
%--------------------------------------------------------------%
%"[..] %
% %
%To be sure, there are a number of things the Fortran standard %
%leaves unspecified that it should pin down. [..]" %
%--------------------------------------------------------------%
Richard Maine posted with timestamp Thu, 21 Jun 2007 09:05:59 -0700:
&-------------------------------------------------------------------------&
&"Dick Hendrickson <dick.hendrick...@att.net> wrote: &
&> analys...@hotmail.com wrote: &
&> > (1) There must have been some issues connected with introducing &
&> > unsigned ints as a native data type into Fortran - would the experts &
&> > please spell out what they are ? &
& &
&> Since the experts seem to be busy, I'll take a swing at this. &
& &
& &
& &
&I'll throw in a few things, some of them partially overlapping with &
&Dick's, but from a slightly different different viewpoint. &
& &
&I'll focus on the questions of why anyone would want such a thing. &
&Answers I've seen are &
& &
&[..] &
& &
&3. Points made previously in this thread about things that shouldn't be &
&negative, so it might be nice to have the compiler catch them. These all &
&seem to me to be just special cases of subranges. I don't see that doing &
&unsigned is the "right" way to address that. If one wants subranges, one &
&should do subranges in general rather than one specific case and that &
&case only. There are arguments for doing subranges; they have certainly &
&been proposed. But that's a different proposal. If one is really after &
&subranges, then unsigned does only one specific case and is not &
&plausibly extendable to cover other cases. You'd have to throw it out &
&and start over again to do the more general case. That's not a very good &
&selling point for unsigned if that is the objective." &
&-------------------------------------------------------------------------&
Glen Herrmannsfeldt posted with timestamp Wed, 20 Jun 2007 20:41:23 -0800:
\---------------------------------------------------------------\
\"[..] \
\ \
\The primary need for unsigned in C is for known properties \
\in the case of overflow. C, like Fortran, makes no guarantee \
\on the results for signed integer overflow, but C does require \
\that unsigned arithmetic give the modulo 2**N result for \
\unsigned overflow." \
\---------------------------------------------------------------\
Richard Maine posted with timestamp Mon, 25 Jun 2007 10:01:43 -0700:
&--------------------------------------------------------------------------&
&"Rich Townsend <r...@barVOIDtol.udel.edu> wrote: &
&> Richard Maine wrote: &
&> > As I have &
&> > said here before, allocatables cannot leak memory (except of course, &
&> > through compiler bugs). &
& &
&> This is true in F95, but was it true in F90? &
& &
& &
& &
&No. F90 allocatables were abysmal. They actually did worse than leak &
&memory. The kinds of things that you might think of as potentially &
&leaking memory instead left the allocatable in an undefined state. You &
&could no longer validly do *ANYTHING* with such an allocatable. You &
&couldn't allocate it, because it wasn't deallocated. You couldn't &
&deallocate it becase it wasn't allocated. You couldn't even inquire &
&about its status. &
& &
&F95 fixed all that and got rid of the undefined allocation status. What &
&f95 didn't fix was the severe limitations on where you could use &
&allocatables at all. TR 15581 addressed most of that, with f2003 filling &
&in some "corners" (such as allocatable scalars). &
& &
& &
&But since the code in question has an allocatable function result, f90 &
&seems pretty irrelevant. It requires at least f95+TR. &
& &
& &
& &
&> Important caveat here: Lahey's implementation of TR 15581 is an &
&> unsupported 'feature' of their compiler, and any bug reports concerning &
&> this implementation are viewed -- quaintly -- as 'feature requests'. &
& &
& &
&Ok. Well, I can't address the question of how the vendor responds to bug &
&reports. That doesn't change whether or not it is a bug. In this case, &
&at least, the workaround is simple: just ignore the bogus message. &
&However, the message does make me suspect that there is a more serious &
&underlying bug. Perhaps the compiler does leak memory in this case; &
&that's what the message seems to say. As I mentioned before, compiler &
&bugs can, of course, leak memory." &
&--------------------------------------------------------------------------&
Richard Maine posted at Sat, 7 Jul 2007 16:18:04 -0700:
&--------------------------------------------------------------------------&
&"Wade Ward <inva...@invalid.nyet> wrote: &
&> If it's illegal, then why aren't compilers required to at least say so? &
& &
& &
&This is an absolutely critical point that gets repeated here many times. &
&I suppose it has been a while. Time for the next repeat. :-) &
& &
&There is a specific list of things that compilers are required to &
&detect. It is a tiny fraction of the requirements of the standard. The &
&general philosophy is that the compiler is required to diagnose things &
&that are always easily detectable at compile time. That's not the actual &
&rule, but that's the flavor of the motivation. There turn out to be many &
&rules where the simple cases are detectable at compile time, but &
&complicated cases aren't. The standard doesn't tend to require detection &
&of violation of those rules, but many compilers do detect the simple &
&ones. &
& &
&[..]" &
&--------------------------------------------------------------------------&
Of course, all languages which are not trivial are affected by this,
but how good are Fortran; C++; and Ada in relation to each other in
this regard?
Richard Maine posted on Wed, 11 Jul 2007 18:45:57 -0700:
&------------------------------------------------------------------------&
&"[..] &
& &
&[..] I'll note that I had exactly that kind &
&of problem once in Fortran using TRANSFER to copy the bits of a pointer &
&to temporary storage in an array of integers. The garbage collector &
&trashed that program. Fortunately, I was able to turn the garbage &
&collector off. Although I did not turn it in as a bug report, an &
&acquaintance who worked for the vendor later suggested that if I had &
&made my temporary storage a pointer (even though it would have been a &
&pointer to the wrong type, and thus still needed the TRANSFER), the &
&garbage collector would have left it alone. &
& &
&[..]" &
&------------------------------------------------------------------------&
Richard Maine posted on Wed, 13 Jun 2007 07:41:56 -0700:
&-------------------------------------------------------------------------&
&"Sebastian Gerecke <gere...@omni-vi.kicks-ass.net> wrote: &
&> my program compiles cleanly but upon execution I get &
&> "Segmentation fault (core dumped)". If I change the "forall" statement &
&> with a simple "do" loop, everything works fine. &
&> Does anybody see the reason for that? &
& &
& &
&Probably exceeding stack limits. Either increas the stack limit (which &
&defaults to an unreasonably low size on many systems), or just use the &
&plain DO. &
& &
&As discussed here regularly, there are few benefits and many problems &
&with FORALL. It tends to result in allocation of temporary arrays and &
&more often hinders than helps performance." &
&-------------------------------------------------------------------------&
Of course, stack limits can also be exceeded with Ada. In principle
FORALL should be good, but Fortran implementations thereof seem to be
bad. Is this due to a flaw in the definition of Fortran itself or is
the concept of FORALL simply not simple as might be naively believed
at first sight?
Catherine Rees Lay posted on Wed, 06 Jun 2007 10:27:59 +0100:
!--------------------------------------------------------------------------------!
!"Richard Edgar wrote: !
!> Michael Metcalf wrote: !
!>> <li.sim...@gmail.com> wrote in message !
!>> news:1180710342.819248.32200@j4g2000prf.googlegroups.com... !
!>>> why Fortran didn't assign parameters with initial value of zero?? I !
!>>> think it may be convennient with a zero initial value at most case. !
! !
!>> Because zero is the average value of all representable numbers on a !
!>> computer. If variables are set to this value inadvertently and used in !
!>> calculations, the resulting wrong results will be closer to the true results !
!>> that if the values you quote are used, and thus the fault harder to detect. !
!>> Default initialization to zero is A VERY BAD IDEA. !
! !
! !
!> Thinking on this.... are there any compilers which will do something !
!> useful - like a default initialisation to NaN? IME (admittedly limited), !
!> zero initialisation tends to be the default (and much cursed) unless you !
!> turn on stack allocation of local variables (-stackvar or -automatic !
!> being common options), which gives 'random' values. These are more !
!> likely to cause a crash, but there isn't the nice guarantee which NaN !
!> provides. !
! !
! !
!> Richard !
! !
! !
! !
!This sounds like the Salford (now Silverfrost) /UNDEF feature. Though I !
!don't think they use a specific NaN, just a very very unlikely value !
!which their own system triggered on. !
! !
!In my experience, the majority of bugs in code are due to undefined !
!variables, with almost all the remainder being either array indices out !
!of bounds or mismatching subroutine argument lists. !
! !
! !
!Second (third, etc.) all the comments that initialisation to zero is a !
!very bad idea. If you want a value to be zero, then set it that way. !
!It's a few seconds of typing which will save you hours of debugging when !
!you forget to set the next variable along which should have been 0.005... " !
!--------------------------------------------------------------------------------!
Li Simula posted something which does not induce the impression of
object orientation support in Fortran on Fri, 29 Jun 2007 09:17:05 -0700 in
news:1183133825.857727.286560@m37g2000prh.googlegroups.com (this had
not been cited by Colin Paul Gloster on July 5th, 2008):
#########################################################################
#"I should use Fortran for some special reason (I have some old codes #
#can be referenced) and I want to program my Fortran codes in #
#oop(object#oriented program) strategy. #
# #
#In C++, you can use a base class pointer in main program to invoke the #
#fuctions in derived class. But in Fortran, the derived class is #
#obtained by "use" base class(type or module containing the type), and #
#we known that the "use" is only feasible in a one#direction way(i.e. #
#if A is already use B, then B can't use A) . So, you can't use base #
#class in main program and then invoke functions in derived class in #
#the main program. You can only directly use derived class in main #
#program and then invoke functions in derived class. But I have too #
#many many derived classes! #
# #
# #
#How can fortran simulate the C++ 's this behavior (in C++, the #
#behavior, I think, is in two#direction way)??? #
# #
# #
#Note: I have read some literatures such as professor Akin etc., Decyk #
#etc., but I think their method is not easy to use if the program is #
#more complex which has several levels of derived classes. [They were #
#using a version of Fortran before the object-based FOrtran 95. -- Colin#
#Paul Gloster.] #
# #
# #
#Any suggestion???" #
#########################################################################
Yours faithfully,
Colin Paul Gloster
next prev parent reply other threads:[~2008-07-09 19:39 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 9:03 another way to shoot yourself in the foot? fedya_fedyakoff
2008-06-20 9:34 ` Dmitry A. Kazakov
2008-06-20 9:48 ` fedya_fedyakoff
2008-06-20 10:01 ` Ludovic Brenta
2008-06-20 10:05 ` christoph.grein
2008-06-20 10:26 ` Dmitry A. Kazakov
2008-06-20 16:12 ` Adam Beneschan
2008-06-20 15:48 ` Adam Beneschan
2008-06-20 19:27 ` Robert A Duff
2008-06-20 23:37 ` Jeffrey R. Carter
2008-06-21 8:56 ` Dmitry A. Kazakov
2008-06-22 20:44 ` Robert A Duff
2008-06-23 7:49 ` Dmitry A. Kazakov
2008-06-24 4:02 ` george.priv
2008-06-24 7:30 ` Dmitry A. Kazakov
2008-06-24 17:16 ` Robert A Duff
2008-06-24 19:15 ` Jeffrey R. Carter
2008-06-24 20:31 ` Robert A Duff
2008-06-24 20:50 ` Ludovic Brenta
2008-06-24 23:02 ` Robert A Duff
2008-06-24 23:42 ` Georg Bauhaus
2008-06-24 21:24 ` Jeffrey R. Carter
2008-06-24 23:24 ` Robert A Duff
2008-06-25 15:07 ` Adam Beneschan
2008-06-24 14:59 ` Adam Beneschan
2008-06-24 16:41 ` Dmitry A. Kazakov
2008-06-24 17:20 ` Robert A Duff
2008-06-24 17:52 ` Dmitry A. Kazakov
2008-06-24 23:35 ` Georg Bauhaus
2008-06-25 8:09 ` Dmitry A. Kazakov
2008-06-25 10:32 ` Georg Bauhaus
2008-06-25 12:06 ` Dmitry A. Kazakov
2008-06-22 20:37 ` Robert A Duff
2008-06-22 21:25 ` Jeffrey R. Carter
2008-07-04 20:52 ` Colin Paul Gloster
2008-07-04 22:15 ` (see below)
2008-07-05 16:06 ` Colin Paul Gloster
2008-07-05 13:38 ` Gary Scott
2008-07-05 16:42 ` Colin Paul Gloster
2008-07-05 19:00 ` Gary Scott
2008-07-09 19:39 ` Colin Paul Gloster [this message]
2008-07-09 20:35 ` Richard Maine
2008-07-09 22:49 ` Terence
2008-07-10 1:07 ` Gary Scott
2008-07-10 14:10 ` Colin Paul Gloster
2008-07-10 14:57 ` fj
2008-07-10 16:47 ` Richard Maine
2008-07-10 17:03 ` Dick Hendrickson
2008-07-10 17:26 ` Craig Powers
2008-07-10 19:55 ` James Giles
2008-07-10 20:45 ` Dick Hendrickson
2008-07-10 21:22 ` Richard Maine
2008-07-10 21:29 ` Craig Powers
2008-07-10 20:45 ` Craig Powers
2008-07-10 19:51 ` James Giles
2008-07-11 15:02 ` Colin Paul Gloster
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox