* RFC: variadic closures in x86/x86_64 @ 2013-11-25 2:46 Hogan, D. (GE Power & Water) 2013-11-25 9:29 ` Andrew Haley 0 siblings, 1 reply; 13+ messages in thread From: Hogan, D. (GE Power & Water) @ 2013-11-25 2:46 UTC (permalink / raw) To: libffi-discuss Hi, I'm requesting feedback on an implementation of variadic closures in libffi. It currently supports x86 and x86_64. This change allows for FMI logging callbacks through JNA in the JFMI[1] and Ptolemy II[2] projects. The libffi changes are in a github branch[3]. I'm waiting to finalize these changes before pushing the JNA branch. It looks like it will be easy to add support for platforms such as SPARC. Are there any platforms that support variadic arguments but would not support variadic closures in this manner? I tested this on x86_64 Linux and x86 Windows. None of the dejagnu tests failed after this change. I could use help testing it on other platforms. Thanks to Christopher Brooks from UC Berkeley for feedback and testing on x86_64 Darwin. Regards, Doug [1] http://ptolemy.eecs.berkeley.edu/java/jfmi [2] http://ptolemy.eecs.berkeley.edu/ptolemyII [3] https://github.com/dhogan1/libffi/tree/variadic_closures ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-11-25 2:46 RFC: variadic closures in x86/x86_64 Hogan, D. (GE Power & Water) @ 2013-11-25 9:29 ` Andrew Haley 2013-11-25 9:37 ` Jakub Jelinek 0 siblings, 1 reply; 13+ messages in thread From: Andrew Haley @ 2013-11-25 9:29 UTC (permalink / raw) To: Hogan, D. (GE Power & Water); +Cc: libffi-discuss On 11/25/2013 02:45 AM, Hogan, D. (GE Power & Water) wrote: > I'm requesting feedback on an implementation of variadic closures in > libffi. It currently supports x86 and x86_64. This change allows for > FMI logging callbacks through JNA in the JFMI[1] and Ptolemy II[2] > projects. The libffi changes are in a github branch[3]. Why is this necessary? I thought that the variadic calling conventions on x86 were the same as the non-variadic ones. Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-11-25 9:29 ` Andrew Haley @ 2013-11-25 9:37 ` Jakub Jelinek 2013-11-25 10:10 ` Andrew Haley 0 siblings, 1 reply; 13+ messages in thread From: Jakub Jelinek @ 2013-11-25 9:37 UTC (permalink / raw) To: Andrew Haley; +Cc: Hogan, D. (GE Power & Water), libffi-discuss On Mon, Nov 25, 2013 at 09:28:52AM +0000, Andrew Haley wrote: > On 11/25/2013 02:45 AM, Hogan, D. (GE Power & Water) wrote: > > I'm requesting feedback on an implementation of variadic closures in > > libffi. It currently supports x86 and x86_64. This change allows for > > FMI logging callbacks through JNA in the JFMI[1] and Ptolemy II[2] > > projects. The libffi changes are in a github branch[3]. > > Why is this necessary? I thought that the variadic calling conventions > on x86 were the same as the non-variadic ones. On x86 they are, on x86_64 they are not (%rax register must contain the number of floating point varargs arguments AFAIK). Jakub ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-11-25 9:37 ` Jakub Jelinek @ 2013-11-25 10:10 ` Andrew Haley 2013-11-26 14:27 ` Alan Modra 0 siblings, 1 reply; 13+ messages in thread From: Andrew Haley @ 2013-11-25 10:10 UTC (permalink / raw) To: Jakub Jelinek; +Cc: Hogan, D. (GE Power & Water), libffi-discuss On 11/25/2013 09:37 AM, Jakub Jelinek wrote: > On Mon, Nov 25, 2013 at 09:28:52AM +0000, Andrew Haley wrote: >> On 11/25/2013 02:45 AM, Hogan, D. (GE Power & Water) wrote: >>> I'm requesting feedback on an implementation of variadic closures in >>> libffi. It currently supports x86 and x86_64. This change allows for >>> FMI logging callbacks through JNA in the JFMI[1] and Ptolemy II[2] >>> projects. The libffi changes are in a github branch[3]. >> >> Why is this necessary? I thought that the variadic calling conventions >> on x86 were the same as the non-variadic ones. > > On x86 they are, on x86_64 they are not (%rax register must contain the > number of floating point varargs arguments AFAIK). Sure, but we don't need a new libffi interface to do that. We need only to set %rax. And we can just do that anyway; it doesn't hurt. I must be missing something. Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-11-25 10:10 ` Andrew Haley @ 2013-11-26 14:27 ` Alan Modra 2013-12-04 8:03 ` Hogan, D. (GE Power & Water) 0 siblings, 1 reply; 13+ messages in thread From: Alan Modra @ 2013-11-26 14:27 UTC (permalink / raw) To: Andrew Haley Cc: Jakub Jelinek, Hogan, D. (GE Power & Water), libffi-discuss On Mon, Nov 25, 2013 at 10:10:37AM +0000, Andrew Haley wrote: > Sure, but we don't need a new libffi interface to do that. We need > only to set %rax. And we can just do that anyway; it doesn't hurt. > > I must be missing something. The claim to fame looks to be the ability to call variadic functions without describing the arguments via ffi_prep_cif_var at the point of call. Instead you do so in the function consuming the args. I'm not sure what that gains you.. The patch suffers from the same flaw as my first attempt at adding variadic argument support for PowerPC64 ELFv2, namely that you cannot add fields to ffi_cif without breaking ABI compatibility. Applications linked against an older version of libffi.so will supply the old ffi_cif to a new shared library.. Oh, and gcc still contains the first attempt since no one has yet approved an import from libffi to cure the problem. -- Alan Modra Australia Development Lab, IBM ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: RFC: variadic closures in x86/x86_64 2013-11-26 14:27 ` Alan Modra @ 2013-12-04 8:03 ` Hogan, D. (GE Power & Water) 2013-12-04 11:05 ` Philip Ashmore 2013-12-04 12:21 ` Andrew Haley 0 siblings, 2 replies; 13+ messages in thread From: Hogan, D. (GE Power & Water) @ 2013-12-04 8:03 UTC (permalink / raw) To: Alan Modra, Andrew Haley; +Cc: Jakub Jelinek, libffi-discuss On Wed, Nov 27, 2013 at 00:57:23PM +1030, Alan Modra wrote: > The claim to fame looks to be the ability to call variadic functions > without describing the arguments via ffi_prep_cif_var at the point of > call. Instead you do so in the function consuming the args. I'm not > sure what that gains you.. This is specifically for variadic callbacks. If it wasn't a callback, I could use ffi_prep_cif_var. To give a little background, FMI is a standard for (among other things) model exchange so you can use a dynamic system model in various modeling or simulation environments. The model is exposed as a C shared library. The shared library executes callbacks (some variadic) provided by a FMU driver. JFMI allows you to drive a FMU from Java. The Java FMU driver provides a Java implementation for the C callbacks. The nonvariadic callbacks were already supported by JFMI through libffi and JNA. In order to handle variadic callbacks, libffi and JNA need to be modified so you can access the variadic arguments inside of a callback. This patch adds the libffi support. I cannot construct a ffi_prep_cif_var because the model's C shared library is the one running a variadic callback in the driver. I don't know how many arguments or what types it will provide in the calls. I have to rely on printf style formatting flags in order to know what to access from inside of the callback. > The patch suffers from the same flaw as my first attempt at adding > variadic argument support for PowerPC64 ELFv2, namely that you cannot > add fields to ffi_cif without breaking ABI compatibility. > Applications linked against an older version of libffi.so will supply > the old ffi_cif to a new shared library.. That's a good point. This should be changed to avoid breaking the ABI. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-12-04 8:03 ` Hogan, D. (GE Power & Water) @ 2013-12-04 11:05 ` Philip Ashmore [not found] ` <F023C084BCC16446BDA5B664305741E8091E8B@ALPMBAPA05.e2k.ad.ge.com> 2013-12-04 12:21 ` Andrew Haley 1 sibling, 1 reply; 13+ messages in thread From: Philip Ashmore @ 2013-12-04 11:05 UTC (permalink / raw) To: libffi-discuss On 04/12/13 08:02, Hogan, D. (GE Power & Water) wrote: > On Wed, Nov 27, 2013 at 00:57:23PM +1030, Alan Modra wrote: >> The claim to fame looks to be the ability to call variadic functions >> without describing the arguments via ffi_prep_cif_var at the point of >> call. Instead you do so in the function consuming the args. I'm not >> sure what that gains you.. > > This is specifically for variadic callbacks. If it wasn't a callback, > I could use ffi_prep_cif_var. > > To give a little background, FMI is a standard for (among other things) > model exchange so you can use a dynamic system model in various > modeling or simulation environments. The model is exposed as a C shared > library. The shared library executes callbacks (some variadic) provided > by a FMU driver. > > JFMI allows you to drive a FMU from Java. The Java FMU driver provides > a Java implementation for the C callbacks. The nonvariadic callbacks > were already supported by JFMI through libffi and JNA. In order to > handle variadic callbacks, libffi and JNA need to be modified so you > can access the variadic arguments inside of a callback. This patch > adds the libffi support. > > I cannot construct a ffi_prep_cif_var because the model's C shared > library is the one running a variadic callback in the driver. I don't > know how many arguments or what types it will provide in the calls. I > have to rely on printf style formatting flags in order to know what to > access from inside of the callback. > >> The patch suffers from the same flaw as my first attempt at adding >> variadic argument support for PowerPC64 ELFv2, namely that you cannot >> add fields to ffi_cif without breaking ABI compatibility. >> Applications linked against an older version of libffi.so will supply >> the old ffi_cif to a new shared library.. > > That's a good point. This should be changed to avoid breaking the ABI. > I may be talking through my hat but if there's a format argument then couldn't you provide a function to parse it and then prepare other cifs on an as-needed basis? The key would be the concatenation of all the types in the format argument. That way you wouldn't need to modify libffi. Regards, Philip Ashmore ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <F023C084BCC16446BDA5B664305741E8091E8B@ALPMBAPA05.e2k.ad.ge.com>]
* Re: RFC: variadic closures in x86/x86_64 [not found] ` <F023C084BCC16446BDA5B664305741E8091E8B@ALPMBAPA05.e2k.ad.ge.com> @ 2013-12-05 13:03 ` Philip Ashmore 0 siblings, 0 replies; 13+ messages in thread From: Philip Ashmore @ 2013-12-05 13:03 UTC (permalink / raw) To: libffi-discuss On 05/12/13 00:54, Hogan, D. (GE Power & Water) wrote: > Hi Philip, > >> I may be talking through my hat but if there's a format argument then >> couldn't you provide a function to parse it and then prepare other cifs >> on an as-needed basis? The key would be the concatenation of all the >> types in the format argument. > > Do you mean inside of a closure? I could access the assumed type > information from the formatting string. The problem would be with > ffi_call(). I can't send in a value for a variadic argument since > I don't have a pointer to it. > No, I mean inside a regular function, as libffi doesn't (yet) support variadic closures. I don't know if it's possible to portably get pointers to variadic arguments using va_arg, but if it is then you build up a list of variadic arguments, synthesize a call using libffi by constructing a cif with prep_cif_var if you don't already have an identical one, then call the "real" function. But then why not just call the "real" function? I was (in my own convoluted way) trying to suggest a possible libffi variadic closure implementation. Any approach needs some hint as to the number and types of arguments to unpack, like a format string. Then it can do what it wants, like provide the arguments as a type/value list, to the psuedo-variadic closure function to process. The psuedo-variadic closure function could then have extra arguments - a count and a type/value array pointer (or a pointer in libffi type-speak) so you wouldn't even need a cif to call it. Regards, Philip Ashmore ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-12-04 8:03 ` Hogan, D. (GE Power & Water) 2013-12-04 11:05 ` Philip Ashmore @ 2013-12-04 12:21 ` Andrew Haley 2013-12-04 18:28 ` Hogan, D. (GE Power & Water) 1 sibling, 1 reply; 13+ messages in thread From: Andrew Haley @ 2013-12-04 12:21 UTC (permalink / raw) To: Hogan, D. (GE Power & Water) Cc: Alan Modra, Jakub Jelinek, libffi-discuss On 12/04/2013 08:02 AM, Hogan, D. (GE Power & Water) wrote: > On Wed, Nov 27, 2013 at 00:57:23PM +1030, Alan Modra wrote: >> The claim to fame looks to be the ability to call variadic functions >> without describing the arguments via ffi_prep_cif_var at the point of >> call. Instead you do so in the function consuming the args. I'm not >> sure what that gains you.. > > This is specifically for variadic callbacks. If it wasn't a callback, > I could use ffi_prep_cif_var. > > To give a little background, FMI is a standard for (among other things) > model exchange so you can use a dynamic system model in various > modeling or simulation environments. The model is exposed as a C shared > library. The shared library executes callbacks (some variadic) provided > by a FMU driver. Please, I'm finding this extremely difficult to understand. Where is the variadic function? You say that a C shared library "executes" a callback, but what does that mean? At the point of the call, the caller knows for certain what arguments are passed, and the type of these arguments. > JFMI allows you to drive a FMU from Java. The Java FMU driver provides > a Java implementation for the C callbacks. Right, so a C program thinks it's calling C, but in fact it's calling Java, and a libffi closure provides the glue. > The nonvariadic callbacks Ah! OK, so the function that is called as a C function is a libffi closure, and it is called in a variadic form. > were already supported by JFMI through libffi and JNA. In order to > handle variadic callbacks, libffi and JNA need to be modified so you > can access the variadic arguments inside of a callback. This patch > adds the libffi support. > > I cannot construct a ffi_prep_cif_var because the model's C shared > library is the one running a variadic callback in the driver. Again, I don't know what it means to "run a variadic callback." Does this mean that the shared library contains this callback function, or that it calls it? > I don't > know how many arguments or what types it will provide in the calls. I > have to rely on printf style formatting flags in order to know what to > access from inside of the callback. OK, so I'm guessing that the C model's shared library calls the variadic function. Why do you not define a variadic C function which does this: void f1(int n, ...) { va_list ap; jintArray argsArray = (*env_p)->NewIntArray(n); jint *args = (*env_p)->GetIntArrayElements(argsArray, NULL); int argno = 0; va_start(ap, n); while (argno < n) { args[argno++] = va_arg(ap, int); } va_end(ap); (*env_p)->ReleaseIntArrayElements(argsArray, args, 0); (*env_p)->CallStaticVoidMethod(clsH, printargs, argsArray); } to call this variadic Java code: public static void printargs(int... args) { for (int i : args) System.out.print(i + " "); System.out.println(); } There is no reason that JNA cannot use this mechanism, is there? Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: RFC: variadic closures in x86/x86_64 2013-12-04 12:21 ` Andrew Haley @ 2013-12-04 18:28 ` Hogan, D. (GE Power & Water) 2013-12-04 18:51 ` Andrew Haley 0 siblings, 1 reply; 13+ messages in thread From: Hogan, D. (GE Power & Water) @ 2013-12-04 18:28 UTC (permalink / raw) To: Andrew Haley; +Cc: Alan Modra, Jakub Jelinek, libffi-discuss On Wed, Dec 04, 2013 at 00:07:21AM, Andrew Haley wrote: > Please, I'm finding this extremely difficult to understand. Where is > the variadic function? You say that a C shared library "executes" a > callback, but what does that mean? Sorry about the confusion. I mean the driver sends to the shared library a struct of function pointers when it creates a model instance. It is represented in JNA as a Structure of Callbacks. One of the function pointers is variadic: typedef struct { void (*logger)(fmiComponent c, fmiString instanceName, fmiStatus status, fmiString category, fmiString message, ...); void *(*allocateMemory)(size_t nobj, size_t size); void (*freeMemory) (void *obj); } fmiCallbackFunctions; And this is a function inside of every shared library model: fmiComponent instantiateModel(char* fname, fmiString instanceName, fmiString GUID, fmiCallbackFunctions functions, fmiBoolean loggingOn) The model dereferences the function pointers inside of a common file, fmuTemplate.c, which is included in every model. Here's an example: fmiStatus fmiSetInteger(fmiComponent c, const fmiValueReference vr[], size_t nvr, const fmiInteger value[]){ int i; ModelInstance* comp = (ModelInstance *)c; ... if (comp->loggingOn) comp->functions.logger(c, comp->instanceName, fmiOK, "log", "fmiSetInteger: nvr = %d",nvr); ... } > Right, so a C program thinks it's calling C, but in fact it's calling > Java, and a libffi closure provides the glue. Yeah. JNA uses a libffi closure to provide the glue. The problem is closures cannot currently access variadic arguments. If you try to write an implementation of the logger above as a Callback in JNA, it won't be able to access anything beyond message. This is a limitation inherited from libffi's closure. > Ah! OK, so the function that is called as a C function is a libffi > closure, and it is called in a variadic form. Right. > Again, I don't know what it means to "run a variadic callback." Does > this mean that the shared library contains this callback function, or > that it calls it? The shared library dereferences a pointer to a variadic function. > Why do you not define a variadic C function which does this: > > void f1(int n, ...) { > va_list ap; In the libffi manual, there's a TODO about variadic closures. My interpretation of variadic closures is a closure which can access variadic arguments without sending in the number of arguments and types at the ffi_prep_cif or ffi_prep_cif_var time. Once you have a variadic closure, you should be call it any number of times with any number of variadic arguments. If libffi had that, JNA could create a closure and the Java callback/function pointer could access variadic arguments in any manner that it sees fit. It wouldn't need an application specific C wrapper that captures the varargs. For instance, taking the simple testsuite/libffi.call/cls_sint.c, what would it look like if you had variadic closures? Below is similar to what it would look like with this patch. diff --git a/testsuite/libffi.call/cls_sint.c b/testsuite/libffi.call/cls_sint.c index c7e13b7..d456be5 100644 --- a/testsuite/libffi.call/cls_sint.c +++ b/testsuite/libffi.call/cls_sint.c @@ -7,14 +7,21 @@ /* { dg-do run } */ #include "ffitest.h" -static void cls_ret_sint_fn(ffi_cif* cif __UNUSED__, void* resp, void** args, +static void cls_ret_sint_fn(ffi_cif* cif, void* resp, void** args, void* userdata __UNUSED__) { + void *vals[1]; + *(ffi_arg*)resp = *(signed int *)args[0]; - printf("%d: %d\n",*(signed int *)args[0], - (int)*(ffi_arg *)(resp)); + + /* Assuming the first variadic argument is sint. */ + CHECK(ffi_closure_va_arg(cif, &ffi_type_sint32, &vals[0]) == FFI_OK); + + printf("%d: %d %d\n",*(signed int *)args[0], + (int)*(ffi_arg *)(resp), *(signed int *)vals[0]); + } -typedef signed int (*cls_ret_sint)(signed int); +typedef signed int (*cls_ret_sint)(signed int, ...); int main (void) { @@ -33,8 +40,10 @@ int main (void) CHECK(ffi_prep_closure_loc(pcl, &cif, cls_ret_sint_fn, NULL, code) == FFI_OK); - res = (*((cls_ret_sint)code))(65534); - /* { dg-output "65534: 65534" } */ + res = (*((cls_ret_sint)code))(65534, 32); + /* { dg-output "65534: 65534 32" } */ + res = (*((cls_ret_sint)code))(65534, 32, 64.5); /* 64.5 is ignored but allowed */ + /* { dg-output "65534: 65534 32" } */ printf("res: %d\n",res); /* { dg-output "\nres: 65534" } */ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-12-04 18:28 ` Hogan, D. (GE Power & Water) @ 2013-12-04 18:51 ` Andrew Haley 2013-12-05 0:47 ` Hogan, D. (GE Power & Water) 0 siblings, 1 reply; 13+ messages in thread From: Andrew Haley @ 2013-12-04 18:51 UTC (permalink / raw) To: Hogan, D. (GE Power & Water) Cc: Alan Modra, Jakub Jelinek, libffi-discuss On 12/04/2013 06:28 PM, Hogan, D. (GE Power & Water) wrote: > On Wed, Dec 04, 2013 at 00:07:21AM, Andrew Haley wrote: > >> Why do you not define a variadic C function which does this: >> >> void f1(int n, ...) { >> va_list ap; > > In the libffi manual, there's a TODO about variadic closures. That's AFAIK to do with targets that have a different calling convention for variadic calls. > My interpretation of variadic closures is a closure which can access > variadic arguments without sending in the number of arguments and > types at the ffi_prep_cif or ffi_prep_cif_var time. Once you have a > variadic closure, you should be call it any number of times with any > number of variadic arguments. Forgive me, but that's not an answer. I have provided an example of a mechanism that JNA could use that would not require us to change libffi. Couldn't you do this in JNA? It doesn't have to be application-specific. Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
* RE: RFC: variadic closures in x86/x86_64 2013-12-04 18:51 ` Andrew Haley @ 2013-12-05 0:47 ` Hogan, D. (GE Power & Water) 2013-12-05 8:33 ` Andrew Haley 0 siblings, 1 reply; 13+ messages in thread From: Hogan, D. (GE Power & Water) @ 2013-12-05 0:47 UTC (permalink / raw) To: Andrew Haley; +Cc: Alan Modra, Jakub Jelinek, libffi-discuss On Wed, Dec 04, 2013 at 00:01:51PM, Andrew Haley wrote: > > In the libffi manual, there's a TODO about variadic closures. > > That's AFAIK to do with targets that have a different calling > convention for variadic calls. Ok, this is the source of my confusion then. I thought the manual was saying you wanted libffi to be able to create closures that could iterate through variadic arguments they were called with. > > My interpretation of variadic closures is a closure which can access > > variadic arguments without sending in the number of arguments and > > types at the ffi_prep_cif or ffi_prep_cif_var time. Once you have a > > variadic closure, you should be call it any number of times with any > > number of variadic arguments. > > Forgive me, but that's not an answer. I have provided an example of a > mechanism that JNA could use that would not require us to change > libffi. Couldn't you do this in JNA? It doesn't have to be > application-specific. I'm sure it would work. A similar suggestion is mentioned in the CFFI documentation. It would require a C function for every assumed variadic processing convention. For instance, FMI requires #<Type><valueReference># which is not a typical printf/logger convention. I didn't go down that path because I thought the manual was asking for patches for a different way. Thanks for the feedback. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: RFC: variadic closures in x86/x86_64 2013-12-05 0:47 ` Hogan, D. (GE Power & Water) @ 2013-12-05 8:33 ` Andrew Haley 0 siblings, 0 replies; 13+ messages in thread From: Andrew Haley @ 2013-12-05 8:33 UTC (permalink / raw) To: Hogan, D. (GE Power & Water) Cc: Alan Modra, Jakub Jelinek, libffi-discuss On 12/05/2013 12:47 AM, Hogan, D. (GE Power & Water) wrote: > I'm sure it would work. A similar suggestion is mentioned in the CFFI > documentation. It would require a C function for every assumed > variadic processing convention. For instance, FMI requires > #<Type><valueReference># which is not a typical printf/logger > convention. I didn't go down that path because I thought the manual > was asking for patches for a different way. > > Thanks for the feedback. Hmm, I'm sorry for pushing back in this way, but I think we'd need to make the changes to all of our twenty or so back ends. And of course no-one wants to do that. Andrew. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-12-05 13:03 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-11-25 2:46 RFC: variadic closures in x86/x86_64 Hogan, D. (GE Power & Water) 2013-11-25 9:29 ` Andrew Haley 2013-11-25 9:37 ` Jakub Jelinek 2013-11-25 10:10 ` Andrew Haley 2013-11-26 14:27 ` Alan Modra 2013-12-04 8:03 ` Hogan, D. (GE Power & Water) 2013-12-04 11:05 ` Philip Ashmore [not found] ` <F023C084BCC16446BDA5B664305741E8091E8B@ALPMBAPA05.e2k.ad.ge.com> 2013-12-05 13:03 ` Philip Ashmore 2013-12-04 12:21 ` Andrew Haley 2013-12-04 18:28 ` Hogan, D. (GE Power & Water) 2013-12-04 18:51 ` Andrew Haley 2013-12-05 0:47 ` Hogan, D. (GE Power & Water) 2013-12-05 8:33 ` Andrew Haley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).