* Ada 95 LRM Error? @ 1999-01-27 0:00 Al Christians 1999-01-27 0:00 ` Martin C. Carlisle ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Al Christians @ 1999-01-27 0:00 UTC (permalink / raw) I'm looking at the Ada 95 Reference Manual, B.4.106. It shows a field: Name : COBOL.Numeric(1..20); Later on, in B.4.109, this gets assigned: Name => "Johnson, John ", This looks pretty obviously like an error, and I think it probably should be Alphanumeric instead of Numeric. However, Numeric is what it is, both in my printed version of the LRM and the online LRM that comes with the brand-new edition of AdaGide. Is 20 even going to work for a Numeric size on typical platforms? That's more than 64 bits. Am I wrong or is this in need of fixing? How would that happen? Al ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 Ada 95 LRM Error? Al Christians @ 1999-01-27 0:00 ` Martin C. Carlisle 1999-01-28 0:00 ` J. David Bryan 1999-01-28 0:00 ` Richard D Riehle 1999-01-28 0:00 ` robert_dewar 2 siblings, 1 reply; 14+ messages in thread From: Martin C. Carlisle @ 1999-01-27 0:00 UTC (permalink / raw) In article <36AF6C22.896FC5B8@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: >I'm looking at the Ada 95 Reference Manual, B.4.106. It shows >a field: > > Name : COBOL.Numeric(1..20); > >Later on, in B.4.109, this gets assigned: > > Name => "Johnson, John ", > >This looks pretty obviously like an error, and I think it probably >should be Alphanumeric instead of Numeric. However, Numeric is what >it is, both in my printed version of the LRM and the online LRM >that comes with the brand-new edition of AdaGide. Actually, there is a newer version of the LRM that I believe is being maintined by: "J. David Bryan" <dbryan@bcpl.net> but it didn't make GNAT 3.11p. I don't recall where he kept it, but I have a copy at: ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/act/incoming/rm-winhelp.tar.gz I agree with your assessment, although if you look at the definitions of Alphanumeric and Numeric, they are the same. So, it's merely a purist sort of thing. --Martin -- Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html DISCLAIMER: This content in no way reflects the opinions, standards or policy of the US Air Force Academy or the United States Government. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 ` Martin C. Carlisle @ 1999-01-28 0:00 ` J. David Bryan 0 siblings, 0 replies; 14+ messages in thread From: J. David Bryan @ 1999-01-28 0:00 UTC (permalink / raw) On 27 Jan 1999 23:23:20 GMT in article <78o758$8ob$1@cnn.Princeton.EDU>, mcc@entropy.cs.princeton.edu wrote... > >I don't recall where he kept it, but I have a copy at: > >ftp://ftp.usafa.af.mil/pub/dfcs/carlisle/act/incoming/rm-winhelp.tar.gz The "primary" copy is at the AdaIC at: http://www.adaic.org/ Follow the link to the Ada95 standards, then to the WinHelp version of the LRM. I will always send updated versions there first, as I don't know in general who might be including it with their own distributions. -- -- Dave Bryan NOTE: Due to unrelenting SPAM, I regret that I have been forced to post with an encoded address. Please ROT13 this message to obtain the reply address. Address also available at http://www.bcpl.net/~dbryan/mailto.html Cyrnfr ercyl gb guvf nqqerff: wqoelna@nyhz.zvg.rqh ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 Ada 95 LRM Error? Al Christians 1999-01-27 0:00 ` Martin C. Carlisle @ 1999-01-28 0:00 ` Richard D Riehle 1999-01-27 0:00 ` Al Christians 1999-01-28 0:00 ` robert_dewar 2 siblings, 1 reply; 14+ messages in thread From: Richard D Riehle @ 1999-01-28 0:00 UTC (permalink / raw) In article <36AF6C22.896FC5B8@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: >I'm looking at the Ada 95 Reference Manual, B.4.106. It shows >a field: > > Name : COBOL.Numeric(1..20); > >Later on, in B.4.109, this gets assigned: > > Name => "Johnson, John ", > >This looks pretty obviously like an error, and I think it probably >should be Alphanumeric instead of Numeric. However, Numeric is what >it is, both in my printed version of the LRM and the online LRM >that comes with the brand-new edition of AdaGide. > >Is 20 even going to work for a Numeric size on typical platforms? That's >more than 64 bits. > >Am I wrong or is this in need of fixing? How would that happen? A look at the data types involved might be helpful. In the package Interfaces.COBOL there are several data types that seem to have the same set of values. Line 13: type COBOL_Character is implementation-defined character type; Line 16: type Alphanumeric is array (Positive range <>) of COBOL_Character := implementation-defined; Line 20: type Numeric is array (Positive range <>) of COBOL_Character := implementation-defined; Line 56: type Alphanumeric corresponds to COBOL's alphanumeric data category. Line 59: type Numeric corresponds to COBOL's numeric data category with display usage. The key words in line 59 are "display usage" which imply that the underlying representation will be one byte per number. Therefore, it is possible that the indicated statements will work in some environments, even though it would have been more appropriate to use alphanumeric. An alphanumeric COBOL number, such as '6', 05 X PICTURE 9. can be assigned directly to a numeric data item, 05 Y PICTURE X. in COBOL if both are USAGE DISPLAY. The Corresponding Ada types would also allow this if the assignment were between slices of the same component type. If there is an error, it may be that the Numeric data type was not more strictly defined to ensure that such assignments require a function call such as, function To_Alphanumeric(N : Numeric) return Alphanumeric; function To_Numeric (A : Alphanumeric) return Numeric; As it is, the package is defined so it conforms to the conventions of typical COBOL programming. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-28 0:00 ` Richard D Riehle @ 1999-01-27 0:00 ` Al Christians 1999-01-28 0:00 ` robert_dewar 1999-01-28 0:00 ` Richard D Riehle 0 siblings, 2 replies; 14+ messages in thread From: Al Christians @ 1999-01-27 0:00 UTC (permalink / raw) Richard D Riehle wrote about Interfaces.Cobol: > > As it is, the package is defined so it conforms to the conventions of > typical COBOL programming. > But if I put non-numeric data into a Numeric, it will flunk the Valid() test, right? Since you speak of 'typical COBOL programming', can you enlighten me a little about why this interface looks the way it does? For example, the To_Binary(Num, Binary_Format) function returns a Byte_Array and not a Binary, and there is no corresponding To_Long_Binary. It looks like To_Binary decides what length of Byte_Array to give back based on the digits of Num. I suppose that the compiler can figure this all out at compile time, since digits is static, but it seems a little odd that the size of a Byte_Array is never really set anywhere in the visible code, but the subtype returned from To_Binary depends on Num's digits. It's also a little confusing that there are 2 binary types, ie Binary and Long_Binary, but that in GNAT, for example, the return values from To_Binary, come in four different sizes (I think). That the Binary_Format doesn't specify the field size also makes it a little hard to be consistent with the Cobol code I know about, which allows a compile time switch to indicate whether or not a number with fewer than 3 digits uses one or two bytes. Here Interfaces.Cobol decides that for me behind the scenes. Thanks for your assistance, Richard. Al ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 ` Al Christians @ 1999-01-28 0:00 ` robert_dewar 1999-01-28 0:00 ` Al Christians 1999-01-28 0:00 ` Richard D Riehle 1 sibling, 1 reply; 14+ messages in thread From: robert_dewar @ 1999-01-28 0:00 UTC (permalink / raw) In article <36AFC42A.57696F4D@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: > That the Binary_Format doesn't specify the field size > also makes it a little hard to be consistent with the > Cobol code I know about, which allows a compile time > switch to indicate whether or not a number with > fewer than 3 digits uses one or two bytes. I don't see anyway the interface can be compatible with odd non-standard COBOL stuff like this! -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-28 0:00 ` robert_dewar @ 1999-01-28 0:00 ` Al Christians 0 siblings, 0 replies; 14+ messages in thread From: Al Christians @ 1999-01-28 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com wrote: > > > I don't see anyway the interface can be compatible with > odd non-standard COBOL stuff like this! > There's also the issue of minimum and maximums within the binary data types. A cobol pic S9(9) comp will generally be represented as 32-bit integer, and the corresponding Ada type will have digits 9. But the 32-bit integer can hold some 10-digit values. IDK which Cobol compilers do how much to prevent these from actually existing -- I suppose it depends on how much run-time type checking is turned on in the programs. I assume that these values, if they exist, should cause an error of some kind if Interfaces.Cobol comes across them. Al ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 ` Al Christians 1999-01-28 0:00 ` robert_dewar @ 1999-01-28 0:00 ` Richard D Riehle 1999-01-28 0:00 ` Interfaces.Cobol (Was LRM Error?) Al Christians 1999-01-29 0:00 ` Ada 95 LRM Error? robert_dewar 1 sibling, 2 replies; 14+ messages in thread From: Richard D Riehle @ 1999-01-28 0:00 UTC (permalink / raw) In article <36AFC42A.57696F4D@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: >Richard D Riehle wrote about Interfaces.Cobol: >> >> As it is, the package is defined so it conforms to the conventions of >> typical COBOL programming. >> > >But if I put non-numeric data into a Numeric, it will flunk the >Valid() test, right? > >Since you speak of 'typical COBOL programming', can you enlighten me a >little about why this interface looks the way it does? > "Well, now, then, there ..." COBOL is not a strongly-typed language. There are, of course, data types in the form of PICTURE characters, but a COBOL programmer has great latitude in performing operations that mix alphanumeric numbers and ordinary alphanumeric characters. 05 Some-Number PICTURE S99V99 USAGE DISPLAY. 05 Some-String PICTURE 9(6). We may freely MOVE (actually MOVE means "copy") the numeric data to the string data without regard to the typing. On the other hand, we will get a compile time error if we try to do arithmetic on the string. The rules for this kind of thing in COBOL are actually rather complex; what is truncated, what is left justified or right justified, all kinds of interesting permutations. If the data type corresponds to COBOL, USAGE DISPLAY, the example shown in the example will work. This does not mean it is good style. It isn't good Ada style, but this package is intended to assist in the interface between Ada and COBOL so a certain amount of flexibility is necessary. As for the function, Interfaces.Cobol.Decimal_Conversions.Valid, invocation depends on the decimal type used for instantiation as well as the actual implementation of type Display_Format. One reason why this is unusual is COBOL's flexibility in where the sign is located in USAGE DISPLAY format. It could be a trailing or leading sign. The people who worked on this package had their work cut out for them. They seem to have done it well, given the huge differences between the COBOL language and Ada. On the positive side, COBOL was designed quite well in the time it was conceived. Consider that it has been one of the most successful programming languages ever used. It would be wonderful if Ada could be even a tenth as successful as COBOL. Richard Riehle richard@adaworks.com http://www.adaworks.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Interfaces.Cobol (Was LRM Error?) 1999-01-28 0:00 ` Richard D Riehle @ 1999-01-28 0:00 ` Al Christians 1999-01-29 0:00 ` Ada 95 LRM Error? robert_dewar 1 sibling, 0 replies; 14+ messages in thread From: Al Christians @ 1999-01-28 0:00 UTC (permalink / raw) Richard D Riehle wrote: > 05 Some-Number PICTURE S99V99 USAGE DISPLAY. > 05 Some-String PICTURE 9(6). > > We may freely MOVE (actually MOVE means "copy") the numeric data > to the string data without regard to the typing. On the other hand, > we will get a compile time error if we try to do arithmetic on the > string. A field that contains 9's only is numeric and can be used for arithmetic even if it is named Some-String. And USAGE DISPLAY just tells how the data is to be stored, not how it is to be used. So, you can do math on either of the two fields above. > > The people who worked on this package had their work cut out for them. I agree 100%. > They seem to have done it well, given the huge differences between the > COBOL language and Ada. Anybody know how much use this package gets? I'd be interested to know how well it works in practice. How many Ada compilers other than GNAT come with it? Do vendors of compilers that don't provide it get any requests for it? Looking at the example in the LRM, I doubt that it gets heavy use as illustrated there. The example shows creating instances of the generic conversion routines for each field to convert. If generics eat up memory, this will be quite a pig to interface to a big Cobol system (say 100's of files, many thousands of fields) -- I think we'd find another way to do it. One alternative is to use Cobol copybooks to generate a wrapper to Interfaces.Cobol for each Cobol copybook, but to only create one instance of the generic converter for each distinct set of Cobol attributes. This would be pretty good, but for a system with many copybooks, you would also want have to avoid duplication between files. But I'd guess that the number of distinct Cobol formats wouldn't go too far up into the hundreds often. I think I'm going to just write a wrapper for Interfaces.Cobol that uses one instance of each of three generics -- for numeric, binary, and packed data, and machine generate the get and set functions that invoke the wrapper. Anyone else already cracked this nut or otherwise interested? Al ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-28 0:00 ` Richard D Riehle 1999-01-28 0:00 ` Interfaces.Cobol (Was LRM Error?) Al Christians @ 1999-01-29 0:00 ` robert_dewar 1999-01-31 0:00 ` Keith Thompson 1 sibling, 1 reply; 14+ messages in thread From: robert_dewar @ 1999-01-29 0:00 UTC (permalink / raw) In article <78qsvv$pim@dfw-ixnews10.ix.netcom.com>, Richard D Riehle <LaoXhai@ix.netcom.com> wrote: > COBOL is not a strongly-typed language. Well ... We need to be careful in the Ada community to distinguish between the notion of strong typing, and the facilities for declaring types. COBOL is definitely strongly typed, and the typing rules will prevent (for example) doing arithmetic on non-arithmetic items. What Richard means is that the typing capabilities of COBOL are weak in the ordinary English sense of the word, but this is not the same as weak typing in the technical sense. C is also a strongly typed language in this technical sense, but again, the facilities for declaring types are poor, and for example, C chooses to make int and char the same type, just as Ada chooses to make natural and integer the same type. When people say that Ada is strongly typed, they mean two things: 1. It has a semantic notion of typing at compile time, with static type checking. 2. It has a well developed typing system, that allows the programmer to easily create types that take advantage of 1. It is actually 2 that is the really important issue in Ada, and indeed I am happy for people to call that strong typing, but it is important to realize that saying "language X is not strongly typed" in language wars discussions may cause confusion of the 1. vs 2. type above, and it is good to understand this source of confusion, so that discussions do not get confused. > There are, of course, data types in the form of PICTURE > characters, but a COBOL programmer has great latitude in > performing operations that mix alphanumeric numbers > and ordinary alphanumeric characters. > > 05 Some-Number PICTURE S99V99 USAGE DISPLAY. > 05 Some-String PICTURE 9(6). > > We may freely MOVE (actually MOVE means "copy") the > numeric data to the string data without regard to the > typing. That's a bit misleading. Such a move is *only* valid if the sending field contains only digits (this is for instance clear from figure 49 of the ANSI 77 standard). A move where other than digits are moved is what Ada programmers would call erroneous. Still, the point that Richard is making, which is that this is not checked at compile time, is valid, and I think it quite appropriate that the COBOL interface of Ada not try to enforce compile time restrictions which would not exist in a normal COBOL environment (there are plenty of "erroneous" COBOL programs in the world :-) Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-29 0:00 ` Ada 95 LRM Error? robert_dewar @ 1999-01-31 0:00 ` Keith Thompson 1999-02-01 0:00 ` Types (was Ada 95 LRM Error?) Richard D Riehle 1999-02-02 0:00 ` Ada 95 LRM Error? robert_dewar 0 siblings, 2 replies; 14+ messages in thread From: Keith Thompson @ 1999-01-31 0:00 UTC (permalink / raw) robert_dewar@my-dejanews.com writes: > C is also a strongly typed language in this technical > sense, but again, the facilities for declaring types are > poor, and for example, C chooses to make int and char the > same type, just as Ada chooses to make natural and integer > the same type. The general point is correct, but the specific point is not; int and char are definitely distinct types in C. Note that there are several possible sources of confusion here. The types char and int are assignment compatible, character literals are of type int, char objects are usually promoted to int in arithmetic expressions, and char function arguments are promoted to int in the absence of a prototype. -- Keith Thompson (The_Other_Keith) kst@cts.com <http://www.ghoti.net/~kst> <*> Qualcomm, San Diego, California, USA <http://www.qualcomm.com> I must be a techno-geek. My mouse is bigger than my phone. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Types (was Ada 95 LRM Error?) 1999-01-31 0:00 ` Keith Thompson @ 1999-02-01 0:00 ` Richard D Riehle 1999-02-02 0:00 ` Ada 95 LRM Error? robert_dewar 1 sibling, 0 replies; 14+ messages in thread From: Richard D Riehle @ 1999-02-01 0:00 UTC (permalink / raw) In article <yecu2x715hb.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: >The general point is correct, but the specific point is not; int and >char are definitely distinct types in C. Semantics, again. Yes, they seem to be "distinct types" (i.e., have distinct names) but the next paragraph makes one wonder. >Note that there are several possible sources of confusion here. The >types char and int are assignment compatible, character literals are >of type int, char objects are usually promoted to int in arithmetic >expressions, and char function arguments are promoted to int in the >absence of a prototype. This reminds me of a card trick expert at some obligatory social function. No matter what card I select, the card trickster will be able to find it through some illusory sleight of hand. My understanding of type, in part, is that a type has, 1) a name, in scope within some declarative region 2) a defined set of operations for objects of the name 3) a defined set of values for objects of the name 4) a "wall" between objects of the named type and objects with some other type name. The last characteristic, a wall, is important for type to have any real meaning. Ada allows us to get beyond the "wall" through type conversion, view conversion, and even unchecked conversion, but the wall is always there. In C, there is no wall. When considered this way, int and char are not really distinct. C allows the dangerous illusion of distinct types, a source of many interesting defects in C and C++ software. The example of Integer, Natural, and Positive does not meet this test because subtypes, in the reserved word sense, have no wall between them. Perhaps int and char are more analogous to Ada entities we define using the subtype reserved word. This thread began with a consideration of the type definitions in the Interfaces.COBOL examples in the Annex B. Robert Dewar has pointed out that COBOL does, in fact, have types, abeit somewhat more flexible types than we find in Ada. Any attempt to interface between a strongly typed language and one that is weakly-type, requires some concession to the characteristics of the weakly-typed language. The ability to implicitly promote one type to another does not seem to me to meet the standards I would expect for "distinct types." It is interesting that one can start with a strongly-type language, one where the default is strong typing, and selectively relax the type model for some targeted environment. It is harder to start with a weakly-typed language and make it strongly-typed. This is one of the key problems with C++. The language starts with the weak typing of C and tries to overlay a model for strong typing. The result is a language that, like the card trickster at the party, seduces the naive programmer into believing in magic. Richard Riehle http://www.adaworks.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-31 0:00 ` Keith Thompson 1999-02-01 0:00 ` Types (was Ada 95 LRM Error?) Richard D Riehle @ 1999-02-02 0:00 ` robert_dewar 1 sibling, 0 replies; 14+ messages in thread From: robert_dewar @ 1999-02-02 0:00 UTC (permalink / raw) In article <yecu2x715hb.fsf@king.cts.com>, Keith Thompson <kst@cts.com> wrote: > robert_dewar@my-dejanews.com writes: > The general point is correct, but the specific point is > not; int and char are definitely distinct types in C. Well I was using type and subtype in the Ada sense, which I agree is a bit confusing, since the notion of type in C subsumes both ideas. But the critical point of the meaning of type in Ada is that different types are not assignment compatible, so in Ada terms, int and char cannot be considered different types. The promotion you talk of in C, corresponds to the conversion of subtypes to the base type in Ada or some such. It is always difficult to compare languages at this level of terminology when the terminologies differ. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada 95 LRM Error? 1999-01-27 0:00 Ada 95 LRM Error? Al Christians 1999-01-27 0:00 ` Martin C. Carlisle 1999-01-28 0:00 ` Richard D Riehle @ 1999-01-28 0:00 ` robert_dewar 2 siblings, 0 replies; 14+ messages in thread From: robert_dewar @ 1999-01-28 0:00 UTC (permalink / raw) In article <36AF6C22.896FC5B8@easystreet.com>, Al Christians <achrist@easystreet.com> wrote: > I'm looking at the Ada 95 Reference Manual, B.4.106. It > shows a field: > > Name : COBOL.Numeric(1..20); > > Later on, in B.4.109, this gets assigned: > > Name => "Johnson, John ", > > This looks pretty obviously like an error, and I think it > probably should be Alphanumeric instead of Numeric. Well first, remember this is just an example, it is not part of the standard, so an error in an example is not of any real significance. Second, oddly the example is indeed completely correct in a formal sense, since the type Numeric is an array of COBOL.Character without any restriction on what can be there. Nevertheless, this is pretty clearly confusing, and examples are supposed to be enlightening, so I agree that Alphanumeric should be used here. Now the next step is to follow the procedure in RM 1(59), and send a comment to the appropriate address: 59 Informal comments on this International Standard may be sent via e-mail to ada-comment@sei.cmu.edu. If appropriate, the Project Editor will initiate a Technical Corrigendum to be issued for the standard. ALso note the formatting requirements in subsequent paragraphs when you send the comment. -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~1999-02-02 0:00 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-01-27 0:00 Ada 95 LRM Error? Al Christians 1999-01-27 0:00 ` Martin C. Carlisle 1999-01-28 0:00 ` J. David Bryan 1999-01-28 0:00 ` Richard D Riehle 1999-01-27 0:00 ` Al Christians 1999-01-28 0:00 ` robert_dewar 1999-01-28 0:00 ` Al Christians 1999-01-28 0:00 ` Richard D Riehle 1999-01-28 0:00 ` Interfaces.Cobol (Was LRM Error?) Al Christians 1999-01-29 0:00 ` Ada 95 LRM Error? robert_dewar 1999-01-31 0:00 ` Keith Thompson 1999-02-01 0:00 ` Types (was Ada 95 LRM Error?) Richard D Riehle 1999-02-02 0:00 ` Ada 95 LRM Error? robert_dewar 1999-01-28 0:00 ` robert_dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox