[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: E-Mail Correspondence
|
From: |
Camm Maguire |
|
Subject: |
[Gcl-devel] Re: E-Mail Correspondence |
|
Date: |
Sat, 16 May 2009 10:22:49 -0400 |
|
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) |
Greetings!
Matt Kaufmann <address@hidden> writes:
> Hi, Camm --
>
> Congratulations on the progress!
>
> As for suggestions, one is something I mentioned in an email to you on
> May 8:
>
>>> GCL 2.6.7 seems to restrict to 1024 #= definitions. Do you know of
>>> any (preferably easy) way to lift this restriction?
>
This can trivially be revised to any larger constant by editing the
following line of read.d and recompiling:
#ifndef SHARP_EQ_CONTEXT_SIZE
#define SHARP_EQ_CONTEXT_SIZE 500
#endif
It appears that I could make this dynamically readjustable in about a
day of work. If a much larger constant would suffice for now, that
might be better from a workload management point of view. Please
advise. If dynamic is needed, I can get it done.
> This restriction might lead our heaviest ACL2 user to stop using GCL.
>
> Another thing I'd find useful for development (I'm not sure about
> Warren and Bob) is more useful backtrace information at the user
> level. Below is an example using Allegro CL from a log I happened to
> have lying around from work I did yesterday, just to show what I'd
> like. It illustrates some nice features:
>
I've also been working on this a bit. As you know, 2.7.0 now carries
around the source of compiled functions, so we have more options here.
Bob Boyer once remarked to me that there was no excuse for GCL not
binding the argument values to their variable names in the function
definition, and he is right -- this appears simple, but I don't know
how helpful. I.e. in your example, instead of (nth 4 *), you could
refer to the argument by name. I suppose the backtrace display would
have to include the variable name too to be useful, but this might
clutter things up too much. Alternately, the names could appear only
in a :bl display.
As you are aware, :up and :down already exist, with apparently reverse
interpretations. I hope that is not critical, as the notion of "up
the call stack" is alas permanently embedded in my aging gray matter
:-).
I presume you can step over forms too. Also, from gdb experience,
'finish' and 'return' are vital. Here I'm not sure what to do in the
case of compiled functions and would appreciate some advise. One
could reload the source and run interpreted automatically with the
same arguments, for example, but this might engender side effects. I
think this was the approach Schelter took with his emacs mode, but
I've just begun to look into this. Definitely want this to be hardened
in the release of 2.7.0.
In short, everything you mention here is quite doable, but still falls
short of the facilities one has in a debugger like gdb. It appears
the main differences with current gcl are questions of display, so I'd
like to ask a few clarifying questions:
> - While the default number of frames is 8, the :count argument (to
> :zoom, the backtrace command) allows control over that.
OK, limiting the default number of frames is new to GCL. :bt n
currently displays n frames. Does this encompass :zoom and :count?
> - You can easily move up and down the stack with up and dn.
Do :up and :down suffice?
> - The stack shows forms at the Lisp level, with about the right amount
> of hiding of subexpressions.
> - The :current command gives you access to the current form.
:bt currently binds *print-length* and *print-level* to reasonable
values -- should these be changed? The big difference here is the
lack of loc0 noise and the display format, I think:
>(si::use-fast-links nil)
NIL
>(in-package 'compiler)
#<"COMPILER" package>
COMPILER>(trace (c1vref :entry (break)))
(C1VREF)
COMPILER>(compile 'compile)
;; Compiling /tmp/gazonk_5522_0.lsp.
1>
Break.
Broken at LET. Type :H for Help.
COMPILER>>:bt
#0 TRACE-CALL
{loc0=#:g1797,loc1=(#:g91),loc2=t,loc3=t,loc4=(break),loc5=t,loc6=(cons (quote
c...} [ihs=22]
#1 C1VREF {#:g91=nil,} [ihs=21]
#2 C1VAR {loc0=#:g91,loc1=#:g91} [ihs=20]
#3 C1EXPR {loc0=#:g91,loc1=((#:g91 integer -2 ...) (#:g93 integer -2147483648
...) (#:g999...} [ihs=19]
#4 C1EXPR* {loc0=#:g91,loc1=#S(info type t ...)} [ihs=18]
#5 C1LET* {loc0=(((#22=#:g92 #) (#23=#24=#:g93 #) (#3=#25=#:g91 #) ...)
(declare (:dynamic...} [ihs=17]
#6 C1SYMBOL-FUN {loc0=let*,loc1=(((#22=#:g92 #) (#23=#24=#:g93 #)
(#3=#25=#:g91 #) ...) (declare...} [ihs=16]
#7 C1EXPR {loc0=(let* ((#22=#:g92 #) (#23=#24=#:g93 #) (#3=#25=#:g91 #) ...)
(declare (:dy...} [ihs=15]
#8 C1PROGN {loc0=((let* (# # # ...) (declare #) ...))} [ihs=14]
#9 C1BLOCK {loc0=(compile (let* (# # # ...) (declare #) ...))} [ihs=13]
#10 C1SYMBOL-FUN {loc0=block,loc1=(compile (let* (# # # ...) (declare #)
...))} [ihs=12]
#11 C1EXPR {loc0=(block compile (let* (# # # ...) (declare #) ...)),loc1=nil}
[ihs=11]
#12 C1PROGN {loc0=((block compile (let* # # ...)))} [ihs=10]
#13 C1DECL-BODY {loc0=nil,loc1=((block compile (let* # # ...)))} [ihs=9]
#14 C1LAMBDA-EXPR {loc0=((name) (let* (# # # ...) (declare #)
...)),loc1=compile} [ihs=8]
#15 T1DEFUN {loc0=(compile (name &optional def) (block compile (let* # #
...)))} [ihs=7]
#16 T1EXPR {loc0=(defun compile (name &optional def) ...)} [ihs=6]
#17 COMPILE-FILE1
{loc0=#P"/tmp/gazonk_5522_0.lsp",loc1=#P"/tmp/gazonk_5522_0.o",loc2=t,loc3=nil,l...}
[ihs=5]
#18 COMPILE-FILE
{loc0=#P"/tmp/gazonk_5522_0.lsp",loc1=nil,loc2=nil,loc3=#<output stream
"/tmp/ga...} [ihs=4]
#19 COMPILE {loc0=compile,loc1=(nil),loc2=nil} [ihs=3]
COMPILER>>:up
#1 C1VREF {#:g91=nil,} [ihs=21]
COMPILER>>:up 6
#7 C1EXPR {loc0=(let* ((#22=#:g92 #) (#23=#24=#:g93 #) (#3=#25=#:g91 #) ...)
(declare (:dy...} [ihs=15]
COMPILER>>:bl
>> NIL():
Local(0): (LET* ((G92 #) (G93 #) (G91 #) ...)
(DECLARE (DYNAMIC-EXTENT G999))
...)
Local(1): REF
NIL
(si::loc 0) and (si::loc 1) here give the arguments. So would
reformatting this, and binding :current as you state above, suffice
here?
> - Variables *, **, *** work as in the top-level loop.
>
I'm not sure I understand -- do these refer to the last evaluated
forms in the debugger? I think this is currently the case in GCL
too.
> I don't know if GCL can provide this level of backtrace help, but
> anyhow, I find it useful.
Thank you so much for your feedback here. Its very important to me to
make sure GCL is productive for people.
Take care,
>
> Break: call to the `break' function.
>
> Restart actions (select using :continue):
> 0: return from break.
> 1: Return to Top Level (an "abort" restart).
> 2: Abort entirely from this (lisp) process.
> [1c] ACL2(4): [RAW LISP] :zoom :count t
> Evaluation stack:
>
> (BREAK)
> ->(SGETPROP1 CONSP FORWARD-CHAINING-RULES ...)
> (FGETPROP CONSP FORWARD-CHAINING-RULES ...)
> (ADD-NEW-FC-POTS (CONSP X) NIL ...)
> (ADD-NEW-FC-POTS-LST (# # #) NIL ...)
> (ADD-NEW-FC-POTS (NOT #) NIL ...)
> (ADD-NEW-FC-POTS-LST-LST (# #) NIL ...)
> (FORWARD-CHAIN (# #) NIL ...)
> (BUILT-IN-CLAUSEP (# #) (# # # . 0) ...)
> (TIMED-PROVE (#) (O< # #) ...)
> (CCMF->-VALUE? (#) (ACL2-COUNT X) ...)
> (CCMF-VALUE (#) FOO ...)
> (ACCG-CONSTRUCT-CCMF-GRAPH (#) FOO ...)
> (ACCG-ANNOTATE #(#) #S(CCG-RESTRICT :CCMFS-PER-NODEP T ...) ...)
> (BUILD-AND-ANNOTATE-ACCGS (FOO) (#) ...)
> (PROVE-TERMINATION-WITH-CCG (FOO) :HYBRID ...)
> (CCG-PUT-INDUCTION-INFO (FOO) (#) ...)
> (CCG-DEFUNS-FN0 :UNKNOWN :UNKNOWN ...)
> (CCG-DEFUNS-FN (#) ACL2_INVISIBLE::|The Live State Itself| ...)
> (RAW-EV-FNCALL DEFUN-FN
> (# ACL2_INVISIBLE::|The Live State Itself| #) ...)
> [... EV-REC ]
> (EV (DEFUN-FN '# STATE ...) (#) ...)
> (EV-FOR-TRANS-EVAL (DEFUN-FN '# STATE ...) (STATE) ...)
> (TRANS-EVAL (DEFUN FOO # ...) TOP-LEVEL ...)
> (LD-READ-EVAL-PRINT ACL2_INVISIBLE::|The Live State Itself|)
> (LD-LOOP ACL2_INVISIBLE::|The Live State Itself|)
> (LD-FN-BODY ACL2-INPUT-CHANNEL::STANDARD-OBJECT-INPUT-0 (# # # ...)
> ...)
> (LD-FN0 (# # # ...) ACL2_INVISIBLE::|The Live State Itself| ...)
> (LD-FN (# # # ...) ACL2_INVISIBLE::|The Live State Itself| ...)
> (LP)
> [... EXCL::%EVAL ]
> (EVAL (LP))
> (TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP)
> (TPL:START-INTERACTIVE-TOP-LEVEL
> #<EXCL:TERMINAL-SIMPLE-STREAM [initial terminal io] fd 0/1 @
> #x71129782>
> #<Function TOP-LEVEL-READ-EVAL-PRINT-LOOP> ...)
> [1c] ACL2(5): [RAW LISP] :dn 8
> Evaluation stack:
>
> (BREAK)
> (SGETPROP1 CONSP FORWARD-CHAINING-RULES ...)
> (FGETPROP CONSP FORWARD-CHAINING-RULES ...)
> (ADD-NEW-FC-POTS (CONSP X) NIL ...)
> (ADD-NEW-FC-POTS-LST (# # #) NIL ...)
> (ADD-NEW-FC-POTS (NOT #) NIL ...)
> (ADD-NEW-FC-POTS-LST-LST (# #) NIL ...)
> (FORWARD-CHAIN (# #) NIL ...)
> (BUILT-IN-CLAUSEP (# #) (# # # . 0) ...)
> ->(TIMED-PROVE (#) (O< # #) ...)
> (CCMF->-VALUE? (#) (ACL2-COUNT X) ...)
> (CCMF-VALUE (#) FOO ...)
> (ACCG-CONSTRUCT-CCMF-GRAPH (#) FOO ...)
> (ACCG-ANNOTATE #(#) #S(CCG-RESTRICT :CCMFS-PER-NODEP T ...) ...)
> (BUILD-AND-ANNOTATE-ACCGS (FOO) (#) ...)
> (PROVE-TERMINATION-WITH-CCG (FOO) :HYBRID ...)
> (CCG-PUT-INDUCTION-INFO (FOO) (#) ...)
> (CCG-DEFUNS-FN0 :UNKNOWN :UNKNOWN ...)
> (CCG-DEFUNS-FN (#) ACL2_INVISIBLE::|The Live State Itself| ...)
> (RAW-EV-FNCALL DEFUN-FN
> (# ACL2_INVISIBLE::|The Live State Itself| #) ...)
> [... EV-REC ]
> (EV (DEFUN-FN '# STATE ...) (#) ...)
> (EV-FOR-TRANS-EVAL (DEFUN-FN '# STATE ...) (STATE) ...)
> (TRANS-EVAL (DEFUN FOO # ...) TOP-LEVEL ...)
> (LD-READ-EVAL-PRINT ACL2_INVISIBLE::|The Live State Itself|)
> (LD-LOOP ACL2_INVISIBLE::|The Live State Itself|)
> (LD-FN-BODY ACL2-INPUT-CHANNEL::STANDARD-OBJECT-INPUT-0 (# # # ...)
> ...)
> (LD-FN0 (# # # ...) ACL2_INVISIBLE::|The Live State Itself| ...)
> (LD-FN (# # # ...) ACL2_INVISIBLE::|The Live State Itself| ...)
> (LP)
> [... EXCL::%EVAL ]
> (EVAL (LP))
> (TPL:TOP-LEVEL-READ-EVAL-PRINT-LOOP)
> (TPL:START-INTERACTIVE-TOP-LEVEL
> #<EXCL:TERMINAL-SIMPLE-STREAM [initial terminal io] fd 0/1 @
> #x71129782>
> #<Function TOP-LEVEL-READ-EVAL-PRINT-LOOP> ...)
> [1c] ACL2(6): [RAW LISP] :current
> (TIMED-PROVE ((IF (CONSP X) (CONSP X) (CONSP Y)))
> (O< (ACL2-COUNT (CDR X)) (ACL2-COUNT X))
> #S(CCG-RESTRICT :CCMFS-PER-NODEP T
> :BIC-ONLYP T
> :TIME-LIMITP NIL
> :TIME-LIMIT 0
> :MEASURE-VARS ...)
> ((2098
> (:HEADER :DIMENSIONS (2500) :MAXIMUM-LENGTH 2501
> :DEFAULT NIL :NAME ENABLED-ARRAY-0 :ORDER ...)
> (2098 :TYPE-PRESCRIPTION HONSP-CHECK)
> (2097 :EXECUTABLE-COUNTERPART HONSP-CHECK)
> (2096 :DEFINITION HONSP-CHECK)
> (2095 :TYPE-PRESCRIPTION NUMBER-SUBTREES)
> (2094 :EXECUTABLE-COUNTERPART NUMBER-SUBTREES)
> (2093 :DEFINITION NUMBER-SUBTREES)
> (2092 :INDUCTION FASTER-CONS-SUBTREES)
> (2091 :TYPE-PRESCRIPTION FASTER-CONS-SUBTREES) ...)
> (ENABLED-ARRAY-0 . 2500)
> (#\E #\N #\A #\B #\L #\E #\D #\- #\A #\R ...) . 0)
> ((FOO STOBJS-OUT NIL) (FOO STOBJS-IN NIL NIL)
> (FOO FORMALS X Y)
> (COMMAND-LANDMARK GLOBAL-VALUE 5875
> (:LOGIC INCLUDE-BOOK #3="ccg35" . #1=(:TTAGS :ALL)))
> (EVENT-LANDMARK GLOBAL-VALUE 6959
> (INCLUDE-BOOK "/v/filer4b/kaufmann/temp/peterd/ccg/ccg35.lisp")
> INCLUDE-BOOK
> #2="/v/filer4b/kaufmann/temp/peterd/ccg/ccg35.lisp"
> . #1#)
> (ACL2-DEFAULTS-TABLE TABLE-ALIST (:DEFUN-MODE . :LOGIC)
> (:INCLUDE-BOOK-DIR-ALIST)
> (:CASE-SPLIT-LIMITATIONS 500 100))
> (TTAGS-SEEN GLOBAL-VALUE (:CCG #2#))
> (INCLUDE-BOOK-PATH GLOBAL-VALUE)
> (CERTIFICATION-TUPLE GLOBAL-VALUE
> . #4=(#2# #3# "ccg35"
> ((:SKIPPED-PROOFSP) (:AXIOMSP) (:TTAGS #))
> . 100200260))
> (INCLUDE-BOOK-ALIST GLOBAL-VALUE #4#
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/all.lisp"
> "hacking/all" "all" (# # #) . 1044285911)
>
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/table-guard.lisp"
> "table-guard" "table-guard" (# # #) . 1836095829)
>
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/subsumption.lisp"
> "subsumption" "subsumption" (# # #) . 188084489)
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/bridge.lisp"
> "bridge" "bridge" (# # #) . 1543367436)
>
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/redefun.lisp"
> "redefun" "redefun" (# # #) . 510136008)
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/raw.lisp"
> "raw" "raw" (# # #) . 354526780)
>
> ("/v/filer4b/v11q001/acl2/v3-5-linux/books/hacking/defcode.lisp"
> "defcode" "defcode" (# # #) . 361101965)
> ...)
> ...)
> (DEFUN . FOO) ACL2_INVISIBLE::|The Live State Itself|)
> [1c] ACL2(7): [RAW LISP] (cdddr (nth 4 *))
> 0
> [1c] ACL2(8): [RAW LISP]
>
> Thanks --
> -- Matt
> cc: Robert Boyer <address@hidden>, address@hidden,
> address@hidden
> From: Camm Maguire <address@hidden>
> Date: Fri, 15 May 2009 15:06:38 -0400
> X-SpamAssassin-Status: No, hits=-2.5 required=5.0
> X-UTCS-Spam-Status: No, hits=-280 required=165
>
> Greetings!
>
> "Warren A. Hunt Jr." <address@hidden> writes:
>
> > Hi Camm,
> >
> >> I'd love to visit. I'll be out of the country for
> >> the next 10 days, but thereafter I'm quite flexible.
> >> Rhonda would love to come too, I'm sure, and you are
> >> so kind to offer.
> >
> > Great! We will be gone for spring break (3/14 - 3/21).
> > Just a couple of days later, I leave for UK for 9 days.
> > So, a visit in April is possible. Even though I will
> > be traveling in UK, I will be reading my E-mail, so we
> > can make some arrangements. I'm glad to hear that your
> > wife may join you; it will be great to meet her. I
> > don't remember the ages of your children -- are they
> > old enough to look after themselves?
> >
>
> Following up ---
>
> There is a board meeting in Dallas on 6/5 that I would like to
> attend. Is there a possibility of woring in a GCL visit either before
> or after? Sorry for the short notice, but the date has just been
> changed.
>
> BTW -- my account on elgin seems to be disabled? Can no longer public
> key ssh in.
>
>
> >> Perhaps we can discuss more when I return. I'd like
> >> to harden the current gcl work, and your
> >> consultation and advise, (especially that of Bob
> >> Boyer) is so critical in this regard. Quite a few
> >> new facilities are available or possible, it is
> >> simply in judging the tradeoffs and deciding what is
> >> most useful that demands consultation, IMHO.
> >
> > For much of the last year, Bob and I have used the
> > 64-bit version of Clozure Common Lisp. We have been
>
> I gather that one 64bit GCL weakness that might be addressed is the
> requirement that every pointer use up 64 bits.
>
> > performing a lot of symbolic simulation, and our work
> > seriously stresses whatever Lisp implementation we are
> > using. Just as Bob's excellent consulations help you
> > with GCL, we even more desparately need your help when
> > we are pushing the limits GCL. Presently, we have an
> > eight-processor Dell computer with 128 GByte RAM -- we
> > often fill the memory of this computer as we attempt
> > verification of large circuits. I look forward to our
> > re-establishing a technical dialog.
> >
>
> Great! Toward that end --
>
> I've found some time over the last two weeks to put in some work on
> GCL towards a 2.7.0 release. I've gutted the function calling
> structure, in part for for performance, in part for preparation for
> threads, and in part, because it is clear from the code that Schelter
> wanted to go in this direction before he passed away. Hence, I'll
> call this function call "Schelter's best".
>
> As you may be aware, GCL has had sfuns, vfuns, afuns, cfuns, closures,
> cclosures .... In this branch these are consolidated into one struct,
> 't_function', all calls of which, regardless of signature proclaims,
> funcalls, apply's, etc, proceed through the same fast link mechanism,
> whereby a single pointer dereference retrieves the function address
> and the jump is made to the C function body.
>
> To achieve this, at most three globals need to be set, which can be
> kept on the C stack when threading is enabled. These three are the
> number of arguments passed, the address for storing extra values
> returned, and the function itself for use in referencing the closed
> over environment. These settings are not made when it is known that
> the function does not need them, hence an anonymous function call is
> only three instructions heavier than a call to a traditional simple
> function, assuming fast linking proceeds, which it will if caller and
> callee at least agree on the number and type of regular arguments. As
> earlier discussed, if only one value is sought, the multiple value
> return address is set to 0, and only one value is written. Apply
> calls share structure with rest arguments in the callee. If type
> coersions are needed, the call is heavier in case of caller/callee
> information mismatch, but is correct in all cases.
>
> Hence it seems best to me at this point to disable automatic
> recompilation at load time. This was primarily motivated by making
> sure the image was correct (i.e. would not segfault) at all times, but
> this appears to now be resolved by this calling consolidation. (In
> prior 2.7.0, for example, the multiple value address is passed as a
> function argument instead of in a global. While this is manifestly
> thread ready, one must be absolutely sure about the call signature if
> one wants to avoid the 100x increase in function call overhead or a
> segfault.) One still can get important improvements by analyzing call
> signatures in a given system (i.e. knowing a returned sequence is a
> list, etc.), but this is perhaps best an optional refinement offered
> to the user for use in finalizing an image. I'm therefore proposing
> that si::*disable-recompile* defaults to t. If agreeable, this
> resolves one of the major obstacles in my mind to a 2.7.0 release.
>
> As earlier stated, GCL has a few nifty new related features -- full
> support for unboxed complex floating point, and persistent (across
> image saves) loading of functions from external shared C libraries,
> which when inlined proceed through a single pointer dereference.
> Local unboxed types (i.e. for use in calls in the same file, or
> variables insied a function) are char, short, fixnum, float, double,
> fcomplex and dcomplex. We have support for two more unboxed global
> types (i.e. calls across different files) in addition to fixnum, one
> of which needs to be a word-sized float. I'm open to suggestions for
> the other, though it must be word sized. 31 unboxed arguments and one
> unboxed return are supported at the moment.
>
> The C overhead for a function is small at a minimum:
>
> struct function {
>
> FUNWORD;
>
> ofunc fun_self;
> object fun_data;
> plist fun_plist;/* sig callees src file flags */
> ufixnum fun_argd; /*checking*/
> object *fun_env;
>
> };
> #define FUNWORD ufixnum
> e:1,m:1,f:1,s:1,t:5,fun_minarg:6,fun_maxarg:6,fun_neval:5,fun_vv:1,w:LM27BITS
>
> fun_self is the address, fun_data the shared data for the compiled
> file, fun_plist an optional list containing the compressed source, the
> list of callees, the signature, the source file path, and various
> function property flags, argd the unboxed status of the arguments and
> return, and env the environment if any, which I did manage to get
> working as relblock instead of the slower contblock. 6 bits each for
> minarg and maxarg can designate up to 64 args, 5 bits for 31 extra
> values, vv indicates that the number of values is variable. callers
> are stored on the symbol plist, as it is the call of a function via
> its symbol, and the fact that this can be redefined after the symbol
> is compiled, which leads to the signature match/proclaims tension. My
> idea is that after a system is optionally analyzed and recompiled, it
> can then be locked, and the function plist and symbol caller
> information can be discarded.
>
> performace examples:
>
> (defun baz (x y) (let ((z 0)) (dotimes (i x z) (incf z (apply '+ y)))))
>
> (compile 'baz)
>
> (setq y (make-list 60 :initial-element 1))
>
> (1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1)
>
> ;;current GCL
> (time (baz 1000000 y))
>
> real time : 1.220 secs
> run-gbc time : 1.180 secs
> child run time : 0.000 secs
> gbc time : 0.000 secs
> 60000000
>
> ;; New funcall
> (time (baz 1000000 y))
>
> real time : 0.180 secs
> run-gbc time : 0.180 secs
> child run time : 0.000 secs
> gbc time : 0.000 secs
> 60000000
>
> Thoughts/feedback as always most welcome.
>
> Take care,
>
>
> > Cheers,
> >
> > Warren
> >
> >
> >
> >
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Re: E-Mail Correspondence,
Camm Maguire <=